Fieldmap, B0 vs. B1(+/-)

[ChristophePhillips]

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.

[Gilles86]

Note that the current BIDS format actually does allow for "real", quantitative B0 maps as well, with the suffix _fieldmap 🤦‍♂.

I think making a new subfolder in source data of subjects is the kind of thing that the BIDS community will make a big deal out of and I think it is therefore better to stay with the fmap-folder.

[tiborauer]

I really like Option 1, but it never gonna happen. Proposal for BIDS 2.0, perhaps. For now, we have to simply accept that B0 maps are not grouped.

[ChristophePhillips]

I should have added Option 3, where we keep the same folder structure and the same naming convention for the B0 maps. This one is clearly the easiest to adopt. And I am well aware of the difficulties of changing standards...

[agahkarakuzu]

I agree with @tiborauer and @Gilles86 , a separate folder would open just another can of worms. Option-1 is really beautiful, but given its wide user base and the retrocompatibility issues, it would certainly receive considerable push back.

I hope that Option-1 will prove itself as a more sensible option to the community in the longer run, once BEP001 manages to make the concept of grouping suffixes less alienated 🤞.

Crying for the 🌔: I'd also be in favor of using an alternative suffix name for the set of images in Option-1 which can imply that these images are actually B0inputs, not B0maps.

[ChristophePhillips]

One further comment on the convention adopted to name the B1+/B1- maps. The current suffix, only for B1+ maps, is _B1plusmap which would naturally extend to _B1minusmap. What do you think then of dropping the map from the suffix ?

Reasons to do so:

• these are stored in the fmap folder, so they're necessarily some kind of map
• keeps filename not too long, _B1minusmap counts 11 chars!
• increasing readability, _B1plus/_B1minus are easier to decipher than _B1plusmap/_B1minusmap

[satra]

in option 1, i would not add B0map in the same vein as B1plus/minus. as @agahkarakuzu points out, one is a set of things (phase/magnitude, pepolar, etc.,.) to derive a B0map, the other is the map itself.

currently the suffix fieldmap corresponds effectively to such a B0 map. changing this suffix to B0 would be reasonable, but would likely be a breaking change. it would be worthwhile to create a separate issue for this in the main repo, so people are aware of these upcoming new suffixes, and can consider the potential breaking change. i would be +1 for increased clarity of B0 moving forward.

[JosePMarques]

I am sorry I missed the call yesterday. I would like to make the following suggestion to the B1 plus and B1minus maps... not sure if this is the right place.

To avoid back compatibility issues and the fact that the fieldmaps folder was specifically created for the B0 maps, and inside that folder in the file name convention there is nothing specifying that it is a B0 maps, I would leave the folder as it is. Also, the fieldmaps for different acquisitions can vary quite significantly depending on the volume coverage of your EPI measurement, or even B0 scanner drifts.

So my suggestion is to actually create a new folder named "calib" where all B1 plus and B1 minus scans could be stored (maybe also the localizer). This is also effectively happens on the siemens platform when you are using "prescan normalize". There is one measurement done at the start of the session, even before the localizer is measured, and this is used for all the scans performed during that session.

[tiborauer]

What you described for the fieldmap is also true for the anat folder: It was specifically created for T1w (and perhaps T2w) images to provide anatomical information for fMRI (and perhaps VBM, SBM) analyses. Now it will also host qMRI acquisitions, which can vary even more than fieldmaps.

Adding a new folder would be quite substantial change, and I think making the definition of suffix fieldmap (i.e. it refers to B0 maps) less ambiguous adds enough clarity and is less 'invasive'.

[dafrose]

Me currently setting up my many-subject MPM pipeline: +1 for option 3 as in

@tiborauer : making the definition of suffix fieldmap (i.e. it refers to B0 maps) less ambiguous adds enough clarity and is less 'invasive'.

and +1 for dropping the map in the suffix

[ChristophePhillips]

Hi @dafrose , Have a look at the BEP001 OSF repo for an example of MPM data. The MPM2 folder contains the example data from the hMRI toolbox, arranged "à la BIDS". Work is not finished yet and things could still evolve a bit but it gives you a fair idea of what is expected. :-)

[dafrose]

thanks a lot. That is very helpful.