Closed elijahrockers closed 3 weeks ago
@elijahrockers this question is underspecified for providing much feedback. The one thing that springs to my mind is that some users prefer to concatenate CT scans that include different exposures, while others want these to be saved as separate images to model differences in SNR. If so, you might be interested in the argument -m y
to enforce concatenation:
-m : merge 2D slices from same series regardless of echo, exposure, etc.
You may want to look at the warnings that dcm2niix generates to the command line. This often outlines the reason images are not being concatenated:
Slices not stacked: X-Ray Exposure varies (exposure 123, 144; number 1, 1). Use 'merge 2D slices' option to force stacking
If this does not solve your problem, perhaps you can send a sample to my institutional email.
That solved it, thanks! I was using a python module (pydcm2niix) which by default calls dcm2niix with "-m n". In fact, I just tried calling dcm2niix manually with no arguments at all, and the result was a single nifti.
The default for dcm2niix is -m 2
which is automatic
, which uses some logic to determine whether to concatenate or not. The -m n
forces variability to split a series, while -m y
forces merging. In general, the dcm2niix defaults are the most widely used and informed from years of experience. The big challenge is that some teams explicitly want to model differences, and others explicitly want to disregard them.
I am batch processing a cohort of CT DICOMs. The dicom files for a single volume are contained in a single directory. If I load this volume into e.g. the OHIF viewer, it is interpreted as a single volume, with ~80 or so slices, and I can scrub through the axial slices, as expected
My script grabs the first .dcm in a given DICOM directory and runs dcm2niix on it. Unfortunately the resulting output from dcm2niix (for this example) is three different .nii.gz files. On inspection, it appears to have 'split' the volume into three smaller axial volumes.
Perhaps I am using dcm2niix incorrectly? Reading through 'dcm2niix -h' did not seem to give me any clues.