The DICOMReader module already contains a set of Reader-Configurations that can cope with most 3D DICOM images.
However, there is only a single 3D+t configuration and that failed to load most of the data it is confronted with.
In this ticket, additional configurations shall be implemented that improve 3D+t loading capabilities.
These improvements should build on the changes by Ralf made in bug-17819-integration_branch.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | None | T19636 Parsing of DICOM-tags is locale-dependent | ||
| Resolved | None | T19485 Add reader-configurations for 3D+t images | ||
| Resolved | None | T17819 AcquisitionTime is ignored when loading DICOM 3D+t data |
I have added 2 DICOM-Reader configurations that can cope with most of the 3D+t DICOM series that I came across.
Furthermore I have improved const-correctness and sped up the loading of images.
This issue can be closed. However, as it builds on the changes made in T17819, these changes cannot be integrated into master, yet.
I have to verify it, but it seems that this bug introduced a bug when loading 3D+t images. With the changes of this branch, 3D+t images are loaded, (time) geometry is correct, but(!) all timesteps have the pixel values of the first time step.
Seems like the image data is not correctly stored.
I have detected the effect on my personal branches DIPP-2015-11 (works fine) and DIPP-2016-02 (broke). The main differences are the cherry picks from this bug.
But I have to verify it on this branch directly compared to the master.
As soon as I have done it, it will give an update.
Or do you have any idea directly poping up on this matter?
No, this sounds new to me. I have been using this code for a couple of weeks now and have not noticed anything out of the ordinary.
However, I have to admit, that I'm using it, merged into another personal-branch and that I am not testing 4D images at the moment.
It would be great if you could test if the bug you described is actually caused by my changes..
I have looked into this matter (and build several versions in the last days).
Now it works fine.
(I will file another bug to extend the unittests for the reader to also check the image content, so that we can detect such problems automatically in the future)
Thanks Ralf for fixing the issue with the loading. Must have missed that one somehow..
I tested the changes and the code seems to work fine now. So from my point, we can merge this issue now..
[896506]: Merge branch 'bug-19485-4d-dicom-reading'
2016-03-21 13:16:10 Ralf Floca [7991e1]
removed const (*sigh*) to be compatible to gcc 4.8 (does not support the c++11 signature of std::vectore__erase() yet)
Signed-off-by: Ralf Floca <r.floca@dkfz-heidelberg.de>
2016-02-29 09:54:38 Ralf Floca [4386b7]
fixed bug that caused incorrect loading of 3d+t images
Signed-off-by: Ralf Floca <r.floca@dkfz-heidelberg.de>
2016-01-04 11:19:10 Markus Engel [7edaec]
reverted inversion of sorting that was commited by mistake
2015-12-22 14:53:51 Markus Engel [2bba0b]
massively speeding up loading of DICOM images
2015-12-22 14:16:46 Markus Engel [c2fd4c]
improved const correctness
2015-12-22 14:16:35 Markus Engel [da255b]
using vector instead of list
2015-12-22 13:34:52 Markus Engel [f3600a]
improved const correctness and ifdef'ed MITK-DEBUG code
2015-12-22 13:28:37 Markus Engel [b9fe19]
improved const correctness
2015-12-22 13:27:12 Markus Engel [d7b416]
added two 3D+t reader configurations that work fine