Total Readout Time for QSIPREP, Philips scan data

Hello All,

I am trying to apply QSIprep 0.16.1 to data from a Philips Scanner, however I encountered some problems related to overcoming limited data in the Philips DICOM headers (a problem already here).

It is a topic that has already been discussed there but it was specific only for fMRIprep and I am wondering if the solutions can also be applied to DWI data.

  • “TotalReadOutTime” : Should I use the “EstimatedTotalReadoutTime” value ?
    -“PhaseEncodingDirection” : Should I use the same parameter as “PhaseEncodingAxis” ?

Thanks !


Hi @Mathis_Fleury and welcome to neurostars!

Why not use the most recent version (0.19.0)?

Yes but you’ll also want to make sure, as mentioned in the other thread, that the value is the same across images used for TOPUP (if you are doing SDC as part of your process).

Can you give an example of what kind of values you get from that axis field? PhaseEncodingDirection should have a value of i/-i/j/-j/k/-k.


Hi Steven,

Thank you for your answer :slight_smile:

Yes I can use the latest version since I have no conflict there.

Thank you for this clarification !

And the “PhaseEncodingAxis” has a value of “j”, should I use this value ?



One thing to be aware of, your PhaseEncodingAxis will be the same regardless of the PhaseEncodingDirection. IIRC there is a vendor that won’t include the direction in the dicom files so you need to know which direction you collected based on the sequence name. As @Steven mentioned, if you’re intending to do distortion correction using AP/PA acquisitions you’ll need to figure out which is which and add the correct PhaseEncodingDirection to their sidecars. One of them will be j-

@mattcieslak is correct: PhaseEncodingAxis does not discriminate between A->P and P->A, nor does it discriminate between L->R and R->L. So for Axial scans it tells you either L?R or A?P. This is a limitation of Philips DICOM files, not dcm2niix. I would suggest that you work with the Philips Clinical Scientist associated with your center to develop a robust method for discriminating these (e.g. appending polarity to user-editable protocol names).

Thank you everyone for those replies, it is clearer now !