[gdal-dev] gdalinfo and scale/offset
Joaquim Luis
jluis at ualg.pt
Thu Oct 28 15:10:00 EDT 2010
Kyle,
Yes, that is much better but (sorry for one other 'but') what about
formats that do not know anything about scale/offset?
(Surfer format is one comes right to my mind)
In those cases conversion would definitively go wrong. Issue a
screaming warning in than?
Joaquim
> 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 <mailto:kshannon at fs.fed.us>
> # ============================
>
>
> On Thu, Oct 28, 2010 at 12:35 PM, Joaquim Luis <jluis at ualg.pt
> <mailto: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 <mailto:kshannon at fs.fed.us>
> # ============================
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org <mailto: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/c365ba12/attachment.html
More information about the gdal-dev
mailing list