Re: [boost] Interest in color library.

27 Sep 2005


      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