'color-interpolation' isn't used for alpha compositing

[litherum]

The definition of color-interpolation states:

The ‘color-interpolation’ property specifies the color space for ... alpha compositing.

However, it appears that no implementations actually do this.

Here is the test file. In an implementation which follows the spec wording, the apparent color of the circles should be different.

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C/DTD SVG 1.1//EN"  "http://www.w3.org/Graphics.SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg">
    <rect x="0" y="0" width="100" height="100" fill="white" stroke="red"/>
    <circle cx="50" cy="50" r="30" fill="black" opacity="0.5"/>
    <g color-interpolation="sRGB">
        <rect x="100" y="0" width="100" height="100" fill="white" stroke="red"/>
        <circle cx="150" cy="50" r="30" fill="black" opacity="0.5"/>
    </g>
    <g color-interpolation="linearRGB">
        <rect x="200" y="0" width="100" height="100" fill="white" stroke="red"/>
        <circle cx="250" cy="50" r="30" fill="black" opacity="0.5"/>
    </g>
</svg>

And here are screenshots of the implementations:

[litherum]

Some more background: The spec states:

When a child element is blended into a background, the value of the ‘color-interpolation’ property on the child determines the type of blending, not the value of the ‘color-interpolation’ on the parent.

But it also states:

Inherited: yes

[svgeesus]

Yes, color-interpolation="linearRGB" is not implemented in browsers. (It used to be, in the Adobe and Corel plugins a decade ago). So they all do sRGB (which is what the Compositing spec says to do, and is mathematically incorrect and gives artifacts, but matches what Photoshop does).

I suspect the Working Colorspace in Color 4 will supersede this.

[litherum]

Can we change the SVG spec to match reality?

[longsonr]

color-interpolation="linearRGB" is implemented in Firefox for masks. It's not implemented elsewhere.

[sobotka]

From the ISO 22028-1 Standard:

3.3

additive RGB colour space

colorimetric colour space having three colour primaries (generally red, green and blue) such that CIE XYZ tristimulus values can be determined from the RGB colour space values by forming a weighted combination of the CIE XYZ tristimulus values for the individual colour primaries, where the weights are proportional to the radiometrically linear colour space values for the corresponding colour primaries

"linearRGB" is not a colorspace, which will bring pain in 2018 given a majority of mobile devices and a significant segment of desktop / laptops are wide gamut.

[svgeesus]

"linearRGB" is not a colorspace

Actually, the exact opposite. If you are doing math (addition, subtraction, multiplication) or color component values then they need to be linear-light to be additive. So sRGB, for example, is not additive (nor is any RGB colorspace with a gamma component). Linear sRGB, and CIE XYZ, are additive.

[svgeesus]

Given that

a) color-interpolation is not implemented in browsers, and also b) a means to specify the working colorspace is needed, and will be defined in CSS Color 4 not in SVG, and will probably not be called color-interpolation

then color-interpolation should be removed from the SVG 2.0 spec. SVG 2.1 will use whatever is in CSS Color 4. Same goes for color-interpolation-filters if that still exists in SVG 2.0 and hasn't been moved over to filters-1.

[svgeesus]

@longsonr

color-interpolation="linearRGB" is implemented in Firefox for masks.

Is there content which relies on this? If we remove it from the SVG 2.0 spec, would Firefox keep it or remove it?

[BigBadaboom]

color-interpolation is supported by some SVG renderers. For example, Batik supports it for gradients.

[sobotka]

Actually, the exact opposite.

According to the ISO 22028-1 Standard, an additive RGB colourspace is defined by three mandatory components:

• Primaries
• Whitepoint
• Transfer Functions (OETF and EOTF)

Linear is not a colourspace. It is the transfer characteristic of an additive RGB colourspace.

So sRGB, for example, is not additive (nor is any RGB colorspace with a gamma component). Linear sRGB, and CIE XYZ, are additive.

False. All are additive. Nonlinear encoding manipulations will result in incorrect results in all colourspaces.

[KelSolaar]

What @sobotka is explaining is that using the LinearRGB term does not give you any information about the intrinsics of the colourspace itself, implying that you have to make assumptions about the underlying encoding of the RGB values. A few years ago, it was probably relatively safe (albeit still bad) to assume it was sRGB encoded, but today with the advent of HDR and Wide Colour Gamuts, DCI-P3 or BT.2020 are very common.

To be unambiguous, RGB colourspaces must be specified with the three components @sobotka enumerated above.

Now on the linearity topic, RGB colourspaces are intrinsically linear, the first RGB colourspace, CIE RGB derived by Wright (1928) and Guild (1931) has no defined colour component transfer function (CCTF), i.e., OEFT and EOTF. We use them mainly for bandwidth/storage optimizations in accordance with the non-linear response of the Human Visual System (HVS) to brightness. However, in a perfect world neglecting commercial performance and expenses, one might conceive colour imaging systems based on high-quality floating point representations where non-linear encoding would not be necessarily required.

[AmeliaBR]

To the extent that anyone implements linearRGB color interpolation, I think it is done using the sRGB gamut, but with addition/interpolation simplified. Does anyone have an objection to formally defining it that way?

On Myles' original question: I have no problem with excluding compositing from the definition of what color-interpolation affects, to match reality. (Even if, as Chris has pointed out, the results aren't always optimal. It seems easier than changing the compositor code in browsers and operating systems and GPUs.)

As far as color-interpolation goes: I think the property would be a lot more popular if it gave us other options, to interpolate colors (for gradients and animations, in particular) using color spaces that use non-RGB decomposition. Wouldn't it be nice to interpolate between two bright, saturated colors without going through gray in between, by interpolating a hue component instead or red, green, and blue?

[svgeesus]

What @sobotka is explaining is that using the LinearRGB term does not give you any information about the intrinsics of the colourspace itself, implying that you have to make assumptions about the underlying encoding of the RGB values.

Aha, I see the problem. My assumption, erroneous as it turn out, was that @sobotka had read the portion of the SVG specification in question and was somehow asserting that the term linearRGB as used in the SVG specification wasn't a linear colorspace and indeed was not a colorspace at all. But apparently they were just reacting to the name, out of context.

If they had read the specification, they would have instantly realized that three items of information they requested are in fact clearly stated, and need not be "assumed".

@KelSolaar yes, I'm aware that the mercury vapor lights used for the 1931 RGB matching experiments were of course linear. And a few years ago or even decades ago there was no "assumption" of the sRGB primaries, D50 whitepoint, and sRGB or linear transfer function (as appropriate); it was clearly and explicitly stated.

[svgeesus]

@AmeliaBR

To the extent that anyone implements linearRGB color interpolation, I think it is done using the sRGB gamut, but with addition/interpolation simplified. Does anyone have an objection to formally defining it that way?

I'm not sure what you mean by "addition/interpolation simplified". The implementations that implemented the linearRGB value for color-interpolation:

• Batik
• Inkscape
• Firefox (in part, as noted above)
• Corel SVG Viewer
• Adobe SVG viewer

all implemented it per spec (sRGB primaries, D65 whitepoint, but in linear-light space (undoing the gamma companding step, using the equations defined in the sRGB standard and duplicated in the SVG and CSS specifications for ease of referencing).

I have had several requests to move the definition of the linearRGB space from SVG to CSS Color 4, and it is on my to-do list. The actual definition in the SVG spec is clear and mathematically correct, however.

As far as color-interpolation goes: I think the property would be a lot more popular if it gave us other options, to interpolate colors (for gradients and animations, in particular) using color spaces that use non-RGB decomposition. Wouldn't it be nice to interpolate between two bright, saturated colors without going through gray in between, by interpolating a hue component instead or red, green, and blue?

Yes, it would. That is why the working colorspace part of CSS Color 4 will not just have the two values sRGB and linearRGB but also the other colorspaces defined there (predefined RGB spaces like image-p3 and rec2020, CIE Lab and LCH. LCH in particular will give the hue-angle interpolation you mentioned.

[svgeesus]

@AmeliaBR

On Myles' original question: I have no problem with excluding compositing from the definition of what color-interpolation affects, to match reality.

If we were keeping color-interpolation then I would object, because it would box us into a corner; but since it looks like color-interpolation and color-interpolation-filters will be deprecated, or will be aliases for the working colorspace, then that will work out okay (as the initial value will of course be sRGB, for Web compat).

[svgeesus]

@longsonr

color-interpolation="linearRGB" is implemented in Firefox for masks. It's not implemented elsewhere.

Right. Masks (and compositing, and anti-aliasing, and image re-sampling) are the cases where using a linear-light, additive colorspace produces better results. While for gradients, using a perceptually linear space gives better results.

[svgeesus]

@Tavmjong wrote a nice summary of color-interpolation implemented in Inkscape and a backgrounder on interpolation in linear RGB

[sobotka]

While for gradients, using a perceptually linear space gives better results.

False.

All manipulations must be applied to either display linear or scene linear transfer function encoded data.

The underlying reference space model must always be linearized for proper light transport composition, regardless of the primaries of said colour space[1]. Full stop. The formatting and display of the blending will typically be encoded with a nonlinear transfer function, as per the UI or display characterization needs, but the reference space must always remain linearly encoded.

[1] This also applies to more sophisticated colour encoding models including extending the model up to spectral.

[KelSolaar]

If they had read the specification, they would have instantly realized that three items of information they requested are in fact clearly stated, and need not be "assumed".

I was stricly reacting to the term (as I wrote), but I read the current specification, and the writing is sloppy. Call me pedantic but quoting some parts:

The color-interpolation property chooses between color operations occurring in the sRGB color space or in a (light energy linear) linearized RGB color space.

or in a (light energy linear) linearized RGB color space

Which one?

light energy linear, the proper terminology is radiometrically linear, you will probably not find light energy linear in color science literature.

It is only toward the bottom that you finally find what is hiding under Linear RGB:

The conversion formulas between the sRGB color space (i.e., nonlinear with 2.2 gamma curve) and the linearized RGB color space (i.e., color values expressed as sRGB tristimulus values without a gamma curve) can be found in the sRGB specification [SRGB].

It is a shame that the 1999 specification was better authored in that regard and was unambiguous:

RGB colors are specified in the sRGB color space [9]. UAs may vary in the fidelity with which they represent these colors, but use of sRGB provides an unambiguous and objectively measurable definition of what the color should be, which can be related to international standards [10].

This should have been the very first paragraph, but back in 1999, sRGB specification was only a few months old. There is no reason to not have it clearly stated at the very start of the current specification.

there was no "assumption" of the sRGB primaries, D50 whitepoint, and sRGB or linear transfer function (as appropriate);

D50, are you certain? ;)

All in all, the CSS 4 draft is much better written in that regard and you will notice that it indeed specify the three components so that no ambiguity is possible.