cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Want the oppurtunity to discuss enhancements to PTC products? Join a working group! X

Floodfill algorithm

pkluska-2
1-Newbie

Floodfill algorithm

Hi!

 

I am working on a project regarding image analysis (object counting, area dimensions, etc..)

Using 'canny edge detector' I isolate edges and fill object or background which interests me.

I have tried using 'floodfill algorithm' from here:  https://community.ptc.com/t5/PTC-Mathcad/Objects-Counting/td-p/283337  but with bigger matrix, I have encountered 'not enough memory' issue.

 

So I wrote my own 'scanline floodfill algorythm'.

Algorithm is colouring next pixels until it reaches pixel with value '1', then depending on direction in which it colours, and free space, it leaves

seed with value 255(x+1) or 250(x-1). Then it checks the location of seeds and continues with colouring starting from this seed.

s3.bmp

(image is stripy because when writing, it was easier for me to find the loop which leaved UNcolored pixels)

While I was writing my algorythm, it looked promising in terms of performance, but in final form it is very slow.

I have no experience in programming so If anyone would have any idea or advice how to make it faster, it would be perfect.

1 ACCEPTED SOLUTION

Accepted Solutions

I tried my routine from the thread you referred to in your initial posting and I experienced no problems wrt memory (the pic obviously isn't large enough). While this floodfill was much faster than yours when it came to filling just one of the blobs, it was way slower than yours when it came to filling the space between the blobs. It seems to struggle when there are a lot of holes in the area to fill.

It was not fully clear to me what you algorithm does, but it looked a bit inefficient (nor sure, though). So I rather implemented a different floodfill algorithm according to

Flood fill - Wikipedia

which does not use the (self-implemented) stack that heavily as it uses loops for the left-right movements.

This algorithm is much faster than yours or my previous one (45 seconds vs 0,7 seconds on a slow machine) and I hope that it also works with your larger pictures.

EDIT: I just augmented your pic creating a picture with double width and the times were 191 sec vs 1.5 secs. So it looks that the time your algorithm need does not change linear with the picture area.

EDIT2: OK, couldn't resist. Picture with four times the size of yours -> 785 secs vs 3.5 secs

View solution in original post

9 REPLIES 9
-MFra-
21-Topaz II
(To:pkluska-2)

Hi Pan Kluska

The program with this simple modification seems already faster:

semplice modifica.jpg

When in a loop there is a conditional operator, the calculation slows. Just imagine the time required by your program with all conditional operators that are present in  several for loops.

Doing that modification also  to "fill_up" program, the required time is 24.16 "

Best regards

F. M.

Werner_E
24-Ruby V
(To:-MFra-)

I wonder why you don't experience the "invalid index" error which I ran into as described below using the originally posted file and bitmap by Pan Kluska.

Your goal was to speed up your fill routine, but when I try to run you file I get an error as of an invalid array index:

Trace points me to this position in your fill routine:

I am too lazy to debug the large program but I suspect that x wil be 0 and as ORIGIN is set to 0, there is no index -1.

What FM showed sure is better programming habit not to let the program do the same calculation (determine the size of the matrix m) over and over again. It may speed up the framing routine "ramka" but "ramka" has nothing to do with the fill routine, which seems to be the slow part. So to speed up your fill routine a little bit, you would have to apply similar modifications to that routine, too.

BTW, something like

really is bad programming and should be avoided. You have a lot similar constructs in your fill routine, too.

May I suggest something ORIGIN-independent like

-MFra-
21-Topaz II
(To:Werner_E)

Hi Werner,

I focused mainly on the presence of many rows(m) and cols(m). If each of these operations requires 10ns time machine, and if in the program they are called, each, ten thousand times, we would have a delay in total 2 * (10 ^ 4 * 10 ^ (- 😎 s) = 0.2ms, and only for these operations . I'm sorry, but I have not looked into the program for the remaining inconsistencies.

Greetings

F. M.

-MFra-
21-Topaz II
(To:Werner_E)

To have no error, you have to click the right image, the one with all-black background. You can click on a closed domain, in which case the time required is much less than that required by clicking at any point of the image.

click.jpg

click1.jpg

Excuse me, my recommendations are for those interested in the subject, certainly not for you that know the topic for a long time.

Greetings

F. M.

Werner_E
24-Ruby V
(To:-MFra-)

Thanks!

Indeed I forgot completely about providing a valid initial value by selecting the starting point in the picture!

Knowing something and remembering it when needed obviously are two different things 😉

Thank you for replying,

I wrote my program from the beginning, using your advices and it is better.

clip2.bmp

clip3.bmp

I still use ramka(m), because it helps me avoid errors with pixels adjacent with mx,cols(m)-1/mx,0 and m0,y/mrows(m)-1,y.

Besides that, I have experimented a bit and I think that the part that is slowing down my program is:

clip4.bmp

Is there any other way to check "seed" coordinates?


Best Regards

I tried my routine from the thread you referred to in your initial posting and I experienced no problems wrt memory (the pic obviously isn't large enough). While this floodfill was much faster than yours when it came to filling just one of the blobs, it was way slower than yours when it came to filling the space between the blobs. It seems to struggle when there are a lot of holes in the area to fill.

It was not fully clear to me what you algorithm does, but it looked a bit inefficient (nor sure, though). So I rather implemented a different floodfill algorithm according to

Flood fill - Wikipedia

which does not use the (self-implemented) stack that heavily as it uses loops for the left-right movements.

This algorithm is much faster than yours or my previous one (45 seconds vs 0,7 seconds on a slow machine) and I hope that it also works with your larger pictures.

EDIT: I just augmented your pic creating a picture with double width and the times were 191 sec vs 1.5 secs. So it looks that the time your algorithm need does not change linear with the picture area.

EDIT2: OK, couldn't resist. Picture with four times the size of yours -> 785 secs vs 3.5 secs

Hi!
Thank you for your reply. Your algorithm works great. I have even tried it on matrix 2048x1242.

Your wrote it very clearly and thanks to the describtion, it’s easy to understand.Clipboard01.bmp

Thank you,

Kind Regards,

Pan Kluska

Top Tags