User:TheLarry/Notebook/Larrys Notebook/2010/03/03

{| width="800"
 * style="background-color: #EEE"|[[Image:owwnotebook_icon.png|128px]] Tracking
 * style="background-color: #F2F2F2" align="center"|  |Main project page
 * style="background-color: #F2F2F2" align="center"|  |Main project page


 * colspan="2"|
 * colspan="2"|

Simulated Images
I ran the movie i made yesterday and the velocity it spat out was 4.98/4.96 (front/back). The actual velocity was 5.00 (pixels/frame). I don't think that is too bad.
 * Steve Koch 11:29, 3 March 2010 (EST): That's great! So it seems like always we're systematically a bit low.  Probably from smoothing.  But if we don't smooth, we're systematically much too high.  At this point, I don't know how to deal with that, except to make sure to note it in our reports.  It's a small amount.  Can you post screen shot of velocity software for this data set when you get a chance?  Also, you should put the image series in web pub so other people can access it and link it here.
 * TheLarry 11:33, 3 March 2010 (EST): It is fairly obvious I guess but i ran this with less background noise and a brighter microtubule and a faster velocity (7.5 pixels/frame). But since i ran it with a higher velocity i had less images. There were 45 for the above example and 24 for the faster microtubule. The tracking showed a velocity of 7.42/7.44. I want to attribute it to just less images to analyze so a greater variance. So I am running the brighter, faster microtubule now with a larger image. I'll post how that goes.

I ran the tracking with 54 images and it gave a velocity of 7.47/7.47. The real velocity was 7.50. I ran that same image directory but only tracking the first 24 images and it gave a velocity of 7.43/7.42. So it is just a sampling size thing. Andy only keeps microtubules that he can track for >100 images (i think he does 150 actually but i am not sure). We might want to think about adding something to look at the variance.

http://kochlab.org/files/Simulated%20Images
 * Here is a link to the image directories i used to create this data.

I tracked this trajectory (seen to the right). There some bad points in the middle because the tracking didn't handle the sharp angle turn the microtubule made into the circle well. When i ran the velocity for all the data (138 points) it gave a velocity of 1.1 intsead of 1.0. But when i rand it on the 80 points before the circle it gave 1.01/1.00. So that is encouraging. I don't worry about it losing those sharp angle turns since that doesn't happen in real life. I can try to send the microtubule into the circle at a better angle and see if it handles that well. Also a giant circle may be helpful.

I ran a long slanted line and it said the velocity was 1.00/1.00. So many points is looking pretty good. I am running a gigantic circle right now

I ran the circle. 389 images. Supposed to have a velocity of 1.50. The tracking software gave 1.50/1.51. Everything is looking pretty good. Knock on wood. Except of course for those bad points above but some one better at smoothing might be able to handle them.
 * Steve Koch 22:34, 3 March 2010 (EST): Looks very good! I don't think the smoothing can deal with bad points, actually.  We didn't re-implement that feature, because bad points stopped happening.  Anyway, this is awesome.  I'm thinking about what actually you need to do to put in the tracking publication.  Tough because it's working so well.  What can we do with the simulation to tell us something about when the tracking doesn't work?  I suppose saying how much curvature is tolerable before smoothing causes underestimation?  We can think about this some more.  As for what would you need to do to publish this as a simulation software paper?  User-friendly type stuff (like w/ tracking, INI, etc.). A great first step would be to add your application to the visual source safe to make sure this working version never goes away!
 * TheLarry 22:53, 3 March 2010 (EST): I look forward to talking about what we have to do for the tracking software. I figure we gotta do high noise background, less intensity, and other things. But we'll talk about it later. Possibly least amount of images before velocity becomes crap (possibly watch variance too). Anyways, for this image simulation it might be better as an in depth supplemental data. There is a lot of work to make the image simulation user friendly. The .ini will be a help. Whatever i have to think about it. But it might be good a supplemental data unless you think i should work at making it another paper.


 * }