Current status: The LevelWindow class has a weak cohesion and to many jobs
- It is used to implement business logic to deduce level window bounds (e.g from an image) or to check/ensure consistency
- As data class to communicate level window and possible ranges between rendering manger and LevelWindowWidgets
- As data class to store the level window bounds (in the LevelWindowProperty) as a rendering property for a data node
I think it would be better to seperate jobs. One class (case 1) that can be used to establish value bounds (given e.g, an image or just by direct setters) and another class (or two if we want to seperate case 2 and 3) to store rendering information in the node. For case 3 it would be also an option to store it in several simple value properties (2 or 4 double properties) instead of a custom one (like it is currently done). I also think that is redundant and potentially errorneous to store the value range in case 3 as node property. The value range is an intrinsic property of the data itself. No need to replicate it. In T24886: MITK workbench freezes due to infinite loop in QmitkSliderLevelWindowWidget::paintEvent this behavior is also part of the problem for data loaded from MITK session files.