This context and code artifacts referred in this issue seems obsolete or changes. The issue needs to be rephrased if not closed.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 5 2023
Apr 4 2023
Mar 27 2023
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.
Mar 24 2023
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.
Mar 22 2023
A pop up appears with whatever error message was thrown from OtsuTool3D::DoUpdatePreview.
Mar 21 2023
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.
Mar 18 2023
After meeting it is decided that:
- 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)
- Certain subtasks which need multiple nifti file agglomeration (eg. "Body") will not be included in the 2023.04 release.
Mar 17 2023
Mar 15 2023
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.
Mar 8 2023
Mar 6 2023
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.
Mar 4 2023
Mar 1 2023
Feb 27 2023
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.
Feb 23 2023
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
Feb 22 2023
I see no value currently, as we have our own statistic backend/view.
Feb 21 2023
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.
Feb 20 2023
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
Feb 19 2023
Feb 13 2023
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.
Feb 8 2023
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.
Feb 7 2023
Feb 6 2023
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,
Feb 3 2023
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.
Jan 30 2023
Hi Ralf,
Jan 28 2023
@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.
Jan 25 2023
Jan 24 2023
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.
Jan 23 2023
Hi Ralf,
@ahmadqasim : 3 questions.
- 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?
- was there a special reason why you want to do it via the picking tool? Why not directly editing in the list of labels?
- 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.
Jan 19 2023
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...