<div dir="ltr"><div>hi Even,<br></div><div><br>If you think it's better to keep it that way, let's leave it as it is. :-)<br></div><div><br></div><div>I will definitely try to add that as a hint to the docs. Not sure if that's how you guys work, but I have created an issue for that taks:</div><div><br></div><div><a href="https://github.com/OSGeo/gdal/issues/1848">https://github.com/OSGeo/gdal/issues/1848</a></div><div><br></div><div>Thanks for the fast answer.</div><div><br></div><div>Alex<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 18, 2019 at 10:19 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On mercredi 18 septembre 2019 10:00:51 CEST Alexandre Neto wrote:<br>
> Hi,<br>
> <br>
> I am new to this list so sorry if this has ever been asked or discussed.<br>
> <br>
> I am using two sentinel bands in gdal_calc. they are in jp2 format and<br>
> uint16. I was surprised that subtracting one for the other (A - B) was<br>
> giving me strange results.<br>
> <br>
> gdal_calc.py --calc "(A-B)" --format GTiff --type Float32 -A<br>
> /home/aneto/ARSI/data/S2A_MSIL2A_20170513T172301_N9999_R012_T14TPP_20190912T<br>
> 155528.SAFE/GRANULE/L2A_T14TPP_A009876_20170513T172257/IMG_DATA/R10m/T14TPP_<br>
> 20170513T172301_B08_10m.jp2 --A_band 1 -B<br>
> /home/aneto/ARSI/data/S2A_MSIL2A_20170513T172301_N9999_R012_T14TPP_20190912T<br>
> 155528.SAFE/GRANULE/L2A_T14TPP_A009876_20170513T172257/IMG_DATA/R10m/T14TPP_<br>
> 20170513T172301_B04_10m.jp2 --B_band 1 --outfile<br>
> /tmp/processing_90d61cb0e2a74784a9fcf4b11f9fd7dc/9945d3aec4a749d98f2a3d14694<br>
> abe16/OUTPUT.tif<br>
> <br>
> The result only returns positive integers, and the integers scale seems<br>
> shifted to accommodate the negative values to something above 0.<br>
> <br>
> Strangely the fix comes by multiplying the values by 0.1. So (A*1.0 -<br>
> B*0.1) works as expected.<br>
> <br>
> Is this a known issue? Is it the expected behavior?<br>
<br>
It's kind of expected given how NumPy works, but a lot of people get into this <br>
trap.<br>
<br>
Instead of multiplying by 1, you can also do A.astype(numpy.float32). This <br>
should be marginally faster.<br>
<br>
This is very much the same as doing in C/C++<br>
<br>
unsigned int A = 1;<br>
unsigned int B = 2;<br>
float C = A - B;<br>
<br>
C will be 4294967296 (initialy I used 'unsigned short' for A and B, and I got <br>
-1 as the result, because in C/C++, when there's an arithmetic operation on <br>
types smaller than int, the operand get promoted to int first, which is <br>
signed)<br>
<br>
We could possibly modify gdal_calc to grab the input raster on the specified <br>
output type, but I'm not completely sure this is a good idea, as there could <br>
be use cases where people would want the initial data type to be preserved.<br>
<br>
But feel free to suggest a hint in the documentation of<br>
<a href="https://gdal.org/programs/gdal_calc.html" rel="noreferrer" target="_blank">https://gdal.org/programs/gdal_calc.html</a><br>
I'd suggest both a note in the doc of the --type switch, and add an example <br>
similar to yours at the end.<br>
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</blockquote></div>