Total Readout Time for fMRIPREP with topup on Philips scan data, possible dcm2niix error

,
1

I am trying to apply fMRIprep to data from a Philips scanner using topup for distortion correction. I’m confused about some issues related to overcoming limited data in the Philips DICOM headers

– Before using fmriprep, our lab had been calculating Total Readout Time using the Spinoza/OSF method described here: OSF . The problem is, Estimated Total Readout Time values calculated by dcm2niix differ from that method by a factor of 2, beyond any slight differences from using different formulas, in our data.

I think this may have something to do with the reported 2x SENSE acceleration factor in the image headers. As I understand it, acceleration needs to be taken into account in some versions of the formula for total readout time. However, our headers include a field for “EchoTrainLength”, which I believe corresponds to (EPI factor + 1) after taking into account acceleration.

When I try to compute the Total Readout Time myself using header data with the formula ((“WaterFatShift” x (“ReconMatrixPE”-1))/(3.4 x “ImagingFrequency” x “EchoTrainLength”)), I get a similar value to what the Spinoza/OSF formula produces. This makes me wonder if dcm2niix is handling the acceleration factor erroneously.

– I also noticed that the total readout time value shouldn’t really matter in most cases, as long as it doesn’t vary between the blip_up and blip_down images (which it doesn’t for us), and as long as images don’t need to be precisely scaled. My question for the fmriprep team regards the latter: is it OK for fmriprep if the total readout time value is incorrect but consistent between scans?

– Finally, because Philips scan headers don’t distinguish between A–>P and P–>A phase encoding directions, I saw elsewhere that it’s best to take the PhaseEncodingAxis value from dcm2niix, and just set the direction to opposing directions for field map data. But now I see that fmriprep is also asking for phase encoding direction to be set on functional images. Does it matter if this is precisely correct (i.e., does it matter if this is j vs. j- for functional images)?

Thanks,
Michael

2

This is a limitation of Philips DICOM images, not dcm2niix. Please see the dcm2niix notes. With the contemporary Philips DICOMs it is impossible to compute the FSL/BIDS definition of TotalReadoutTime. For the details, please see dcm2niix issue 377. Please lobby the Philips clinical scientist affiliated with your site to include additional sequence details in the scan.

The good news is that the “TotalReadoutTime” correct is not critical to the TOPUP correction if the readout time is identical for all the relevant images.

The order of j and j- does not matter: the final transform will be of identical magnitude.

3

Thanks, Dr. Rorden – yeah, I did read up on what I could find online from you and others about this issue.

What seemed strange is that I thought I was using the same formula that you used to calculate “EstimatedTotalReadoutTime” in dcm2niix based on what the Philips headers do provide, but I’m not getting the same result, and I’m not sure why that would be.

That is also good to hear that these things shouldn’t matter, though. I’m not sure if the fMRIPrep team (@oesteban or others) have anything more to add on this, but if not, I’ll assume that it’s OK to go forward as-is.