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.

IMGLIB2 IMG_quantize bug

Other Parts Discussed in Thread: CCSTUDIO

I downloaded the IMGLIB2 (imglib2.l64P), and found out that the IMG_quantize is not performing correctly. 

Could you please fix it?

Thanks.

  • Are you following all the special requirements:

    · The block size, blk_size, must be at least 32 and a multiple of 16.
    · The Q-point, q_pt, controls rounding and final truncation; it must be in the range 0 <= q_pt <= 31.
    · Both input arrays, data[ ] and recip_tbl[ ], must be double-word aligned.
    · The data[ ] array must contain num_blks * blk_size elements, and the recip_tbl[ ] array must contain blk_size elements.

     

  • Sorry for my unclear statement.

    All the settings are right.

    If I use the IMG_Quantize from IMGLIB1 (previous version), the result is right.  

    If I use the C functions of IMG_Quantize, the result is also right.

    Only the IMG_quantize from IMGLIB2 generates wrong result.

     

     

     

  • Alan,

     

    I don't think the kernel has changed between the v1.0 and v2.0 release. I did a quick diff between the ASM file at:

    C:\CCStudio_v3.3\c64plus\imglib_v201\kernels\asm\IMG_quantize.asm

    and

    C:\CCStudio_v3.3\c64plus\imglib\lib\img64plus.src

    I don't see any difference.

    Do you have a test case that highlights the problem?

     

    Thanks,

    Gagan

  • "The previous version" in my case is C:\CCStudio_v3.2\c6400\imglib\lib\img64x.src.  (I throught this is the IMGLIB v1.0).

    Alan

     

  • Alright. So you are comparing with the older version that was on 64x devices. Yes, there were multiple changes that have been done when moving to 64x+. As the code is in handASM, it will take some time to debug. For now, I would recommend using the 64x version of quantize kernel but continue using the latest 64x+ library for others. Sorry for trouble.

     

  • No problem. Thanks for support.

    The handASM of IMG_fdct_8x8 is faster than previous version, and it is generating correct result.

     

  • Alan,

            I am unable to recreate this issue with our test setup. Can you send me a failing test-case?

    Thanks & Regards,

    Sadanand

  • I could not attached the image file here.

    could you tell me your email address so that I can send it to you?

    Alan

     

  • You should be able to post a file to the forums in your personal profile, click on your name in the upper right hand corner of the page to get to your profile and from there there should be a section at the bottom that allows you to post up a file.

  • I posted the image I used in testing.

    But you need to convert it into YUV format first, then do encoding.

    Thanks for support

    Alan

  • Alan,

        Thanks for your quick response.

     

    However, we will need some more information/data to reproduce the bug. I am assuming that you are working on the MPEG2 encoder with this. Is that correct?

     

    Assuming you are working on a video encoder, coding a particular frame depends on a large number of factors. These include the frame type, (I, P or B), ME, the rate control parameters, etc. More-over your motion-estimation algorithm will produce different results compared to the standard codec.

    As I do not have access to your source code as well as your complete set of inputs, I will not be able to reproduce this error with a single input frame.

     

    It will be great if you can tap the input and output of the IMG_quantize() function for this frame and send it over.(i.e. write the input parameters, such as the data array, num_blks, blk_size, recip_table, q_point and the output data array in a text file and post it. You can do this by placing conditional fprintf() in the c version of this function. Thus whenever this function is called, based on the write control flag, the data will be written out.) This will ensure that I have bit matching input as you do.

     

    You can use the following sample source code to dump data:

     

     

    if ( data_dump == TRUE) {   // data_dump is set to TRUE based on the frame number

          int i, j;

          /* fp should be a valid file handle */

     

          /* Write the input */

          if( fprintf( fp, "num_blks = %d, blk_size = %d, q_pt = %d\n", num_blks, blk_size, q_pt) == 0 ) {

                printf( "\nUnable to write test data\n Exiting....\n");

                exit(0);

          }

     

          for(i = 0; i < num_blks; i++) {

                fprintf(fp, "\n%d => ", i);

                for(j = 0; j < blk_size; j++) {

                      fprintf( fp, "%d, ", data[i*num_blks + j]);

                }

          }

    }

     

    // IMG_quantize code.

     

    // write the output

    if ( data_dump == TRUE) {   // data_dump is set to TRUE based on the frame number

          int i, j;

          /* fp should be a valid file handle */

     

          for(i = 0; i < num_blks; i++) {

                fprintf(fp, "\n%d => ", i);

                for(j = 0; j < blk_size; j++) {

                      fprintf( fp, "%d, ", data[i*num_blks + j]);

                }

          }

    }

     

    You also need to send me the quant table for this frame. If your quant table changes within the frame, print the quant table also with other data for each call of the function.

     

    Thanks again for your co-operation in helping us fix this issue.

     

    Regards,

    Sadanand.