Page MenuHomePhabricator | MITK

How to handle update informations in heterogeneous time geometries and out of bound situations
Open, NormalPublic

Description

Current situation:

The code that updates the status bar (QmitkImageNavigatorView::UpdateStatusBar()) currently assumes that the time steps (not time points) are always covered in terms of accessible data volumes for the top most visible node.
This is often not the case in heterogeneous scenes where we have different images and time geometries.

Before we fix that code in UpdateStatusBar() (and maybe other locations as well) we should discuss/clarify several questions:

  1. How to handle situations, when the top most image is not within the time bounds? Show N/A? Show the last timestep? Go to the "next" images (see 2)
    1. How is it handled for the rendering? Statusbar and renering should handle it the same way?
  2. How to handle situations, when the top most image does not cover the world coordinate?
    1. Currently the next valid top most node is selected. This is the analogy in the time domain to taking the top most node that covers the time bounds. Which in turn would mean that nodes should disappear in the rendering, when the current time step is out of there time bounds.
    2. I think the logic for the time domain and the spatial domains should be the same.

Another more "fundamental" questions that pops into my mind, when thinking about that matter is pixel information, but for visibility reasons I will spawn a sub task for that.

Event Timeline

floca created this task.Jul 10 2018, 3:48 PM

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.
floca updated the task description. (Show Details)Jul 19 2018, 5:24 PM
kalali added a subscriber: kalali.Jul 25 2018, 2:37 PM

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?

floca added a comment.Jul 25 2018, 3:02 PM

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.

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?

floca updated the task description. (Show Details)Oct 23 2018, 12:28 PM
floca updated the task description. (Show Details)

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).

kislinsk edited projects, added MITK; removed MITK (2018-04).Nov 7 2018, 8:41 AM
kislinsk triaged this task as Normal priority.Thu, Nov 22, 11:52 AM