Re: [Boost-users] Boost-users Digest, Vol 2650, Issue 4

Subject: Re: [Boost-users] Boost-users Digest, Vol 2650, Issue 4
From: Nathan Crookston (nathan.crookston_at_[hidden])
Date: 2011-04-27 11:22:55

Hi Curtis and Robert,

On Fri, Apr 22, 2011 at 1:06 PM, Curtis Gehman <curtis2006_at_[hidden]> wrote:
> Sorry for _my_ slow response (I was in Japan). I don't care about colour
> conversions, but I think that these types will convert to integral types
> with scaling unless you add more boilerplate. I added the following -- but
> it may not all have been needed; this was quite a while ago and I was new to
> gil. I also have some remaining conversion problems where I have to rewrite
> expressions to make them compile, but this may be something else. Anyway,
> I'd really like to see native gil support for a complete set of NON-scaling
> types.

<snip partial specializations of channel_multiplier and channel_converter>

> Using only the four typedefs that I provided earlier, I don't see any sign
> that the GIL classes that I'm using are scaling the floats behind the
> curtain.  I haven't been able to follow the details of the metaprogramming
> inside GIL, but I have observed two key facts that suggest that no scaling
> is occuring:
>
> The end result has the scale I expect (without scaling).
> std::less<typename std::iterator_traits<InIter>::value_type> works with
> InIter = gray_float_const_view_t::x_iterator (or y_iterator).

I'm neither Christian nor Lubomir, but I've spent a fair amount of
time with the channel conversion code.  GIL generally doesn't verify
that pixel values are in gamut (too expensive), so it doesn't really
modify anything under the hood.  Robert has identified two places
where there's the potential for strange conversions --
channel_multiply and channel_convert.  Channel multiply is used inside
GIL to convert from one colorspace to another, and the problem occurs
when normalizing the result by the maximum channel value (in this
case, std::numeric_limits<float>::max()).  channel_convert is similar.
 So avoiding the conversion code should be all that's necessary to
prevent unwanted scaling.

I'll admit that I'm suspicious of the correctness of Robert's
color_convert overloads -- if you don't want color conversion to
happen perhaps you could add a static assert to verify they're not
instantiated?

HTH,
Nate