In the MitkNodePredicateGeometry to precision is set to 1e-6. So this is at least one of the issues why the old masks are not found. It could be an option to relax the precision, but since the rotation matrix might have a large effect even for small inaccuracies, it needs to be thoroughly tested first how big the effect is if. e.g 1e-4 is accepted.
For now, the new segmentation masks are provided as test data instead of the old masks.

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

This is a good idea.

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

In T30417#258666, @floca wrote:

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... 🤔

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.

Yes, I agree. Well, not completely I guess, since I vote for B. The current state confused all testers (and me at first when I double-checked what's going on, and after I understood I still would consider it a bug in this state). I see the good intentions why you changed it from initial B to something else, but the disadvantages proved to outweigh.

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.

The tools are not useing InitializeByLabeledImage anymore. If speed is still a problem, please reopen.

I would tend to remove it.

Discussion: How important is that?

Yes, this is a bug. All ITK-based objects should call Modified() in their setter methods, if the values actually changed.

I would change the checklist. With the multilabel support it makes sense to keep it open, if you have confirmed an interpolation, because you might directly go to the next label and confirm there as well...

More context:

• There's already MITK_CUSTOM_REVISION_DESC, which allows to change the tag/commit hash that is displayed in the Workbench as version like "v2023.12" and I think also in the package names generated by CPack.
• Exclusion/visibility of views, toolbars, and perspectives will be part of our customization efforts for the upcoming release and is scheduled to be implemented in March.
• Toolbar visibility is already implemented (just recently) as preferences.