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

Slightly confused here (yes that's not hard).

The tiff_conf.h file which I copied from tiffconf.vc.h has unconditional

#define STRIPCHOP_DEFAULT TIFF_STRIPCHOP 

I can't see how anything in Makefile.vc or nmake.opt could override that - should I comment that line out to disable the chopping?

You said:

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

With it enabled I get ONE row per strip:

00000091 2020/02/05 16:02:20.234 033944 0000a798               >TIFF Scan
Line Size 14784
00000092 2020/02/05 16:02:20.240 033944 0000a798               >TIFF spp=3,
bpp=8, w=4928, h=3280
00000093 2020/02/05 16:02:20.246 033944 0000a798               >Allocating
buffer of 48491520 bytes
00000094 2020/02/05 16:02:20.271 033944 0000a798               >Number of
strips is 3280
00000095 2020/02/05 16:02:20.303 033944 0000a798               >limit - curr
= 1

Have you perhaps specified a custom value for STRIP_SIZE_DEFAULT on your system of around 256kB as that's the only way I can see that allows 17 rows to be inhaled as one strip. Compiling with /DSTRIP_SIZE_DEFAULT=262144, I got:

00000091 2020/02/05 16:47:23.946 049660 0000ce70               >TIFF Scan
Line Size 14784
00000092 2020/02/05 16:47:23.953 049660 0000ce70               >TIFF spp=3,
bpp=8, w=4928, h=3280
00000093 2020/02/05 16:47:23.959 049660 0000ce70               >Allocating
buffer of 48491520 bytes
00000094 2020/02/05 16:47:23.990 049660 0000ce70               >Number of
strips is 193
00000095 2020/02/05 16:47:24.013 049660 0000ce70               >limit - curr
= 1

Which shows a significant speed up (0.013 seconds versus 0.032 seconds)

When I disabled the chopping by commenting the line in tiffconf.h, I got this:

00000091 2020/02/05 15:53:57.026 009388 0000b75c               >TIFF Scan
Line Size 14784
00000092 2020/02/05 15:53:57.031 009388 0000b75c               >TIFF spp=3,
bpp=8, w=4928, h=3280
00000093 2020/02/05 15:53:57.037 009388 0000b75c               >Allocating
buffer of 48491520 bytes
00000094 2020/02/05 15:53:57.064 009388 0000b75c               >Number of
strips is 1
00000095 2020/02/05 15:53:57.124 009388 0000b75c               >limit - curr
= 1

Interestingly this was slower than either of the above by a noticeable amount (about 1.9 times slower than the first case and 4.6 times slower than the second case above)!

So I have left strip chopping enabled and have defined STRIP_SIZE_DEFAULT to 256kB as this seems to work best!

Finally if an image has been created with one row per strip, is there a good way to over-ride that programmatically in a safe manner (no I don't mean tinkering with tif->tif_dir) so that it will read as much as STRIP_SIZE_DEFAULT bytes instead of the single row?

PS I see that no-one ever adopted my proposal to change TIFF_IO_MAX in tif_unix.c to be 16777216UL (16MB) The current value of 2GB seems a tad silly.

David