Undo/redo is a known problem, covered by other tickets.
The crash propblem I was not able to reproduce.

Hm, yes, As we also define a reference image like in the segmentation view. I think it is the most pragmatic and consistent approach to introduce the same/simelar behavior:
warn users if the rendering is not alligned with the reference image and only allow making planar figures if the geometry was reinit.
I am not sure if reinit as soon as the click on a planar figure button wouldn't be irritating.

With a reinit it works but boy is this unintuitive for users. Like when starting the Workbench and opening brain.nrrd, there's no indication that a reinit is necessary (and what a reinit is and where to find it is another story). You can draw a planar figure on it just fine.

I cannot reproduce the "bug".
But it is not realy a bug but correct. If you do not reinit on brain.nrrd before making the planar figure, it is tilted. Therefore no statistics can be computed.

Have to check if T30420 is fixed.

Resolved with T30390

does it still happen?

This fitting task was applied not to many cases, therefore AVID batch processing was not required and fitting was done in MITK using the formula parser.

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.

Hi there! 🙂

Hi there! 🙂

Hi there! 🙂

Not clear when and how it happens. Need to narrow it down more.

In T30157#253717, @fedorov wrote:

offer the feature to take an instance UID that is an int as the pixel value.

Not sure if I understand it correctly, but ... DICOM UID cannot have int as the value - this would violate VR constraints.

offer the feature to take an instance UID that is an int as the pixel value.

T29204 should be done before as we need to store the information in an appropriate way. The most important thing is that we have then a property to store the instance UID. The default UID is the pixelvalue if not overwritten by the user or another configuration. Regarding the persistance of the pixel value I see two option:
a) Leave with the fact (and document it) that DICOM Seg is not "loss less" regarding the pixel value. So after saving to and loading from DICOM Seg your label will have the same (class) name and instance UID but might have a different pixel value.
b) offer the feature to take an instance UID that is an int as the pixel value. But this is only possible if we assure in our UI that you cannot use/change into an instance UID in a Segmentation that is alrready used there by another label.
Currently I would lean to a) and generate a new ticket for b) and see if we need it in the future.

MITK v2022.10

Sounds good Ralf - happy to help!

@fedorov Thank you for your quick reply and verification for my assumption (I hoped, that I might have overlooked some broader interpretablility...)

" increase monotonically by 1" could be interpreted as "no holes allowed". We should clarify if this is the case.

The formula for the 23Na-MR data analysis is:

What is the status here?