Opened 8 years ago

Closed 3 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)

one.tif (29.7 KB) - added by Jukka Rahkonen 7 years ago.
two.tif (29.7 KB) - added by Jukka Rahkonen 7 years ago.

Download all attachments as: .zip

Change History (5)

Changed 7 years ago by Jukka Rahkonen

Attachment: one.tif added

Changed 7 years ago by Jukka Rahkonen

Attachment: two.tif added

comment:1 Changed 7 years ago by Jukka Rahkonen

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.

gdal_calc -A one.tif -B two.tif --outfile three-one.tif --calc="A*20+B"
gdal_calc -A one.tif -B two.tif --outfile three-two.tif --calc="A*20.0+B"

The first command yields a valid image as far as I understand. The latter creates somehow faulty image and gdalinfo -stats throws an error:

ERROR 1: three-two.tif, band 1: Failed to compute statistics,
no valid pixels found in sampling.

comment:2 Changed 6 years ago by meier

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.

Last edited 6 years ago by meier (previous) (diff)

comment:3 Changed 3 years ago by Even Rouault

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.