It seems that the filter is applied in a wrong color space, which seems not controlled by Blink>Paint. Routing to Skia to triage.

I'd have to go through the path by which SVGs are rendered to be sure, so this may be inaccurate.

But my guess is that SVGs are rasterized in the color space of the display. This space is often ~P3-like instead of being exactly-sRGB, which is the space that feColorMatrix should be applied in. The issue vanished on HDR displays when you add

div(style=`--f: url(#b)`) 
  img(style=`width:100px;height:100px;`, src=`https://people.csail.mit.edu/ericchan/hdr/gain_map_images/01.jpg`)

because in that case the working space goes from "8-bit P3" to "16-bit float extended sRGB".

Fixing this in the general case (which includes all blending operations) is very involved (and I suspect no browsers actually do that).

That said, the limited case of feColorMatrix and friends doesn't seem unreasonable. We convert to a working color space here that is either "linear" or "srgb". IIRC Skia recently added something that allows a paint filter to explicitly convert to a specified color space for a stage.

Right now I believe the linear and srgb working color spaces in SVG are controlled by wrapping the image filters in an SkImageFilters::ColorFilter with a color filter that performs the gamma encoding or decoding. But this has a built-in assumption that the destination color space of the image filter is already in the srgb gamut. Skia now has a way to just define the SkColorSpace on a saved layer, and that would be able to replace the use of these color filters if the control only has to be at the root of the filter graph, and if it's okay to draw via the expanded SkCanvas::saveLayer API.

We also have relatively new SkColorFilter and SkShaders for changing the working color space of those effects and it would straight forward to generalize that to SkImageFilter as well. Then the SVG filters could simply wrap their formats in whatever working color space it needed to be and Skia would handle it (and in most cases would work out to the same or more efficient than the current color filter wrapping).

Nice! Sounds like we have a much wider range of tools to address this than we did a while ago.

Another test including a lot more cases, where I try to extract individual channels, their negation, union, intersection, difference, XOR, plus extraction as alpha masks, attempting various corrections... https://codepen.io/thebabydino/pen/KwKvRKr