Le Sun, Mar 05, 2023 at 12:05:36PM +0100, Even Rouault a écrit : > Hi, > > > > currently some interesting features (for example jxl compression in > > tiff) requires one to build against internal tiff/geotiff - after > > looking at the code, from my understanding this is because the gtiff > > driver reaches to internal tiff functions not present in the public API, > > which (to me) is a valid reason. Afaict the bundled copies dont diverge > > from upstream, since even maintains both sides in parallel. > The JXL codec is the only functionality that currently requires using the > internal copy of libtiff, not because there's anything special in it, but > because TIFF codecs require access to private headers of libtiff. The reason > for the JXL codec being in GDAL only is that it makes it easier for early > adopters to assess adequacy of this codec for GDAL purposes without > requiring first to have it accepted in libtiff (there was a similar > situation a few years ago with the LERC codec). The medium/long term plan is > to migrate it to libtiff, presumably once libjxl has reached 1.0 and API > stability.
so that means optional support of libjxl directly inside a future libtiff version, and thus gdal would gain 'jxl-in-tiff' support by linking against a jxl-enabled libtiff. Makes sense. > > - would it be possible to allow building against external > > libtiff/libgeotiff _sources_ ? this way i'd still be able to apply > > fixes to one place, but i also suppose that'll require a tight version > > dependency on those.. > > Everything is possible, but I don't think we want to complicate the build > system with that extra possibility. Agreed, that was my fear. > So yes packages that follow rules of not using vendored libraries can't use > the JXL codec for now. Hopefully that's just a transient state. Makes sense - thanks for the explanation ! _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
