This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

davinci resizer output is bad

Hi,
We are using our custom made board with DM6446 on which i am  resizing an composite input image 720x576 to 192x160.
My problem is that the quality of output image is very bad. i am not seeing that problem when i try to resize a smaller image to larger
size the quality of image is ok but whenever i am resizing larger image to smaller size the quality of image degrades????
Any suggestions...

  • Did you recompute your resizer coeffcients for 192x160 case?  The following App Note gives a good description of how the resizer works and provides a utility for calculating the proper resizer coefficients.

    http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spraai7b

  • Hi Juan,

    Thanks for your reply. I have gone through the application note that u provided.

          I am using the Resize_ API from the DMAI Interface as it is given. I have gone through the

    c     code given in resize.c for calculating coeffs for the resizer & it looks correct to me.

           & i'm using the default resizer attributes. given in the resize.c file i.e.

            const Resize_Attrs Resize_Attrs_DEFAULT = {
        Resize_FilterType_LOWPASS,
        Resize_FilterType_LOWPASS,
        Resize_WindowType_BLACKMAN,
        Resize_WindowType_BLACKMAN,
        0xe
     };

           So i believe it is not a problem of resizer coeffs .

           Any suggestions!!!!!!!!

                

  • What DVSDK version of the software are you using?  I can investigate further to see if there are any software contraints (none documented in the latest DVSDK that I can see).

  • well I am using DVSDK version 2.00.00.22.

    DMAI version 1.20.00.06.

    I have written my code exactly as defined in the API reference doc dvsdk_2_00_00_22/dmai_1_20_00_06/dmai_1_20_00_06_ApiReference.html.

    API's used are Resize_create, Resize_config, Resize_execute, Resize_delete for resizing PAL(720x576) image to 192x160.

     

  • can you try resizing with the following DMAI application to see how quality compares.

         .../dmai_1_20_00_06/packages/ti/sdo/dmai/apps/video_loopback_resize

     

  • Hi Juan,

    thanks again for the reply. video_loopback_resize also gives the same kind of output.

    Also i would like to bring to your attention the following piece of code from dmai_1_20_00_06/packages/ti/sdo/dmai/linux/dm6446/resize.c line 247

    case Resize_FilterType_LOWPASS:
                /* Optimize upscaling as it always produces the same coeffs */  -
                if (rsz < 256) {
                    for (i=0; i<NUM_COEFS; i++) {
                        coeffs[i] = upsamplingCoeffs[i];
                    }
                    return;
                }

    if you look at the comment It seems the resize code is always using same upsampling coeffs which are fixed & should be different for each set of input & output resolution.

    Hope u will analyse this.

    However the link u send was helpful i used the calccoeffs utility to generate the correct horizontal & vertical coefficents & now the

    output of resizer is coming properly. The only thing is I have to hardcore the horizontal & vertical value whereas i would have liked it to be calculated

    dynamically.

     

    thanks & regards

    yuvraj pasi

     

  • Hi,

    I too am facing the same issue. I have been looking around in Resize.c to check if i can find the root of the problem.

    It seems that the code block,

    case Resize_FilterType_LOWPASS:
                /* Optimize upscaling as it always produces the same coeffs */
                if (rsz < 256) {
                    for (i=0; i<NUM_COEFS; i++) {
                        coeffs[i] = upsamplingCoeffs[i];
                    }
                    return;
                }

    , has been inserted for the purpose of optimizing the calculation of the coefficients.  The reason this appears to be done is because, while upsampling it seems always the same coefficients are generated and hence it seems to have been hardcoded.

    However, while doing downsampling this condition will not be met, and so begins the process of calculating the filter coefficients. From what i have found out, this is where the problem lies. The only reason, the upsampling is working, is because these values have been hardcoded for upsampling. Had the upsampling_coefficients not been hardcoded, upsampling too would produce bad output (i have not tested this yet, but i am pretty sure).

    To make a comparison, i generated the horizontal and vertical filter coefficients for a particular downsampling operation using the calcCoef tool, and generated for the same operation using the Resizer API for DMAI, and the two were way too off.

    There appears to be a BUG (which i think is probably a typo of some sort) in the computation of the filter coefficients in the calcCoeffs() call. Which i have not been able to trace. A comparison between the source calcCoef and Resize.c could easily get this issue fixed.

    Last time i checked calcCoef was distributed in binary form only. Is the source code made open now? If yes, can you please direct me as to where i could be able to pick it upfrom and get this issue fixed.

    PS. I am working on the DM6446 platform.

    Thanks and Regards

    ~Sameer

  • Yuvraj , Sameer

    Thank you for your feedback; I will report this to our software team.  Based on your comments, I would agree that there is likely a bug in DMAI that needs investigating.  Unfortunately, it appears that calccoeff utility source code is not available, but we should be able to fix the DMAI software and allow for dynamic calculation of the coefficients.

  • looks like Sameer beat me to it; bug has been submitted and can be tracked here

  • a quick question.

    should i keep any hopes of the issue being fixed, not that a bug report has been filed?
    from what i see, there are open bugs that date back a year.

  • Sameer,

    We certainly consider all bug submissions and was a little surprised to see open bugs that are over a year old.  I thank you for calling this to our attention and am hoping is just a matter of fauilure to update the status on the outstanding issues.  I am investigating this and will post when I have more news.