Old Philips data

Dear experts,

I’m currently preprocessing an old Philips rest fMRI dataset using fMRIprep. Unfortunately there is no slice timing info in the PAR/REC data, so I cannot use STC. There is PhaseEncodingDirection info (which is called Preparation Direction in the PAR file) which is anterior-posterior, so j- . However, the newest version of dcm2niix does not include this in the json file, while an older dicm2nii does do this (I decided to still use the newest version of dcm2niix and add it to the json myself). Is this enough for using the Syn-based distortion correction? It seems to work fine.

Thanks!

Best
Hans van der Horn

It is worth noting that dicm2nii and dcm2niix are separate tools, so an older version of dicm2nii may perform better than a later version of dcm2niix (or vice versa). The two teams work closely together, so most should perform well for most cases, but you may observe differences for edge cases. It is worth noting that the lead developers for both tools work a sites with Siemens equipment, and therefore rely on users for exemplars for other manufacturers.

In particular, Philips users should only export to PAR/REC when required (e.g. multi band sequence with too many slices to be exported to DICOM with current Philips software). I would heed the warning of a Philips engineer that PAR/REC reflects simpler times and contains limited meta data.

As you note, dicm2nii uses the PAR tag Preparation Direction to determine the BIDS tag PhaseEncodingDirection:

.    Preparation direction              :   Anterior-Posterior

However, in my experience, this PAR value only reports the PhaseEncodingAxis. In other words, it will report Anterior-Posterior for both Anterior->Posterior as well as Posterior->Anterior. So while dicm2nii will respond to the value Posterior-Anterior, I am not convinced this is ever seen in actual data. This explains why dcm2niix does not support this feature: I prefer to only include information I am confident about. You should be fine using either dicm2nii, or using dcm2niix and inserting the tag:

	"PhaseEncodingDirection": "j-",

However, you will have to intervene if you have any FSL TOPUP compatible undistortion series which leverages reversed polarity phase encoding (which was the original rationale for the PhaseEncodingDirection tag).

Unfortunately, phase encoding polarity is also missing from Philips DICOM data. I urge all users of Philips equipment to lobby their Philips Research Collaboration Managers to provide critical meta data. The impoverished BIDS files created by dcm2niix and dicm2nii for Philips data is a reflection of the missing information in the source files, not in the conversion software.

Dear Chris,

Thanks so much for your detailed reply. So, I am correct that specifying the Phase Encoding Axis is enough for Syn-based distortion correction? (and no polarity info is necessary).

I’d also like to ask one more question if that’s all right. Converting this old data unfortunately does not create any meta-data regarding slice timing. That’s why I plan to perform slice timing correction in SPM first and then run fMRIprep. What do you think of this approach?

Thanks again.
Best
Hans

Unfortunately, Philips does not SliceTiming data for either PAR/REC or DICOM images. Again, this is a limitation of Philips data, not the converters. As ever, please lobby your Philips Research Collaboration Manager to provide these details in their images.

Dear Chris,

Thanks for your response. Unfortunately, it’s an old, already replaced, scanner. We use a Siemens scanner now. However, this old Philips rest fMRI data has never been analyzed, so I’d like to give it a try. Since I like the processing pipeline of fMRIprep a lot, I will add a SliceTiming and PhaseEncodingDirection tag to the json files created with dcm2niix and use this.

Best
Hans

Curious – how old is old?
if <= 2013, checkout slides from 61 of an elderly talk http://www.onerussian.com/tmp/talk-umass2019-tales.pdf – you might be able to tell if it was interleaved collection based on the presence of artifact (if you can catch it ;)), and then evenly distributing timing through the RT following that order. But altogether – I would so not bother about slice timing correction (it is a chicken/egg issue of either motion correct or slice time correct, and “stock” implementations don’t do simulaltaneous estimation).

It’s a dataset from 2009. Thanks for your info, I will check it out:)