Bug report #20493
32 bit floating geotiff showing as black. worked in 2.18 and 3.0 - not working 3.4
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)
details page
after converting in arcgis it works though. any ideas?
History
#1 Updated by Giovanni Manghi about 6 years 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 almost 6 years ago
Strange also works in 3.2 ; but not 3.3 onwards..
#3 Updated by Giovanni Manghi almost 6 years ago
- Crashes QGIS or corrupts data changed from Yes to No
- Regression? changed from No to Yes
#4 Updated by Brad Kanther almost 6 years ago
- File assignprojections.jpg added
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 almost 6 years 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 almost 6 years 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 almost 6 years ago
- Assignee set to Peter Petrik
- Affected QGIS version changed from 3.4.3 to 3.5(master)
#8 Updated by Peter Petrik almost 6 years 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 almost 6 years ago
- Status changed from Open to In Progress
- Assignee set to Peter Petrik
#10 Updated by Even Rouault almost 6 years 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 almost 6 years ago
- Status changed from In Progress to Closed
#12 Updated by Peter Petrik almost 6 years ago
also backported https://github.com/qgis/QGIS/pull/9056