[compositing] Requesting clarification of color interpolation

Dear all,

I just reviewed the latest draft of the compositing spec [0], and I 
would like to ask if an explicit clarification about the color 
interpolation space could be included in the compositing spec.

Right now, CSS states that "When drawing, implementations must handle 
alpha according to the rules in Section 14.2 Simple alpha compositing of 
[SVG11]. (If the ‘color-interpolation’ or ‘color-rendering’ properties 
mentioned in that section are not implemented or do not apply, 
implementations must act as though they have their initial values.)"

(http://www.w3.org/TR/css3-color/#alpha)

This more or less fixes sRGB-based blending/interpolation, SVG's 
unfortunate default. That is wrong (see below for more information).

In these list archives there are many encouraging words (and resources) 
suggesting that linear is right an should be the default, but it is 
missing from the spec that I read.

PNG and SVG follow the sRGB spec (see section Alpha Channel Masking and 
Computer Graphics Compatibility) and explicitly call for linear 
blending, in different degrees of detail. In PNG it is the only 
conforming way of doing compositing, which I regard as an exemplary 
choice (see 13.16 Alpha channel processing).

Note that I am not really asking for a "color-interpolation" property. 
Such a property purports that non-linear (sRGB) mixing/interpolation 
would be a valid choice among many, which it isn't.

The defect of sRGB or other non-linear blending is treated formally and 
visually by Jim Blinn from his 1998 Article "A Ghost in a Snowstorm". It 
is one of the few accurate and thorough treatments of the subject. To 
cite from this article:

"A typical video or paint image,
however, encodes intensity nonlinearly. Most image
manipulation software doesn’t take this into account
and just does arithmetic on the pixel values as though
they were linearly related to light intensity. This is obvi-
ously wrong. The question is, how wrong, and for what
pixel values is the problem worst and best?"

His net result is that only corner cases that aren't really compositing 
will be fine irrespective of gamma correctness. In the other cases, you 
get strange-looking effects (hence the name of the article). Thus, sRGB 
mixing is only really good for being compatible to lazy implementations.

I am writing because I am worried that his great attempt to improve 
graphics on the web may make it worse by fixing the mistakes of the 
past. Please dispel my doubts, or better yet, state clearly how to 
implement compositing.

In a sense, this is a followup to

http://lists.w3.org/Archives/Public/public-fx/2012JanMar/0149.html

which calls for similar things. Since compositing is seemingly nearing 
recommendation status, I thought  I'd bring this up again as the issue 
seems still open.

What I would recommend is to stay compatible with css3-color by 
specifying that assuming a color-interpolation of linearRGB is the 
correct and preferred implementation, just as indicated by sRGB and 
others. This would also have the benefit of PNG alpha and CSS alpha 
being aligned to each other.

Some have expressed concerns regarding performance on this list. I did 
implement gamma-correct GPU shaders 
(https://github.com/igd-geo/x3dom/commit/65f02b29290d2b6d4fa92353b0151df8bd506634) 
and I could hardly tell the difference in performance. It's a full-blown 
renderer, but you could use it to obtain numbers if you really want to.

Thank you,

Simon

[0] http://www.w3.org/TR/2015/CR-compositing-1-20150113/

Received on Monday, 19 January 2015 07:09:51 UTC