[GRASS-dev] Problems with r.out.gdal byte export: colors modified in RGB multilayer GeoTIFF

Hi,

I am currently processing satellite data > 8bit and created a nice
"natural color" RGB composite (channels separated).
Using the #map operator of r.mapcalc I could successfully reduce each
channel to 8 bit, after i.colors.enhance the respective RGB composite
looks almost identical.
The scope is to process the data in GRASS GIS, then export them for a
performant OGC Web service.

So far so nice. Now, exporting it as a multilayer GeoTIFF (I made a
group of the 3 channels using i.group, then gave that as input to
r.out.gdal) leads to yellowish colors which are not the same any more.
Adding the -c flag did not help.

GRASS 7.1.svn (utm48n): > r.out.gdal -c input=rgb_group
output=rgb_8bit_flag_c.tif
Checking GDAL data type and nodata value...
100%
Using GDAL data type <Byte>
100%
Using GDAL data type <Byte>
100%
Using GDAL data type <Byte>
Exporting raster data to GTiff format...
100%
100%
100%
r.out.gdal complete. File <rgb_8bit_flag_c.tif> created.
[Raster MASK present]

Screenshot attached (top left: original; top right: reduced to 8 bit;
low: exported multilayer-RGB shown in QGIS).

I also tried the HFA driver, same issue.

What's the trick?

thanks
Markus

(attachments)

sat_rgb_16bit_8bit_GRASSGIS_8bit_QGIS.jpg

I recently experienced some buggy image color table management by Qgis,
did not dig much deeper. Sorry if my case may be the exact inverse of
yours, but I finally did it to obtain a more "faithful" color rendering:

- composited an initial 3-band image
  r.composite [...]
- then exported it with
  r.out.gdal [...] format=GTiff type=UInt16
- and expanded it again to a 3-band rgb image via :
  gdal_translate -expand rgb [...]

Anyway, since Qgis Lyon, we have some trouble wih image color
management.

Yours,
V.

Le mercredi 10 février 2016 à 10:05 +0100, Markus Neteler a écrit :

Hi,

I am currently processing satellite data > 8bit and created a nice
"natural color" RGB composite (channels separated).
Using the #map operator of r.mapcalc I could successfully reduce each
channel to 8 bit, after i.colors.enhance the respective RGB composite
looks almost identical.
The scope is to process the data in GRASS GIS, then export them for a
performant OGC Web service.

So far so nice. Now, exporting it as a multilayer GeoTIFF (I made a
group of the 3 channels using i.group, then gave that as input to
r.out.gdal) leads to yellowish colors which are not the same any more.
Adding the -c flag did not help.

GRASS 7.1.svn (utm48n): > r.out.gdal -c input=rgb_group
output=rgb_8bit_flag_c.tif
Checking GDAL data type and nodata value...
100%
Using GDAL data type <Byte>
100%
Using GDAL data type <Byte>
100%
Using GDAL data type <Byte>
Exporting raster data to GTiff format...
100%
100%
100%
r.out.gdal complete. File <rgb_8bit_flag_c.tif> created.
[Raster MASK present]

Screenshot attached (top left: original; top right: reduced to 8 bit;
low: exported multilayer-RGB shown in QGIS).

I also tried the HFA driver, same issue.

What's the trick?

thanks
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Hi,

On Wed, Feb 10, 2016 at 10:23 AM, Vincent Bain <bain@toraval.fr> wrote:

I recently experienced some buggy image color table management by Qgis,
did not dig much deeper. Sorry if my case may be the exact inverse of
yours, but I finally did it to obtain a more "faithful" color rendering:

- composited an initial 3-band image
        r.composite [...]
- then exported it with
        r.out.gdal [...] format=GTiff type=UInt16
- and expanded it again to a 3-band rgb image via :
        gdal_translate -expand rgb [...]

Thanks for the tip. We tried and the colors are better but a black "no
data" area came back which I managed to remove in GRASS GIS.
How complicated :slight_smile:

Anyway, since Qgis Lyon, we have some trouble wih image color
management.

We checked and the yellowish white also shows up in Geoserver. So I
guess it is a GDAL/GeoTIFF issue at this point.
Perhaps worth a GDAL ticket?

Markus

Le lundi 22 février 2016 à 20:43 +0100, Markus Neteler a écrit :

but a black "no data" area came back

couldn't you have managed this issue with gdal_translate -a_nodata
option ?

V.

On Mon, Feb 22, 2016 at 9:04 PM, Vincent Bain <bain@toraval.fr> wrote:

Le lundi 22 février 2016 à 20:43 +0100, Markus Neteler a écrit :

but a black "no data" area came back

couldn't you have managed this issue with gdal_translate -a_nodata
option ?

Unfortunately not because it will set any 0 to nodata (even in the
image, not only at the border)...

Markus