Hermann, Speaking to GDAL being one (not very small) piece of an ecosystem of libraries and tools:
This is exactly what unit tests are for. A well done tool or library should have the tests that cover their critical uses of libraries they depend on. It's often referred to as the "Beyonce rule": "If you liked it, you should have put a test on it." (c.f. here <https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ch01.html> ) Now is a great time to make sure that your workflow has a check for proper handling of 8-bit rasters. -kurt On Wed, Nov 16, 2022 at 11:39 AM Even Rouault <even.roua...@spatialys.com> wrote: > > > 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. > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
