Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Special pages
Niidae Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Flood fill
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Walk-based filling (Fixed-memory method)== A method exists that uses essentially no memory for [[Pixel connectivity|four-connected]] regions by pretending to be a painter trying to paint the region without painting themselves into a corner. This is also [[Maze-solving algorithm|a method for solving mazes]]. The four pixels making the primary boundary are examined to see what action should be taken. The painter could find themselves in one of several conditions: # All four boundary pixels are filled. # Three of the boundary pixels are filled. # Two of the boundary pixels are filled. # One boundary pixel is filled. # Zero boundary pixels are filled. Where a path or boundary is to be followed, the right-hand rule is used. The painter follows the region by placing their right-hand on the wall (the boundary of the region) and progressing around the edge of the region without removing their hand. For case #1, the painter paints (fills) the pixel the painter is standing upon and stops the algorithm. For case #2, a path leading out of the area exists. Paint the pixel the painter is standing upon and move in the direction of the open path. For case #3, the two boundary pixels define a path which, if we painted the current pixel, may block us from ever getting back to the other side of the path. We need a "mark" to define where we are and which direction we are heading to see if we ever get back to exactly the same pixel. If we already created such a "mark", then we preserve our previous mark and move to the next pixel following the right-hand rule. A mark is used for the first 2-pixel boundary that is encountered to remember where the passage started and in what direction the painter was moving. If the mark is encountered again and the painter is traveling in the same direction, then the painter knows that it is safe to paint the square with the mark and to continue in the same direction. This is because (through some unknown path) the pixels on the other side of the mark can be reached and painted in the future. The mark is removed for future use. If the painter encounters the mark but is going in a different direction, then some sort of loop has occurred, which caused the painter to return to the mark. This loop must be eliminated. The mark is picked up, and the painter then proceeds in the direction indicated previously by the mark using a left-hand rule for the boundary (similar to the right-hand rule but using the painter's left hand). This continues until an intersection is found (with three or more open boundary pixels). Still using the left-hand rule the painter now searches for a simple passage (made by two boundary pixels). Upon finding this two-pixel boundary path, that pixel is painted. This breaks the loop and allows the algorithm to continue. For case #4, we need to check the opposite 8-connected corners to see whether they are filled or not. If either or both are filled, then this creates a many-path intersection and cannot be filled. If both are empty, then the current pixel can be painted and the painter can move following the right-hand rule. The algorithm trades time for memory. For simple shapes it is very efficient. However, if the shape is complex with many features, the algorithm spends a large amount of time tracing the edges of the region trying to ensure that all can be painted. A walking algorithm was published in 1994.<ref name="94Henrich">{{Cite conference |title=Space-efficient region filling in raster graphics |last=Henrich |first=Dominik |year=1994 |conference=The Visual Computer |pages=205β215 |doi=10.1007/BF01901287 }}</ref> === Pseudocode === This is a pseudocode implementation of an optimal fixed-memory flood-fill algorithm written in structured English: ; The variables * <code>cur</code>, <code>mark</code>, and <code>mark2</code> each hold either pixel coordinates or a null value ** NOTE: when <code>mark</code> is set to null, do not erase its previous coordinate value. Keep those coordinates available to be recalled if necessary. * <code>cur-dir</code>, <code>mark-dir</code>, and <code>mark2-dir</code> each hold a direction (left, right, up, or down) * <code>backtrack</code> and <code>findloop</code> each hold Boolean values * <code>count</code> is an integer ; The algorithm : NOTE: All directions (front, back, left, right) are relative to <code>cur-dir</code> set cur to starting pixel set cur-dir to default direction clear mark and mark2 (set values to null) set backtrack and findloop to false '''while''' front-pixel is empty '''do''' move forward '''end while''' jump to START MAIN LOOP: move forward '''if''' right-pixel is inside '''then''' '''if''' backtrack is true '''and''' findloop is false '''and''' either front-pixel '''or''' left-pixel is inside '''then''' set findloop to true '''end if''' turn right PAINT: move forward '''end if''' START: '''set''' ''count'' to number of non-diagonally adjacent pixels filled (front/back/left/right ONLY) '''if''' ''count'' '''is not''' 4 '''then''' '''do''' turn right '''while''' front-pixel is inside '''do''' turn left '''while''' front-pixel is not inside '''end if''' '''switch''' ''count'' case 1 '''if''' backtrack is true '''then''' set findloop to true '''else if''' findloop is true '''then''' '''if''' mark is null '''then''' restore mark '''end if''' '''else if''' front-left-pixel and back-left-pixel are both inside '''then''' clear mark set cur jump to PAINT '''end if''' end case case 2 '''if''' back-pixel is not inside '''then''' '''if''' front-left-pixel is inside '''then''' clear mark set cur jump to PAINT '''end if''' '''else if''' mark is not set '''then''' set mark to cur set mark-dir to cur-dir clear mark2 set findloop and backtrack to false '''else''' '''if''' mark2 is not set '''then''' '''if''' cur is at mark '''then''' '''if''' cur-dir is the same as mark-dir '''then''' clear mark turn around set cur jump to PAINT '''else''' set backtrack to true set findloop to false set cur-dir to mark-dir '''end if''' '''else if''' findloop is true '''then''' set mark2 to cur set mark2-dir to cur-dir '''end if''' '''else''' '''if''' cur is at mark '''then''' set cur to mark2 set cur-dir to mark2-dir clear mark and mark2 set backtrack to false turn around set cur jump to PAINT '''else''' if cur at mark2 '''then''' set mark to cur set cur-dir and mark-dir to mark2-dir clear mark2 '''end if''' '''end if''' '''end if''' end case case 3 clear mark set cur jump to PAINT end case case 4 set cur done end case '''end switch''' end MAIN LOOP ===Advantages=== * Constant memory usage. ===Disadvantages=== * Access pattern is not cache or bitplane-friendly. * Can spend a lot of time walking around loops before closing them.
Summary:
Please note that all contributions to Niidae Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Encyclopedia:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Search
Search
Editing
Flood fill
(section)
Add topic