Re: [filter-effects] A few more issues: 'in2', 'feSpecularLighting', CSS Comp. & Blend. modes

Hi Tav,

I added all raised issues to the spec as spec issues for now. This way we can discuss them during the SVG F2F. See inline comments to your issues:

On Nov 12, 2013, at 4:51 AM, Tavmjong Bah <tavmjong@free.fr> wrote:

> 
> Since there seems to be a lot of discussion planned at the TPAC F2F for
> filter effects, I want to add a few issues to the list:
> 
> 
> 1. 'in2'
> 
>  For 'feBlend' and 'feComposite' the spec says:
> 
>  in2 = "(see ‘in’ attribute)"
>    The second input image to the compositing operation. This
>    attribute can take on the same values as the ‘in’ attribute.
> 
>  I interpret this that 'in2' behaves like 'in', thus if 'in2'
>  is not given and this is the first primitive, 'SourceGraphic'
>  is used, if not given and this is not first primitive,
>  the result of the previous filter is used.
> 
>  Inkscape, rsvg, and Opera (12.16) agree with this
>  interpretation. Batik as well as 'validator.w3.org'
>  says 'in2' is required.  Firefox and Chrome require
>  'in2' to be defined.
> 
>  For an example, see:
> 
> http://tavmjong.free.fr//INKSCAPE/MANUAL/images/FILTERS/Filters_SolarFlare.svg

I think this is a misinterpretation. This sentence really just says that in and in2 can have the same input. It does not say anything like “if in2 is not specified, then take the input of in”. To make this clear, it should maybe transformed into a note and be rephrased.

> 
> 
> 2. 'feSpecularLighting'
> 
>  The specification states:
> 
>  "Such a map is intended to be combined with a texture using
>   the add term of the arithmetic ‘feComposite’ method.". It
>   does not state that one is required to use it this way. The
>   browsers disagree on how the filter is rendered if the
>   compositing step is not done.
> 
>  ('Such a map' should be 'Such an image', I think.)

The lighting filter creates a bump map. The text is referring to this bump map. I think the usage of the term here is correct, even though the sentence before talks about an image (a bump map is still just an image).

To be honest, I do not really understand the issue that you raise. The lighting filter creates a bump map which is composited with the input graphic, no? What should be required or not be required here?


> 
> 
>  Trivial, example:
> 
>  <filter id="emboss">
>    <feColorMatrix type="luminanceToAlpha" />
>    <feSpecularLighting lighting-color="#808080">
>      <feDistantLight elevation="0"/>
>    </feSpecularLighting>
>  </filter>
> 
>  Compare "Specular Lighting" example in:
> 
>  http://tavmjong.free.fr/SVG/COLOR_INTERPOLATION/filter_interpolate.svg
> 
>  Inkscape, rsvg, Opera agree on rendering (outer square
>  matches inner square). Firefox and Chrome agree (outer
>  square does not match inner square). Batik can't render
>  example.
> 
>  (Note: Chrome has a problem with 'feDiffuseLighting' primitive
>  when interpolation is set to 'linearRGB'.) 
> 
> 
> 3. CSS Compositing and Blending modes.
> 
>  CSS Filters should extend 'feComposite' and 'feBlend' to include
>  all the operators defined in Compositing and Blending Level 1.
>  The new operators are trivial to implement once the existing
>  operators in the basic filter primitives are implemented and
>  thus there is no reason not to include them.

CSS Compositing does not have compositing modes for CSS or SVG yet. We could add the new blend modes though. I would rather back off on adding new features at this point and mark this as an improvement for the second level of the spec.

Greetings,
Dirk

> 
> 
> Tav
> 
> 
> 
>

Received on Monday, 11 November 2013 23:49:35 UTC