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

Greg Troxel gdt at lexort.com
Thu Dec 19 09:06:04 PST 2024


Even Rouault via gdal-dev <gdal-dev at lists.osgeo.org> 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 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?

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 that
  gdal doesn't need, and one codebase, that's fine and the normal
  approach.  If you mean "there are two live branches of libertiff",
  that sounds like a bad idea.

  It also seems that it could be vendored, but vendoring is not a good
  thing, so if so it should be default-off (and hence fail) if not
  present.

  This doesn't read all tiff, and proj might be reading grid files that
  the people who made them think are compliant, but that the new lib
  won't read.  Thus this is really a proposal to do two things:
    - change the specification of proj  to read only a limited subset of
      tiff
    - change to a simpler implementation that still meets that new
      specification
  That raises the question of whether the grid file spec is bigger than
  proj, and how such a change would be viewed by others, or if this is
  "there is a spec, but to use it with proj it has to meet narrower
  spec-prime".


So modulo the "vendoring bad" issue, the big question on the table is
whether the proj community is ok with narrowing the grid file
specification, and whether there is some larger community behind that.

<dark_humor>Maybe take it to OGC</>




More information about the PROJ mailing list