2016.01.25 18:25 "[Tiff] OpenMP enabled libtiff", by Aaron Boxer

2016.01.26 14:46 "Re: [Tiff] OpenMP enabled libtiff", by Olivier Paquet

2016-01-26 8:45 GMT-05:00 Aaron Boxer <boxerab@gmail.com>:

Sounds like the simplest approach is to allow the user to set a lock callback method,

which, if not null, will protect the global/static variables with a lock of the user's choice.

I'm not sure that would do much without a lot of other work. As has been said, the bulk of CPU work is in the compressors and if I remember correctly they have a significant amount of preallocated state. This needs to be duplicated for each thread to get any useful speedup.

IMO, the cleanest approach is to split read/write and decompression/compression and make the latter thread safe (no global/static data in that part of the code). Then OpenMP or whatever else can be used at a higher level to run the compression work in multiple threads.

It's all a lot of work though because the code is not written with that in mind at all and the compressor can change when you move to a different IFD. As we only needed multithread reading in our project, what we did instead is use several TIFF handles on the same file. This works well enough for reading.

This idea of "blasting" the entire file into RAM, and then reading with libtiff; is this currently possible? Can

libtiff read from a memory buffer?

Yes, you can provide your own IO functions with TIFFClientOpen().

Olivier