Hm, yeah I guess that was our original problem, mentioned in the referenced task. So it might be that we never did it right because we could never really inspect the behavior sadface
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 8 2020
Has to be checked if the problem still exists in the master. It could be already solved due to T27322: [DICOM reader] DICOM image reader should only read dicom files from a directory that are in the same image block like the selected file.. Please verify.
I can do that. I already checked with 2018.4.0. In this version it's possible to select a third time step only by moving the time slider (not the spin box buttons), but for the third time steps it's showing the volume of the first.
Curently you can workarround by moving the control point (e,g, for size) to the other side, so that it does not hit the boundary.
Ok thanks, then I would like to test the data with an old installer (e.g. 2016) to see if we ever did it correctly.
I checked with the MultiVolumeExplorer module of 3D Slicer: A third volume is shown which is different from the other two volumes.
I'm currently trying to get access to the relevant data again.
I tested this and I can confirm that the segmentation-node will be deselected but the parent node stays selected in my case!
I just ran into this error (on Windows) unexpectedly by doing the following:
- load ImageStatistics/testimage.dcm
- remove the image node
- load Pic3D
- -> Error in PlaneGeometry::CheckBounds(const BoundingBox::BoundsArrayType &bounds)
May 7 2020
Done (pm)
@kalali: As nobody has claimed the task and no new comment emerged, I would say "no".
As the next step is fairly simple:
Does the MITK team have access rights on the NAKO dataset? Then I would suggest an example from there.
do you know when this stopped working?
The error was first noticed recently while working with clinical partners on MRI lung data from the NAKO. I checked the old installer from 2015, where it also did not work.
or someone else: is there an example image in MITK Data to show this behavior?
I could not find a suitable lung example in MITK Data. I checked on two old lung MRI datasets in the department, where the problem did not occur.
Pushed new branch T27318-IvimFit.
mitk::ExtractSliceFilter::GenerateOutputInformation() generates the bounds of the itk object. There are some values that need to be inspected:
xMin = 0 xMax = 512 yMin = 0 yMax = 0
So subsequently
// currently the unit rectangle must be starting at the origin [0,0] assert(bounds[0] == 0); assert(bounds[2] == 0); // the unit rectangle must be two-dimensional assert(bounds[1] > 0); assert(bounds[3] > 0);
in PlaneGeometry::CheckBounds(const BoundingBox::BoundsArrayType &bounds) fails.
+1
I just found out the following:
- perform both steps as written in the description
- change the layer of one of the two segmentations such that one segmentation is on the same layer as the parent node (the other segmentation should still have a layer above the parent node),
e.g. from
ParentNode: Layer 4 Segmentation1: Layer 5 Segmentation2: Layer 7
to
ParentNode: Layer 4 Segmentation1: Layer 5 Segmentation2: Layer 4
- see how both segmentations are visible with overlapping area
@floca Any progress here? This also happened often with real data from partners and is really annoying because the error message is somewhat unspecific.
I would also like to see this fixed for MITK 2020.
May 6 2020
Tests don't fail anymore
May 5 2020
For MITK 2020 I would remove them since it doesn't seem feasible with time constraints (so change task to wishlist and change title to implement interpolation).
Is there some rough estimate when this bug was introduced?
May 4 2020
Ok, on fedora there is a newer xvfb version which includes a new option for a more robust choice of a suitable display number which seems to fix the issue for me.