fix(dependencies): Switch from catch22 to pycatch22

See merge request postprocessor!19

WHY IS THIS CHANGE NEEDED?:
- catch22 developers deleted it from pyPI and moved it to pycatch22

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- used poetry to remove catch22 and add pycatch22
- updated the only thing in postprocesses that depends on catch22

REFERENCES:
- issue #26

feat(core): Butterworth filter

See merge request postprocessor!18

Change behaviour of detrend process

See merge request postprocessor!17

WHY IS THIS CHANGE NEEDED?:
- Sliding window detrending imposes oscillations onto time series.
  The period of these oscillations is determined by the size of the
  window.
- I discovered this by varying the window size on my analysis of real data.

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- Re-defined the window size to match the period of a cell division
  cycle/yeast metabolic cycle under favourable conditions, assuming
  image sampling every 5 minutes (most common setting).  Detrend process
  is used mainly in pre-processing to study biological oscillations --
  the process removes long-term trends that may obscure these
  oscillations.
- Changing the default parameter value does not solve the problem per
  se, but if the window size corresponds to the oscillation frequency,
  it will only reinforce these oscillations.

WHAT SIDE EFFECTS DOES THIS CHANGE HAVE?:
- Will change behaviour of skeletons scripts that rely on detrend,
  especially when no parameter value is defined.  Users have to be aware
  of the new default value and may have to adjust the parameter value to
  suit their data.

REFERENCES:
- Issue #22

WHY IS THIS CHANGE NEEDED?:
- process currently first normalises by dividing by mean -- not strictly
  part of detrending
- process divides normalised time series by moving average -- difficult
  to justify as poor evidence for signal's trend being multiplicative to
  phenomenon of interest

HOW DOES THE CHANGE SOLVE THE PROBLEM?:
- remove normalising step
- subtract moving average instead of dividing

WHAT SIDE EFFECTS DOES THIS CHANGE HAVE?:
- change is not backwards compatible
- does not affect aliby, agora, or the rest of postprocessor as none
  depend on detrend
- will affect skeletons/arin as modules & scripts rely on detrending as
  part of time series pre-processing -- but qualitatively little changes

EVIDENCE THAT COMMIT WORKS:
- testing on skeletons/arin/strain report script and inspecting output
  plots -- still makes sense

REFERENCES:
- issue #22

refactor(core): Simplify detrend process

See merge request postprocessor!16

- clarify definition of signal_detrend

WHY IS THIS CHANGE NEEDED:
- logical steps of computation unclear, therefore unclear if
  result of computation is what we want

HOW DOES THE CHANGE SOLVE THE PROBLEM:
- replace moving_average() and lines 74-76 with pandas.DataFrame
  methods -- simplifies code; standardised routines
- rename variables so they are more informative

EVIDENCE THAT COMMIT WORKS:
- generate random DataFrame, original & new implementation produce
  same outputs

REFERENCES:
- Issue #21

[plotting routines] Fix x-axis ticks and repurpose sampling factor argument for unit scaling

See merge request postprocessor!15

Heatmap added x-ticks based on the time points, not absolute time.

When a DataFrame is passed into matplotlib.imshow, the Axes no longer
cares about the column names.  We want the plot to take into account the
sampling period AND the unit scaling if the user specifies one.

I copied over the method I implemented for boxplot.py -- it essentially
'tricks' matplotlib by redefining the labels rather than change the
time-axis values (see
https://stackoverflow.com/questions/10171618/changing-plot-scale-by-a-factor-in-matplotlib).
matplotlib's xscale does not support simple linear re-scaling; in any
case, having time-axis values does not make sense for imshow.

This commit addresses issue #20.

Repurpose sampling_period for unit scaling, as in
b6575f25

This commit addresses issue #20.

Specifying a sampling period via the sampling_period argument duplicated
multiplying the horizontal axes by a scaling factor.

This is because recent changes to postprocessor (see last paragraph of
commit) makes the columns of DataFrames show absolute time units (e.g. [0, 5,
10, 15...] if the images were taken every 5 minutes).  Previously,
columns showed time points (e.g. [0, 1, 2, 3...]).  All routines relied
on column labels to define the horizontal axis.  This issue would
have been addressed more timely if the commit in question had a more
informative description; 'add tiniterval property' tells me nothing and
does not inform me that it affects the column labels.

These recent changes mean that the sampling_period argument is no longer
necessary.  However, instead of deleting this argument, I've decided to
repurpose it for unit scaling, e.g. from minutes to hours.
Operationally, nothing has changed, but the meaning of the argument has
changed, and I've updated the docstrings accordingly.

This commit may affect horizontal axes of plots affected; users should
inspect the axes carefully, especially if the source data relies on
postprocessor.grouper.

This bug was likely caused by 17e13b59
on 2022-06-16 14:21.  It is unclear from the commit message, but I
suspect that this commit attempted to incorporate the image sampling
interval into defining the DataFrame columns produced by postprocessor.
This commit addresses issue #20.

[routines/heatmap] Refactor: change how x-ticks are defined

Closes #19

See merge request postprocessor!14

When the user defines xtick_step and sampling_period so that
sampling_period is not divisible by xtick_step, an error is shown.
Specifically:

    int(np.where(time_axis == label)[0].item()) for label in xticklabels
ValueError: can only convert an array of size 1 to a Python scalar

The routine assumed that all instances of label (line 66) can be found
in time_axis (defined in line 61).  This is not true when
sampling_period is not divisible by xtick_step -- as an example:

Suppose time_axis is: [0, 1, 2, 3, 4, 5, 6, 7]
And xtick_step is 0.6.
xtick_min is thus defined as 0 and xtick_max is thus defined as 7.2, as
expected.
xticklabels is then defined as [0, 0.6, 1.2, 1.8, ... 7.2]
In the list comprehension that defines self.xticks, label first acquires
the value of 0.  This results in no errors as time_axis contains a 0.
However, when label then acquires the value of 0.6, the ValueError is
returned because time_axis does not contain a 0.6.

Fortunately, Axes.xaxis.set_major_locator() does all this for me, so I
scrapped the original method of defining horizontal axis for this.  I
had originally written the lines to define the horizontal axis when I
didn't know that set_major_locator() existed, and tried to define the
x-ticks manually.

These changes should not affect the behaviour of heatmap apart from
cases that cause the error.

This commit fixes issue #19.

Add plotting routines

See merge request postprocessor!10

So that:
- developers can understand the logic and write new routines that
  confirm (or something else otherwise)
- Sphinx documentation displays the description; this helps users
  and developers understand the routines

Addresses postprocessor!10 (comment 94319)

Cross-corr process computes std dev over time for each replicate

See merge request postprocessor!13

Merge branch 'plotting-routines' of git.ecdf.ed.ac.uk:swain-lab/aliby/postprocessor into plotting-routines

Merge branch 'plotting-routines' of git.ecdf.ed.ac.uk:swain-lab/aliby/postprocessor into plotting-routines

knngraph process constructs a geometric graph based on nearest neighbours

See merge request postprocessor!11