Pushed new branch to rMITK MITK: feature/T27319-multilabelInterpolation.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 31 2022
May 30 2022
I have added object[[algorithm]] <- as.factor(object[[algorithm]]) to challengeR.R as you suggested. Now everything works without any problem. No need of stating stringsAsFactors anymore during CSV read.
In T29158#238958, @floca wrote:
- We should use the same format for the label preset file and this custom labels file. Everything else would be inefficient.
In T29158#238943, @kislinsk wrote:Naming/coloring is still supported with a list of proposed label names while typing but it is not the default anymore. It is now triggered when renaming a label by right-clicking on it and choosing "Rename...". So, I propose that the solution here is split into two preferences: (1) Showing the naming dialog when creating a new label vs. assigning a default name and (2) custom list with a few options like mentioned above.
In T29158#238949, @kislinsk wrote:@floca I would like to discuss if we should also facilitate this file format and check if the parser can handle only names and colors to keep it somewhat feasible for our users or if we should provide/parse another simple format like a JSON file or something like a simple text file parsed line by line with an optional color value in each line in addition to the name:
Pushed new branch to rMITK MITK: feature/T29158-CustomLabelSuggestions.
Pushed new branch to rMITK MITK: feature/T29158-OptionallyAskForLabelNamesAndColors.
May 29 2022
The current list of suggestions for label names is based on an XML format and the preset is loaded from an embedded XML file: https://github.com/MITK/MITK/blob/master/Modules/Core/resource/mitkAnatomicalStructureColorPresets.xml
{D655} addresses part 1 of the solution proposed above. To resolve this task completely the custom list for label name suggestions is missing, which will be tackled in another Diff.
Naming/coloring is still supported with a list of proposed label names while typing but it is not the default anymore. It is now triggered when renaming a label by right-clicking on it and choosing "Rename...". So, I propose that the solution here is split into two preferences: (1) Showing the naming dialog when creating a new label vs. assigning a default name and (2) custom list with a few options like mentioned above.
Resolved with T28285: DICOM with 'ä' in filename not readable on Windows.
May 27 2022
In T26399#238893, @kalali wrote:I'm not sure if this is the reason (T24348: Invalid pointer exception due to invalid QModelIndex in QmitkDataStorageTreeModel) for the decision. I would go the route to deprecate the QmitkDataStorageModel and replace it with the QmitkDataStorageSimpleTreeModel.
However, the QmitkDataStorageSimpleTreeModel probably needs to be extended (e.g. dropping, changing hierarchy). Do we already have a task for this / should we tackle this in this release-phase?
This should be carefully discussed. I think some of the features QmitkDataStorageModel does not belong in a model.
In T26399#238877, @kalali wrote:@floca What was the reason for this: What does "would not reflect the data storage graph anymore" mean? Does the classic / original QmitkDataStorgageTreeModel have any drawbacks because it changes the "internal representation" by changing the parent?
In T26399#238874, @kalali wrote:@floca : Ilooked into this again and found the following:
This is a problem because inside the AddNodeInternal-function the tree is rebuilt by checking the parent-child-node hierarchy and adding tree-items accordingly. However, the hierarchy at that time is incorrect and already outdated.
Good that you identified the problem.
After looking into the code, it seems to me that the warning is just formulated wrongly. A simple reinit will not make the bounding box for a rotated image pixel-aligned. Implementing this would take some time and require a lot of reworking the bounding shape interaction. As this is not currently requested, we will keep things as they are and only update the warning text so it won't be misleading.
May 23 2022
Thank you so much @aekavur ! It helps a lot to understand the reason finally!
May 22 2022
Hi again :)
May 20 2022
I wanted to work on the reproduction, but the GSP-Networkdrives was super slow (kb/s) that I couldn't copy the files to my local machine :/
I'm not sure if this is the reason (T24348: Invalid pointer exception due to invalid QModelIndex in QmitkDataStorageTreeModel) for the decision. I would go the route to deprecate the QmitkDataStorageModel and replace it with the QmitkDataStorageSimpleTreeModel. However, the QmitkDataStorageSimpleTreeModel probably needs to be extended (e.g. dropping, changing hierarchy). Do we already have a task for this / should we tackle this in this release-phase?
I stumbled upon these different tasks because of T26394: [Render window manager] Provide tree view / model, which is related to the mxnMultiWidget.
May 19 2022
See T16165: Reinit after deletion for a reasoning. Both tasks are justified but maybe we should highlight / utilize the general preference "Call global reinit if node is deleted" more.
My changes related to this task were mainly to clear some classes and remove uncertainty (see T28617: Inconsistent view initialization in rendering manager).
As far as I see it some changes have been made in the subtask T28490: Segmentation plugin: "new" segmentation should not run reinit! and the respective D523: This was mainly concerned with NOT resetting the view / camera using a newly introduced parameter "resetCamera".
In T26399#238874, @kalali wrote:
- move the node-tree-items to their new parents immediately inside the QmitkDataStorageSimpleTreeModel::NodeRemoved, like it is done here: https://phabricator.mitk.org/source/mitk/browse/develop/Modules/QtWidgets/src/QmitkDataStorageTreeModel.cpp$675-684
I quickly tested the second suggestion and I was not able to reproduce the bug anymore.
@floca : Ilooked into this again and found the following:
After a node has been removed, inside QmitkDataStorageSimpleTreeModel::NodeRemoved the function QmitkDataStorageSimpleTreeModel::UpdateModelData is called. Here the data storage pointer is used to retrieve the data node subset of a given node predicate. The returned nodeset still returns 6 nodes in my case, although only 5 should exists, since one node was removed.
The node still exists in the data storage, because the signal for a node being removed (RemoveNodeEvent) is sent before the actual removal of the node from the list of nodes inside StandaloneDataStorage (data member m_SourceNodes)).
The command nnUNet_print_available_pretrained_models calls nnunet.inference.pretrained_models.download_pretrained_model:print_available_pretrained_models.
This method can be expanded to take an extra optional argument eg. --export.
If the arg is provided, a JSON file will be exported to the RESULTS_FOLDER location by default.
Since it's an optional argument, there is no need for a documentation update by Python devs.
Instead of command output string parsing, the plan is to export available models' information and place it in a machine-readable format (eg. JSON) in the RESULTS_FOLDER.
This file can be further read by MITK and shown in GUI.
So, this involves making changes on the Python side, as well, for the dumping of the information in a machine-readable format (eg. JSON) natively.
Deleted branch from rMITK MITK: T26958-MapToSource-in-level-window-preset-dialog.
Deleted branch from rMITK MITK: T27049-Measurement-view-with-single-node-selection-widget.
Deleted branch from rMITK MITK: T27183-Fix-segmentation-view.
Pushed new branch to rMITK MITK: bugfix/T28285-Windows-UTF-8.
May 18 2022
Solved in context of i.a. T28982. Now this is handled correctly and user can also configure the behavior.
I would say some code in Modules\IGT\IO has to be adapted to fix this bug. Possibly the class mitk::NavigationDataRecorderDeprecated, if it is still in use.
The output of the abovementioned command, for reference:
Discussion result: yes makes sens.
Started dicussion about it. Current discussion result: We should go for a new model view based implementation instead of try to fix the current boiler plate code.
Have to discuss design of the model view pattern in detail in the next MITK meeting.