Adjust definition of `RepetitionTime` in section 8.3.3 and add two new fields in section 8.3.2

[KirstieJane]

PROPOSAL: Adjust the definition of RepetitionTime in section 8.3.3 Task (including resting state) imaging data and add two new fields to section 8.3.2 Anatomy imaging data.

Justification: RepetitionTime is currently defined very specifically as relating to functional imaging data. However there are structural scans that collect multiple volumes during an acquisition. Here we adjust the definition of RepetitionTime in section 8.3.3 and add RepetitionTimeExcitation and RepetitionTimeInversion as two additional terms for structural acquisitions that include multiple contrasts.

See Proposal_RepetitionTime.md for details.

[chrisgorgo]

That's a +1 from me! Thanks for putting this together.

Best, Chris

On Mon, Sep 3, 2018 at 10:35 AM Kirstie Whitaker notifications@github.com wrote:

PROPOSAL: Adjust the definition of RepetitionTime in section 8.3.3 Task (including resting state) imaging data https://docs.google.com/document/d/1HFUkAEE-pB-angVcYe6pf_-fVf4sCpOHKesUvfb8Grc/edit#bookmark=id.jm7qgqg5x2on and add two new fields to section 8.3.2 Anatomy imaging data https://docs.google.com/document/d/1HFUkAEE-pB-angVcYe6pf_-fVf4sCpOHKesUvfb8Grc/edit#bookmark=id.3pszfzgi4dpj .

Justification: RepetitionTime is currently defined very specifically as relating to functional imaging data. However there are structural scans that collect multiple volumes during an acquisition. Here we adjust the definition of RepetitionTime in section 8.3.3 and add RepetitionTimeExcitation and RepetitionTimeInversion as two additional terms for structural acquisitions that include multiple contrasts. Add to 8.3.2 Anatomy imaging data

Some meta information about the acquisition MAY be provided in an additional JSON file. See Common MR metadata fields for a list of terms and their definitions. There are also some OPTIONAL JSON fields specific to anatomical scans:

• RepetitionTimeExcitation: The time in seconds between successive excitation pulses that excite the same tissue. As with RepetitionTimeInversion this corresponds to DICOM Tag 0018, 0080 http://dicomlookup.com/lookup.asp?sw=Tnumber&q=(0018,0080): “the period of time … between the beginning of a pulse sequence and the beginning of the succeeding (essentially identical) pulse sequence”. Note that although this would typically be called RepetitionTime please use RepetitionTimeExcitation for structural scans with multiple excitations as RepetitionTime is already defined as the amount of time that it takes to acquire a single volume in section 8.3.3 and to distinguish it from RepetitionTimeInversion.
• RepetitionTimeInversion: The time in seconds between successive inversion pulses in an inversion recovery (IR) sequence, such as MP(2)RAGE. As with RepetitionTimeExcitation this corresponds to DICOM Tag 0018, 0080 http://dicomlookup.com/lookup.asp?sw=Tnumber&q=(0018,0080): “the period of time … between the beginning of a pulse sequence and the beginning of the succeeding (essentially identical) pulse sequence”. Note that although this would typically be called RepetitionTime please use RepetitionTimeInversion for structural scans with successive inversion pulses as RepetitionTime is already defined as the amount of time that it takes to acquire a single volume in section 8.3.3 and to distinguish it from RepetitionTimeExcitation.

Change in 8.3.3 Task (including resting state) imaging data

Some meta information about the acquisition MUST be provided in an additional JSON file.

Required fields:

• RepetitionTime: The time in seconds between the beginning of an acquisition of one volume and the beginning of acquisition of the volume following it (TR). When used in the context of functional acquisitions this parameter best corresponds to DICOM Tag 0020,0110 http://dicomlookup.com/lookup.asp?sw=Tnumber&q=(0020,0110): the “time delta between images in a dynamic of functional set of images” but may be found in DICOM Tag 0018, 0080 http://dicomlookup.com/lookup.asp?sw=Tnumber&q=(0018,0080): “the period of time in msec between the beginning of a pulse sequence and the beginning of the succeeding (essentially identical) pulse sequence”. (Remember that DICOM measures must be converted from milliseconds to seconds to fit the BIDS specification.) Note that the definition includes time between scans when no data has been acquired in the case of sparse acquisition schemes. This value needs to be consistent with the ' pixdim[4]' field (after accounting for units stored in 'xyzt_units' field) in the NIfTI header. This field is mutually exclusive with VolumeTiming.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/INCF/BEP001/issues/4, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOkp6DtdN5IXq3q8eaAAhPnPdLy5-vJks5uXWhGgaJpZM4WX6Zw .

[KirstieJane]

Thanks @chrisfilo! I've adjusted the issue and linked to a file that make super clear what I'm suggesting. The content is the same as the wording in the issue when you read it though 😸.

[KirstieJane]

There was also a +1 from @effigies on the mailing list too and no other comments....so this looks ready to go!

[Gilles86]

Mathieu Boudreau (@mathieuboudreau) made the following comment in the Google doc:

In MPRAGE and IR, the inversion pulse acts as a preparation pulse for the magnetization prior to the imaging readout. This pattern repeats itself in several other quantitative MRI techniques (e.g. quantitative magnatization transter, where the preparation pulse here is instead an off-resonance pulse of a specific shape and length). Would it not be better to have a RepetitionTimePreparationPulse-type general parameter instead of having several one for each types of preparation pulses (e.g. RepetitionTimeExcitation, RepetitionTimeInversion, RepetitionTimeMTPulse, etc)? Another example is Saturation Recovery T1 mapping, where the preparation pulse is a 90 degree pulse, instead of a 180. In MRI literature, these are all simply referred to as "repetition time", so it's unclear to me why we need several names to distinguish each of these.

I think this is worth to think about.

[mathieuboudreau]

Maybe "PulseSequenceRepetitionTime" could be another option?

[Gilles86]

Maybe "PulseSequenceRepetitionTime" would be another option?

RepetitionTimePulseSequence? :P

[Gilles86]

The current text says:

When used in the context of functional acquisitions this parameter best corresponds to DICOM Tag 0020,0110: the "time delta between images in a dynamic of functional set of images" but may be found in DICOM Tag 0018, 0080: "the period of time in msec between the beginning of a pulse sequence and the beginning of the succeeding (essentially identical) pulse sequence".

The DICOM tag 0018, 0080 is "wrong" for segmented EPIs where multiple shots are made per volume (the time between shots is less than the time it takes to get a volume). I would leave that out or maybe even say it does not correspond. What do you hink?

[mathieuboudreau]

I think specifying that tags 0020,0110 and 008,0080 only match for the single-shot EPI case is worth mentioning if it's kept. Otherwise yeah, remove the mention to 008,0080, or explain how it differs since they can sometimes (but not always) match.

[spinicist]

Hi,

as I commented on Agah's spreadsheet, if a student on our MSc course wrote "Inversion Repetition Time" or similar on an exam, I would fail them. You will not find that as a term in the physics literature anywhere, and it conflates two very separate properties of a sequence.

In my opinion, the usage of "TR" to refer to the time between imaging/readout pulses is well established. That's the convention in the original MP2RAGE paper (https://www.sciencedirect.com/science/article/pii/S1053811909010738, equation A1.1), the Deichmann MPRAGE paper (DOI: 10.1006/nimg.2000.0601) and every other paper I can think of.

To process an MP2RAGE dataset (which is where I think the need for these terms has arisen), you need to know TR, the number of readouts in one segment (ETL), the two Inversion Times (TI), and also the delay time (TD) after the end of the second readout train. This then defines the "other" repetition time, which is equal to TI2+ETL*TR+TD

In the MP2RAGE paper the "other" repetition time is referred to as "MP2RAGETR", which is a mouthful. In the Deichmann MPRAGE paper, this quantity is not named explicitly.

In QUIT, I refer to this quantity as the "Segment TR", shortened to SegTR in the input files (https://quit.readthedocs.io/en/sphinx/Docs/Relaxometry.html#qimp2rage). This is a terminology picked up from our old Agilent scanner, but in my opinion it is the correct one, as an MPRAGE type sequence is inherently a segmented sequence.

[Gilles86]

Hey Tobias,

as I commented on Agah's spreadsheet, if a student on our MSc course wrote "Inversion Repetition Time" or similar on an exam, I would fail them. You will not find that as a term in the physics literature anywhere, and it conflates two very separate properties of a sequence.

Thanks for your feedback. It is helpful to know that the BIDS community would fail your MSc course. It shows that we need people like you to align BIDS with the MR physics literature!

For the interested reader, the spreadsheet can be found here: https://docs.google.com/spreadsheets/d/1awzGVflxXiWtzeLVOH5XI8Bar2ND9759yZxsK3stCzc/edit#gid=0

So I think you proposed three alternatives here:

1) To use a set of other parameters to calculate the MP2RAGETR. Off the top of my that means we would now also have to include Time Delay and echo train length into our spec and let developers include this calculation. To me, this seems a bit less user-friendly and a bit more error-prone than other alternatives. 2) Use the moutfhul of "MP2RAGETR". This would be very specific to MP2RAGE sequences though. 3) Your preference seems to be to use the term RepetitionTimeSegment or something similar. This seems very close to the proposal of using RepetitionTimePulseSequence. Can you explain why you like RepetitionTimeSegment more? Do you have a pointer to MR physics literature where this term is used?

[spinicist]

Hello,

So first off - apologies for my strong wording on Friday. After I had some time to think about it, InversionRepetitionTime is not actually such a bad name - as it is the amount of time it takes to repeat the inversion pulse (I still think the likelihood is that one of our students would have mixed TI and TR if they ever wrote that though). However, I think my initial reaction shows you the kind of problem you are going to face a lot trying to write this standard - these terms are not even standardised among physicists! You also have the perennial MR problem of how you would translate the written/spoken term into a symbol for the equations, especially given that MR is the only topic (to my knowledge) that allows multi-letter combinations to represent one term. Repetition Time is TR, Inversion Time is TI, so Inversion Repetition Time would be???? TIR????

In answer to your points:

1. You will have to add one of either Time Delay or Echo Train Length anyway. To uniquely determine the timing of the MP2RAGE sequence, you need to know (using my terminology for a moment) TI1, TI2, ETL, TR & TD (and also if the sequence is centric or linear). If you know SegTR, then you can calculate one of those terms from the others. On the scanners I use, SegTR is the parameter on the console, not TD, so I ask users for that and then calculate TD.

Note that Echo Train Length is a term that is most commonly for fast-spin echo imaging where one initial 90 degree flip is refocussed into multiple echoes, whereas here we generate fresh gradient echoes after each readout pulse. Segment Length might be a better term, but I've not seen that used in the literature. 2/3. If you want to generalise it, you could go for PreparationRepetitionTime. After all, MP-RAGE does stand for Magnetisation Prepared Rapid Acqusition of Gradient Echoes, and the Inversion prep in what everyone calls MP2RAGE is a special case of that (Although the authors themselves broke this by coming up with the SA2RAGE sequence and not renaming MP2RAGE to IR2RAGE). Hmmm, I think I like PreparationRepetitionTime. Could go down as TP in equations.

Final note - I'd prefer to have the terms written "XRepetitionTime" rather than "RepetitionTimeX", I think it reads better in English.

[KirstieJane]

Hi @spinicist! Thank you for commenting - I'm sorry for the slow reply.

I'm not 100% following exactly what you're proposing to add to the standard. There's a proposal here: https://github.com/INCF/BEP001/blob/repetitiontime/Proposal_RepetitionTime.md. Maybe you could submit a pull request to that branch with the additional wording that you're recommending.

One note: the RepetitionTimeX vs XRepetitionTime discussion was one that had already been had extensively before you joined the project. We voted on RepetitionTimeX so that the metadata was listed in alphabetical order to help human readers understand the distinctions. If you feel really strongly about re-opening that decision you're of course welcome to, but I just wanted you to know that there has already been a vote on that point, and as it doesn't affect the usage of BIDS metadata (only the human readable aspect) then it might not be an important conversation to re-have.

[spinicist]

Hello,

My main post was on the Google group, the comment here was an extension of that.

I'm clearly late to the party here, so I don't really want to get in your way. However, I will note that if you wanted all the timing parameters in the meta-data to show up next to each other in alphabetical order, then Time should have been the first term (i.e. both RepetitionTimeX and XRepetitionTime are suboptimal), as otherwise EchoTime will be at the other end of the list. I am fairly certain this is why the TR, TE, T1, etc. convention was adopted for equations, to emphasise that these are all times.

For this particular proposal, I'll note that:

1. In the case of MP2RAGE, adopting a separate RepetitionTimeExcitation and leaving RepetitionTime as the "volume" time isn't very helpful, because the two inversion images are acquired interleaved. Hence there is no "volume" time - it's just the total scan time.
2. For any 2D scans (e.g. diffusion) the RepetitionTime is also the "volume" time. The distinction here is not structural versus functional, it's 2D versus 3D. 2D structural/anatomy scans are rare in research but they are still used widely for radiography.

[KirstieJane]

Thanks @spinicist!

We can't change (for example) EchoTime or RepetitionTime as they are already part of the BIDS standard. Changing these names for BIDS 2.0 can be noted in the BIDS 2.0 document.

I'm still not clear on what you're recommending instead of adding RepetitionTimeX (where X is Inversion and Excitation)?

I'm also happy to adjust the wording if you can propose clearer phrasing.

[spinicist]

I am recommending not adding RepetitionTimeExcitation. I can't think of a situation where it would be useful. If someone can give an example, I'll change my mind.

For RepetitionTimeInversion, I think RepetititionTimePreparation is more general. As noted above, in the SA2RAGE sequence the prep module is saturation, not inversion. There are also T2-prepared and diffusion-prepared versions of MPRAGE in existence (but not in widespread usage). RepetitionTimePreparation makes sense for all of those, whereas RepetitionTimeInversion would not.

[Gilles86]

Hey Tobias,

Thanks for your feedback! This issue goes back to a long and heated debate in 2017. Let me summarize it once more:

The reason we have to add RepetitionTimeExcitation is that in sequences like MP2RAGE we have to distinguish between the time between preparation/inversion pulses (e.g., "TR_MP2RAGE" in Marques et al.) and the time between excitations pulses in the GRE readout blocks. (e.g., "TR of the GRE module" in Marques et al. )

If history would have played out differently, and RepetitionTime" in the main BIDS specification was defined as DICOM tag (0018, 0080), 1C "The time in ms between two successive excitations of the same volume. ", we could have used RepetitionTime, like you reccomend here.

However, the definition of RepetitionTime in the BIDS spec 1.0 is as follows:

The time in seconds between the beginning of an acquisition of one volume and the beginning of acquisition of the volume following it (TR).

This is, thus, the time it takes to acquire an entire volume, which in the case of 2D acquisitions is the same as the time between succesive excitations, but not in 3D sequences, like most structural acquisitions.

We decided we cannot change the BIDS 1.0 specification post-hoc and to be fully unambiguous we have to add another tag, namely RepetitionTimeExcitation. Another solution would be to have different definitions for RepetitionTime for functional and structural scans, but we think that would be even more confusing.

Please let me know if you have any other questions about this, or maybe you another way of solving the conundrum :).

I like your idea of using RepetititionTimePreparation. Let's discuss it next meeting.

Cheers, Gilles

On Tue, Nov 20, 2018 at 10:08 AM Tobias Wood notifications@github.com wrote:

I am recommending not adding RepetitionTimeExcitation. I can't think of a situation where it would be useful. If someone can give an example, I'll change my mind.

For RepetitionTimeInversion, I think RepetititionTimePreparation is more general. As noted above, in the SA2RAGE sequence the prep module is saturation, not inversion. There are also T2-prepared and diffusion-prepared versions of MPRAGE in existence (but not in widespread usage). RepetitionTimePreparation makes sense for all of those, whereas RepetitionTimeInversion would not.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bids-standard/bep001/issues/4#issuecomment-440197287, or mute the thread https://github.com/notifications/unsubscribe-auth/ABD4zkcMUlTccrv3mIOs0qBZEm6VtQz-ks5uw8aUgaJpZM4WX6Zw .

-- Gilles de Hollander Postdoctoral Researcher Department of Experimental and Applied Psychology, http://www.vupsy.nl/ https://webmail.login.vu.nl/OWA/redir.aspx?C=MeXKTnHrb7rqNpc5d9_z4HY5RYvDrp4dMHZjA7VgV9-renkmXN7UCA..&URL=http%3a%2f%2fwww.vupsy.nl%2f Faculty of Behavioural and Movement Sciences Van der Boechorststraat 1, 1081 BT Amsterdam | Room 1B75 website http://www.gillesdehollander.nl/ | github https://github.com/Gilles86/

[spinicist]

Hi @Gilles86 - please see my response above yours.

Currently the proposal is to add both RepetitionTimeExcitation and RepetitionTimeInversion (or my preference RepetitionTimePreparation), which when added to RepetitionTime will result in 3 terms, one of which will be entirely superfluous. This an opportunity for error and confusion, so I don't think all 3 entries should exist.

To use your own example, in an MP2RAGE sequence the BIDS 1.0 definition of RepetitionTime is entirely meaningless. What value would you set this to for an MP2RAGE image?

[KirstieJane]

Hi @spinicist. I'm very confident that @Gilles86 had read your reply. Please make sure to stay as collegiate as possible in this discussion which, as Gilles said, has been going on for more than a year with some very passionate conversations causing frayed nerves all around.

RepetitionTime is not a required field for structural images, so it would not be set for a structural image that needed RepetitionTimeExcitation and RepetitionTimePreparation.

I can't think of a way of rephrasing the current definition of RepetitionTime that's in the BIDS that doesn't introduce more confusion for the large proportion of users who will use RepetitionTime to capture the time between volumes during a standard EPI functional MRI scan.

[spinicist]

If only one of RepetitionTime and RepetitionTimeExcitation is present then I have no further objections.

[KirstieJane]

Coolio - I'll leave myself an action here to make sure that that is clear in the proposal (I'm just figuring some bug out at the moment 🐛)

• [ ] Action: make sure it is clear that RepetitionTime is not necessary for structural scans that have other RepetitionTimeX metadata.

[mathieuboudreau]

How about RepetitionTime + RepititionTimePulseSequence (to be explicit that it's the MR physicist's TR)?

I think it's as general as ReptitionTimePreparation, but a bit less confusing/more clear (I know, I'm the one who first recommended that name ??)

Télécharger Outlook pour Androidhttps://aka.ms/ghei36

---

From: Tobias Wood notifications@github.com Sent: Tuesday, November 20, 2018 8:13:28 AM To: bids-standard/bep001 Cc: Mathieu Boudreau; Mention Subject: Re: [bids-standard/bep001] Adjust definition of RepetitionTime in section 8.3.3 and add two new fields in section 8.3.2 (#4)

If only one of RepetitionTime and RepetitionTimeExcitation is present then I have no further objections.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/bids-standard/bep001/issues/4#issuecomment-440244590, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABWu5SFnRLmzViMOUwnBfdl3hwgzWorwks5uw-rggaJpZM4WX6Zw.

[KirstieJane]

@mathieuboudreau - this is the same question as I had for @spinicist: can you suggest how you'd redefined RepetitionTime from the definition that's currently in the BIDS specification to make it clearer?

How would you define RepetitionTimePreparation?

For reference, my attempt at defining the updates is at: https://github.com/bids-standard/bep001/blob/repetitiontime/Proposal_RepetitionTime.md

[mathieuboudreau]

Oh sorry for that. I'm only on my phone at the moment, but the definition on MR-Tip looks to be close to what I believe it is, and more general than the time between succesive excitation pulse: https://www.mr-tip.com/serv1.php?type=db1&dbs=Repetition%20Time

What do you think @spinicist?

Télécharger Outlook pour Androidhttps://aka.ms/ghei36

---

From: Kirstie Whitaker notifications@github.com Sent: Tuesday, November 20, 2018 8:25:19 AM To: bids-standard/bep001 Cc: Mathieu Boudreau; Mention Subject: Re: [bids-standard/bep001] Adjust definition of RepetitionTime in section 8.3.3 and add two new fields in section 8.3.2 (#4)

@mathieuboudreauhttps://github.com/mathieuboudreau - this is the same question as I had for @spinicisthttps://github.com/spinicist: can you suggest how you'd redefined RepetitionTime from the definition that's currently in the BIDS specification to make it clearer?

How would you define RepetitionTimePreparation?

For reference, my attempt at defining the updates is at: https://github.com/bids-standard/bep001/blob/repetitiontime/Proposal_RepetitionTime.md

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/bids-standard/bep001/issues/4#issuecomment-440247531, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABWu5aG9wIW2DkhdVlV1XZmkfq9DrGDVks5uw-2ngaJpZM4WX6Zw.

[spinicist]

@KirstieJane / @mathieuboudreau I think I am missing the point of the question, but if you used your definition of RepetitionTimeExcitation as the definition of RepetitionTime then it resolves everything. The time between successive excitations of the same tissue is the volume time in a 2D sequence.

If you swap all instances Inversion for Preparation in the current definition of RepetitionTimeInversion, and then say "For example, in an MP2RAGE sequence this would be the time between successive inversion pulses" I think it is clear.

[KirstieJane]

My feeling is that that is too big a change to the Task (including resting state) imaging data section of the specification for the majority of BIDS users.

I don't have a problem with Preparation instead of Inversion - happy to discuss in the meeting on Wednesday 28.

I have to head into another meeting. If either of you have time to submit a pull request to update my proposal it would be really helpful to have something concrete to discuss.

[Gilles86]

@KirstieJane https://github.com/KirstieJane / @mathieuboudreau https://github.com/mathieuboudreau I think I am missing the point of the question, but if you used your definition of RepetitionTimeExcitation as the definition of RepetitionTime then it resolves everything. The time between successive excitations of the same tissue is the volume time in a 2D sequence.

We can not do this, because we cannot change the current BIDS specification of RepetitionTime post-hoc.

On Tue, Nov 20, 2018 at 1:05 PM Tobias Wood notifications@github.com wrote:

@KirstieJane https://github.com/KirstieJane / @mathieuboudreau https://github.com/mathieuboudreau I think I am missing the point of the question, but if you used your definition of RepetitionTimeExcitation as the definition of RepetitionTime then it resolves everything. The time between successive excitations of the same tissue is the volume time in a 2D sequence.

If you swap all instances Inversion for Preparation in the current definition of RepetitionTimeInversion, and then say "For example, in an MP2RAGE sequence this would be the time between successive inversion pulses" I think it is clear.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bids-standard/bep001/issues/4#issuecomment-440250096, or mute the thread https://github.com/notifications/unsubscribe-auth/ABD4zqyYWl9NE6kb4q0F8cYize8RTeIsks5uw-_zgaJpZM4WX6Zw .

-- Gilles de Hollander Postdoctoral Researcher Department of Experimental and Applied Psychology, http://www.vupsy.nl/ https://webmail.login.vu.nl/OWA/redir.aspx?C=MeXKTnHrb7rqNpc5d9_z4HY5RYvDrp4dMHZjA7VgV9-renkmXN7UCA..&URL=http%3a%2f%2fwww.vupsy.nl%2f Faculty of Behavioural and Movement Sciences Van der Boechorststraat 1, 1081 BT Amsterdam | Room 1B75 website http://www.gillesdehollander.nl/ | github https://github.com/Gilles86/

[Gilles86]

See pull request https://github.com/bids-standard/bep001/pull/13