LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
January 2008
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2008.01.11 07:35 "Re: LibTiff..Reading partial strips", by Joris Van Damme
Bob, Bob Friesenhahn wrote: > > I havent tried it..but the cautionary note that " It is not always > > possible to do so due to decompression constraints" scares me. I > > also read on the archive that "that *strip* *chopping* only works > > for uncompressed IFDs.". How common(or uncommon) is this? When > > would one use compressed IFD's? The tiff's we get can be compressed or > > uncompressed formats and we > > have to support them all. :) > > It is quite likely that other folks here know a lot more about this > than I do so hopefully they will chime in. I don't know what a > compressed IFD might be since and IFD is just a structure. It's a misnomer. The intention there was to refer to image compression as stated in the IFD. Strip-chopping works only on the majority of stripped uncompressed images (i.e. IFDs with Compression tag set to None), it works on no compressed images nor tiles images. > My impression is that libtiff decompresses into a buffer and then uses > part (or all) of that buffer. Strip-chopping works differently. It patches up relevant tags (RowsPerStrip, StripOffsets and StripByteCounts) so as to make it seem there's a lot of small strips rather then a smaller number of huge strips. This can be done due to the predictable offset of uncompressed data. > Some compression algorithms/options > either require decompressing a huge amount of data (e.g. the whole > strip), or else using simultaneous streaming decompression at the same > time that data is consumed by the rest of the library. If libtiff > decompresses in blocks and does not stream (as I suspect) then > sometimes it will need to decompress the entire strip before it can be > used. G4 FAX compression with a strip-per-page is likely a good > example of that. You suspect correctly. LibTiff works largely on with complete buffers, rather then maximum streaming. That makes it unsuitable for large strips/tiles on small machines. A streaming approach is often much more scalable. But it's a completely different design, and it needs to be consistent with design of colour conversion and other application layers. As to the original question, it's often hard to do real 'regional decoding'. It so happens I'm currently working on that exact concept in my JPEG codec. The problem is that many compression schemes, by their very nature, don't support ways to locate the data directly from the pixel indexes. It is often necessary to scan through the data and do at least the very first steps of decoding so as to derive the offsets of the region of interest. In the JPEG scheme, this very first step that needs to be done in as far as RST markers don't come to the rescue, is Huffman decoding. Whilst it cannot be avoided, it's still a lot faster to do Huffman decoding for positioning only (without storage of results that is), compared to a full decompression (Huffman, dequantization, inverse DCT, desubsampling, and possibly colour conversion). But it does require specific support on the part of the decoder. LibTiff subcodecs just aren't designed to do such first-step-decoding-for-positioning-only, so you're out of luck unless you're willing to redesign and rewrite them. Best regards, 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