Page MenuHomePhabricator

3D+t Images with very large max time step need very long to load
Closed, ResolvedPublic


Example data set is E130-Daten/Clemens/maxTimestep.nrrd needs ~5 min to load.
Time geometry is as follows:

org_mitk_timegeometry_timepoints:=0 22 45 67 89 112 134 157 180 202 227 250 272 295 317 339 362 384 407 430 452 475 497 519 542 564 587 610 632 655 677 700 7.38474e+06

if I correct it to

org_mitk_timegeometry_timepoints:=0 22 45 67 89 112 134 157 180 202 227 250 272 295 317 339 362 384 407 430 452 475 497 519 542 564 587 610 632 655 677 700 720

loading takes ~1s.

In case of dicom data, it's not possible to correct the time geometry.

See also {T24451}

Revisions and Commits

Restricted Differential Revision

Event Timeline

hentsch triaged this task as Normal priority.Apr 3 2018, 4:16 PM
hentsch created this task.

Ok, this is interesting! I am very curious what is the reason...

Have you measured the loading (only) or the time till the workbench is responsive again (this would include reinit, visualiziation etc...; maybe the max bounds causes some negative time consuming effect in the reinit).

I measured until the workbench is responsive again. I'm pretty sure it's a visualization problem.


The directory "Clemens" does not exist. Could you please provide the data again. Please also the DICOM data.

found the data in tmp/Clemens.


floca raised the priority of this task from Normal to High.Apr 6 2018, 6:58 PM
floca edited projects, added Request for Discussion, MITK (2018-04); removed MITK.
floca added subscribers: kislinsk, goch.

I have found the reason.

The implementation of mitk::DataStorage::ComputeBoundingGeometry3D() (and some used time geometry functions) is unfavorable in context of arbitrary timegeometries.

  1. ComputeBoundingGeometry3D() takes the min time point, max time point and the minimal time span between to time points of all data objects. This can lead to an extremly large number of time steps (and geometry constructions); e.g. A) if we have data with the default time span of 1 ms and a dynamic data set that spans over some minutes or hours (but has only <100 time steps) or B) or currently nearly every dynamic dataset (with arbitrary time geometry) because the last frame, is currently set to 1 ms if no explicit different max time bound is given.
  2. TimeGeometries are not able to define bounding box update strategies if the geometry does not differ in time steps. Currently the base class time geometry has a non-virtual hard coded strategie to update the bounding box. It would be good if we can allow TimeGeometries to "signal" that there Geometry3D is always the same and thus spare the loop.

Number 1 draines the most CPU time and is the reason for a lot of the mentioned performance issues (in this and other task). Number 2 could lead to an additional speed up.

Regarding number 1:

I think it would be better to use, if possible an ArbitraryTimeGeometry in the method and really just generate all the timepoints that are available in the data collection. The bounding box computation could be keept as it is and then we initialize the ArbitraryTimeGeometry with the computed "bounding box" Geometry. The only change in behavior a can see so far is that the Image Navigation "time slider" may not slide "equidistant" anymore.

But I would like to discuss it before we are making any change regarding the computation of bounding boxes.

floca added a revision: Restricted Differential Revision.Apr 10 2018, 10:26 AM
floca added a revision: Restricted Differential Revision.Apr 13 2018, 10:26 AM