1. We can call this the La-Z-boy graph
1.1. Systematic error 1 is the head/back part of lay-z-boy
1.2. Systematic error 2 is the lower legs / feet
1.3. Good data comes from the seat of our pants
1.4. Let's label potential figures with a yellow flag
2. References
2.1. Possible References
2.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.
2.1.1.1. SJK: This paper's supplementary info describes tracking software from Howard Group
2.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.
2.1.3. Cheezum MK, Walker WF, Guilford WH. (2001) Quantitative comparison of algorithms for tracking single fluorescent particles. Biophys. J. 81: 2378–2388.
2.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
2.2. Larry image simulation software
2.2.1. Either Nature Precedings, Biomed Central Research Notes, or supplemental info
2.3. The AFM DNA contour-length measuring paper steve found
2.3.1. We can cite it when mentioning algorithms we _didn't_ implement
2.4. Felix Ruhnow, David Zwicker, Stefan Diez paper, if they have one
2.4.1. We should send them preprint and ask them if they have something to cite
2.4.2. Possibly this one? http://www.ncbi.nlm.nih.gov.libproxy.unm.edu/pubmed/19367603
2.5. A snake contour paper, mentioning that we didn't implement it
3. Introduction
3.1. Need to collect literature to cite!
3.1.1. Reference that tests with simulated data
3.1.2. Potentially cite papers that would have benefited from automated tracking
3.2. Want to cite papers that would benefit from automated tracking
3.2.1. Can cite Rivera et al.
3.2.2. Without slamming people too much, note how people won't notice speed distributions
4. Abstract
5. Results/Discussion
5.1. March 4 Ideas
5.1.1. Two things that we learned and can teach people
5.1.1.1. 1. If calculating instantaneous speed (as opposed to fitting a trajectory), then pixel noise substantially increases perceived speed
5.1.1.1.1. Necessitates XY smoothing (in time)
5.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.
5.1.1.2.1. The underestimation will be related to difference between chord length and arc length
5.1.1.2.2. Even if sampling rate is high enough, too much smoothing can cut corners and cause underestimation
5.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.
5.1.1.4. Larry's image simulation software is good for demonstrating this systematic error, as well as for exploring extent of random error
5.2. Results on simulated images
5.2.1. To be able to discuss systematic and random error
5.3. Results on real data
5.3.1. Demonstrate one result to show utility of software?
6. Figures we may use (not yet filed in a section of paper)
6.1. Flow chart for software, similar to Degerman 2009 Figure 2
6.2. Problem examples
6.2.1. Too much smoothing on circle
6.2.2. We can group several problems into one composite figure?
6.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.
6.3. Good examples
6.3.1. Good example, diagonal with smoothing
7. Details of how it works
7.1. Flow chart a la Degerman
7.2. Image segmentation
7.2.1. Thresholding, etc.
7.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?
7.3. Tracking (one at a time, not automated)
7.3.1. Identification of objects
7.3.1.1. Depends on previous frame, right?
7.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
7.3.2. End-tracking
7.3.2.1. Pattern matching
7.3.2.2. Assignment of front / back
7.3.3. I think we should give a shout out to automation and say there is more info in the appendix or something
7.4. Speed calculation
7.4.1. Smoothing x(t); y(t)
7.4.1.1. Describe gaussian window method
7.4.1.2. Describe auto end removal
7.4.2. Instantaneous speed calc, graph
7.4.3. Total mean speed
7.4.3.1. Graph of total mean speed versus smoothing window size (see la-z-boy figure)
7.5. Data storage
7.5.1. How is the data stored?
7.5.1.1. .dat files (columns) along with .ini saving set up parameters
7.5.2. File format
7.5.3. INI files?
7.5.3.1. Demonstrate that it's easy to replicate the analysis, based on INI files
7.5.3.1.1. This would be great thing to show in the cam studio
7.5.4. Append to array as well which saves as a .dat file (i gotta double check)
8. Acknowledgements
8.1. Haiqing and Gabe for kinesin
8.2. Funding
8.2.1. DTRA
8.2.2. INCBN
8.3. Other help with writing?
9. Prove it works
9.1. Simulated Images
9.1.1. What Images to make
9.1.1.1. Straight
9.1.1.1.1. Horizontal
9.1.1.1.2. Vertical
9.1.1.1.3. Diagonal
9.1.1.2. Round Edges
9.1.1.3. Circle
9.1.1.3.1. Varying Radii
9.1.1.4. No Velocity
9.1.2. Velocity: 5 frames/sec; 800 nm/sec; 184 nm/pixel, x pixels/frame
9.1.2.1. I got .87 pixels/frame. 1.74 in high res/frame
9.1.2.1.1. I'll use 2 to make sure program does round it off and ruin the the actual velocity
9.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)
9.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 (?)
9.2. Andy Data
9.2.1. Should Andy data be in a different section than "prove?"
9.2.1.1. We can put it in something like show it in action.
9.3. All test data should go in webpub folders
9.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.
10. How do I get it and use it?
10.1. Need a help text file
10.1.1. Probably a camstudio will be needed as well
10.1.1.1. SJK: How much is the better version of cam studio (academic license)? Would it be worth it?
10.1.2. A text file. or something i think we can make something in labview i am not sure though.
10.1.3. SJK: Agree. The better instructions and documentation are, the more likely someone will actually use it
10.1.3.1. Also need to include test data and results
10.2. Need to decide on code repository. Google or SourceForge likely.
10.2.1. Sourceforge can work with LabVIEW definitely
10.2.2. Google may work with LabVIEW, probably easier to use than sourceforge?
10.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.
10.3. Need to include _all_ test data somehow. A zip file w/ heirarchy seems best.
11. Paper outline
11.1. SJK 3/8/10: We're still not sure how to outline the paper.
11.1.1. Would like the "does it work" to be obvious.
11.1.2. Would like the "how does it work" to be easy to skip over if people don't care.
11.1.3. Would like the "how do I get it / use it?" to be obvious
11.1.4. We both agree now that the fully automated should be an appendix, showing a figure with the automatically tracked colored tracks
11.1.5. Entire whiteboard photo from this evening