[GRASS-user] GRASS export GeoTiff adventure... continued :-)

Sun Aug 3 11:49:44 EDT 2008

Markus,
I appreciate it that you clarify the details.

On Sun, 2008-08-03 at 17:22 +0200, Markus Metz wrote:
> 
> 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:
> line 208
> hCT = GDALCreateColorTable(GPI_RGB);
> line 210
> GDALSetRasterColorTable(hBand, hCT);

Did you already filed a ticket for that?

> > 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 [1] (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.

So nodata=255 does not mean "loss of information"?
The red, green, blue channels are 8-bit (2 high 8 = 256, values counting
from 0 up to 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
> XXX: 0,0,0,255
> with XXX going from 0 to 255 in case of Byte type, this is an all-black 
> colour table.

One example report for an image imported with r.in.gdal, MASKed,
r.colors -r, r.out.gdal as a group with nodata=-9999:
Driver: GTiff/GeoTIFF
Files: simmern_2624_5548.tiff
       simmern_2624_5548.tiff.aux.xml
Size is 2500, 2500
Coordinate System is:
PROJCS["Transverse Mercator",
    GEOGCS["bessel",
        DATUM["Deutsches_Hauptdreiecksnetz",
            SPHEROID["Bessel 1841",6377397.155,299.1528128000008,
                AUTHORITY["EPSG","7004"]],
            AUTHORITY["EPSG","6314"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",6],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",2500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (2624000.000000000000000,5550000.000000000000000)
Pixel Size = (0.800000000000000,-0.800000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  ( 2624000.000, 5550000.000) (  7d43'56.88"E, 50d 4'28.10"N)
Lower Left  ( 2624000.000, 5548000.000) (  7d43'54.54"E, 50d 3'23.39"N)
Upper Right ( 2626000.000, 5550000.000) (  7d45'37.42"E, 50d 4'26.59"N)
Lower Right ( 2626000.000, 5548000.000) (  7d45'35.05"E, 50d 3'21.88"N)
Center      ( 2625000.000, 5549000.000) (  7d44'45.97"E, 50d 3'54.99"N)
Band 1 Block=2500x1 Type=Byte, ColorInterp=Red
  NoData Value=-9999
  Metadata:
    COLOR_TABLE_RULES_COUNT=5
    COLOR_TABLE_RULE_RGB_0=0.000000e+00 4.640000e+01 255 255 0 0 255 0
    COLOR_TABLE_RULE_RGB_1=4.640000e+01 9.280000e+01 0 255 0 0 255 255
    COLOR_TABLE_RULE_RGB_2=9.280000e+01 1.392000e+02 0 255 255 0 0 255
    COLOR_TABLE_RULE_RGB_3=1.392000e+02 1.856000e+02 0 0 255 255 0 255
    COLOR_TABLE_RULE_RGB_4=1.856000e+02 2.320000e+02 255 0 255 255 0 0
Band 2 Block=2500x1 Type=Byte, ColorInterp=Green
  NoData Value=-9999
  Metadata:
    COLOR_TABLE_RULES_COUNT=5
    COLOR_TABLE_RULE_RGB_0=0.000000e+00 4.680000e+01 255 255 0 0 255 0
    COLOR_TABLE_RULE_RGB_1=4.680000e+01 9.360000e+01 0 255 0 0 255 255
    COLOR_TABLE_RULE_RGB_2=9.360000e+01 1.404000e+02 0 255 255 0 0 255
    COLOR_TABLE_RULE_RGB_3=1.404000e+02 1.872000e+02 0 0 255 255 0 255
    COLOR_TABLE_RULE_RGB_4=1.872000e+02 2.340000e+02 255 0 255 255 0 0
Band 3 Block=2500x1 Type=Byte, ColorInterp=Blue
  NoData Value=-9999
  Metadata:
    COLOR_TABLE_RULES_COUNT=5
    COLOR_TABLE_RULE_RGB_0=3.400000e+01 7.320000e+01 255 255 0 0 255 0
    COLOR_TABLE_RULE_RGB_1=7.320000e+01 1.124000e+02 0 255 0 0 255 255
    COLOR_TABLE_RULE_RGB_2=1.124000e+02 1.516000e+02 0 255 255 0 0 255
    COLOR_TABLE_RULE_RGB_3=1.516000e+02 1.908000e+02 0 0 255 255 0 255
    COLOR_TABLE_RULE_RGB_4=1.908000e+02 2.300000e+02 255 0 255 255 0 0

> 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: 
> ftp.remotesensing.org/pub/libtiff/doc/TIFF6.pdf

Thats a good source.

> 
> ESRI's capability reading GeoTIFF: limited, check
> http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Technical_specifications_for_raster_dataset_formats
> 
> 
> Regards,
> 
> Markus