[gdal-dev] gdalinfo and scale/offset
Kyle Shannon
ksshannon at gmail.com
Thu Oct 28 15:21:05 EDT 2010
Ah, I see your issue. I honestly don't know what to do about that. The
only option I see is issuing a warning and continuing. I don't think
unscaling that data is an option without a user explicitly asking for it to
be unscaled. I am still not sure if this is even a gdal issue. The caller
just might have to know what's going on. A warning message wouldn't be a
bad idea, but I don't know who's job it should be, whether specific drivers
that don't support Scale/Offset should issue a warning on CreateCopy() or if
the caller, gdal_translate, should issue that warning. I have to defer to
more experienced gdal'ers/programmers.
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 1:10 PM, Joaquim Luis <jluis at ualg.pt> wrote:
> 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
> # ============================
>
>
> 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/65d6a2e0/attachment-0001.html
More information about the gdal-dev
mailing list