Deployment configurations were completed. A user guide was added to the Readme file in the root folder.

(I was painting in axial slice which was 2048x2048)

Fixed by T28753

In T28763#229375, @floca wrote:

May be I do not understand the problem right. But the described behavior sounds correct to me. Flood fill should stop on another (not the label you clicked on (including background) label boundary. The only thing you could discuss is wether it is important if another label is locked or not.

May be I do not understand the problem right. But the described behavior sounds correct to me. Flood fill should stop on another (not the label you clicked on (including background) label boundary. The only thing you could discuss is wether it is important if another label is locked or not.

Thanks for the feedback.

Some related issues remain and can be found here:

• T28630
• T28741
• T28677
• T28279

I stumbled upon this since @s434n and I worked a lot on the interaction in the last weeks.
We fixed something related to mouse-interaction in the image cropper plugin, see e7f6648cd685.
Before these changes were merged into develop (so e.g. using the latest Installer v2021.02) the user was able to set the cross hair while clicking inside the bounding box using the PACS mode.
So to reproduce what would happen using the second idea:

• create a bounding box
• enable PACS like mouse interaction (cross hair)
• click inside the image and see how the cross hair is moved
• drag the bounding box and see how the cross hair is moved as well (undesired)
• this is even worse with other PACS interations, e.g. "Scroll"

In T28756#229271, @floca wrote:

Found the problem. It is not a error in the picking tool.

It is in

void mitk::LabelSetImage::ClearBuffer()

Because AccessByItk (which is used there) by default only supports 2D and 3D. -> Exception when trying to reset dynamic LabelSetImages.

So far I see the following solutions:

1. Add 4D as a CMake default (but would impact a lot of code...)
2. Add in clear buffer a check if instance is 4D and if so explizitly call it for 4D (in other cases use AccessByItk as we did so far.

@kislinsk Do you see an other option? Which one would you choose?

strange... the color in here is displayed correctly. It's then my png viewer that must be messing things up...

Found the problem. It is not a error in the picking tool.

I raised it back to normal, as it becomes very relevant for tools like nnUnet. So we should consider it for next spring release when we make the planning in a month.

Pushed new branch to rMITK MITK: feature/T28464-new-add-tool.

it still is very relevant and I have a master student working on the project right now. Is there a chance to contact you directly via Email?

This issue was mentioned on 18.Oct.2021 by Fabian as his comment on the upcoming nnUNet tool.
This issue could be a duplicate. If so, please mark it as such.

Testing if both Segmentation Utilities and Multilabel Segmentation Utilities have the same functionality:

• For 3d data, a surface (or surfaces, depending on the case) was created by doing a 3d-interpolation of the masks in different 2d views. Data Used: MITK-Data/brain.nrrd.

Deleted branch from rMITK MITK: release/T28750-2021-Week-42.