Create simplification routine for rendering visualization of worm

[MichaelCurrie]

In our public-facing site exposing the worm database, it will be nice if we can support a short sample or visualization of the worm file bring requested. Such a visualization is possible with client-side js libraries like d3.js or paper.js, however, passing many megabytes of worm data for a simple visualization is too much.

https://bl.ocks.org/mbostock/1136236 http://paperjs.org/examples/tadpoles/

So a lossy compression method would be desirable.

[Ichoran]

I'm not sure how this is a Tracker Commons issue.

[MichaelCurrie]

I was thinking it would become part of the API for the Python implementation, transforming a WCON object into a simpler one.

So if w is our WCONWorms object, you would call w2 = w.simplify_lossy() to obtain a compressed version.

- `simplify_lossy`
  - [property]
  - returns: a copy of this object but compressed form

This way, a 70mb file could be transformed perhaps into a 70kb file.

As I write this, I am thinking of various ways a compression might be achieved, if the only goal is to preserve a human-appreciable rendering of the worm's movements:

• Linear interpolations between time points could be compared to the real data and if the difference falls below a given threshold, the unnecessary frame could be dropped.
• Worm's body is a continuous perimeter around a relatively invariant area. Could be represented by a Bézier curve.
• We can already isolate the worm's body from the worm's Euclidean translation around the arena (via the centroid)
• The array of centroid coordinates can be further simplified since the coordinates are arranged in a sequence. Again this could be approximated with a piecewise bezier curve or other method.

This is an enhancement, not a requirement, but I needed a place to capture my thoughts about this.

[Ichoran]

I would have thought that this was the kind of analysis you'd want to use the full analysis toolbox on, where you presumably already have useful things to deal with curves and PCA and so on. So you'd want to take in and put out WCON, but does it really make sense in the basic repository? It is a continuum, of course, but this seems like a pretty advanced operation conceptually.

[cheelee]

I'm thinking along the same lines as @Ichoran here - in my mind, WCON ought to stay purely an I/O interface library. An OWAT tool could then take a WCON file containing point-data and convert it into a lossy form and vice-versa. I believe the WCON schema will have to change to accommodate this form of worm posture representation?

[Ichoran]

If Bezier curves are out and only splines are in, then you only need a metadata field to explain that the shapes are in fact splined. Everything else is just interpolation between the data points you've already got. If we did want Bezier curves, the control points could go in custom code, leaving the actual points there making a lousy-looking but not wholly ridiculous spine.

[Ichoran]

@MichaelCurrie - Would a metadata field "spline" which is an object with fields of "spine" and "perimeter", each of which is a number saying what is the degree is of an approximating spline going through the points, be enough so an external tool could create compressed data that wasn't completely hopeless? E.g.

"spline": { "spine":1, "perimeter":0 }

would be the default assumption for a pixel-walk based perimeter. If there is a tail index in the perimeter, then the spline is expected to be broken there.

[MichaelCurrie]

1. I concede to you guys to put this somewhere else. I'm not sure it belongs in OWAT either so I'll just develop privately until I have something. I will close this issue here.

2. On how to implement splines (or Bézier curves), I'm studying these and as far as I understand:

A spline is a piecewise polynomial real function on a closed interval, consisting of k subintervals, such that each subinterval boundary point k is continuous and continuously differentiable to order n(k)-1, where n is the order of the polynomial of the kth subinterval.

A single Bézier curve is a special case of a spline, consisting of just 1 subinterval, and typically of order 2 or 3, using "control points" and "Bernstein polynomials" to characterize the polynomial curve parametrically.

Using splines, in particular, defining the splines by interpolation between control points, seems like the right way to go here since it avoids Runge's phenomenon of high-order polynomials being unstable.

The way to do this in Python is (from http://stackoverflow.com/a/31544486/1832942):

import numpy as np
from scipy import interpolate

def f(x):
    x_points = [ 0, 1, 2, 3, 4, 5]
    y_points = [12,14,22,39,58,77]

    tck = interpolate.splrep(x_points, y_points)
    return interpolate.splev(x, tck)

print f(1.25)

[MichaelCurrie]

It would be interesting to characterize how much the worm features change if the WCON file is converted into this lossy spline-based format, and then converted out again, depending on how many control points are used. (this would help to answer how many control points are necessary)

This is admittedly a different question to how many control points are needed to preserve the human-visible "look" of a worm for a UI widget.