[GRASS-user] GRASS export GeoTiff adventure... continued :-)
markus_metz at gmx.de
Sun Aug 3 11:42:23 EDT 2008
Nikos Alexandris wrote:
> I think I solved my problem by removing color tables
That doesn't solve the problem, I learned. If you remove the associated
colour table, r.out.gdal writes a completely black colour table.
Applications that read the colour table will consequently show a
completely black image, but the true values are still there. I think
this is a bug in r.out.gdal. If there is no colour table, no colour
table should be written to the output file at all, because only then
would other applications use the real values to display the image. Fixed
after removing lines 208 and 210 in raster/r.out.gdal/main.c and
compiling again, GRASS 6.3.0
The lines read:
hCT = GDALCreateColorTable(GPI_RGB);
> I can see the exported images in QGIS, OpenEV. However, this sets 255 as
> "nodata" which is something that I don't want. Whenever I set a nodata
> value out of range  (for Byte that would be smaller than 0 or bigger
> than 255 --- right?) I can't see propely the exported tiffs in either
> QGIS or OpenEV.
255 is the default nodata value. r.out.gdal does the right thing if it
replaces a specified nodata value that is out of range with 255.
> In QGIS nothing appears and in OpenEV the individual
> tiff's (loading with openev -h *.tiff) "flash" and dissapear to leave a
> black screen.
See above, the colour table might be all black. Check with gdalinfo, if
all colour table entries read something like
with XXX going from 0 to 255 in case of Byte type, this is an all-black
If there is no colour table, the real values are used.
The "flash" in openev appears because openev needs a bit of time to
apply the all-black colour table.
More on INTERLEAVE=PIXEL
For single band images, there is no difference between INTERLEAVE=PIXEL
and INTERLEAVE=BAND. TIFF specs from 1992:
ESRI's capability reading GeoTIFF: limited, check
More information about the grass-user