Is this still an open thing?

In T29650#248947, @gaoh wrote:

@k656s has an example dataset. I am still at the release version before (I think 2022.10?) but I will update to the current release. Could this already help?

Yes, it could. I thought something like this was already introduced. @kislinsk, or?

what is the problem here/where do you lose the other channels? shouldn't it work out of the box already?

@gaoh do you have example data to reproduce this situation. That would help to replicate it and search for the best solution.
Which version of MITK was it?

That is a first shorted list. Other apps and plugins are already ruled out (e.g. due to Vigra dependency). We no shuold assess which of those can really stay in the main mitk repo.

thanks for taking care. 🙏

they are ok

What is the status here?

please ask tanja before I say something wrong.

No that should not happen. What is the rest of the stack trace? Does it fail to clone a layer image or the LabelSetImage itself?

I don't understand the propblem. It behaves like it should. If you ignore locks and transfer all otsu labels, all other labels of a group will be wiped (but still the label exist, as tools do not delete label instances but only pixels), because otsu covers all pixels.

Pushed new branch to rMITK MITK: feature/T29606-Add_MatchPoint_MiniApps.

🙏

As we now have preferences at the module level that can be done even in a better way. Now the mapper can set the default node settings for rendering if not already done. No need to have it handled by the reading code anymore.

I reeopened because I would like to llok into the feature branch at least and see what might be of interest:

@a178n Could you verify if the problem still exist or if it is fixed?

I can now tell at least why you can paint into other windows.

See the point and would agree. But I am biased as I never liked the feature ;).

Important as long as we do not know if it hints to a more fundamental underlying problem.