Morphological image processing is a very advanced topic, even with a good math background.
Have you tried using OpenCV's built-in morphology operators already ? That might be a good start. ITK also has quite a few operations included (http://www.itk.org). There also are a few commercial libraries such as the SDC Morphology Toolbox which is one of the most complete.

IMHO developing a full-fledged morphology toolbox is quite a daunting task, especially given that it would need to be particularly efficient, as you want to use it for real-time rendering.

The Center of Mathematical Morphology at Ecole des Mines (http://cmm.ensmp.fr/index_eng.html), who pioneered those techniques 50 years ago, have developed such tools over many years, and they're all PhD's

A lot of the advanced methods are patented too, so you might need to research this too.

I'll try to have a look at the papers you cite when I have time though.

Good luck,

Lorcan

You might also want to check out Mamba (MIT license) http://www.mamba-image.org/

for the (squared) euclidean distance transform, my first shot would be to directly translate the pseudocode in this paper:



into actual code, and throw the "difficult case" of Fig. 6 at it for a unit test - consider the test passed, if the result is equal to Fig. 7 B.

a practical pitfall could be that (grayscale) images are typically represented as 2D arrays of bytes (char) - you probably want to use floats instead since the squared euclidean distance is likely to exceed the range of a char. moreover, if you want the non-squared euclidean distance later, you'll have to take the square root of each pixel value which generally results in a non-integer
Last edited by Robin from www.rs-met.com on Thu Aug 02, 2012 10:00 am; edited 1 time in total

hey - i just found a free ebook on image processing:

http://homepages.inf.ed.ac.uk/rbf/BOOKS/PHILLIPS/

it comes also with source code in C - from a first glance, it looks like code for erosion and dilation is also available there. however, these seem to be the binary (not grayscale) versions of the algorithms and i don't see anything about "structuring elements". but it's perhaps a good place to start anyway.

Well I found out two important pieces of information

- The Euclidean distance transformation is a key ingredient of the Bevel and Emboss layer style

- Erosion and dilation is easily calculated from the Euclidean distance transform.

Made some progress with Euclidean Distance Transform:

I think there's a simple solution to that, if you can provide an option so the user can disable the enhanced UI and run the UI in a separate thread. JUCE's thread support is very good, and it has OpenGL texture shaders which could theorietically create layer effects.

Please, don't anyone reply to that nonsense.

[quote="thevinn"]- The Euclidean distance transformation is a key ingredient of the Bevel and Emboss layer style

- Erosion and dilation is easily calculated from the Euclidean distance transform.[/quote]

The Eudclidean transforms are simple enough. Yes, it could be performed in Juce on two images importd into OpenGL with transparent textures for overlays, or non-trapsarect textures with bump maps to emulate Photoshop txextures, with the added benefit that true perspective transformations are also available in OpenGL for free.

looks like the outside of the stroke is nicely anti-aliased but the inside still looks jaggy. how is the EDT used in the context of that outline-stroke style?

i have been looking around a bit for books on the topic but it seems like most image processing textbooks focus on "classic" image processing techniques (filters, restoration, histogram-stuff, etc.) but there seems to be a lack of books on artistic image processing. maybe this is comparable to the situation with signal processing textbooks and books on musical signal processing one or two decades ago.

There is one pixel missing from the interior of the stroke. The distance transform takes as input a binary image where "true" means its a point of interest (distance 0) and "false" means its a point where you want to know the distance from the nearest point of interest.

The reality is that the alpha channel of the layer is 8 bits of alpha levels. So a mask alpha that is fully transparent == 0, fully opaque == 255, and somewhere in between meaning partial coverage. My current implementation assumes that any non zero mask alpha is a "point of interest". Therefore, they don't get stroked.

The solution is to modify the distance transform algorithm to give points corresponding to partially transparent foreground pixels a small starting distance proportional to their alpha value. As most of the fast distance transform algorithms work with integers, this might be accomplished by changing the intermediate distance calculations to fixed point numbers.

Oops, I forgot to actually answer your question!

In my distance transform implementation, a functor is called for each pixel with the squared distance. For the very last step in the range (corresponding to the edge), I compute a transparency level. For all other distances I just fill with a fully opaque colour. This is convenient because it means sqrt() is only called for edge pixels, a dramatic speedup. This is the functor:

void operator() (int x, int y, double distance)
{
  PixelRGB& dest = *((PixelRGB *)&m_dest (x, y));

  if (distance > 0)
  {
    if (distance <= m_radiusMinusOneSquared)
    {
      dest.blend (m_src);
    }
    else if (distance < m_radiusSquared)
    {
      distance = sqrt (distance) - (m_radius - 1);
      uint8 const alpha = 255 - uint8 (255 * distance + 0.5);

      dest.blend (m_src, alpha);
    }
  }
}

Even with that "classic" stuff they all look like disconnected mess of information to me. Perhaps that info should be unified into something useful before anything more added. That's not the case with signal processing textbooks for some reason.

Are you just concerned with having sub-pixel regions of interest?

Photoshop does all it's compositing with alpha channel (aka mask). As long as you build your overlays with alpha, you don't need to calculate the outlines on the fly.

If you do, isn't it just a matter of determining the pixels that contain both inside and outside areas (the border pixels) then setting their alpha according to the proportions of each within the pixel? (With various optimizations available depending on the sub-pixel accuracy you need, which to fool the eye isn't much.)

Also, isn't antialiasing like this built into just about every OS already? Particularly for font rendering?

Frankly I'd rather have a large "filmstrip" in my GUI than waste a nanosecond of CPU time on unnecessary image processing. Anything that can be "canned" beforehand, I'd can. And you can achieve dropshadow and even lighting effects by designing your images and alpha channel right. Like so...

This is more than a simple anti-aliasing.



Calculating the effects at run time lets you do more than can be done with pre-rendered bitmaps. You could overlay a control with glowing edges on top of another element that changes its appearance. Or you can change colours dynamically based on context. There are many possibilities.

But also, this will become part of a system that uses just in time compilation that shows you a preview of your code as you are writing it (disclaimer: I'm not writing that part).