[fxtf-drafts] [filter-effects] Should implementations preserve color values of transparent pixels for filter primitive results?

AmeliaBR has just created a new issue for https://github.com/w3c/fxtf-drafts:

== [filter-effects] Should implementations preserve color values of transparent pixels for filter primitive results? ==
In #113, it was discovered that some non-intuitive results for feDisplacementMap can be traced to the fact that browser implementations mostly use alpha-premultiplied colors for filter primitive results, and that this means that the color channels get ignored for pixels with 0 alpha.  Other implementations (e.g., Adobe software) does not.

The [spec](https://drafts.fxtf.org/filter-effects/#FilterPrimitivesOverviewIntro) is clear that RGBA values should be clamped to allowable ranges for every filter primitive output (and this is regularly used in filters to create clamping color effects).  It also says, in a non-normative note, that "All input images are assumed to be in premultiplied RGBA," but does not explicitly say the same for filter primitive results.

It is particularly problematic for the result of feTurbulence, where the alpha channel has all sorts of random variation which you might want to ignore when manipulating the result to create a solid color pattern.

Example of feTurbulence as an input to color map functions for creating a solid pattern: https://github.com/oreillymedia/Using_SVG/blob/master/ch16-filters-files/water.svg

When I initially created this filter, I tried simply setting alpha to 1 in the feComponentTransfer section, but that resulted in black sections where all color data was lost.  The final version instead scales up the alpha and then composites it over a separate solid layer.


Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/243 using your GitHub account

Received on Sunday, 31 December 2017 23:12:47 UTC