Make our internal functions to read imro tables consistent with Spikeglx C++ file

[h-mayorquin]

@cwindolf pointed to us the exact mapping from probe type to geometry:

https://github.com/billkarsh/SpikeGLX/blob/master/Src-imro/IMROTbl.cpp#L142

Right now we are doing this with a local ad-hoc solution:

https://github.com/SpikeInterface/probeinterface/blob/2dfc7378b991aa83d3b5bd1036666b2b9c9c2a69/src/probeinterface/io.py#L662-L894

We should follow the convention in their code so we can track it more closely and follow changes. I am opening this issue here to keep track for ourselves and I will add more detaill and an actiionable lists of todo later.

[cwindolf]

Relevant for this issue, another SpikeGLX universal reading project from @jenniferColonell which looks great and handles lots of cases! https://github.com/jenniferColonell/SGLXMetaToCoords

[samuelgarcia]

The function done by @jenniferColonnell use snsGeomMap or snsShankMap fields from the meta file. We chosse the harder way : the imro table.

[h-mayorquin]

You have probably written about this before but would you mind repeating why we have chosen that way, @samuelgarcia ?

It is good for provenance and future decision making.

[jenniferColonell]

@billkarsh and I actually designed the snsGeomMap partly with SpikeInterface in mind, so that all the information to interpret a SpikeGLX file would available in the metadata, without needing to maintain separate tables of probe geometries and other properties. Just to clarify why I'm using the snsShankMap and snsGeomMap: (1) They both include only entries for the saved channels in the file. If you choose to use the imro table (which my older version in fact did) you must also read either the saved channel string. Files with just some of the channels will become more common as people tackle analysis of 4 probe data. (2) They both include the enabled flag, which indicates which sites were disabled during recording. Usually, this is just the reference channels. These are not indicated in the imro table. (3) The snsGeomMap, in particular, has all the geometry information directly available. If there are new probes (there will be new probes) code that reads the snsGeomMap will be compatible with NO changes.

Indeed, to support older data, you need to handle the shank map as well, and keep a table of geometries that correspond to current probes. But you won't need to expand that table as new probes come along.

[h-mayorquin]

@jenniferColonell @cwindolf

This is very useful information. Thanks a lot.

[billkarsh]

We encourage you to parse ~snsGeomMap as a replacement for parsing the imro table. It already combines information about the saved channel subset and the imro table to report where each readout channel is on the probe surface in microns. You don't need to keep up with new probes or carry tables or databases. Everything you need is automatically generated in the ~snsGeomMap for each dataset.

[alejoe91]

Thanks for the info! We definitely will :)

[samuelgarcia]

Merci beaucoup Jennifer and Bill!

I propose to implement all cases in probeinterface, lets be exhaustive.

Lets use first snsGeomMap when available on recent version. For older formats lets keep imro and optionaly we can implement parsing snsShankMap (this was the case a while ago)

Reading and writting imro is also good to have because we can generate and debug the imro table directly in probeinterface.