bids-standard / bep001 Goto Github PK

For legacy and logical purposes it makes sense to add a T2starw suffix. This will push T2star into the legacy section of suffix table (see #55) and hopefully make the standard a little more internally consistent.

Assigned to @Gilles86

In bep001-naming-conventions.md we have a 'meta'-key (belonging to a value), defined as [_indexable_metadata-]. This is not ok since it hat an underscore (_). We should replace it with fa, inv, echo and tsl.

I have such a list from the last time I dived into the code:

FieldnamesOriginal	FieldnamesBIDS	                Scaling
RepetitionTime	        ExcitationRepetitionTime	1
EchoTime	        EchoTime	                1
FlipAngle	        FlipAngle	                1
B1mapNominalFAValues	B1mapNominalFAValues	        1
B1mapMixingTime	        MixingTime	                1
epiReadoutDuration	epiReadoutDuration	        1
PhaseEncodingDirectionSign	PhaseEncodingDirectionSign	NaN
ScanningSequence	ScanningSequence	        NaN
SequenceName	        SequenceName	                NaN
ProtocolName	        ProtocolName	                NaN
RFSpoilingPhaseIncrement	RFSpoilingPhaseIncrement	1
spoilingGradientMoment	spoilingGradientMoment	       1
spoilingGradientDuration	spoilingGradientDuration	1

These are a bit outdated but can be easily updated, such that the DICOM-to-NIFTI conversion produces the right BIDS-fields.
Then variable names can easily be updated in the main code, as number crunching routines typically use shorter names and simply 'import' the required parameters at the beginning.

Next dev call: Wednesday 17 April at 6pm CEST / 5pm BST / 12noon EDT / 9am PDT

All welcome, please see BIDS mailing list for zoom link (or ping @KirstieJane!)

Agenda

This agenda is built from the March call (#31) minutes. @KirstieJane has had a little rearrange to hopefull make the meeting flow sensibly 😄

Indexable metadata -- #26

From last month's action list

• Need to add a little more explanation to the indexable_metadata section: #26 (comment) --- @agahkarakuzu

👉 @agahkarakuzu merged PR #37 🚀 ✨ 💯

• Not yet done - add to ProposedChangesToSpecification.md file 😭
  • @KirstieJane has kinda started in #25 (bad git management rather than on purpose) see here but it isn't complete.

Proposed changes to specification -- #41

• Update ProposedChangesToSpecification.md with the changes that @agahkarakuzu made in #30 --- action @agahkarakuzu

• Key discussion had in the call about why we have justified collecting different scans together under one suffix (eg: MP2RAGE and MPM)

Update examples -- issue #34

• There are a couple of inconsistencies with the examples -- specifically that FLASH is currently used as a suffix --- action @alazari

• MPM examples use a bunch of different suffices:
  • Rename sub-01_echo-1_part-mag_MTw.nii.gz --> sub-01_echo-1_aqc-MTon_part-mag_MPM.nii.gz
  • Rename sub-01_echo-1_part-mag_PDw.nii.gz --> sub-01_echo-1_aqc-MToff_part-mag_MPM.nii.gz
  • Rename sub-01_echo-1_part-mag_T1w.nii.gz --> sub-01_echo-1_aqc-T1w_part-mag_MPM.nii.gz
• Outputs for MPM processing should be in a derivatives folder.

See PR #38

• Comment from @KirstieJane on #38 (comment)
  • Linked PR: lazaral#1

Symlink - issue #8

• Need to add to the specification something about being able to symlink derivatives files to raw --- @KirstieJane
  • Specifically to allow outputs to be used with current BIDS-Apps.
  • In the future, hopefully the BIDS-Apps will be able to take inputs from the derivatives, so this linking is a band-aid to help qMRI researchers get into the BIDS-App ecosystem, not a long term plan 😄

• Current WIP #25 - this is just a bit of a mess because I have too many other files in this branch 😬
  • But if anyone can reveiw what I've written for the common principles section that would be great!

Add examples to specification

• Read through the draft specification looking for where examples can be added to make things clearer --- @tiborauer
  • Useful google doc from @agahkarakuzu: https://docs.google.com/document/d/1HfCjPKCXqTckB0OPs-Py06yY2gPYaFGc0sFTPB74fEA/edit?usp=sharing

Tidy up

• Tidy up the issues and fix a few "little" points --- @Gilles86

Looking forwards

What are the next steps we need to take?

Do we want to call data _MPM or _hmri?

Answer: MPM is an acquisition while hmri is a pipeline.

A group of people have done some great work on INCF and we talked about it during a BIDS meeting.

See here for the original document:
https://docs.google.com/document/d/1HfCjPKCXqTckB0OPs-Py06yY2gPYaFGc0sFTPB74fEA/edit#

I think there are some great suggestions, such as using the suffix _MPM for MPM acquisitions and the acq-field to indicate which acquisition is mostly weighted like what.

There are also some nice examples for VFA, MT, B1...

I think it would be good to include them in the current draft. Any opinions on this? Anyone wants to make a commit for this?

See also:
https://docs.google.com/spreadsheets/d/1awzGVflxXiWtzeLVOH5XI8Bar2ND9759yZxsK3stCzc/edit#gid=0

I think in the November call we decided that the suffixes of (ME-)MP2RAGEs should be _MP2RAGE, even though there are two inversion times and there could be more and this is implied by the number of inv-{}-tags.

The reason we came to this decision was that what people currently tag as _t1w in BIDS datasets are very often MPRAGES. MP2RAGES are in a way very different, because they have very different, 'white noise' contrast in regions of low/no signal. This should be very clearly marked for any anatomical processing pipelines.

However, it is currently not yet implemented in the maintext-branch.

We decided that b1 maps should also go in the 'fmap'-folder/modality. However, this is never explicitly stated in the extension text now. Any thoughts on how to do this?

From August call:

Suggestion from CP (for MPM & hMRI toolbox):

• Got a list of stuff to add and have provisionally inserted them in BEP001 document… may not be entirely related to MT scans.
• Here they are
• MixingTime (TM) in seconds.
• In a STEAM (Stimulated Echo Acquisition Mode) experiment, three consecutive RF pulses are applied to generate a simulated echo (STE). The mixing time is the time interval between the second and third pulses. [Ref: Frahm J, Merboldt KD, Hänicke W, Haase A. Stimulated echo imaging. J Magn Reson 1985;64:81-93]
• RFSpoilingPhaseIncrement.
• in RF-spoiled gradient echo sequences (e.g. FLASH), RFSpoilingPhaseIncrement (in degrees) is the increase in the phase difference between consecutive pulses. This parameter, together with the spoilingGradientMoment and the spoilingGradientDuration, is required to calculate imperfect spoiling correction coefficients (Preibisch & Deichmann 2009). If not available, no imperfect spoiling correction will be applied.
• spoilingGradientMoment.
• in gradient-spoiled gradient echo sequences (e.g. FLASH), spoilingGradientMoment is the zeroth moment (in T*s/m) of the spoiler gradient applied at the end of each repetition. This parameter, together with the RFSpoilingPhaseIncrement and the spoilingGradientDuration, is required to calculate imperfect spoiling correction coefficients (Preibisch & Deichmann 2009). If not available, no imperfect spoiling correction will be applied.
• spoilingGradientDuration:
• in gradient-spoiled gradient echo sequences (e.g. FLASH), spoilingGradientDuration is the duration (in s) of the spoiler gradient applied at the end of each repetition. For a trapezoidal gradient, the duration is defined as the ramp-up duration + flat-top duration. This parameter, together with the RFSpoilingPhaseIncrement and the spoilingGradientMoment, is required to calculate imperfect spoiling correction coefficients (Preibisch & Deichmann 2009). If not available, no imperfect spoiling correction will be applied.

Suggestion from AKar

• MT Pulse shape (eg. gaussian, gaussian-hann, fermi, etc)
• Duration of the MT pulse
• Bandwidth of the MT pulse
• Off-resonance frequency of the MT pulse
• Spoiler gradient moment between the MT pulse and the readout

I drafted a text for explaining _suffix in the proposed changes file. You can find it here.

I want to keep working on it more once ISMRM annual meeting is over. But I hope there is enough material to discuss if this is the right way to approach it.

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).
✅

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

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.

✅ 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?

☑️ 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?

✅ 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.

✅ 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.

✅ 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)

✅ 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.

☑️ 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".

✅ 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.

In August 2018 it was agreed that 'derived' quantitative maps should be exported to the /derivatives-folder, but if the user wants, it can always make a symlink to the sourcedata-folder. This is useful for example for T1-weighted images derived from two MP2RAGE volumes.

We'll need to acknowledge everyone who helps incorporate this extension into BIDS at some point. I'd very much like to keep track of people prospectively (from August 2018) so if you know of someone who has contributed to BEP001 please add their name to this issue.

⚠️Note⚠️ : This initial list has been created by @KirstieJane simply by reading through the comment boxes on the google doc. It is very likely to be missing key people. If your name is not here - or you see someone whose name should be please add it!

Note also that being on this list does not automatically mean you will be an author on any publications associated with BEP001. We aren't at the write up stage yet, and so we aren't having that conversation yet. Any contribution is good enough to be added to this list, authorship will likely require a minimum commitment or sustained contribution to the project.

• Tibor Auer
• Suyash Bhogawar
• Mathieu Boudreau
• Julien Cohen-Adad
• Gilles de Hollander
• Chris Gorgolewski
• Daniel Handwerker
• Michael Harms
• Agâh Karakuzu
• Ali Khan
• Ilana Leppert
• Tobias Leutritz
• Martijn Mulder
• Dylan Nielson
• Christophe Phillips
• Julien Sein
• Isla Staden
• Wietske van der Zwaag
• Kirstie Whitaker
• Tobias Wood

Hey,

I notice that there are some inconsistencies in the spec right now. So in general, people seem to use B1map and B1plusmap interchangeably. But for the MPM examples, we use B1minusmap. What should we do here? Replace everything with B1plusmap?

-Gilles

Call on 4 September 2019

• @agahkarakuzu apologises for not updating the inheritance principle as planned - he's going to keep working on #59 & tag in @KirstieJane for a review
• we made a few small fixes and merged a couple of PRs
• @lazaral is going to keep working on #38 including making sure that the inheritance principle isn't violated (ie: one json file per nifti file).

Next call: 18 September 2019

The next call is on 18 September at 8am PDT / 10am EDT / 3pm BST / 4pm CEST.

Here's a link to get your local time: https://arewemeetingyet.com/London/2019-09-18/15:00/BEP001%20dev%20call

We haven't been really explicit about the metadata fields that have to accompany certain qMRI acquisitions. That's our goal for the next call.

• @lazaral is going to work on getting the hMRI demo dataset into BIDS format (https://github.molgen.mpg.de/hMRI-group/Toolbox/wiki/HmriDemoDataset)
• @Gilles86 is going to bring MP2RAGE example data that can be made public
• @agahkarakuzu will bring anything he can
• @ChristophePhillips, if you're around, it would be great to have an update on your work updating the hMRI toolbox

Can we change the names of the example data sets to make it clear why they're there?

I think @lazaral had a markdown file describing them a little so maybe you can take this one on?

• Clearer names
• Useful information in the data set description json file
• Make sure the derivatives folders have correct pipeline names

We need to clarify in the specification the difference between using the _FLASH suffix and the _MEGRE suffix.

We're leaving _FLASH in the specification to maintain backwards compatibility but we recommend that it is superceded by the vender non-specific _MEGRE suffix (multi-echo gradient echo) suffix.

Note that _GRE is probably going to be used for a _T1w, _T2star or _PDw or one of the other suffices which is why we aren't adding it.

Let's collect some actual data that we can use as examples for the BEP001.

One candidate already is Chris G's 7T dataset:
https://openneuro.org/datasets/ds000113

Wietske van der Zwaag's 3D EPI MP2RAGEs:
https://www.sciencedirect.com/science/article/pii/S2352340918308825

I am most likely to also share some ME-MP2RAGE data.

I'm currently merging changes to the bids specification into our repository to keep us in sync with those changes.

The point of this issue is to note where there are conceptual merge conflicts (rather than just git not knowing which line information should be on!) so we can review and discuss them.

The Fieldmap data section needs reviewing for a way to combine the updates. Mostly gramatically as there aren't really any conceptual conflicts.

The final sentence of this section doesn't actually flow on to the four examples - recommend reading through and double checking the grammar etc.

Data acquired to correct for B0 inhomogeneities can come in different forms.
B0 (static magnetic field strength pattern), B1+ (transmit field pattern),
and B1- (receive field pattern; not yet supported) maps can be useful in
post-processing both raw functional and anatomical data.

B0 maps are primarily used to correct for spatial distortions in functional
data acquired with EPI sequences.

B1+ and B1- maps are mostly used in anatomical imaging, especially when
applying quantitative MRI (qMRI) techniques.

The current version of this standard considers four different scenarios. Please
note that in all cases fieldmap data can be linked to a specific scan(s) it was
acquired for by filling the IntendedFor field in the corresponding JSON file.

As mentioned in this reply to issue #67 , B1+ maps do have a specific suffix and there should be one for B1- maps too.

Still originally (and in the current BIDS release) the fmap was intended to host only B0 maps, therefore no suffix was proposed and the template looks like

sub-<label>/[ses-<label>/]
    fmap/
        sub-<label>[_ses-<label>][_acq-<label>][_run-<index>]_phasediff.nii[.gz]
        sub-<label>[_ses-<label>][_acq-<label>][_run-<index>]_phasediff.json
        sub-<label>[_ses-<label>][_acq-<label>][_run-<index>]_magnitude1.nii[.gz]
        sub-<label>[_ses-<label>][_acq-<label>][_run-<index>]_magnitude2.nii[.gz]

For the (Siemens) case of 1 phase difference and 2 magnitude images.

On the other hand the B1 maps will look like

sub-<participant_label>/[ses-<session_label>/]
    fmap/
        sub-<participant-label>[_ses-<session_label>][_acq-<acq-label>][_run-<run_index>]_B1plusmap.nii[.gz]
        sub-<participant-label>[_ses-<session_label>][_acq-<acq-label>][_run-<run_index>]_B1plusmap.json

Key question

With the addition of the B1+ and B1- fieldmaps in the fmap folder, wouldn't it make sense to give the B0 map a specific suffix, e.g. _B0map?

Option 1

The template could thus be updated like this

sub-<label>/[ses-<label>/]
    fmap/
        sub-<label>[_ses-<label>][_acq-<label>][_run-<index>]_part-phasediff_B0map.nii[.gz]
        sub-<label>[_ses-<label>][_acq-<label>][_run-<index>]_part-phasediff_B0map.json
        sub-<label>[_ses-<label>][_acq-<label>][_run-<index>]_part-magnitude1_B0map.nii[.gz]
        sub-<label>[_ses-<label>][_acq-<label>][_run-<index>]_part-magnitude2_B0map.nii[.gz]

In the common cases where only the B0 map are present, typically with fMRI studies, one could skip the _b0map suffix, i.e. use the original specs.
Drawback: this may break some back compatibility!

Option 2

Another possibility would be to put the B1+/B1- maps altogether in a different folder? For example B1map. This will ensure backward compatibility regarding the content of fmap and let the B1 maps live on their own.

This makes sense in a way since B1 maps are fundamentally different from the B0 maps, and with the avent of UHF MRI, pTX imaging, etc. B1 mapping may actually become more complex.

Opinion

I was originally in favour of putting B0 and B1 maps in the same fmap folder, in order to avoid the multiplicity of folders...
Now though, I am a bit uncomfortable with this because:

• if B0 map do not carry a specific suffix, that is not consistent with the B1 maps
• if we try to add a specific B0 map suffix, it will break back compatibility (to some extent)
• anatomical (MPM) and functional are commonly processed separately. With the B1 maps not (AFAIK) used for functional data, why carry them along (with a risk of confusion) if one is only interested in functional data.
  So I would be in favour of a separate folder for the B1 maps.

It would be good if we implement BEP001 in pybids before release, so people (e.g., me) can easily develop pipelines etc.

I made a first go here:
https://github.com/Gilles86/pybids/tree/BEP001

• Update on the big merges that @KirstieJane and @Gilles86 did this morning 😬 💪 🚀
• Look through issue list
  • Close those that are done
  • Assign those that are not!

The text should make clear that there are recommendations for standard suffixes for standard sequences (MP2RAGE, FLASH, T1w), but depending on context, one can change the suffix. This is to make sure the standard remains extensible.

Discussion in the google doc:

https://docs.google.com/document/d/1QwfHyBzOyFWOLO4u_kkojLpUhW0-4_M7Ubafu9Gf4Gg/edit?disco=AAAABql0bLg

Need to get MH to sign off on incorporating it but decision in July meeting was to add this new key.

The next BEP001 developer call will be on Tuesday 17 January at 6pm CET / 5pm GMT / 12noon EDT / 9am PST. Everyone's welcome!

Please comment below if you'd like to add anything to the agenda 😸

Update

Agenda being built at https://docs.google.com/document/d/1TIsdWEi1TimAftbgf0OJnPorHif6uqclpwx4cXcx2tw/edit?usp=sharing

Jumping in here without having been involved much... hope this is isn't annoyingly obvious/redundant...

In reviewing bep001's 04-modality-specific-files/01-magnetic-resonance-imaging-data.md I noticed there is

while in the current standard we have in 04-modality-specific-files/01-magnetic-resonance-imaging-data.md we currently have

Is the proposal to remove PD and replace it with PDw? While that is most logical, it represents a non-backwards compatible change; also, it suggests that current modality label PDT2 should also be revised to PDT2w (or PDwT2w?).

As this looks rather mature, seems sensible to think about how this will merge with the existing standard.

Wednesday 28 November works for @Gilles86 & @KirstieJane.

• Send out an email to the BIDS mailing list suggesting a few times: 4pm, 5pm, 6pm CET.
  Here's the doodle poll: https://doodle.com/poll/gz787nhx8srv83dg
  Close at end of day on Monday 12 Nov
• Confirm time to BIDS mailing list
• Send invite & zoom link

I'm currently merging changes to the bids specification into our repository to keep us in sync with those changes.

The point of this issue is to note where there are conceptual merge conflicts (rather than just git not knowing which line information should be on!) so we can review and discuss them.

Specifically, we need to review the section The acq entity in src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md which I've created in the sync-bids branch as a combo of the current bids specification and our proposed updates.

Hi @chrisfilo - please could you transfer this repository into the bids-standard organisation? Then we're all nicely lined up with the other repositories.

If you'd like to re-name it to bep001 that's totally fine with me (and I don't think @Gilles86 will be super mad...although I've tagged him now to double check!)

I think it would be good to enforce within BIDS that phase images are always constrained to (0, 2pi] radians (including 0, excluding 2 pi). This makes it easier to, e.g., fit qMRI models. What do you guys think?

Action for @ChristophePhillips to map the metadata that is required for the hmri toolbox into the BEP001 recommendations and to check whether we're all covered.

Regarding the examples, the current version contains a template
sub-<participant_label>[_ses-<session_label>][_<indexable_metadata>-<index>][_acq-<label>][_part-<mag/phase>][_ce-<label>][_rec-<label>][_run-<index>]_<suffix>.nii.gz,
so the MPM example should be:

• sub-01_echo-1_acq-MTon_part-mag_MPM.nii.gz
• sub-01_echo-1_acq-MToff_part-mag_MPM.nii.gz
• sub-01_echo-1_acq-T1w_part-mag_MPM.nii.gz
  (i.e. "acq" before "part")

As suggested by @ChristophePhillips in #75 (comment) we should submit an abstract to OHBM 2020.

@Gilles86 has said that he can make a shortened version of the doc - stay tuned here for a version of the ISMRM abstract. Update here it is! https://docs.google.com/document/d/1Zwg_dpwkk9YJzHU3wAV8jPvCZ9MUMCtgepee4ATx4hE/edit?usp=sharing

ACTIONS

• Please check the author list and comment here if anyone is missing who should be included
• Please have a read through of the abstract and add comments and suggestions....but if you want to add something please suggest somewhere to ✂️ cut ✂️ too because we're very close to the 4000 character word limit.
• All authors, please make an account at the OHBM abstract submission page: https://ww4.aievolution.com/hbm2001.
  • This might feel strange strange because it means clicking the "submit here" button at the bottom of this page. You aren't going to submit anything, you're just making it easier for @Gilles86 to submit next week!
• Please comment on this post whether you're planning to be at OHBM in person or not 👋

Please add the 🚀 reaction to this post when you've made your account and the ❤️ reaction when you're happy with the abstract!

Thank you @Gilles86 and @agahkarakuzu for writing it!!

We are meeting tomorrow at Thursday 28 February at 6pm CET / 5pm GMT / 12noon EDT / 9am PST. Everyone's welcome!

What should we discuss tomorrow?

First thing that comes to mind is the new version of the spec. @agahkarakuzu, did you have time to e.g., the new metadata fields?

I'm currently merging changes to the bids specification into our repository to keep us in sync with those changes.

The point of this issue is to note where there are conceptual merge conflicts (rather than just git not knowing which line information should be on!) so we can review and discuss them.

Specifically, we need to review the section The rec entity in src/04-modality-specific-files/01-magnetic-resonance-imaging-data.md which I've created in the sync-bids branch as a combo of the current bids specification and our proposed updates.

I think this section should be moved out of the rec- section to a new heading for mod- entity. What do you think?

If the structural images included in the dataset were defaced (to protect
identity of participants) one CAN provide the binary mask that was used to
remove facial features in the form of _defacemask files. In such cases the
OPTIONAL mod-<label> key/value pair corresponds to the modality (as stored in
the suffix) of the acquisition eg: T1w, inplaneT1, referenced by a
defacemask image. E.g., sub-01_mod-T1w_defacemask.nii.gz where T1w is the
scan suffix which becomes the value for the mod- entity.

To be discussed in August call.

I'm currently merging changes to the bids specification into our repository to keep us in sync with those changes.

The point of this issue is to note where there are conceptual merge conflicts (rather than just git not knowing which line information should be on!) so we can review and discuss them.

The paragraph below comes kinda out of nowhere in the main specification at the moment - it seems to be nested under the rec entitity but I don't think it is really related to that point. I think it probably needs its own heading. "Additional metadata"?? What's a good heading?

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

(Table not shown, but we have added two rows to it in BEP001)

Hi BEP001 folks!

@agahkarakuzu has written a really fantastic abstract to present BEP001 at ISMRM in 2020.

The link to the text is here: https://docs.google.com/document/d/1b-mbpHbVckd53jXfQR4mSZ_wBxqy_AdwTxkKP0HUKyg/edit?usp=sharing

We've put the following authors on the document - please add your affiliations and comment here if you're ok with being named on the abstract.

• @agahkarakuzu
• @Gilles86
• @sappelhoff (BIDS maintainer)
• @tiborauer
• @mathieuboudreau
• @franklin-feingold (BIDS maintainer)
• @akhanf
• @lazaral
• @ChristophePhillips
• @nstikov
• @KirstieJane

@effigies & @chrisgorgo - would you like to be in the list? We're not sure what you'd prefer and you're very welcome!

If you are not named and think you should be please let me know! @Gilles86 and I have a very strong inclusion policy! We're very sorry if we've forgotten you 😭

I think we're slightly over the word count at the moment but @Gilles86 and I figured there was no point in getting it absolutely perfect before you had the chance to comment 😆

Having said that....

The submission deadline is 6 November but the real deadline is this Sunday 3 November due to scheduling challenges next week. So please have a look through as quickly as possible - thank you so much 💖

The discussion is happening at: bids-standard/bids-specification#128

My (@KirstieJane's) view is that this is another "BIDS 2.0" challenge (aka "I wish I had a time machine"). It would make more sense to use part-mag or part-phase for the EPI data, but as _bold is already a very widely used suffix (as @chrisfilo says in his comment bids-standard/bids-specification#128 (review)) it would break backwards compatibility.

I commented (bids-standard/bids-specification#128 (comment)) that we'd try to get a BEP001 consensus comment back by the end of 24 Jan, so please have a think about this before our meeting on Thursday. Thank you! ✨

The section in the main specification that describes field maps is written for fMRI folks by fMRI folks 😉

This section needs some re-arranging so that it clearly describes a broader use of field maps.

We also need to be clear - through using a few examples - where the field maps need to go (derivatives or raw folders?)

• What processing is done to create these maps? What additional json metadata do we need to include?

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.

Our use case: We are doing period QA (data is available from http://datasets.datalad.org/?dir=/dbic/QA), and in the past had some scans with standard flip angles with no indication of flip angle in the file name. Now we (in particular @kodiweera) experimenting with different flip angles. If we resort to _fa-<index>, we could potentially have confusingly identical filenames across sessions when actual flip angle would be different. Moreover it is not immediately clear from the filename how any two files (e.g. _fa-1 and _fa-2) are different, and would require lookups into .json files, decreasing the usefulness from BIDS convention.

I wondered what was the rationale (besides may be inability/difficulty of reflecting floating point values? did you see any of those in over 10% (100-90% of the use cases? ;)) for storing indexes and not the actual values?

In our call we decided to remove the 2 in the suffix MESET2, since it is more consistent with the suffix _MEGRE and, for example, you might want to have both a PDw and a T2w image from this acquisition.

Originates from #71 but taken into a separate issue since largely orthogonal. I am quoting here #71 (comment) by @tiborauer :

Modality-specific suffixes answer why rather than what

examples?

2. Grouping suffix helps tools to identify images belonging to an/a compound acquisition

how often it would be necessary (i.e. % of the use-cases)? As I have argued in a comment I think grouping might be less frequently used, and custom suffixes would render those files not usable by standard analysis pipelines (e.g. fmriprep).

We need to make sure that the additional entities (key-value pairs) that we introduce in BEP001 are in the Appendix IV: Entity table in file 99-appendices/04-entity-table.md.

Next dev call: Wednesday 29 May at 4pm CEST / 3pm BST / 10am EDT / 7am PDT

All welcome, please see BIDS mailing list for zoom link (or ping @KirstieJane!)

Agenda

The following points are put in place by @KirstieJane after the call on 15 May....they might move around as we develop and discuss the extension 😸

Document merged changes: @KirstieJane & @agahkarakuzu

There are a few changes that are already merged to master but that aren't reflected in the ProposedChangesToSpecification.md file.

• indexable metadata merged in PR #37 but issue #26 open until the PCTS doc is updated
• there are a few changes merged in PR #30 but not captured in the PCTS doc
  • Discussion about why we have justified collecting different scans together under one suffix (eg: MP2RAGE and MPM) needs to be added....for example.

Update the examples: @lazaral, @tiborauer, @ChristophePhillips & @Gilles86

General driving principle is that for each new concept in the specification we have an example in the text (and maybe as a dataset?)

Empty files correctly named: @lazaral

Issues #34 & #46.

Real data in BIDS format: @tiborauer, @ChristophePhillips & @Gilles86

Issue #11.

List of metadata terms

Do the metadata terms that we have listed contain the information needed to run the processing pipelines? Are there any missing?

Run hmri toolbox on BIDS formatted data: @ChristophePhillips

Specifically, can we run the hmri toolbox on BEP001 formatted data? (And get out BEP001 formatted data!)

Field maps: @agahkarakuzu

Expand definition of field maps in specification. Issue #44.

Symbolic links: @KirstieJane

Need to add to the specification something about being able to symlink derivatives files to raw. See #25

• Specifically to allow outputs to be used with current BIDS-Apps.
• In the future, hopefully the BIDS-Apps will be able to take inputs from the derivatives, so this linking is a band-aid to help qMRI researchers get into the BIDS-App ecosystem, not a long term plan 😄

Timeline

It would be GREAT to get a PR open to the main specification before OHBM. Documenting what we have done (and why we have done it) is one of the big steps in getting there.... 💪 Keep up the hard work 🏋️ 🏋️‍♀️ 👾

We'll plan to meet in person at OHBM in the Open Science Room: ohbm/OpenScienceRoom2019#18

Discussed in the meeting: we need to move some of the suffixes in the table of the current spec (_FLAIR, _FLASH, PD...) to a "legacy" part of the table with instructions of what we reccomend to use instead.

Assigned to @Gilles86.

The ProposedChangesToSpecification.md file is the master document that lists the changes that we've made.... we need to capture somewhere what it is and how people can update it!

Hi folks! I can't remember if we set a time for the next call 🤦‍

The next Wednesday at 4pm (UK) that I'm available is November 13. Shall we do that?

Alternatively I could do Tuesday 5 November at 4pm (UK)?

Can you react to this issue with a 🚀 for 5 November and 👀 for 13 November? (You can respond twice) and I'll go with the majority ✨

Next dev call: Wednesday 15 May at 6pm CEST / 5pm BST / 12noon EDT / 9am PDT

All welcome, please see BIDS mailing list for zoom link (or ping @KirstieJane!)

Agenda

The following points are put in place by @KirstieJane after the March call....they might move around as we develop and discuss the extension 😸

Document merged changes

There are a few changes that are already merged to master but that aren't reflected in the ProposedChangesToSpecification.md file.

• indexable metadata merged in PR #37 but issue #26 open until the PCTS doc is updated
• there are a few changes merged in PR #30 but not captured in the PCTS doc
  • Discussion about why we have justified collecting different scans together under one suffix (eg: MP2RAGE and MPM) needs to be added....for example.

Update the examples

We have some nice example folder structures at the moment, but there are a couple more tasks that should be done. See #34 & #35, #46.

General driving principle is that for each new concept in the specification we have an example in the text (and maybe as a dataset?)

There's the open issue #11 which hasn't moved forwards in a while - lets see where that goes.

Field maps

We need to update the specification (and maybe some of the examples - the files might be in the wrong folders) to generalise the use of field maps. See #44

Symbolic links

Need to add to the specification something about being able to symlink derivatives files to raw. See #25

• Specifically to allow outputs to be used with current BIDS-Apps.
• In the future, hopefully the BIDS-Apps will be able to take inputs from the derivatives, so this linking is a band-aid to help qMRI researchers get into the BIDS-App ecosystem, not a long term plan 😄

Timeline

It would be GREAT to get a PR open to the main specification before OHBM. Documenting what we have done (and why we have done it) is one of the big steps in getting there.... 💪 Keep up the hard work 🏋️ 🏋️‍♀️ 👾

We'll plan to meet on Wednesday 29 May at 4pm CEST / 3pm BST / 10am EDT / 7am PDT and also in person at OHBM in the Open Science Room. Stay tuned 🚀