std.experimental.color, request reviews
Manu via Digitalmars-d
digitalmars-d at puremagic.com
Wed Jun 24 01:54:51 PDT 2015
On 24 June 2015 at 17:58, Andrea Fontana via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:
>>
>> https://github.com/D-Programming-Language/phobos/pull/2845
>>
>> I'm getting quite happy with it.
>> I think it's a good and fairly minimal but useful starting point.
>>
>> It'd be great to get some reviews from here.
>
>
> Some points about blend/lerp:
>
> - Using operation on rgb components usually doesn't give the expected
> result. It should be done, for example, blending hue saturation and
> brightness, rather than Red, Blue, Green (or at least using toLinear?)
Cast your input to a linear type (or whatever colourspace you prefer)
before lerping. User needs to make the trade-off between efficiency
(approximation) and precision (in linear space).
> - What happens if srcFactor + destFactor != 1? Maybe we should normalize
> srcFactor and destFactor on 0..1 using something like:
> normSrcFactor = srcFactor/(srcFactor+DestFactor);
> normDestFactor = destFactor/(srcFactor+DestFactor);
I don't see any reason they should require to add to one. HDR is a thing.
Lerp is a mathematical function, and while t=[0..1] is conventional,
it's not enforced, or even necessary. I think user should make a
decision to require normalisation.
> - Does it work with RGB only?
No, but like, kinda. Lab interpolates very well (by design).
Technically, all spaces lerp, just that results should be expected
with respect to the colour space you are working in.
I was thinking of removing those functions because they're a bit hard
to define concretely, for some of the reasons you say, and others.
I left them there to gather opinions and comments. Also to identify
missing functions if people find them to add value.
More information about the Digitalmars-d
mailing list