Page MenuHomePhabricator
Create Task
Maniphest T25939

DICOM data and Nifti Segmentation don't like each other, 3d+t data
Closed, DuplicatePublic
Actions

Description

Dear MITK-Team,

I'm using Stefans MITK-2018.4.0-linux64 Installer (sorry for being to exclusive) on ubuntu 16.04. Stefan will be able to give you more information about the current status of this version and he will also be able to decide whether a bug fix is necessary at all.

In the past I used to work with raw images in nifti format and the corresponding segmentations in nifit format.

Now however I used a raw image in DICOM format and the corresponding segmentation in nifti format. When I drag an drop the DICOM and the nifti into MITK's data manager two difference things happened (at this moment I am not able to predict whether case 1 or case 2 will occur):

  1. "time line" will be concatenated, meaning: both DICOM and nifit have 30 time steps, after loading both of them into MITK both will have 60, although only 30 of them contain unique content -> by sliding through time the file loaded first will change for the first 30 time steps, then the image will freeze for the last 30 time steps before it starts again to move. the file loaded last will change its content for the last 30 time steps.
  2. The file which was loaded last (either DICOM or nifti) will behave as expected: by sliding through all 30 time steps the image will change 30 time. The file which was loaded first however will change its content over the 30 time steps (30 time steps are shown in the "image navigator") only one or two times.

Reproduce:
in my case (hope it is not an issue of the data I use)

  • load an arbitrary 3d+t DICOM image and the corresponding segmentation (nifti)
  • slide through time -> strange behavior should occur

Thanks you MITK!
<3,
Peter

Event Timeline

full created this task.Jan 29 2019, 11:58 AM
floca added a subscriber: floca.Jan 29 2019, 3:11 PM

The reason is (most certainly, but not verified!), that the nifti segmentations do not store correct timepoints for each frame. If loaded, they will get the default time geometry. (starting with 0 ms and a duration of 1 ms per frame). This is one of the problems I addressed last december with my camic info mail, to make people aware of current problems with using nifti (cf nrrd format) when storing data.

DICOM offers the correct acquesition time information, which will be used to reconstruct the time geometry.

Combining both can lead to several strange world time geometry; e.g.

  • 60 time steps (the first 30 ms are covered by the nifty frames and the rest are covered by DICOM frames because the overall 3D-t acquesition took longer then 30 ms)
  • interleafed time steps (because DICOM also starts with the first 30 ms)
  • ...

To verify you may generate a segmentation on a DICOM 3D+t image and store the segementation as NRRD. When you reload the nrrd segmentation everything should still be fine.

If my assumption is correct, I would propose the following.

  1. new segmentations should as a default stored as nrrd, if no requirements prohibits it and as long as nifti is not fixed (not trival :() or a better format is available.
  2. work arround for old data: one can store the DICOM image as NRRD, store the nifti segmentation as NRRD and then copy the time geometry information from the image NRRD to the segmentation NRRD in a text editor.
  1. If the need arises more often one could think about a little plugin for the workbench that allows to impose the timegeometry of one base data onto another. You might propose it as another (related/sub) task and tag it with "request for discussion".
full added a comment.Jan 29 2019, 3:59 PM

Thank you for your extensive response.

I remember your mail about nifti vs nrrd very well;) I am not really into nifti, but Fabians workflow, which I am working with, seems to rely on nifti. That is why I keep writing bug reports about nifti in MITK but I see your point and I am sure it is very valid.

For the sake of completeness: I did as you suggested and created a segmentation from scratch and exporting it as nrrd. This did not solve the problem.

floca added a comment.Jan 29 2019, 4:02 PM
In T25939#173903, @full wrote:

For the sake of completeness: I did as you suggested and created a segmentation from scratch and exporting it as nrrd. This did not solve the problem.

Then there might be another bug involved. Could you make such a segmentaton (must not be a meaningfull) store it as nrrd and provide the stored NRRD?

Ah, do you use multi lable segmentation? Or the classic segmentation?

Thanks.
Ralf

full added a comment.Jan 29 2019, 4:04 PM

Sorry I did not mention this, but I use the multi label segmentation.

I attached the nrrd which did not work properly which my workbench.

1.2.276.0.7230010.3.1.4.3054843160.1116.1505770761.nrrd59 KBDownload

floca added a comment.Feb 5 2019, 10:48 AM

Thanks for that. The problem arises from a insufficient implementation of the LabelSetImagIO. It currently ignores the time geometry and additional properties :(.

I will open a sub task to address this matter. If the sub task is resolved. It should work. But NIFTI would be a problem never the less, because ITK does not store custom meta information in NIFIT yet.

full added a comment.Feb 5 2019, 10:50 AM

Alright, thanks for your support!

kislinsk edited projects, added MITK; removed MITK (2018-04).Mar 11 2019, 9:32 AM
kislinsk closed this task as a duplicate of T25988: LabelSetImageIO should support time geometries and property serialization.Apr 29 2019, 6:32 AM
kislinsk removed a subtask: T25988: LabelSetImageIO should support time geometries and property serialization.
MITK · MIC · IMSY · DKFZ