Naming convention for multiple acquisition parameters

,
1

Hello -

I have a dataset where we are examining multiple acquisition parameters during the same task, for example multi echo, multiple mulitband acceleration factors, multiple in slice acceleration, and different TRs.

The data have already been collected and I’m working on a heuristic file to convert to BIDS format. Given that we have so many acquisition parameters, I’m wondering what is the best course of action for file naming. It would be nice for users to know the differences between each file from looking at the filename, though this is difficult with only the -acq key. So far the best option I’ve found is to create a unique string value, which I can explain in the README.

For example, acq-mb2ipat2phase_echo-01_sbref could denote echo one of the phase info (phase) of the reference volume (sbref) for the scan with a muliband acceleration factor of 2 (mb2) and an in slice acceleration iPAT=2 (ipat2), which would have accompanying magnitude data in acq-mb2ipat2mag_echo-01_sbref.

Another example, acq-mb2pf68phase_echo-03_bold could denote the third echo of the phase info for the scan with a multiband acceleration factor of 2 and a partial fourier = 6/8 (pf68).

I have yet to incorporate the TR in the naming, but that is less important, I think.

I am wondering if anyone has a cleaner way to do this? It would be great to be able to include multiple (perhaps custom) key/value pairs for a variety of acquisition parameters, which could then be easily parsed. Some of this information lives in the JSONs, so it might not be essential to the filename (eg multiband acceleration factor, TR, mag/phase). Though it doesn’t look like dcm2niix put all of the relevant parameters (eg inslice acceleration) in the sidecar (we used dcm2niix on a few files to see how they’d look).

Thanks!

3

Hi @dmoracze

Thank you for your question! I have seen others using the approach of putting it into the acq key with the unique strings you mentioned. Having this detailed in the readme I think helps too. With these being functional scans - the TR is required in the json sidecar. I agree that being able to distinguish easily the different files is important (a goal of BIDS). I think this is a reasonable approach! Each file will be human-readable (after taking in the information from the readme). I would suggest once you have a subject that has been converted to test against our validator for confirmation.

Thank you,
Franklin

4

In general, the less metadata you have to insert in the naming the better. The TR must be in the JSON sidecar as @franklin mentioned. Therefore, if you don’t have two acquisitions completely equivalent except for the TR, then, in principle, it should not be in the name.

5

Thanks for your input!