[gdal-dev] gdalinfo and scale/offset
Kyle Shannon
ksshannon at gmail.com
Thu Oct 28 14:51:10 EDT 2010
Joaquim,
With my code I wrote today, the offset and scale are set on the
GDALRasterBand itself. If I do the following:
gdal_translate lixo.grd lixo.tif
gdalinfo lixo.tif -mm
I get:
Driver: GTiff/GeoTIFF
Files: lixo.tif
lixo.tif.aux.xml
Size is 21, 21
Coordinate System is `'
Origin = (-10.500000000000000,10.500000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)
Metadata:
NC_GLOBAL#Conventions=COARDS/CF-1.0
NC_GLOBAL#title=lixo.grd
NC_GLOBAL#history=grdmath -R-10/10/-10/10 -I1 X Y MUL = lixo.grd
NC_GLOBAL#GMT_version=4.5.4
z#long_name=z
z#_FillValue=nan
z#actual_range=-1, 1
z#scale_factor=0.01
x#long_name=x
x#actual_range=-10, 10
y#long_name=y
y#actual_range=-10, 10
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( -10.5000000, 10.5000000)
Lower Left ( -10.5000000, -10.5000000)
Upper Right ( 10.5000000, 10.5000000)
Lower Right ( 10.5000000, -10.5000000)
Center ( 0.0000000, 0.0000000)
Band 1 Block=21x21 Type=Float32, ColorInterp=Gray
Computed Min/Max=-100.000,100.000
NoData Value=nan
Offset: 0, Scale:0.01
Metadata:
NETCDF_VARNAME=z
where you can see the offset and scale reported at the band level. This is
not just metadata anymore, it belongs to GDALRasterBand.
if I run:
gdal_translate -unscale lixo.grd lixo_uscale.tif
gdalinfo -mm lixo_unscale.tif
Files: lixo_uscale.tif
lixo_uscale.tif.aux.xml
Size is 21, 21
Coordinate System is `'
Origin = (-10.500000000000000,10.500000000000000)
Pixel Size = (1.000000000000000,-1.000000000000000)
Metadata:
NC_GLOBAL#Conventions=COARDS/CF-1.0
NC_GLOBAL#title=lixo.grd
NC_GLOBAL#history=grdmath -R-10/10/-10/10 -I1 X Y MUL = lixo.grd
NC_GLOBAL#GMT_version=4.5.4
z#long_name=z
z#_FillValue=nan
z#actual_range=-1, 1
z#scale_factor=0.01
x#long_name=x
x#actual_range=-10, 10
y#long_name=y
y#actual_range=-10, 10
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( -10.5000000, 10.5000000)
Lower Left ( -10.5000000, -10.5000000)
Upper Right ( 10.5000000, 10.5000000)
Lower Right ( 10.5000000, -10.5000000)
Center ( 0.0000000, 0.0000000)
Band 1 Block=21x21 Type=Float32, ColorInterp=Gray
Computed Min/Max=-1.000,1.000
NoData Value=nan
Metadata:
NETCDF_VARNAME=z
The data in the tif is unscaled or unpacked.
I don't know if this is clear, I apologize for all the snippets. I, like
Even, have no strong feelings for gdalinfo reporting scaled/unscaled data.
kss
# ============================
Kyle Shannon
Physical Science Technician
RMRS Fire Sciences Lab
Fire, Fuels & Smoke - RWU 4405
5775 Highway 10 W.
Missoula, MT 59808
(406)829-6954
kshannon at fs.fed.us
# ============================
On Thu, Oct 28, 2010 at 12:35 PM, Joaquim Luis <jluis at ualg.pt> wrote:
> Even
>
> Thanks for pointing into this that I was not aware of as it would be the
> main point of my answer to Kyle's question.
> But still, as it is referred in the ticket (sorry for lousy formatting but
> I never learn how to do it better) the main issue occurred in the conversion
> to another format (geotiff for that matter). So though an option exists
> ('unscale') to account for offset/scale the natural expectancy is that the
> conversion does not change the data values.
>
> Redoing the tickets example we can see (not shown than because I thought
> it of lesser interest)
>
> C:\SVN\mironeWC\src_C\t>gdalinfo lixo.tiff -mm
> Driver: GTiff/GeoTIFF
> Files: lixo.tiff
> Size is 21, 21
> Coordinate System is `'
> Origin = (-10.500000000000000,10.500000000000000)
> Pixel Size = (1.000000000000000,-1.000000000000000)
> Metadata:
> NC_GLOBAL#Conventions=COARDS/CF-1.0
> NC_GLOBAL#title=lixo.grd
> NC_GLOBAL#history=grdmath -R-10/10/-10/10 -I1 X Y MUL = lixo.grd
> NC_GLOBAL#GMT_version=4.5.4
> z#long_name=z
> z#_FillValue=1.#QNAN0e+000
> z#actual_range=-1, 1
> z#scale_factor=0.01
> x#long_name=x
> x#actual_range=-10, 10
> y#long_name=y
> y#actual_range=-10, 10
> Image Structure Metadata:
> INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left ( -10.5000000, 10.5000000)
> Lower Left ( -10.5000000, -10.5000000)
> Upper Right ( 10.5000000, 10.5000000)
> Lower Right ( 10.5000000, -10.5000000)
> Center ( 0.0000000, 0.0000000)
> Band 1 Block=21x21 Type=Float32, ColorInterp=Gray
> Computed Min/Max=-100.000,100.000
>
>
> It's true that we can still see a trace of the previous info about the
> scale
>
> z#actual_range=-1, 1
> z#scale_factor=0.01
>
> but a user would need to be very very attentive to realize that and to know
> that the data values were off by an 0.01 factor.
>
> I think that in these situations the scale factor would better be applied
> by default (like with the gdal_info example)
>
> Joaquim
>
> Kyle,
>>
>> Frank added in GDAL 1.7 a '-unscale' option to gdal_translate, so people
>> can
>> always use gdal_translate -unscale to apply the offset and scale (they can
>> even
>> do that do a VRT file to save disk space), and then use gdalinfo on the
>> result.
>>
>> Extract from the gdal_translate man page:
>>
>> "-unscale : Apply the scale/offset metadata for the bands to convert
>> scaled
>> values to unscaled values. It is also often necessary to reset the output
>> datatype with the -ot switch."
>>
>> Is there a need for such an option in gdalinfo ? I have no strong opinion
>> about this. An issue I see is that usually -stats record the computed
>> stats in
>> a .aux.xml file for later retrieval. The interaction with a -unscale
>> option
>> would be tricky... What happens if the user computes with -unscale and
>> then do
>> gdalinfo without it... Or the other way round.
>>
>> Le jeudi 28 octobre 2010 19:58:55, Kyle Shannon a écrit :
>>
>>
>>> Hello,
>>> I have been working on ticket #3797. In the example given, gdalinfo is
>>> the calling the netcdf driver. I agree with Frank's opinion on this in
>>> ticket #1660:
>>>
>>> Note that GDALRasterBand has methods to get the offset and scale. The
>>> normal
>>>
>>>
>>>
>>>> GDAL practice would be to return them via those methods - not to apply
>>>> them on the fly. Then it is up to the caller to do so if they wish.
>>>>
>>>>
>>> gdal shouldn't be in charge of scaling the data to what may be a
>>> different
>>> data type, or unpacking it. But in this case, gdalinfo is the caller.
>>> Should the functionality of the scaling be added to gdalinfo? Maybe
>>> optionally reporting the stats as scaled data? Any thoughts?
>>>
>>> # ============================
>>> Kyle Shannon
>>> Physical Science Technician
>>> RMRS Fire Sciences Lab
>>> Fire, Fuels& Smoke - RWU 4405
>>> 5775 Highway 10 W.
>>> Missoula, MT 59808
>>> (406)829-6954
>>> kshannon at fs.fed.us
>>> # ============================
>>>
>>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>>
>>
>>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20101028/0c686cf8/attachment-0001.html
More information about the gdal-dev
mailing list