Page MenuHomePhabricator

Redesign storage of ImageDataItems in Image
Closed, WontfixPublic

Description

ImageDataItems represent different image parts (e.g. slice, volume, channel) and point to corresponding memory areas. Unfortunately, ImageDataItems aren’t available at all times, they are created on demand. This behavior impedes several aspects from const-correctness to thread-safety and therefore blocks several image bugs.

I recommend removing this on-demand behavior in order to make progress regarding mitk::Image and its legacies. The Initialization of images would then require an initialization of all necessary/possible ImageDataItems.

Event Timeline

During working on T17931 the mitk::Image class got considerably more const-correct. This involved making a few member variables of mitk::Image mutable, especially the containers holding ImageDataItems.

With the point-of-view that const methods should imply thread-safety, all const-methods accessing the mutable members now use a locking strategy to guarantee consistency during concurrent reads.

This should allow a safe (and still on demand) creation of ImageDataItems in multi-threaded scenarios, e.g. be requiring a mitk::ImageReadAccessor from a const mitk::Image instance from multiple threads.

The mitk::Image class as a whole is still not thread-safe. However, these changes should allow the usage of read/write accessors in a multi-threaded scenario.

I would therefore propose to close this bug unless there is more discussion needed.

kislinsk added a project: Bulk Edit.
kislinsk removed a project: Bulk Edit.