In the "expected.png", the ~8 o'clock segment is blue, and is the darkest.

The input image has blue at 12 o'clock, but with a color space that rotates it to 8 o'clock.

This particular example uses a SkColorFilterImageFilter to do the "to greyscale" transformation. It appears to me that we aren't appropriately transforming the image, but I haven't found the call where we do that yet.

Actually, this reproduces when the input image has no special color profile.

And ... the main issue is: We have a color transform defined as "apply the matrix M to pixel values". In which color space do we apply this?

The above example does NOT actually use a SkColorFilterImageFilter. Rather, it is applied via cc::RenderSurfaceFilters::BuildImageFilter.

This just applies the matrix M in the output space.

Note that there is no true fix for this, because there exists no matrix M' that, when applied in the output space, gives the same results as M would have in sRGB.

But, a decent guess would be, if we let A be the the matrix that transforms linear sRGB primaries to linear output space primaries, we could let M' be A^-1 * M * A.

Brian/Matt, WDYT? What do you do in Skia in these sorts of situations (I couldn't find an onMakeColorSpace for any matrix-based color transforms).

Oh, actually, cc::RenderSurfaceFilters::BuildImageFilter builds a SkColorMatrixFilterRowMajor255, which doesn't have ::onMakeColorSpace overridden. I'll see about adding the A^-1*M*A thing there.

Sounds like we want to retroactively apply the matrix to the sRGB color, even though the color is already in destination color space?

I wonder if what we want is for the matrix color filter's onMakeColorSpace() to return a new kind of non-linear effect.  Does this seem like the gist of what you'd expect to happen now when using SkColorSpaceXformCanvas?

Inputs are presumed to be sRGB encoded in destination gamut.
   1. linearize, undoing sRGB transfer function
   2. transform to sRGB gamut
   3. apply matrix
   4. transform back to destination gamut
   5. re-encode with sRGB transfer function

2-4 are linear operations that can be fused together  unless you want to clamp to [0,1] or [0,a] anywhere in there.

The spec at
https://drafts.fxtf.org/filters/
says that "Filter functions must operate in the sRGB color space."

AFAICT, this means sRGB pixel values, not a linear space, so the sequence would be:

   1. linearize using potentially-non-sRGB transfer function of dst space
   2. transform dst to sRGB gamut
   3. un-linearize using sRGB transfer function
   4. apply matrix
   5. linearize using sRGB transfer function
   6. transform sRGB to dst gamut
   7. un-linearize using potentially-non-sRGB transfer function of dst space

Note that the spec is ambiguous about what is to happen if the input color are not representable as sRGB values in [0,1] (I haven't tested what other browsers do there).

While this particular example is a bit of an edge case, the reason that I'm pretty sure that they mean "sRGB pixel values" is that that is emphatically the way that they intend for the feBlend filter to work.

That 7-step version seems right to me.

What do you mean by potentinally-non-sRGB transfer function of dst space?  Just making sure to include linear dst?  I still don't think we've got any intention to support drawing into anything except with sRGB or linear transfer functions.  Am I behind the times here?

Am I decoding the spec correctly as
  "sRGB color space"       ---> sRGB gamut, sRGB transfer function
  "linear RGB color space" ---> sRGB gamut, linear transfer function

What's the part about color-interpolation-filters vs. color-interpolation telling us?  Some things default into linear operation, some in sRGB-encoded values?

> What do you mean by potentinally-non-sRGB transfer function of dst space?  Just making sure to
> include linear dst?  I still don't think we've got any intention to support drawing into
> anything except with sRGB or linear transfer functions.  Am I behind the times here?

For fully color correct skia (true color Chrome), we only plan to support linear and srgb transfer functions.  I think here we are considering the legacy++ mode.  Given that the approach is generally "pre-transform inputs and use legacy Skia", we intend to support any transfer function that can be represented as parameters to the standard equation.

--------------------

+1 to the approach discussed in 5 and 6.  FWIW, if we go down this route, we'll probably want to take another pass over Skia effects and see if we need something similar anywhere else.  The effects that I originally classified as "arbitrary math" were essentially left alone.

To think a bit more on this, maybe it's best for us to leave this as defined in the output color space.

These arguments all apply equally to blending (that it should be done using sRGB pixel values), which, while desirable for getting predictable results, is basically impossible.

So, for the moment, maybe we should just sit on this.

Marking as WontFix for now. We may re-examine this later.