Re: [boost] GIL - is there interest for an image library in Boost?

From: Pavel Chikulaev (pavel.chikulaev_at_[hidden])
Date: 2006-06-20 14:00:32

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 YCbYr 4:4:4, 4:2:2, 
4:2:1, 4:2:0, etc. (Especially 4:2:0 one ;) without redutant data)
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