Chimap naming doesn't seem to be BIDS-valid?

[andrew-yian-sun]

Hi all,

I was using the online BIDS validator on my dataset and was told that my Chimap naming was incorrect somehow, but I can't figure out why.

Here's the full error log file. Please let me know what the issue is!
https://drive.google.com/file/d/1h_DCRyk25FKbz1ZhKDdojpB2thqRZwaF/view?usp=sharing

Thanks,
Andrew

[tsalo]

Based on the MRI Entity Table, Chimap files may have sub, ses, acq, ce, rec, and run entities, but no echo. My understanding is that Chimap is a quantitative map, so there shouldn't be any entities that would be used to estimate quantitative values in a map like that, such as echo, part, flip, inv, or mt.

Can I ask why you have echo in the filename?

[andrew-yian-sun]

@tsalo Thanks for the quick reply and the catch!

I used HeuDiConv but didn't specify echo in the heuristic.py file:
chimap = create_key('sub-{subject}/{session}/fmap/sub-{subject}_{session}_run-{item:03d}_Chimap')

It looks to be an automatic insertion based on the fact that the QSM files for a single QSM run were split into several folders?

This may be a question for the HeuDiConv people then, as I'm not sure how to not get that echo in there.

[effigies]

It sounds like you have the files for calculating the Chimap, not the Chimap itself. Perhaps there's a more appropriate suffix? Maybe MEGRE?

[tsalo]

+1 to @effigies' point.

One minor note, though. In BEP004 (SWI), they use a GRE suffix for the input files. GRE is not a supported suffix in BIDS, so your data wouldn't be BIDS-compliant and you'd need to ignore those files in your .bidsignore. However, if your protocol is designed for QSM, I imagine there's a good chance you have data from individual coils reconstructed as well, along with the phase and magnitude data. Is that correct? If so, then you won't be able to make those files BIDS compliant, since we don't have a coil entity supported yet. Your best shot, in that case, might be to just use the SWI BEP's suffix and entities.

[andrew-yian-sun]

Thanks everyone! We don't have data from the individual coils reconstructed, but the files in GRE_QSM correspond to magnitude images (GRE_QSM_23s) and phase maps (GRE_QSM_24s), and that sub-numbers indeed correspond to the echos.

So my understanding is that we would do something like sub-0061_part-mag_echo-1_GRE.nii.gz for consistency, but that it would still have to be added to .bidsignore?

[effigies]

The templates (defined here) are going to be:

            sub-<label>[_ses-<label>][_acq-<label>][_ce-<label>][_rec-<label>][_run-<index>]_echo-<index>[_part-<label>]_MEGRE.json
            sub-<label>[_ses-<label>][_acq-<label>][_ce-<label>][_rec-<label>][_run-<index>]_echo-<index>[_part-<label>]_MEGRE.nii[.gz]

So: sub-0061_echo-1_part-mag_MEGRE.nii.gz

Note that the order of entities is mandatory; echo comes before part.

And you should not need a .bidsignore.

[andrew-yian-sun]

It seems like HeuDiConv is automatically placing echo right before _MEGRE, such that I cannot get the order to be correct:

Here is the relevant line in my heuristic file: megre_mag = create_key('sub-{subject}/{session}/anat/sub-{subject}_{session}_part-mag_MEGRE') (If I add echo, it results in 2 instances of it)

And it results in something like: 'sub-0061/ses-1/anat/sub-0061_ses-1_part-mag_echo-1_MEGRE.json', making it BIDS-invalid. I will forward this issue to nipy/heudiconv.

[effigies]

Do you also have phase images? If not, you can just drop part-mag.

[andrew-yian-sun]

Yes I do :(

[tsalo]

It looks like you followed up in heudiconv in nipy/heudiconv#541. Given that you're going to use the MEGRE suffix, which allows the part and echo entities, can I close this?

[andrew-yian-sun]

Yes, thank you!