Some SVG Questions

I have posted some of my experiments, but have yet to mark any "SOLVED."
Please e-mail me at david.dailey@sru.edu with solutions. I will post solutions here, unless you specify otherwise.

1. Is there a way, using filters, to take an image A and produce it photographic negative A', such that 255-C(A)=C(A') for each channel C in {R,G,B)? I've fooled a bit with the filter "feComponentTransfer" with some hints of success, but it seems like so natural a thing that there must be a straightforward way that I'm just missing. Here is an approach that comes close using <feComponentTransfer> together with <feComposite operator="arithmetic">. ComponentTransferComposite.svg. It produces an image which looks like a spectrum-equalized version of the negative.

2. On a related theme, <feBlend/> has modes including "screen", "multiply" etc. Is there a way to create the "difference" between two images (as with the Photoshop difference filter) in SVG? Here's the best I have figured out so far: ImageDiffer.svg.

3. If I deform a simple shape using < feDisplacementMap/> (see for example eggcloning3.svg where the user may unleash fried eggs bouncing and sliding over a radial washboard) is there any way to determine exactly how far an image has been moved by that transformation? id est what is the on-screen locus of a shape deformed by a transformation? If so, then I'd be able to determine RGB values of pixels in the underlying image and that could prove quite handy for other things. Are there other ways to interrogate RGB values of pixels ?  (See some allied issues under question #6.)

4. In the animation, eggcloning3.svg , (discussed in #3, above), I observe that on slower machines its SMIL animation takes precedence over its JavaScript animation. That is, if the browser can't keep up with the SMIL (because there is too much processing going on) it never begins the JavaScript animation. Is there anyway to adjust the relative priorities of these two kinds of events?

5. To make a jig-saw puzzle using SVG, one may

a) chop up an image into little movable chunks using numerous clipPaths applied to numerous copies of an image (see for example, http://srufaculty.sru.edu/david.dailey/svg/clips2.svg). The problem is that this appears to use lots and lots of RAM and bogs down when the number of rows and columns gets large.

b) use feOffset's and feTile's to slice an image (be prepared to wait for it to render). I didn't see any easier way to grab the parts I wanted to move than this. It is way too time-consuming to be practical on a large scale.

c) build a checkerboard of red-scale values underneath the image and then distort the image using  <feDisplacementMap> and the red-channel. See attempt1 or attempt2 by way of illustration. The approach looks like it will be fast and generalize easily to large images with lots of slices. The hassle is that the exact distance by which pixels are moved, while clearly related to the displacement's scale attribute and the red-scale value of the underlying map, seem not to be entirely predictable (see attempt3). The W3C spec actually spells out how the pixel loci will move, so maybe I'm just misreading it.

Is there an easier way? Can I somehow just grab the pixels out of a rectangular section of a bitmap in SVG and move (just) them around? I think I may just be missing something key in the SVG tool set.

6. Has anybody built a "distort" widget which would allow one corner of a rectangular bitmap to be grabbed and moved about, hence distorting (not just skewing) the associated image? It looks like transform="matrix(a,b,c,d,e,f)" always converts rectangles into parallelograms -- can we distort a rectangle into an arbitrary quadrilateral?

7. Do we really need the <animateColor> tag in SVG? We may animate colors using the <animate> tage with, for example, an <animate attributeName="fill" values="red;cyan;yellow;black;green"...> just fine. What else does <animateColor> do for us?

Back to Dailey's SVG page