Page MenuHomePhabricator

[MultiLabel Segmentation] Define desired behavior of fill / erase tool
Closed, ResolvedPublic

Description

The following tasks mention problems with the fill / erase tool and they all boil down to the same issue:

Currently the fill / erase tool works in a way that everything, that is encompassed by the imaginary area the user clicked on, is filled / erased

We have to make a decision how we expect the fill / erase tool to behave and act accordingly.

Revisions and Commits

rMITK MITK
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision

Related Objects

Event Timeline

I looked into the mitkSetRegionTool-class and found the following:

The main work seems to be done with the use of the itkBinaryFillholeImageFilter

  • this filter fills holes inside of a given input image
  • the input image is the working image with a region growing filter applied to it

This means:

  • the region growing filter (ConnectedThresholdImageFilter) fills the selected region using the seed
    • the seed was at the backgrounds so it's 0
    • the bounding contour has value 1 so it's not filled by the region grower

-> we get only the selected region filled with 1's

  • now the BinaryFillholeImageFilter continues with this region grower output and fills remaining holes
    • since the new region is now connected with the other regions, any small area encompassed by the selected area is a hole

I created intermediate output images to show the results of the filters:

  • the region rowing filter output images looks fine
    • depending on the region I clicked I get a simple contour representing the borders of the clicked background region with 0's outsize and 1's inside
  • the binary fill hole filter output image looks incorrect
    • regardless of the region I clicked I always get a single contour (no "concentric contour"), which always encompasses the inner region completely
    • this is probably the desired result for a "fill hole" filter but in this case it's problematic
  • It seems as if the ImageToContourModelFilter simply transforms the binary output image to a contour, so it does not modify the contour after the previous filters.

So naively it would make sense to remove the BinaryFillholeImageFilter and simply rely on the connected regions of the region grower.
I removed the fillhole filter and looked at the intermediate filter image outputs:

  • the region rowing filter output images looks fine
    • nothing changed here since the region growing filter is the first that is applied
  • the image to contour model filter output images looks incorrect
    • regardless of the region I clicked I always get a single contour (no "concentric contour"), which always encompasses the inner region completely

So it seems as if the problem actually lies somewhere in the ImageToContourModelFilter (and the BinaryFillholeImageFilter, but first we need to take care of the former).

The itk description of the itk::ContourExtractor2DImageFilter, which is used inside the ImageToContourModelFilter::Itk2DContourExtraction-function says:

Outputs are not guaranteed to be closed paths: contours which intersect the
 * image edge will be left open. All other paths will be closed. (The
 * closedness of a path can be tested by checking whether the beginning point
 * is the same as the end point.)

As far as I see neither the mitkFeedbackContourTool nor the used mitkContourModel are capable of representing a contour with holes (which eventually results in two closed contours). Please prove me wrong but it seems as if MITK is not able at all to store such a torus-shaped contour model. Has this ever been done before somewhere?

I added a review for changes that describe the current behavior for developers. Actually the description already matched the behavior but I made some slight changes anyway.

kalali added a revision: Restricted Differential Revision.Apr 21 2022, 1:25 PM

Discussion results:

  1. Name of Fill might be missleading. It is more a "Closing" tool. We should think about renaming it. But we keep it for now. But the checklists should be revised as it might imply normal fill tool behavior.
  2. It might makes sense to introduce a real fill tool like you know it from gimp aka.
  3. erase is not realy the antagonist of the current fill tool, thus using the same implementation is illposed. (see details in [T29078])
floca added a revision: Restricted Differential Revision.Sep 28 2022, 9:15 AM
floca moved this task from Segmentation to Cycle on the MITK (v2022.10) board.
floca added a revision: Restricted Differential Revision.Oct 4 2022, 4:15 PM