SpikeInterface/probeinterface

Load Open-ephys probe data with multi-shank

Closed this issue · 11 comments

Hello,
I am trying to load a multishank recording like this but it does not seems to work.

Based on this comment in read_openephys, # TODO get example of multishank for parsing (L911), does that means we cannot load yet multishank probe from open-ephys ? Or the problem is elsewhere?

rec_oe1 = si.read_openephys(oe_npx_folder)
rec_oe1.get_probe()

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
/tmp/ipykernel_161120/3307797951.py in <module>
      1 # internal list of segments- don't touch this!
----> 2 rec_oe1.get_probe()

~/miniconda3/envs/fkdev/lib/python3.7/site-packages/spikeinterface/core/baserecording.py in get_probe(self)
    449 
    450     def get_probe(self):
--> 451         probes = self.get_probes()
    452         assert len(probes) == 1, 'there are several probe use .get_probes() or get_probegroup()'
    453         return probes[0]

~/miniconda3/envs/fkdev/lib/python3.7/site-packages/spikeinterface/core/baserecording.py in get_probes(self)
    454 
    455     def get_probes(self):
--> 456         probegroup = self.get_probegroup()
    457         return probegroup.probes
    458 

~/miniconda3/envs/fkdev/lib/python3.7/site-packages/spikeinterface/core/baserecording.py in get_probegroup(self)
    462             positions = self.get_property('location')
    463             if positions is None:
--> 464                 raise ValueError('There is not Probe attached to recording. use set_probe(...)')
    465             else:
    466                 warn('There is no Probe attached to this recording. Creating a dummy one with contact positions')

ValueError: There is not Probe attached to recording. use set_probe(...)

Probe interface version : 0.2.9
settings.txt

Thanks, Have a good day
Marine, Fklab/Nerf

Hi Marine, thanks for the report. I can't see any shank info in the settings file..however, the probe shoulf be loaded automatically. Can you try to run this?

import probeinterface as pi

probe_oe = pi.read_open_ephys("path-to-oe-folder")

and let me know if you get errors?

Oh indeed there is an error when using the probeinterface module directly. Is that normal the probeinterface errors are not display when using spike interface package ? I was very confused by the lack of errors message.

Exception: Open Ephys can only be read when the Neuropix-PXI plugin is used

I can do some debugging now and keep you posted.

About the shank, it is not this part?

          <CHANNELS CH0="0:0" CH1="0:0" CH2="0:0" CH3="0:0" CH4="0:0" CH5="0:0" CH6="0:0"
                    CH7="0:0" CH8="0:0" CH9="0:0" CH10="0:0" CH11="0:0" CH12="0:0"
                    ...

It just happen that all channels selected were in the shank 0. You would have expected something else?

Thanks for checking! That's weird because you are indeed using the Neuropic-PXI plugin!

The SpikeInterface only tries to load the probe, but if it fails it doesn't throw an error. At least we should display a warning though!

I'll try to reproduce and fix the error from the settings file you provided :)

The detection of the processor is based on the name which for me is different (Sources/Neuropix-PXI) instead of Neuropix-PXI. I will investigate why mine is different. I think it is due to how I installed it (develop mode) but anyway I think you would be better checking on the plugingName attribute which will stay constant.
After the hackathon meeting, i can do some tests to confirm it.

I'll push a fix tomorrow, both for the name and the shank ids!

Great !
For the shank ids, it needs some double check. I just received the imro corresponding and it does not match as some channels where on the shank 1 and not only on the shank 0.

About the shank number, from the code (L1288), it is indeed the second number in CH0="0:0" that gives you the shank.

        if (probe->type == ProbeType::NP2_4)
               chString += ":" + String(shank);

        channelNode->setAttribute("CH" + String(channel), chString);
        xposNode->setAttribute("CH" + String(channel), String(probe->electrodeMetadata[elec].xpos + 250 * shank));
        yposNode->setAttribute("CH" + String(channel), String(probe->electrodeMetadata[elec].ypos + 250 * shank));
    

Be careful there of the PosX and PosY with multiple shanks, I guess the 250 * shank would be a problem for you no?

But that also means there is a problem in Open-Ephys side as our multishank imro file does match the setting.xml obtained.
What do you think ? Does it makes sense ?

Edit: Also, FYI, with your fix, the probe is loaded but as the shank info is wrong, there are channels with the same x/y. It does not fail in the probe loading, but when loading with spike interface it fails because of missing channels spec. I am sure it is all related to the shank problem in Open-Ephys.

Thanks for pointing to the code! I'll implement the same logic into probeinterface making sure the shank info and 250 shift!

@jsiegle is it possible that the shank id is not correctly saved to the settings.xml? There seems to be a mismatch between the imro and the OE settings.

The shank index is written properly with the latest version of the Neuropixels plugin (example file here). We're currently investigating why the correct shank indices didn't get stored in Marine's case.

And shank ids loaded here: #107 (this is the data from @jsiegle)

image

Thanks for the fix !