Add "channel" or "ch" entity for channel-level data

[tsalo]

While most MRI data with multi-channel coils is saved and converted to images only in its combined state, one can reconstruct both magnitude and phase data from each coil separately.

My understanding is that coil-level data is necessary for quantitative susceptibility mapping with SWI data, which is why BEP-004 proposes the addition of a "coil" entity. However, coil-level data can also be used in other modalities, including fMRI, where phase-based denoising can be improved by incorporating coil-level phase data (which @CesarCaballeroGaudes and @ostanley most likely know more about than me).

[sappelhoff]

Hi @tsalo could you be a bit more concrete what you are proposing, preferably also with an example? that will make your issue easier to parse for @bids-standard/raw-mri

[tsalo]

Ah, yes, sorry about that. The idea is that you can save the signal (both magnitude and phase) from individual channels in the head coil. Typically, the scanner combines the data across coils before reconstruction, but it's something you can switch in most sequences. Unfortunately, I don't know exactly which datatypes the entity should apply to, except SWI and func.

In BEP004, the proposed format is _coil-<index>, with the convention that, if coil is not defined, it is assumed that the image is the total/combined data. So, we might have:

func/sub-X_task-Y_coil-1_bold.nii.gz
func/sub-X_task-Y_coil-1_bold.json
func/sub-X_task-Y_coil-2_bold.nii.gz
func/sub-X_task-Y_coil-2_bold.json
func/sub-X_task-Y_coil-3_bold.nii.gz
func/sub-X_task-Y_coil-3_bold.json
func/sub-X_task-Y_bold.nii.gz  # coils 1-3 combined, probably with sum of squares
func/sub-X_task-Y_bold.json

I don't have any data collected yet, but I was hoping to get some phantom data I could share as an example at some point in the near future. In the meantime, is the example I provided helpful?

[ostanley]

Just chiming in here. I have two thoughts on this but I am not as familiar with BIDS specs. I will read up.

1) Storing coil specific functional data will drastically increase storage requirements. I don't think this matters to BIDS but it is something to think about for sharing data. A 32 channel Rx means 32 times the data if it is stored at this level. This turns a 200MB functional file to 6.4GBof data for example and that is just uncombined magnitude.

2) I think that if you are storing combined and uncombined runs in the same folder you need a required field, probably in the json, with a combination method. For example, as sos combined image has a phase of 0 but a complex sum combined image results in poor combinations for magnitude and phase. Therefore you may have a _bold.nii.gz file with one method and a _phase.nii.gz with another method. This is why I believe if you are looking into this stuff the combination method should be required. I don't know the scope of that requirement though. I will think about it.

Hope this helps. Happy to chat more. Excited other people want to try phase denoising :)

Olivia

[tsalo]

@ostanley thank you for weighing in. I hadn't thought about the metadata that should be associated with the entity.

It looks like CoilCombinationMethod is a recommended metadata field (see the last row here), so there's no need to edit the metadata requirements, but we will need more documentation related to coil-level data. I believe that coil-level files should just have "None" or maybe "n/a" for the CoilCombinationMethod field, while the combined files can have some value there if the method used was not root-sum-of-squares (rSOS). Perhaps it would be necessary to add a check when the entity coil is used that CoilCombinationMethod be set to "None" in the validator.

[tsalo]

Would it perhaps be better to use "channel" instead of "coil"? I know that "coil" tends to refer to the whole unit, while "channel" refers to the individual subunits, although in at least one case in the MR BIDS specification, they seem to be used interchangeably:

For the fields described above and in the following section, the term "Volume" refers to a reconstruction of the object being imaged (e.g., brain or part of a brain). In case of multiple channels in a coil, the term "Volume" refers to a combined image rather than an image from each coil.

[tsalo]

It seems like coil combination methods have come a long way in the part few years, so uncombined data aren't necessary for things like QSM anymore. I'm going to close this.