Compression - Re: Decoding progressive JPEG with low memory consumption

Author

Re: Decoding progressive JPEG with low memory consumption

Jeppe

2006-10-30, 6:55 pm

Hmm .. seems comp.compression is a more suitable group for my question.
xposting here.

/Jeppe

Jeppe wrote:
> Hi
>
> I need to decode JPEG images on an embedded platform with limited RAM
> available. The input JPEG images can are usually some mega pixels large
> and I have to decode these only a small screen canvas (e.g. 100x100
> pixels). For "normal" baseline JPEGs, I use libjpeg (from the
> independent JPEG group) to decode one scan line at the time and resample
> this to fit the screen canvas. This works great -- and I can live with
> the memory consumption.
>
> My problem arise when I start working with progressive JPEGs. Because
> the DCT coefficients are hufmann encoded, libjpeg allocates a full-size
> DCT buffer to decode the progressive image. I do not have this much
> memory available, hence my only option seems to be decoding the image
> from scratch for each pass/scan. I had a look at an old post from this
> group
> (http://groups.google.dk/group/comp....d4c11755e656346)
> where Thaddeus Beier posted a profiling of the internals of libjpeg
> while decoding:
> "
> Here is the output of gprof run on djpeg, after decompressing
> 100 pictures
>
> Each sample counts as 0.01 seconds.
> % cumulative self
> time seconds seconds name
> 39.09 1.38 1.38 jpeg_idct_islow
> 37.68 2.71 1.33 ycc_rgb_convert
> 10.20 3.07 0.36 h2v2_fancy_upsample
> 8.22 3.36 0.29 decode_mcu
> 2.55 3.45 0.09 jpeg_fill_bit_buffer
> 1.42 3.50 0.05 decompress_onepass
> 0.28 3.51 0.01 jpeg_huff_decode
> 0.28 3.52 0.01 main
> "
>
> The huffman decoding seems to be computationally very cheap compared the
> other operations, hence the decoding-from-scratch-for-each-scan approach
> could be OK.
>
> I find it difficult to think that I am the first with this problem --
> but I have not been able to find much about this in news group archives
> or on the web. Does someone know of an already implemented and freely
> available solution to my problem, e.g. a patch to libjpeg's handling of
> progressive JPEGs?
>
> Thanks
> /Jeppe

Jack Berlin

2006-10-30, 6:55 pm

Hello Jeppe,

Good news and bad news....

Bad news is that the IJG code really screwed up their architectural
implementation of progressive JPEG.

As I said in this group June 15 of this year, somewhat 'tongue in ch

':

"Let us know if we can show you how to reduce the memory use in the IJG
progressive JPEG decoder. Seriously, it killed the format. Our decoder
uses many times less memory..."

Progressive JPEG held such promise, now only delivered by JPEG 2000, just
because of the poor design becoming the defacto standard. In this case
people got exactly what they paid for (since it is free?). If you look back
in newsgroups you will see similar disgust dating back to 1996.

Good news is Pegasus' implementation of p-jpeg uses many, many times less
memory, and is available as a commercially supported, portable C library.
We use less memory for baseline JPEG as well, and our code is significantly
faster.

You can download and test our library from our website. Free to try, but
not free to use however.
http://www.pegasusimaging.com/picphotofeatures.htm

Hope this helps,
jack
--
The JPEG Wizard free web compression testing: http://www.jpegwizard.com/
http://www.pegasusimaging.com/ - Pegasus - The BETTER JPEG People!
--

"Jeppe" <nej@nej.dk> wrote in message news:P7Y%g.3$vS2.0@news.get2net.dk...[color=darkred]
> Hmm .. seems comp.compression is a more suitable group for my question.
> xposting here.
>
> /Jeppe
>
> Jeppe wrote:

Sponsored Links