1. References
1.1. Possible References
1.1.1. 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.
1.1.1.1. SJK: This paper's supplementary info describes tracking software from Howard Group
1.1.2. 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.
1.1.3. Cheezum MK, Walker WF, Guilford WH. (2001) Quantitative comparison of algorithms for tracking single fluorescent particles. Biophys. J. 81: 2378–2388.
1.1.4. Above are coming from the Chirico et al. paper. So, should double-check later to make sure we cite all that are relevant
1.2. Larry image simulation software
1.2.1. Either Nature Precedings, Biomed Central Research Notes, or supplemental info
1.3. The AFM DNA contour-length measuring paper steve found
1.3.1. We can cite it when mentioning algorithms we _didn't_ implement
1.4. Felix Ruhnow, David Zwicker, Stefan Diez paper, if they have one
1.4.1. We should send them preprint and ask them if they have something to cite
1.4.2. Possibly this one? http://www.ncbi.nlm.nih.gov.libproxy.unm.edu/pubmed/19367603
1.5. A snake contour paper, mentioning that we didn't implement it
2. Introduction
2.1. Need to collect literature to cite!
2.1.1. Reference that tests with simulated data
2.1.2. Potentially cite papers that would have benefited from automated tracking
2.2. Want to cite papers that would benefit from automated tracking
2.2.1. Can cite Rivera et al.
2.2.2. Without slamming people too much, note how people won't notice speed distributions
3. Abstract
4. Acknowledgements
4.1. Haiqing and Gabe for kinesin
4.2. Funding
4.2.1. DTRA
4.2.2. INCBN
4.3. Other help with writing?
5. Prove it works
5.1. Simulated Images
5.1.1. What Images to make
5.1.1.1. Straight
5.1.1.1.1. Horizontal
5.1.1.1.2. Vertical
5.1.1.1.3. Diagonal
5.1.1.2. Round Edges
5.1.1.3. Circle
5.1.1.3.1. Varying Radii
5.1.1.4. No Velocity
5.1.2. Velocity: 5 frames/sec; 800 nm/sec; 184 nm/pixel, x pixels/frame
5.1.2.1. I got .87 pixels/frame. 1.74 in high res/frame
5.1.2.1.1. I'll use 2 to make sure program does round it off and ruin the the actual velocity
5.1.3. 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)
5.1.4. 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 (?)
5.2. Andy Data
5.2.1. Should Andy data be in a different section than "prove?"
5.2.1.1. We can put it in something like show it in action.
5.3. All test data should go in webpub folders
5.3.1. 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.
6. How do I get it and use it?
6.1. Need a help text file
6.1.1. Probably a camstudio will be needed as well
6.1.1.1. SJK: How much is the better version of cam studio (academic license)? Would it be worth it?
6.1.2. A text file. or something i think we can make something in labview i am not sure though.
6.1.3. SJK: Agree. The better instructions and documentation are, the more likely someone will actually use it
6.1.3.1. Also need to include test data and results
6.2. Need to decide on code repository. Google or SourceForge likely.
6.2.1. Sourceforge can work with LabVIEW definitely
6.2.2. Google may work with LabVIEW, probably easier to use than sourceforge?
6.2.3. 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.
6.3. Need to include _all_ test data somehow. A zip file w/ heirarchy seems best.
7. Paper outline
7.1. SJK 3/8/10: We're still not sure how to outline the paper.
7.1.1. Would like the "does it work" to be obvious.
7.1.2. Would like the "how does it work" to be easy to skip over if people don't care.
7.1.3. Would like the "how do I get it / use it?" to be obvious
7.1.4. We both agree now that the fully automated should be an appendix, showing a figure with the automatically tracked colored tracks
7.1.5. Entire whiteboard photo from this evening
8. We can call this the La-Z-boy graph
8.1. Systematic error 1 is the head/back part of lay-z-boy
8.2. Systematic error 2 is the lower legs / feet
8.3. Good data comes from the seat of our pants
8.4. Let's label potential figures with a yellow flag
9. Results/Discussion
9.1. March 4 Ideas
9.1.1. Two things that we learned and can teach people
9.1.1.1. 1. If calculating instantaneous speed (as opposed to fitting a trajectory), then pixel noise substantially increases perceived speed
9.1.1.1.1. Necessitates XY smoothing (in time)
9.1.1.2. 2. A curved trajectory will underestimate speed (unless using some kind of shape-based trajectory fitting), unless sampling rate is high enough.
9.1.1.2.1. The underestimation will be related to difference between chord length and arc length
9.1.1.2.2. Even if sampling rate is high enough, too much smoothing can cut corners and cause underestimation
9.1.1.3. 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.
9.1.1.4. Larry's image simulation software is good for demonstrating this systematic error, as well as for exploring extent of random error
9.2. Results on simulated images
9.2.1. To be able to discuss systematic and random error
9.3. Results on real data
9.3.1. Demonstrate one result to show utility of software?
10. Figures we may use (not yet filed in a section of paper)
10.1. Flow chart for software, similar to Degerman 2009 Figure 2
10.2. Problem examples
10.2.1. Too much smoothing on circle
10.2.2. We can group several problems into one composite figure?
10.2.3. 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.
10.3. Good examples
10.3.1. Good example, diagonal with smoothing
11. Details of how it works
11.1. Flow chart a la Degerman
11.2. Image segmentation
11.2.1. Thresholding, etc.
11.2.1.1. 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?
11.3. Tracking (one at a time, not automated)
11.3.1. Identification of objects
11.3.1.1. Depends on previous frame, right?
11.3.1.1.1. 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
11.3.2. End-tracking
11.3.2.1. Pattern matching
11.3.2.2. Assignment of front / back
11.3.3. I think we should give a shout out to automation and say there is more info in the appendix or something
11.4. Speed calculation
11.4.1. Smoothing x(t); y(t)
11.4.1.1. Describe gaussian window method
11.4.1.2. Describe auto end removal
11.4.2. Instantaneous speed calc, graph
11.4.3. Total mean speed
11.4.3.1. Graph of total mean speed versus smoothing window size (see la-z-boy figure)
11.5. Data storage
11.5.1. How is the data stored?
11.5.1.1. .dat files (columns) along with .ini saving set up parameters
11.5.2. File format
11.5.3. INI files?
11.5.3.1. Demonstrate that it's easy to replicate the analysis, based on INI files
11.5.3.1.1. This would be great thing to show in the cam studio
11.5.4. Append to array as well which saves as a .dat file (i gotta double check)