<div dir="auto">nice, thanks so much for the extended description.<div dir="auto"><br></div><div dir="auto">Cheers, Mike</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 8 Sept 2023, 21:34 Even Rouault, <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p>Michael,</p>
<p>It turns out that gdal_translate was using 255.999 since the
origins in 2002 :
<a href="https://github.com/OSGeo/gdal/commit/47d859efb25da249b5d62eb8619c36134ae76572#diff-d57b4553312c88a736821448adc155e6797653b0d902bd42f9310572aa71f0b0R215" target="_blank" rel="noreferrer">https://github.com/OSGeo/gdal/commit/47d859efb25da249b5d62eb8619c36134ae76572#diff-d57b4553312c88a736821448adc155e6797653b0d902bd42f9310572aa71f0b0R215</a></p>
<p>I suspect the reasoning was that, if you rounded values down
(floor) and used 255 as the scaleDstMax, and you remapped
[0,65535] to [0,255] for example, then 65534. / (65535. / 255) =
254.996.. would be rounded to 254. So you would only get 255 as
the output for 65535 as the input, which seems "unfair". But GDAL
actually rounds to closest, so if using dstMax = 65535, all input
values in range [65535 - 128, 65535] get scaled to 255, which is
OK to me. Of course that last "bucket" and the first one at 0
(input values in [0,128]) are half-width of the ones in the middle
(input values in [129,129+256] get scaled to 1) but I don't think
we can do much about that (discrete values vs intervals)<br>
</p>
<p>One downside of using dstMax=255.999 is that if your input range
is [0, 255], then -scale was not the identity (254 got transformed
to 253), which is kind of an issue! Hence I've changed dstMax to
be 255 in <a href="https://github.com/OSGeo/gdal/pull/8367" target="_blank" rel="noreferrer">https://github.com/OSGeo/gdal/pull/8367</a></p>
<p>I've also noticed during testing a more subtle consistency issue
when if you did for example "gdal_translate
autotest/gcore/data/byte.tif out.asc -scale 0 1 0 1.5 -of
aaigrid", you would get values outside of the [0, 255] range
because the VRT machinery was ignoring the constraints of the
VRTRasterBand data type (Byte), and was only honouring the buffer
data type of the RasterIO() request from the AAIGrid driver
(Int32, always used when translating from source bands having
integer data types, but with the reasoning that if you query a
Byte band then you would get always value in [0,255] range)<br>
</p>
<p>Even<br>
</p>
<div>Le 08/09/2023 à 04:20, Michael Sumner a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi, I'm expecting `gdal_translate -scale` to emit values in
the range 0,255 but it seems to be targeting 0,256. (All
works as expected when using explicit src_min src_max dst_min
dst_max).
<div><br>
</div>
<div>To see the output range on a simple example (see code at
link below in case email garbles): </div>
<div><br>
</div>
<div>from osgeo import gdal<br>
ds = gdal.Translate("/vsimem/scl.tif",
"autotest/gcore/data/float32.tif", options = "-scale")<br>
ds.GetRasterBand(1).ComputeRasterMinMax()<br>
</div>
<div>## (0.0, 255.99899291992188)</div>
<div><br>
</div>
<div>
<div>Is that expected, am I missing something? I've tried
variations on the input values and output types. </div>
<div><br>
</div>
</div>
<div><a href="https://gist.github.com/mdsumner/ee4103d8616b9aa341e82c46b44a8c8c" target="_blank" rel="noreferrer">https://gist.github.com/mdsumner/ee4103d8616b9aa341e82c46b44a8c8c</a><br>
</div>
<div><br>
</div>
<div>Cheers, Mike</div>
</div>
<div><br>
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Michael Sumner<br>
Research Software Engineer<br>
Australian Antarctic Division<br>
Hobart, Australia<br>
e-mail: <a href="mailto:mdsumner@gmail.com" target="_blank" rel="noreferrer">mdsumner@gmail.com</a></div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
gdal-dev mailing list
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="noreferrer">gdal-dev@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank" rel="noreferrer">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank" rel="noreferrer">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" rel="noreferrer">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>