Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement new interfaces for other non-MRI recorded file formats #405

Open
smoia opened this issue Jun 17, 2021 · 6 comments
Open

Implement new interfaces for other non-MRI recorded file formats #405

smoia opened this issue Jun 17, 2021 · 6 comments
Labels
Enhancement New feature or request

Comments

@smoia
Copy link
Member

smoia commented Jun 17, 2021

During OHBMH @htwangtw showed me neo, a python package that can read a lot of different physiological file formats (see the list here), like Spike2 as implemented here.
@htwangtw also has some code that we could use to work on a phys2bids interface for spike2 here.

We could use it to expand our file support to other file formats. Granted, we also would need some actual recordings to work with, but we could start looking around for them.

Some of the file formats are for neurophysiology, some others are for general biosignal - and we should concentrate on those!

@smoia smoia added the Enhancement New feature or request label Jun 17, 2021
@htwangtw
Copy link
Contributor

A few things I found while working on this issue:

For Spike2 file, CED has two kinds of files, .smr and .smrx. The latter is a 64-bits version and going to replace to former. It will be a few release cycle before .smrx is supported. (See this issue)
Another news is CED released a pip-installable API

We can either -

  1. Limit the support .smr and wait for the upstream dependency to update smrx support
  2. Use sonpy API

WDYT?

@smoia
Copy link
Member Author

smoia commented Jun 24, 2021

Sorry for the late reply - I didn't see this comment!

I'd start with .smr support through neo (also because I can't find the documentation of sonpy), and add .smrx support in the future. I wouldn't drop .smr support unless we're 100% sure that it's not used any more by the users.
If sonpy supports both formats, we could use that API instead.

Does it make sense?

@htwangtw
Copy link
Contributor

I had a closer look - neo is using sonpy under the hood.
The part of neo that broke the loading function of .smrx is just missing the header loading info in the 64-bit format.
I can attempt to fix the upstream dependency so we can just use neo

@smoia
Copy link
Member Author

smoia commented Jun 24, 2021

Oh wow, that sounds great!

Or we can also use sonpy straight away and get the interface rolling, as you prefer!

@smoia
Copy link
Member Author

smoia commented Jun 24, 2021

(as in: I completely trust your judgement, go for the option that is easier or looks more proper for you to implement)

Btw, do you have a link to sonpy API?

@htwangtw
Copy link
Contributor

(as in: I completely trust your judgement, go for the option that is easier or looks more proper for you to implement)

Btw, do you have a link to sonpy API?

There's no online doc. The only way to access it is by installing sonpy through pip. Inside there's a PDF for docs and API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants