Opened 10 years ago
Closed 5 years ago
#5478 closed defect (wontfix)
gdal_calc.py gives different answers depending on type of multiplier
Reported by: | timcera | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | closed_because_of_github_migration |
Component: | default | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description
Discovered an interesting problem with gdal_calc.py
The following gives incorrect answers:
gdal_calc.py -A wg.tif -B lc.vrt --outfile=lue.vrt --calc=A*20+B
But the following works fine:
gdal_calc.py -A wg.tif -B lc.vrt --outfile=lue.vrt --calc=A*20.0+B
Just shifting the 20 from integer to float did the trick.
The 'wg.tif' and 'lc.vrt' are Byte.
Attachments (2)
Change History (5)
by , 9 years ago
by , 9 years ago
comment:1 by , 9 years ago
comment:2 by , 8 years ago
Both of the file formats are of the type byte. When you compute A*20 + B, you are overshooting the byte-limits of the layer channel (255). For instance, if the histogram values of A and B (for a particular pixel of a raster layer) are 123 and 77 respectively, then A*20 + B >> 255. The image that will be the output is wrongly formatted. For such an operation, I recommend scaling the images to a higher format (maybe word-aligned/32-bit channel) using gdal_translate http://www.gdal.org/gdal_translate.html and then computing the same.
comment:3 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.
I had also a try with the attached images "one.tif" and "two.tif" and GDAL 1.11.1, released 2014/09/24. For me using integer as multiplier seems to be giving a good result but using a decimal number is no good.
The first command yields a valid image as far as I understand. The latter creates somehow faulty image and gdalinfo -stats throws an error: