Susceptibility weighted images

[Najmahan]

Your idea

Hello,

We are in the process of creating a large open dataset (https://open-mpn.biobank.mcgill.ca), which includes susceptibility weighted imaging and we realise that the suffix SWI is not a valid option. We would like to introduce this to BIDS to avoid using the suffix t2starw as this is a distinct contrast from t2starw images that are created by echo-combination of the magnitude images reconstructed by ASPIRE.

Also, it would be useful to have a contrast called "mask".

acq-megre07_rec-ASPIRE_desc-EchoCombinedSensCorr_T2starw
acq-megre07_rec-ASPIRE_desc-EchoCombined_T2starw
acq-megre07_rec-ASPIRE_echo-1_part-mag_MEGRE
acq-megre07_rec-ASPIRE_echo-1_part-phase_MEGRE
acq-megre07_rec-ASPIRE_echo-2_part-mag_MEGRE
acq-megre07_rec-ASPIRE_echo-2_part-phase_MEGRE
acq-megre07_rec-ASPIRE_echo-3_part-mag_MEGRE
acq-megre07_rec-ASPIRE_echo-3_part-phase_MEGRE
acq-megre07_rec-ASPIRE_echo-4_part-mag_MEGRE
acq-megre07_rec-ASPIRE_echo-4_part-phase_MEGRE
acq-megre07_rec-ASPIRE_echo-5_part-mag_MEGRE
acq-megre07_rec-ASPIRE_echo-5_part-phase_MEGRE
acq-megre07_rec-ASPIRE_T2starmap
acq-megre07_rec-ROMEO_echo-1_MEGRE
acq-megre07_rec-ROMEO_echo-2_MEGRE
acq-megre07_rec-ROMEO_echo-3_MEGRE
acq-megre07_rec-ROMEO_echo-4_MEGRE
acq-megre07_rec-ROMEO_echo-5_MEGRE
acq-megre07_rec-ROMEO_desc_unwrapped_t2starw
***acq-megre07_rec-ROMEO_desc-mask_T2starw
***acq-megre07_rec-CLEARSWI_SWI

[tsalo]

I think it makes sense to add an SWI suffix.

There is an SWI BIDS Extension Proposal for SWI (BEP 005), although it no longer has a BEP lead and may be out of date. I believe most elements from that BEP have since been added to BIDS, except for an SWI suffix.

I have a few questions:

1. You include a number of files with the derivatives-only desc entity. Are you describing derivative data or raw data coming from the scanner?
2. What do you mean by "mask" contrast? What is in the desc-mask_T2starw file?
3. What is in the rec-ROMEO_desc-unwrapped_T2starw file? T2* is typically estimated from magnitude or complex-valued data, so I don't understand this file. Is it T2* estimated from just the unwrapped phase data somehow?
4. Similarly, what is in rec-ROMEO_echo-<index>_MEGRE? If those are unwrapped phase images, then rec-ROMEO_part-phase_desc-unwrapped_MEGRE would be more fitting (and, because it includes desc, would only go in a derivative dataset).

[Najmahan]

Hi Taylor,
Please see below:

There is an SWI BIDS Extension Proposal for SWI (BEP 005), although it no longer has a BEP lead and may be out of date. I believe most elements from that BEP have since been added to BIDS, except for an SWI suffix.

Thank you. I have left my comments on that document.

I have a few questions:

1. You include a number of files with the derivatives-only desc entity. Are you describing derivative data or raw data coming from the scanner?

**_This is a great question. Technically, the "raw" data for our sequence (multi-echo GRE) is part-mag (x5) and part-phase. However, our scanner does output reconstructed mag images (using ASPIRE algorithm to combine mag files) and phase images (using ROMEO algorithm to unwrap phase). This is why we propose the rec to specify ASPIRE and ROMEO; and "desc" to specify additional (on-scanner) procedures such as sensitivity correction.

We propose to put things in the "derivative" folder ONLY if ASPIRE, ROMEO or corrections are run on the nifti images. Otherwise, as long as the scanner produced DICOMs for those, we add precision by desc- but keep them in the anat folder. This improves querying on LORIS for us as well.**

3. What do you mean by "mask" contrast? What is in the desc-mask_T2starw file?

_Right now, that is the mask. However, according to BIDS, the last element need to specify the contrast. The mask is a binary file created from phase unwrapped images and is not t2 contrast BUT because mask is not a valid contrast in BIDS, we have put T2starw._*

5. What is in the rec-ROMEO_desc-unwrapped_T2starw file? T2* is typically estimated from magnitude or complex-valued data, so I don't understand this file. Is it T2* estimated from just the unwrapped phase data somehow?

Correct. We propose to specify ROMEO in the filename as it is the phase combination algorithm tha is run before generating the DICOM files. Do you think it is important to add part-phase to this name too?

7. Similarly, what is in rec-ROMEO_echo-<index>_MEGRE? If those are unwrapped phase images, then rec-ROMEO_part-phase_desc-unwrapped_MEGRE would be more fitting (and, because it includes desc, would only go in a derivative dataset).

This is a multi-echo sequence and we output both part-man and part-phase for each of the 5 echos in the sequence.

[tsalo]

Thank you. I don't want to derail the issue from the SWI suffix request too much, but here are some notes:

1. mask is a valid suffix for derivatives (https://bids-specification.readthedocs.io/en/stable/derivatives/imaging.html#masks), so desc-mask_T2starw --> desc-T2starw_mask (or some other desc value if you prefer, like "brain").
2. In the absence of a part entity, the image is assumed to be magnitude, so you should include part-phase things like the unwrapped phase images.
3. I haven't heard of calculating a T2*-weighted image from phase data only, but including part-phase in <source_entities>_rec-ROMEO_desc-unwrapped_T2starw.nii.gz is probably the way to go.
4. desc is not valid for raw BIDS datasets, so you'll need to either add any affected files to your bidsignore, move them into the derivative dataset, or use another entity to distinguish them (e.g., rec or acq).

In terms of the SWI suffix, I think it would be fine to open a PR adding it to the spec so others can review.

[Najmahan]

Thanks for the feedback.

1. Indeed, mask seems to be an entity; thank you!
2. We will do that.
3. It is correct. and indeed ROMEO does not produce a T2starw but we assumed to be forced to include it in order to comply with having a contrast as the last entity. In other cases we put MEGRE at the end.
4. Noted. We may opt for adding it to bids ignore. We may also just get rid of it. My challenge is that I don't know a BIDS-interested ASPIRE/ROMEO using community to confer with :)

In terms of SWI, in the document you shared with me, someone has proposed adding this as a directory and a coupe of people (JB and Chris) have accepted the idea; but I am not sure if there is any branch for SWI or QSM additions?

[tsalo]

I think the swi folder was from before BEP001 (which added many quantitative MRI scans and derivatives). I would put it in anat, which is where QSM derivatives go as well.

[fabriciocravo]

@Najmahan @tsalo - A small correction - BEP004 is the one handling SWI imaging. Since it has no BEP lead, and I am currently overseeing no BEPs, I propose that I lead this one.
Also, PR#2343 adds both SWI and minIP as potential suffixes for BIDS, but the PR was never merged because of the following ongoing main discussions:

Q1: Is minIP raw or derivative?
Q2: Should minIP be a suffix (_minIP) or an entity/statistic (stat-minIP_swi)?
Q3: Is minIP SWI-specific, or usable in other contexts?

Those issues are related to the SWI extension, but, from my view, they do not block adding SWI as a suffix. We could separate the PR to handle SWI, as this does not generate controversy and it appears there is an agreement that it should be added as a suffix. This could also break the BEP to focus only on SWI, then move towards solving the minIP issues.

Finally, my small research indicates:
Q1 - Some scanners generate minIP directly from the output with minimal preprocessing, but I think we need expert opinion to settle this one. I lean towards raw.
Q2 - The answer is likely no. As minIP is a projection algorithm, it can come from other images other than swi. So making it an entity or statistic would force us to add minIP to every other neuroimaging type compatible with the projection (scaling issue), while the same would not happen with a dedicated suffix.
Q3 - minIP appears to be used in other contexts.

[Najmahan]

Hi @fabriciocravo , thank you for joining the discussion.

I don't believe our sequences (MEGRE) compute SWI base on minIP--we have ASPIRE, ROMEO and CLEAR SWI for combining magnitude, phase and computing SWI, respectively.

I propose the following strategy:

acq_{type of sequence}_part-{mag/phase}rec{algorithm for reconstruction such as ROMEO or ASPIRE CLEARSWI}{SWI, T2starW, mask, T2starmap}.

Thoughts?

[Najmahan]

@fabriciocravo So how about separating the SWI from minIP issue?

[Najmahan]

@fabriciocravo I have done some investigations and have some thoughts:

@Najmahan @tsalo - A small correction - BEP004 is the one handling SWI imaging. Since it has no BEP lead, and I am currently overseeing no BEPs, I propose that I lead this one. Also, PR#2343 adds both SWI and minIP as potential suffixes for BIDS, but the PR was never merged because of the following ongoing main discussions:

Q1: Is minIP raw or derivative?
I think minIP or CLEARSWI could be considered as reconstruction methods. I would put these data in the raw folder.

Q2: Should minIP be a suffix (_minIP) or an entity/statistic (stat-minIP_swi)?
rec_minIP_SWI

Q3: Is minIP SWI-specific, or usable in other contexts?

It's used in Angio as well.

Those issues are related to the SWI extension, but, from my view, they do not block adding SWI as a suffix. We could separate the PR to handle SWI, as this does not generate controversy and it appears there is an agreement that it should be added as a suffix. This could also break the BEP to focus only on SWI, then move towards solving the minIP issues.

Yes, let's do that!

Finally, my small research indicates:
Q1 - Some scanners generate minIP directly from the output with minimal preprocessing, but I think we need expert opinion to settle this one. I lean towards raw.

I agree. I think if the internal reconstruction algorithms generate the DICOM files on the scanner, the data should be in the raw folder, and precision added by _rec-

Q2 - The answer is likely no. As minIP is a projection algorithm, it can come from other images other than swi. So making it an entity or statistic would force us to add minIP to every other neuroimaging type compatible with the projection (scaling issue), while the same would not happen with a dedicated suffix.

For Angio, where we have this as an internal reconstruction method, we do something like "acq-TOF_rec_mipCor_angio"

Q3 - minIP appears to be used in other contexts.
Correct.

[fabriciocravo]

Hi @Najmahan

Understood. I will separate BEP004 issues to push for the swi suffix before resolving the minIP discussion. I will also open the PR adding the swi suffix to BIDS. Since this was already discussed previously, it should move faster. I am trying to get in contact with the maintainers who were part of that discussion to move things forward. So swi will likely be an allowed suffix. It will take some time to update the validator, but I think it would be fine to name it like this until the PR gets approved.

On your proposed naming convention:
acq_{type of sequence}_part-{mag/phase}_rec{algorithm for reconstruction such as ROMEO or ASPIRE CLEARSWI}{SWI, T2starW, mask, T2starmap}.

rec - normally comes before part - as stated in your examples:
acq-megre07_rec-ASPIRE_desc-EchoCombinedSensCorr_T2starw

On the _part-{mag/phase} - from my understanding, SWI combines magnitude and phase to generate a new image. Would you mind clarifying the purpose of part here? I am assuming this is only for the raw MRI images and not the SWI.

Another important point: the desc entity is not allowed in raw files, only in derivatives, so:
acq-megre07_rec-ROMEO_desc_unwrapped_t2starw
acq-megre07_rec-ROMEO_desc-mask_T2starw
would likely qualify as derivatives.

I will check if BIDS already have all the specifications to satisfy SWI images (excluding minIP). It's likely that pushing the suffix will make it possible to share the files. I will check the specifications to come back with valid file names, considering that the swi suffix will be added.

[fabriciocravo]

@Najmahan

I consulted with some of the other maintainers. From my understanding, the standard practice is to name the files according to what is planned for the BEP's resolution. Therefore, feel free to add the swi (miniscule) suffix to the swi images, as this was the accepted change across multiple PRs and discussions.

On some of your proposed file names. I wanted to confirm some things with you.
From my understanding, both ASPIRE and ROMEO are algorithms that work on the phase, not the magnitude. Is that true? If that is the case, rec-ASPIRE and rec-ROMEO should only be contained in the phase files names and not in the magnitude ones. As it is optional, no need to add rec to the magnitude ones.

Further, from my understanding, the ROMEO files appear to have no part. Are they all magnitude files? Normally, it is assumed magnitude, but given SWI images require the combination, the specification would be beneficial here.

For the ROMEO files, since scanners normally generate them, considering them as raw files is not an issue.

Since I can see from your case that the SWI image is generated from the combines echos, the more suitable name that is compatible with the BEP004 discussion is:
acq-megre07_rec-CLEARSWI_swi

I also checked, and unfortunately, there is no clear suffix for the unwrapped phase map, which means this is an issue that BEP004 must address. I will get back to you about that shortly. Do you require a new suffix for this?

Feel free to name the files this way. Upon the BEP004 completion, the validator will be compatible with your dataset naming. I just need to work on adding it to the schema. You can add the SWI files to .bidsignore in the meantime.

[Najmahan]

I have added examples to BEP004.