[gdal-dev] Motion: adopt RFC 87: Signed int8 data type for raster

[Even Rouault]

>
> 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.
>
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.
>
> 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. :)
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.
>
> I don't understand what limitations you are referring to. Perhaps the 
> support was broken to some types of raster files?
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.
> 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).

You should have a better experience with GDAL 3.7 then, pending perhaps 
a few changes in your code.

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20221116/cc8925d9/attachment-0001.htm>