Bug report #22010

Raster calculator, abs() not working

Added by Adriaan van Natijne 7 months ago. Updated 7 months ago.

Status:Open
Priority:High
Assignee:-
Category:Raster Calculator
Affected QGIS version:3.6.1 Regression?:Yes
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:29824

Description

The abs() function in the QGIS 3.6.1 Raster Calculator does not work. When the absolute value is taken using the Raster -> Raster Calculator function it will return the original (negative) values without a warning. As an example a GeoTiff (neg2.tif) is attached with the result from the Raster Calculator (abs2.tif). Behaviour was observed on both Microsoft Windows and Linux machines.

I am unsure if the function worked properly in previous versions of QGIS. Although we have not noticed the problem before upgrading to QGIS 3, reanalysis of earlier results shows that the bug might have been present before.

From issue #21405 I understood that the OpenCL acceleration may produce erroneous results in the raster calculator. OpenCL was disabled on at least some of the machines this was tested on.

The Raster Calculator provided by GDAL provides the correct results.
gdal_calc.py --calc "abs(A)" --format GTiff --type Float32 -A /tmp/abs2.tif --A_band 1 --outfile /tmp/abs2_gdal.tif

Workaround
Use GDAL Raster Calculator or sqrt("[email protected]"^2) in the QGIS Raster Calculator.

neg2.tif - Example GeoTiff, with both negative and positive values. (25.5 KB) Adriaan van Natijne, 2019-05-07 04:41 PM

abs2.tif - Result of abs([email protected]) in the QGIS Raster Calculator. (25.5 KB) Adriaan van Natijne, 2019-05-07 04:43 PM

abs2_gdal.tif - Result of abs(A) in the GDAL Raster Calculator. (25.5 KB) Adriaan van Natijne, 2019-05-07 04:43 PM

History

#1 Updated by Alessandro Pasotti 7 months ago

Just to clarify, OpenCL option should not produce wrong results and if it does it's a bug and should be reported.

That said, it is important for us to know if the issue was found with that option on or off because the code paths are different.

#2 Updated by Adriaan van Natijne 7 months ago

Alessandro Pasotti wrote:

That said, it is important for us to know if the issue was found with that option on or off because the code paths are different.

On my machine OpenCL was switched off (and can't be enabled due to missing drivers).

I have since installed QGIS 3.6.2, which did not solve the issue.

#3 Updated by Adriaan van Natijne 7 months ago

This issue is also confirmed in QGIS 3.4.4 on Windows.

Diving into the source, the issue is probably more general in nature. As far as I could reconstruct the syntax checking is done in source:src/analysis/raster/qgsrastercalcparser.yy. Here any function is accepted, therefore the use of abs(), chocolate() and spaghetti() are all considered valid by the raster calculator - although none of them is implemented. I believe the actual calculations are done in consecutive calls to source:src/analysis/raster/qgsrastercalcnode.cpp#L53. For unknown operations this function will return false. As the ouput of the calculate() function is checked before writing (either source:src/analysis/raster/qgsrastercalculator.cpp#L233 or source:src/analysis/raster/qgsrastercalculator.cpp#L306) I am unsure on why/how the original data is written to the output. Possibly due to the fact that ("[email protected]") is a valid statement in itself, that copies the input to the output matrix (source:src/analysis/raster/qgsrastercalcnode.cpp#L189?) before trying to apply the non-existent abs function?

#4 Updated by Giovanni Manghi 7 months ago

  • Regression? changed from No to Yes
  • Operating System deleted (Ubuntu 18.04.2)
  • Priority changed from Normal to High

Also available in: Atom PDF