The relationship between win_step_um and contact positions.

[BEGINRX]

I met a bug.

Traceback (most recent call last):
  File "/home/NITD/lxr/code/spike_sorting/run_sorter1014.py", line 405, in start_sorting
    rec_corrected, rec_ww = preprocess(raw_rec_part, detection, filting, need_correct_motion)
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/NITD/lxr/code/spike_sorting/run_sorter1014.py", line 199, in preprocess
    recording_f = si.correct_motion(recording=recording_f, preset='kilosort_like', detect_kwargs=detection,
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/NITD/anaconda3/envs/si_env_rolling/lib/python3.11/site-packages/spikeinterface/preprocessing/motion.py", line 436, in correct_motion
    motion = estimate_motion(recording, peaks, peak_locations, progress_bar=progress_bar, **estimate_motion_kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/NITD/anaconda3/envs/si_env_rolling/lib/python3.11/site-packages/spikeinterface/sortingcomponents/motion/motion_estimation.py", line 111, in estimate_motion
    motion = method_class.run(
             ^^^^^^^^^^^^^^^^^
  File "/home/NITD/anaconda3/envs/si_env_rolling/lib/python3.11/site-packages/spikeinterface/sortingcomponents/motion/iterative_template.py", line 117, in run
    shift_indices, target_histogram, shift_covs_block = iterative_template_registration(
                                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/NITD/anaconda3/envs/si_env_rolling/lib/python3.11/site-packages/spikeinterface/sortingcomponents/motion/iterative_template.py", line 246, in iterative_template_registration
    window_slice = slice(window_slice[0], window_slice[-1])
                         ~~~~~~~~~~~~^^^
IndexError: index 0 is out of bounds for axis 0 with size 0

The contacts' positions are computed by positions = [[i*100, j*100] for j in range(0, 2) for i in range(0, 4) ]. How can I set the win_step to aviod the problem.

[zm711]

I think seeing the script for this would also be beneficial.

[BEGINRX]

In the preprocess,

def preprocess(raw_rec, detection, filting, need_correct_motion):
    estimate_motion_kwargs = dict()
    estimate_motion_kwargs['rigid'] = False

    estimate_motion_kwargs['win_step_um'] = 2
    estimate_motion_kwargs['win_scale_um'] = 1.5

    recording_cmr = si.common_reference(raw_rec, reference='global', operator='median', dtype='float32')
    recording_f = si.bandpass_filter(recording_cmr, freq_min=filting['freq_min'], freq_max=filting['freq_max'], dtype='float32')
    if need_correct_motion:
        recording_f = si.correct_motion(recording=recording_f, preset='kilosort_like', detect_kwargs=detection,
                                      estimate_motion_kwargs=estimate_motion_kwargs)
    rec_w = si.whiten(recording=recording_f)
    return recording_f, rec_w

Obviously, need_correct_motion is True.

[BEGINRX]

This enviorment is '0.101.2'.

[cwindolf]

I've seen this before too in tiny probes. Definitely something we can add a test case for. Maybe it's just setting rigid=True when the probe length is super small... will take a look when I get a chance.

[cwindolf]

But in any case @BEGINRX I'd suggest using rigid=True in your motion estimation for now, this would hopefully not trigger the crash (I think!! hope I am right, let me know if not), and we'll also fix this bug so that future users don't hit it either.

Alternatively, if you want nonrigid registration, 2um is a tiny window step that you have set here. Maybe you want something more like 200um? With contacts spaced by 100um, motion estimation will be a challenge!

[samuelgarcia]

Yes.
We need to handle more carrefully and with better message when win_step and win_scale are too big if the probe is small.