[GRASS-user] Attempt to export (r.out.gdal) produces sometimes an error and sometimes not

[Nikos Alexandris]

On Wed, 2008-09-24 at 14:41 +0200, Markus Metz wrote:
> 
> Nikos Alexandris wrote:
> >> r.info composite_b123 -tr
> >>     
> > min=0
> > max=32767
> > datatype=CELL
> > [Raster MASK present]
> >
> > 1st attempt to export:
> >  > r.out.gdal in=composite_b123
> > out=/home/nik/grassdb/peloponnese/data/exports/composite_b123.tif
> > Exporting to GDAL data type: UInt16
> > Segmentation fault
> > [Raster MASK present]
> >
> > 2nd attempt to export without any change:
> >   
> >> r.out.gdal in=composite_b123
> >>     
> > out=/home/nik/grassdb/peloponnese/data/exports/composite_b123.tif
> > Exporting to GDAL data type: UInt16
> > Warning 1: Lost metadata writing to GeoTIFF ... too large to fit in tag.
> >  100%
> > WARNING: Input raster map constains cells with NULL-value (no-data). The
> >          value -32768 was used to represent no-data values in the input
> >          map.You can specify nodata value by nodata parameter.
> > Warning 1: Lost metadata writing to GeoTIFF ... too large to fit in tag.
> > r.out.gdal complete.
> > [Raster MASK present]
> >
> >   
> Apart from the segmentation fault answered by Glynn, I see more problems
> here.
> 
> The nodata value of -32,768 is not valid, effectively discarding nodata
> information, because the range of UInt16 is 0 to 65,535 and -32,768 is
> out of range, i.e. there are no cells with -32,768 in the output
> GeoTIFF. The range of composite_b123 is 0 to 32,767, therefore a
> reasonable nodata value would be anything between 32,768 and 65,535. You
> can try to use r.out.gdal with the options e.g. type=UInt16 nodata=32768
> or type=Int16 nodata=-32768. Generally it seems to be a good idea to
> specify the options type and nodata (if needed) for r.out.gdal
> 
> The next problem I suspect is the export of a raster probably generated
> with r.composite (as the name suggests). This will only be displayed
> with the same colours as in GRASS if the colortable provided with the
> GeoTIFF metadata is properly interpreted. As I have shown previously [1]
> this is not always the case, especially for UInt16, even GRASS struggles
> with the re-import of UInt16 type GeoTIFFs [2]. A safer alternative
> would be to put the three rasters used for r.composite in a group and
> export the group with type=Byte if possible. The resulting GeoTIFF
> should be a RGB image that can be displayed with any image viewer, an
> easy way to check that the three bands are assigned red, green, and blue
> as intended, otherwise swap the order in the ref file.
> 
> I hope that helps
> 
> Markus
> 
> [1] http://trac.osgeo.org/grass/ticket/73#comment:13
> [2] http://trac.osgeo.org/grass/ticket/73#comment:15

Markus,
your attention to details is very much appreciated.

The above reported range is from a composite image created r.composite.
But it was just a test to see whether it works or not. I can't export
any viewable composite (at least for OpenEV with which I work) if max
value exceeds 255. It works if you use levels=x (where x something which
will give a max < 256 --- in my case it was levels=6).

Anyhow, exporting the group of 3 bands with r.out.tiff or r.out.gdal
works but there is something important: I don't like the white
background. I would like to have a black backgroud surrounding my map. I
could not get that really. I think I managed to see that only when I
reduced levels with r.composite. Don't remember right now but I think
rescaling initial bands with range from 0 up to 8000 in to 0 to 255 and
export the group did not work either.

If I am not wrong this has to do with transparency. I was trying all
possible export methods (r.out.gdal, r.out.tiff, r.out.png) but I didn't
nail a good method.

Thank you,
Nikos