[filter-effects] resolution dependent filter primitives

Hi,

This is a follow up on Stephen White's mail "Filter Effects and High DPI"[2]

The Filter Effects spec[1] has a couple of filter primitives that are resolution dependent. Namely: feConvolutionMatrix, feDiffuseLighting, feSpecularLighting and feCustom.

With removing 'filterRes', there is just 'kernelUnitLength' that can be used to "hard code" a resolution for a primitive. 'filterRes' defined the resolution for the whole filter chain which reduced or increased pixel density for each filter primitive instead of one. This either caused unnecessary oversampling of filter operations but more often: unnecessary reduction of quality. With 'kernelUnitLength' the affect of over- or undersampling can be localized to exactly one primitive where the primitive values can not be scaled for resolution independent results.

If 'kernelUnitLength' is not set, all the primitives in the introduction may depend on the device pixel ratio and are therefore platform dependent. This is actually hardly a "retina" vs "normal" screen problem. SVG is scalable by nature and therefore you can see the problem on any screen today. Open the following example in a browsers and resize the window:

	http://www.w3.org/Graphics/SVG/Test/20110816/svg/filters-conv-01-f.svg

You'll see that you don't have consistent results. If you make the window smaller, the top left image gets more blurry and the top right image more sharpen. Same happens if you zoom into a page where one of the above primitives was applied.

We could create stable results by default. UAs could set 'kernelUnitLength' such that the kernel size is always relative to a CSS pixel in the current local coordinate system of the filtered object. This is something that is nearly impossible to determine for the author if he wants to use the same filter on different objects. With the auto calculated 'kernelUnitLength' the proportion of the filter chain result looks always the same across platforms but might be more pixelated on one platform and less pixelated on another one.

It is unclear what is better for the users:
* best results that are highly platform dependent and indeed differ significantly, or
* platform independent results that might be pixelated.

During my research I couldn't find one SVG example where the above primitives are used in combination of either 'filterRes' or 'kernelUnitLength'. Not even in the SVG test suite. That means these examples in the web out there are all suffering from device and zoom dependent filter results.

I would even suggest removing 'kernelUnitLength' as well and choose one of the above two ways (high DPI but resolution dependent results, or pixelated proportion stable results). Or let the author choose between one of the two options and have one as fallback.

Does anyone have a comment?

Greetings,
Dirk


[1] http://dev.w3.org/fxtf/filters/
[2] http://lists.w3.org/Archives/Public/public-fx/2013JanMar/0149.html

Received on Tuesday, 27 August 2013 04:29:12 UTC