Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there a parallel flood fill implementation?

I've got openMP and MPI at my disposal, and was wondering if anyone has come across a parallel version of any flood fill algorithm (preferably in c). If not, I'd be interested in sketches of how to do parallelise it - is it even possible given its based on recursion?

Wikipedia's got a pretty good article if you need to refresh your memory on flood fills.

Many thanks for your help.

like image 789
mchen Avatar asked Dec 27 '12 14:12

mchen


People also ask

What are the three flood fill techniques?

The traditional flood-fill algorithm takes three parameters: a start node, a target color, and a replacement color.

How are flood fill algorithms implemented?

In fill algorithm, we start from a specified interior point (x, y) and reassign all pixel values are currently set to a given interior color with the desired color. Using either a 4-connected or 8-connected approaches, we then step through pixel positions until all interior points have been repainted.

What are the disadvantages of flood fill algorithm?

Disadvantages of Flood Fill:Flood fill algorithm is not advisable for filling larger polygons as quite larger stack is requiredfor them. Also it is slow since it requires a recursive function call to be given to the getpixel() commandtime and time again. It is an easy way to fill color in the graphics .

Is flood fill recursive?

Flood fill is usually implemented as a recursive algorithm which makes four recursive calls. Each recursive call tries going north, south, east, and west. To avoid infinite recursion, some method is needed to prevent repeating the same positions in the array.


1 Answers

There's nothing "inherently" recursive about flood-fill, just that to do some work, you need some information about previously-discovered "frontier" cells. If you think of it that way, it's clear that parallelism is eminently possible: even with a single queue, you could use four threads (one for each direction), and only move the tail of the queue when the cell has been examined by each thread. or equivalently, four queues. thinking in this way, one might even imagine partitioning the space into multiple queues - bucketed by coordinate ranges, perhaps.

one basic problem is that the problem definition usually includes the proviso that no cell is ever revisited. this implies that each worker needs an up-to-date map of which cells have been considered (globally). mutable global information is problematic, performance-wise, though it's not hard to think of ways to limit the necessity for propagating updates globally...

like image 61
markhahn Avatar answered Oct 08 '22 19:10

markhahn