AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2016.01.25 18:25 "[Tiff] OpenMP enabled libtiff", by Aaron Boxer
2016.01.26 09:12 "Re: [Tiff] OpenMP enabled libtiff", by John
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?

Cheers,

Aaron

On Tue, Jan 26, 2016 at 4:12 AM, <jcupitt@gmail.com> wrote:

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