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
Either Nature Precedings, Biomed Central Research Notes, or supplemental info
We can cite it when mentioning algorithms we _didn't_ implement
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
Reference that tests with simulated data
Potentially cite papers that would have benefited from automated tracking
Can cite Rivera et al.
Without slamming people too much, note how people won't notice speed distributions
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
To be able to discuss systematic and random error
Demonstrate one result to show utility of software?
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 example, diagonal with smoothing
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?
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
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)
How is the data stored?, .dat files (columns) along with .ini saving set up parameters
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)
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 (?)
Should Andy data be in a different section than "prove?", We can put it in something like show it in action.
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.
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
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.
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