If you load a measurement or point set first and an image afterwards, the workbench crashes. When I tried to reproduce the error by creating an own measurement and doing the same, the error didn't occur.
Steps to reproduce:
| rMITK MITK | |||
| Restricted Differential Revision | rMITK5317a6b4c554 Fixed T26979 | ||
| Restricted Differential Revision | rMITK37a74f46ded1 Fixed one change into sliceGeometry i have forgot to revert/change to… | ||
| Restricted Differential Revision | rMITKbf956ecdcb22 Changed ExtractSliceFilter::m_WorldGeometry from raw to smart pointer | ||
| Restricted Differential Revision | rMITK5fade6e50480 Used m_WorldGeometry insted of slicedGeometry as it is equivalent to the old… | ||
| Restricted Differential Revision | rMITKc9792b31d1c3 Fixed T26979 | ||
| Restricted Differential Revision | rMITK0a7cada910bc Removed redundant cast (instance is already of the cast type) | ||
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.
I think this is due to yMax = static_cast<int>(extent[1]); inside mitk::ExtractSliceFilter::GenerateOutputInformation() with extent[1] being 0.333333 so it's cut off to zero.
@floca @kislinsk , I'm not an expert on geometry-stuff so please take a look. I don't know why it does not happen when loading both data objects in a different order.
I just ran into this error (on Windows) unexpectedly by doing the following:
I know how to fix the obvious problem. But I want to discuss if this is the complete fix or only curing the symptoms,
The problem occures when the current world geometry, that
should be rendered by the mapper, has an FOV that in combination with
a loaded image generates an index (right or bottom vector) that is
smaller then 1 and will be rounded to 0, wich violates the bound checks
of plane geometry.
To make it concrete:
Loading ImageStatistics/testimage.dcm (size 17x17x1) leads in the 2d mappers to slices of (17x1). When I load Pic3D (spacing: 1x1x3), the mapper wants a reslice for the world geometry still defined by testimage.dcm (so a slice 17x1 mm). For mapping the ponts to index the geometry of the input image (Pic3D) is used. Therefor the mapped index is -> 17x0.3333. This will be later floored to 17x0, which leads to the error.
I assume that happens because the mappers are triggered at least once before a new world geometry is establisched.
@kislinsk @nolden I think from first glance that it is valid to just ensure that the slice never colapses (see code review) and there is no deeper error just covered by the fix. But I want to discuss to get a second opinion.