>Is this what you had in mind : http://leunen.d.free.fr/prog-blur.svg ?
Yes,
it is an approximation of a real progressive blur. But not perfect, and
it
cannot be achieved with a filter

[Agreed; and yes that is what I had in mind.]

>Here is another approximation on the x-axis "blur" only :
http://leunen.d.free.fr/progr-blur2.svg. The drawback of this workaround
is
to be non-scalable, a pity for *S*vg.

[this link seems to be broken]

>So, I'm really stuck I guess.
I have to hope that the svg-ig will convince the wg to add this feature
to
svg 1.2. (thanks for forwarding)

[joining the svg-ig would be one way to help in the convincing J]


>Speaking of new feature, and to avoid that the filter module misses
some
(features), I wonder how this kind of effect would make sense :

><script>
function myEffect(in, x, y) {
// compute and return the RGBA color
// of the destination pixel,
// with full access to the source raster (in)
}
</script>

><feCustom in="SourceGraphic" function="myEffect" />

>This would allow me to program my own progressive blur, skew,... or any
other crazy stuffs that come in my mind.
"in" would be an object that gives access to the rgba colors of the
input
pixels. "x" and "y", the coordinates of the target pixel. Maybe other
parameters would be useful, but i can't think of any others.
It would make the filter modul turing-complete.
What do you think ? Does it make any sense ?
If it does, should I forward this to the swg-wg...



[For some years now, the request for access to pixel values in SVG has
come up. [1],[2],[3]. Occasionally, I've heard (maybe from the HTML WG
folks) that there are security reasons for not allowing access to pixel
values in web pages. I don't really know why there would be, since one
could use a same-domain policy to prevent any mischief it seems. I think
the presentation of a compelling set of use cases might be what is
needed. Maybe some of the implementers could comment? One of the things
I think would be very handy and useful is to have a bitmap to
vectorization filter (either implemented by the browser) or accessible
through script. I would like to be able to take a bitmap and a few
parameters like smoothness and difference-threshold as input and receive
as output a series of curves (like <path>s) representing a contour (such
as discussed in [4] ). Inkscape and Adobe Illustrator and Adobe
Streamline, as well as NIH image all have those abilities to some
degree. The ability to make on-the-fly animated sequences from such
vectorizations of bitmaps done client-side, would extend our power
greatly. It could also be quite practical when it comes to data sensing
in the field.

Being able to bitblt rectangles of imagery around the screen (as in [3])
might save lots of memory in making jig-saw puzzles, and this also would
involve some access to pixel value. Knowing how far pixels have actually
moved in an <feDisplacementMap> would also be handy.

In general, just being able to do client-side image analysis would be
handy, and I think I remember hearing that access to client side images
through something like <input type=file> is being contemplated within
SVG??? That would ultimately improve security concerns it seems since
right now the web app has to upload bitmaps to a server (through who
knows what intermediaries enroute) rather than allowing direct access
by the client.

<reco>



David]

[1] http://tech.groups.yahoo.com/group/svg-developers/message/52310

[2] http://tech.groups.yahoo.com/group/svg-developers/message/53522

[3] http://tech.groups.yahoo.com/group/svg-developers/message/53849

[4] http://srufaculty.sru.edu/david.dailey/svg/Spec.html



[Non-text portions of this message have been removed]