[GRASS5] r.in.gdal and colors

[Eric G. Miller]

On Wed, Feb 05, 2003 at 11:43:59PM -0500, Russell Nelson wrote:
> Eric G. Miller writes:
>  > Of course, min/max per band isn't really correct for RGB imagery
>  > since it can skew the colors, but we can't assume 0-255 with 32-bit
>  > ints.
> 
> If r.in.gdal is reading an image with 24 bits per pixel (e.g. a jpg),
> and it writes those 24 bits into three 8-bit-deep rasters, then it
> seems to me that a greyscale colortable of 0-255 is the ONLY right
> thing to do.

GRASS has one integer CELL type (32 bits wide).  However, I think it's
probably true that r.in.gdal could be improved.

(1) Use G_set_cell_format() before writing out each band.  This sets the
    max bytes which is used to save space (1..sizeof(CELL)).  From the
    looks of it, this could be pretty straight forward from GDAL (though
    I don't know the GDAL API).

(2) Write grey scale color rules for each band:
    (a) If 8 bits / band, write 0-255 grey scale color rule. [1]
    (b) If > 8 bits / band, write min/max grey scale color rule?

(3) Set RED/GREEN/BLUE imagery interpretation if/when known for
    imagery groups.

    Apparently, there's no API to set the colors programatically?
    But, libes/imagery/ask_colors.c has:

   /**************************************************************
    * step 5 - finish
    *  set the colors
    */
       ref->red.n = r;
       ref->grn.n = g;
       ref->blu.n = b;

    Where "r", "g", and "b" are the integer indices for the respective
    bands of the imagery group...

[1] r.in.tiff does this, but it is much less flexible than r.in.gdal for
    image formats and doesn't even mess with the imagery stuff.

-- 
echo ">gra.fcw at 2ztr< eryyvZ .T pveR" | rot13 | reverse