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

On Mon, 2013-11-11 at 15:48 -0800, Dirk Schulze wrote:
> 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:

Thanks!

> 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.
> 

I don't have a strong feeling either way, although since 'in' and 'in2'
can have the same input, it would be reasonable that 'in2' follow the
same rule as 'in'.
 

> > 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?
> 

It should not be necessary to composite the bump map. It should be
possible that the bump map be the final output of the filter. This
preserves the symmetry between all the filters primitives and it might
also be useful now that blending (and in the future, compositing) can be
done outside of a filter.

Both Inkscape and rsvg display an "embossed" image with the following
file:

http://tavmjong.free.fr/SVG/emboss_test.svg

None of the browsers I tested display the image.


> > 
> > 
> >  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.

I would agree that one shouldn't add new features to the spec at this
point except that adding the new blending modes is really trivial (and
at the same time it would be strange to have the modes available outside
of filters but not inside filters). It took me about 30 minutes to add
them to my private build of Inkscape.

Tav

> Greetings,
> Dirk
> 
> > 
> > 
> > Tav
> > 
> > 
> > 
> > 
> 
>