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

After monkey testing in RelWDebugInfo, I think I found a lead. It can happen due to different processing of the Qt event queue that GetLabel is queried in a widget on a label that does not exist anymore. But it is not checked if GetLabel returns nullptr. Which in this case can happen. I hope this will fix the problem..,

We should clarify how we handle the reinit or reinit warning in the Measurement view. Should be very simelar to the Segmentation view.

How to adapt: Use the "clear label" option in the context menue of the label inspector.

hm. I see.
May be:
B + if you press shift while hovering, then always highlight?

In T30417#258648, @kislinsk wrote:

but the disadvantages proved to outweigh.

That you cannot tell. You don't know how testers would react to option A. May be it is equaly irritating to them. And may be they would missing the highlighting of invisible labels if the realy would work with it... 🤔
If we want to base it on user feedback in such an unclear situation, one would need to offer/explain all options and let them choose/poll.

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.

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.

The first version had option B.
I changed it because I thought that UX is better if you have still the posibility to peek/see also the highlight of invisible labels. E.g. in order to pick the right one to make visible again.

Have to check if T30420 is fixed.

I also peeked into the code base. And as also 2D is a mess 🙈.
It would make sense to completle rework and align it with the chaching mechanism of the surface interpolation controler (may be refactor it to use the same interpolation base class or just cover both use cases in the same controller class, because the only difference is the interpolation strategy (generate surface or slice interpolations along a plane normal, and over a method for doing 2D interpolations).
Therfore I am inclined to opt for the following:

@a178n isn't that resolved?

The open sub tasks are still valid. But as TotalSegmentator itself is added, I would close this very task.

thanks for the research. Are you already working on that ticket?

Was this also a problem in the last release?