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

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

Thanks again for all the comments. Just an update, I took out the "TIFFWriteScanLine" call while leaving the OpenCV pixel access, and did not see the RAM increase. I did instrument a call to GlobalMemoryStatusEx to watch the changes and for my purposes they reflected what I was also seeing in Windows Task manager.

I then built up the same sized TIFF file only using TIFFWriteTile instead, and this wrote the entire file with no appreciable change in memory. The file in Windows Explorer still read 0kb until I called TIFFClose(), but TIFFClose() completed almost instantly (vs. many seconds in the scan-line version that also showed Ram usage.)

I know I'm better off using Tiled anyway for these large images!

________________________________
From: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Sent: Wednesday, April 24, 2019 11:31 AM
To: Paul Hemmer
Cc: Tiff List
Subject: Re: [Tiff] TIFFWriteScanLine - buffers to RAM before flushing to disc?

On Wed, 24 Apr 2019, Paul Hemmer wrote:

>
>> 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.

I am thinking that you should investigate how OpenCV works. This is
appears to be powerful C++ code which provides a wrapper for the
pixels. Perhaps it is actually OpenCV which is allocating memory
based on your access request since the underlying pixel store might
not be compatible with simple linear byte access and so it needs to
allocate temporary memory.

Libtiff was primarily written a long time ago when computers provided
very little memory (most computers at the time did not provide more
than 640k of RAM) so its implementation tries to be memory-efficient,
although it was implemented on SGI workstations which offered much
more memory than a typical PC.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.simplesystems.org%2Fusers%2Fbfriesen%2F&amp;data=02%7C01%7C%7C7c7f1a0ff7894abe84d108d6c8c9f2d4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917167023437825&amp;sdata=FQS%2F43T%2F0i4abdvtGU8uYdyj%2BFdrqhaPhOi1%2BmITu08%3D&amp;reserved=0

GraphicsMagick Maintainer,    https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.GraphicsMagick.org%2F&amp;data=02%7C01%7C%7C7c7f1a0ff7894abe84d108d6c8c9f2d4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917167023437825&amp;sdata=JU%2B0148TeOjUtuXrrO%2F7W36uoBQk0ojJmtkyK8%2Bglgs%3D&amp;reserved=0

Public Key,     https://apc01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.simplesystems.org%2Fusers%2Fbfriesen%2Fpublic-key.txt&amp;data=02%7C01%7C%7C7c7f1a0ff7894abe84d108d6c8c9f2d4%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636917167023447836&amp;sdata=34gcz4kbctjeZFGDAQZBVi7i%2F%2FmvsxI%2Bbj9ZPaszEeo%3D&amp;reserved=0