DIXON images

[ashgillman]

Hi, One image type that I don't think has been covered with this proposal is the DIXON acquisition.

I'd suggest a new acquisition type with something like part-<inphase/outphase/water/fat>.

These are common in PET/MR for MRAC, there could be an additional part called either "attentuation" or "MRAC" or "electrondensity" or similar.

I'd be curious on any thoughts.

Thanks, Ash

[ChristophePhillips]

Hi Ash, Could you provide a bit more information about:

• the nature of image(s) you're mentioning.
• the how-when-and-why these are acquired.

This would help us figure out how those images could fit in BEP001 and feed the ensuing discussion on how to accommodate them. :-)

Best, Chris

[lazaral]

Thank you for getting in touch Ash! To add to Chris's questions - is this acquisition type always acquired with PET or can it be a standalone acquisition? There is also a PET BIDS extension project (BEP009) which might be more or less relevant.

[ashgillman]

Hi, no worries.

Dixon images are just a method where two images are acquired in such a way that two images are acquired where only one is fat suppressed. Each image is called various things by different manufacturers/software versions/etc., but something like in-phase for the normal image and out-of-phase or (more accurately) opposed-phase for the fat-suppressed image. These are then added or subtracted to get the water and fat images, which are each more sensitive to the relevant material. http://mriquestions.com/dixon-method.html

So inphase/outphase, are the original types, and water/fat are processed from them (at least for Siemens, but I imagine for other manufacturers also, these just appear in the DICOM Study.

Indeed, they are more common for use in PET/MR for attenuation correction in all regions, or for use for other purposes in imaging of other regions. However, I did see a few citations using them for other purposes in neuro imaging and they are not inherently tied to PET. So I don't think BEP009 is the appropriate place.

However, the derived attenuation image (which is further processed from the water/fat images) probably IS very PET-specific. So, perhaps it would make sense for the in/opp/water/fat to sit under /anat, and the attenuation map to sit under /pet as a part of BEP009?

[ChristophePhillips]

Hmmm, this looks interesting (since PET data are also acquired in the center I am based at).

In term of BIDS, it seems to me that the distinction between the 2 types of images you consider, <inphase/outphase> or <water/fat>, would better fit in the acq-<label> key/value pair, see here. Indeed the part- field is "hard coded" to only have the labels <mag/phase>, see here. Changing this would break back-compatibility and create too many issues...

Now, if this Dixon acquistion protocol is standardized and has specific application, it could simply appear as a new suffix, e.g. _dixon, for which you could require some specific _acq labels. Could you then come up with a short definition of this _dixon suffix, i.e. name and description?

Obviously I am not the only one deciding, so this would have to be discussed with the gang. 😃

[agahkarakuzu]

I am familiar with DIXON from msk imaging. As @ashgillman noted, the number of outputs may depend on the vendor. Regardless of whether derived images are produced by the scanner or calculated offline, in-phase and out-phase are to be recognized as raw and water and fat images as their derivatives.

In this case inputs would be named like this:

sub-01_acq-inphase_DIXON.nii.gz sub-01_acq-outphase_DIXON.nii.gz

outputs would be:

sub-01_Waterimg.nii.gz sub-01_Fatimg.nii.gz

The above applies to 2-point DIXON method. Can be extended to 3-point and add fat fraction map as an output as well. Not sure if 3 point DIXON is any good for attenuation correction in PET/MR applications for imaging brain.

As a side note, having DIXON described in BIDS would attract some body and extremity imaging communities (liver, muscle etc.).

[ashgillman]

This is probably a little off-track for this discussion, but I'm not so sure about stuffing so many things into the acq-<label> field. Its description says it

corresponds to a custom label the user MAY use to distinguish a different set of parameters used for acquiring the same modality

I.e., this is differentiating within the same acquisition type. It also had a related, but slightly different purpose of collecting images across different acquisition types:

If the grouping logic of a set of parametrically linked anatomical images is (entirely or partially) bound up with a metadata field that varies from image to image, acq- SHOULD be included in the file name. This is applicable if the varying entries of the metadata field are categorical.

I find it confusing, then, when certain acquisition types "take command" of the field - it is "free form" until it isn't. It's also not clear how to proceed when you want to include multiple forms of differentiation into acq-<label>.

As an example, I am trying to store a dataset in which a number of Dixon acqusitions are acquired for each contrast, at various breath-hold states (its abdominal, I'm aware that BIDS isn't really designed for this), and also acquired with the higher resolution in different planes. I have something like this (of course liable to change depending how discussions go):

nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-fat_acq-BreathHoldExpirationCoronalPlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-fat_acq-BreathHoldExpirationTraversePlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-fat_acq-BreathHoldHalfExhaleCoronalPlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-fat_acq-BreathHoldInspirationCoronalPlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-inphase_acq-BreathHoldExpirationCoronalPlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-inphase_acq-BreathHoldExpirationTraversePlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-inphase_acq-BreathHoldHalfExhaleCoronalPlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-inphase_acq-BreathHoldInspirationCoronalPlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-outphase_acq-BreathHoldExpirationCoronalPlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-outphase_acq-BreathHoldExpirationTraversePlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-outphase_acq-BreathHoldHalfExhaleCoronalPlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-outphase_acq-BreathHoldInspirationCoronalPlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-water_acq-BreathHoldExpirationCoronalPlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-water_acq-BreathHoldExpirationTraversePlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-water_acq-BreathHoldHalfExhaleCoronalPlane_DIXON.json
nifti/sub-AAA/ses-baselineabdominal/anat/sub-AAA_ses-baselineabdominal_part-water_acq-BreathHoldInspirationCoronalPlane_DIXON.json

[ashgillman]

@ChristophePhillips

Indeed the part- field is "hard coded" to only have the labels <mag/phase>, see here.

I agree that part might not be the best label, especially if it is supposed to be for complex or perhaps even vector images. But that aside, I could also see it being defined something like part<mag/phase|inphase/outphase/...> (or same goes if another label is more appropriate).

Re: implementation I've temporarily implemented that with a separate path_pattern (see https://github.com/bids-standard/pybids/blob/master/bids/layout/config/bids.json#L82) like:

"sub-{subject}[/ses-{session}]/{datatype<anat>|anat}/sub-{subject}[_ses-{session}][_part-{part}][_acq-{acquisition}][_ce-{ceagent}][_rec-{reconstruction}][_run-{run}]_{suffix<DIXON>}.{extension<nii|nii.gz|json>|nii.gz}",

(rather than adding DIXON to:

"sub-{subject}[/ses-{session}]/{datatype<anat>|anat}/sub-{subject}[_ses-{session}][_acq-{acquisition}][_ce-{ceagent}][_rec-{reconstruction}][_run-{run}]_{suffix<T1w|T2w|T1rho|T1map|T2map|T2star|FLAIR|FLASH|PDmap|PD|PDT2|inplaneT[12]|angio>}.{extension<nii|nii.gz|json>|nii.gz}",

@agahkarakuzu I think having separate _Dixon and _WaterImg/_FatImg suffices would be fine. I think it would make sense, then, to assert that the other metadata fields (acq, ce, run, not part obviously if we went that way) between the _Dixon and *Img MUST be the same so there is no ambiguity as to which inpha/outpha a water/fat is derived from.

PS: _Dixon? _DIXON? _dixon? - Its not actually an acronym, but is always stylised that way by Siemens.

[agahkarakuzu]

@ashgillman, we are aware of the confusion brought by that free form and SHOULD duality. Having some reserved acq entity values to describe calculation pairs is still an open discussion.

The reason I fall back on the acq entity is that i) I think part entity is not a good fit and ii) we don't have any other entity ATM which can contain in-phase and out-phase values in the context of DIXON application: mag/phase values are inherent to any kind of images, so these values are highly generalizable. Whereas in DIXON application, in/out refer to the phase coherence of water and fat, more of a specific use case.

I think the point you make comes down to making a selection between acq/part, did I get that right ?

Otherwise, I second that the entities other than those involved in describing input pairs of a grouping suffix (I call them iterator entities in my head) MUST be the same in generated outputs. Entities REQUIRED (acq, or something else in this case) for picking up a grouping suffix (_DIXON) input pairs will disappear from the file name of the generated output (_*Img) anyway.

[ashgillman]

Good point, I see that many images could have the mag/phase properties.

But yes, my point wasn't so much an argument for having a part, but rather something separate from acq. I'm not sure if fa fits here? I don't quite know enough about MR physics to know if the phase change in Dixon is a flip angle thing.

Is there not scope for creating a new field in places where one feels compelled to use acq?

[agahkarakuzu]

@ashgillman fa is for flip angle, so it is not possible to use that for this method. The parameter that is altered in DIXON to obtain in/out phase images is TE. There is an echo entity, but for this application it is better to know which one is in-phase, which one is out-phase from the file name. Having file names like this:

sub-01_echo-01_DIXON.nii.gz sub-01_echo-02_DIXON.nii.gz

would not help much.

Is there not scope for creating a new field in places where one feels compelled to use acq?

This is one of the agenda items for our upcoming meeting.