Change RepetitionTime definition to the same one as DICOM field 0018,0080

[tsalo]

Current definition of RepetitionTime in BIDS is not the same as the one in DICOM which might cause confusion. The new definition would be:

The period of time in msec between the beginning of a pulse sequence and the beginning of the succeeding (essentially identical) pulse sequence.

RepetitionTime would also not be mandatory for _bold files and it’s previous role would be replaced by new mandatory TemporalResolution field or (similar TBD) field defined as:

The time in seconds between the beginning of an acquisition of one volume and the beginning of acquisition of the volume following it. Please note that this definition includes time between scans (when no data has been acquired) in 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.

Relevant discussion:

https://groups.google.com/d/msg/bids-discussion/MLUqmcD1XSY/_lMkr00yAwAJ

https://groups.google.com/d/msg/bids-discussion/wtolT5qPjy0/k2avH_1mCAAJ

Original authors: @mharms

[tsalo]

@Gilles86 wrote:

The period of time in msec between the beginning of a pulse sequence and the beginning of the succeeding (essentially identical) pulse sequence.

Note that for inversion recovery sequences (e.g., MP(2)RAGE), this corresponds to the time between inversion pulses.

For GRE sequences (i.e., FLASH), this corresponds to the time between excitations.

Unfortunately, the much-used MP(2)RAGE sequences consists of inversion pulses interspersed with GRE readout blocks.

To calculate quantities like T1 from a set of MP2RAGE images, we need both the time between inversion pulses and the time between excitations in the subsequent GRE blocks. Maybe we should include an additional "ExcitationRepetitionTime"-field for that?

One alternative would be to deduce this time between excitations using the number of k-space lines, acceleration, and the TotalReadoutTime, but this seems tricky to me...

[tsalo]

@tiborauer wrote:

RepetitionTime would also not be mandatory for _bold files and it’s previous role would be replaced by new mandatory TemporalResolution field or (similar TBD) field defined as:

There are two different versions of 0018,0080: http://dicomlookup.com/lookup.asp?sw=Tnumber&q=(0018,0080)

1. The period of time in msec between the beginning of a pulse sequence and the beginning of the succeeding (essentially identical) pulse sequence. Required except when Scanning Sequence (0018,0020) is EP (EPI) and Sequence Variant (0018,0021) is not SK (segmented K-space). This interpretation is not for standard EPI.

2. The time in ms between two successive excitations of the same volume. Shall be 0 (zero) if there is a single excitation per volume. Required if Frame Type (0008,9007) Value 1 of this frame is ORIGINAL. May be present otherwise. This is more general, therefore, more fitting for EPI (and other purposes).

[tsalo]

@tiborauer wrote:

RepetitionTime would also not be mandatory for _bold files and it’s previous role would be replaced by new mandatory TemporalResolution field or (similar TBD) field defined as:

Therefore, I propose the second definition and making it mandatory for all (also for BOLD). It should also replace RepetitionTime 'patches' (e.g. RepetitionTimeExcitation for structural) in BIDS 1.

[tiborauer]

@tsalo, I think you quote yourself and not me. :)

Otherwise, I agree.

[tsalo]

@tiborauer The quote is yours from the BIDS 2.0 doc, but it's from July 20, 2018.

[tiborauer]

Oh, I see. I almost forgot that document. It is great to see its resurrection.

I think I actually wrote everything else but the one in the quote in the two comments. Do not you want me to paste them properly capture provenance? :D

[tsalo]

You wrote the original suggestion? I'll update the "Original Authors" with you instead of Harms if so.

[tiborauer]

See my suggestions here

[tsalo]

Ah, I see. The way I've written these issues, the quoted parts are quotes from previous comments to retain threads. The non-quoted part is what you wrote. This is just because GitHub issues don't thread the way Google Doc comments do.

[tsalo]

@tiborauer do you know if the changes in BEP001 encompass this? I recall there being something about redefining RepetitionTime, but I don't know if it's the same definition as from the DICOM standard.

[tiborauer]

Partially. As you can see here, BEP001 keep the original definition but expands on the one suggested here (i.e. "the period of time in msec between the beginning of a pulse sequence and the beginning of the succeeding (essentially identical) pulse sequence"). However, it also defines two 'patches', as you can see here.

[tsalo]

Thanks! Okay, so it seems like BEP001 provides an intermediate solution, in which case this proposal is still relevant for 2.0.