About svg2 filters draft

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.