This context and code artifacts referred in this issue seems obsolete or changes. The issue needs to be rephrased if not closed.

theoretically yes, but I guess it is not relevant. Since we now use the tasklist feature. And before that, I used the described workaround. So this is not needed anymore.

Still does not work for Del. For a sequence like CTRL+L CTRL+D it works.

@gaoh is this still an open issue?

is the discussion realy over now? I think this is also more an meta task, concrete actions like removing binary tag and such should be sub tasks.
@kislinsk Could you make sub tasks out of your discussion points. Thanks.

Updated task description since the class has been refactored. However, the issue still exists, but now it is - as far as I can see - only abut getting the visibility etc. which can easily be refactored.

A pop up appears with whatever error message was thrown from OtsuTool3D::DoUpdatePreview.

I uploaded a fix in D783. Let's see if this will solve the issue also for Ubuntu.

I tested this on Windows with 4974a335ada8a85d7fba8d313e2efc20acc84b48, which was the latest develop I had, since I recently merged something into develop and couldn't reproduce the error.
Used StdMultiWidget, no other plugins open, no data loaded, only the widget planes available in the data storage.
I tested this with the commit given in the task description and couldn't reproduce the error there as well.

After meeting it is decided that:

1. Label names/classes & their pixel values that are hardcoded in the python codebase will be parsed directly and shown in MITK for 2023.04 release (Ref: https://github.com/wasserth/TotalSegmentator/blob/master/totalsegmentator/map_to_binary.py)
2. Certain subtasks which need multiple nifti file agglomeration (eg. "Body") will not be included in the 2023.04 release.

Current interim thoughts:

The issue is also applicable to TotalSegmentator tool where label id 1 (spleen) is predefined yet replaced as "Label 1" by MITK.

I am leaning towards changing selection as it is what users (and I) expect based on experience with other list widgets like the Data Manager.

I see, I then should probably blow the dust off of the MacBook in my drawer and start to suffer as well. :) / :(

Hi Stefan,

Hi André, does it freeze for you when scanning the MITK-Data/3D+t-Heart directory? I try to narrow it down but this directory works for me for example.

for "ii" the developments of T29392 could be of help (if we also implement a reader of this kind). But we would still need to generate the meta info file

I see no value currently, as we have our own statistic backend/view.

How about something like this but in the Preview labels list? Once confirmed, this tail end info will can be pruned and only Label names are transferred.

Hi Ralf,
I did some digging into the TotalSegmentator python code.
So yes, (I believe) label names/classes & their pixel values are hardcoded in the python codebase. Ref: https://github.com/wasserth/TotalSegmentator/blob/master/totalsegmentator/map_to_binary.py
I couldn't find any documentational guarantee for it. Maybe we can double check on it. But the statistics generation (--statistics flag) uses this map to calculate volume & intensity of each label. So it's a safe assumption.

for "ii" the developments of T29392 could be of help (if we also implement a reader of this kind). But we would still need to generate the meta info file

I tried today to move everything from MitkMultilabel into MitkSegmentation but it generates some dependency cycles issues like for modules that sit in between MitkMultilabel and MitkSegmentation.

In the meeting it was decided that a decision regarding whether or not to replace or add labels will be still in RFD.
Decision will be later on after further discussion with the group, in conjunction with Ralf's planned changes in the tool API classes.

We decided that it is a nice and maybe necessary feature so we want to encode it somehow.

That ist not a good solution (as far as I can see it) i.a. due to other constraints. Lets discuss this topic in the next meeting.

Hi Ralf,

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