TIFF and LibTiff Mail List Archive


2012.09.06 15:30 "[Tiff] Managing the buffer", by
2012.09.06 17:10 "Re: [Tiff] Managing the buffer", by John
2012.09.07 09:21 "Re: [Tiff] Managing the buffer", by
2012.09.07 09:57 "Re: [Tiff] Managing the buffer", by Joris Van Damme
2012.09.07 10:26 "RE: [Tiff] Managing the buffer", by
2012.09.07 11:01 "Re: [Tiff] Managing the buffer", by Joris Van Damme
2012.09.07 13:12 "RE: [Tiff] Managing the buffer", by
2012.09.07 13:39 "Re: [Tiff] Managing the buffer", by Joris Van Damme
2012.09.07 13:45 "RE: [Tiff] Managing the buffer", by
2012.09.07 14:16 "Re: [Tiff] Managing the buffer", by Bob Friesenhahn
2012.09.07 14:31 "Re: [Tiff] Managing the buffer", by
2012.09.07 15:52 "Re: [Tiff] Managing the buffer", by Bob Friesenhahn
2012.09.07 11:25 "Re: [Tiff] Managing the buffer", by John

2012.09.07 09:21 "Re: [Tiff] Managing the buffer", by

Hi, John:

On 6 September 2012 16:30, <> wrote:

I would like (for complicated reasons) to write a large number of TIFF images that are the same size. I wish to have a pre-allocated buffer and not allocate a new buffer each time I want to write an image.

The simplest solution is probably something like this:

---- update the memory buffer p with the pixels you want to write
---- tif = TIFFOpen (filename, "w")
---- TIFFSetField (tif, TIFFTAG_IMAGEWIDTH, width);
---- etc. for the rest of the header
---- for y = 0; y < height; y++:
-------- TIFFWriteScanline (tif, p + y * sizeof (line), y, 0 );
---- TIFFClose (tif)

Something like that will have no trouble at all saturating your disc write.

No problem there, in fact that IS the problem, disk write is saturated so the incoming buffer gets large.

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 could also use a higher-level library to do the writing for you, but of course that adds another dependency which you might want to avoid. For example, vips (my library) would hide some of the detail for you.

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.

The reason is that other processes (which I did not write) are grabbing memory, they may be able to know if the system has no memory and do something-or-other (like throttling the acquisition or deliberately dropping images). (basically.. it's the queue of incoming images) However, sometimes it happens that at one moment when TIFFOpen is called, there isn't enough available memory for the buffer. Thus I get a problem. Pre-allocating the buffer and passing it to TIFFWriteBufferSetup seems like the solution, then my process has dibs on the memory. I just don't quite get it from reading the man pages and so forth, what order to do it in.

At which point may I call TIFWriteBufferSetup and pass in a pre-allocated buffer so that a buffer will not be allocated again during TIFFOpen? Is it ensured that the buffer is not freed when TIFFClose is called?


This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom