@floca I just tested it with my latest changes and the issue still persists. The connection to interpolation seems to be that the SegmentationInterpolationController is still holding a reference to the image and is notified about a modification. When changing the segmentation volume to the new segmentation eventually the ImageTimeSelector crashes when trying to clone an ImageDataItem that already seems to be null (this is 0x00000000). Here's a part of the call stack:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 7 2021
Jul 5 2021
Pushed new branch to rMITK MITK: bugfix/T28606-UseLZ4InCompressedImageContainerClass.
With the same test data as in T28491, I was already able to virtually eliminate the time spent on compression with LZ4.
Jul 2 2021
Deleted branch from rMITK MITK: release/T28602-2021-Week-26.
Pushed new branch to rMITK MITK: release/T28602-2021-Week-26.
Jul 1 2021
I will create another task for an optimization of the diff image operations in the do/undo stack.
Deleted branch from rMITK MITK: bugfix/T28491-SpeedUp2DInterpolationsOfLargeSegmentations.
Jun 30 2021
On my 4 cores / 8 threads workstation, I get a speedup factor of nearly 10x (or 35x, if neglecting the whole do/undo stuff during measurement). This is for a 1024³ block, where only the first and last slices contain segmentations, so the whole image block need to get interpolated.
Jun 29 2021
1024³ image block 2d-interpolation ================================== Without optimizations 392.78s Distance image cache 53.17s -- Speedup factor ----------- 7.4x Distance image cache + Extract slice cache 47.22s -- Speedup factor ----------- 8.3x
Interpolation is not done in place to build a Do and Undo operation for the Undo/Redo-Stack. In the test case above this is another 30 seconds (more than half of the time with the first optimizations). While undo/redo is important, we should consider coming up with an heuristic, or option, or something similar to disable it for the interpolation of large images.
Without looking into parallelizing the interpolation yet, I was already able to algorithmically speed up the interpolation by 7-8 times.
Pushed new branch to rMITK MITK: bugfix/T28491-SpeedUp2DInterpolationsOfLargeSegmentations.
Jun 28 2021
Deleted branch from rMITK MITK: bugfix/T28591-SourceFileExtensions.
Pushed new branch to rMITK MITK: bugfix/T28591-SourceFileExtensions.
Deleted branch from rMITK MITK: bugfix/T28591-SourceFileExtensions.
Pushed new branch to rMITK MITK: bugfix/T28591-SourceFileExtensions.
Jun 25 2021
Jun 15 2021
Wasn't able to reproduce it anymore, too.
I reported the cmakebuilder-plugin issue to Jenkins: https://issues.jenkins.io/browse/JENKINS-65893
Deleted branch from rMITK MITK: bugfix/T28546-macOSCatalina-Boost.
Pushed new branch to rMITK MITK: bugfix/T28546-macOSCatalina-Boost.
We also need to fix the Boost binary build on macOS.
Jun 11 2021
Deleted branch from rMITK MITK: bugfix/T28546-macOSCatalina.
Pushed new branch to rMITK MITK: bugfix/T28546-macOSCatalina.
- For now I will disable SWIG (and PCRE) builds on macOS and require it to be provided (for example via Homebrew brew install swig).
- I already renamed everything in Jenkins, Phabricator, and Git hooks
- The macOS codename extraction can be easily fixed adding the backslash to the extraction regex
Jun 4 2021
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 2 2021
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.
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().
May 28 2021
May 11 2021
Hm, I cannot answer this without looking into this in detail but a first step could be to improve the AssertImageForLevelWindowProperty function or maybe even encapsule the CPPUNIT_ASSERT_MESSAGE calls in that function instead the other way around since the error message one does receive currently doesn't tell much about what actually failed since it could be any or all of the three checks.
Apr 30 2021
Deleted branch from rMITK MITK: release/T28473-2021-Week-17.
Pushed new branch to rMITK MITK: release/T28473-2021-Week-17.