Changing default output format

[lrq3000]

Continuation from rordenlab/dcm2niix#242

I suggest to change the default output format to at least include %d and to extend the tooltip or the default message in the console to include all formatting options. Indeed, only %d allows to disambiguate some sequences (eg, MoCoSeries on Siemens machines, and pretty much any dual stream sequence).

Here is a comparison:

%t_%p_%s: 20140519131916_ep2d_bold_repos_7.nii
%f_%p_%t_%s: DICOM_ep2d_bold_repos_20140519131916_7.nii
%n_%t_%p_%d_%z_%s: NAME_20140519131916_ep2d_bold_repos_MoCoSeries__epfid2d1_64_7.nii

I suggest these changes as the GUI is presumably made for people who do not like or are not accustomed to using the commandline, and formatting options are currently mostly accessible only via commandline, which prevent adequate use from most GUI users.

[neurolabusc]

The DICOM image comments (0020,4000) is a public tag, but it is very rarely seen outside of Siemens and even in Siemens is usually blank or "none". SeriesDescription (0008,103E) is often a duplicate of ProtocolName (0018,1030). But description is always missing from some vendors (e.g. GE). Therefore, I do not think these are good choice for a default naming scheme.

I think Siemens MOCO images might be a special case where this would help disambiguate files, e.g. with field maps we detect echo number and phase/magnitude/real/imaginary automatically. I never acquire MOCO images, as I think post-hoc correction does a good job with image stabilization and provides parameters for statistical regression. I assume the main reason for MOCO is for real time fMRI.

Regardless, maybe you want to submit a feature request as a dcm2niix issue to have the software automaticially detect MOCO series. A good solution might be the approach used by dicm2nii where the word _MoCo is appended to the motion correction series protocol name. It would help greatly if you could provide a sample dataset (only a few volumes required), as I do not have access to any MOCO data.

Beyond MOCO, can you provide an example of other multiple-stream sequences that are not distinguished by the default naming scheme?

[lrq3000]

I understand, it's just that by default, most users with a Siemens machine might get into trouble. I know that the info was missing because of conversion because I worked directly on the protocol design, but most MRI analysts don't know and assume there's no additional info to disambiguate.

This also happens for DTI (where Siemens can generate ADC, FA, Colored FA, tractography, etc), so adding a special case for MOCO would not fix the general issue of dual stream sequences identification on Siemens protocols.

I'll try to prepare an example dataset for you, I'll send you a link when it's ready.

[lrq3000]

Here is a link to the dicoms, the file expires in a week: https://filesender.belnet.be/?s=download&token=964900a3-a74f-e219-11b2-9a44d57eaa03

[neurolabusc]

I never generate derived DWI values (ADC, FA, Trace, etc) on the console - I would strongly recommend that the MRI console is set to only save the original DWI images. You will get much nicer derived images after you degibbs, denoise, and undistort (eddy/TOPUP) your original data.

Since I do not store these console-created derived images, I do not have much experience with them. However, if you have any examples where Siemens saves these with the same series number as the original data I would be grateful if you could share a set with me. Further, you will really want to share these with your Siemens research collaboration manager - these represent a clear violation of the DICOM standard: DERIVED data MUST have a different series number than the ORIGINAL data. In my experience, Siemens increments raw data by 1 (1,2,3..) and derived data by 1000 (1001, 2001, etc). Note that Philips scanners do generate DWI scans where the derived data is erroneously stuffed into the same series as the original data, and dcm2niix will automatically detect this and strip out the offending images.

In brief, for all the Siemens data I have seen (and all legal DICOM files) using %s in your filename should be sufficient to disambiguate original and derived DWI data. The fact that only the original data will have a bvec file ensures that the user will only process the original data. The json files provide further details.

[neurolabusc]

Thank you for the sample images. You can test out the latest dcm2niix commit that will append "_MoCo" to the protocol name of your motion corrected series. It also allows the -i y to automatically detect and ignore your derived DWI series.

As an aside, I would recommend you pull up the protocol for t1_tse_tra on your console and un-check the interpolation option. The resulting files will required 25% of the disk space, process faster. While this is not a DWI dataset, note you can not de-Gibbs interpolated data.

I am closing this issue here - go to the dcm2niix issue if you have comments on the dcm2niix changes.

[lrq3000]

Wow, thank you very much for implementing these changes and for the advice! I will have a look about the interpolation :-) (just out of curiosity, can you tell me how you noticed? Is it a dicom header field?)

[neurolabusc]

You can detect this by comparing the acqusition matrix with the image rows and columns:

• AcquisitionMatrix (0018,1310) = 256*256

• RowsColumns(0028,00100028,0011) 512*512

For Siemens, you can also look for the "I" in this tag:

• AcquisitionMatrixText (0051,100B) "512*512s I"

In these situations, dcm2niix will generate a warning during conversion: Warning: interpolated data may exhibit Gibbs ringing and be unsuitable for dwidenoise/mrdegibbs. /Users/rorden/tst/moco/moco/13_t1_tse_tra_FIL/16.dcm. It will also create a tag in your BIDS file: "Interpolation2D": 1,

[lrq3000]

Great! Thank you very much! :D