Support for Philips physiological recordings read-in

[m-miedema]

It would be nice to be able to process Philips proprietary data formats for physiological recordings.

Possible Implementation

• already implemented by @mrikasper in PhysIO toolbox (Matlab) here: https://github.com/translationalneuromodeling/tapas/blob/master/PhysIO/code/readin/tapas_physio_read_physlogfiles_philips.m
• another reimplementation was inspired by PhysIO's approach in Python a few years back by Lukas Snoek: https://github.com/lukassnoek/scanphyslog2bids

[m-miedema]

also per @mrikasper :

The key issue with Philips is that they don't have good time stamps for the scanner events (when does a volume start etc). So you have to either infer this from nominal timing (scanphyslog file ends shortly after last volume) or use regularities in the imaging gradient time course that is written to the same file. The latter is implemented in PhysIO as well , have a look here:https://github.com/translationalneuromodeling/tapas/blob/master/PhysIO/code/sync/tapas_physio_create_scan_timing.m

[costantinoai]

Was this feature ever implemented? We have a substantial amount of Philips physiological data, but at the moment I’m unsure how to convert it to BIDS. A tool that automates this conversion—and ideally also handles preprocessing—would be extremely helpful for us. It would also enable integration with other BIDS conversion tools like BIDScoin (see this discussion).

I’m willing to contribute to getting this process started, but I would greatly appreciate any guidance on how to proceed. Specifically, I’d like to know whether there is ongoing development on tools like phys2bids that might support this, or whether there are general recommendations for building out the conversion process.

Thanks in advance for any help or direction!

[smoia]

@costantinoai we didn't have the occasion to implement it yet, but if you have some data and the willingness to try, we'd love your help! I'm happy to schedule a quick meeting in the upcoming days to guide you through where I think the code should change. Also worth checking in with @nw-duncan who created the parts of the workflow for GE data (and thus for scanner -based derivatives).

We started working a while back with bidscoin and @marcelzwiers , I have to admit I dropped the ball on that front, but we were so close a quick pr should finish the job, if you are interested in running p2b from bidscoin!

[costantinoai]

Hi @smoia , glad to hear this positive comment. I do have heart-rate and respiration data files, and as I mentioned I'd be happy to put some work in it. A quick meeting would indeed be a good start -- feel free to drop me an email at andreaivan.costantino@kuleuven.be !

[nw-duncan]

Happy to help if I can.

For integrating the GE data, I set it so that the files are recognised by particular features of GE physiological recordings and then given a specific filename extension (.gep). The rest of the pipeline is already set up to adapt to different file types, based on the extension, so that was sufficient to integrate things. All that had to be done was to then adapt relevant subsequent processing parts to know what to do with .gep files. Depending on the features of Philips recordings, a similar approach should probably work.

Alternatively, adding an extra flag to the phys2bids function that specifies the scanner type could also work, but that would seem to change the overall workflow. Could be worth it to avoid proliferating filename extensions.

[marcelzwiers]

I can write a basic structure for a phys2bidscoin plugin for BIDScoin, but I don't know much about physiological data, nor do I know how phys2bids needs to be executed/called. As long as phys2bids can read (and return) header attributes from the source data (e.g. sampling_rate or so) and can convert the data to a given output name, then it should be a breeze to get it working. The best approach would be to do a minimal BIDscoin PR to which I can commit my changes

[smoia]

I thought we already had the plugin going from Brainhack OHBM 2021, that was working well with this branch, or do I remember wrong?

We were discussing how to enrich the data the heuristic file can parse with @costantinoai - something we could also add to the GE data workflow. And given that our herusitic file is not too different from the yaml files bidscoin parses, I think there's an easy way to write one from the other

[marcelzwiers]

Yes, we have an old branch, but things have also moved forward. I think using the old branch for reference, to copy pieces of code from, is fine, but I'd start with a fresh plugin

[marcelzwiers]

The biggest improvement is that plugins now inherit from an abstract base class (ABC).

[smoia]

Ah, then yes, it wouldn't work any more. Let's wait that we finish this PR (and maybe a little more for after OHBM changes) and then we can restart the plugin development!

[marcelzwiers]

And given that our herusitic file is not too different from the yaml files bidscoin parses, I think there's an easy way to write one from the other

Can phys2bids also be called directly, i.e. skipping the heuristics file and giving it the output name directly?

[smoia]

We did not implement a workflow for that use, actually. We can think about it, and I'm fairly sure that if we split the current workflow in tasks we could achieve something htat works for both use cases, but I wonder if that's worth implementing. Instead, I think working through the heuristic file OR implementing a yaml file parser would be a better investment.
But if the old plugin was working already through the heuristic file, it should not be a major problem to keep working via that route - after all mostentimes the only thing we can use as information on how to bidsify data is the filename alone, and maybe now we can implement number of TRs. Only (some) MRI files are richer than that.