W3C home > Mailing lists > Public > www-svg@w3.org > January 2013

Re: About svg2 filters draft

From: Dirk Schulze <dschulze@adobe.com>
Date: Wed, 2 Jan 2013 09:55:09 -0800
To: Yves followdsvg <svgadopter@gmail.com>
CC: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <2145379B-A0AB-4995-B657-E559E72F9720@adobe.com>
Hi Yves,

Thank you very much for your feedback and the detailed description. The SVG WG will review your proposals and discuss them in the weekly telephone conferences. I will reply to the individual proposals in behalf of the SVG WG once we discussed them.

Greetings,
Dirk

On Dec 12, 2012, at 3:24 PM, Yves followdsvg <svgadopter@gmail.com> wrote:

> Hi, 
> 
> I don't know if it's the right place to post but here are some thoughts about
> 
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
> 
> (0) Maybe add some notes about valid/safe values for coefficients with minimal requirement
> -----------------------------------------------
> I (think I) understood that coefficients are unbounded.
> 
> >https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feColorMatrixElement
> >  Values outside the 0..1 range under- or oversaturates the filter input image respectively
>  
> I heavily use values such as 256 for feColorMatrix.
> I use them so that, after computation, an input value in range [0,1] maps to 
> 0 if input was 0, 
> 1 if input was > 0.
> 
> Should implementations ensure that summing won't exceed the capacities of their internal "storage" ?
> (Of course they should but maybe one can add some words about it ?)
> 
> 
> 
> (1) feDropShadow : angle and distance instead of (or along with) dx,dy 
> ----------------------------------------------------------------------
> 
> Instead of dx, dy for offseting the dropshadow I'd rather see two properties "angle" and distance.
> (think gimp drop shadow vs photoshop).
> Valid values for angle would be [0,360[ with lacuna value of 90 (or "globalLightSource" ?)
> 
> 
> 
> (2) feDropShadow : globalLightSource
> ------------------------------------
> 
> Another valid value for angle could be "globalLightSource"
> with globallightSource a new property of the svg tag (or any group tag ?) (with a lacuna value of 50%, -infinite)
> 
> For every shape, the angle is calculated by taking the center of shape and the "position" of a global light source.
> 
> So after you designed your whole scene, if you decide the sun is at noon instead of 11am,
> you won't have to look after every shape to change this dx,dy you just set the sunposition of svg and voilà.
> 
> I know there could be more than one light source in a scene. But it's better than nothing (and better than just dx,dy)
> Maybe we could use xlinking instead of just "globalLightSource" ?
> 
> 
> 
> (3) feDropShadow : Spread property
> ----------------------------------
> 
> I think feDropShadow lacks a spread property. This could be simulated using a feMorphology as first stage.
> 
> The result of a ‘feDropShadow’ filter primitive would be equivalent to the following:
> 
>     <feMorphology in="alpha-channel-of-feDropShadow-in" operator="dilate" radius="spread-radius" />
>   <feGaussianBlur stdDeviation="stdDeviation-of-feDropShadow"/> 
>   <feOffset dx="dx-of-feDropShadow" dy="dy-of-feDropShadow" result="offsetblur"/> 
>   <feFlood flood-color="flood-color-of-feDropShadow" flood-opacity="flood-opacity-of-feDropShadow"/> 
>   <feComposite in2="offsetblur" operator="in"/> 
>   <feMerge> 
>     <feMergeNode/>
>     <feMergeNode in="in-of-feDropShadow"/> 
>   </feMerge>
> 
> maybe it could accept neg values for radius then the operator feMorphology would be "erode" with a radius of "-spread-radius".
> 
> 
> 
> (3b) feMorphology : new operator "spread"
> ---------------------------------------
> 
> instead of juggling with erode or dilate one could define a new operator for femorphology ("spread" ?) which accepts positive or negative value. With positive values it dilates with neg it erodes. 
> 
> 
> 
> (4) feTurbulence : new type "random"
> ------------------------------------
> 
> add a new algorithm that returns a value in [0,1] by applying the classical random() for every "dot".
> Basefrequencies could accept integers that would be the size of the dots. 
> Usefull for layer effect like diffuse (and deliberate pixelation if you play wwith base frequencies)
> 
> 
> 
> (4b) feTurbulence : new property "preserveGrey" (sorry can't find a better name) 
> ------------------------------------------------
> 
> This property will accept any combination of R,G,B,A (eg : "RB") ; lacuna value would be "";
> When set, the result of feTurbulence for every channel listed in property is "weighted" so that sum() = sum(grey).
> It would be usefull when you want to do a feDisplacementMap(scale) followed by a Offset(scale/2,-scale/2) and be sure it would not move too much.
> 
> 
> 
> (5) feDisplacementMap : allow "none" in addition to "R,G,B,A" for *ChannelSelector
> ----------------------------------------------------------------------------------
> 
> Sometimes you don't want to displace along one axis. For now you need to empty one of the channel. This looks very uneccesary to me.
> 
> 
> 
> (6) feComposite : new property "alpha"
> --------------------------------------
> fecomposite : please, please, please allow computation to exclude the alpha. Everything would be that much easier without this alpha
> May I suggest an alpha property that indicates how to handle it ?
> valid values would be : 
> "k"         => compute as usual (would be the lacuna value)
> "in", "in2" => alpha output = alpha of input 1 or 2
> [0,1]       => alpha output = const
> 
> 
> 
> (7) 4 new in sources for filter
> ------------------------------
> 
> StrokeGraphic + FillGraphic (~= SourceGraphic)
> StrokeAlpha   + FillAlpha   (~= SourceAlpha)
> 
> StrokeGraphic => same as SourceGraphic but without fill property   (like if all fill properties of elements were set to "none")
> FillGraphic   => same as SourceGraphic but without stroke property (like if all stroke properties of elements were set to "none")
> 
> Yeah I already got a response by Jasper van de Gronde about this last one but it was a bit off topic.
> We talked about speed issues of femorphology. But if femorphology could be solution to get the stroke for some simple case, 
> I think it would be more convenient to have those 4 new sources. For me, StrokeGraphic looks more usefull than the existing StrokePaint for exemple : it could be use to make complex borders (groove, double, bumped...)
>  
> 
> 
> -------
> 
> 
> What I missed the much in svg for now : 
>  meshes gradient (or diffusion curves ;) ), 
>  being able to offset the stroke so that it is fully outset (and not 50% inset, 50% outset) 
>  natural y (viewport 1,-1 is not a solution because of font going top/down)
> 
> 
> Thank you for reading.
> 
Received on Wednesday, 2 January 2013 17:55:24 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:53 GMT