Adding extra "key-values" pairs in the bidsmap

Remi-Gau commented 4 years ago

Working on trying to use bidsme for MP2RAGE data and trying to follow the BEP001 :

https://bep001.readthedocs.io/en/master/04-modality-specific-files/01-magnetic-resonance-imaging-data.html#anatomy-imaging-data.

The BEP plans to have this as the template for the names for anat data:

sub-<label>[_ses-<label>][_acq-<label>][_part-<label>][_echo-<index>][_fa-<index>][_inv-<index>][_mt-<on/off>][_ce-<label>][_rec-<label>][_run-<index>]_<suffix>.nii[.gz]

Currently, BIDSME seems to support the part key but not some of the other ones e.g inv.

I think it would be good to add those fields or at least have a way to make it possible for users to add them somehow (even if not yet supported by BIDS official).

nbeliy commented 4 years ago

The bids key are completely dynamic, so in the bidsmap you can specify them as you wish in the json section:

    json: !!omap
       - acq: ~
       - part: ~
       - echo: <EchoNumber>
       - fa: ~
       - inv: ~
       - mt: on
       - ce: ~
       - rec: ~
       - run: ~

This will raise warnings at map creation (inciting extra attention), but they disappears when you validate the entry (set checked to true).

Unfortunately the philosophy of bids community deviates from my vision (which I used when designing the core code). In my vision any modality (in therm of bids, i.e. the modality folder) must have same fixed set of entities. If in extension a new set is needed, then a new modality should be introduced, except such entity is useful for base modality (anat, in example given). It make it much more consistent and easy to treat numerically.

However bids community seems to follow more contextual approach -- modality folder defines type of acquisition, and the interpretation of acquisition depends of overall dataset structure. This is better in they of organisation, the number of folders do not explode, but makes the templates difficult of create -- you have a set of keys for anat, but if protocol is MP2RAGE then the set is different.

Remi-Gau commented 4 years ago

OK I checked and this bidsmap worked:

        bids: !!omap
          - acq: hires
          - part: mag
          - inv: '1'
          - ce: ~
          - rec: ~
          - run: ~
          - mod: ~

But this crashes:

        bids: !!omap
          - acq: hires
          - part: mag
          - inv: 1
          - ce: ~
          - rec: ~
          - run: ~
          - mod: ~

mapper(56) - INFO Processing: sub 'sub-pilot001', ses 'ses-001', 015-mp2rage_siemens_ipat3_0.69mm_AAbasis_INV1/0 (1 files)
bidsme(148) - ERROR /home/remi/github/bidsme/bidsme/bidsme.py(135) in <module>: 
bidsme(148) - ERROR /home/remi/github/bidsme/bidsme/mapper.py(334) in mapper: 
bidsme(148) - ERROR /home/remi/github/bidsme/bidsme/mapper.py(66) in createmap: 
bidsme(148) - ERROR /home/remi/github/bidsme/bidsme/bidsmap/_bidsmap.py(193) in match_run: 
bidsme(148) - ERROR /home/remi/github/bidsme/bidsme/Modules/base.py(1112) in getBidsname: 
bidsme(148) - ERROR /home/remi/github/bidsme/bidsme/tools/tools.py(74) in cleanup_value: 
bidsme(149) - ERROR 1:AttributeError: 'int' object has no attribute 'strip'

This looks similar to the issue #2 so I will check if the fix you created tackles that problem too.

Though in general it would be good to have a couple of tips for users to know if certain things have to be strings or not.

Remi-Gau commented 4 years ago

Yup that "bug" is fixed. :-)

But I think we could mention some the content of that message in the doc.

nbeliy / bidsme

Adding extra "key-values" pairs in the bidsmap #6