Even crashes with a "fixed" 3D+t-Heart image (see https://phabricator.mitk.org/T24766#131218).

Have you looked deeper into that problem so far / need help?

I tested with our images and I confirm the bug in 2016.11 and 2018.04.
image1: Dimensions: 128 128 74 65 Spacing: [2.03125, 2.03125, 2] https://drive.google.com/open?id=1a1UuHc3hQJLY9tAC4G3Gxz4oEBJZFEJ0
Image2: Dimensions: 128 128 74 2 Spacing: [2.03125, 2.03125, 2] https://drive.google.com/open?id=134hjTj3vLZbVS9717V86r2xecoD1RTBZ

I tested simply removing the condition and the mitkThrow(). It "fixes" the crash but , as you can guess, there's some strange behaviors when on Time=2:

• With only Image1 visible, everything is ok, probably because there's actual content to feed to the views.
• With only Image2 visible, there's no slice update at all.
• With both images visibles in a specific part of the image (<65, > 136, > 42), it's ... weird. The 2D views show the wrong image and they don't update. The 3D view is still updated.
• In the other part of the image, everything is ok.

So, if you have any idea on how to fix this, I'm interested! I can help if you know what to change but don't have the time to do it.

I think I found a way to fix it. I only tested with the 2 images in my previous post, but it looks ok.

1. Remove the condition and throw in /Modules/Core/include/mitkImagePixelAccessor.h
2. In /Modules/Core/src/Rendering/mitkImageVtkMapper2D.cpp, replace all uses of this->GetTimestep() with

unsigned int timeStep = this->GetTimestep();
if (image->GetDimension() >= 3) {
    timeStep = std::min(timeStep, image->GetDimension(3) - 1);
}

A return near line 670 explains why my Image2 stopped updating. It doesn't explain the other weird positional behaviors though. Anyway, I can't reproduce this bug anymore so I guess it's not that important.

I know I can send a PR with these changes, but there's a probably a better fix, something that wouldn't uselessly call an update, less deep, etc. I don't know your codebase much so I prefer havng your opinion first.

Thanks for the investigation! If not the solution it is a helpfull lead. I will have a look into that matter, but not befor end of next week (lots of current dead lines; *sigh*)

Ok, I had a bit of time today to look into that matter.

I think I have identified the root of the problem.

I boils down to an insufficient handling/respecting of time geometry in QmitkImageNavigatorView::UpdateStatusBar().
In line 265 ff

image3D->GetGeometry()->WorldToIndex(position, p);
mitk::ScalarType pixelValue;
mitkPixelTypeMultiplex5(
  mitk::FastSinglePixelAccess,
  image3D->GetChannelDescriptor().GetPixelType(),
  image3D,
  image3D->GetVolumeData(renderer->GetTimeStep()),
  p,
  pixelValue,
  component);

The naive use of renderer->GetTimeStep() results in some constelations to an out of bound request of GetVolumeData(), which in turn results into a nullptr return. This leads in the accessor to use channel informations as a fallback. And this channel information may be 4D. bam We have our exception.

Bottom line. The proposed changes cure symptomes but not the reason. I would like to so reomve the problem at its roots.
Before fixing it, we have to discuss some aspects of the application behavior in more detail.
I'll open a diskussion task (T25042) for that. After these points are cleared, it is a straight forward task to fix the current task by reworking UpdateStatusBar().

We have discussed who to handle it. See results of T25042 in order to fix that bug properly.

Pushed new branch T24767-3D+t_crash.

We noticed a changed behavior compared to previous workbench release:

• Load data as described above (topmost visible data set has 3 time steps, data set below has 10 time steps)
• Move time slider to the end

--> Slider can be moved to a 12th time step

In the previous release, the last navigable time step is the 10th time step. Using the spin box arrow up for navigation starting from the 1st time step also started the time series from the beginning, showing the last time step for the residual 7 time steps. Currently the 1st time step of the topmost data set is show for the first 10 steps.

12 time point are correct in this case. Because all time geometries of data in the storage have 12 distinct timepoints. Thus a global time geometry must have 12 time points.

Please keep in mind that our mapper currently do not handle timegeometries correctly. Please see also T25042: How to handle update informations in heterogeneous time geometries and out of bound situations and T25098: Mapper (partially?) do not handle images correctly if they are out of time bound.