AWare Systems, Home TIFF and LibTiff Mail List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2016

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date


The TIFF Mailing List Homepage
Archive maintained by AWare Systems

New Datamatrix section

Valid HTML 4.01!


2016.01.25 18:25 "[Tiff] OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 09:12 "Re: [Tiff] OpenMP enabled libtiff", by
2016.01.26 13:45 "Re: [Tiff] OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 14:46 "Re: [Tiff] OpenMP enabled libtiff", by Olivier Paquet

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, <> wrote:

On 25 January 2016 at 18:25, Aaron Boxer <> 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.