LibTiff Mailing List

Hello,

TIFFWriteScanline always allocates memory for a complete strip.  When
writing large TIFF files in a single strip, this can lead to memory
problems quickly.

I am aware that the whole point of dividing the image data into strips
is to be able to read and write in manageable chunks of memory.
However, some applications (e.g. many fax applications) seem to have
problems with TIFF images with more than a single strip.

I am aware of libtiff's strip-based API, which is capable of writing
strip data incrementally with TIFFWriteRawStrip.  Unfortunately, it
expects already compressed data and is therefore not making use of the
built-in compressors.  TIFFWriteEncodedStrip on the other hand
compresses data prior to writing it, but it doesn't work incrementally,
i.e. it expects the full data of each strip.

I assume that this is because libtiff's implementation of the
compression algorithms cannot operate on streamed data?  I think it'd
make sense to support this, as the data which needs to be buffered by
most compression schemes should be substantially less (and never more)
than the smallest strip size feasible for each algorithm.

What are you general thoughts on changing the compression
implementations in this regard?  Do you think it is doable or am I
overlooking something?  Is somebody already working on it or planning
to?

     Lars

P.S.: A bit of context: We ran into these issues with ghostscript, after
porting all of its tiff output devices to use libtiff instead of writing
output files manually (using ghostscript's streamable implementation of
some of the compression schemes).  In order to provide backwards
compatibility, the output files are written in a single strip.


AWARE [SYSTEMS]		Imaging expertise for the Delphi developer
		TIFF and LibTiff Mailing List Archive
	LibTiff Mailing List TIFF and LibTiff Mailing List Archive December 2009 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 2009.12.07 16:47 "Full strip allocation in TIFFWriteScanline", by Lars Uebernickel 2009.12.07 18:01 "Re: Full strip allocation in TIFFWriteScanline", by Frank Warmerdam 2009.12.07 16:47 "Full strip allocation in TIFFWriteScanline", by Lars Uebernickel Hello, TIFFWriteScanline always allocates memory for a complete strip. When writing large TIFF files in a single strip, this can lead to memory problems quickly. I am aware that the whole point of dividing the image data into strips is to be able to read and write in manageable chunks of memory. However, some applications (e.g. many fax applications) seem to have problems with TIFF images with more than a single strip. I am aware of libtiff's strip-based API, which is capable of writing strip data incrementally with TIFFWriteRawStrip. Unfortunately, it expects already compressed data and is therefore not making use of the built-in compressors. TIFFWriteEncodedStrip on the other hand compresses data prior to writing it, but it doesn't work incrementally, i.e. it expects the full data of each strip. I assume that this is because libtiff's implementation of the compression algorithms cannot operate on streamed data? I think it'd make sense to support this, as the data which needs to be buffered by most compression schemes should be substantially less (and never more) than the smallest strip size feasible for each algorithm. What are you general thoughts on changing the compression implementations in this regard? Do you think it is doable or am I overlooking something? Is somebody already working on it or planning to? Lars P.S.: A bit of context: We ran into these issues with ghostscript, after porting all of its tiff output devices to use libtiff instead of writing output files manually (using ghostscript's streamable implementation of some of the compression schemes). In order to provide backwards compatibility, the output files are written in a single strip.

LibTiff Mailing List

Thread

2009.12.07 16:47 "Full strip allocation in TIFFWriteScanline", by Lars Uebernickel