Since this issue was pointed out by a user recently (and I also found it confusing before reading this task description), I would like to re-open this task for discussion.

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.

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.

Pushed new branch to rMITK MITK: bugfix/T30416-AddUsageHintsToMeasurementView.

The Measurement view is quite a historically grown abomination that would greatly benefit from a complete overhaul. Hence, to keep complexity down to a minimum for the upcoming release, I suggest to not implement canceling but instead to add a hint to the GUI on how to finish continuous planar figures.

Pushed new branch to rMITK MITK: bugfix/T29525-IgnoreLabelSetImagesInPixelValueView.

For now, I suggest the most simple solution which is to ignore label set images all together, as long as we do not correctly support probing pixel values at a certain location. This is a much more complex problem that can be tackled in the future if requested, for example:

It seems to be an issue with this specific dataset. I made new set of segmentations (Prostate label and AIF label) and stored them each as DICOM segmentation. And now I find that the segmentation nodes are found as expected. It needs to be determined if the old data set is somehow corrupted or if it is a backwards compatibility issue (the masks were initially created in 2019).

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.

Agree. SAM and MedSAM can work reasonably well even without GPU. Sorry can be removed.

Have to check if T30420 is fixed.

In T30410#258367, @floca wrote:

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

This was not a valid issue. The real issue was T30403.

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?