<div dir="ltr">Just adding my two cents...<div><div><br></div><div>I highly support adding the signed int8 datatype - this would probably lead to downstream projects that support different raster datatypes to eventually fully support int8 rasters as a first class citizen. </div><div>Yes - downstream projects would need to invest some time adapting but the result would be a PROPER support for int8 rasters. </div><div> (I would imagine that searching the code for some key search words would yield most places that need fixing), <br></div><div>Nobody is forced to upgrade a major version and sometimes a downstream effort is required to support the evolution of the upstream project.</div><div><br></div><div>I was a maintainer of an app that used signed int8 data vastly and wanted to incorporate save/load/calc rasters using GDAL. </div><div>After spending countless hours of trying to use the signed byte flag properly in every case I ended up changing the logic of the application to use only unsigned byte rasters since there were too many cases where the signed byte flag was not honored or caused weird outputs (for instance, I think that QGIS didn't fully support int8 rasters properly).</div><div><br></div><div>Even, Thanks for investing the time to make this right,</div><div>Idan</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 16 Nov 2022 at 21:39, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>I think long term compatibility is a very desirable
feature, and several applications just use GDAL as part of
their code base without even being aware of what is
happening in the GDAL development front. The same is true
for several other libraries, given the fact the use of
package managers (VCPKG, conan etc) are becoming more
common. For some code bases, GDAL is just a small cog, and I
believe it is very easy for the developers to simply
download the next version from the package manager thinking
that they are getting mostly bug fixes and not being aware
of new silent incompatibilities.<br>
</div>
<br>
</div>
</div>
</blockquote>
We try to avoid breakage or silent breakage when reasonable, but
sometimes it is the best thing to do. People/software who depends on
the past functionality will see the tests related to their code
testing GetMetadataItem("PIXELTYPE", "IMAGE_STRUCTURE") ==
"SIGNEDBYTE" break and will probably figure out they should read
GDAL release notes to understand what happens. It is not the first
time nor the last one we will do that.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Sorry, but I think it is funny that you mention removing
GDT_Byte would have breaking implications, since I am
expressing my reservations against a change that will have
breaking implications. :) <br>
</div>
</div>
</div>
</blockquote>
My perception is that > 90% of current uses of GDT_Byte are for
the unsigned usage. Of course their might be some domains where this
is not the case.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>I don't understand what limitations you are referring to.
Perhaps the support was broken to some types of raster
files?</div>
</div>
</div>
</blockquote>
This is described in the RFC: " the absence of a proper data type
means that it is easy
to forget to test the PIXELTYPE=SIGNEDBYTE metadata item in all
places where
the value of pixels is taken into account. There were special cases
for
statistics computations, but most of the other code, such as the
overview or
warping computation code had no provision for it, and consequently
mis-interpreted negative values in the range [-128,-1] as positive
values in
the range [128,255]." . So current support of signed 8-byte within
GDAL was broken in a number of places, and the new GDT_Int8 data
type enables to fix it. One could argue that the past behavior of
reporting a metadata item that altered the semantics of GDT_Byte was
a silent breakage of the API promise of GDT_Byte being unsigned.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div> In my field, signed 8-bit images representing
categorical images are very common, given the fact they can
be used fully decompressed and represent a null value/nodata
in very convenient way (as a negative value).<br>
</div>
</div>
</div>
</blockquote>
<p>You should have a better experience with GDAL 3.7 then, pending
perhaps a few changes in your code.</p>
Even<br>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>