User Details
- User Since
- Aug 1 2016, 12:10 PM (436 w, 5 d)
Aug 2 2016
+1. Major issue for us.
This is a major issue for us. The segmentation module is unusable with 2014.10.
-F
I was thinking on fixing this issue by implementing a system similar to the one used for changing the DepartmentLogo (ie. by using IBerryPreferences). Any thoughts on that?
The core dump can be retrieved from
I just tested it with b6576a5dcafc90bf6d181e3f54bf09df02517e02 + patch and it still crashes here. The core dump looks the same.
Patch to address the negative spacing
Patch to address the negative spacing
Patch that fixes the compilation error
I forgot to mention that we can't assign the computed outside value directly to m_OutsideValue because m_OutsideValue is stored as a mitk::ScalarType and TOutputPixel can be double which would result in an invalid value.
Thanks for pointing that out.
Thanks for working on that!
FYI, I can confirm that our code works when using GrabItkImageMemory instead of ImportItkImage. Again, thanks for working on that.
This is where the fun begins.
The unit test files.cmake
Overlay ground truth #1
The test image
Overlay ground truth #2
@Jan: The test you wrote passes, but the problem is still present. Here's the code causing problem on our side:
The unit test
2012.12 moved
2013.03 original
2013.03 move
Original test image
The bug seems resolved in 2013.06
Nevermind my previous comment, it's still there. The issue seems to come from the lines
I can confirm this bug under Linux and Windows with latest master (9f0c858a54cd48f7cc050762e66e005328865be7).
This is a big problem for us. +1
I noticed that the region growing provided by the Step6 MITK tutorial seems to have a different behaviour.
I pushed my branch on Github [1] if you want to see/test the 4D region growing. All the tests pass so far.
I managed to make the region growing work in 4D with minor code modification.
@Joseph: The crash still occurs with the current master. I attached a screenshot showing the location of the bounding box. I will email you a link to the dataset used for testing.
I can confirm that the bug is fixed with the current bug branch
Crop selection
@Joseph, Do you need an official pull request on Github or if you can manage to merge the workaround from the link to my branch?
I made a WIP branch on my Github [1]. I'm not sure that the fix is good since the data hold by the ImageDataItemPointer needs to be cleared at some point and I'm not sure it is if we change the data type to a standard pointer. This needs to be investigated but I'm running after time at the moment. Any suggestions are welcome.
Here's some more info...
The problem comes from the line
Patch released, see
Fix the issue
Please comment on the fix
Patch has been submitted on Github.
Is it possible for me to contribute directly to the new branch (if needed)? Branches don't seem synced on the Github repository.
One problem I see with Andreas' solution is the lack of consistency for the file opening action. For example, I like the fact that I can drag'n'drop files from my file explorer to the MITK data manager and MITK automatically creates expected nodes. I'm curious to know how you could achieve this behavior with the DICOM editor?
FYI, our application becomes unusable (linux) and/or crashes (windows) and we think it is because of this bug. As Sascha pointed out, the same operation can be started again.
I came across a post [1] about the use of the itk::CastImageFilter to make a 4D dataset from multiple 3D dataset. Would it be possible to use this?
I can confirm this issue. It still happens on 2012.12 and 2013.03.
At the line