Non-interleaved JPEG decompression

[ard_o]

Hi,

We are using the IPP IJL sample code for decompressing jpeg images. For most images we get an amazing decompression time (2ms), but for some images the decompression takes much longer (100ms).

I have looked at the code of decode_buffer.c and for these images, the SetDecodeFastPath function apparently can not select an optimized MCU decompression function, because jprops->jinterleaveType is set to 1. I assume this means that the jpeg image is non-interleaved at the MCU level?

Is there a way to speed up the decompression of these non-interleaved jpeg images with the IPP?

Regards,
Ard Oerlemans

[Vladimir_Dudnik]

Hello Ard,

you probably talk about performance difference in decoding between baseline JPEG files and progressive JPEG files. The progressive JPEG files generally requires more time to process because they are consist from several scans whereas baseline JPEG file usually contain only one scan.

By the way, I recommend you to take a look on other JPEG samples we have. You can find in package three different JPEG codec implementations:
1. IJL, we only provide bug fixes for this codec, and have no plan to extend its functionality.

2. IJG, it is well known libjpeg codec, we only substituted time critical functions with IPP equivalents and so can provide visible performance improvement while staying in old, popularand stable interface

3. jpegcodec, which is part of JPEGView sample. The interface and design of this codec was developed with using experience we got from supporting IJL library for several years. It is attemt to eliminate IJL design limitation anddevelop simple but powerful and flexible interface and design which allow to reach highest perfomance for both decoding and encoding. Additional features in this codec is support for lossless JPEG format, OpenMP threading on codec level, cross-architecture implementation which allow us to deliver this codec on IA32, EM64T, Itanium, Xscale systems for both Windows and Linux.

PS,
jpegcodec (from JPEGView), uses threading to speedup decoding, so it will provide you better speed for progressive images on dual-core systems.

Regards,
Vladimir

[ard_o]

Hi Vladimir,

Thank you for your advice! We have compiled the jpeg codec in the JpegView sample and the images decompress much faster now. However, there some errors in the decompressed image. The order of the decompressed blocks seems to be incorrect.. It is hard to explain, but maybe you can try the JpegView sample with the image that I have attached?

By the way, it is not a progressive jpeg image, but it does have multiple scans for the Y, U and V data.

Regards,
Ard Oerlemans

[Vladimir_Dudnik]

Hi Ard,

thanks for reporting this issue, you are right, there was a mistake in decoder.cpp file. Please replace your decoder.cpp file with this one from attach.

Regards,
Vladimir