lost slice gap information after conversion from multi-slice DICOM to nifti about dcm2niix HOT 7 CLOSED

Hello-

In general, if your 2D images share the same series number they will be stacked as a single 3D volume (or if the compile time parameter "mySegmentByAcq" is set, the images must share the same series and acquisition number). Note that the NIfTI format only stores the distance between slice centers (the sum of slice thickness and slice gap).

You can always look at the function "isSameSet()" to see the comprehensive set of criteria used to determine if 2D slices should be stacked: series number, acquisition number, date/time, echo time, echo number, coil number, protocol name, slice orientation.

I am not sure why your slices have not been stacked, but either using my software with the verbose ("-v y") conversion or using Osirix to inspect your images should reveal why they are not stacked.

Note that in the case where my software saves the images as separate 2D slices, you can still infer the inter-slice distance: each slice stores its spatial coordinates and angulation as both a spatial transformation matrix (the s_form) and as a quaternion (q_form). So you can always compute the spatial position between slices (e.g. if they share the same angulation, just use Pythagorean theorem to compute the Euclidean distance between each slices' origin). So in this case, the NIfTI pixdim[3] gives you the slice thickness, pythagorean theorem provides the distance between voxel centers, and the difference between these two values is your slice gap.

from dcm2niix.

Thanks for the quick reply, lots of information here. Just as a recap:

What you are saying in your first paragraph is that assuming the data from the DICOM stack were only differing by the slice gap, your software would have stacked them right? Based on the list of criteria you gave me, I have a feeling that the data were given a distinctive name and acquisition number. I will check your list and verify which criterion is not fulfilled.

Also, assuming the nifti were stacked to 3D+t, then the inter-slice distance would be lost. But not for multiple 2D+t where inter-slice distance can be calculated via basic geometry. Could you confirm?

from dcm2niix.

If the slices are stacked as a 3D volume the resulting NIfTI image does not store the slice thickness or the slice gap, rather it stores the sum of those (the distance between voxel centers). If you want, you can email me the link to a DropBox archive of your images and I can provide more detail.

from dcm2niix.

Thanks to your pieces of explanation, I think I got the limitations behind the single 3D+t versus multiple 2D+t files.

Do you happen to know how the stitching of these data into a 3D+t volume is usually done, i.e. how is the slice gap treated when processing this sort of data?

from dcm2niix.

All the image processing tools I use ignore slice gap, effectively assuming that voxels are contiguous in each of the 3 dimensions. For brain imaging, the gap is usually around 20% of slice thickness to reduce interference (sequential slices) or spin history (interleaved) effects. The slice selection is not actually perfectly discrete, so there is always some roll off.

I would have expected my software should stack your slices for you. When you say 2D+t do you mean that each slice has multiple time points, and if so are all the slices acquired in the same acquisition (s1t1, s2t1, s1t2, s2t2...) or are they scanned one after the other (s1t1, s1t2, s1t3..., s2t1, s2t2, s2t3....). If it is the latter and you are using a GE scanner, you should make sure you are using the latest build of my software (1-Nov-2016) as I just added support for that feature.

from dcm2niix.

When you say 2D+t do you mean that each slice has multiple time points

Indeed, each time point corresponding to a different cardiac phase.

from dcm2niix.

Can you see if the current build (1-Nov-2016) correctly converts your images. You can try it with "-m y" and "-m n" parameters to see how forcing the software to stack across series influences the output. The NIfTI standard requires that time is the 4th dimension (with the first 3 dimensions reserved for spatial dimensions). If this works fine, lets close this issue, otherwise I would need to see a sample dataset.

from dcm2niix.