Re: [boost] Interest in color library.

From: Adam Badura (abadura_at_[hidden])
Date: 2005-09-27 11:07:45

    But this in deed does have some disadvantages. Previous I had functions
like

    component_type component(const int index) const;
    component_type& component(const int index);

or simple [] operator for getting components. This allows to easy write code
which preforms the same operation on each color component (for example
interpolates color by interpolating R than G than B...). Now (when
components could have different types) writing such a function is almost
impossible because you must return one specific type (inheritance is
imposibble due to speed overhead and use of basic types).
    You can still write somethink like this

    union types {
        red_type red;
        green_type green;
        blue_type blue;
    };

    types component(const int index) const;
    void component(const int index, const types value);

but also this would produce worse (in readablity) code becouse instead of

    color.component(0) = 128;

you will have to write

    color.component(0).red = 128;

which is not intuitiv (someone not knownin library would by puzzeld by 0 in
argument if you specify "red").
    Not mentioning lack of safty and eleganc caused by unions...

    So to sum up I am considarating whether to add feature of different
types or at least in RGB which as I think, is not used in this way, besause
this feature has to high cost.

    Adam Badura

> Adam Badura wrote:
> >     As I rewrite some parts of code for color library I noticed silent
> > assumption I made. Namely I assumed that all color components are the
same
> > type. But must it be this way?
> >     Does anyone use types like:
> >
> > struct rgb {
> >     float r;
> >     unsigned char b;
> >     signed char g;
> > };
> <snip>
> >     So? Allow diffrent types or not?
> Although it wouldn't be terribly useful for RGB, other representations
> may (will?) benifit from this, as a simple example, L*a*b* is
> represented as an /unsigned/ Lightness, and two /signed/ components, a
> and b.  Someone may wish to represent (or is forced to represent) HSV
> values with floating Hue, but integral Saturation and Value.  Perhaps a
> specialised graphics application would wish to use (custom?) fixed point
> types and floating point types in the same value (If consistancy of
> calculations for Saturation and Value are needed, but accuracy is more
> important for Hue, for example)
> In short, I say yea!
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>