Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dcm2niix creating mosiacs out of non-mosaic EPIs (dcm2nii did not previously) #337

Closed
iamdamion opened this issue Sep 11, 2019 · 9 comments

Comments

@iamdamion
Copy link

I'm hoping you can help me figure out how to work around this issue I'm having re-processing an old dataset (and perhaps update the program to account for this in the future). For background, I am re-processing a dataset with dcm2niix in order to create the BIDS sidecars and run them through our updated preprocessing pipeline.

However, no matter what I have tried, it creates a mosaic file out of any full EPI scans. At first I thought it was diving into the previous folder and taking some settings from the actual mosaic scan's header and merging them, so I have even tried running it on just the full EPI scan's dicoms folder completely separated from any other scans. Unfortunately I get the same result.

I have tested this against our old version of dcm2nii (Chris Rorden's dcm2nii :: 1JUNE2015 64bit BSD License) and it converts these series just fine making one nifti for the mosaic, and one for the EPI that is not in mosaic.

Oh and dcm2niix works just fine with our new acquisitions. Any idea on what updated setting might be causing this and if there's any way to work around this issue? Thanks!

neurolabusc added a commit that referenced this issue Sep 11, 2019
@neurolabusc
Copy link
Collaborator

Thanks for an example. The issue is that this Siemens D13 data had the CSA Header removed. dcm2niix relies on the CSA header for many parameters. The tag (0002,0013) SH [MATLAB IPT 7.1] suggests the DICOM data was re-saved, perhaps during anonymization. I would suggest checking the providence of this data, and seeing if you can attempt to get a copy of the images that retain the CSA header.

As a great and desperate attempt to salvage this situation, the latest commit to the developmental branch will use the acquisition matrix (0018,1310) to identify mosaics. This has some severe limitations. First, it will not work for mosaics acquired with partial Fourier or with interpolation on. Second, it identifies the maximum number of slices in the mosaic, not the number of slices acquired. For example, in your data a total of 48 slices are acquired and saved to a 7x7 mosaic (with 49 slots). dcm2niix guesses this is a 49 slice volume, and therefore the slice positioning will be off by a little bit (which should be fixed by subsequent coregistration). When dcm2niix encounters this situation, it will generate a warning, e.g.

Warning: Guessing this is a mosaic up to 49 slices (issue 337). Slice positioning will be inaccurate if fewer slices.

You should be able to compile and test the developmental branch on a Unix computer with the commands

git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console
make

Be aware that since the CSA header is missing the resulting BIDS sidecar will be impoverished. This reflects a limitation of these images, not dcm2niix.

@iamdamion
Copy link
Author

Thank you for your extremely fast response!

This all makes sense and I had a feeling it was a result of something odd with those old data. Thank you for incorporating a non-ideal solution to the dev branch.

I’m going to try to hunt down copies where the header info is not changed (anonymized?) but since this may help others working with data they do not have full access to, perhaps this will also help others in the future?

I will test this a little bit later today and update this thread to let you know if it worked as is and you can close this issue.

Thank you again for your prompt response!! It is very appreciated!

@iamdamion
Copy link
Author

Update: The dev version worked and the BIDS sidecar appears to have all the baseline info (that we require anyway). Thank you again for your help!!

neurolabusc added a commit that referenced this issue Feb 3, 2020
neurolabusc added a commit to neurolabusc/dcm_qa_enh that referenced this issue Feb 3, 2020
…saic detection, see IM_0006_T1.dcm from dcm_qa_enh
@tashrifbillah
Copy link
Contributor

tashrifbillah commented Apr 27, 2020

Hi @neurolabusc , is it still in the development branch or merged already?

Edit:
Linking the PR #389

@neurolabusc
Copy link
Collaborator

Included in current stable release (v1.0.20200331). Even in this best case, my kludge can not discriminate between a 21-slice volume and a 25-slice volume as both demand a 5x5 mosaic.

dcm2niix/console/nii_dicom.cpp

Lines 6448 to 6453 in 485c387

if ((isMosaic) && (d.CSA.mosaicSlices < 1) && (numberOfImagesInMosaic < 1) && (!isInterpolated) && (d.phaseEncodingLines > 0) && (frequencyRows > 0) && ((d.xyzDim[1] % frequencyRows) == 0) && ((d.xyzDim[1] / frequencyRows) > 2) && ((d.xyzDim[2] % d.phaseEncodingLines) == 0) && ((d.xyzDim[2] / d.phaseEncodingLines) > 2) ) {
//n.b. in future check if frequency is in row or column direction (and same with phase)
// >2 avoids detecting interpolated as mosaic, in future perhaps check "isInterpolated"
numberOfImagesInMosaic = (d.xyzDim[1]/frequencyRows) * (d.xyzDim[2]/d.phaseEncodingLines);
printWarning("Guessing this is a mosaic up to %d slices (issue 337).\n", numberOfImagesInMosaic);
}

However, be aware that Matlab's dicomanon function scrambles a lot of other information. See issues 275, 296 and 383. This reflects limitations of dicomanon and not my software. Images mangled with this tool can often not be recovered with any tool. Please consider a robust solution for data anonymization such as gdcmanon.

My release notes tend to highlight major features and changes that might break compatibility. Each release tends to have a lot of changes, reflecting the evolving usage of the format and its interpretation by the vendors.

@tashrifbillah
Copy link
Contributor

tashrifbillah commented Apr 27, 2020

Description

We converted a set of DICOMS and found only zero bvalues and bvecs:

dcm2niix -b y -z y -f %d -d 7 -o /tmp/ 7047_MR1

Output

I am putting the output log here for future reference:

Chris Rorden's dcm2niiX version v1.0.20200331  GCC4.8.5 (64-bit Linux)
Found 6500 DICOM file(s)
Warning: Guessing this is a mosaic up to 49 slices (issue 337).
Warning: Guessing this is a mosaic up to 49 slices (issue 337).
Warning: Guessing this is a mosaic up to 49 slices (issue 337).
Warning: Guessing this is a mosaic up to 49 slices (issue 337).
Warning: Guessing this is a mosaic up to 49 slices (issue 337).
...
...
Warning: Guessing this is a mosaic up to 49 slices (issue 337).
Warning: Guessing this is a mosaic up to 49 slices (issue 337).
Convert 100 DICOM as /home/tb571/tmp/MPRAGE_1mm_iso_MPR_COR_T1_MPRAGE (220x220x100x1)
Convert 48 DICOM as /home/tb571/tmp/t2_spc_sag_p2_iso_MPR_COR_T2_SPACE (220x220x48x1)
Convert 5402 DICOM as /home/tb571/tmp/High_b_ep2d_diff (128x128x73x74)
Convert 80 DICOM as /home/tb571/tmp/t2_spc_sag_p2_iso_MPR_AX_T2_SPACE (220x220x80x1)
Convert 73 DICOM as /home/tb571/tmp/AX_T2 (128x128x73x1)
Convert 37 DICOM as /home/tb571/tmp/t2_spc_sag_p2_iso_MPR_SAG_T2_SPACE_L-R (220x220x37x1)
Convert 40 DICOM as /home/tb571/tmp/MPRAGE_1mm_iso_MPR_AX_T1_MPRAGE (220x220x40x1)
Slices not stacked: orientation varies (vNav or localizer?) [1 0 0 0 1 0] != [1 0 0 0 0 -1]
Convert 1 DICOM as /home/tb571/tmp/localizer_i00003 (512x512x1x1)
Warning: Check that 2D images are not mirrored.
Convert 1 DICOM as /home/tb571/tmp/localizer_i00002 (512x512x1x1)
Warning: Check that 2D images are not mirrored.
Convert 1 DICOM as /home/tb571/tmp/localizer_i00001 (512x512x1x1)
Warning: Check that 2D images are not mirrored.
Convert 40 DICOM as /home/tb571/tmp/MPRAGE_1mm_iso_MPR_SAG_T1_MPRAGE (220x220x40x1)
Convert 176 DICOM as /home/tb571/tmp/MPRAGE_1mm_iso (256x256x176x1)
Convert 149 DICOM as /home/tb571/tmp/ep2d_bold (64x64x49x149)
Convert 176 DICOM as /home/tb571/tmp/SAG_3D_T2_FLAIR (256x256x176x1)
Convert 176 DICOM as /home/tb571/tmp/t2_spc_sag_p2_iso (256x256x176x1)
Conversion required 57.120454 seconds (38.860001 for core code).

Expected behavior

Mostly non-zero bvalues and bvecs

Additional information

Used the latest stable release.

@neurolabusc
Copy link
Collaborator

These Siemens E11 images had the CSA header removed. Indeed, no private tags survive. I presume an over-aggressive anonymization was applied.

Images are impoverished and many details are removed, including but not limited to

SliceNormalVector
DiffusionGradientDirection
SliceMeasurementDuration
BandwidthPerPixelPhaseEncode
PhaseEncodingDirectionPositive

Obviously, without DiffusionGradientDirection the bvecs are lost.

This reflects a limitation of your images, not my software. Check the provenance of your images and convert images prior to the removal of these critical tags.

@tashrifbillah
Copy link
Contributor

Between the time we reported and now, we figured the missing tags and looking into the effect of anonymization.

@yxm-9625-cj
Copy link

@tashrifbillah
I have the same warning: Guessing this is a mosaic up to 100 slices (issue 337). , how do you deal with it? could you help me in this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants