2019.04.23 18:55 "[Tiff] TIFFWriteScanLine - buffers to RAM before flushing to disc?", by Paul Hemmer

2019.04.24 13:58 "Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to disc?", by Paul Hemmer

Why do you allocate a buffer using _TIFFmalloc() and use memcpy() if you could just pass the address (myOpenCV.data + myOpenCV.step * y) as 'buf' to TIFFWriteScanline()?

Good question. I inherited this code. No need for the intermediate buffer.

What strip size is being used for your TIFF? Are you enabling any TIFF predictors which might require re-organizing the data prior to it being written?

The size depends on the image data, and I calculate it using TIFFScanlineSize() after setting the tags for width/length/bps etc. No predictors.

You said that compression is not being used. If compression is enabled, then buffering of the compressed data may be required, and some compressors might suffer from arbitrary limits.

Understood

How are you observing/measuring this memory growth?

Windows Task Manager

In my limited experience, Microsoft Windows is not very good at reporting the properties of files which are currently being written.

Mine as well. Just pointing it out in case it means something in this context.

It only (optionally) uses memory mapping when reading from a file. The reason for this is that reading a TIFF file may require a lot of random access and the memory-mapping makes that random access appear almost "free". However, simply memory mapping a file does not bring any data into memory. Accessing memory corresponding to a portion of the mapped file which has not been accessed yet causes the kernel to trap (stopping the program), a kernel driver reads memory pages (e.g. 4k at a time) from the file, and then the program continues running.

So the "m" option in TIFFOpen should make no difference?

Thanks Bob!