Appears to confuse AX FLAIR with diffusion

[sawhitmire]

I have a set of dicoms that include a multi-slice axial T2 or axial FLAIR and a single-slice sagittal T2. When I read the dicom stack directly, I get what I expect, but dcm2niix creates a multi-slice diffusion image and a single slice sagittal T2. It does not create the filename extensions that I expect when creating multiple images.

My question is what in the image metadata is dcm2niix using using determine that the image is a diffusion? I don't see anything in the dicom tags that would indicate that, but it could be hidden in one of the matrices stored in the metadata. I need the tool fixed eventually, but in the short term, I might be able to work around the issue if I know what I'm looking for.

[neurolabusc]

1. It can help to know the version of dcm2niix you are using (dcm2niix --version). If it is less than the current version (v1.0.20200331), please upgrade.

$dcm2niix --version Chris Rorden's dcm2niiX version v1.0.20200331 (JP2:OpenJPEG) (JP-LS:CharLS) Clang11.0.0 (64-bit MacOS)

2. The presence of a b-value greater than zero or a gradient vector suggests diffusion data. Different strategies are required for decoding DICOM images from different vendors, in particular for [DWI](https://www.na-mic.org/wiki/NAMIC_Wiki:DTI:DICOM_for_DWI_and_DTI). See the vendor-specific notes for [GE](https://github.com/rordenlab/dcm2niix/tree/master/GE), [Philips](https://github.com/rordenlab/dcm2niix/tree/master/Philips) and [Siemens](https://github.com/rordenlab/dcm2niix/tree/master/Siemens).

3. I am unclear what your problem is. dcm2niix will losslessly rotate 3D acquisitions to approximately match the canonical NIfTI identity matrix. I think this is what you mean by saying the sagittal T2 is saved as an axial T2 (e.g, you used a 3D T2 sequence like SPACE). You can disable this behavior with the `-x i` option. The correct spatial transforms are always stored in the Form and QForm, so while the order of voxels may be transposed, the spatial information is preserved. 

4. In general, dcm2niix converts DICOM images that share a common series instance UID (from 0020,000E) as a single NIfTI file, though there are exceptions to be BIDS compliant (e.g. different files for series with multiple echo/trigger times; removal of derived images from raw DWI sequences). The [filenaming is described here](https://github.com/rordenlab/dcm2niix/blob/master/FILENAMING.md). For example, if you request` -f %s_%p` the resulting files should be named based on series number and protocol name.

[sawhitmire]

Thanks for the quick response.

I upgraded to the latest version yesterday and re-ran the conversion with the same result. Which tags store the b-value and the gradient vector?

This is not a spatial problem. The axial T2/FLAIR is converted to a diffusion, and the sagittal T2 is converted to a sagittal T2 but not in a separate file, instead overwrites the first image file.

I will check the series UIDs to see if they're the same. If they are, I can edit the dicom stack to remove the sagittal slice as it does nobody any good.

[neurolabusc]

Feel free to share a sample with me (send images via DropBox/GoogleDrive to email in my avatar). The tags used depend on the vendor (GE/Philips/Siemens), see links in my previous response.

I am not sure what you mean "converted as diffusion" - do you mean the filename includes "diffusion" - if so filename is driven explicitly by DICOM tags as described here, in other words if you used -f %p and got the filename "DiffusionAX" it means the input data had in tag "DiffusionAX" 0018,1030. If you mean that dcm2niix detected it as diffusion because it generated a .bval and .bvec file, then you need to look at the vendor-specific tags for b-value and gradient direction.

I really do not have enough information to answer. With regards to 'overwriting images in the file' this is very atypical of dcm2niix. The example I can think of is if a derived image is saved in the same series number as the raw data (e.g. a TRACE or ISOTROPIC image saved in the same series as the raw DWI data). This is actually a violation of the DICOM standard, and reflects a limitation of your images, not my software (the derived images MUST be given a unique series number). Even so, as long as you have the default -i n flag set (rather than the -i y) it should save the derived images as well a copy where the derived images are conveniently removed (e.g. dwi_adc.nii and dwi.nii). You can always create better derived images once you have processed them.

I am going to go out on a limb here, and guess that you are dealing with some hyper acute clinical sequences. In this case it is common to acquire a diffusion (DWI) sequence that has a B=0 volume and a TRACE image. The conventional T2 and T2-FLAIR sequences will not be sensitive in the hyper-acute stage, so the clinical team specified a diffusion sequence. For hyper acute injury, the PWI/DWI modalities are standard of care. The TRACE image looks a bit like FLAIR (CSF is dark), the B=0 is a T2-weighted image acquired with a rapid sequence (e.g. EPI). Things that are bright on the B=0 that are not CSF suggests old lesions, tissue that appears abnormal in the TRACE that appears normal in the B=0 suggests hyperacute injury.

[sawhitmire]

"Converted as diffusion" means it created the bval and bvec files. The resulting image also looks different than the original dicom when viewed through ITK-Snap.

I suspect you're right about the images violating dicom standards. We see that all the time.

Your last paragraph provides some helpful information to figure out what might be going on. I'll get back to you.

Thanks.

[neurolabusc]

When you refer to the 'single slice sagittal' is it possible that this is a localizer series (sometimes referred to as a scout)? When we initially put someone in a scanner, we often acquire a localizer that is used to plan the orientation and position of the subsequent images. Often these are just 3 orthogonal slices (axial, sagittal and coronal). The NIfTI standard requires that all slices in an image are parallel planes, which is the case for all series except the localizers. Localizers are unsuitable for subsequent analyses: spatially normalizing a 2D slice will never be as good as normalizing 3D volumes. In addition, the localizers are intentionally 'quick and dirty' exhibiting features like T1-effects from prior orthogonal slice, poor shim, RF artifacts, etc. I often like this inherent poor quality, as it helps me identify if there will be issues in subsequent scans (e.g. hair product artifacts). If these are localizers, I think you want to discard them. The sole intention for these images was to plan subsequent high quality images.

[sawhitmire]

I suspect you're right about that single slice being a localizer. This particular institution likes to create axial stacks out of other orientations and leaves a slice with a grid on it and a slice thickness that is nowhere near the others. Luckily, dcm2niix saves this as a separate image file (-f results with an extension on it) and I can discard them. That's what surprised me about this case: the behavior appears to be different.

[neurolabusc]

Unfortunately, there is no universally defined tag that defines a scan as a localizer. dcm2niix uses a few vendor-specific heuristics, but it is not able to universally detect a localizer sequence. If unsure, it decides to preserve files. So likely it is just a sequence that dcm2niix is unfamiliar with. You can use -i y to ignore all 2D slices and derived data. People who set up research sequences never want derived data, as they can generate better images in post processing. However, if you only have clinical data that was acquired for clinical care you may want to keep these.

You may also want to try out MRIcroGL for visualizing data https://github.com/neurolabusc/MRIcroGL/releases it will use dcm2niix to load series. I suspect ITK-Snap acts like MRIcroGL and loads 2D data in plane, while 3D volumes are oriented in subject space.

[sawhitmire]

The scanner software version is Siemens syngo MR B17. From your documentation, I surmise the b-value information is in the CSA header, but where does dcm2niix find it (which dicom metadata pair)? I get a b-value of 1000 and a b-vector of -0.295124/0.588181/-0.752958 out of the conversion from dicom to Nifti, but I don't see those values anywhere. The locations for XA10 and XA11 are not in the header.

[neurolabusc]

See the Siemens page how dcm2niix handles images from this vendor. For B17, diffusion data is in the proprietary CSA header. For DWI, the crucial tags of the CSA header are DiffusionGradientDirection and B_value. If you call dcm2niix with the logorrheic verbosity argument (-v 2) it will display all the CSA tags (as well as a lot of other information).

Your data is from VB17, not XA10. The Siemens software is named [System][Generation][MajorVersion][MinorVersion], so your data is from system 'V', generation 'B', major version 1, minor version 7. The 'V' system has had generations 'A', 'B', 'C' (China only), 'D', 'E'. For system 'V' the stable software releases always have odd numbers (e.g. 'VB12' was the development version for the stable 'VB13'). The 'V' system generates classic DICOM.

As an aside, the 'X' system (Vida and Sola products) create enhanced DICOM images. They provide a clean-sheet approach to how Siemens stores DICOM meta data. At the moment, they do not include much of the meta data required by scientists. Due to this, in my opinion these systems do not yet create archival grade DICOM data. Users of this system should read my public service announcement. Conversion of DICOM images from these systems will yield impoverished NIfTI datasets. This reflects limitations of the DICOM images, not my software.

I think we can close this issue. It appears that dcm2niix has correctly identified the data.

[sawhitmire]

The Siemens page doesn't say where in the CSA header it gets the information, so that doesn't help me in this case. But, I agree we can close this issue, and I agree it's not the tool. Thanks for all the help.

[neurolabusc]

OK, just remember that Siemens records gradient directions with respect to the scanner bore. In contrast, dcm2niix saves .bvec files in the FSL format, which is with respect to the image plane. Therefore, the gradient directions must be rotated based on the image angulation, must take into account DICOM vs NIfTI spatial coordinates and must account for FSL's unusual expectations regarding the determinant of the volume. If you want to emulate the behavior of dcm2niix, here is a repository of DWI data from different vendors and software versions.

[sawhitmire]

Thank you, this is very helpful.

-- Scott Whitmire

On Apr 8, 2020, at 9:31 AM, Chris Rorden notifications@github.com wrote:

OK, just remember that Siemens records gradient directions with respect to the scanner bore. In contrast, dcm2niix saves .bvec files in the FSL format, which is with respect to the image plane. Therefore, the gradient directions must be rotated based on the image angulation, must take into account DICOM vs NIfTI spatial coordinates https://www.nitrc.org/plugins/mwiki/index.php/dcm2nii:MainPage#Spatial_Coordinates and must account for FSL's unusual expectations regarding the determinant of the volume https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/FDT/FAQ#What_conventions_do_the_bvecs_use.3F. If you want to emulate the behavior of dcm2niix, here is a repository of DWI data from different vendors and software versions https://www.nitrc.org/plugins/mwiki/index.php/dcm2nii:MainPage#Diffusion_Tensor_Imaging.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rordenlab/dcm2niix/issues/393#issuecomment-611060243, or unsubscribe https://github.com/notifications/unsubscribe-auth/AED7QXZSMHQ6WRLC33ZGCHDRLSRFVANCNFSM4MDJMFJQ.