<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Kyle,<br>
<br>
Yes, that is much better but (sorry for one other 'but') what about
formats that do not know anything about scale/offset?<br>
(Surfer format is one comes right to my mind)<br>
In those cases conversion would definitively go wrong. Issue a
screaming warning in than?<br>
<br>
Joaquim<br>
<br>
<blockquote
cite="mid:AANLkTimiZ834k=fuLDqZb8Mxeuo57T6sWQezf2ZpOUgX@mail.gmail.com"
type="cite"><font face="courier new,monospace">Joaquim,<br>
With my code I wrote today, the offset and scale are set on the
GDALRasterBand itself. If I do the following:<br>
<br>
gdal_translate lixo.grd lixo.tif<br>
gdalinfo lixo.tif -mm<br>
<br>
I get:<br>
<br>
Driver: GTiff/GeoTIFF<br>
Files: lixo.tif<br>
lixo.tif.aux.xml<br>
Size is 21, 21<br>
Coordinate System is `'<br>
Origin = (-10.500000000000000,10.500000000000000)<br>
Pixel Size = (1.000000000000000,-1.000000000000000)<br>
Metadata:<br>
NC_GLOBAL#Conventions=COARDS/CF-1.0<br>
NC_GLOBAL#title=lixo.grd<br>
NC_GLOBAL#history=grdmath -R-10/10/-10/10 -I1 X Y MUL = lixo.grd<br>
NC_GLOBAL#GMT_version=4.5.4<br>
z#long_name=z<br>
z#_FillValue=nan<br>
z#actual_range=-1, 1<br>
z#scale_factor=0.01<br>
x#long_name=x<br>
x#actual_range=-10, 10<br>
y#long_name=y<br>
y#actual_range=-10, 10<br>
Image Structure Metadata:<br>
INTERLEAVE=BAND<br>
Corner Coordinates:<br>
Upper Left ( -10.5000000, 10.5000000) <br>
Lower Left ( -10.5000000, -10.5000000) <br>
Upper Right ( 10.5000000, 10.5000000) <br>
Lower Right ( 10.5000000, -10.5000000) <br>
Center ( 0.0000000, 0.0000000) <br>
Band 1 Block=21x21 Type=Float32, ColorInterp=Gray<br>
Computed Min/Max=-100.000,100.000<br>
NoData Value=nan<br>
Offset: 0, Scale:0.01<br>
Metadata:<br>
NETCDF_VARNAME=z<br>
<br>
where you can see the offset and scale reported at the band level.
This is not just metadata anymore, it belongs to GDALRasterBand. <br>
<br>
if I run:<br>
gdal_translate -unscale lixo.grd lixo_uscale.tif<br>
gdalinfo -mm lixo_unscale.tif<br>
<br>
Files: lixo_uscale.tif<br>
lixo_uscale.tif.aux.xml<br>
Size is 21, 21<br>
Coordinate System is `'<br>
Origin = (-10.500000000000000,10.500000000000000)<br>
Pixel Size = (1.000000000000000,-1.000000000000000)<br>
Metadata:<br>
NC_GLOBAL#Conventions=COARDS/CF-1.0<br>
NC_GLOBAL#title=lixo.grd<br>
NC_GLOBAL#history=grdmath -R-10/10/-10/10 -I1 X Y MUL = lixo.grd<br>
NC_GLOBAL#GMT_version=4.5.4<br>
z#long_name=z<br>
z#_FillValue=nan<br>
z#actual_range=-1, 1<br>
z#scale_factor=0.01<br>
x#long_name=x<br>
x#actual_range=-10, 10<br>
y#long_name=y<br>
y#actual_range=-10, 10<br>
Image Structure Metadata:<br>
INTERLEAVE=BAND<br>
Corner Coordinates:<br>
Upper Left ( -10.5000000, 10.5000000) <br>
Lower Left ( -10.5000000, -10.5000000) <br>
Upper Right ( 10.5000000, 10.5000000) <br>
Lower Right ( 10.5000000, -10.5000000) <br>
Center ( 0.0000000, 0.0000000) <br>
Band 1 Block=21x21 Type=Float32, ColorInterp=Gray<br>
Computed Min/Max=-1.000,1.000<br>
NoData Value=nan<br>
Metadata:<br>
NETCDF_VARNAME=z<br>
<br>
The data in the tif is unscaled or unpacked. <br>
<br>
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. <br>
<br>
kss<br clear="all">
</font><br>
# ============================<br>
Kyle Shannon<br>
Physical Science Technician<br>
RMRS Fire Sciences Lab<br>
Fire, Fuels & Smoke - RWU 4405<br>
5775 Highway 10 W.<br>
Missoula, MT 59808<br>
(406)829-6954<br>
<a moz-do-not-send="true" href="mailto:kshannon@fs.fed.us">kshannon@fs.fed.us</a><br>
# ============================<br>
<br>
<br>
<div class="gmail_quote">On Thu, Oct 28, 2010 at 12:35 PM, Joaquim
Luis <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jluis@ualg.pt">jluis@ualg.pt</a>></span> wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Even<br>
<br>
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.<br>
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.<br>
<br>
Redoing the tickets example we can see (not shown than because I
thought it of lesser interest)<br>
<br>
C:\SVN\mironeWC\src_C\t>gdalinfo lixo.tiff -mm<br>
Driver: GTiff/GeoTIFF<br>
Files: lixo.tiff<br>
Size is 21, 21<br>
Coordinate System is `'<br>
Origin = (-10.500000000000000,10.500000000000000)<br>
Pixel Size = (1.000000000000000,-1.000000000000000)<br>
Metadata:<br>
NC_GLOBAL#Conventions=COARDS/CF-1.0<br>
NC_GLOBAL#title=lixo.grd<br>
NC_GLOBAL#history=grdmath -R-10/10/-10/10 -I1 X Y MUL = lixo.grd<br>
NC_GLOBAL#GMT_version=4.5.4<br>
z#long_name=z<br>
z#_FillValue=1.#QNAN0e+000<br>
z#actual_range=-1, 1<br>
z#scale_factor=0.01<br>
x#long_name=x<br>
x#actual_range=-10, 10<br>
y#long_name=y<br>
y#actual_range=-10, 10<br>
Image Structure Metadata:<br>
INTERLEAVE=BAND<br>
Corner Coordinates:<br>
Upper Left ( -10.5000000, 10.5000000)<br>
Lower Left ( -10.5000000, -10.5000000)<br>
Upper Right ( 10.5000000, 10.5000000)<br>
Lower Right ( 10.5000000, -10.5000000)<br>
Center ( 0.0000000, 0.0000000)<br>
Band 1 Block=21x21 Type=Float32, ColorInterp=Gray<br>
Computed Min/Max=-100.000,100.000<br>
<br>
<br>
It's true that we can still see a trace of the previous info about the
scale<br>
<br>
z#actual_range=-1, 1<br>
z#scale_factor=0.01<br>
<br>
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.<br>
<br>
I think that in these situations the scale factor would better be
applied by default (like with the gdal_info example)<br>
<br>
Joaquim<br>
<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div class="h5">Kyle,<br>
<br>
Frank added in GDAL 1.7 a '-unscale' option to gdal_translate, so
people can<br>
always use gdal_translate -unscale to apply the offset and scale (they
can even<br>
do that do a VRT file to save disk space), and then use gdalinfo on the
result.<br>
<br>
Extract from the gdal_translate man page:<br>
<br>
"-unscale : Apply the scale/offset metadata for the bands to convert
scaled<br>
values to unscaled values. It is also often necessary to reset the
output<br>
datatype with the -ot switch."<br>
<br>
Is there a need for such an option in gdalinfo ? I have no strong
opinion<br>
about this. An issue I see is that usually -stats record the computed
stats in<br>
a .aux.xml file for later retrieval. The interaction with a -unscale
option<br>
would be tricky... What happens if the user computes with -unscale and
then do<br>
gdalinfo without it... Or the other way round.<br>
<br>
Le jeudi 28 octobre 2010 19:58:55, Kyle Shannon a écrit :<br>
<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello,<br>
I have been working on ticket #3797. In the example given, gdalinfo is<br>
the calling the netcdf driver. I agree with Frank's opinion on this in<br>
ticket #1660:<br>
<br>
Note that GDALRasterBand has methods to get the offset and scale. The<br>
normal<br>
<br>
<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
GDAL practice would be to return them via those methods - not to apply<br>
them on the fly. Then it is up to the caller to do so if they wish.<br>
<br>
</blockquote>
gdal shouldn't be in charge of scaling the data to what may be a
different<br>
data type, or unpacking it. But in this case, gdalinfo is the caller.<br>
Should the functionality of the scaling be added to gdalinfo? Maybe<br>
optionally reporting the stats as scaled data? Any thoughts?<br>
<br>
# ============================<br>
Kyle Shannon<br>
Physical Science Technician<br>
RMRS Fire Sciences Lab<br>
Fire, Fuels& Smoke - RWU 4405<br>
5775 Highway 10 W.<br>
Missoula, MT 59808<br>
(406)829-6954<br>
<a moz-do-not-send="true" href="mailto:kshannon@fs.fed.us"
target="_blank">kshannon@fs.fed.us</a><br>
# ============================<br>
<br>
</blockquote>
</div>
</div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:gdal-dev@lists.osgeo.org"
target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
<br>
<br>
</blockquote>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a moz-do-not-send="true" href="mailto:gdal-dev@lists.osgeo.org"
target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</body>
</html>