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

[Glynn Clements]

Hamish wrote:

> > > 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.

It's unusual to have variables smaller than an "int". "short" and
"char" are normally reserved for array indices and structure fields,
where you may want to conserve space, either because you have an array
which may contain thousands of elements or a structure which you want
to fit into a 32-bit word.

If you want the values stored in variables, the variables are
typically going to be integers, so you may as well pass pointers to
the variables themselves. Note that G_str_to_color() uses ints.

If you want the values stored in an RGBA_Color, it would make more
sense to pass a pointer to the structure rather than to individual
fields.

AFAICT, there's no fundamental reason why tran_color.c can't be
changed to use RGBA_Color instead of the color_rgb structure.

> > > 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...

I would be inclined to simply replace color_rgb with RGBA_Color.

Also, I'm not sure why we have lib/gis/named_colr.c with its own table
of named colours, but using floats for the R/G/B components.

All of this should really be harmonised; I'm just wondering whether
it's too late to do it for 6.4.

-- 
Glynn Clements <glynn at gclements.plus.com>