the default implementation is currently to not overwrite label information if already present in the segmentation image only copy labels from the preview that do not exist.

Hi Ralf,

@ahmadqasim thank you for the additional information. I think we should schedule a VCon or meeting to clarify some things (e.g. some of the information seem to be contradicting) and to ensure that everything is properly understood and we decide for the best design option. Could you arrange a poll? Thanks.

We should discuss if/how we revisit that task. With current hidpi monitors (e.g. our new notebooks), it realy starts to become a usibility issue in my regard.

Sorry! I changed them now.

@ahmadqasim We cannot see the images as their View Policies are too strict (it is an issue with Phabricator). You can change the View Policy afterwards by clicking on the file and you find according settings in the menu.

Hi Ralf,

@ahmadqasim : 3 questions.

1. are you doing semantic seg or instance segmentation. Your description sound in betweenish. So do you want to tag a special region or everything that is labeld with a certain label?
2. was there a special reason why you want to do it via the picking tool? Why not directly editing in the list of labels?
3. What is the time frame when it should be available?

We may be have to sort out some technical details. Currently the view has a hard code name/UI that is defined by MITK Flow policy. MITK Flow expects always to have *one* view with view id="org.mitk.views.flow.control". That id is not very specific on purpose as you could use the MITK Flow with just another set views (e.g. a hypothatical org.mitk.gui.qt.flow.registration plugin) and then have the same work style but for doing registration. By using an id convention for the view that controls the saving/clearence of the data and one well defined perspective (ID = org.mitk.qt.flowapplication.defaultperspective) they are easy interchangable. If we start to reuse them in the normal application it might be a problem as the IDs are not very specific.

Pushed new branch to rMITK MITK: feature/T29432-PreloadFirstTask2.

Original issue resolved, raising priority and leaving open to discuss consequences in the next MITK meeting.

Deleted branch from rMITK MITK: feature/T29432-PreloadFirstTask.

Pushed new branch to rMITK MITK: feature/T29432-PreloadFirstTask.

While the original issue is rather easy to resolve by exchanging the class to data->Modified() with a RequestRenderWindowAll() (which is the actual intent anyway according to the comments), more hurdles start to appear that are not as easy to resolve.

Status: Currently I add 10 MITK-related papers per day to our publications page. Ongoing...

We see and feel you. Considering the circumstances that Ralf mentioned (it's basically an ITK issue/contribution) I would anyway go for a Won't Fix here on our MITK side for now, until ITK provides the functionalities for such data types. Okay? :)

As it is a really nice user-friendly feature, we have a high interest in getting TotalSegmenter integrated soon into MITK.

In T24398#244802, @floca wrote:

Have you pushed your clean ups? Not that your efforts get lost. 😉

In T24398#242008, @kislinsk wrote:

In T24398#241998, @floca wrote:

Our side or also the CTK part.

Hm, lets put it as known issue and discuss its priority when we plan the spring release.

Only looked into our side so far. I'll create a separate task and push my clean-up that I already did so far.

The hash above doesn't seem to be auto-linked. So here it is: rMITKa73e482c0387: moved labelset-related classes out from core

I big leap into the Python direction would be to finally resolve T27923: Integrate possibility to execute Python Code in MITK , which is complete for a while now but we weren't able to figure out why it fails on Ubuntu build clients. Since the ITK v5 upgrade, we also need to adjust a little more I guess.

Adding a data node reset-geometry-action was a first step and enough to tackle this issue. If there are more requirements for some "intelligence", new tasks need to be opened.