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 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).
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
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?
