[filter-effects-1] How to handle feColorMatrix with type=saturate and values outside a 0..1 range?

[RazrFalcon]

• https://www.w3.org/TR/SVG11/filters.html#feColorMatrixElement
• https://www.w3.org/TR/filter-effects-1/#feColorMatrixElement

SVG 1.1 spec states that:

For type="saturate", ‘values’ is a single real number value (0 to 1).

but in Filter Effects Module Level 1:

Values outside the 0..1 range under- or oversaturates the filter input image respectively.

And the real results are even more strange:

<svg viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg">
    <linearGradient id="lg1">
        <stop offset="0" stop-color="#cc00cc"/>
        <stop offset=".33" stop-color="#228822"/>
        <stop offset=".67" stop-color="#400000"/>
        <stop offset="1" stop-color="#a0a0ff"/>
    </linearGradient>
    <filter id="filter1">
        <feColorMatrix type="saturate" values="-0.5"/>
    </filter>
    <rect x="20" y="20" width="160" height="160" fill="url(#lg1)" filter="url(#filter1)"/>
</svg>

And with values="99999":

[AmeliaBR]

The definition of saturation values over 1.0 is fairly clear: using the same formula, multiply the saturation until the color channels max out. This is the "oversaturation" mentioned in the note. It works the same as the saturate(n) shorthand. The Chrome and Batik result for values="99999" match what I expect. Not sure what's going on with Firefox. The other browsers clearly haven't been updated since SVG 1.1: librSVG is treating it as an error that disables rendering, the others are clamping to 1 and therefore treating it as a no-op effect.

But I'm not sure a negative value makes sense. It's disallowed in the shorthand. It certainly doesn't make sense to say these values "undersaturate" beyond grayscale. If you substitute the value into the matrix equation, you end up inverting the colors and then applying the saturation factor. And that seems to be what Chrome and Batik are doing. Firefox is ignoring the negative value, treating it as a no-op. The others are clamping to 0. (librSVG again treating as a fatal error)

The invert & saturate calculation is definitely the most consistent with the current spec text, although I'm not sure what the use case is. I'd also be OK with clamping to 0, or making negative values invalid (to match the shorthand). Either way, it definitely needs to be defined.

[dirkschulze]

So it sounds like we either:

• Disallow negative values and the filter primitive is either in error or values gets ignored.
• Clamp negative values to 0.
• Open bug reports to implementations.

IMO the last 2 options seem fine to me.