[GRASS-dev] lib fn to convert int color number to RGB values?

[Hamish]

Hamish wrote:
> > I am looking for a library function to get the R,G,B values (0-255)
> > for an integer color number which was created with D_parse_color().

Glynn:
> That information isn't available at present.
> 
> Also, the concept of colour numbers is likely to go away entirely in
> 7.x. With the display drivers and raster library using R/G/B colours
> exclusively, the only reason that colour numbers remain was to avoid
> having to re-write all of the modules which parse a colour string to
> an integer.

In that case it would probably be better to rewrite the three color
variables in d.grid* to pass RGBA_color structs instead of color index
integers and not worry about D_number_to_RGB() now. But as it is
missing I think I'll add it anyway, it might be useful during the
transition.

[*] new -c and -f now added to d.grid, hardcoded as black. For
geo-grids the local mark rotation is working but finding confluences is
not as much harder. Also it would be nice to improve rendering of
geogrid lines into one fluid line rather than rough 100*G_plot_line()s.
Could R_cont_abs() be used or would it have to wait for punctuated arcs
in GRASS 7?


H:
> > Is a new D_number_to_RGB(int color, unsigned char &r,&g,&b) fn
> > needed in lib/display/tran_colr.c?
G:
> Yes. E.g.:
> 
> int D_color_number_to_RGB(int color, int &r, int &g, int &b)
> {
>     const struct color_rgb *c;
> 
>     if (color <= 0)
>         return 0;
> 
>     if (color >= ncolors)
>         return 0;
> 
>     c = &colors[color];
>     r = c->r;
>     g = c->g;
>     b = c->b;
> 
>     return 1;
> }

Thanks.
Any reason you use int for the r,g,b type? color.h defines {}color_rgb
as unsigned char, as does gis.h's {}RGBA_Color. I'd like to avoid new
casting issues, and for GRASS 7 would like to settle on one consistent
type rather than the mix of two we have now.
 
> > Or some place better?
> 
> The array which holds the information isn't exported from
> tran_color.c, so the code can't go anywhere else.

ok.


If I pass the colors as a single RGBA_Color struct, I would like to
have a parsing lib fn to replace D_parse_color(). It would call
G_str_to_color() then fill the RGBA_Color struct, like set_last_color()
in d.graph. e.g.:
  G_str_to_RGBA(char* str, RGBA_Color color);


but for GRASS 7 does that belong in libgis? for now RGBA_Color is
defined in gis.h and does not depend on external libs so I'd call it
G_, but as libgis is already bloated I hesitate...



Hamish



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs