Re: LIBERTIFF / Thread-safe TIFF reader
Even Rouault via gdal-dev <[email protected]> Thu, 19 Dec 2024 18:13:59 +0100
| Newsgroups | gmane.comp.gis.gdal.devel,gmane.comp.gis.proj-4.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============6261580425029826072==
Content-Type: multipart/alternative;
boundary="------------ubITeUDuf5j1CrKNq2eyjuvX"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------ubITeUDuf5j1CrKNq2eyjuvX
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
> 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.
No, vendor libertiff.hpp into PROJ as already done in GDAL. If someone
wants to package libertiff as a standalone package, fine for them, but
we're probably not at that point of success that we need to do it. I'm
happy to resync libertiff_upstream/GDAL/PROJ libertiff.hpp when needed.
Given its limited scope, it is probably close to be feature complete.
>
> 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.
Yep, that's the main restriction. So this is a question for the
community: does anyone use PROJ TIFF grids with a codec that is not
uncompressed or deflate ?
> 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".
Yes the deal would be: you can use any valid (Geo)TIFF/(Geo)BigTIFF
big/little endian ordered, provided you limit yourself to uncompressed
or deflate.
> <dark_humor>Maybe take it to OGC</>
Fortunately, there's nothing geo in this!
--
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
--------------ubITeUDuf5j1CrKNq2eyjuvX
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<span style="white-space: pre-wrap">
</span>
<blockquote type="cite" cite="mid:[email protected]">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
No, vendor libertiff.hpp into PROJ as already done in GDAL. If
someone wants to package libertiff as a standalone package, fine for
them, but we're probably not at that point of success that we need
to do it. I'm happy to resync libertiff_upstream/GDAL/PROJ
libertiff.hpp when needed. Given its limited scope, it is probably
close to be feature complete.<br>
<blockquote type="cite" cite="mid:[email protected]">
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
Yep, that's the main restriction. So this is a question for the
community: does anyone use PROJ TIFF grids with a codec that is not
uncompressed or deflate ?<br>
<blockquote type="cite" cite="mid:[email protected]">
<pre class="moz-quote-pre" wrap=""> 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".</pre>
</blockquote>
Yes the deal would be: you can use any valid (Geo)TIFF/(Geo)BigTIFF
big/little endian ordered, provided you limit yourself to
uncompressed or deflate.<br>
<blockquote type="cite" cite="mid:[email protected]">
<pre class="moz-quote-pre" wrap="">
<dark_humor>Maybe take it to OGC</></pre>
</blockquote>
Fortunately, there's nothing geo in this!<span
style="white-space: pre-wrap">
</span>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
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</pre>
</body>
</html>
--------------ubITeUDuf5j1CrKNq2eyjuvX--
--===============6261580425029826072==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--===============6261580425029826072==--