• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 102 subscribers
  • Views 643 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Still Image JPEG Compression

Taylor Smith2
Prodigy 30 points

Hi all,

I'm looking to implement JPEG compression of still images using the 5515 eZdsp. My input will be raw pixel data from this sensor:

https://www.aptina.com/products/image_sensors/mt9v022ia7atc/

which will be mounted on this module:

 http://www.videologyinc.com/cameras/cmos-board-camera-24B752XA.htm#cmos-board-camera-24B752XA=overview

After processing one image the JPEG file will be stored to SD before moving on to the next image.

I am just starting out on this task but it looks like the c55x image library (http://www.ti.com/tool/SPRC101) has the tools I need. My anticipated problem is that the sensor outputs pixel data in either 10 or 12 bits, however the image library seems to only deal with Q16.0 data input (16 bits). I am getting this info from the image library programmer's reference.  Does anyone know how I could deal with this? Or is it actually a problem at all?

I would appreciate any insight into this and into this task in general. Maybe someone could point me in the direction of a previous implementation or something similar. Please keep in mind this is my first time doing this kind of work :)

Thank you very much for reading and for any comments

EDIT: I guess I will add my other questions as well. As I understand it this is how the library can be used to JPEG compress some raw pixel data, 8x8 array of pixels at a time. Please correct any problems you see

1. call IMG_fdct_8x8 which does the DCT on your pixels

2. call IMG_jpeg_make_recip_tbl which makes your reciprocal quantization table. I am not clear here on how this quantization table will be generated (or downloaded?)

3. call IMG_jpeg_quantize which quantizes the pixels. This requires an input of a zigzag table, again which I'm not sure about how it will be generated or downloaded?

4. call JPEG_vlc_init which initializes the Huffman code

5. call IMG_jpeg_vlc which does the variable length coding, the output of which will be a compressed block of 8x8 pixels in JPEG format. Correct?

Any insight on where the quantization table and zigzag table actually come from would be greatly appreciated. Sorry for lack of experience, thanks!

  • 0
    TI__Mastermind 35645 points

    Hi,

    Team is working on and we would address your request as soon as we can.

    Thanks & regards,

    Sivaraj K

  • 0
    TI__Intellectual 1530 points

    A 10-12 bit data input shouldn't be a problem as it can be sign-extended to 16.0 format. It would have been an issue if you'd had something >16-bit required to be truncated causing data-loss. But it doesn't seem to be so in your case. But yes, the API's indeed take in a 16.0 signed data as input, but which again, you can provide by sign-extending the 10-12 bit data vailable with you.

    The routine definitions are provided in the same SPR101C package that you'd downloaded. The zipped file contains the installer which will install the imglib src code. You'll find the  IMG_jpeg_make_recip_tbl() and  IMG_jpeg_quantize() routine definitons in c5500\imglib\55x_src\JPEG_Qtbal.asm and JPEG_qtal.asm respectively which will explain how the tables are generated and quantization performed.

    This quantization table is defined by the compression application, not by the JPEG standard. A great deal of work goes into creating "good" quantization tables that achieve both good image quality and good compression. Would suggest utilizing the same quantization table as provided in the examples c5500\imglib\examples\Quantize\quantize\test.c. Ditto for the zig-zag table, which is also mentioned in the same file test.c and is nothing but a 64-element 1-D array with integers 0:63 arranged in zig-zag pattern:

    short  zigzag[64]={ 0,  1, 5, 6, 14, 15, 27, 28,
                                      2,  4, 7, 13, 16, 26, 29, 42,
                                      3,  8, 12, 17, 25, 30, 41, 43,
                                      9,  11, 18, 24, 31, 40, 44, 53,
                                     10, 19, 23, 32, 39, 45, 52, 54,
                                     20, 22, 33, 38, 46, 51, 55, 60,
                                     21, 34, 37, 47, 50, 56, 59, 61,
                                     35, 36, 48, 49, 57, 58, 62, 63};

    The usage of JPEG_vlc_init() and IMG_jpeg_vlc() as mentioned by you is in-line with the one in the examples: c5500\imglib\examples\JPEG_VLC\jpeg_vlc_test.c.

    Best Regards.

  • 0 in reply to KRaviS
    Prodigy 30 points

    Hi KRaviS, thanks for the reply that was quite helpful. If I have further questions as I get further into this I will post here. 

  • 0 in reply to Taylor Smith2
    Prodigy 30 points

    Hi,

    I just have a quick question about IMG_jpeg_vlc. For the 'type' argument, the programmer's reference says type 0 is luminance and type 1 is chrominance. However in the provided example jpeg_vlc_test.c a type of 2 is used, apparently for one of the chrominance blocks. 

    So my question is what do the different types actually do and more importantly when should a type of 2 be used for the IMG_jpeg_vlc function? Thank you for reading and for any comments. 

    EDIT: So IMG_jpeg_vlc requires the DC co-efficient from the previously processed block, correct? So is this data point stored in the VLC_status array? Or if not how does IMG_jpeg_vlc get this data?

  • 0 in reply to Taylor Smith2
    TI__Intellectual 1530 points

    Indeed, the type '2' isn't described anyhwhere in the documentation. I am checking with the team experts if there's any visibility to the src code that might explain the same.

    Best Regards.