scott <sco### [at] scottcom> wrote:
> > Later however, I found the time to revisit the issue, and found that
> > good results /can/ be obtained; the key is to split up the colour
> > information into brightness (i.e. the weighted sum of the colour
> > channels) and chroma (i.e. the relative balance between the colour
> > channels), interpolate the brightness non-linearly and the chroma
> > linearly, and then re-combine the two properties into the new result colour.
>
> Never realised that this had been implemented - great work!
>
> What chroma values are you using?

Actually I'm just using the RGB values, normalized to identical brightness, so
it's a particular slice of RGB space if you will. Not sure what official chroma
format that corresponds to.

While this means that I'm doing the interpolation on three values instead of two
(which might seem like doing extra work), on the other hand it avoids the
computations required to convert from RGB to chroma and back, so I guess it
might even be faster this way -- and I think it's more straightforward and
easier to understand, at least for people who don't wrap their head around
colour spaces on a daily basis.

It also has the benefit of being easily adaptable to a spectral colour model,
which I tend to keep in the back of my head when working on POV-Ray's internal
colour maths.


> Have you heard of MacAdam ellipses?
>
> https://en.wikipedia.org/wiki/MacAdam_ellipse
>
> My idea is that if you convert your chroma values to a colour space with
> almost equal-sized MacAdam's ellipses, you can then just do a linear
> interpolation in that colour space, and you should get "perfect" hue
> blends for any colours.

That might be a neat addition, but at present I don't think it's really
necessary. There's plenty of stuff ranking higher on the agenda right now.

Feel free to do some research on this topic though -- while I don't have much
time to invest into this matter, I'm still interested in it.

Post a reply to this message