In cases of 3D+t data where acquisition time is always the same and only the tag TriggerTime differs (e.g. gated data like test data Heart3D+t) the time points for each frame and the overall time bounds are not correctly determined.
In this cases it is currently allways a duration of 1 ms starting at 0 ms.

This is true for the old DICOMSeriesReader as well as the new DICOMReader module.

The bug should be focused on the new DICOMReader module, because DICOMSeriesReader will be deprecated anyways.

On solution strategy would be to extend mitkITKDICOMSeriesReaderHelper.cpp in such a way that the time bounds of each frame list are correctly determined by also taking trigger time (if defined) as an offset into account.

ExtractTimeBoundsOfTimeStep() and ExtractTimeBoundsOfTimeSteps() as well as the used helping structures should be reworked.
To avoid bringing boost datetime into the header but also have a stable definition of the time bounds of a frame list following approach could be considered:

1. ExtractTimeBoundsOfTimeStep() should be renamed in ExtractDateTimeBoundsOfTimeStep (to better depict its purpose).
2. ExtractTimeBoundsOfTimeSteps() uses ExtractDateTimeBoundsOfTimeStep () for the base line date time.
3. Add a ExtractTimeBoundsOfTimeStep that directly computes the duration in ms as lower and upper bound for a given time step compared to the also passed base line date time. Here to offset (e.g. trigger time is also taken into account).
4. ExtractTimeBoundsOfTimeSteps() loops through all time steps and extracts there TimeBounds via the new ExtractTimeBoundsOfTimeStep().

Also think about using a functor to enable the reader to control the strategy that is used to compute the timebounds in ExtractTimeBoundsOfTimeStep().

Ralf, has there been any work so far? This is something we need resolved, soon.

So, if you haven't done anything yet and the plan mentioned above is still valid, I'd take a shot at it..

Hi markus,

not so for. Due to the fact that i am currently in parental leave and there are other more pressing issues I have to take care of when I am back, it is unlikly that I will take care of it before end of October. So if you want to take a shot, please feel invited! :) Would be greate.

It think the outlined plane above is pragmatic but still valid. But I am open for other suggestions.

Pushed new branch T19473-consider-triggertime-in-DICOM-loading-Intigration_branch.

Deleted branch T19473-consider-triggertime-in-DICOM-loading.

Deleted branch T19473-consider-triggertime-in-DICOM-loading-rebased.