Bug report #5035
stretching with nb of standard deviation: always min = max = 0
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Rasters | ||
| Affected QGIS version: | master | Regression?: | No |
| Operating System: | ubuntu 10.04 | Easy fix?: | No |
| Pull Request or Patch supplied: | No | Resolution: | |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 14808 |
Description
I have an image for which selecting "Use standard deviation"
always results into min and max equal to 0
Is this perhaps because it is float 32 or because of some negative values?
According to R, the actual summaries for each band are:
1 2 3 4 5 6
Min. -3.00 -3.00 -3.0 -3.00 -3.00 -3.00
1st Qu. 67.00 3.00 3.0 4.00 10.00 16.00
Median 84.00 4.00 4.0 4.00 17.00 24.00
Mean 79.78 10.29 14.5 19.05 26.71 26.86
3rd Qu. 97.00 5.00 17.0 18.00 34.00 35.00
Max. 219.00 215.00 234.0 255.00 221.00 178.00
image here:
https://sites.google.com/site/openfiles2/home/Ilerfly125v2geoarcgis2.tif
using ubuntu 10.04
qgis 1.7.3
History
#1
Updated by Leyan Ouyang almost 13 years ago
The direct link to the file is not accessible, the file can be accessed from there though : https://sites.google.com/site/openfiles2/home
Actually, the problem lies within your file itself. Qgis will read GDAL metadata when they are available, and here your metadata indicate a mean and a standard deviation both equal to zero. This means Qgis will calculate min and max values based on this bogus information and obtain 0.
#2
Updated by Paolo Cavallini over 12 years ago
- Target version changed from Version 1.7.4 to Version 1.8.0
#3
Updated by alobo - over 12 years ago
Confirmed the problem of the erroneous stats in the GTif files with several
examples.
These files are created in R through raster::writeRaster(),
which might be using rgdal. In such a case, the problem of these
GTif files with wrong stats could be caused by gdal and be more
widespread. I'm inquiring the author of raster in R and the R sig-geo list.
Anyway, QGIS should have the option of re-calculating the stats.
I would keep this ticket open until I find out more details in the R list,
but this ticket should be closed soon. Another one for the optional stat calculation
should be opened.
Agus
#4
Updated by Giovanni Manghi over 12 years ago
Agus,
rasters are under heavy development in qgis-master. I guess soon we must check every raster related ticket and see if the issue still valid.
alobo - wrote:
Confirmed the problem of the erroneous stats in the GTif files with several
examples.
These files are created in R through raster::writeRaster(),
which might be using rgdal. In such a case, the problem of these
GTif files with wrong stats could be caused by gdal and be more
widespread. I'm inquiring the author of raster in R and the R sig-geo list.
Anyway, QGIS should have the option of re-calculating the stats.
I would keep this ticket open until I find out more details in the R list,
but this ticket should be closed soon. Another one for the optional stat calculation
should be opened.
Agus
#5
Updated by alobo - about 12 years ago
- Status changed from Open to Closed
Confirmed in the R list that the problem is caused by R
writing GTiff files that have erroneous stats info (writeRaster()
used to set the mean and sd values always to 0).
This has been changed for moderately sized layers, which are written with
correct stats now, but very
large layers still get wrong mean and sd (written now
as NaN). By some reason the developer is reluctant to leave
this info empty, which is what gdalinfo -stats would like:
from http://www.gdal.org/gdalinfo.html :
DESCRIPTION
The gdalinfo program lists various information about a GDAL supported
raster dataset.
-mm
Force computation of the actual min/max values for each band in the dataset.
-stats
Read and display image statistics. Force computation if no statistics
are stored in an image.
Anyway, this ticket has to be closed.
I open a new one asking for the feature of having a button to recalculate stats: qgis cannot rely
on external info being always correct.