Urs, I don’t really understand your suggestion for ‘batch processing’. I associate that term with applying the same operation to each item in a set, without the neighborhood relationship and ordering implied by the recursive operations.

That said, Steve’s ‘queue processes’ must be a subdivision of ‘neighborhood processes’. So now we have:

• transforms
• point operations
• neighborhood operations
      – recursive operations
      – spatial filters

Am I missing something?

On a more serious note … if the pixel relationship is static (well-defined when the “search” or “traversal” starts), then “traversal” of the image/graph is a good term.

If the pixel relationship changes “with time” or “during the traversal”, then “traversal” doesn’t really fit (nor does “search”), since “breadth-first traversal” doesn’t envisage the graph changing as you look at it. Neither does “connected components” since things are changing and thus the components are not “fixed”.

Which one is more typical?

What you are really talking about are methods that operate on connected components of a graph (or image). The term “connected components” is a structural term, not refering to exactly how you find them, what you do with them and so on. So it’s not tied to a particular algorithm, but instead to what you want to do with your image (or graph).

Both kinds (and others…) of traversals/searches can be used to find connected components. They just differ in the order that they explore the nodes (pixels) of the graph (image).

So you could refer to algorithms, methods, transforms, or whatever that operate on the connected components of an image (or graph) as a “connected component method”.

That term is also a helpful reminder that if you can precompute the graph the expresses the relationship between pixels (rather than constructing it on the fly when looking at 2 pixels), then you can just use dmperm.

So you could call this a “dmperm-based method” or more generically a “connected component method”.

“connected components” is also a well-established term. It’s much better to use a well-established term (if it applies) than invent a new one.

See http://en.wikipedia.org/wiki/Breadth-first_search

See also: Tarjan, R. E. “Depth-First Search and Linear Graph Algorithms.” SIAM J. Comput. 1, 146-160, 1972.

You could also say “depth-first traversal” (or “depth-first search”) if you just replace the word “queue” with “stack”, and the word “get” with “pop” in your algorithm.

I would stick with an established term like these four (breadth/depth-first traversal/search). They’ve been in use a long time (early 70′s at least). No need to make up a new term; it would just confuse people.

“Queue process” doesn’t extend to the depth-first traversal. It’s a little too generic of a term, as well, since queues can be used for all sorts of things, not just breadth-first traversals.

The term “iterative process” is either far too generic (is it any algorithm with a for loop?) or too specific (is it conjugate gradients for solving Ax=b?).

“recursive process” is also problematic; this is not a recursive algorithm (although it can be written as such).

I prefer “traversal” instead of “search” but the latter is more commonly used. And I see from Steve’s comments #13 and #15 that he’d probably prefer “traversal” to “search” too.