Boost logo

Boost :

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2008-04-27 14:09:51

Christian Henning wrote:
> Hi there, over the past few months I have been working on a new
> version of gil's io extension.

Hi Christian,

I'm not currently using gil, though now it has been released in 1.35 I
will probably convert some of my existing code to use it. However, I
have used the C++ interfaces to libjpeg in a couple of other libraries
- ImageMagick and DirectFB - and I thought I'd have a look at your code
to see how it compares. My application involves decompressing large
JPEGS from digital cameras which are displayed on a pan/zoon user
interface, which needs to be responsive despite running on somewhat
slow hardware. Here are some comments, some of which are feature
requests and others are really just questions for someone who might
know a bit more about libjpeg than me:

DCT type: libjpeg lets you select one of three different DCT
implementations via cinfo.dct_method: integer, normal floating point
and a faster floating point algorithm that is less accurate. I have
found this faster algorithm to be visually indistinguishable and makes
decoding about 1/4 to 1/3 faster overall, and I now use it by default.
It would be good to have some way to enable this.

Scaled decoding: libjpeg has a mode in which it will scale the image
down to 1/2, 1/4 or 1/8 of its native size while decoding (see
cinfo.scale_num and cinfo.scale_denom). This is much less expensive
than doing the full decode and then scaling. It would be good to have
some way of using this.

Partial image decoding: I see that you have some code to extract a
portion of an image, but that it does this by reading and discarding
the unwanted parts. You should certainly be able to avoid doing this
for the parts after the wanted portion, as you note in the comments. I
have been trying to work out how to avoid doing this work for the
earlier parts of the image. It should be possible to skip the
expensive DCT for these parts as libjpeg has a mode in which it will
perform only Huffman decoding and returns DCT coefficients
(jpeg_read_coefficients). However, I've not found a way to ask it to
do the DCT (and subsequent steps) for the wanted subset of those
values. I believe that it's also possible to skip lines in the JPEG
data (i.e. not even doing the Huffman decoding) by looking for an FFDA
marker, but I don't see anything in libjpeg to support that.

MMX/SSE: It should be possible to get a significant speedup for the DCT
using MMX or SSE instructions on x86 machines. Versions of libjpeg
that do this have existed, but it seems that they were buggy and not
well maintained; Debian stopped shipping theirs.

Byte packing: I recall that the output from libjpeg is a packed
sequence of red/green/blue values, which you typically then unpack to
32 bits per pixel. Wouldn't it be nice if libjpeg would save it in
this format?

Rotation: It's possible to rotate a jpeg image inexpensively by
fiddling with the DCT coefficients. But I find the same situation as
for partial image decoding: having asked libjpeg to decode to DCT
coefficients, and then having fiddled with them to effect the rotation,
I can see no function that will complete the decoding to pixel values.
Maybe I'm missing something.

In-memory jpegs: If I get my jpeg data from somewhere other than a
file, e.g. from some sort of database, or from an in-memory cache or an
mmap()ed file, do you have a way to use it?



Boost list run by bdawes at, gregod at, cpdaniel at, john at