NHP long probes (NP1020, NP1030) have incorrect probe_planar_contour height

[h-mayorquin]

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

	def get_probe_length(probe_part_number: str) -> int:
	"""
	Returns the length of a given probe. We assume a length of
	1cm (10_000 microns) by default.
	Parameters
	----------
	probe_part_number : str
	The part number of the probe e.g. 'NP2013'.
	Returns
	-------
	probe_length : int
	Length of full probe (microns)
	"""
	probe_length = 10_000
	return probe_length

Probably contour should scale with the actual probe length based on contact rows × y_pitch.

Check here:
https://h-mayorquin.github.io/apps/probe-viewer/#/probes/imec/NP1020?x=-86&y=-873&zoom=25.63&cx=182.5&cy=9806.2

This is not capture with the matplotlib version:
https://github.com/SpikeInterface/probeinterface_library/blob/main/imec/NP1020/NP1020.png

[chrishalcrow]

Hello, yeah, defo a problem!

One issue with using contact_rows x y_pitch is 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]

We could ask Bill to add the actual probe length to the ProbeMaps

[h-mayorquin]

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]

Hello, yeah, defo a problem!

One issue with using contact_rows x y_pitch is 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.

@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]

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]

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.

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]

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]

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]

I will add this from the sheets hereafter #383 is either accepted or rejected

[billkarsh]

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]

Thanks

[billkarsh]

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.