Re: [compositing] Requesting clarification of color interpolation

Hi Nikos,

thank you for your kind answer. Please see inline for my comments.

On 01/19/2015 05:28 AM, Nikos Andronikos wrote:
> Hi Simon,
>
> On 16/01/2015 8:21 am, Simon Thum wrote:
>> 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.
> So, to confirm, you would ideally like the compositing spec to state
> that all blending and compositing operations must be performed in a
> linear colour space?

I *would like*, yes, but I understand the limitations. My order of 
preference is:

1) A correct and unambiguous standard
2) An intentionally incorrect but unambiguous standard
3) An incorrect but unambiguous standard
4) an ambiguous standard

I really would avoid 4, which is where compositing is at now (if I'm not 
missing something).

> I don't think that's possible as it would not be backwards compatible,
> but perhaps the next best thing would be to add a note for authors
> stating that compositing and blending operations should always be done
> in a linear colour space, which is controllable with color-interpolation?
>
> However I fear that wouldn't achieve very much, as the browser vendors
> have shown (from what I can see) little interest in allowing
> transformations to be performed in any alternate colour spaces (probably
> because of limitations in the underlying graphics libraries that they use).
> e.g. color-interpolation isn't implemented anywhere (although is still
> present in SVG 2 so maybe there's hope?).

If I'm not mistaken composite specifies a bunch of stuff that has not 
been available broadly yet. E.g. SVG used the vehicle of 
color-interpolation-filter to put a sane default on newly-specified 
stuff (at least that's my interpretation). I'm not sure if that's an 
option in compositing but it should be given some thought.


>
>>
>> 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.
>
> There is certainly an understanding of the problems with sRGB
> transformations, at least within the SVG working group. Tav has brought
> this up multiple times and has blogged about it here:
> http://tavmjong.free.fr/blog/?p=765.
>
>>
>> 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.
> I'm not quite following what you've written here. I think you're saying
> you would like the initial values of color-interpolation to be changed
> to linearRGB but I'm not sure how that would stay compatible with
> css3-color?

I am unsure at what stage css3-color is, i.e. whether one needs to 
remain compatible with it at the cost of correctness, or whether it is 
perferable to align css3 and png in this regard. AFAICT this was 
unspecified before, but of course, it wasn't implemented correctly 
anywhere so I see that's not a very convincing argument.

Nonetheless, it would be higher up in the order of preference I just gave.

>>
>> 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.
> I don't think it's performance that's blocking this - it's support in
> the underlying libraries.
> I also don't think we can make linearRGB the default due to backwards
> compatibility issues.
>
> Bugs tracking color-interpolation in browsers:
> WebKit: bugzilla.opendarwin.org/show_bug.cgi?id=5972
> Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=298281

Thanks for those bugs! But whatever is going on implementation-wise, the 
document should be unambiguous. Right now, as mentioned, it's in the 
terrain but not the spirit of PNG and SVG. This will bring up 
implementation issues that could be avoided with explicitly specifying 
the relation to PNG compositing, the color-interpolation CSS/SVG 
property etc.

For example, when alpha-compositing a PNG on a page, which algorithm 
applies? PNG or compositing?

I know it's really hard to find correct implementations of color 
algorithms, but one cannot expect that to improve if something exposed 
like W3C compositing implies it's a non-issue by silently assuming sRGB 
compositing, even in conflict with some of SVG and PNG.

So, whatever the actual choice to go with [which is probably the simple 
but wrong choice as the default or only option], please make it explicit 
and well-documented, thus climbing up to 2 in the above order. I 
volunteer to provide input if that's what is missing.

Cheers,

Simon


>
>
>
> ---------------------------------------------------------------------------------------
>
>
> The information contained in this email message and any attachments may
> be confidential and may also be the subject to legal professional
> privilege. If you are not the intended recipient, any use, interference
> with, disclosure or copying of this material is unauthorised and
> prohibited. If you have received this email in error, please immediately
> advise the sender by return email and delete the information from your
> system.
>

Received on Monday, 19 January 2015 20:30:41 UTC