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

2024-12-19 Thread Javier Jimenez Shaw via gdal-dev
We are making our own grid files (for strange cases with nonsense licenses), but fortunately they are with deflate (thanks Alex). We link only with libz, not with deflate (also for gdal). But that should we easy to change if needed. On Thu, 19 Dec 2024, 18:16 Thomas Knudsen via gdal-dev, < gdal-d

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

2024-12-19 Thread Thomas Knudsen via gdal-dev
I think that sounds awesome wrt. PROJ dependency reduction, since the informal interpretation of TIFF as "Thousands of Incompatible File Formats" doesn't really apply to PROJ's use case ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osge

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

2024-12-19 Thread Even Rouault via gdal-dev
Without thinking too much: You say '"port"' (in quotes), and I don't follow. The new implementation is a library, even if it does not have a .so. So it seems obvious that it would become a dependency of a particular gdal driver and, of proj. If that means adding a feature for proj

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

2024-12-19 Thread Greg Troxel via gdal-dev
Even Rouault via gdal-dev writes: > 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 swi

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

2024-12-19 Thread Even Rouault via gdal-dev
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* / fr