This task is closed since the ModelFit/Perfusion views will be part of MITK v2024.06 and it is planned that they will be part of the official releases from MITK v2024.06 onwards.

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.

Already removed

Pushed new branch to rMITK MITK: feature/T30447-totalseg-levelwindow.

Pushed new branch to rMITK MITK: feature/T30430-python-venv-check.

I compared the geometry of the dynamic image, the old mask (which could not be found anymore) and a new mask (is found), using the Details info box in MITK. I found small differences in the geometries between the old mask and the dynamic image, but not between the new mask and the dynamic image. Namely:
Spacing:
dynamic image: [1.0156, 1.0156, 5.99998]
old mask: [1.0156, 1.0156, 5.99997]
new mask: [1.0156, 1.0156, 5.99998]

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

Could also verify with Ubuntu and macOS installers that it only seems to happen on the Windows installers with Qt 6.6.1. Close as resolved.

Qt 6.6.3 is the latest version of the Qt 6.6 range. I upgraded e230-nuc03. e230-nuc01 is not accessible via Remote Desktop because of expired credentials, have to upgrade later in office. Ubuntu 20.04 and 22.04 clients already build with Qt 6.6.2.

I was surprised not being able to reproduce this issue anymore with my local build. I then tested the snapshot installer and I was able to reproduce. The only difference I see is Qt 6.6.1 (installer) vs. Qt 6.6.2 (local). I will upgrade Qt on our Windows CI clients and check again...

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

Deleted branch from rMITK MITK: bugfix/T26934-FixLogoAnnotation.

Pushed new branch to rMITK MITK: bugfix/T26934-FixLogoAnnotation.

Deleted branch from rMITK MITK: bugfix/T26934-FixHighResScreenshots.

Pushed new branch to rMITK MITK: bugfix/T26934-FixHighResScreenshots.

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

Deleted branch from rMITK MITK: bugfix/T30414-MakeIndexDefaultPage.

Pushed new branch to rMITK MITK: bugfix/T30414-MakeIndexDefaultPage.

In the past we used the XLST functionalities from Qt 5 to remove certain parts for the help files. Since Qt 6 we removed the transformation as it is not easy to set up a feasible alternative with libxml for example. The downside now is to have a little bit more clutter in the Help Contents. Since the Help Index still looks like the Help Contents before, I think we should simply change the default view of the Help Perspective to Help Index and live with the Help Contents as-is.

Deleted branch from rMITK MITK: bugfix/T30416-AddUsageHintsToMeasurementView.

Deleted branch from rMITK MITK: bugfix/T30413-FixBlankHelpPages.

Pushed new branch to rMITK MITK: bugfix/T30413-FixBlankHelpPages.

The task will be addressed after migrating the install options into Preferences. Then the status update for installation will be implemented for all "AI" tools.

RFD result: Remove the functionality

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.

Pushed new branch to rMITK MITK: feature/T30426-doc-updates.

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.

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.