2020.02.05 04:07 "[Tiff] Inhaling an image all at once in scanline format", by David C. Partridge

2020.02.05 14:10 "Re: [Tiff] Inhaling an image all at once in scanline format", by Bob Friesenhahn

The writer in this instance was a Nikon D4s camera, and tiffinfo reports:

Rows/Strip 3280

So somewhere the code appears to have decided that a strip size of 3280 rows is a bit large... and has set it to one :(

This is due to libtiff's optional strip-chopping feature, which is usually enabled. From the Unixish configure script this is controlled via --disable-strip-chopping. In the 'nmake' nmake.opt, this is controlled via STRIPCHOP_SUPPORT and STRIP_SIZE_DEFAULT:

# Comment out the following lines to disable strip chopping
# (whether or not to convert single-strip uncompressed images to mutiple
# strips of specified size to reduce memory usage). Default strip size
# is 8192 bytes, it can be configured via the STRIP_SIZE_DEFAULT parameter
#
STRIPCHOP_SUPPORT = 1
STRIP_SIZE_DEFAULT = 8192

and looking down further, I see this logic

!IFDEF STRIPCHOP_SUPPORT
EXTRAFLAGS      = -DSTRIPCHOP_DEFAULT=TIFF_STRIPCHOP -DSTRIP_SIZE_DEFAULT=$(STRIP_SIZE_DEFAULT) $(EXTRAFLAGS)
!ENDIF

Since you are doing your own libtiff build, you have complete control over this option.

With the default strip chopping enabled, I see that libtiff reports 17 rows per strip for the image you posted earlier.

If you know that the strip data is not compressed, and given the one large strip, you could arrange to bypass libtiff's buffering and read directly from the file at the offset where the strip starts. However, you might find it easier to just disable the strip chopping and put your OpenMP threads to work on the large memory buffer, assuming that there is actually significant work to do that a single thread can't do better.

In my experience, libtiff itself is rarely the bottleneck to performance since it is very fast. Usually transforming the data to/from the application's own notion of image storage becomes the bottleneck.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt