2005.09.13 17:48 "Re: [Tiff] read-by-scan-line buffers full strip, part 3", by Mark Pilon
Thanks for this -- exactly what I need. and I'm not even playing w/ a really small-memory system; I have several megabytes of memory I can alloc for this -- but not 60+.
>>i.e. using libtiff part-way to get access to the compressed data, but >>perform the decompression in smaller increments than the whole strip.
> Much of my first reply stands. And you're fortunate: the LZW compression > codec isn't very complicated. Neither is your type of image, it's just a
> single plane, single strip, without any subsampling or prediction or > whatever... Still, though, this will keep you occupied for at least a
> few days I guess... ;-)
> Use TIFFGetField to get the offsets and bytecount of the single strip as
> The next part of your code should be thought of as a pulling pipeline > scheme. Whatever the destination of the scanlines is, this pulls the
> scanlines from the LZW decoder as they are needed. This decoder pulls > data from the strip as it needs it, small buffer at a time (say 2K).
> 'Pulling from the strip' may be implemented as calls to the seek and > read proc that are given in TIFFClientOpen, and pointed to in the
> LibTiff TIFF structure. That way, it'll work whatever IO layer is used > added to LibTiff. The LZW decoder, you'll have to build. Use tif_lzw.c
> as a source of documentation. There is also a good deal of detail on the > LZW codec in the TIFF spec (section 13, page 57 and below), but do make
> sure to also peek at tif_lzw.c as this documents also an older pre-6.0 > LZW encoding that is not detailed in the spec and that you may or may
> not need to include.
> Essentially, what you want to do is rework the decoder in tif_lzw.c,
> such that
> - it returns when it has build a single scanline
> - where it currently merely accessed the compressed data in available > memory, it makes a call to a reading helper procedure instead. This
> helper procedure will check whether data is available still in the small > buffer, and if it's not, refill it
> A particular issue to keep in mind is that neither your input buffer nor > your output buffer of your own LZW decoder respects scanline boundaries.
> For your input buffer, this is normal, of course, since you can't > predict how much input you'll need to output a scanline. Thus, simply
> keep the input buffer around, without changing its state from one > scanline-pulling call to the next.
> For your output buffer, this is because the LZW compression doesn't
> 'stop and restart' at scanline boundaries. It may very well be that a > particular LZW compressed code resolves to five uncompressed bytes,
> where your scanline has only 2 bytes left, and the next three bytes are > the first three of the next scanline. This is a nasty issue, that is
> resolved on tif_lzw with 'restart logic' with the aid of such state > variables as 'dec_restart' and related.
> Good luck!
Joris Van Damme
Download your free TIFF tag viewer for windows here:
Konica Minolta Printing Solutions U.S.A.
P.O. Box 37
325 Dawson County Road 227
Fallon, MT. 59326-0037