[feature request] Export to IBL Atlas tool?

[jonahpearl]

Hi Si folks — I'm wondering if there's a feature (or any plan to develop one) to allow exporting a recording to the IBL's neat Atlas Electrophysiology tool, which allows post-hoc realignment of probe tracks based on characteristics of the ephys data.

You can read their description of how to export data for their tool here. Unfortunately, it seems to only support data acquired with spikeGLX. I've been using open-ephys, so I'm out of luck, and it seems at least a few others have run into this problem before. As I wrote in that issue, it seems like the exported data is quite similar to what phy needs, and in the same format, so I imagine that si's export_to_phy function is a good starting point. (You can download example data here, "ephys_alignment_sample_data.zip").

I think there's a good chance that a few folks in my lab will develop an exporter for this if one doesn't already exist, but just checking in case someone has already done it...

Thank you!

[samuelgarcia]

Hi,
feel free to propose a PR for implementing export_to_ibl().
The other way which is more work would be to patch this ibl data tools to support spikeinterface object directly as input!

[alejoe91]

@jonahpearl We actually have some code lying around for this:
https://github.com/AllenNeuralDynamics/aind-ephys-ibl-alignment-gui-converter/blob/main/code/run_capsule.py

[jonahpearl]

Aha! Thanks for the tip — I will take a look and see if I can modify it for my use case.

[jonahpearl]

Hi @alejoe91 — I'm encountering an error where there's some mismatched channel labeling. I think it's due to this line that appears to be converting the channel index into the Y value on the npx probe (ie since channel 381 has a probe position of (0, 3820), it gets labeled as "382"). Any idea why they're doing that? It's causing an issue for me where I sometimes have an odd number of total channels in my spikeinterface recording (e.g. 381, because I exclude any that are bad acc. to si.detect_bad_channels), and the last channel is labeled as n+1 in the data, and so it causes an index error further down the road when there are only n channels available. Does the IBL gui use channel numbers for depth? Surely not...I downloaded their sample data and confirmed that their clusters.channels.npy contains a mix of even / odd numbers, so however that example data was created didn't seem to have done this step. I changed this line to be cluster_channels.append(extremum_channel_index) and it seems to work fine. Let me know if you foresee any issues with that.

[alejoe91]

Not sure honestly, but maybe @jsiegle can comment on that?

I think that your solution should be correct. The extremum channel index is already the channel that should be used.

[jsiegle]

I think that should work! Let us know if you encounter any issues.