Try to add plots on probe.

Author: JoeZiminski

doc/long_tutorials/handle_drift/handle_drift_jupyter.zip

@@ -15,6 +15,7 @@ rst (TODO: fill in filename) that
 sphinx-gallery generates.
 
 
+
 .. raw:: html
 
     <div class="sphx-glr-thumbnails">
@@ -23,7 +24,7 @@ sphinx-gallery generates.
 
 .. raw:: html
 
-    <div class="sphx-glr-thumbcontainer" tooltip="Spikeinterface offers a very flexible framework to handle drift as a preprocessing step. If you...">
+    <div class="sphx-glr-thumbcontainer" tooltip="When running in vivo electrophysiology recordings, movement of the probe is an inevitability, e...">
 
 .. only:: html
 

doc/long_tutorials/handle_drift/handle_drift_python.zip

@@ -4,14 +4,14 @@
       "cell_type": "markdown",
       "metadata": {},
       "source": [
-        "\n# Handle motion/drift with spikeinterface NEW\n\nSpikeinterface offers a very flexible framework to handle drift as a preprocessing step.\nIf you want to know more, please read the\n`motion_correction` section of the documentation.\n\nHere is a short demo on how to handle drift using the high-level function\n:py:func:`~spikeinterface.preprocessing.correct_motion()`.\n\nThis function takes a preprocessed recording as input and then internally runs\nseveral steps (it can be slow!) and returns a lazy\nrecording that interpolates the traces on-the-fly to compensate for the motion.\n\nInternally this function runs the following steps:\n\n| **1.** ``localize_peaks()``\n| **2.** ``select_peaks()`` (optional)\n| **3.** ``estimate_motion()``\n| **4.** ``interpolate_motion()``\n\nAll these sub-steps can be run with different methods and have many parameters.\nThe high-level function suggests 3 pre-difined \"presets\".\n"
+        "\n# Handle motion/drift with spikeinterface NEW\n\nWhen running *in vivo* electrophysiology recordings, movement of the probe is\nan inevitability, especially when the subjects are not head-fixed. SpikeInterface\nincludes a number of popular methods to compensate for probe motion during the\npreprocessing step.\n\n### What is drift and where does it come from?\n\nMovement of the probe means that the spikes recorded on the probe 'drift' along it.\nTypically, this motion is vertical along the probe (along the 'y' axis) which\nmanifests as the units moving long the probe in space.\n\nAll common motion-correction methods address this vertical drift. Horizontal ('x')\nor forward/backwards ('z') motion, that would appear as the amplitude of a unit\nchanging over time, are much harder to model and not handled in available motion-correction algorithms.\nFortunately, vertical drift is the most common form of motion as the probe is\nmore likely to move along the path it was inserted, rather than in other directions\nwhere it is buffeted against the brain.\n\nVertical drift can come in two forms, 'rigid' and 'non-rigid'. Rigid drift\nis drift caused by movement of the entire probe and the motion is the\nsame for all points along the probe. Non-rigid drift is instead caused by\nlocal movement of parts of the brain along the probe, and can affect\nthe recording at only certain points along the probe.\n\n### How SpikeInterface handles drift\n\nSpikeinterface offers a very flexible framework to handle drift as a\npreprocessing step. In this tutorial we will cover the three main\ndrift-correction algorithms implemented in SpikeInterface with\na focus on running the methods and interpreting the output. For\nmore information on the theory and implementation of these methods,\nsee the `motion_correction` section of the documentation.\n\n### The drift correction steps\n\nThe easiest way to run drift correction in SpikeInterface is with the\nhigh-level :py:func:`~spikeinterface.preprocessing.correct_motion()` function.\nThis function takes a preprocessed recording as input and then internally runs\nseveral steps and returns a lazy recording that interpolates the traces on-the-fly\nto compensate for the motion.\n\nThe\n:py:func:`~spikeinterface.preprocessing.correct_motion()`\nfunction provides a convenient wrapper around a number of sub-functions\nthat together implement the full drift correction algorithm.\n\nInternally this function runs the following steps:\n\n| **1.** ``localize_peaks()``\n| **2.** ``select_peaks()`` (optional)\n| **3.** ``estimate_motion()``\n| **4.** ``interpolate_motion()``\n\nAll these sub-steps have many parameters which dictate the\nspeed and effectiveness of motion correction. As such, `correct_motion`\nprovides three setting 'presets' which configure the motion correct\nto proceed either as:\n\n* `rigid_fast` - a fast, not particularly accurate correction assuming ridigt drift.\n* `kilosort-like` - Mimics what is done in Kilosort (REF)\n* `nonrigid_accurate` - A decentralised drift correction, introduced by the Paninski group (REF)\n\n**Now, let's dive into running motion correction with these three\nmethods on a simulated dataset and interpreting the output.\n"
       ]
     },
     {
       "cell_type": "markdown",
       "metadata": {},
       "source": [
-        "FIRST WE IMPORT AND # We will use GENERATE RECORDINGS\n\n"
+        ".. seealso::\n    hello world\n\n"
       ]
     },
     {

doc/long_tutorials/handle_drift/images/sphx_glr_plot_handle_drift_001.png

@@ -2,16 +2,51 @@
 Handle motion/drift with spikeinterface NEW
 ===========================================
 
-Spikeinterface offers a very flexible framework to handle drift as a preprocessing step.
-If you want to know more, please read the
-:ref:`motion_correction` section of the documentation.
-
-Here is a short demo on how to handle drift using the high-level function
-:py:func:`~spikeinterface.preprocessing.correct_motion()`.
-
+When running *in vivo* electrophysiology recordings, movement of the probe is
+an inevitability, especially when the subjects are not head-fixed. SpikeInterface
+includes a number of popular methods to compensate for probe motion during the
+preprocessing step.
+
+### What is drift and where does it come from?
+
+Movement of the probe means that the spikes recorded on the probe 'drift' along it.
+Typically, this motion is vertical along the probe (along the 'y' axis) which
+manifests as the units moving long the probe in space.
+
+All common motion-correction methods address this vertical drift. Horizontal ('x')
+or forward/backwards ('z') motion, that would appear as the amplitude of a unit
+changing over time, are much harder to model and not handled in available motion-correction algorithms.
+Fortunately, vertical drift is the most common form of motion as the probe is
+more likely to move along the path it was inserted, rather than in other directions
+where it is buffeted against the brain.
+
+Vertical drift can come in two forms, 'rigid' and 'non-rigid'. Rigid drift
+is drift caused by movement of the entire probe and the motion is the
+same for all points along the probe. Non-rigid drift is instead caused by
+local movement of parts of the brain along the probe, and can affect
+the recording at only certain points along the probe.
+
+### How SpikeInterface handles drift
+
+Spikeinterface offers a very flexible framework to handle drift as a
+preprocessing step. In this tutorial we will cover the three main
+drift-correction algorithms implemented in SpikeInterface with
+a focus on running the methods and interpreting the output. For
+more information on the theory and implementation of these methods,
+see the :ref:`motion_correction` section of the documentation.
+
+### The drift correction steps
+
+The easiest way to run drift correction in SpikeInterface is with the
+high-level :py:func:`~spikeinterface.preprocessing.correct_motion()` function.
 This function takes a preprocessed recording as input and then internally runs
-several steps (it can be slow!) and returns a lazy
-recording that interpolates the traces on-the-fly to compensate for the motion.
+several steps and returns a lazy recording that interpolates the traces on-the-fly
+to compensate for the motion.
+
+The
+:py:func:`~spikeinterface.preprocessing.correct_motion()`
+function provides a convenient wrapper around a number of sub-functions
+that together implement the full drift correction algorithm.
 
 Internally this function runs the following steps:
 
@@ -20,12 +55,25 @@
 | **3.** ``estimate_motion()``
 | **4.** ``interpolate_motion()``
 
-All these sub-steps can be run with different methods and have many parameters.
-The high-level function suggests 3 pre-difined "presets".
+All these sub-steps have many parameters which dictate the
+speed and effectiveness of motion correction. As such, `correct_motion`
+provides three setting 'presets' which configure the motion correct
+to proceed either as:
+
+* `rigid_fast` - a fast, not particularly accurate correction assuming ridigt drift.
+* `kilosort-like` - Mimics what is done in Kilosort (REF)
+* `nonrigid_accurate` - A decentralised drift correction, introduced by the Paninski group (REF)
+
+**Now, let's dive into running motion correction with these three
+methods on a simulated dataset and interpreting the output.
+
 """
 
+
+
 # %%
-# FIRST WE IMPORT AND # We will use GENERATE RECORDINGS
+#.. seealso::
+#    hello world
 
 from pathlib import Path
 import matplotlib.pyplot as plt

doc/long_tutorials/handle_drift/images/sphx_glr_plot_handle_drift_002.png

@@ -6,7 +6,7 @@
 
 Computation times
 =================
-**42:27.561** total execution time for 1 file **from long_tutorials/handle_drift**:
+**00:00.000** total execution time for 1 file **from long_tutorials\handle_drift**:
 
 .. container::
 
@@ -33,5 +33,5 @@ Computation times
      - Time
      - Mem (MB)
    * - :ref:`sphx_glr_long_tutorials_handle_drift_plot_handle_drift.py` (``plot_handle_drift.py``)
-     - 42:27.561
+     - 00:00.000
      - 0.0