[GRASS5] r.in.gdal and colors

[Glynn Clements]

Frank Warmerdam wrote:

> > AFAICT, r.in.gdal only writes a color map if the image source has a
> > color map.  This is not usually the case for RGB type images.
> > The default color map in GRASS is a rainbow...
> 
> Eric / Russell,
> 
> Do you or others who get the Zen of GRASS better than I think r.in.gdal ought
> to be writing a greyscale colortable for imported files without a colormap?
> Should it only do this for multiband images?  Only for 8bit images?

For RGB "image" files, it should be writing a greyscale colour table. 
Otherwise, there's no way for e.g. d.rgb to reliably determine the
interpretation of the cell values; d.rgb (et al) shouldn't just assume
a 0-255 range.

E.g. r.in.png preserves the original bit depth; it doesn't coerce the
data to 8 bits. So, if the data is 4-bpp, the output map will use
categories 0-15, with a colour table which maps 0 to black and 15 to
white. Also, if the sBIT tag is present, it will use that information;
e.g. if the data is stored as 4-bpp, but the sBIT record says that it
was promoted from 3-bpp, then the resulting map will use categories
0-7.

FWIW, both "r.in.ppm -b" and r.in.png write greyscale colour tables.

For JPEG data, there would ideally be an option to output the raw
Y/Cr/Cb channels at their individual resolutions (the Y channel
typically has twice the spatial resolution in each direction), rather
than converting to R/G/B. Similarly for any other colour spaces which
might plausibly be used (the libjpeg documentation indicates that it
supports CMYK and YCCK directly, and supports "pass-through" of other
spaces).

Other issues include gamma correction (i.e. whether this should be
performed by modifying the actual cell values or the colour table),
and images with more than 8 bits-per-pixel (cell values aren't
restricted to 0-255, but colour table entries are).

-- 
Glynn Clements <glynn.clements at virgin.net>