Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raster calculator, abs() not working #29824

Closed
qgib opened this issue May 7, 2019 · 5 comments · Fixed by #29965
Closed

Raster calculator, abs() not working #29824

qgib opened this issue May 7, 2019 · 5 comments · Fixed by #29965
Assignees
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Rasters Related to general raster layer handling (not specific data formats)

Comments

@qgib
Copy link
Contributor

qgib commented May 7, 2019

Author Name: Adriaan van Natijne (Adriaan van Natijne)
Original Redmine Issue: 22010
Affected QGIS version: 3.6.1
Redmine category:raster_calculator


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 #29222 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("neg2@1"^2)@ in the QGIS Raster Calculator.


@qgib
Copy link
Contributor Author

qgib commented May 7, 2019

Author Name: Alessandro Pasotti (@elpaso)


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.

@qgib
Copy link
Contributor Author

qgib commented May 7, 2019

Author Name: Adriaan van Natijne (Adriaan van Natijne)


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.

@qgib
Copy link
Contributor Author

qgib commented May 8, 2019

Author Name: Adriaan van Natijne (Adriaan van Natijne)


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 @("neg2@1")@ 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?

@qgib
Copy link
Contributor Author

qgib commented May 9, 2019

Author Name: Giovanni Manghi (@gioman)


  • regression was changed from 0 to 1
  • operating_system was changed from Ubuntu 18.04.2 to
  • priority_id was changed from Normal to High

@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! High Priority Rasters Related to general raster layer handling (not specific data formats) Regression Something which used to work, but doesn't anymore labels May 25, 2019
@elpaso elpaso self-assigned this May 27, 2019
@elpaso
Copy link
Contributor

elpaso commented May 27, 2019

I think that the bug here is that the raster calculator does not flag as invalid an expression that contains not-implemented functions, for example:

 abs ( "RT_T33UVV_A008628_20181031T101140_B08_clip@1" )

@elpaso elpaso removed High Priority Regression Something which used to work, but doesn't anymore labels May 27, 2019
elpaso added a commit to elpaso/QGIS that referenced this issue May 27, 2019
Tell the user that is invalid instead of
silently ignoring undefined functions.

Fixes qgis#29824
backporting bot pushed a commit that referenced this issue May 27, 2019
Tell the user that is invalid instead of
silently ignoring undefined functions.

Fixes #29824
nyalldawson pushed a commit that referenced this issue May 27, 2019
Tell the user that is invalid instead of
silently ignoring undefined functions.

Fixes #29824
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Rasters Related to general raster layer handling (not specific data formats)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants