Bug 150940 - Color interpolation for colors with alpha incorrect (gradients)
Summary: Color interpolation for colors with alpha incorrect (gradients)
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: Safari 9
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
: 156105 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-11-05 13:06 PST by Christian Schnorr
Modified: 2017-01-11 11:30 PST (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Schnorr 2015-11-05 13:06:04 PST
Currently the following gradients produce different results despite they should render the same:
 - opaque black to transparent black
 - opaque black to transparent white
 - opaque black to transparent anything

All transparent anythings are in fact the same color, a clear color, no matter what the underlying RGB components say. It seems all four components are currently linearly interpolated, resulting in a very odd gradient -- the second one has a semitransparent gray in the middle. For semitransparent endpoint colors we have the same issue: their RBG components affect the interpolated colors too much, in an unnatural way.

No matter in which color space colors are interpolated, their components should be weighted according to their alpha component.

Firefox seems to use the following weighted approach, producing a much more visually appealing gradient:

float r3 = (r1 * a1 * (1.0 - fraction) + r2 * a2 * fraction) / ((1.0 - fraction) * a1 + fraction * a2);
float g3 = (g1 * a1 * (1.0 - fraction) + g2 * a2 * fraction) / ((1.0 - fraction) * a1 + fraction * a2);
float b3 = (b1 * a1 * (1.0 - fraction) + b2 * a2 * fraction) / ((1.0 - fraction) * a1 + fraction * a2);
float a3 = a1 * (1.0 - fraction) + a2 * fraction;
Comment 1 Simon Fraser (smfr) 2015-11-05 21:23:22 PST
This is because we don't interpolate gradients in non-premultiplied colors, because CG can't do this yet.
Comment 2 Christian Schnorr 2015-11-06 03:17:46 PST
What do you mean by 'CG can't do this yet'?
It is obviously possible...

(In reply to comment #1)
> This is because we don't interpolate gradients in non-premultiplied colors,
> because CG can't do this yet.
Comment 3 Darin Adler 2015-11-06 08:22:12 PST
The OS X and iOS graphics framework, Core Graphics, that WebKit uses to draw on those operating systems has a gradient feature that does not have a mode where it properly handles this. If we wanted to fix this problem in WebKit without waiting for the Core Graphics we would have to write a new gradient implementation that bypasses the Core Graphics Framework. Our plan is to instead ask Apple to add this feature to the Core Graphics framework.
Comment 4 Christian Schnorr 2015-11-06 08:37:58 PST
(In reply to comment #3)
> The OS X and iOS graphics framework, Core Graphics, that WebKit uses to draw
> on those operating systems has a gradient feature that does not have a mode
> where it properly handles this. If we wanted to fix this problem in WebKit
> without waiting for the Core Graphics we would have to write a new gradient
> implementation that bypasses the Core Graphics Framework. Our plan is to
> instead ask Apple to add this feature to the Core Graphics framework.

Ah, I see. So is this a known/confirmed issue? One may argue for both approaches of drawing such a gradient.

How does the collaboration with Apple work in such scenarios? Who even decides who's right and who's wrong? Is there a specification on how these gradients should be drawn?
Comment 5 Darin Adler 2015-11-06 08:49:10 PST
(In reply to comment #4)
> So is this a known/confirmed issue?

Yes. Simon personally contacted the team at Apple responsible for Core Graphics, a while back, to let them know about this issue.
Comment 6 Simon Fraser (smfr) 2015-11-06 08:52:44 PST
(In reply to comment #4)
> How does the collaboration with Apple work in such scenarios? Who even
> decides who's right and who's wrong? Is there a specification on how these
> gradients should be drawn?

This is specified by CSS: <https://drafts.csswg.org/css-images/#gradients>

"with the interpolation taking place in premultiplied RGBA space"

but that text is expected to change once Mac and iOS can support interpolation in non-premultiplied.
Comment 7 Christian Schnorr 2015-11-06 09:49:27 PST
> "with the interpolation taking place in premultiplied RGBA space"

> but that text is expected to change once Mac and iOS can support
> interpolation in non-premultiplied.

Mh, I'm a little confused now as I'm not quite familiar with this terminology. Is interpolation in premultiplied RGBA what we are seeing now or what would be the correct thing to do? Why would that text change once Core Graphics decides to ship a fix for this bug?
Comment 8 Simon Fraser (smfr) 2015-11-06 10:38:33 PST
(In reply to comment #7)
> > "with the interpolation taking place in premultiplied RGBA space"
> 
> > but that text is expected to change once Mac and iOS can support
> > interpolation in non-premultiplied.
> 
> Mh, I'm a little confused now as I'm not quite familiar with this
> terminology. Is interpolation in premultiplied RGBA what we are seeing now
> or what would be the correct thing to do?

That's what you're seeing now. Transparent red in premultiplied color just becomes transparent, so any time you interpolate from it you end up with grayish intermediate values.

> Why would that text change once Core Graphics decides to ship a fix for this bug?

Because all browsers would then be able to interpolate in non-premultiplied color, and the CSS working group would change the text (at least for the next level of the spec).
Comment 9 Christian Schnorr 2015-11-06 10:58:58 PST
> > Mh, I'm a little confused now as I'm not quite familiar with this
> > terminology. Is interpolation in premultiplied RGBA what we are seeing now
> > or what would be the correct thing to do?
> 
> That's what you're seeing now. Transparent red in premultiplied color just
> becomes transparent, so any time you interpolate from it you end up with
> grayish intermediate values.

Sorry if this is really obvious and I am missing something, but that makes only little sense to me.

I am currently seeing this behavior in Safari:
[opaque black (0,0,0,1)] => [semitransparent dark red (128,0,0,0.5)] => [transparent red (255,0,0,0)] (all components interpolated linearly)

However, I think it should look like this: (and it does in Firefox)
[opaque black (0,0,0,1)] => [semitransparent black (0,0,0,0.5)] => [transparent black (0,0,0,0)] (color components weighted with alpha)

Your description ("so any time you interpolate from it you end up with grayish intermediate values") sounds like the latter is what you call interpolation in premultiplied RGBA, however you are also stating that what I am currently seeing is interpolation in premultiplied RGBA...

Could you please clear this up? Which of the two examples is interpolated in premultiplied RGBA? And how is the other method called?
Comment 10 Simon Fraser (smfr) 2016-04-01 13:13:13 PDT
*** Bug 156105 has been marked as a duplicate of this bug. ***
Comment 11 Radar WebKit Bug Importer 2016-04-01 13:59:08 PDT
<rdar://problem/25499232>
Comment 12 Binyamin 2017-01-11 11:30:54 PST
Any progress with this?