Phase encoding polarity can not be inferred from PAR/REC

[neurolabusc]

For Philips PAR/REC format files, dicm2nii populates the BIDS field PhaseEncodingDirection based on the attribute Preparation direction. However, this attribute only reports the axis of phase encoding, not the polarity. Therefore, regardless of whether an acquisition was acquired with A->P or P->A, this attribute will report:

.    Preparation direction              :   Anterior-Posterior

To handle these situations, dcm2niix creates the field PhaseEncodingAxis when the axis but not polarity of phase encoding can be determined (e.g. both Philips PAR/REC and DICOMs).

This issue was inspired by this comment. Happy to provide illustrative datasets.

[xiangruili]

@neurolabusc
Thank you for letting me know the limitation. I have been using

PhaseEncodingDirection: j?

where the axis is known, while the polarity is unknown. Do you like this, or do you prefer to creating a new field PhaseEncodingAxis?

[neurolabusc]

PhaseEncodingAxis was suggested by @mharms in 2018. I defer to @effigies for all questions related to BIDS (a role previously held by @chrisfilo). I have no personal preference for PhaseEncodingAxis versus using a ? with PhaseEncodingDirection, though I do think different tools should try to be consistent.

[effigies]

I don't have a personal preference.

The best way to get community input would be to propose a PR to the BIDS specification, either adding "i?"/"j?"/"k?" as valid values, or a new field PhaseEncodingAxis (which presumably must be consistent with PhaseEncodingDirection if both are present).

[mharms]

IMO, i/j/k? are inherently ambiguous. Most people would interpret that notation as calling into question whether even the axis itself is correct.

[xiangruili]

I recalled I talked to chris G long time ago about this. He asked me the possible values for this field. I am not sure if he made the question mark valid or not.

I don't like the idea to add new fields just due to incomplete information for one of the existing fields. BIDS fields is exploding, like dicom, and we should try to avoid new fields if possible.

[mharms]

This would be less of an issue if positive i had to be specified as i+. But that's not the case. i is a valid substitute for i+. Thus i? is ambiguous as to whether you are calling into question the polarity or the direction itself, which is why for this situation, I think the cleanest thing is to have a separate field to use when one is sure of the axis, but unsure of the polarity.

[xiangruili]

@mharms
Could you check if

1. Question marker is valid for this value, or
2. PhaseEncodingAxis is added into the field list?

If one of above two is true, we simply follow it, rather than changing anything.
If none of above is true, we can have more discussion for which one to take.

@neurolabusc What did you do in dcm2niix for those GE data with InPlanePhaseEncodingDirection before we figured out the polarity? To be consistent is another thing to consider, I think.