Regionalize operator flood fill algorithm can fail depending on tile order

[GoogleCodeExporter]

In its present form, the flood-filling algorithm is dependent on the order of 
tile computation. The 
problem is with the handling of carry-over regions (those that extend across 
tile boundaries).

The carry-over code handling needs to be redone.

If we do this, and allow arbitrary tile computation order, then then the 
numbering of regions may 
differ between two runs with the same source image. As long as it is made clear 
to users that the 
numbering is arbitrary this may not matter.

The only way to make the region numbering consistent between runs is to impose 
an order on tile 
computation (e.g. by processing the whole image and caching the results). Can't 
see any compelling 
reason to do this right now.

Original issue reported on code.google.com by michael.bedward@gmail.com on 3 Sep 2009 at 10:13

[GoogleCodeExporter]

Bah !  Realized that my 'logic' above is flawed. Tile computation must be done 
in some fixed order to avoid 
artefacts across tile boundaries

Original comment by michael.bedward@gmail.com on 4 Sep 2009 at 3:56

[GoogleCodeExporter]

Rewrote the RegionalizeOpImage to work with a DiskMemImage so that the flood 
filler can fill regions across tile 
boundaries. 

Original comment by michael.bedward@gmail.com on 15 Sep 2009 at 12:16

• Changed state: Fixed