Bug report #20493

32 bit floating geotiff showing as black. worked in 2.18 and 3.0 - not working 3.4

Added by Brad Kanther about 1 year ago. Updated 10 months ago.

Status:Closed
Priority:High
Assignee:Peter Petrik
Category:Rasters
Affected QGIS version:3.5(master) Regression?:Yes
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:28313

Description

Not sure why these type of geotiff's that were previously been read are now displaying as black and all at one elevation in QGIS 3.4. (see attached files)

geotiff

details page

after converting in arcgis it works though. any ideas?

geotiffproblems-02.jpg (57.8 KB) Brad Kanther, 2018-11-15 01:13 AM

geotiffproblems-01.jpg - geotiff (51.3 KB) Brad Kanther, 2018-11-15 01:13 AM

geotiffproblems-03.jpg (66.1 KB) Brad Kanther, 2018-11-15 01:13 AM

GEOTIFF_32floating.zip (2.82 MB) Brad Kanther, 2018-11-15 01:16 AM

assignprojections.jpg (59.8 KB) Brad Kanther, 2019-01-10 01:47 AM

History

#1 Updated by Giovanni Manghi about 1 year ago

  • Crashes QGIS or corrupts data changed from No to Yes
  • Priority changed from Normal to High
  • Operating System deleted (Win 7 64 bit)

Confirmed, it seems incapable to compute the mix/max values. On 2.18 is ok.

#2 Updated by Brad Kanther 12 months ago

Strange also works in 3.2 ; but not 3.3 onwards..

#3 Updated by Giovanni Manghi 12 months ago

  • Crashes QGIS or corrupts data changed from Yes to No
  • Regression? changed from No to Yes

#4 Updated by Brad Kanther 10 months ago

A current work around to this issue is to simply use the GDAL "Assign projection" tool to read in these geotiff's and they work.

Not sure if this hlps diagnose the problem with the geotiffs

#5 Updated by Nyall Dawson 10 months ago

  • Status changed from Open to Feedback

Works fine here -- using GDAL 2.2.4. What version of GDAL are you using?

#6 Updated by Giovanni Manghi 10 months ago

  • Status changed from Feedback to Open
  • Affected QGIS version changed from 3.4.1 to 3.4.3

Nyall Dawson wrote:

Works fine here -- using GDAL 2.2.4. What version of GDAL are you using?

I see the same as the issuer:

On Linux with 3.4.3 and GDAL 2.3.1
AND
Window with 3.4.3 and GDAL 2.4

the raster load in QGIS with min AND max value 192.59, and in the propoerties there no way to make QGIS compute the real min/max (as given by GDAL, for example with gdalinfo from Processing --> Minimum=193.126, Maximum=228.477, Mean=213.176, StdDev=7.677)

On Linux with 2.18.27 and GDAL 2.2.3 it all works as expected.

#7 Updated by Peter Petrik 10 months ago

  • Assignee set to Peter Petrik
  • Affected QGIS version changed from 3.4.3 to 3.5(master)

#8 Updated by Peter Petrik 10 months ago

  • Assignee deleted (Peter Petrik)

with GDAL 2.2.x QgsGdalProvider::bandScale( bandNo ) = 1, but with GDAL 2.3.x, 2.4.x scale returned by GDALGetRasterScale() is 0, which effectively sets min and max to a single value and the resulting image is black

gdalinfo -stats ~/GIS/bugs/20493/GEOTIFF_32floating.tif
Driver: GTiff/GeoTIFF
Files: /Users/peter/GIS/bugs/20493/GEOTIFF_32floating.tif
       /Users/peter/GIS/bugs/20493/GEOTIFF_32floating.tif.aux.xml
Size is 1553, 856
Coordinate System is:
LOCAL_CS["unnamed",
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (639355.488999999943189,7430046.259999999776483)
Pixel Size = (2.000000000000000,-2.000000000000000)
Metadata:
  AREA_OR_POINT=Area
  TIFFTAG_SOFTWARE=Autodesk Civil3D 2008
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  639355.489, 7430046.260) 
Lower Left  (  639355.489, 7428334.260) 
Upper Right (  642461.489, 7430046.260) 
Lower Right (  642461.489, 7428334.260) 
Center      (  640908.489, 7429190.260) 
Band 1 Block=1553x100 Type=Float32, ColorInterp=Gray
  Min=193.126 Max=228.477 
  Minimum=193.126, Maximum=228.477, Mean=213.176, StdDev=7.677
  NoData Value=3.4028234663852886e+38
  Offset: 192.59,  Scale:0
  Metadata:
    STATISTICS_MAXIMUM=228.4774017334
    STATISTICS_MEAN=213.17601565667
    STATISTICS_MINIMUM=193.12649536133
    STATISTICS_STDDEV=7.6765733315397

#9 Updated by Peter Petrik 10 months ago

  • Status changed from Open to In Progress
  • Assignee set to Peter Petrik

#10 Updated by Even Rouault 10 months ago

GDAL upstream fixed push in GDAL master per https://github.com/OSGeo/gdal/commit/e261b7ff4fa15e762f7f3a73ff3dbc965181d991 and release/2.4 (for 2.4.1) per https://github.com/OSGeo/gdal/commit/0a3d241f96e83b86073efc86b51376c7cd5f6e4f
A reasonable QGIS workaround is to check GDALGetRasterScale() != 0, since == 0 doesn't make much sense

#11 Updated by Peter Petrik 10 months ago

  • Status changed from In Progress to Closed

Also available in: Atom PDF