Bug report #14210
QGIS adds NODATA values when saving rasters with "Save as..."
|Affected QGIS version:||master||Regression?:||No|
|Operating System:||all||Easy fix?:||No|
|Pull Request or Patch supplied:||No||Resolution:||fixed/implemented|
|Crashes QGIS or corrupts data:||Yes||Copied to github as #:||22212|
- start QGIS and load landcover.img from Alaska dataset
- open Layer properties dialog and go to the Transparency tab. Ensure that NODATA values are not set. Close Layer properties
- save raster as GeoTiff using "Save as.." from context menu using "Raw" output mode and default settings
- load saved raster. Open layer properties and go to the Transparency tab. Now 0 (zero) is NODATA value
Converting same raster in GeoTiff with gdal_translate does not alter NODATA values. QGIS also should not alter NODATA values if user doesn't ask for this, as such silent change lead to the unexpected results.
Maybe related to #11010.
#1 Updated by Radim Blazek over 4 years ago
- Assignee deleted (
There seems to be more problems.
I tried first with bfad753 (Jan 23 2016) and the raster was written with NoData Value=255 (gdalinfo). It is maybe unnecessary to set nodata value but it should not harm, the value is set to high value and it is checked (IIRC) if raster data do not have that value (in which case wider data type is used). Nodata values handling is quite complex and it should be modified carefully (nodata values are for example required if the raster is reprojected).
Then I tried with fresh b6c714a and the raster is written with NoData Value=nan which is obviously wrong for Type=Byte.
Another problem is, that nodata=nan is displayed in transparency tab as 0, but that is again caused by nan for Byte (there is no integer nan, thus it is converted to 0). If the raster is converted to Float64, the nan value is shown correctly in transparency tab.
I don't think it is directly related to #11010 until it was broken trying to fix that issue.
BTW, the dialog is broken (crs, size, resolution), see my comment in #14209