Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace libtiff by vendored libertiff + external libdeflate #4358

Open
rouault opened this issue Dec 20, 2024 · 4 comments
Open

Replace libtiff by vendored libertiff + external libdeflate #4358

rouault opened this issue Dec 20, 2024 · 4 comments

Comments

@rouault
Copy link
Member

rouault commented Dec 20, 2024

Cf thread at https://lists.osgeo.org/pipermail/proj/2024-December/011674.html

@rouault
Copy link
Member Author

rouault commented Jan 17, 2025

Not sure I'll follow up on this as there have been discussions about potentially using LERC. If we want to handle several codecs, libtiff is probably still the better choice, as from PROJ's point of view it is just one single find_package() whereas if we need to handle several codecs, that will be a find_package() per codec.

@hobu
Copy link
Contributor

hobu commented Jan 20, 2025

that will be a find_package() per codec.

LERC would not be a find_package. It would be vendored.

If geodetic grids were actually defined as definite-precision content, they wouldn't be delivered as floating points. I think it should be reasonable to provide LERC-compressed content to a stated MAX_Z_ERROR and garner the significant benefits from the LERC approach for floating point files. Otherwise, can the other mantissa-heads in the community tell us why we couldn't take this approach? 😄

The benefits that would be accumulated over the entire system multiplied by the substantial user base of PROJ – CDN usage, people downloading individual bytes, replicated storage on individual systems – would be a lot. LERC would mean smaller files that decompress faster. Can someone make the cogent case for bigger codecs that compress slower?

@rouault
Copy link
Member Author

rouault commented Jan 20, 2025

to a stated MAX_Z_ERROR

One difficulty is to find that value. For ASCII delivered grids, pending the pain of going back to the original sources, we can see it from the number of decimals in the file. For binary grids, that would be a guess.

@rouault
Copy link
Member Author

rouault commented Jan 20, 2025

LERC would not be a find_package. It would be vendored.

We'd still need a find_package() even if vendored (which I'm moderately enthusiast about, although not strongly opposed), because packagers won't accept using a vendored LERC when there's an external one available

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants