Page MenuHomePhabricator

DICOM import of multi-channel data not working
Closed, ResolvedPublic

Description

During DICOM import of data comprising multiple data channels, the separate channels get confused across different 3D blocks.

Revisions and Commits

rMITK MITK
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision

Related Objects

Event Timeline

norajitr created this task.

DICOM_import_problem_2.png (1×1 px, 1 MB)
Issue as shown in the attachment

A current blocker for use of NAKO data, therefore set as high priority.

floca removed floca as the assignee of this task.Jun 25 2020, 1:47 PM

Looked into the topics. Following comments:

The non-composed data sets work without a problem (even if pack all slices into one directory). There I cannot reproduce such problems.

The composed data sets are constructed very unfortunately (to say it politly). If I could avoid it, I wouldn't build my automated pipe line on them.
Reason: The only differntiating (public) DICOM tag is the instance number. All other discrimentating tags (e.g. Series description, series time) have been overwritten to a default values. And instance number is only implicitly discimination, if you apply the following policy: to sort by instances, divide it into 4 chunks and reconstruct each chunk.
We have a configuration that does this: "Instance Number, consecutive"
But as it produces 4 images it is not picked by the auto selection strategy, because an other configuration (due to missing other discriminating tags, see above) merge everthing into one image.

D332 I have added a new reader that allows to explicitly select the configuration. It is not a propert solution yet, but helps to check how one would like to have it loaded.

For a proper solution we should need to discuss how you want to use the data after loading. i.a.:

  • In the workbench or as mini app
  • as 4 different images; as 1 image and 4 timepoints; only the image out of 4 which slice was selected...

Then I can see if something fundamentel is missing to allow you building your workflow.

What I really do not understand is, why the composer has thrown away usefull machine encoded information that allows to discriminate the phases. In the composed image you have to pray that the order of the block never change: block 1 is always phase A, block 2 always Phase B and so on. There is now easy automatic way to check it (and this is why I would personally avoid it, if possible; see above). When they had kept the phase encoding in the series description (as they were already there in the non-composed data) it would be much much easier and safer. *kopfschüttel*

kislinsk added a revision: Restricted Differential Revision.Jul 6 2020, 9:57 AM
floca moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 8 2020, 10:55 AM