Re: About svg2 filters draft

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 UTC