2005.09.13 15:58 "Re: [Tiff] read-by-scan-line buffers full strip, part 2", by Joris Van Damme

Mark,

Very confusing, having multiple Marks in a single list... ;-)

Custom decompression by single scanlines using JPEG would not be possible since the JPEG DCT algorithm is applied on spatial blocks.

Yes, of course. But this same issue applies to many 'steps' in a scanline-by-scanline oriented design. You can't do bilinear interpolating without buffering an additional scanline in that step either, and you can't apply filters without buffering an amount of scanlines equal to the filter height, etc.

In general, the scanline-by-scanline approach is always merely the general step, and any step in the pipeline should always be allowed to override it and 'pull' multiple scanlines from previous step at any point. JPEG decompression, in this case, pulls what it needs to deliver a single MCU row I think it is called, and buffers that row, when asked for the first scanline in that row. Subsequent scanline questions are served from the buffer, until it's exausted.

In any case, I understood the original posters quest to be a quest for minimum buffering, maximum streaming.

I don't know what the organization is for color.

Without subsampling, it's the same organization. With subsampling, at least with LibJpeg, maximum streaming is obtained by asking LibJpeg blocks that are eight lines heigh in the plane wich is smallest. For instance, a common smallest block you can ask LibJpeg might consist of 16 lines of Y, 8 lines of Cb, and 8 lines of Cr.

I believe that the DCT is applied to 8x8 blocks in raster order, from top to bottom, left to right. So to get an 8 line decompressed strip from the middle of the raw compressed strip, you'd have to first decompress and discard all compressed data "above" the lines that you wish to get to, just to get to the right place.

I didn't see that the original poster was also after such 'random access', but I may be mistaking. I merely understood him to be after minimum buffering and thus maximum streaming of complete image.

Also, while the JPEG compressed data itself is always stored in that single same 'rotation', an actually different rotation may be defined by the Orientation tag on the IFD level (http://www.awaresystems.be/imaging/tiff/tifftags/orientation.html). So this is always an issue in a maximum streaming design, even if the issue is not imposed by the actual compression.

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html