Repository navigation
NHP long probes (NP1020, NP1030) have incorrect probe_planar_contour height #388
Description
The probe_planar_contour for long NHP Neuropixels probes is incorrectly sized. The polygon height is hardcoded to ~10mm for all NHP probes, regardless of actual probe length.
Affected probes:
- NP1020: contacts span 24,940 μm but contour is only 10,373 μm
- NP1030: contacts span 44,140 μm but contour is only 10,373 μm
The issue is in the polygon_description dictionary which has fixed 10,000 μm heights for all neuropixels variants:
probeinterface/src/probeinterface/neuropixels_tools.py
Lines 93 to 111 in 6b2b819
Probably contour should scale with the actual probe length based on contact rows × y_pitch.
This is not capture with the matplotlib version:
https://github.com/SpikeInterface/probeinterface_library/blob/main/imec/NP1020/NP1020.png
Activity
chrishalcrow commentedon Dec 18, 2025
Hello, yeah, defo a problem!
One issue with using
contact_rows x y_pitchis that sometimes there is a large gap between the top electrode at the top of the physical probe, e.g. https://h-mayorquin.github.io/apps/probe-viewer/#/probes/imec/NP1100. So it's nice that the current setting does reflect reality (for the probes that don't fail).But I think your suggestion is better than the current set-up.
alejoe91 commentedon Dec 18, 2025
We could ask Bill to add the actual probe length to the ProbeMaps
h-mayorquin commentedon Dec 18, 2025
Yes, I guess that would be the way to move forward.
Also, should we have a way on the schema to mark things that we are inferring and are not derived from source? it would be nice to mark that down for downstream users.
h-mayorquin commentedon Dec 18, 2025
@chrishalcrow I think that the gap comment is relevant to what Bill is proposing here:
billkarsh/ProbeTable#4 (comment)
Am I correct about it? If so, could you help me addressing that there? As in, why we might want the gap.
billkarsh commentedon Dec 18, 2025
My thoughts about it. What's useful is where the active sites are relative to neural targets. That may be aided by knowing how far you inserted after the tip touches the outer surface, hence tip length is important. However, how much length of shank is above the target has no importance. Another way of saying this is no matter how long a shank is, it only matters how far you insert it.
alejoe91 commentedon Dec 19, 2025
Thanks @billkarsh. I think this could be relevant for visualization and integration with pinpoint or similar. In my opinion, if we have you have this info, it wouldn't hurt adding it to the table.
billkarsh commentedon Dec 19, 2025
We are integrated with pinpoint. Length is not a needed parameter. Rather an axis is zeroed where the tip touches the surface. The length is not tabulated because it isn't used. We don't have it. It would need to be created and that takes people's time. I'm pushing back where there isn't need.
h-mayorquin commentedon Dec 19, 2025
Thanks for jumping in @billkarsh
We are probably gonna add it here for completeness. I understand that you are busy, would you welcome us pushing a PR to the probe table repo?
h-mayorquin commentedon Dec 19, 2025
I will add this from the sheets hereafter #383 is either accepted or rejected
billkarsh commentedon Dec 19, 2025
Please don't make a PR. The data are drawn from several sources and formats and have to be merged. I'll try to add these data in some appropriate way.
h-mayorquin commentedon Dec 19, 2025
Thanks
billkarsh commentedon Dec 19, 2025
Posted v1.5. The new field, shank_tip_to_base_um has nominal values (good to <.5mm) which are hopefully close enough for visualization. This level of precision does not need to involve the imec engineers to obtain.
BTW, it remains true that the region of active sites is defined as starting at tip_length_um. From there it extends upward spanning: electrode_pitch_vert_um * (rows_per_shank - 1) + (electrode_size_vert_direction_um / 2). The region from there to the end of shank_tip_to_base_um (to the base edge) has no addressable sites.
Note that detailed modeling, say, to calculate probe collisions in a very crowded insertion plan, or to design fixturing, would be better served by CAD files than by innumerable table entries.