AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2016.01.25 18:25 "[Tiff] OpenMP enabled libtiff", by Aaron Boxer
2016.01.25 19:05 "Re: [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 09:36 "Re: [Tiff] OpenMP enabled libtiff", by Mat Maher
[...]

2016.01.26 09:12 "Re: [Tiff] OpenMP enabled libtiff", by John

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.

John