2020.04.18 12:15 "[Tiff] Updating zlib library", by Vincent Ripoll

2020.04.18 15:16 "Re: [Tiff] Updating zlib library", by Olivier Paquet

Speed is definitely an important factor. I have always noticed that libtiff's own LZW compression is much faster than zlib's deflate.

LZW is not very useful for 16-bit data (our main usage case). In our experience LZW often tends to increase the size of our 16-bit images, instead of compressing them.

Did you enable the predictor? It makes a world of difference in the final compression ratio. We've been using LZW with all kinds of images for a long time and have never noticed increased size.

We still use LZW as a default because of its speed too. I tried zstd recently and surprisingly, could not get much out of it. I think part of the reason was that much of zstd's greatness comes from a large search window which is useless with the "small" 64x64 tiles we use. I don't recall it doing much better than deflate without being ridiculously slow nor doing much faster than LZW without producing larger files. Another explanation might be that the predictor already does most of the compression work and all we really need is decent entropy coding.

As for the original topic, I'm all for supporting alternate deflate implementations as long as the resulting files are compatible. But we need to keep zlib support too as otherwise we force everyone to build new dependencies just to support very common TIFF files.

Olivier