Enhanced MR DICOM EPI from Bruker - volumes not resolved correctly

[isolovey]

I've encountered an issue converting Enhanced MR EPI DICOMs from a Bruker scanner. The slice and volume dimensions are not resolved and are squeezed together.

I've uploaded a small 2-volume EPI scan here.

When I "un-enhance" the DICOM file using dcm4che's emf2sf tool, and then convert the resulting 2D images using dcm2niix, I get the right output.

dcm2niix -s y -f direct B3DEC1C1.dcm
mkdir unenhanced && emf2sf --out-dir ./unenhanced B3DEC1C1.dcm
 dcm2niix -f unenhanced -o . unenhanced
diff <(python -c "import nibabel; h=nibabel.load('direct.nii'); print(h.header)") <(python -c "import nibabel; h=nibabel.load('unenhanced.nii'); print(h.header)")

dim, qoffset_y and srow_y are incorrect in the directly converted Nifti:

9c9
< dim             : [  3 128 128  32   1   1   1   1]
---
> dim             : [  4 128 128  16   2   1   1   1]
17c17,18
< pixdim          : [-1.   0.5  0.5  0.5  1.5  0.   0.   0. ]
---
> pixdim          : [-1.          0.5         0.5         0.50000006  1.5         0.
>   0.          0.        ]
38c39
< qoffset_y       : 14.28165
---
> qoffset_y       : 6.281651
41c42
< srow_y          : [ 0.       0.      -0.5     14.28165]
---
> srow_y          : [ 0.          0.         -0.50000006  6.281651  ]

[neurolabusc]

@isolovey-robarts

1. Can you also upload a copy you have "un-enhanced" with dcm4che as I do not have that tool.
2. Was the enhanced DICOM image created directly by the Bruker console or was it created by dcm4che? I ask because the ImplementationVersionName (0002,0013) lists dcm4che-1.4.34. If the latter, can you upload the original DICOM image directly from the Bruker scanner without it being touched by dcm4che. I suspect I can support this dcm4che variant of enhanced DICOM, as it is broadly similar to Philips enhanced DICOM. However, it does not seem like a great format for Archival work as it crashes popular DICOM viewers like Horos 2.0 (3.3 seems OK) and does have some unique features. I note your images were acquired on 20181026 but dcm4che 1.x development ended in 2006. So if you really did use dcm4che 1.4 to convert your files to enhanced DICOM, I would suggest you try out the modern version of dcm4che (5.x) as it may produce more standard enhanced DICOMs. Further, 5.x has active development and support. Regardless, to support dcm4che's enhanced format it would be useful to have some datasets from other vendors converted as well (e.g. could you convert dcm_qa using dcm4che to enhanced DICOM).

[neurolabusc]

Please test latest code (v1.0.20181027). It attempts to support dcm4che's enhanced DICOM based on a single example. Ideally, it would be good to test on data from different vendors and more modern versions of dcm4che.

[isolovey]

Thank you, Chris, and sorry for a delayed reply. v1.0.20181027 (commit af1d53d920) properly converts the provided 2-volume fMRI Enhanced MR DICOMs, but there are issues with what's stored in real-life datasets. I was trying to diagnose it and provide a more complete reply.

I think I should explain our setup a bit better to clear up some confusion.

On our Bruker console, DICOMs can be exported as files or sent to the DICOM storage SCP. Additionally, they can be exported as either "single-frame" (i.e. regular single-slice DICOM Magnetic Resonance Image type) or "multi-frame" (Enhanced Magnetic Resonance Image type).

EPI datasets can be exported as "single-frame", but this isn't feasible for us because it generates n_slices-by-n_volumes files, which for long EPI runs can be something like 64*600 = 38400 files. This takes hours to export to the DICOM server (or to the filesystem) and results in huge storage overhead.

On Siemens consoles, these would be exported as "mosaic" files (all slices of a volume tiled into one file), but unfortunately the Bruker console cannot do this. So our only option is Enhanced.

Our DICOM server is dcm4chee (version 2.18.3). The library it uses for writing DICOM files, dcm4che, is reflected in Implementation Version Name (0002,0013) DICOM attribute of the file I uploaded above which you examined. This is because the DICOM instances are modified by the server (supplemented by additional DICOM attributes) when they're received, so the software must also overwrite (0002,0012) and (0002,0013) attrributes with its own info.

For completeness, I've uploaded 4 datasets:

1. (shared in original post) Enhanced_extended_dcm4che - enhanced MR DICOM, supplemented with some additional info and downloaded from a dcm4chee DICOM server (hence ImplementationVersionName=dcm4che*).

2. Enhanced_console_original - enhanced MR DICOM, directly exported to the filesystem from the Bruker console software (Paravision). It has Implementation Version Name = OFFIS_DCMTK_360, which I'm guessing means that Bruker console software uses the DCMTK library for DICOM functionality.

3. Singleframe_console_original - single-frame/regular MR DICOMs, directly exported to files from the Bruker console software (Paravision).

4. Singleframe_unenhanced_dcm4che - single-frame/regular MR DICOMs, created using an "un-enhance" command-line tool which is part of dcm4che (emf2sf).

Before commit af1d53d920), dcm2niix could not convert 1 and 2, but could convert 3 and 4. Our DICOM server currently stores 1. As a temporary workaround I use emf2sf to convert 1 to 4, and then convert 4 to Nifti using dcm2niix.

As of af1d53d920, the dimensionality issue is fixed, but there is something wrong with the contrast in the output images (not in the 2-volume EPI I sent, but in other datasets). I'll post an example as soon as I can figure out how to acquire a minimal-size one.

Also, the commit refers to dcm4che in variable names and commit message, but should probably refer to 'Bruker' instead, as outlined above.

[isolovey]

Although the dataset I initially provided is converted fine by v1.0.20181027, larger datasets seem to have an issue with the order in which data is written in. It looks like the de-facto order is Nx-Ny-Nt-Nz, but in the header the dimensionality is Nx-Ny-Nz-Nt.

Here is a sample dataset (50 MB rat image). I can fix it by loading the converted Nifti file into Python, first reshaping (i.e. changing dimensionality to reflect the order in which the slices are actually stored), and then transposing (i.e. reordering the data):

I=nibabel.load(...)
D=I.get_data()
D2=D.reshape((D.shape[0],D.shape[1],D.shape[3],D.shape[2]),order='F').transpose(0,1,3,2)
I2=nibabel.Nifti1Image(D2,I.affine,I.header)
nibabel.save(I2,...)

[neurolabusc]

@isolovey-robarts the current version should convert your image ok. It will generate the warning "Error: Anatomical Orientation Type (0010,2210) is QUADRUPED: rotate coordinates accordingly". I know that some quadruped templates use the Y direction for Anterior->Posterior and the Z for Inferior->Superior, while others reverse these. I think one would need to rotate the image and the bvec's correspondingly. I do not have enough sample datasets or insight to be confident in a solution. I think my current solution is usable for most situations and handles the data I have seen.

[isolovey]

I've tested the current version v1.0.20181105 on several fMRI and CEST datasets and the Nifti files are all correct (identical to ones converted from unenhanced DICOMs).

[isolovey]

Found another problem so I thought I'd re-open this issue.

I have an Enhanced MR with a slice gap ((0018, 0050) Slice Thickness is 3, but the spacing between successive slices as reflected in (0020, 0032) Image Position (Patient) is 5.7)

dcm2niix writes the (0018, 0050) Slice Thickness value into pixdim[3], instead of the actual spacing.

When converting the non-Enhanced MR DICOMs, dcm2niix computes the spacing correctly.

I'm not sure whether this problem is specific to Bruker/Diffusion data, or Enhanced MR DICOMs in general.

See test dataset.

[neurolabusc]

Please test latest commit. The BIDS will report "SliceThickness": 3, while will be reproted as`pixdim[3] = 5.9. This reflects 3mm thick slices with 2.9mm gap. This is a perfectly legal DICOM image, I have just never encountered an enhanced DICOM with a slice gap that did not populate 0018,0088.

[isolovey]

Thanks, the pixdim voxel dimensions are now correct.