Re: [boost] Interest in color library.

From: Geoffrey Romer (geoff.romer_at_[hidden])
Date: 2005-09-25 11:54:55

I have a question about this approach: what is the purpose of using
templates? What operations do you see as being performed on colors
polymorphically?

In other words, the only advantage I see to this templated approach
would be to allow clients to write templated functions/classes which
could operate on arbitrary color types, but I can't think of any
interesting functions that would work with your approach.

(P.S. sorry if this has been addressed earlier in the thread; I only
just joined the list)

On 9/25/05, Adam Badura <abadura_at_[hidden]> wrote:
>     Actually, to be mor acurate I do something like this:
>
> struct rgb_8888 {
>     unsigned char _r : 8;
>     unsigned char _g : 8;
>     unsigned char _b : 8;
>     unsigned char : 8;
>     unsigned char red() const {/*...*/}
>     void red(unsigned char r) {/*...*/}
>     unsigned char green() const {/*...*/}
>     void green(unsigned char r) {/*...*/}
>     unsigned char blue() const {/*...*/}
>     void blue(unsigned char r) {/*...*/}
>     unsigned char component(unsigned int index) const {{/*...*/}
>     unsigned char& component(unsigned int index) {/*...*/}
> };
>
> template<typename Components> class component_traits {
> public:
>     typedef ? component_type;
>     static const int components;
>     static const int indexes[components];
>     static const component_type min[components];
>     static const component_type max[components];
> };
>
> and than specialization could look like this:
>
>     component_traits<rgb_8888>::component_type === usnigned char
>     component_traits<rgb_8888>::min === [0, 0, 0]
>     component_traits<rgb_8888>::max === [255, 255, 255]
>
>     component_traits<rgb_double>::component_type === double
>     component_traits<rgb_8888>::min === [0.0, 0.0, 0.0]
>     component_traits<rgb_8888>::max === [1.0, 1.0, 1.0]
>
> and so on...
>
>     The base concept is that "color" class (like for example "color_rgb",
> "color_yuv") akes car of color model or color space things, and therefore
> must be a template (polymorphism could be used as well, but code speed is
> here very important [graphic manipulation!] so I decidet: templates)
> parametrized with "components type". This "component type" takes care for
> serving color data lika values of channels. "components type" knows exact
> types and palcement in memory.
>     So if you want to use your own format in wich all channels have 10 bits
> size and all is stored in double word you just write simple components type:
>
> struct your_rgb {
>     unsigned int _r : 10;
>     unsigned int _g : 10;
>     unsigned int _b : 10;
>     unsigned int : 2;
>     unsigned int red() const { return _r;}
>     void red(unsigned int r) {_r = r;}
>     unsigned int green() const {return _g;}
>     void green(unsigned int r) {_g = g;}
>     unsigned int blue() const {return _b;}
>     void blue(unsigned int r) {_b = b;}
>     unsigned int component(unsigned int index) const {/*...*/}
>     unsigned int& component(unsigned int index) {/*...*/}
> };
>
>     component_traits<your_rgb>::component_type === usnigned int
>     component_traits<your_rgb>::indexes === [0, 1, 2]
>     component_traits<your_rgb>::min === [0, 0, 0]
>     component_traits<your_rgb>::max === [2^10, 2^10, 2^10]
>
> in this case writing "component" could be a little difficult however youy
> can be sure taht "color class" will not call your functions with improper
> arguments by it self (actually to speed up code control can be turned of and
> the user may give wrong arguments, but if someone wants to spoild program he
> will do it anyway). Also you dont have to actualy retrun type
> "component_traits<your_rgb>::component_type" but type that behaves like it
> were this type.
>     (component_traits::indexes is to allow another order of data not only
> RGB but for example also BGR, "color class" always [to ease using] uses
> index 0 for R, 1 for G and 3 for B, this is problem for "compoinent"
> function, to avoid using "swich" in this function, what would make its
> execution longer, indexes are staticly mapped, so for BGR this array would
> look like:
>
>     component_traits<bgr>::indexes === [2, 1, 0]
>
> and "color class" still uses its indexes, but in calls to components
> "component" maps them (staticly) to right indexes.
>     Hope everything is understandable... :)
>
>     But now I encountered another problem, which I post in differen message.
>
>     Adam Badura
>
> "Rob Stewart" <stewart_at_[hidden]> wrote in message
> news:200509201642.j8KGgYci010670_at_shannonhoon.balstatdev.susq.com...
> > From: "Adam Badura" <abadura_at_[hidden]>
> > >
> > >     For now I think taht template representation would be best. What i
> mean
> > > is for example
> > >
> > >     struct rgb_8888 {
> > >         unsigned char r : 8;
> > >         unsigned char g : 8;
> > >         unsigned char b : 8;
> > >         unsigned char : 8;
> > >     };
> > >
> > >     struct yuv_422 {
> > >         unsigned char y : 4;
> > >         unsigned char u : 2;
> > >         unsigned char v : 2;
> > >     };
> > >
> > >     template<typename Components> class color {
> > >     private:
> > >         Components mComponents;
> > >     };
> >
> > I haven't been following your discussion but this looks suspect.
> >
> > First, you'd need to specialize color for each color structure
> > type so the color member functions know how to do the right
> > thing.  That obviates what I think you're trying to do with the
> > template.
> >
> > Second, all code using colors must be either templated on color
> > type or will only work with one type.  That is, including the
> > representation in the type (color<yuv_422>) means that functions
> > must be written in terms of color<something> and can't work with
> > color<something_else_entirely>.
> >
> > To fix the former problem, you might consider that the color
> > template can provide higher level functionality from primitives
> > supplied by a policy type.  Thus, your Components type would have
> > to provide represention plus primitives.
> >
> > To fix the latter problem, you would need an ABC from which
> > color<T> derives.
> >
> > HTH
> >
> > --
> > Rob Stewart                           stewart_at_[hidden]
> > Software Engineer                     http://www.sig.com
> > Susquehanna International Group, LLP  using std::disclaimer;
> > _______________________________________________
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>