Re: [compositing] Requesting clarification of color interpolation

Hi Simon,

On 20/01/2015 7:29 am, Simon Thum wrote:
> 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).
The compositing spec isn't assuming sRGB. It is defining blending and
compositing operations that can be performed in any RGBA colour space -
with varying levels of quality (and perhaps this should be stated - see
below). SVG and CSS provide mechanisms for setting the colour space for
those operations, but these aren't implemented anywhere, which is
unfortunate.

>> 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.

The compositing specification builds on what already existed - that was
called simple alpha compositing, which uses the src-over Porter Duff
operator and the Normal blend mode.
So, when an author selects these values, the result must be the same as
it appeared in SVG 1.1.
>
>
>> 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?

My understanding is that the PNG spec only says 'should'. Therefore PNG
only recommends alpha compositing in a linear space, but this is not
strictly required, and browsers ignore it and do all PNG composing in sRGB.
A test: http://jsfiddle.net/dodgeyhack/ffzjtrwz/1/

> 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
>
My thoughts are that the compositing spec should include a note for
authors stating:
- to achieve high quality/accurate colour output, all operations need to
be performed in a linear colour space
- the default colour space is non-linear sRGB
- the colour space for compositing operations can be controlled with the
color-interpolation property

Then it is up to implementations to implement  color-interpolation.
I would like to add this wording to the next version of the spec - level
2. I don't think it's worth revising the current CR since the advice
cannot be acted upon currently.

Would you be happy with this? And what do others think?

Cheers,
Nikos
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 Wednesday, 21 January 2015 00:11:20 UTC