@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.

@gaoh / @kislinsk would that integration/workflow something for the MIC meeting pitch?

🎉

thanks again, for solving this issue! So in the current kaapana develop the tasklist feature is now integrated!

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.

Status: Added quite a few papers up until 2020 thanks to a currated list of papers from @floca. For the past two years we now need to look out for papers first.

Pushed new branch to rMITK MITK: feature/T29206-MVC_for_labelsets_v2.

@gaoh I triggered the build of a new Flowbench installer in our CI. Will be ready later today and automatically uploaded. Commit hash: 122321bb.

@gaoh could you verify if the fix work?

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...

@s434n I added my draft with a custom multi node selection widget and several action buttons. There are some things missing and going wrong but this should give you a better overview of the current status.
Things that are not working correctly / are missing:

• thumbnail / pixmap for the data node
• currently the widget is not reacting on node changes (name change or later, thumbnail change)
• moving an item in the list does not change the layer order
• currently the length of the list widget / item is defined by the string and thus the push buttons are not aligned
  • also the whole widget is not extended if a name is too long

Thanks Ralf!

Describe problem has the same root then T26953. But I think for this task here we can have a work around, so that Hanno does not need to wait until the DICOM Seg thing is fixed.

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? :)

Discussed: Proposal is fine, we should do it this way.

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