-
Notifications
You must be signed in to change notification settings - Fork 228
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
adding BIDS EchoTime1, EchoTime2 metadata for fieldmaps? #139
Comments
I do not think this is required, as dcm2niix should save each echo as a separate NIfTI volume with its own json file - so both the NIfTI descrip field and BIDS files should report the echo time for the volume. Images from multiple TRs (e.g. fMRI data) and data with different B-vectors (DTI) are stacked as 4D data, where different echo times and different coils are segmented in different files. I think this is convenient for most tools, which expect data segmented this way. For example it is possible to create fMRI runs with multiple echoes, but the software expects two 4D files with X/Y/Z/T rather than a single volume with X/Y/Z/T/E. As ever, I leave @chrisfilo as the final say for BIDS information, but I think the current solution is consistent and simple. If you have any data that is not segmented like this, I would be interested in seeing a sample. |
In case of two separate volumes each should have it's own sidecar file with |
The standard Siemens GRE fieldmap outputs 2 Magnitude volumes and 1 Phase
difference volume. In this case, the typical inputs to a preprocessing
pipeline would be 1 of those magnitude volumes (not necessarily the first
one, as the resulting fieldmaps dont really depend on which magnitude is
selected) and then the 1 (only) phase volume.
Example: My siemens scanner outputs two dicom directories for a GRE fieldmap
MR-SE013_FieldMap (144 dicom files) ... 72 per magnitude volume (2 volumes)
MR-SE014_FieldMap (72 dicom files) ... only 1 phase
The conversion generates:
13_FieldMap.nii.gz (magnitude at TE1), BIDS json "EchoTime: 0.00492"
13_FieldMap_e2.nii.gz (magnitude at TE2), BIDS json "EchoTime: 0.00738"
14_FIeldMap_e2.nii.gz (phase difference), BIDS json "EchoTime: 0.00738"
In this case, if I provide the 13_FieldMap (mag1) and 14_FieldMap_e2
(phase), I will have both TE's that are needed, but if I provide
13_FieldMap_e2 (mag2) and 14_FieldMap_e2 (phase), then I won't.
…-Keith
-Keith
On Wed, Oct 25, 2017 at 12:01 AM, Chris Filo Gorgolewski < ***@***.***> wrote:
EchoTime1 and EchoTime2 fields are only required when the scanner outputs
phase difference volume instead of two phase volumes (see
https://docs.google.com/document/d/1HFUkAEE-pB-angVcYe6pf_-
fVf4sCpOHKesUvfb8Grc/edit#heading=h.fexn37cr2yum).
In case of two separate volumes each should have it's own sidecar file
with EchoTime field (which is what I think dcm2niix is producing).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#139 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIO8l5JqQMEKB4it94sgoBx5PtFaRxSmks5svnpygaJpZM4QFKCX>
.
|
I see - in this case it would be optimal if dcm2niix produced 14_FIeldMap_e2.json that includes |
Chris Rorden will have to comment, but I’m not sure if that is possible in any straightforward way, because all the slices/DICOMs in the Siemens “Phase Difference” series are stored with a single echo time in the standard DICOM field (0018,0081), corresponding to the 2nd echo time (which is also why the JSON for EchoNumber has the value of 2 for the Phase Difference series):
(0018,0081) DS [7.38] # 4, 1 EchoTime
(0018,0086) IS [2] # 2, 1 EchoNumbers
The other echo time *is* lurking the ASCI header, apparently as microseconds (on a VD11 example I had available):
alTE[0] = 4920
alTE[1] = 7380
but now you’re taking about adding code to the ‘dcm2niix’ conversion that would have to be customized to a specific type of acquisition and recon.
Cheers,
-MH
BTW, @keith: This is tangential, but using the latest (20171017) version of ‘dcm2niix’, I don’t get the echo number included in the file name of the Phase Difference series unless I include ‘e%e’ as part of the ‘-f’ flag in ‘dcm2niix’, but then if you’re using the same conversion flags for all series, I’d have expected the file name for the “magnitude recon at TE1” to include “_e1”.
…--
Michael Harms, Ph.D.
-----------------------------------------------------------
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave. Tel: 314-747-6173
St. Louis, MO 63110 Email: [email protected]
From: Chris Filo Gorgolewski <[email protected]>
Reply-To: rordenlab/dcm2niix <[email protected]>
Date: Tuesday, October 24, 2017 at 7:22 PM
To: rordenlab/dcm2niix <[email protected]>
Cc: Subscribed <[email protected]>
Subject: Re: [rordenlab/dcm2niix] adding BIDS EchoTime1, EchoTime2 metadata for fieldmaps? (#139)
I see - in this case it would be optimal if dcm2niix produced 14_FIeldMap_e2.json that includes EchoTime1 and EchoTime2 fields.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#139 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ADswBh3vrSX_uBlrOR7tMbqhUBfFTmkSks5svn9TgaJpZM4QFKCX>.
________________________________
The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.
|
This might not be within the scope of dcm2niix, but for multi-TE B0 fieldmaps, BIDS metadata expects something like "EchoTime1" "EchoTime2", so that you can extract a delta-TE for preprocessing. Is it possible to automatically add something like that to the BIDS json when appropriate?
The text was updated successfully, but these errors were encountered: