This issue should be postponed until T28523: Evaluate MITK segmentation survey (to now the new priority) is done.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 4 2021
This issue should be postponed until T28523: Evaluate MITK segmentation survey (to now the new priority) is done.
This issue should be postponed until T28523: Evaluate MITK segmentation survey (to now the new priority) and T27437: Migrate MITK to use ITK 5.x (check for performance improvments due to refactored ITK) is done.
This issue should be postponed until T28523: Evaluate MITK segmentation survey (to now the new priority) and T27437: Migrate MITK to use ITK 5.x (check for performance improvments due to refactored ITK) is done.
Also see our internal discussion about who to address several more fundamental design issues: https://hub.dkfz.de/f/5459842
As it is an inexpensive operation my first guess would be an issue related to the amount of used memory. For example, the image above eats 3,5 GB, Activating the interpolation already triples it. Confirming adds at least another 3,5 GB. That could also explain why it is so slow (swapping). But at this point it is just a first assumption. On a 16 GB Windows machine I was able to complete the interpolation without crash but it took a while.
Without looking into it yet, I think the Nvidia solution for accelerated remote desktop is currently by far the most promising as it tackles the actual issue.
Jun 3 2021
Running MITK within a Windows Server 2012 R2 Session (VMWare virtualized) and using the fdossena's opengl mesa libraries the current state is (no crash, though):
This seems to be still an issue. Maybe there is new information out there or it could be re-tested with newer Windows versions / drivers?
Jun 2 2021
It seems to be the same bug, I just failed to find the existing task. Since I found it in the last Release version, the bugfix was just not included yet, but the problem is still solved. I guess this task can be closed then
I am indeed still reading since I still have tasks to do (I will not leave beforehand just as promised :-)). I think you are referring to T28383 / D477 ... maybe it didn’t fully do the trick.
A few things that impact the handling of huge images:
The tool was already removed from the last release because people tend to use the Add/Subtract tool for the same tasks anyway and we could reduce code/complexity.
Discussed it in the MITK meeting:
And we seem to have a huge leak here. Even after deleting all the nodes again, half of my RAM is still in use.
As it is an inexpensive operation my first guess would be an issue related to the amount of used memory. For example, the image above eats 3,5 GB, Activating the interpolation already triples it. Confirming adds at least another 3,5 GB. That could also explain why it is so slow (swapping). But at this point it is just a first assumption. On a 16 GB Windows machine I was able to complete the interpolation without crash but it took a while.
Maybe @thomass is still reading. :) I think she reported the same thing some weeks ago but I cannot find it. It's just a missing RequestRenderWindowUpdate().
Jun 1 2021
@kislinsk sorry for the late reply. I am not using the convert to segmentation functionality because it draws contours by default and that is annoying because it obstructs too much from the image. Multilabel color map does exactly the right thing, is easy to use and does not require and additional mouse clicks. It is just more convenient :-)
closing gVisor experiments since Kata is our first choice and Kata is able to run in our bare-metal machine, hence temporarily closing gVisor testing.
Closing the issue since gVisor has lots of limitations with microk8s and our current Kaapana architecture.
May 31 2021
May 28 2021
May 26 2021
May 25 2021
May 24 2021
May 20 2021
Hey Marco, I had uploaded the models there back in the days:
import numpy as np import colorsys from skimage import io
May 19 2021
I agree on that. I had some problems with that with the new mxn-multiwidget. The topic was also mentioned in T27613: Improve reinit behavior.
The same issue seems to apply to the normal workbench, so this container has also to be updated to the current master