Future plans for probes in probe library?

[dbirman]

Hi, I'm the developer of Pinpoint and I think it would be really nice to use probeinterface to automatically generate 3D models of the many probes people are using for electrophysiology.

I just looked at the probeinterface library and I'm only seeing a handful of probe options. Are there plans to expand the library to other really common probe types such as Neuropixels?

[samuelgarcia]

Hi Dan.
sorry for the delay. Vaccation are super long in France.

Congrats for pinpoint, this looks amazing.

Neuropixel probe are handle with openephys and spikeglx format with the read_imro() read_spikeglx()function.
Have a look to this https://github.com/SpikeInterface/probeinterface/blob/main/probeinterface/io.py#L1108
The neuropixel probe is somehow dynamic because the active contacts depend on the setting. This is what probeinterface do, parse the files from openephys and spikeglx. Of the course the probe shape is always the same.

The primary goals of probeinterface was to handle the probe geometry thought the prisme of spike sorting and so mostly the contact postion. We also include some basic 2d shape (probe + conact) for plotting results.
The main use is for spikeinterface.

If it can help other tools like pinpoints, for sure, we are open to any extention of the format (json based) to also handle optionaly 3d mesh to describe the probe in 3D.

We won't have time to implement this within a short delay but if you have time to try an implementation then we could have a call to discuss the best way to improve this.

[dbirman]

Okay so if I understood right you don't have Neuropixels probes in your library because you generate them dynamically from the imro files, since you are mostly interested in the active contacts for the purposes of spike sorting?

That makes sense, but I think then probably probeinterface isn't useful for me to incorporate into Pinpoint, since we represent probes not only by their active sites but the full geometry. Then we allow users to select among the different possible active site configurations when there are options for that. For reference, the internal representation I use for a probe (e.g. neuropixels 1.0) looks like this: neuropixels_1.csv. As you can see there are columns that define the different possible active site configurations that users can select from, or upload their own configuration from an imro file. I store the 3D geometry information separately as a .obj 3D model. I think the library files (these files: https://gin.g-node.org/spikeinterface/probeinterface_library) have the right information to reconstruct this channel csv and 3D geometry (since most probes are actually 2D with a constant depth), but they don't represent the possible active site configurations.

Unless there's a plan to expand the library to additional probe types, including neuropixels, and add active channel options, then I think it's not worth it to spend time on adding the 3D geometry to the library. Let me know if you have other thoughts?

[alejoe91]

Hi @dbirman

Sorry for my late reply on this. You are right, currently the Neuropixels probes are created dynamically from the meta/settings files of SpikeGLX/Open Ephys.

However, I think it makes absolute sense to add the full geometries in the probeinterface library and then use the settings files to dynamically wire the connected channels.

In this case, loading the probe from the library will return a full probe, while the read_* functions will fetch the full probe from the library and slice it according to the channel selection. Do you have the csv files for all NP probes?

[dbirman]

No worries. I have these files for NP1/NP2 probes, not for any of the more atypical varieties (like ultra, etc). NP1 is above, here's the NP2 file: neuropixels_2.csv. This defines the channel geometry along a single probe shank relative to the tip, so you have to extrapolate to get 4 shanks.

[samuelgarcia]

Maybe this files could be converted to the probeinterface json format et push to the libray with a name like "NP1-all-channels".
What do you think ?

[alejoe91]

Yes I think that would be useful! Or really just "Neuropixels-1.0", since that is indeed the probe design. The meta/settings files would then just add the wiring

[danielpollak]

Not sure if this hasn't already been done somewhere, but I thought it might be useful to share this quick 'n dirty first- or all-bank code snippet for NP1.0:

from probeinterface.plotting import plot_probe
import probeinterface
total=384 #, 960
NP1 = probeinterface.generate_multi_columns_probe(
    4, num_contact_per_column=total//4, xpitch=16, ypitch=40,
    y_shift_per_column=[0,20,0,20], contact_shapes="square", contact_shape_params={"width":12},)

plot_probe(NP1, with_contact_id=True, title="NP1.0")

[WeissShahaf]

was this implemented?
@samuelgarcia a function to export from probeinteface to pinpoint would be greatly appriciated

@dbirman an option to upload a probeinteface probe design into the Pinpoint GUI would also be great. or even just a convertion script / function

[dbirman]

I didn't end up working more on this, although I do want to find a solution for easier importing of probes into Pinpoint. The probeinterface_library repo doesn't seem to be getting any updates, so I assume when people use probeinterface they are using it directly without loading the specs for a probe from somewhere?

I could use probeinterface to define the metadata for probes and then build them into Pinpoint, which would be a little easier for people to make contributions, just not sure if this is the right tool for that!

[WeissShahaf]

@db or each user makes his own probe that he saves locally.

But I guess you're right. Picking one platform isn't the way.
Perhaps you can just publish the Metadata pinpoint needs. And have an import function that looks for that.
Then it's up to the user to create that data. However they choose to.