Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional key/value pairs for B1+/B1- images? #3

Open
ChristophePhillips opened this issue Sep 23, 2019 · 0 comments
Open

Additional key/value pairs for B1+/B1- images? #3

ChristophePhillips opened this issue Sep 23, 2019 · 0 comments
Assignees

Comments

@ChristophePhillips
Copy link
Member

So far the only 2 key/value pairs available for the B1+ maps in the fmap folder are _acq-<acq-label> and _run-<run_index>. This does not seem sufficient for the characterization of the B1+/- maps for the hMRI toolbox example dataset.

Using these example data,

  • B1+ maps are acquired for a series of 11 flip angles and 2 acquisition types (SE/STE). It would therefore be useful to use indexable metadata _fa-<index>.
  • B1- maps are acquired separately for the 3 anatomical images types (MTw, PDw and T1w) and the 2 coils (head and body), i.e. 3x2 images, each corresponding to a different acquisition type. Both information must appear in the filename otherwise 2 or 3 files would end up with the filename. Could the _mod-<mod-label> key/value pair be used for the 3 image types (MTw, PDw and T1w)?

Potential issues though:
Currently the _mod-<mod-label> key/value pair is only used for the case of a _defacemask.nii mask image, in order to associate this mask with the corresponding modality image, see here.
Plus, with MPM data, the suffix of the anatomical images is actually _MPM, and the image type defined in the _acq-<acq-label> key/value pair! So the _mod-<mod-label> may not be ideal...

@ChristophePhillips ChristophePhillips self-assigned this Apr 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant