Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Tracking Software Paper Writing by Mind Map: Tracking Software Paper Writing
0.0 stars - 0 reviews range from 0 to 5

Tracking Software Paper Writing

We can call this the La-Z-boy graph

Systematic error 1 is the head/back part of lay-z-boy

Systematic error 2 is the lower legs / feet

Good data comes from the seat of our pants

Let's label potential figures with a yellow flag

References

Possible References

11. Helenius J, Brouhard G, Kalaidzidis Y, Diez S, Howard J (2006) The depolymerizing kinesin MCAK uses lattice diffusion to rapidly target microtubule ends. Nature 441(7089): 115–9., SJK: This paper's supplementary info describes tracking software from Howard Group

Degerman J, Thorlin T, Faijerson J, Althoff K, Eriksson PS, Put RVD, Gustavsson T (2009) An automatic system for in vitro cell migration studies. J. Microsc. 233: 178-191.

Cheezum MK, Walker WF, Guilford WH. (2001) Quantitative comparison of algorithms for tracking single fluorescent particles. Biophys. J. 81: 2378–2388.

Above are coming from the Chirico et al. paper. So, should double-check later to make sure we cite all that are relevant

Larry image simulation software

Either Nature Precedings, Biomed Central Research Notes, or supplemental info

The AFM DNA contour-length measuring paper steve found

We can cite it when mentioning algorithms we _didn't_ implement

Felix Ruhnow, David Zwicker, Stefan Diez paper, if they have one

We should send them preprint and ask them if they have something to cite

Possibly this one? http://www.ncbi.nlm.nih.gov.libproxy.unm.edu/pubmed/19367603

A snake contour paper, mentioning that we didn't implement it

Introduction

Need to collect literature to cite!

Reference that tests with simulated data

Potentially cite papers that would have benefited from automated tracking

Want to cite papers that would benefit from automated tracking

Can cite Rivera et al.

Without slamming people too much, note how people won't notice speed distributions

Abstract

Results/Discussion

March 4 Ideas

Two things that we learned and can teach people, 1. If calculating instantaneous speed (as opposed to fitting a trajectory), then pixel noise substantially increases perceived speed, Necessitates XY smoothing (in time), We developed a gaussian-weighted smoothing algorithm for this, Picking the smoothing time window is a user task, 2. A curved trajectory will underestimate speed (unless using some kind of shape-based trajectory fitting), unless sampling rate is high enough., The underestimation will be related to difference between chord length and arc length, Even if sampling rate is high enough, too much smoothing can cut corners and cause underestimation, These are two potential sources of systematic error that we let the user deal with. We can illustrate both of them via the "speed versus smoothing time" graph that we show the user at the top of the window., Larry's image simulation software is good for demonstrating this systematic error, as well as for exploring extent of random error

Results on simulated images

To be able to discuss systematic and random error

Results on real data

Demonstrate one result to show utility of software?

Figures we may use (not yet filed in a section of paper)

Flow chart for software, similar to Degerman 2009 Figure 2

Problem examples

Too much smoothing on circle

We can group several problems into one composite figure?

These are a general class of figures showing XY data. Another class of figures shows speed versus time. Another class shows speed versus smoothing window. I think we'll have many more XY-themed figures (showing tracks, etc.) than any other.

Good examples

Good example, diagonal with smoothing

Details of how it works

Flow chart a la Degerman

Image segmentation

Thresholding, etc., We can cite the exact LV algorithm(s) used, and list the parameters we tend to choose, and maybe offer a list of all the other possible parameters?

Tracking (one at a time, not automated)

Identification of objects, Depends on previous frame, right?, We use the bounding box of the previous to narrow the search for the object for the next frame. so there is a potential problem if the velocity is very large. I have never checked this and i guess i should

End-tracking, Pattern matching, Assignment of front / back

I think we should give a shout out to automation and say there is more info in the appendix or something

Speed calculation

Smoothing x(t); y(t), Describe gaussian window method, Describe auto end removal

Instantaneous speed calc, graph

Total mean speed, Graph of total mean speed versus smoothing window size (see la-z-boy figure)

Data storage

How is the data stored?, .dat files (columns) along with .ini saving set up parameters

File format

INI files?, Demonstrate that it's easy to replicate the analysis, based on INI files, This would be great thing to show in the cam studio

Append to array as well which saves as a .dat file (i gotta double check)

Acknowledgements

Haiqing and Gabe for kinesin

Funding

DTRA

INCBN

Other help with writing?

Prove it works

Simulated Images

What Images to make, Straight, Horizontal, Varying Background Noise, All other background noise to match Andy's images, Vertical, Diagonal, Round Edges, Circle, Varying Radii, No Velocity

Velocity: 5 frames/sec; 800 nm/sec; 184 nm/pixel, x pixels/frame, I got .87 pixels/frame. 1.74 in high res/frame, I'll use 2 to make sure program does round it off and ruin the the actual velocity

want to take out certain frames and thus speed up the velocity. show when this fails. also show that the speed we get is lower than expected (for curved paths)

This data would probably be best shown in a table. What info should be in there? Trajectory, tracked velocity (actual velocity and length are the same for all .pngs) # of frames tracked over (?)

Andy Data

Should Andy data be in a different section than "prove?", We can put it in something like show it in action.

All test data should go in webpub folders

Can have a .zip file to preserve a heirarchy. Use a file folder like C:\Testimages\ or something so we can make the software distribution default to those directories.

How do I get it and use it?

Need a help text file

Probably a camstudio will be needed as well, SJK: How much is the better version of cam studio (academic license)? Would it be worth it?

A text file. or something i think we can make something in labview i am not sure though.

SJK: Agree. The better instructions and documentation are, the more likely someone will actually use it, Also need to include test data and results

Need to decide on code repository. Google or SourceForge likely.

Sourceforge can work with LabVIEW definitely

Google may work with LabVIEW, probably easier to use than sourceforge?

Either way, looks like we'll need to use subversion, which luckily Caleb already installed. Will take Larry & Steve probably several hours to figure out how to do this, but worthwhile to learn for all the other projects.

Need to include _all_ test data somehow. A zip file w/ heirarchy seems best.

Paper outline

SJK 3/8/10: We're still not sure how to outline the paper.

Would like the "does it work" to be obvious.

Would like the "how does it work" to be easy to skip over if people don't care.

Would like the "how do I get it / use it?" to be obvious

We both agree now that the fully automated should be an appendix, showing a figure with the automatically tracked colored tracks

Entire whiteboard photo from this evening