this particular dicom fails to import and shows up as two copies of the content under the same volume with the original resolution (images are shrunk up to fit in the original resolution)
i used Microdicom program to export the individual slices then reimported them to slicer and manually entered spacing and slice thickness in order to get the correct volume.
Here is the problematic file:
Different slices in this series report different X-Ray Exposures. I suspect this will cause most tools to segment these as different images. For example, if you run dcm2niix with default settings:
$dcm2niix_stable ~/tst/slicer7576/
Chris Rorden’s dcm2niiX version v1.0.20190410 (JP2:OpenJPEG) (JP-LS:CharLS) Clang8.1.0 (64-bit MacOS)
Found 120 DICOM file(s)
…
slices not stacked: X-Ray Exposure varies (exposure 20, 24; number 1, 1). Use ‘merge 2D slices’ option to force stacking
You can convert this series successfully by using dcm2niix’s “merge” argument (“-m y”). Use this argument with caution - we often want to segment images with different exposures, echo times, etc as these can influence contrast.
$dcm2niix -m y ~/tst/slicer7576/
Chris Rorden’s dcm2niiX version v1.0.20190410 (JP2:OpenJPEG) (JP-LS:CharLS) Clang8.1.0 (64-bit MacOS)
Found 120 DICOM file(s)
Image Decompression is new: please validate conversions
Convert 120 DICOM as /Users/rorden/tst/slicer7576/2_5.3_THORACO-ABDOMINO-PELVIEN (512x512x120x1)
Conversion required 5.730815 seconds (5.719810 for core code).
Slicer uses DICOM reader of ITK library and it seems that this reader cannot cope with the compression method of your image. Please report the problem at https://discourse.itk.org/.
Robustness of dcm2niix is very impressing, so if we keep having problem’s with ITK’s DICOM reader then maybe we’ll add DICOM plugin that allows loading of images using dcm2niix.
@Chris_Rorden Would you be able to add an “examine” option to dcm2niix, which would just quickly return what files dcm2niix would create (without actually creating those files, to save time)?
Slicer performs this “examine” step for each DICOM series with all of its DICOM readers to see which ones can interpret it. The reader that reports the highest confidence will be used by default (in advanced mode, user can freely choose from the list of loadable items).
Ideally, dcm2niix would also provide for each output file a confidence value (between 0.0-1.0 to indicate how probable is that dcm2niix would load the file correctly), a short name (that describes what the file will contain), and “additional comments” (text describing warning messages or any additional information could be relevant for the user).
@lassoan you may want to look at issue 252. Both FSLeyes and MRIcroGL use the ‘-n -1’ argument to report how files would be segmented based on all the other arguments. In additon, some vendors have a lot of rounding errors in reporting these values, so the values reported in the DICOM vary even when they are supposed to be the same (hence dcm2niix allows a tolerance for these). If you want to suggest the algorithm used to further estimate outputs, consider posting an issue on the dcm2niix Github page. The merging of echo-times (MRI) and X-ray exposure (CT) is vexing, as some users expect these to be combined while others want them kept separate. A heuristic might be to assume that files should be merged if each slice position is unique, and not to merge if positions repeat across these.
$ dcm2niix_stable -f %s_%p -n -1 0 -m n ~/dcm_qa_uih
Chris Rorden’s dcm2niiX version v1.0.20190410 (JP2:OpenJPEG) (JP-LS:CharLS) Clang8.1.0 (64-bit MacOS)
I planned to ask for loading from file list later, but did not want to ask for too much at once - it seems #252 provides a solution for that.
It is not entirely clear if we would need to re-run dcm2niix several times with all commonly useful loading option combinations to map out what dcm2niix can load, as it may take too long time.
Parsing of dcm2niix output does not seem straightforward either, because warning messages break the structure. Maybe with some heuristics it could work, though: e.g., consider all output lines that do not contain tab characters as warnings. If there are warnings then set confidence to 0.5, if there are no warnings then to 0.9. Warning messages could be used as additional comments.
@lassoan with regards to ITK support, the Transfer Syntax is 1.2.840.10008.1.2.4.91, which means lossy JPEG-2000 compression. OpenJPEG is the only open source library that can reliably read these images at high precision. The dcm2niix code shows how to call this library. The Python-based dicom2nifti shows a different approach - if calls gdcmconv to decode compressed DICOMs to raw DICOM (e.g. from the command line ‘gdcmconv -w IM-0001-0001.dcm raw.dcm’).
In these examples, JPEG-2000 achieves an impressive 5:1 compression ratio. However, I would personally suggest users avoid compressed DICOM transfer syntaxes: the DICOM standard only requires DICOM compliant tools to read the uncompressed data, so while one can generate a valid compressed DICOM image, there is no guarantee it will be supported by various DICOM utilities in your tool chain.
As an aside, my own personal opinion is that lossy JPEG-2000 is particularly ill-suited to medical imaging. The reason is that it is so “good” from the perspective of human observers, avoiding the blocking and other artifacts of classic JPEG. As one increases compression with JPEG-2000 the images exhibit a subtle blurring. Even highly compressed images look great to a human viewer. However, in my experience it is often the high frequency edges that are crucial to diagnoses, e.g. signs of hippocampal sclerosis. One assumes the moderate compression applied in the sample images retains such attributes, but loss in fidelity will be hard to detect.
The SlicerDcm2nii extension should help Slicer users in the rare cases where the in-built ITK library fails. The current integration of the ITK libraries in Slicer is so good that I think it would be a major engineering feat to use a different tool. My sense is Slicer users report the rare instances where the ITK library fails, yet the vast number of successful conversions are unreported.
I do not think there is any perfect DICOM converter. This is due to the inherent complexity of DICOM, the fact that different vendors have interpreted it differently, the reality that vendors are evolving their interpretations, and that over the years each vendor has released buggy DICOMs that do not strictly conform to the standard. I suspect that if Slicer relied on dcm2niix rather than ITK, you would be made aware of the instances where dcm2niix fails.
@lassoan I think that “-m” is the only dcm2niix argument that influences how DICOM images are combined or segmented. The other arguments influences attributes of the output files (name, format, type of scaling) but do not influence the number of files generated. The only other option that alters the number of files generated is ‘-i’ (ignore) which will skip files that are 2D, derived or localizers.
I agree with your comment that the warnings could be denoted better. This could actually be changed pretty easily, as all text output is one of three types:
printMessage(): refers to typical commentary (which one can control with verbosity).
printWarning() refers to an ambiguity that the user should inspect.
printError() is used when their is an exception that terminates conversion.
These 3 messages are all piped through the unit print.h, so it would be easy to add different markers to denote each type of error. As you note, perhaps a space could precede every warning, a tab could precede every warning, and an asterisk could mark an error (errors are already easy to detect as they change the return value of the executable).
By the way divest already modifies the print.h file so that messages generated for R are prefixed as [dcm2niix info], [dcm2niix WARNING], and [dcm2niix ERROR].
I’ve implemented a DICOM plugin to allow loading volumes using dcm2niix from the Slicer DICOM browser as usual. After the pull request is merged, the dcm2niix plugin will show up in the DICOM browser if users install SlicerDcm2nii extension.
Example of loadables produces for a corrupted series (I’ve removed a few slices from the series):
