Will be resolved/obsolete with current utilitie rework-

This task is closed and will be worked on as part of task https://phabricator.mitk.org/T30217.

This task is closed due to task duplication and will be further taken care of in https://phabricator.mitk.org/T30238.

Deleted branch from rMITK MITK: bugfix/T27744-ReviseModelFitDemo.

Hi there! 🙂

Hi Ralf,

@a178n the changes in D816 should offer everything to solve the problem. I also adapted TotalSegmentator Tool. But you should verify that it works as expected.
Basically the tool should now change the labels in the preview as they like (see Otsu and TotalSegmentator for example) and use the TransferMode AddLabel. Then the labels (with all there settings) of the preview image will be added instead of mapped.

I don't think it is necessarily a bug, but rather unintuitive how it works. The recentering is not triggered by the clicking of a node, but via changes in the selection. One can also do things like select multiple lines (on different slices), then deselect one, and the view recenters to one of the still selected nodes.
For me, it would feel more intuitive if the view just recenters every time a node is clicked, regardless of the selection. But there is no bug apparent to me here.

Deleted branch from rMITK MITK: bugfix/T29348-ImproveWelcomePage.

Pushed new branch to rMITK MITK: bugfix/T29348-ImproveWelcomePage.

I designed a few mouse navigation icons and put together a first HTML draft:

Okay, cool. Do you proceed and adapt the checklist to close this task?

The way the masking is done inside the QmitkImageMaskingWidget of the segmentation-plugin is different but it works as expected and is easy to understand.
As written in the task description the QmitkImageMaskingWidget of the multilabelsegmentation-plugin provided different options, but they were not used so I think we are safe here.

So far only the minimum was implemented as transparent. So I would not change anything right now.
And before changing it in one color palet, I would tend to think of making it a general feature of the LookupTable class, to say that its visualization is clamp (thus everything outside the lut window gets transparent. (but that would be a new feature request/idea).

From testing, it seems to work correctly in one direction. Everything below the level window is transparent (i.e. black) while everything above the level window is dark red, as the maximum end of the colormap. If this is the desired behavior, it works for me. If we want the upper part to also be transparent, then it is not quite right yet.

With {D744 } being landed we need to check if this also applies for the single remaining Segmentation Utilities view.

I added a task in the "smoothed polygon" section:
Task

extend one segmentation to multiple neighboring slices to create a “3D” segmentation

Result

The segmentation mask is rendered on multiple neighboring slices.

I removed the „Smoothed surface creation“ Preference section from the Segmentation - Options checklist.

We discussed this and we decided to remove the options from the preferences completely. This will be done in the mentioned task T28793: [Segmentation][Multilabel][Options] Changing only decimation rate has no visible effect in "Create smoothed polygon model".

I think there may have been a misunderstanding in this task. With the current description, I am not able to reproduce the problem (zoomed in image when loading).
From the mentioned checklist, I understand it that the tester zoomed in himself, as the checklist recommends, to see if the crosshair is aligned with the pixels. The comment only says "Problem with the brain image. The other are working. Attachment 1", so I assume the image is only to illustrate this.
So the only problem is that brain.nrrd is not pixel-aligned automatically when loaded, only after doing a reinit. I think this step in the checklist is worded a bit unclear anyway, so it's probably best to just improve that instruction and I think that's it.

I tested this and the smoothing works but as stated in the description it should be made more obvious what to do.
As @kislinsk wrote we will not tackle this issue here but instead remove the options from the preferences. However, this is more about the context menu action "Create smoothed polygon model". Should the whole action be removed? Or are we only talking about the additional preferences for "Smoothed surface creation"? If only the preferences should be removed we still need to adapt the checklist to make it more clear how a smoothed polygon should be created.

The confirm string should not be changed. Result of the discussion was only to change the clear string.

A short but clear description of the interaction types is given in the MITK StdMultiWidget Editor help page (F1 on "StandardDisplay"):

I changed the strings according to the suggestions in this task.
However, your last comment only stated to rename the "Clear Segmentation" button.

I updated the "Checklist Segmentation – 3D Segmentation_EN":

• updated tool-image (no region growing, new icon for Picking and GrowCut)
• removed region growing test section, changed order of tool sections
• updated Otsu-tool GUI image
• added description of "Transfer ..." checkboxes
• modified description of "GrowCut"-tool