Lubomir Bourdev wrote:
Pavel's concern was that every channel permutation (like BGR, for example) requires creating a new color space, which seems inflexible.
I think his concern is in part a misunderstanding based on terminology. In both GIL and his example, to support BGR we have to write some new code - in GIL we call it "derived color space" while Pavel calls it "layout"
"Derived color space" is only a small subset of "layout".
But let me point out that: 1. Adding a channel permutation (like BGR) requires very little new code 2. All channel-level support (assignment, copy-construction, etc) will automatically work for BGR 3. All the algorithms that operate on RGB will automatically work for BGR (unless explicitly prevented).
Ok. You've pointed out how make a new permutation of any colorspace, but don't you think it's kind of too-level stuff and should be automated? I still think you approach is less flexible: 1. I can hardly imagine how you would support all RGB565, RGB555, RGB888 etc. with your RGB class or BGR? 2. Perhaps with your "semantic channels" you can create interleaved RGB image, but do you really think that mixing "colorspace" stuff and how it is organized in memory is good?
In detail: ___1. Adding a channel permutation (like BGR) requires very little new code The only changes that you need to do to make BGR are more or less the following: struct bgr_t : public rgb_t {}; template <typename T> struct color_base<T,bgr_t> { T blue,green,red; color_base() {} color_base(T v0, T v1, T v2) : blue(v0),green(v1),red(v2) {} template <typename T1, typename C1> color_base(const color_base<T1,C1>&);
template <int N> T& semantic_channel(); template<> T& semantic_channel<0>() { return red; } template<> T& semantic_channel<1>() { return green; } template<> T& semantic_channel<2>() { return blue; } };
The only catch is that it is illegal to create full specialization (semantic_channel<0>) inside a partially specialized class, which requires us instead to use a channel_accessor class.
You could use T& semantic_channel(boost::mpl::int_<0>) { return red; } and in some "very" base class template<typename U> void semantic_channel(U) { //Something's wrong with client code if it've triggered BOOST_STATIC_ASSERT(sizeof(U) != 0); }
We are investigating a more compact representation, for example using mpl::vector_c<int,2,1,0>. Once you make it working and add some generalization be sure you'll get my layout ! ;)
between RBG and CMYK (the RGB to CMYK code will be reused.) Another example - the I/O code will allow you to read into an RBG image, (as long as RGB is supported for the given file format).
About IO: If I understand correctly you in Adobe have "not open-source" IO GIL stuff? Is it correct and would that two versions be the same one day? -- Pavel Chikulaev