Use ProbeGroup object instead of contact_vector property#4465
Use ProbeGroup object instead of contact_vector property#4465alejoe91 wants to merge 17 commits intoSpikeInterface:mainfrom
ProbeGroup object instead of contact_vector property#4465Conversation
Co-authored-by: Alessio Buccino <alejoe9187@gmail.com>
| ) | ||
| # check that multiple probes are non-overlapping | ||
| all_probes = recording.get_probegroup().probes | ||
| check_probe_do_not_overlap(all_probes) |
There was a problem hiding this comment.
This is removed because when we split_by and aggregate probes might overlap
|
I would like to take a look to this. I can do it this week. |
|
I guess that @zm711 and @h-mayorquin are now dancing on their seat just reading this PR. Let me read it slowly. |
h-mayorquin
left a comment
There was a problem hiding this comment.
As we discussed previously I think this is a step in the direction direction.
Is _build_probegroup_from_properties only for backwwards compatbility?
I think we can segregate the backward-compatibility serialization logic (_build_probegroup_from_properties) from the main class methods by moving it into the deserialization hooks. _extra_metadata_from_dict already runs after properties are set (base.py:1202), so it can check for "probegroup" first and fall back to reconstructing from contact_vector. For the folder path, load_metadata_from_folder (base.py:639) needs to swap lines 643 and 646 so .npy properties load before _extra_metadata_from_folder runs, giving the hook access to legacy contact_vector when there is no probe.json. This has the side effect of a cleaner design where has_probe() becomes return self._probegroup is not None with no mutation at check time.
Let's check also how zarr does it. If we don't have a separate function for zarr, we can also add it to |
Depends on SpikeInterface/probeinterface#416