In another thread it was stated that Pixel###::unpremultiply() yields inaccuracies when recovering the original value. But Colour::interpolatedWith inexplicably converts to premultiplied RGB, performs the blending operation, and then unpremultiplies. Wouldn’t this lead to inaccuracies?
Well, interpolating premultiplied colours gives a very different result to using unpremultiplied ones - and for the correct results you need to premultiply them. Not sure why that’s true, but it’s definitely how it works!
But remember that the inaccuracies are only evident when you boost a colour’s alpha level. In this case, the output alpha is never greater than the input ones, so I don’t think you’d get any problems. I guess it might be possible to rewrite the maths so that the premultiply/tween/unpremultiply stages are all combined into one equation, and then it’d have a better chance of maintaining accuracy, but I really don’t think it’s worth worrying about.
Well on further analysis, interpolatedWith is only called from ColourGradient::getColourAtPosition, which itself is only called from LowLevelGraphicsPostScriptRenderer::fillPath. So any inaccuracies would occur with JUCE Postscript output of paths filled with gradients, and any user defined code which calls interpolatedWith().
Yes, but even then any inaccuracy would only be evident if you deliberately increase the alpha of the resulting colour before using it.