Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2006-10-27 16:20:03

Lubomir Bourdev wrote:

>> Thus, pixel references (for both types of pixels) yields
>> "pixel<>" objects as a closest match to a "pixel rvalue",
>> even though in the case of a planar pixel such object is
>> really a deep copy of the pixels color.
> In the case of a planar pixel we also use the same object for rvalue
> and lvalue - the planar reference.


> It is not a deep copy of the pixel's color (it contains references to
> each channel), but it is convertible to a deep copy.
Right, I knew the planar reference was a not a deep copy.
But it is converted to pixel<> right? (because pixel_value_type is that)
In which case then? I figured it was when you access an rvalue for the
planar pixel.

>> --------------------------------------------------------------
>> ----------------
>> If all that is correct, or mostly correct, then I would suggest:
> Yes your description was correct.
>> (1) rename the pixel<> class as color<>.
>> (2) rename the planar_ptr<> class as planar_pixel_iterator<>
>> (3) rename the planar_ref<> class as planar_pixel_handle<>
> I am hesitating to do (1). Using color is very strange when inside the
> image. Color iterators? Looking at several other libraries I see the
> terms pixel, pixel iterators, used frequently...
I understand that, but...

If you have a planar pixel, there is some operation by which you obtain its
*value* as represented by the class pixel<> right? At least that's what I
infer from the fact that a planar pixel reference has a nested type named
"pixel_value_type" defined to be "pixel<>".
But that pixel<> object, when obtained from a planar pixel, is representing
its color isn't it? I mean, it's not *the* pixel AFAICT. In contains copies
of the channel values. So the class used for _this_ should be named color<>

But well, I can see the issues in dropping pixel<>.

If C++ had template typedef I would suggest to keep both pixel<> and

> (3) Good suggestion, but maybe we could change to
> planar_pixel_reference. I don't want to introduce the term "handle".
> Reference is already used in this context, for example "reference
> proxy" object is a common term.
Ya well, OK, I supposed that if the need for just a wrapper is sufficiently
explained in advanced then users would know what a pixel reference really is
when they see the term.

I wouldn't mind if you wanted to use the description I gave about these. :)


Fernando Cacciola

Boost list run by bdawes at, gregod at, cpdaniel at, john at