Difference between revisions of "Multi Label Segmentation"

From mitk.org
Jump to navigation Jump to search
(username removed)
(username removed)
Line 9: Line 9:
 
== Shortcomings of the current implementation ==
 
== Shortcomings of the current implementation ==
  
* 8-bit images are used for segmentations by default, wasting 7 of 8 byts, occupying far more memory than technically necessary
+
* 8-bit images are used for segmentations by default, wasting 7 of 8 bits, occupying far more memory than technically necessary
  
 
== Wishlist ==
 
== Wishlist ==

Revision as of 13:30, 26 January 2011


Using multiple segmentations with the Segmentation bundle

Following a proposal of Sebastian Ordas to support multi-label segmentations, this page will be used to sketch future changes to the Segmentation bundle and the related framework.

Shortcomings of the current implementation

  • 8-bit images are used for segmentations by default, wasting 7 of 8 bits, occupying far more memory than technically necessary

Wishlist

Implications on the implementation

  • what parts of MITK would need to be changed?
  • what needs to be changed in the Segmentation view?
    • new controls:
      • label manager widget ( e.g. have a QmitkDataStorageTable): should easily allow to (multiple) select labels for visualization or editing/locking toggling, change their representation (filled or border line), enable volume render feedback, etc.
  • avoid connection with Data Manager for data selection (IMHO: the current working/reference node selection approach via the DataManager is not user friendly)

Proposed working plan

  • Stage 1: add lock/edit feature to the current approach
  • For every mitk::Tool, upon finish editing (e.g. mouse release), correct the feedback image for every intersection with other editable/locked segmentations
    • The Segmentation Interpolation should also respect other locked and editable labels
  • Stage 2: do not use binary images any more
  • Stage 3: