Siemens PhaseEncodingDirection polarity wrong when phase encoding in Column direction

[neurolabusc]

This issue first described by Michael Harms
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=MRICRO;ed070f02.1708
Data acquired with Axial (RL/LR, AP/PA), Coronal (RL/LR, F/H,H/F) and Sagittal (A/P,P/A, F/H,H/F) to demonstrate this issue are here
http://people.cas.sc.edu/rorden/dcm_test/phase_encode.zip
To match the BIDS spec, the polarity of the PhaseEncodingDirection direction should be reversed when phase-encoding is in the i-dimension. This should have little influence on tools like TOPUP, as the prior method accurately detected sequences that used different phase encoding directions. However, it should be changed to ensure BIDS compliance.

[mharms]

Maybe I'm missing something, but assuming that opts.isFlagY = true, won't the revised code now incorrectly swap the reported polarity when the PhaseEncodingDirection is 'j'? i.e., Doesn't the treatment need to be contingent on the PhaseEncodingDirection itself? A>>P has phaseEncodingDirectionPositive=1, and should be 'y-'. P>>A has phaseEncodingDirectionPositive=0, and should be 'y'.

[neurolabusc]

Yup, please check latest update - I validated this with the data I acquired. New conditionals should work regardless of the opts.isFlipY setting (e.g. the direction of the column vector is not influenced based on whether you swap the order of rows). Thanks for spotting this.

[mharms]

Sorry, but I don't see it. The changes you made will correct the polarity for RL/LR, but appear to have introduced an error for AP/PA data. Namely, data acquired with a "P>>A" phase encoding will have
d.CSA.phaseEncodingDirectionPositive == 0
So, assuming we are flipping to a LAS oriented output, the following code will get invoked

else if ((d.CSA.phaseEncodingDirectionPositive == 0) && ((opts.isFlipY)))
fprintf(fp, "-");

such that I'd expect the PA scan to have PhaseEncodingDirection = j- (and the AP scan to have PhaseEncodingDirection = j)
But, for an LAS oriented output, the PA scan should be j, and the AP scan should be j-
Admittedly, I did not compile and directly test the proposed change. But I don' t see how it can be correct from the code...

[neurolabusc]

Michael-
Please compile and test - appears to work with all the Prisma data I acquired this week (linked above) across phase encoding directions and image orientation (Axial, Coronal, Sagittal). I think you are being thrown off by the fact that DICOM and NIfTI have reverse polarity in the X (a.ka. J) dimension, e.g. the rows of a 2D image. For DICOM, rows are indexed like we read English, starting at the top and proceeding down. In contrast, NIfTI draws the Y coordinate like we draw a graph with cartesian coordinates, with larger values above lower values.

[mharms]

Now, that (commit e31930*) makes perfect sense, and I can see how that will generate the desired polarities (at least for axial slices, where the PE direction is either RL/LR or AP/PA). Thanks!

[mharms]

One other (admittedly somewhat esoteric) issue related to the accuracy of the reported PhaseEncodingDirection is 3D acquisitions. The value of PhaseEncodingDirection for 3D scans is not accounting for the reorientation that occurs for 3D scans (as discussed here: #117). Admittedly, the definition of PhaseEncodingDirection is somewhat ambiguous for 3D scans, since there are two PE directions. But if that tag is going to be included for 3D scans, it seems like it should at least account for the reorientation of what Siemens considers the (primary) PE direction. Otherwise, the tag has no meaning whatsoever for 3D scans. Cheers.

[neurolabusc]

PhaseEncodingDirection is no longer reported for 3D acquisitions.