Multi echo anatomical MRI BIDS questions

ofgulban · October 19, 2020, 2:48pm

Hi,

I have conducted an “anatomical” MRI experiment for T2* mapping. I have acquired multiple “anatomical” multi echo gradient recalled echo (MEGRE) runs in the same session. An important detail was manipulating the phase encoding directions across each run. Upon referring to BIDS specification, I have ended up with the following filenames:

sub-01_ses-T2s_acq-MEGRE_dir-i_run-01_magnitude.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-i_run-01_phase.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-j_run-02_magnitude.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-j_run-02_phase.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-i-_run-03_magnitude.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-i-_run-03_phase.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-j-_run-04_magnitude.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-j-_run-04_phase.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-i_run-05_magnitude.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-i_run-05_phase.nii.gz
.
.
.

So my questions are:

Am I missing something in my file naming? I am somewhat irritated by the i- j- convention to indicate reversed polarity, because dash - means <keyword>-<value> combo in many other cases. This might cause issues in file name parsing.
As far as I understand, BIDS says that multi echo images “MUST” be split into separate files per echo. However, in my case, this would be equivalent to e.g. splitting each measurement of a functional MRI data into separate 3D nifti files. Because I am going to analyze the echoes as my time series signal. Therefore I was thinking about keeping all my echoes in one 4D nifti file. Am I right to think this? Or is there a benefit of splitting each echo into separate files even for the “anatomical” experiments? Or would this highlight a potential change in BIDS?

I know that there are initiatives for extending BIDS so maybe there are others who would link relevant discussions.

emdupre · October 19, 2020, 5:04pm

Hi @ofgulban !

I’d agree that looking at the BIDS extension proposals might be more informative, here. Specifically, I’d look at BEP001, which suggests the following convention for MEGRE:

sub-01_echo-1_MEGRE.nii.gz
sub-01_echo-1_MEGRE.json   (`EchoTime` = 0.0005)
sub-01_echo-2_MEGRE.nii.gz 
sub-01_echo-2_MEGRE.json   (`EchoTime` = 0.0015)
sub-01_echo-3_MEGRE.nii.gz
sub-01_echo-3_MEGRE.json   (`EchoTime` = 0.0025)

as detailed here.

re: your specific questions:

I’d agree that including a - in the value name is likely to cause an issue in field name parsing. In fact, it is explicitly disallowed in BIDS 1.0 (though it is currently a proposal for BIDS 2.0).
If you were to combine all your echos into a single file, then you would no longer be able to tie the appropriate meta-data to the acquisition, since – at a minimum-- the echo times themselves would vary across frames. So I’d encourage you to keep them separate, which BEP001 also does.

I’m also tagging in @tsalo and @Gilles_de_Hollander in case they have any more relevant information re: currently recommended handling of MEGRE.

ofgulban · October 19, 2020, 5:34pm

Thanks @emdupre , I think I would follow the example from here, right?

The phase magnitude part seems different and I think I will go for phase encoding directions as AP PA RL LR and so on instead of i i- j j-.

However I am not sure about putting MEGRE at the end. I thought acq keyword is used to indicate acquisiton types.

Would this be fitting or MEGRE needs to be at the end?:

sub-01_ses-T2s_acq-MEGRE_dir-AP_run-01_echo-1_part-mag.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-AP_run-01_echo-1_part-phase.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-AP_run-01_echo-2_part-mag.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-AP_run-01_echo-2_part-phase.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-AP_run-01_echo-3_part-mag.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-AP_run-01_echo-3_part-phase.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-AP_run-01_echo-4_part-mag.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-AP_run-01_echo-4_part-phase.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-RL_run-02_echo-1_part-magnitude.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-RL_run-02_echo-1_part-phase.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-RL_run-02_echo-2_part-magnitude.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-RL_run-02_echo-2_part-phase.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-RL_run-02_echo-3_part-magnitude.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-RL_run-02_echo-3_part-phase.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-RL_run-02_echo-4_part-magnitude.nii.gz
sub-01_ses-T2s_acq-MEGRE_dir-RL_run-02_echo-4_part-phase.nii.gz
.
.
.

Another question I have is that I am using bipolar readouts so the readout direction changes per echo. If I wanted to indicate this in the filenames, would there be different keywords for phase encoding direction and readout direction?

emdupre · October 19, 2020, 5:50pm

In the current BEP draft, MEGRE is a a new modality – much like bold or T1w – so it would go at the end of the file.

I’m less familiar with your question re: phase encoding and readout, so I’ll let someone else chime in there !

Gilles_de_Hollander · October 20, 2020, 6:04am

Hi Omer,

This looks like pretty cool data!
Do the phase-encoding and readout really matter here? Are you using EPI readouts?

Indeed, we had long discussion in the BEP-001 meetings about some of the issues you brought up. It turns out that if you want to accomodate many qMRI acquisition protocols, it is really better to group scans that " belong together" together with the same suffixes. Also, we believe it’s easier to have data with different parameters in different files.

I’m pretty sure that there is currently no key/value-pair for the readout direction. However, the acq--field is meant exactly for this kind of use case. Note that, according to the spec, dir- currently can only be used in _bold-data. So also the phase-encoding direction we will have to put in the acq--field.

Note that you do not have to use the i/i- and j/j- coding for the key-value pair in your filename. Only in the metadata. See BIDS spec:

The label value of the dir-<label> key/value pair can be set to arbitrary alphanumeric label ( [a-zA-Z0-9]+ for example LR or AP ) that can help users to distinguish between different files, but should not be used to infer any scanning parameters (such as phase encoding directions) of the corresponding sequence.

Then, your concrete questions:

Am I missing something in my file naming? I am somewhat irritated by the i- j- convention to indicate reversed polarity, because dash - means <keyword>-<value> combo in many other cases. This might cause issues in file name parsing.

See above, you can use AP or LR if you prefer. The i/i--pairs are for the metadata in the json (and indeed, the minus sign breaks BIDS filenames). However, unfortunately (?), the dir- key/value-pair right now is only meant for function data.

As far as I understand, BIDS says that multi echo images “MUST” be split into separate files per echo. However, in my case, this would be equivalent to e.g. splitting each measurement of a functional MRI data into separate 3D nifti files. Because I am going to analyze the echoes as my time series signal. Therefore I was thinking about keeping all my echoes in one 4D nifti file. Am I right to think this? Or is there a benefit of splitting each echo into separate files even for the “anatomical” experiments? Or would this highlight a potential change in BIDS?

We had endless discussions about this in BEP-001. We chose to split images up as much as possible when scan parameters are different. This really makes the logistics of storing and pulling out parameter values a lot easier for developers. When the data is well-organized, it should be easy to collect the echoes that belong together with, e.g., pybids, concatenate them, and fit a T2* curve.

So, I would organize your data as follows:

sub-01_ses-T2s_acq-readoutAPpeLR_part-mag_echo-1_MEGRE.nii.gz
sub-01_ses-T2s_acq-readoutAPpeLR_part-phase_echo-1_MEGRE.nii.gz
sub-01_ses-T2s_acq-readoutLRpeAP_part-mag_echo-1_MEGRE.nii.gz
sub-01_ses-T2s_acq-readoutLRpeAP_part-phase_echo-1_MEGRE.nii.gz
sub-01_ses-T2s_acq-readoutAPpeRL_part-mag_echo-1_MEGRE.nii.gz
sub-01_ses-T2s_acq-readoutAPpeRL_part-phase_echo-1_MEGRE.nii.gz
sub-01_ses-T2s_acq-readoutLRpePA_part-mag_echo-1_MEGRE.nii.gz
sub-01_ses-T2s_acq-readoutLRpePA_part-phase_echo-1_MEGRE.nii.gz
sub-01_ses-T2s_acq-readoutPApeLR_part-mag_echo-1_MEGRE.nii.gz
sub-01_ses-T2s_acq-readoutPApeLR_part-phase_echo-1_MEGRE.nii.gz
sub-01_ses-T2s_acq-readoutAPpeLR_part-mag_echo-2_MEGRE.nii.gz
sub-01_ses-T2s_acq-readoutAPpeLR_part-phase_echo-2_MEGRE.nii.gz

....

(Note that if parameters are different, there is no need for the run--keyword)

-Gilles

ofgulban · October 20, 2020, 12:23pm

Hi @Gilles_de_Hollander, thanks for your reply.

It clarified the usage of _suffix (the justification from here also helped) and acq- parts. And I also see that separating echoes is not a big issue as I can merge them back straightforwardly when processing.

However, I have some remaining comments & questions:

I am not using EPI readouts. Just plain old GRE, acquiring one line of a 3D k-space after each excitation pulse. Well actually acquiring the same k-space line multiple times after one excitation pulse as I am doing multi-echo (see item 2).
Phase encoding direction and readout direction (or frequency encoding direction) does really matter here (a brief explanation of why can be found here). Because phase encoding direction affects the flow artifact directions and bipolar readout means that the same k-space line transversed back and forth multiple times in opposite polarities which has an affect of the image artifacts too.
I need something like run- keyword or what series number refers to in dicom headers, because I am repeating this “anatomical” acquisition many times in a session. So that there are different MEGRE series of images with the same acquisition parameters acquired multiple times. Getting inspiration from dicom organization, I thought series- keyword might be required here. Would this be problematic?
I am somewhat confused about writing echo- after part- keyword as echoes have magnitude and phase and stand one step above as a concept. I thought I had to go from general to specific. Would changing echo- and part- orders be problematic?

So, upon referring to the BIDS common principles again, and considering your input, I am now thinking of something like this:

sub-01_ses-T2s_series-01_acq-pedAPfedLR_echo-1_part-magnitude_MEGRE.nii.gz
sub-01_ses-T2s_series-01_acq-pedAPfedLR_echo-1_part-phase_MEGRE.nii.gz
sub-01_ses-T2s_series-01_acq-pedAPfedRL_echo-2_part-magnitude_MEGRE.nii.gz
sub-01_ses-T2s_series-01_acq-pedAPfedRL_echo-2_part-phase_MEGRE.nii.gz
.
.
.
sub-01_ses-T2s_series-05_acq-pedAPfedLR_echo-1_part-magnitude_MEGRE.nii.gz
sub-01_ses-T2s_series-05_acq-pedAPfedLR_echo-1_part-phase_MEGRE.nii.gz
sub-01_ses-T2s_series-05_acq-pedAPfedRL_echo-2_part-magnitude_MEGRE.nii.gz
sub-01_ses-T2s_series-05_acq-pedAPfedRL_echo-2_part-phase_MEGRE.nii.gz
.
.
.

Comments and suggestions are much appreciated

tsalo · October 20, 2020, 2:42pm

@Gilles_de_Hollander’s points are quite correct, with one small correction:

The dir entity is actually supported for EPI field maps, all functional suffixes (including BOLD, phase, and cbv), and DWI data. Since MEGRE is not yet a supported suffix (i.e., BEP001 is still open), I think it would be reasonable to support dir as an optional entity for it, given that there’s a clear use-case. I’d be happy to feed that request back into the BEP001 pull request.

There is no series entity in the specification or in any of the current BIDS extension proposals (AFAIK). run is what you want. The key is just to make sure that run also reflects the collection of images that should be analyzed together. It sounds like you’ll be analyzing each run as a distinct set of images, so incrementing run makes sense.

The entities follow a specific order. That order may generally reflect a “general --> specific” structure, but that is not guaranteed. If anything, I’d say that newer entities tend to be placed after existing entities regardless of their level of specificity.

part is not currently supported in the specification, however. There is an open pull request (#424) which places part after echo. That pull request is fairly close to being merged, so I think it’s reasonable to follow it, but if you think that part should go before echo, then please feel free to comment on the PR so we can get community feedback before it’s merged.

agahkarakuzu · October 20, 2020, 4:55pm

I think it can be useful, looks like the current description of the dir entity pertains to a specific application. The more we run into such use cases, the more clear becomes the benefit of adding the common principle (parametrically linked scan collections) we’ve been talking about. We should ensure that descriptions should not imply 1:1 entity:application connection for the entities scoped by the parametrically linked scan collections.

I think the dataset would ideally become (ignore the order of entities, which will only become clear after the BEPs are merged):

sub-01_run-01_dir-☝️_part-mag_echo-1_MEGRE.nii.gz
sub-01_run-01_dir-☝️_part-phase_echo-1_MEGRE.nii.gz
sub-01_run-01_dir-👉_part-mag_echo-1_MEGRE.nii.gz
sub-01_run-01_dir-👉_part-phase_echo-1_MEGRE.nii.gz
sub-01_run-01_dir-👇_part-mag_echo-1_MEGRE.nii.gz
sub-01_run-01_dir-👇_part-phase_echo-1_MEGRE.nii.gz
.
.
. (iterates over echo 1-->N) 
------------------------------------------------- Same parameters repeat run ⬇️
sub-01_run-02_dir-☝️_part-mag_echo-1_MEGRE.nii.gz
sub-01_run-02_dir-☝️_part-phase_echo-1_MEGRE.nii.gz
.
.
.

If I understand @ofgulban correctly.

ofgulban · October 21, 2020, 8:28am

Dear @tsalo, thanks for the very clear comments! And @agahkarakuzu , thanks for the suggestions.

I understand your points and agree with both of you that I can use run- & dir- for my needs. Also the positioning of echo- and part- is not something that I have a strong preference on. So I would rather follow the expert advice here.

I think this settles it. I will proceed with the following just adding one change in in the naming of runs. The processing pipeline I have will mix and match signals from each acquisition to homogenize the phase encoding and readout directions. Therefore I think I will iterate the run numbers:

sub-01_run-01_dir-AP_part-mag_echo-1_MEGRE.nii.gz
sub-01_run-01_dir-AP_part-phase_echo-1_MEGRE.nii.gz
.
.
. (iterates over echo 1-->N) 
sub-01_run-02_dir-RL_part-mag_echo-1_MEGRE.nii.gz
sub-01_run-02_dir-RL_part-phase_echo-1_MEGRE.nii.gz
.
.
. (iterates over echo 1-->N)
sub-01_run-03_dir-AP_part-mag_echo-1_MEGRE.nii.gz
sub-01_run-03_dir-AP_part-phase_echo-1_MEGRE.nii.gz
.
.
.

Let me know if there is a remaining issue. I really appreciate you spending time to help with this

tsalo · October 21, 2020, 3:06pm

Since the part PR is close to being merged and it places part after echo, I would just switch the order of part and echo. Other than that, it looks good to me.

agahkarakuzu · October 21, 2020, 5:34pm

Cool, happy to see this resolved @tsalo I am planning to start the surge of BEP001 PRs with the common principle addition. This use case calls for updating the description of dir entity.

I am happy to generalize the description and add @ofgulban’s and the existing applications to the appendix. What do you think?

tsalo · October 21, 2020, 6:02pm

That sounds great.

I was actually confused about that. The current definition of dir (as of 1.4.1) is sufficiently broad, isn’t it? Here it is:

The dir-<label> key/value can be used to distinguish different phase-encoding directions.

I think that can be used with almost any MRI scan (although I’m obviously not a physicist, so there could be exceptions I’m not thinking of).

agahkarakuzu · October 21, 2020, 6:10pm

@tsalo you are right, definition in 1.4.1 is lean, my bad.

The only remaining addition has to do with the appendix in this case

ofgulban · October 21, 2020, 6:55pm

If you need some input from my side, let me know. Happy to return the favor

As a future reference, just typing the file naming based on the current consensus to later accept it as the solution:

sub-01_run-01_dir-AP_echo-1_part-mag_MEGRE.nii.gz
sub-01_run-01_dir-AP_echo-1_part-phase_MEGRE.nii.gz
.
.
. (iterates over echo 1-->N) 
sub-01_run-02_dir-RL_echo-1_part-mag_MEGRE.nii.gz
sub-01_run-02_dir-RL_echo-1_part-phase_MEGRE.nii.gz
.
.
. (iterates over echo 1-->N)
sub-01_run-03_dir-AP_echo-1_part-mag_MEGRE.nii.gz
sub-01_run-03_dir-AP_echo-1_part-phase_MEGRE.nii.gz
.
.
.

Thanks again @emdupre @Gilles_de_Hollander @tsalo @agahkarakuzu !

ofgulban · February 3, 2022, 3:58pm

[Update] This work is now available as a preprint and the data is shared.

I have included an acknowledgement for @emdupre @Gilles_de_Hollander @tsalo @agahkarakuzu on our OSF homepage, let me if you are not fine with this . I will include this statement in the next iteration of the manuscript, sorry that I forgot about it first time.

agahkarakuzu · February 3, 2022, 4:37pm

Thanks for the update and congrats on the preprint!