We have discussed it.

Regarding questions

1. Go to the "next" visible image. Meaning to show the value of the topmost image with valid spatial and temporals bounds.
   1. Yes Mapper and Status should handle it the same way => mapper currently do not!!!!
2. Agreed on A and B

Result:
T24767 should be solved as discussed here, meaning

• GetTopLayerNode() in QmitkImageNavigatorView.cpp must be reworked to get the topmost visible node (in space and time!!!).
• UpdateStatusBar must be reworked to do not use the renderer->GetTimeStep() but GetTimePoint and then deduce the TimeStep of the image by the given TimePoint.

I'm currently trying to understand the problem to possibly fix the bug together with the T24173.
I loaded two datasets:

• LinearModel_4D_arbitrary_time_geometry.nrrd from MITK-Data\3D+t-ITKIO-TestData and
• the image from MITK-Data\3D+t-Heart

The first image has 10 time steps, with time bounds: 0 - 10, 1ms step duration
The second image has 3 time steps:

min TimeBounds: 
 Step 0: 0 ms
 Step 1: 103 ms
 Step 2: 160 ms

max TimeBounds: 
 Step 0: 103 ms
 Step 1: 160 ms
 Step 2: 160 ms

When I load both images the bounding box (for spatial and temporal geometry) is computed and the slice navigator allows to select 10 different time points. Here the workbench crashes, when I select a time point larger than 2. So far so bad.
What happens in the background is that the m_WorldTimeGeometry of the current base renderer has minimum- and maximum time points. Here we have 12 time points:
minimum: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 103, 160
maximum: 1, 2, 3, 4, 5, 6, 7, 8, 9, 103, 160, 160

What you propose now, when finding the topmost visible image, is to use the current time point of the base renderer as defined e.g. by the ImageNavigator. So if we change the time stepper to step 3 we'll get the timepoint 3 from the base renderer.

What should happen now, assuming that the second image has a higher layer and is visible? Currently the topmost node that will be retrieved will be the second image (Heart). Is this correct, since time step 3 lies between 0 and 103 ms? If so, then why do we experience a workbench crash?

In T25042#160682, @kalali wrote:

What you propose now, when finding the topmost visible image, is to use the current time point of the base renderer as defined e.g. by the ImageNavigator. So if we change the time stepper to step 3 we'll get the timepoint 3 from the base renderer.

That's correct.

What should happen now, assuming that the second image has a higher layer and is visible? Currently the topmost node that will be retrieved will be the second image (Heart). Is this correct, since time step 3 lies between 0 and 103 ms? If so, then why do we experience a workbench crash?

Because your are still thinking in time steps (of the world time geometry) instead if thinking in time points and asking what would be the appropriate time step of this image (in its time geometry of the image) at the given time point.
So correct would be:

auto globalStep = render->GetTimeStep(); //[globalStep == 3];
auto globalTimePoint = worldTimeGeometry()->TimeStepToTimePoint(globalStep ); //[globalTimePoint == 3]
auto currentStep = image->GetTimeGeometry()->TimePointToTimeStep(globalTimePoint ); //[currentStep == 0]

Now we use currentStep (0) and tada no crash and the correct volume associated with the global time point.

In the FilterTopMostNode we don't need the whole stuff. There its enough to check if globalTimePoint is not < minBound and > max Bound.
The other stuff written above must be done in the updateStatusbar method(s).

I hope it is clear now.

Just as a side note:

• LinearModel_4D_arbitrary_time_geometry.nrrd from MITK-Data\3D+t-ITKIO-TestData and

[...]

the first image has 10 time steps, with time bounds: 0 - 10, 1ms step duration

Your MITKData is not uptodate. There was a bug in the NRRD file. The time geometry must be different.

In T25042#160695, @floca wrote:

What should happen now, assuming that the second image has a higher layer and is visible? Currently the topmost node that will be retrieved will be the second image (Heart). Is this correct, since time step 3 lies between 0 and 103 ms? If so, then why do we experience a workbench crash?

Because your are still thinking in time steps (of the world time geometry) instead if thinking in time points and asking what would be the appropriate time step of this image (in its time geometry of the image) at the given time point.
So correct would be:

auto globalStep = render->GetTimeStep(); //[globalStep == 3];
auto globalTimePoint = worldTimeGeometry()->TimeStepToTimePoint(globalStep ); //[globalTimePoint == 3]
auto currentStep = image->GetTimeGeometry()->TimePointToTimeStep(globalTimePoint ); //[currentStep == 0]

Now we use currentStep (0) and tada no crash and the correct volume associated with the global time point.

Yes, I meant time point. So using the time stepper and setting it to step 3 we'll get the time point 3. This time point lies between 0 and 103 of the second image so we "round" to the next smaller time step (in TimePointToTimeStep with if (timePoint < *pos)), which will give us time point 0 => time step 0.

Is this fixed with 50b8977b3486?

Yes, partially. We have no crashes, but

T25043: Remove pixel informations from the statusbar and put it into views and T25098: Mapper (partially?) do not handle images correctly if they are out of time bound are missing.

So it depends if you see this task as diskussion task (then we can close it) or as a meta task for the whole topic (then it is not closed).