Under normal circumstances, the QmitkStdMultiWidgetEditor creates a QmitkStdMultiWidget, and each QmitkRenderWindow constructor calls an Initialize method. Ordinarily, at startup, when the DataStorage is empty, the mitk::VtkPropRenderer::SetWorldGeometryToDataStorageBounds will try to compute the visible bounding geometry 3D. This returns null when there is no data within the DataStorage, and so ultimately, the rendering pipeline has no world geometry, and rendering updates are abandoned.

All that is ok, and as expected.

However, in our application, we can create additional widgets, each one containing a subclass of QmitkStdMultiWidget. So, in our sequence of events, you can be creating a new QmitkStdMultiWidget, when the application is running, and the DataStorage already has images in it. This means that the creation of the QmitkRenderWindow, will call the Initialize method, and so the mitk::VtkPropRenderer::SetWorldGeometryToDataStorageBounds will not be NULL, as the DataStorage has images, which means that the initialization process eventually ends up trying to actually create an image slice and render it. The code works its way through to mitk::ExtractSliceFilter::GenerateData, and at line 335

https://github.com/MITK/MITK/blob/master/Core/Code/Algorithms/mitkExtractSliceFilter.cpp#L335

the calculation of GetClippedPlaneBounds produces the wrong extent, causing the rendering to crash. The reason the bounds are wrong, (in our case, or rather,... with the data I am using) is that the bounds are initialised to -10000000 to 10000000, and then the line intersection of the bounding box does not intersect, so the bounds are not updated, and the method returns false at line 556.

https://github.com/MITK/MITK/blob/master/Core/Code/Algorithms/mitkExtractSliceFilter.cpp#L556

Subsequently the Extents calculated are way out of range.

So, in one sense the problem is data specific, as the test data I am using does not encorporate the origin.

We additionally see this problem more than most because we create new QmitkStdMultiWidget on the fly. It probably rarely occurs if ever in the standard MITK ExtApp, or CoreApp application. So, it is also probably specific to our application.

There may also be problems with mitk::PlaneGeometry, as the plane of interest is calculated outside of the volume. However, I believe this is because we are using images with flipped direction cosines ... and I don't fully understand all the code in PlaneGeometry to calculate the initial plane. So the Line intersection bit in GetClippedPlaneBounds may simply be correctly calculating the fact that the generated plane does not intersect with the volume provided by the world geometry.

However, the GetClippedPlaneBounds method returns false when the intersection fails, and this is not tested. If the return value was checked, then we could simply fall back to some default plane size and avoid a crash.

So, while I don't fully understand all the intricacies of the geometry, it seems a reasonable thing to fix, just to stop the code crashing.