Transfer of issues from original google doc BEP-001 file

[Gilles86]

As discussed in the January call, I would have a look at the old Google Doc to see if any issues were raised there that we have not tackled or discussed in the github repo yet.

Rename RepetitionTimeInversion Mathieu Boudreau suggested to rename the RepetitionTimeInversion, to make it also apply to other preparation pulses. We decided to do so and @agahkarakuzu implemented it in the curren text (this commit). :white_check_mark:

part- tag Michael P Harms asked whether we should really incorporate the part-tag. We decided to do so and have done so. :white_check_mark:

Sequences with different TRs Dylan Nielson suggested to add a tag for identical scans with different TRs. Chris Gorgolewski suggested to use the acq-tag for that.

:white_check_mark: I think Chris's suggestion makes a lot of sense, since unlike multi-echo or -inversion sequences, the different TRs really belong to different acquisitions.

What ordering of key-value tags

If used, must increasing correspond in a one-to-one fashion with increasing values in the underlying parameter?

:ballot_box_with_check: This has never really been resolved. We should discuss this in the next call.

What about SPACE sequence Michael P Harms:

Where does Siemens "SPACE" sequence fall into this?

:white_check_mark: This has been incorporated in the main text now.

DESPOT1/2 Tobias Wood:

DESPOT1 and DESPOT2 are NOT sequence names. They are "techniques" or "experiment" names. The most general sequence names are Gradient Echo / Gradient Recalled Echo / GRE and balanced Steady-State Free Precession / bSSFP respectively

Ali Khan:

I am all for using the more general name when possible, but also pointing out that in many cases for DESPOT1/2 the GRE/SSFP sequence code is customized to some degree, and one could imagine a DESPOT fitting app should ideally have some easy way of locating input images

 :ballot_box_with_check: This has never really been resolved, although Ali Khan's argument makes sense and no one objected again. Also, we let data set maintainers somewhat free in choosing their sequence_label (now: suffix).

FLASH is a proprieaty, vendor-specific name? Gilles de Hollander:

Some people have suggested that this term is vendor (Siemens)-specific. However, I think this is the term that I most often encounter in the literature. Anyone has a non-vendor specific alternative? Or maybe we should use an ever broader term like just "GRE"?

Tobias Wood:

FLASH is indeed Siemens & Bruker specific. Siemens just happens to have the largest share of the research market currently. FLASH is called SPGR on GE and Fast-Field Echo or FFE on Phillips. GRE is the most general name. And it's shorter.

:white_check_mark: No explicit decision was made I think. However, again, there is some flexibility in choosing a suffix.

What about MPnRAGE Some people argued both the suffix MPRAGE with two inv-tags or the suffix MP2RAGE are defendable.

:white_check_mark: In November call we decided for the suffix MP2RAGE, since the contrast of these images can be very different. See also this issue

Quantitative maps are different Daniel Handwerker:

I think it's critical to distinguish the images reconstructed from k-space from images that are some type of combination of images reconstructed from k-space, such as a quantitative T1 map. This will be a big deal because I think the number of "post-processed" images generated right of the scanner will expand much faster than the orig recon images. Categorizing "T1map" as a postprocessed image would be a good foundational step for this. My add-on suggestion is that, in the JSON file for any post-processed image, the math underlying how images are combined is part of that file. The "equation" could be: The method published in X" or, less ideally, "The method built into this pulse sequence (With the sequence version info definitively also in the JSON file)

:white_check_mark: quantitative data should be in derivatives-folder, but can be symlinked to souredata to ease processing.

Different B1 maps Tobias Wood:

There needs to be two labels, one for a 'true' B1+ map (non-selective/transmit inhomogeneity) and one incorporating the slab-profile.

:ballot_box_with_check: Not sure about this one. Can't it be handled with a acq-label?

MTsat? Mathieu Boudreau:

Is MT-map MTsat? If so I think it should be named that way, as it should be clearly differentiated from MTR and qMT maps, which other people may also consider to be "MT-maps".

:white_check_mark: Solved

NumberShots is ambivalent Michael P Harms:

Is this linked to any particular DICOM field? I'm concerned that the initial choice for this name of this variable may be vendor specific. e.g., Siemens lists a "Turbo Factor" for its MPRAGE and SPACE scans -- is that the same thing? And "EPIFactor" for its EPI sequences.

 :ballot_box_with_check: Original BIDS spec doesn't really care about difference between ExcitationPulses and PreparationPulses. Not sure how to improve though.

_FLASH or suffix for MPM data? For the MPM examples that Kirstie made, she used suffixe _T1w, _PDw and MTw. Myself, Agah and Mathie argued that _FLASH might be more appropriate, since the only difference between these sequences are the acquisition parameters.

 :ballot_box_with_check: Not sure. I think the 'some freedom for the data set maintainer in which suffix to choose for which data set, depending on context'-approach might solve this.

[KirstieJane]

AMAZING @Gilles86! Thank you!!