Enforcing TE order for multi-echo fMRI

46 views
Skip to first unread message

Elizabeth DuPre

unread,
Mar 1, 2018, 6:52:57 PM3/1/18
to bids-di...@googlegroups.com
Hi all,

This is a detail in the current BIDS spec for multi-echo fMRI which does not seem to be settled. It would be great to enforce an ordering for the multiple TEs in multi-echo fMRI data. Currently, it seems that any sequential ordering is accepted, with `*_echo-1*` as either the longest or the shortest echo.

Is there any objection to standardizing this so that `*_echo-1*` is always the shortest echo (i.e., has the shortest TE), and all subsequent echos occur in sequential order ? Would love to know your thoughts !

Thanks,

Elizabeth

Chris Gorgolewski

unread,
Mar 2, 2018, 8:41:48 AM3/2/18
to bids-discussion
Thanks for bringing this up. +1 for adding this clarification to the spec.

Best,
Chris

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CAAucEq-X_NVZ9QyZGCChJ%3DjB8MTdCrdn0WVjJYfYznN81VR%3DZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Daniel Handwerker

unread,
Mar 2, 2018, 9:00:50 AM3/2/18
to The Brain Imaging Data Structure (BIDS) discussion
As another multi-echo user, I have no objections. Perhaps there's a big-endian subgroup of multi-echo users somewhere who put the longest echo first, but every data set I've seen puts the shortest echo first. This might be useful to standardize before such variation arises.

Best,

Dan

Harms, Michael

unread,
Mar 2, 2018, 9:13:03 AM3/2/18
to bids-di...@googlegroups.com

 

While that could be *suggested* for BIDS 1.x, wouldn’t *requiring* that under the 1.x spec represent a “backwards incompatibility”, since there may possibly be datasets where such ordering isn’t the case?

 

Also, this is a broader issue than just multi-echo, and could be applied to any key/tag with an <index> component.  E.g., Should there be any expectation that the <index> value in “run-<index>” is sequentially incremented according to the temporal order of acquisition?

 

Cheers,

-MH

 

-- 

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: mha...@wustl.edu

 

From: <bids-di...@googlegroups.com> on behalf of Chris Gorgolewski <krzysztof....@gmail.com>
Reply-To: "bids-di...@googlegroups.com" <bids-di...@googlegroups.com>
Date: Friday, March 2, 2018 at 7:42 AM
To: bids-discussion <bids-di...@googlegroups.com>
Subject: Re: [bids-discussion] Enforcing TE order for multi-echo fMRI

 

Thanks for bringing this up. +1 for adding this clarification to the spec.

Best,
Chris

On Mar 1, 2018 3:52 PM, "Elizabeth DuPre" <elizabet...@gmail.com> wrote:

Hi all,

This is a detail in the current BIDS spec for multi-echo fMRI which does not seem to be settled. It would be great to enforce an ordering for the multiple TEs in multi-echo fMRI data. Currently, it seems that any sequential ordering is accepted, with `*_echo-1*` as either the longest or the shortest echo.

Is there any objection to standardizing this so that `*_echo-1*` is always the shortest echo (i.e., has the shortest TE), and all subsequent echos occur in sequential order ? Would love to know your thoughts !

Thanks,

Elizabeth

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

 

--

You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CAAQzouPa0N9MQiQa_Y%2BCjM21FRC4VE_u%3DbyqWa0Z%2Bwaw3Sb84g%40mail.gmail.com.


For more options, visit https://groups.google.com/d/optout.

 


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.

Chris Gorgolewski

unread,
Mar 3, 2018, 12:59:09 PM3/3/18
to bids-discussion
That's a good point about backward compatibility.

As for runs - this could potentially also apply, but with the same compatibility constraints you brought up.

Best,
Chris

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

 


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.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/D0188E83-6A04-49AA-B551-FEE078F058A1%40wustl.edu.

Elizabeth DuPre

unread,
Mar 3, 2018, 1:21:59 PM3/3/18
to bids-discussion
 Thanks so much for the feedback !

Regarding the issue of runs, I'm not sure that I directly see the connection. Echos have a different relationship to one another than runs do, as echos are usually not considered independently. The example I can immediately think of where run ordering matters is pre/post intervention, but in the BIDS examples I've seen, this is usually specified in another key/value pair. Could you please clarify why the sequential concern would apply to all key values with a numerical index ?

Thanks again,

Elizabeth

Chris Gorgolewski

unread,
Mar 3, 2018, 4:57:07 PM3/3/18
to bids-discussion
Hi,

The connection between run and echo filename keys is not direct. They both enforce indices as values, they both relate to time (but in slightly different way). The way I understood Michael's comment was that if we are thinking about specifying that "echo-2" has to have large TE value than "echo-1" we might also want to specify that "run-2" has to be acquired after "run-1". Those two additional clarifications are not however linked to each other and decisions about them could be done independently.

They do, however, share the same backward compatibility concern. If there is a dataset out there that used reverse order of echo when saving files (because that was not specified) and a new version of spec will require a particular order that dataset will not be compatible with it.

I hope this clarified things a little.

Best,
Chris

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

Elizabeth DuPre

unread,
Mar 4, 2018, 11:08:47 AM3/4/18
to bids-di...@googlegroups.com
Thanks for clarifying, Chris ! Yes, I think my confusion was if these decisions were linked. I do appreciate the backwards compatibility concern, so if there are no other concerns-- specifically with the idea of enforcing echo ordering-- I can add it as a suggestion to the BIDS 2.0 document.

Best,

Elizabeth

--
You received this message because you are subscribed to a topic in the Google Groups "bids-discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bids-discussion/Utv29uL0Bdc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bids-discussion+unsubscribe@googlegroups.com.

To post to this group, send email to bids-discussion@googlegroups.com.

Chris Gorgolewski

unread,
Mar 4, 2018, 11:21:36 AM3/4/18
to bids-discussion
Great. Thanks!

Best,
Chris

On Mar 4, 2018 8:08 AM, "Elizabeth DuPre" <elizabet...@gmail.com> wrote:
Thanks for clarifying, Chris ! Yes, I think my confusion was if these decisions were linked. I do appreciate the backwards compatibility concern, so if there are no other concerns-- specifically with the idea of enforcing echo ordering-- I can add it as a suggestion to the BIDS 2.0 document.

Best,

Elizabeth
Reply all
Reply to author
Forward
0 new messages