Thanks for the clarification. I agree 100%.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 4 2021
Don't get me wrong - I'm not saying that you or someone "verschlimmbesserte" anything :D I understand and appreciate all the effort that has been made by you.
I am more thinking of a different approach architecture wise - you already mentioned "abstraction levels". For me it seems as if different classes and functions are on the same "level" of doing something but they do it differently - which makes it even harder to grasp the logic behind it. That's why I mentioned "class diagrams". Also, often classes and functions are way too overloaded (e.g. SegTool2D) with way too many responsibilities.
In T28131#223675, @kalali wrote:Ok I have to admit: The whole code base that is related to this topic is totally unclear to me and I find it very hard to understand what is going on.[...]
Told you so. ;) As proposed we can have a session together.
Ok I have to admit: The whole code base that is related to this topic is totally unclear to me and I find it very hard to understand what is going on. I don't know why the code is like that but I would highly suggest to simplify and clean the relevant classes and functions as much as possible before it becomes problematic (e.g. more complex cases with 4D-dynamic segmentations with multi-layer multi-label segmentation masks or similar). Also, I highly doubt that this is future proof when it comes to changes in the following years so as already mentioned in my last comment: I think we really need to discuss this topic - maybe it helps to have a clearer picture by creating (class) diagrams with relations etc.
Thanks for the clarification. I will look into the FeedbackCntourTool and ContourModelUtils and see if I can make sense of all this :D
Depending on what I find out I think we should really talk about the future of the (multilabel) segmentation modules / plugins and how we can simplify the code base (generalize it) and remove redundancy as well as decouple classes etc.
May 3 2021
In T28206#223651, @kalali wrote:
You meen T28221, don't you?
Great you are looking into that matter.
The problem is caused by mitk::AutoSegmentationWithPreviewTool::TransferImageAtTimeStep() more precisely in the private helper template function ITKSetVolume (same cpp).
I am not sure what is exactly done here to reproduce. To get any help page I have to click on a plugin anyway. How would I provoke a blank page?
When I use F1 while the Standard Display is activated I get a blank page for the Standard Display. If that's what is meant than we need to reconsider how to display this specific help page: There is a description of the "four window view" inside src\Plugins\org.mitk.gui.qt.ext\documentation\UserManual\MITKUserManual.dox but we can not move it to the stdmultiwidgeteditor-plugin as it contains more information about the workbench, not only about the standard display.
I tried to reproduce this issue and found the following:
With the changes in T28211 @floca mentioned, there is no legend anymore m_Controls.chartWidget->SetShowLegend(false);
Showing this legend again displays "histogram" as the label name - not even the original segmentation node name. Now when I add another segmentation and add it to the statistics, the histogram is completely removed (it's calculated but the widget does not provide any space for the histogram anymore).
@floca I sarted looking into this and found out the following:
The threshold tool used is QmitkBinaryThresholdToolGUIBase, which is a subclass of QmitkAutoSegmentationToolGUIBase. This class uses the AutoSegmentationTool, a subclass of the mitkTool. As far as I can see the target node that will be connected with this tool upon activating the tool is done inside mitk::AutoSegmentationTool::GetTargetSegmentationNode().
However, there is no information about any layer or even the information that this can be used with multilabel segmentation nodes.
Let me know if you got hold of it.
Apr 30 2021
Deleted branch from rMITK MITK: release/T28473-2021-Week-17.
Pushed new branch to rMITK MITK: release/T28473-2021-Week-17.
Apr 29 2021
Apr 28 2021
Deleted branch from rMITK MITK: feature/T28118-Refactor_SegTool2D_and_derived_classes.
@floca Please delete the feature branch mentioned above if this task is resolved.
Deleted branch from rMITK MITK: bugfix/T28437-RegionGrowing3DSeedPoint0.
Apr 27 2021
The task as such is resolved. Another task with open questions from D279 is created with T28466
Apr 26 2021
Fixed the task policy :D Did you get acces to it ?
@eisenman the change in develop branch has not been uploaded to GitHub, is this not automatically synchronized?. So the user who reported the bug still has the same problem. It would be good to merge into master as well
In T27437#223356, @al-sabr wrote:Can this also be matched with this other task I created?
https://phabricator.mitk.org/T28454
I only need help in one place if that part is cleared then I already refactored the Core to reflect the changes suitable for version 3.6.0 of CppMicroServices.
Apr 25 2021
Apr 23 2021
I will put this up for grabs as it does not make sense to start a new project now. Personally I will investigate further after the Conan evaluation report has been written.
One long term solution would also be to create an own Litmus Conan recipe and use this external Litmus package inside MatchPoint.
I was trying to test if I can forward the ITK_USE_FILE variable inside the ExternalProject call to Litmus, as we did in the change for the CMAKE_PREFIX_PATH. I realized that neither the CMAKE_PREFIX_PATH nor the ITK_USE_FILE is correctly forwarded and accessible inside Litmus CMake configuration.
now test case in test-report.R
I started looking into this and some changes need to be made in order to get some errors out of the way:
- Conan-center recipes are built without CMake find / config files, as mentioned here: In short: Conan creates own find / config files so they are removed from the original package.
Do you have a minimum example to reproduce this? Would be great to have that in the test checklists as well.
Pushed new branch to rMITK MITK: bugfix/T28437-RegionGrowing3DSeedPoint0.
Apr 22 2021
very simple fix in rankingHeatmap.challenge
@eisenman can this be merged into master branch?