Changing default output format about mricrogl10_old HOT 8 CLOSED

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?

from mricrogl10_old.

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.

from mricrogl10_old.

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

from mricrogl10_old.

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.

from mricrogl10_old.

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.

from mricrogl10_old.

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?)

from mricrogl10_old.

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,

from mricrogl10_old.

Great! Thank you very much! :D

from mricrogl10_old.