During DICOM import of data comprising multiple data channels, the separate channels get confused across different 3D blocks.
Revisions and Commits
|Restricted Differential Revision||rMITK9a29ffc60b2e T27483-DICOM_import_mulit_phase_data|
|Restricted Differential Revision||rMITK6307b8d92e46 Fixed reveiw remarks|
|Restricted Differential Revision||rMITK2628fb5822b4 Added option feature to PreferenceListReaderOptionsFunctor|
|Restricted Differential Revision||rMITK0697e83d9b42 Added DICOM reader that allows to manually select which configuration should be…|
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*