[gdal-dev] LIBERTIFF / Thread-safe TIFF reader

[Even Rouault]

Hi (cross-posting GDAL and PROJ to save me some typing and because we're 
part of the same conspiration, aren't we?),

so I've authored recently this new "LIBERTIFF" GDAL driver in 
https://github.com/OSGeo/gdal/pull/11507, using 
https://github.com/rouault/libertiff/,  which is a *natively* / 
from-the-ground thread-safe read-only TIFF driver free of libtiff 
(almost) and any legacy baggage. That is you can use a 
GDALDataset/GDALRasterBand coming from it in as many threads as you wish 
without any mutex, and that will use a single file handle underneath, 
and hopefully that won't crash (usual disclaimer of the MIT license 
applies if it does). Should serves users that make the most CPU 
intensive usage of GDAL, either by reading in parallel within the same 
huge dataset, or reading from many files without needing the GDAL block 
cache to trigger and go into your way. The driver is fresh, isn't 
necessarily fully optimized to all use cases, and isn't used by default 
(you need to explicitly select it), but might still be useful. Maybe.

Now for the PROJ community only: my evil idea when coding it was that I 
could ""port"" a very subset of it to remove the libtiff depedency from 
PROJ. As we only uses Deflate compression, at least for grids we host on 
proj-data / the CDN, we could just switch our libtiff dependency to be 
just a libz/libdeflate one (can we just pick up libdeflate to simplify 
things - most libtiff builds nowadays already link to libdeflate - and 
get the x2 boost it gives over zlib. I guess we can). What do you think?

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.
Mood of the day: "Bien entendu, on peut sauter sur sa chaise comme un cabri en disant : les standards ! les standards ! les standards ! Mais ça n’aboutit à rien et ça ne signifie rien." ~ dixit De Gaulle