Page MenuHomePhabricator

Render windows are not updated when last time step is selected
Open, HighPublic


Following up on T24766, I discovered that the render windows are not updated (apart from cross hairs) when the last time step is selected.

Steps to reproduce:

  • Load MITK-Data/3D+t-Heart
  • Choose file reader: MITK DICOM Reader v2 (autoselect)
  • Navigate to last time step
  • Change the slice (axial, sagittal, coronal)

--> The render windows are not updated

Revisions and Commits

Event Timeline

eisenman triaged this task as Normal priority.Mar 27 2020, 10:53 AM
eisenman created this task.
kislinsk raised the priority of this task from Normal to High.Apr 15 2020, 9:06 AM
kislinsk edited projects, added MITK (2020); removed MITK.
kislinsk renamed this task from Render windows are not uptdated when last time step is selected to Render windows are not updated when last time step is selected.Apr 16 2020, 9:21 AM

Reproduced with said image but does not happen with US4DCyl for example.

I did not look into it but I suspect that the reason might be the 3D+t dataset, which has three time steps but actually the second and third time step have the same time point. Could you check with any other DICOM viewer if it is possible to see different slices for the last time step?

I checked with the MultiVolumeExplorer module of 3D Slicer: A third volume is shown which is different from the other two volumes.

Ok thanks, then I would like to test the data with an old installer (e.g. 2016) to see if we ever did it correctly.

I can do that. I already checked with 2018.4.0. In this version it's possible to select a third time step only by moving the time slider (not the spin box buttons), but for the third time steps it's showing the volume of the first.

Hm, yeah I guess that was our original problem, mentioned in the referenced task. So it might be that we never did it right because we could never really inspect the behavior sadface

eisenman added a comment.EditedFri, May 8, 11:06 AM

In 2016.11.0 it's showing different volumes for all of the three time steps.

I don't know if that's a good thing 😈

kalali edited projects, added Cleared; removed Missing Info.Fri, May 8, 11:12 AM

Another observation in the current version: "No image information at this position!" is shown in the status bar when switching from second to third time step.

The status is set as mentioned above because in QmitkImageNavigatorView::UpdateStatusBar() the call of mitk::FindTopmostVisibleNode(...) for time point 160 ms returns a null pointer.

The null pointer is returned because mitk::ArbitraryTimeGeometry::IsValidTimePoint(...) evaluates time point 160 ms to false.

floca claimed this task.Fri, May 29, 10:44 AM
floca added a comment.Fri, May 29, 6:25 PM

It is still the problem explained in

I have thought about different possibilities to solve it; e.g.

  1. Ensure that we have no collapsed final time steps.
  2. Support infinite time bounds for the last time bounds.
  3. Introduce the support of the corner case of a collapsed final time step in ArbitratyTimeGeometry. In this case we accept time points as valid and within the last time step if the equal the max time bound

Option 1 I have dismissed, because it would mean to introduce a rule to deduce the duration of the last time step for most dynamic DICOM images as it is not stored. This is not trivial and can introduce new pit falls (and we somehow alter the dicom data which is also not good). 
Option 2 I have dismissed, as for dicom it is just a special version of option 1 with all strings attached.  And DICOM images are what causes the pain right now.

So I have opted for option 3. It seems the minimal invasive but still acceptable clean solution for the problem.

floca added a revision: Restricted Differential Revision.Fri, May 29, 6:28 PM