nppc-uk / ct_scanner_plotting Goto Github PK

We have the major and minor axis diameters at every z height. Using the major axis diameter naively as pod width is probably fine. A refinement:

1. Calculate the angle of the pod with respect to the central axis of the scanneras a function of z height. This will be two angles, the inclination and the in what direction it is inclined.
2. Correct the major axis diameter to account for the fact that we are not measuring the minimal distance across the pod.

This would require getting not just major and minor axis diameters, but also their orientation.

Originally posted by @maxf130 in #2 (comment)

Absolute numbers are problematic when dimensions might be scaled arbitrarily. We should make all parameters relative to the pod length or something.

We now have access to the pod width at all z heights. Plot it against other parameters, output it in pod data.

We should try to have a more intelligent approach to filtering seeds. We have tried:

• Removing seeds that are implausibly close to the ends of the pod
• Removing seeds that have an implausibly large diameter relative to the size
  of the pod at that point

Both of these approaches suffer from the problem of selecting the threshold.
Just how close is implausible, just how large is implausible.

We should try:

• Model the distribution of grains as a sum of two gaussians (I think this
  is a mixture model). There is some noise at the end of the beak, and then the
  remaining grains. It should be possible to distinguish between the two groups.
• A more complicated model, with uniform distribution in the pod and gaussian noise at beak tips.
• K-Means clustering
• Kernel density estimation - breaking at minimal kernel density
• Jenks natural breaks optimization
• Expectation-maximization algorithm

Debugging plots introduced in SHA1: 0edefdf have proven popular. Should include these poperly in the code.

I don't know what the problem is, but it needs fixing.

The plot of correlations between properties is wierd:

Where the beak meets the silique in a brassica pod, there is usually a step in the gradient. We could look for it, and used it to calculate the beak length.

For some reason performance goes down when using parallel maps, by at least a factor of ten. I've disabled the use of parallel maps in SHA: 70c0b66

Internally data is stored in three lists.

• A list of all pods
• A list of all plants, which contains a list of pods
• A list of all gentotypes, which contains a list of all plants, which contains a list of all pods

Ideally all the pod objects should resolve to the same memory address. We do not wan't to create 3 copies of everything. I think the copying is what is currently happening. That should be investigated.

Integrate along the curve of the pod to find the length

Since the success of filtering of noise in #1, we now have access to good estimates of silique and beak length. We should plot those and output them in the combined stats.