|
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.
Ha OK
> 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<>
IMO.
But well, I can see the issues in dropping pixel<>.
If C++ had template typedef I would suggest to keep both pixel<> and
color<>.
> (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. :)
Best
-- Fernando Cacciola SciSoft http://fcacciola.50webs.com/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk