Page MenuHomePhabricator

Rendering timegeometry does not match image timegeometry
Closed, ResolvedPublic

Description

When a 3D+t image is loaded that has an arbitrary timegeometry because the time-distance between the first and second timestep is longer than the time-distances between the following timesteps, not all timesteps are correctly displayed.

Cause of this issue is, that the rendering-geometry is always a ProportionalTimeGeometry that uses the distance between the first two timesteps for all timesteps.
When rendering the scene, the BaseRenderer calculates the timepoint 'tp_render' from the rendering-geometry for the current timestep. Afterwards, the image-geometry is asked for the corresponding timestep.
However, as the rendering-geometry consideres all timesteps to be equally-distanced there is a mismatch in the timestep-to-timepoint calculation between rendering- and the image-geometry that causes a wrong image-timestep to be shown for the current rendering-timestep.

A potential fix would be to Extend the SliceNavigationController to be able to use an ArbitraryTimeGeometry instead of a ProportionalTimeGeometry.
However, I'm not quite sure what that would cause if you mix images with ArbitraryTimeGeometries and ProportionalTimeGeometries.

Revisions and Commits

Event Timeline

Hi Markus,
sorry for the late response. The problem wasn't noticed because we currently work with dynamic data that have the same duration for all time steps. And the unit test for heterogenious durations don't cover the workbench :(.

But as far as I can see, you made the same assumption of what to change like I would do.
... And alreade made a patch if I see it correctly. Does it work fine for you now?

Hi,

I have indeed implemented a fix that works in our environment. I extended the SliceNavigationController to create the correct type of TimeGeometry for the rendering, depending on the data that shall be displayed.

I had to make some adaptions to your original code in the ArbitraryTimeGeometry and how the timestep-to-timepoint conversion is done. So far, everything works fine with those changes.

However, I might need some time until I'll be able to port those changes to a more recent code-version to be able to integrate it into master..

kislinsk triaged this task as Normal priority.Aug 9 2016, 9:09 AM
engelm added a revision: Restricted Differential Revision.Aug 11 2016, 11:08 AM
IMPORTANT: Reverted behaviour of time bounds definition in mitkITKDICOMSeriesReaderHelper.cpp (see below).

@engelm : I have reverted the bounds generation strategy in mitkITKDICOMSeriesReaderHelper.cpp again. The last time point as now again a duration given be the reading process (often normaly equal to zero (both bounds have the same value)). The rational/design consideration behind that where (amongst others):

  • Estimating a duration is not guaranteed to be correct (e.g. for acquisitions with arbitraty timings). Therefor we thought it is better to explicitly state that we don't know it (bounds of last time step are equal, duration is 0) instead of generating a value that looks plausible, might be correct, but cannot be trusted/guaranteed.
  • For all use case scenarios (including dynamic data analysis) we had so far, the max bounds of the last time step was irrelevant, because the all work on the time points (== min bound) of the time steps.

If there is a problem for MINT with this assumptions and the reverting of the functionality. Please let us know and we can discuss how to cope with all requirements.

floca added a revision: Restricted Differential Revision.Apr 11 2017, 4:52 PM

Deleted branch T19830-fix-rendering-of-arbitrary-TimeGeometries-master.

Deleted branch T19830-fixing-rendering-of-arbitraryTimeGeometries-snapshot.