Euclidean Distance Transform

Mostly a request, and also a shoutout to Sphinx who may have cracked this already.

What is it? Basically, you take a binary image (black/white), say that white defines the shape, for each white pixel, you give it a value that is it's distance to the nearest non-white pixel.

Ideally, a solution could be found that used a choice of whatever distance metric you wanted, like Euclidean, Manhattan or Chessboard distances.

Why? This surprisingly simple mathematical operation is the basis for the hallowed "Bevel/Emboss" layer style in photoshop, which is itself the basis for a whole world of graphical design techniques.

Yes, I did solve this, but the filter is not very generic - it currently relies on a certain image size to work properly. I'm hoping for FF to add more control logic for gray properties so I can control radius settings in relation to pixel "size". I know a way to work out the pixel/percentage ratio, but I can't connect the result to radius properties (green don't mix with gray props). It would be awesome if they added a sampled "control", i.e. a gray module that takes one sample from a green sampler source and use that for the grey constant output.

Alright, here you go. Minimum radius and threshold clipping settings are relative to image size. The filter was designed for 600x600 px, other sizes might result in wrong intensity steps etc.





Distance.ffxml

Yes exactly. Basically what is going on is this:

We take the initial binary shape and multiply it with a small value to avoid running into range clipping (no HDR support in min,max perc. components). This is the initial sum buffer.

Then we start the expansion:

Expand sum by 1 pixel, add to sum (gradient span now: 2 px)
Expand sum by 2 pixels, add to sum (gradient span now: 4 px)
Expand sum by 4 ..
Expand sum by 8 ..
Expand sum by 16 ..
Expand sum by 32 ..
Expand sum by 64 pixels, add to sum (gradient span now: 128 px)

The numbers above are the theoretically correct ones, but in FF you don't get to deal with pixel spans, so thats why the current settings relate to the image size. I can figure out the percentage value equivalent to one pixel, but this is in green sample connection and I can't use that to set the min. radius. Perhaps the scale transformation can solve this.

In addition to the expansion accumulation I do some clipping which drastically reduces memory usage and processing time (without clipping its like 20-30 secs for 600x600, with clipping its relative to the actual shape size, often only a few secs of processing).

For simplicity I only show either inner or outer distance transform. The really cool thing is that you can do both with little extra overhead (hint invert the original shape and plug it into another channel, clipping needs tweaking though).

Oooh, nifty.
2 things: first is that I think you still have LDR clipping issues, I'm getting confused as to what I've changed and why, but I had to drop the initial multiply to 0.5. Second, as far as I can tell, you ARE dealing with percentages, you've figured out a really neat way of making 1% = 1px, but your power of 2 scale stops at 96%, so the large areas in your example shape (which is really cool btw I'll be stealing that idea ) have flat top areas, I've attempted to fix this with a hacked solution involving 1 final Min step with a wierd If step where the flat area (those equal to 0.64 RGB values) is replaced with a down-scaled sample from the final min step, but that seems to hang FF o.O.

It's also slow as hell.

Yeah, the flat areas are there because the expansion chain is not long enough. Its possible to add more first in the chain (i.e. radius 0.5 and 0.25), but the scaling needs adjustment relative to that.

While this scaling trick seems to work, its not working well with the threshold clipping. When I add that, the filter takes forever (10-15 mins :-S). I think the scaling has some nasty internal consequences (extremely large temporary bitmaps or something). The scale hack is not that attractive after all. I wish we had more options for controlling / working with grey constant inputs - remap options are too limited for this stuff.