Maybe some extension: it would be nice if a warning could be general for incomplete DICOM files. I recently had a different case where the modality was missing, and at the moment it is quite difficult to figure out what information is missing since there is just a crash with little information.
So if we add a warning here, maybe it could be in a way that works for any required DICOM tags that are missing.

Discussion result: want to do, probably without detailed modified checks

Discussion result: we'll keep the task open. When eMITK builds again for the current state, try to reproduce the crash by going through the Geldosimetry workflow.
If it can't be reproduced, close the task.
If it can be reproduced, depending on the way the error expresses itself, either fix or accept as is.

Pushed new branch to rMITK MITK: bugfix/T30459-mergeGithubPullRequest276.

Pushed new branch to rMITK MITK: bugfix/T30459-mergeGithubPullRequest275.

Could it make sense to add an additional field to the Image Navigator, similar to the "Loc. (mm)" but instead for time? Then both the timestep and the time in (ms) could be shown at the same time.

In a certain sense, the bug would be fixed by making sure the menus are present when the layout changes.
However, it might make sense to rethink the usefulness of these menus in the MxN context, since many features are not usable anyway (e.g. rotation).
The layout management of the rightmost menu can still be used, but might need heavy extension for useful usage. We might redesign it entirely, to make it more general for Std- and MxN-view, or remove it from MxN on purpose.

Yes, this still happens as described above.

Deleted branch from rMITK MITK: feature/T29273-Decouple-TimeNavigationController-from-SliceNavigationController.

Discussion result:
Simplify bounding box interaction / Add simpler version and make it available outside of the Image Cropper

The action makes sense, for the stamping widget we'll have to check if it is used somewhere, and in doubt remove it.

Discussion result: remove

Discussion result: for now, we can live with this being a known issue

I am also in favor of option 3.

Conclusion: still needs subtasks

• can the binary tag be removed?
• convert binary images easier into segmentations
• offer python utility package as a way to convert -> T29389

Conclusion: makes sense to do, will be tackled implicitly in the future.

Discussion: the listed parts can be removed + semantic relations can also be removed (in its current implementation state, because it would need to be reimplemented with property relation rules).

Has been clarified

Conclusion: In general it makes sense, but we would want to get rid of the "locked state" of the perspective. Needs further research if the locked state can be removed easily or be made more clearly visible, e.g. by a UI element.