Hi Curtis and Robert,
On Fri, Apr 22, 2011 at 1:06 PM, Curtis Gehman
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
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