<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <br>
    <blockquote type="cite"
cite="mid:CADnw22bz-y78R8t+HwgatO25kBshb3xTA1eaYi28u5LkuWHp5g@mail.gmail.com">
      <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"
cite="mid:CADnw22bz-y78R8t+HwgatO25kBshb3xTA1eaYi28u5LkuWHp5g@mail.gmail.com">
      <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"
cite="mid:CADnw22bz-y78R8t+HwgatO25kBshb3xTA1eaYi28u5LkuWHp5g@mail.gmail.com">
      <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"
cite="mid:CADnw22bz-y78R8t+HwgatO25kBshb3xTA1eaYi28u5LkuWHp5g@mail.gmail.com">
      <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 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.</pre>
  </body>
</html>