Page MenuHomePhabricator
Create Task
Maniphest T2351

Discuss integration/support of bit images in MITK
Closed, WontfixPublic
Actions

Description

Background: Segmentation results are in most cases stored as single char images. This wastes a huge amount of memory.

Comment from the MITK mailing list:
Hi guys,

I wanted to hear your opinion regarding two possible ways of reducing memory requirements in handling segmentations in MITK.

So far, a separate binary image is used to handle each segmentation, right?. This in principle means a lot of memory waste, as each segmentation has to have the same size as the reference image (also in RAM). The pixel size is 8bits, but still, a lot of memory. The option of cropping the segmentation (e.g. by the AutoCrop filter) to a reduced size is always present; but this is not optimal as the user may want to continue segmenting in other regions in a new work session.

A way of reducing this memory burden could be to use 1-bit binary
images: http://insight-journal.org/browse/publication/646. Do you think it's feasible to adapt mitkImage to cope with itkSingleBitBinaryImage?

Another solution would be to have all segmentations into a single labeled image (like e.g. in Amira). The classes contributed to ITK in
http://insight-journal.org/browse/publication/176 look very promising to this aim. What do you think?

Do you see other approaches?

thanks for the great job
sebastian

Event Timeline

• schwarzt added projects: MITK, Bugzilla.Aug 5 2009, 3:54 PM
neuhaus added a subscriber: neuhaus.Aug 5 2009, 5:46 PM

Currently, the InteractiveSegmentation Bundle stores changed slices as runlength encoded images in the undo stack.

For regular images that are renderered, it is difficult to change the memory layout. mitk::Image is not a itk image and therefore we can not ensure that itk PixelAccessors are always used to access the image data (e.g. by 2D mappers).

maleike added a subscriber: maleike.Aug 6 2009, 9:24 AM

I see two options here:

1: using multi-label images in InteractiveSegmentation

In general, MITK can handle multi-label images. Some internal applications do this. However, none of the classes in InteractiveSegmentation expects segmentations in such a format. The whole thing is built around the assumption that one DataTreenode hold one Image/Surface and this in turn represents one structure of interest.

2: using the single-bit classes proposed for ITK

This would leave the application-level with the "one mitk::Image -- one segmentation" concept. However, this would require a major change in mitk::Image, Rendering, some Algorithms and IO. Even some application code expects the contiguous memory model (e.g. the region grower tool is based on old and ugly low level code). It could be technically possible to let an mitk::Image generate contiguous char memory blocks on request.

Ivo, you know mitk::Image best. What is your opinion on feasibility and consequences?

maleike added a comment.Jan 13 2010, 5:29 PM

Assigning this to default assignee because mbi-bug-manager is not a person and cannot evaluate/reassign this bug. Would you please assign it to the correct product/component and estimate whether it is relevant for the 1.0 release? Thank you.

nolden added a subscriber: nolden.Jan 18 2010, 1:23 PM

Marking as not 1.0 relevant.

nolden added a comment.Mar 16 2011, 4:36 PM

Ok, this is the original bug, also contains a post by sebastian. Please reassign if appropriate.

nolden added a comment.Jul 27 2011, 2:42 PM

Resetting all bugs without active assignee flag to "CONFIRMED". Change status to IN_PROGRESS if you are working on it.

maleike added a comment.Jun 25 2012, 2:31 PM

Discussion is dead, so I'm closing the bug

kislinsk reopened this task as Open.Jun 27 2018, 1:05 PM
kislinsk added a project: Bulk Edit.
kislinsk closed this task as Wontfix.Jun 27 2018, 1:10 PM
kislinsk removed a project: Bulk Edit.
MITK · MIC · IMSY · DKFZ