[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work

[GRASS GIS]

#73: r.out.gdal tiff output does not work
--------------------------+-------------------------------------------------
  Reporter:  helena       |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect       |      Status:  new                      
  Priority:  critical     |   Milestone:  6.4.0                    
 Component:  Raster       |     Version:  svn-trunk                
Resolution:               |    Keywords:  r.out.gdal, tiff         
  Platform:  Unspecified  |         Cpu:  Unspecified              
--------------------------+-------------------------------------------------
Comment (by mmetz):

 Replying to [comment:1 hamish]:
 > (I see the same with 6.2.1's old script version of r.out.gdal)
 >
 > it works if the values are in the range of 0-255:
 >
 > but not if all values are out of range:

 It is equally right to say that the chosen datatype=Byte is not capable of
 holding the full data range and a different datatype must be chosen.

 > {{{
 >   r.info -r elevation.dem
 >     min=1066
 >     max=1840
 >   r.info -t elevation.dem
 >     datatype=CELL
 >   r.out.gdal in=elevation.dem out=elv.tif type=Byte
 >
 >   r.in.gdal in=elv.tif out=elv2
 >   r.info -r elv2
 >     min=255
 >     max=255
 > }}}
 >
 >
 > we can try with half the raster in range:
 > {{{
 >   r.mapcalc "elev_0 = elevation.dem - 1066"
 >   r.info -r elev_0
 >     min=0
 >     max=774
 >   r.out.gdal in=elev_0 out=elv0.tif type=Byte
 No color table was specified with r.colors, so what data visualization
 scheme is to be expected?
 >
 > If I load elv0.tif into an image viewer it comes out as all black. But
 in Gimp if you use the eyedropper you can see the index number changes,
 but the palette is black for all 256 index entries.

 Gimp and many other image viewers only support 8 bit per channel,
 cinepaint e.g. supports 32 bit. Most of them can not display tiff files
 with anything else but Byte: only tiff images, not tiff datasets.
 Elevation is a dataset, not an image. INT16 or UINT16 would be appropriate
 to hold elevation data, in case of cm accuracy with meters as units,
 FLOAT32 would be ok. Such tiff files hold a dataset. For elevation data,
 GRASS offers several color tables which can be written to a tiff file as a
 suggested data visualization scheme, if they have been set with r.colors.
 Still, datatypes other than Byte can only be read with spatial data
 viewers that could make use of this colour table, but not all of them are
 actually able to do so. They could instead choose their own color schemes.
 >
 > gdalinfo confirms palette info was not written to file:
 But the color palette was indeed written to the file.
 >
 > {{{
 > Band 1 Block=1899x4 Type=Byte, ColorInterp=Palette
 >   NoData Value=255
 >   Metadata:
 >     COLOR_TABLE_RULES_COUNT=0
 Below here. The instructions read to display each value with R:G:B = 0:0:0
 = black. A data visualization scheme should have been provided with
 r.colors to have control over the colortable written to the tiff file.
 >   Color Table (RGB with 256 entries)
 >     0: 0,0,0,255
 >     1: 0,0,0,255
 >     2: 0,0,0,255
 >     3: 0,0,0,255
 >     4: 0,0,0,255
 > ...
 >   255: 0,0,0,255
 > }}}
 >

 > If you want to store integer values >255 in the Tiff, you will have to
 use one of Int16,UInt16,UInt32,Int32[,CInt16,CInt32?].
 >
 It would help a lot to have a list with these data types and their ranges
 in the man page so that the appropriate data type for file export can be
 chosen.

 > If you use type=Int32 etc you should preserve the CELL data for use in
 other GIS software, even if the saved palette is bogus.

 Maybe the color table is not so important, different people have different
 preferences e.g. for elevation data visualization.
 If imagery is exported, e.g. after atmospheric correction or masking, the
 datatype should probably be Byte as it was originally, e.g. to make
 postprocessing in Gimp possible.
 A tiff file that holds an image (e.g. GRASS display saved as tiff, a
 scanned image, aerial photography, LANDSAT) does not have a color table,
 usually. It does not need one, because the data in the file are already
 R:G:B or grayscale (better: single band) values.

 As long as both the data in the tiff file and its georeferencing are
 identical to the original raster, the tiff file could be regarded as
 perfectly ok. Suggested data visualization with an embedded color table is
 nice to have, but coloring schemes are a matter of taste and not crucial
 for further processing (e.g. terrain analysis with a DEM).

 There is still the issue of nodata: a nodata value must fall into the
 range of the chosen datatype, otherwise this information gets lost.
 r.out.gdal does not check if a supplied nodata value is valid.

 >
 > Only Byte and UInt16 will attempt to write out a color palette to the
 GeoTIFF AFAIK.
 >
 For UINT16, the color table in the tiff file will always have 65535
 entries, gdal does that. This slows down display. Have an option in
 r.out.gdal to choose whether a color table should be written to the tiff
 file?

 Markus

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/73#comment:11>
GRASS GIS <http://grass.osgeo.org>