support for neuropixel data recorded with SpikeGLX

[robertoostenveld]

Marco Numi asked me over email whether we could implement support for Neuropixel data recorded with SpikeGLX software. I found this https://github.com/jenniferColonell/SpikeGLX_Datafile_Tools/tree/main/MATLAB, and using the example added support to the low-level fieldtrip reading functions. That means that high-level functions like ft_preprocessing and ft_databrowser now also support it.

For example

cfg = [];
cfg.dataset = 'myRun1_4_7_2022_mag_stim_comnination_9_10_150uT_2sec_10reps_g0_t0.imec0.lf.bin';
ft_databrowser(cfg); 

[github-actions]

You should test whether your modifications do not break anything.
See https://www.fieldtriptoolbox.org/development/testing/

When outside the DCCN, please consider testing: test_bug804, test_issue1585, test_bug2370, test_bug2231, test_bug1262, test_bug1404, test_pull731, test_issue1395, inspect_issue1216, test_yorkinstruments

When inside the DCCN, please also consider testing: test_bug1856, test_issue1387, test_issue1585, test_bug1427, test_pull1736, test_issue1992, test_bug963, test_bug1407, test_bug3027, test_bug1808, test_bug2385, test_bug1665, inspect_issue1216, test_issue1601, test_issue1395, test_curry, test_yorkinstruments, test_bug2888, test_bug2303, test_bug2027, test_bug1348, test_pull731, test_bug1266, test_bug629, test_bug2093, test_bug1403, test_issue1161, test_issue789, test_bug804, test_pull1229, test_bug1807, test_bug1924, test_ft_read_header, test_bug1914, test_bug2170, test_bug1412, test_pull1248, test_pull1271, test_readcompresseddata, test_pull1374, test_issue1991, test_pull2111, test_bug1490b, test_pull832, test_bug2231, test_bug1262, test_ctf2grad, test_bug1490, test_issue1320, test_bug2887, test_pull1688, test_bug1359

Suggested tests outside the DCCN use public data or do not use data.
Suggested tests inside the DCCN use private data.

[github-actions]

You should test whether your modifications do not break anything.
See https://www.fieldtriptoolbox.org/development/testing/

When outside the DCCN, please consider testing: test_bug2231, test_issue1585, test_bug1262, test_pull731, test_bug2370, inspect_issue1216, test_bug1404, test_issue1395, test_bug804, test_yorkinstruments

When inside the DCCN, please also consider testing: test_bug1807, test_bug1412, test_issue1992, test_bug1427, test_bug2170, test_curry, test_issue1320, test_bug804, test_bug2027, test_bug1924, test_bug2231, test_bug1856, test_bug1262, test_pull731, test_pull1271, test_ctf2grad, test_issue1387, test_bug1914, test_bug2303, test_bug1266, test_bug3027, test_pull1688, test_issue1161, test_pull832, test_readcompresseddata, test_bug1490b, test_issue1601, test_issue1585, test_bug1407, test_bug2888, test_bug2887, test_bug1403, test_bug1359, test_pull1229, test_pull2111, test_issue1395, test_pull1374, test_issue1991, test_bug1490, test_bug1348, test_bug2093, test_pull1736, test_pull1248, test_bug1665, test_bug1808, test_bug629, inspect_issue1216, test_bug963, test_issue789, test_bug2385, test_ft_read_header, test_yorkinstruments

Suggested tests outside the DCCN use public data or do not use data.
Suggested tests inside the DCCN use private data.

[robertoostenveld]

I believe that there is still some useful metadata in the original header (now in hdr.orig) regarding the arrangement of the pixels. And there is apparently also a default .imro file with mapping information between contacts and channels. That could possibly be used to make an elec structure. The elec structure could then be used to make a 2D channel layout, but also for 3D plotting.

An alternative for the 2D channel layout would be to follow this https://www.fieldtriptoolbox.org/tutorial/layout/#making-a-layout-for-lfpspike-electrodes. It would be good to get some input from Marco to decide whether to add more code to fieldtrip, or whether it is better to add some documentation that explains how a researcher can do it themself.

In the technical brochures on https://www.neuropixels.org/probes-np1-0 I found for example this

The probes feature 960 low-impedance TiN recording sites densely tiled
along a thin, 10 mm-long, straight shank. The 384 parallel, configurable,
low-noise recording channels ...

The example data has 384 plus one binary channel, so might match. However, I don't understand yet how the 960 electrode contacts map onto the 384 channels. The meta header suggests that there an offset in the channels/electrodes. Getting the channel-to-electrode mapping right would be relevant for visualization.

[marconumi]

Thank you so much for you preciious help and I am extremely sorry for the late response.
The reader works and I can use low-level funtion like ft_preprocessing, ft_timelock and ft_freqanalysis.
Concerning your doubt, the probe has 960 electrodes but it's possible to employ "just" 384 of these for each recording session and these can be chosen dynamically from the 960 total ones (for example, we use the first 384).

[robertoostenveld]

thanks for the feedback, then this issue can be closed.

[robertoostenveld]

oh no, sorry: I first have to merge and then close