Siemens "Invert RO/PE polarity" detected by dcm2nii?

dcm2niix
fieldmap
fmriprep
heudiconv

#1

Hi All,

I have just learned of a setting on our Siemens scanner which effectively reverses the phase encoding direction if switched on: “Invert RO/PE Polarity” (https://github.com/CMRR-C2P/MB/issues/84).

Does anyone know if this inversion would be detected by dcm2nii (and subsequently passed to heudiconv) so that the correct phase encoding direction would be written to the field map and BOLD json files for fmriprep?

This concern has been raised as we have a sequence which has been incorrectly named as “xxx_PA” (posterior-anterior), which the radiographer suggested might have the geometry as A>P but the encoding direction inverted. I’d like to be sure that should this inversion option be switched on, dcm2nii would be able to catch it and label it appropriately. Invert RO/PE is “off” for the BIDS formatted data I have available, so I haven’t got an example to check against.

Many Thanks,

Cass


#2

Currently it looks like heudiconv is using the successor to dcm2nii, dcm2niix.

There is no mention of polarity inversion detection being a feature in the documentation:

I couldn’t positively identify anything in the code base that would detect this, but some one more familiar with the code base would better be able to definitively say.


#3

Many thanks for looking into the documentation and code base, @rwblair. I am reassured that this is not something so obvious that I should have known about it already, and I will keep an eye out for it in our sequences going forward.


#4

Don’t know the details about how dcm2niix accesses the information, but we use the “Invert RO/PE Polarity”-option in the CMRR sequences for our spin echo fieldmaps (Siemens Prisma). And dcm2niix detects this, that is, PhaseEncodingDirection comes out correctly in the associated .json.


#5

dcm2niix populates the BIDS JSON field PhaseEncodingDirection if it can determine both the Phase encoding direction and polarity (e.g. for axial scans: A->P, P->A, R->L, L->R). It populates the field PhaseEncodingAxis if it is able to determine the direction but not the polarity (e.g. A<->P vs R<->L). dcm2niix is limited to the amount of information that the vendors insert into their DICOM images. In general, neither GE or Philips report the PE polarity. However, for Siemens this information is recorded in the CSA header, which will help users of VA…VE software. Unfortunately, the new Siemens XA enhanced DICOMs (Vida) do not store this. If you have a Vida, I would encourage you to lobby your Research Collaboration Manager. Further, users of Siemens VE11C software should be aware of a bug in the product sequences where copy references will convert a P->A scan to R->L and a L->R scan to A->P. This is an insidious bug, because it happens spontaneously as you plan a scan. Further, the Siemens E11C product DWI sequence has a bug where when the user requests a monopolar sequence the default directions are acquired with only a half sphere. I would encourage E11C users to use the CMRR research sequences (which include a handy “reverseRO/PE” checkboxes) until these issues are fixed. Users of Siemens hardware need to be aware that Siemens is now supporting two different platforms (XA11, VE11) and their engineering resources seem to be spread very thin. It appears to me that both have had teething problems that we have not seen since VB13. There is a web page that describes how dcm2niix decodes Siemens data, so you can always write your own scripts to interrogate your images.