AWARE [SYSTEMS]
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

Contact

The TIFF Mailing List Homepage
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



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
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

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