From: Simon Buchan (simon_at_[hidden])
Date: 2005-09-27 19:01:55
Adam Badura wrote:
>>So, it seems like an ideal design would be to allow color classes to
>>specialize depending on whether their components are in some sense
>>equivalent. Those that are could offer a component() method, and would
>>require the same type for all 3 components. Those that aren't would
>>not offer a component() method, and consequently would have the
>>freedom to use different types for the different components.
> Yes. Indeed.
> I heard of looping over RGB components but never heared of RGB
> representations with different types (even size is usually the same). So I
> thought to disallow different types for RGB (and CMYK probably also) and to
> allow this where it is realy suitable.
> Its no problem to wrtie classes thet serv "red", "green" and "blue"
> instead of "component". But giving both solutions for RGB for example would
> require (in my opinion) ~double code. I think that large parts of code would
> have to be writen once for "generic" (component()) and once for "not
> generic". This would probably be realized by a specialization of color_rgb
> (model) class for components that suport component and those which do not.
> But because I dont wand to use any inhertiance to be maxiamly sure about
> memory representation and speed I would have to write to separate (but
> giving athe same functions) implementations.
> So I'm not quite sure if its worth in case of RGB. Or do you have any
> proposal of easy solution?
Could I just ask if something like:
for(int i = 0; i < 3; ++i)
if(col[i]*1.2 < col.max) col[i] *= 1.2;
else col[i] = col.max;
is what you mean? Something like this is the only time doing something
to every component over a loop makes sense to me (simpler ops could be
applied directly to the colour), and here you can just assume that the
colour ops are by default clipping (since that makes sense).
col *= 1.2;
Presumably, there would be non-clipping colours as well?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk