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? Regards, Phil.