<div dir="ltr"><div>Hi<br></div><br><div class="gmail_quote">><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> So based on that RFC it is a breaking change when reading signed <br>
> images. I confess that this type of silent behavor change scares me.<br>
It is documented in <br>
<a href="https://github.com/OSGeo/gdal/blob/master/MIGRATION_GUIDE.TXT" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/blob/master/MIGRATION_GUIDE.TXT</a> which is <br>
always referenced in the release notes.<br>
><br>
> Why dont make this an opt-in behavior instead of just breaking <br>
> application code silently?<br>
Opt-in behaviour would mean clutering the GDAL code base even more, to <br>
implement both the legacy and the new behavior. One of the purposes of <br>
the RFC was to de-clutter the GDAL code base.<br>
</blockquote><div><br></div><div>I understand the idea of decluttering the code base and I think it is a valid point and I agree that not having to check PIXELTYPE when reading or writing images is better. What I still don't understand is why break code in a way that the compiler would not help at all when just compiling a library or application against the new GDAL version.</div><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><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Otherwise, I would rather have GDT_Byte removed so that application <br>
> code would not compile against new versions of GDAL. At least that <br>
> makes migration to new versions less risky.<br>
<br>
Removing GDT_Byte would have enormous breaking implications! Signed Byte <br>
is I believe a marginal feature not commonly used by GDAL based <br>
applications, partly because the support for it before RFC87 was clunky <br>
and partial.<br></blockquote><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><br></div><div>I don't understand what limitations you are referring to. Perhaps the support was broken to some types of raster files? 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><br></div><div>Best,<br></div><div><br></div><div>hermann <br></div><div><br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>----------------------------------------------------------------------<br>Hermann Rodrigues<br><a href="mailto:hermann.rodrigues@gmail.com" target="_blank">hermann.rodrigues@gmail.com</a><br><a href="mailto:hermann@csr.ufmg.br" target="_blank">hermann@csr.ufmg.br</a><br><span style="font-size:12.8px">Twitter: @horodrigues | @dinamica_ego</span></div><div></div><div>Centro de Sensoriamento Remoto / UFMG<br><a href="https://csr.ufmg.br" target="_blank">https://csr.ufmg.br</a> | <a href="https://dinamicaego.com" target="_blank">https://dinamicaego.com</a></div></div></div></div> </div></div></div>