2012.09.06 15:30 "[Tiff] Managing the buffer", by

2012.09.07 11:25 "Re: [Tiff] Managing the buffer", by John

Hi again Robert,

On 7 September 2012 10:21, <Robert.Atwood@diamond.ac.uk> wrote:

But as an aside.. Is it any faster to use TIFFWriteEncodedStrip and manage the strips? My predecessor did it that way but I don't agree. I understand that TIFFLib is usually clever enough to manage strips in memory as the scanlines are added, at least it seems to work very well using exactly the sequence you describe in my other programs using TIFFlib. I expect it is not any slower or faster, just the code is more complicated managing each strip. I haven't tried a comparison though.

You're right (in my experience). I imagine writing a scanline at a time will cause an extra copy operation as the strip buffer is filled, but that should be an almost invisible overhead. Here's tiff scanline write vs. calling unix write() repeatedly:

$ time vips black wtc.tif 20000 20000
real    0m4.926s
user    0m0.712s
sys     0m0.800s
$ time vips black wtc.v 20000 20000
real    0m4.705s
user    0m0.400s
sys     0m0.812s

So calling write() directly is about 0.3s less CPU time for a 400MB image on my terrible old desktop PC.

I'm sorry, but you misunderstand. I wish to ensure that TIFFOpen is not allocating its own buffer repeatedly. I was not asking about how to manage my program's image array.

Ah yes, sorry you're right. That buffer isn't going to be large though, if you're that short of memory you are in terrible trouble anyway. Pre-allocating the tiff write buffer will only get you a very marginal increase in your ability to buffer images being queued for transfer to disc at the cost of some annoying hackery. I wonder if it's worth the trouble.

Would it be easier to add more memory or to boost the disc write speed or somehow throttle image capture? I guess there's some reason this isn't possible.

John