2017.11.20 17:04 "[Tiff] TIFF tag and compression registration", by Kemp Watson

2018.01.15 20:23 "Re: [Tiff] Strategies for multi-core speedups", by Bob Friesenhahn

I tried to do this myself using libtiff -- for the common case of needing to read an entire image, my aim was read all the raw strips (TIFFReadRawStrip, serially), then dole them out to different threads to decompress in parallel (and when writing, compress in parallel, then TIFFWriteRawStrip each one serially). If libIlmImf is any indication, doing this on our typical 12 or 16 core machines ought to speed up TIFF I/O by an order of magnitude, easily.

An order of magnitude is unlikely. 2-4x is possible. The problem is that a computer has limited memory bandwidth. With enough threading, the bottleneck moves from CPU to memory bandwidth and CPUs offer 2-4x memory-path parallelism (more on expensive server CPUs and less on desktop CPUs). EXR uses floating point which requires a lot more CPU so there is more to be gained with many cores.

It is likely that even with sequential single-threaded I/O through libtiff that other parts of your app will benefit by threading. I see up to 4x benefit when reading SMTPE DPX format sequentially (one thread doing I/O at a time), but then allowing each thread to continue processing the data in a multi-threaded fashion.

But my plan was thwarted because it sure seems that the API for the codecs is inherently stateful and non-reentrant.

This would be very useful to fix.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/