- From: Mike Bremford via GitHub <sysbot+gh@w3.org>
- Date: Sat, 23 Mar 2019 17:08:29 +0000
- To: public-fxtf-archive@w3.org
The premultiplied alpha question above has been covered by other commenters, but no-one has voiced any thoughts on the colorspace issue which I think is more interesting. A few observations: * If you want 50% gray in the input it should be #808080 not #888 (which expands to #888888) * All of the implementations described above are converting the "displacement" input in "in2" to sRGB. This appears to be the right thing to do when the displacement comes from an feImage, as in [filters-displace-01-f.html](http://tavmjong.free.fr/INKSCAPE/W3C_SVG_1.1F2/harness/htmlInkscapeApproved/filters-displace-01-f.html) - because images created by feImage are (?) always sRGB. Amelia, you asked whether the spec should change to match current behaviour, or whether there was anything that could be clarified. I can think of 3 options. 1. Require the displacement input into feDisplacementMap to be sRGB. This will work if the input is an image, but if you want it to work for anything else, like feFlood in your example, this becomes a problem. Most of the primitives work best in linearRGB, and a conversion to sRGB would make it harder to get an exact color like #808080. 2. Allow the `feImage` primitive to define the color-space of the image. sRGB, as it is now, is ideal for images destined for display, but feDisplacementMap uses the color-channels of an image effectively as a data channel (I believe it's the only primitive that does). It makes a lot of sense here to have #808080 in a bitmap image mean "no displacement". Allowing feImage to define which space the image is loaded in covers all the bases. But it would mean any existing SVGs defining an feImage as input to an feDisplacementMap would suddenly become incorrect. 3. Explicitly state that the displacement input into feDisplacementMap doesn't care about the colorspace of the input. Regardless of whether the input is linear (as in the feFlood example above) or sRGB (when it's loaded from an image), if it contains #808080 then there's no shift. This means `color-interpolation-filters` is ignored by feDisplacementMap. On balance I'd go for the last option. feDisplacement is unique in using a color channel for something other than color, and applying any sort of gamma curve to this input makes no sense. So far I haven't thought of a case where this will do the wrong thing. The other benefit is it means that the behaviour of all browsers when the feDisplacementMap input is an image continues to work. The only change required is to remove any color conversion on the input loaded from "in2" - if the input is an image this has no effect, and if the input is not, well that's the case that isn't working now. Hope that makes sense. -- GitHub Notification of comment by faceless2 Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/113#issuecomment-475887189 using your GitHub account
Received on Saturday, 23 March 2019 17:08:31 UTC