LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
Previous by Thread
Next by Thread
Previous by Date
Next by Date
The TIFF Mailing List Homepage
Archive maintained by AWare Systems
2016.01.26 13:45 "Re: [Tiff] OpenMP enabled libtiff", by Aaron Boxer
Thanks, everyone. It will take me a little time to fully grok all of this information.
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 don't think the user could use OpenMP for this, since OpenMP is a fork/join architecture. So,
it would also be nice to provide a light-weight cross platform lock library, wrapping pthreads / win32 API.
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?
On Tue, Jan 26, 2016 at 4:12 AM, <firstname.lastname@example.org> wrote:
On 25 January 2016 at 18:25, Aaron Boxer <email@example.com> wrote:
Is anyone interested in having OpenMP support in libtiff?
Is this feasible? I am planning on adding this feature for another project I am working on, so I am trying to gauge interest.
I think I would not add openmp support directly. Scattered reads and writes are too difficult to support efficiently with the current structure.
Instead, as Bob said, I think I would split the library in two. Have a very low level interface which just reads or writes compressed strips or tiles, essentially just a thin wrapper
around the read() and write() system calls, and then have a higher layer to do compression, decompression, packing and unpacking. The low-level read/write layer should be
single-threaded, the higher layer should be threadsafe.
Now you can serialize read/write to match the disc structure, but the application can use SMP in whatever framework it prefers to accelerate the CPU-intensive parts.
Uncompressed tiffs already work rather like this: if you call TIFFReadEncodedStrip() on an uncompressed image, it's just a few function calls around read() --- it's very easy to saturate
any disc system. We just need to move the decompress stage outside the serial code path.