-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question regarding max_velocity_detector and velocity correction #7
Comments
On a sidenote, can this https://github.com/gilestrolab/ethoscope/blob/0567585158ff3a51ea998faa97a8d60285711163/src/ethoscope/trackers/adaptive_bg_tracker.py#L468 Correct me if I am wrong, but that would then mean that different ROIs require different correction coefficients? |
max_velocity_detector
and velocity correction
Hi @antortjim, Yes, the threshold/correction will need to be scaled by ROI size. ROI size is the only stable reference we had since ethoscopes can be used at higher/lower magnifications (so it is hard to convert pixels to actual distances). I hope it makes some sort of sense! |
Hi @qgeissmann Regarding the addition of an extra pixel, since the ROI width is around 457 pixels (as shown in the ROI_MAP table), that means that adding 1 pixel to all measurements implies the ROI-width-scaled distance gets increased 1/457 = 0.0021. Since the threshold is 0.003 (default velocity correction coeff.), this means that the activity threshold on the actual activity of the fly is 0.003 - 0.0021 < 0.001, i.e. < 0.1% of the width of the ROI. We are trying now to compute the distance also offline in R, using the X and Y columns of the ROI_X tables. I wrote a new class in variables.py that admits float data. Using these X, Y data with float precision, the distance can be computed like this:
Using this approach, the results should be identical if I decrease the velocity correction coefficient to match 0.003 - one pixel, right? Please let me know if my conclusions are wrong! Thank you very much, Antonio |
Dear Gilestro lab
Thank you for developing sleepr and making it publicly available for free. It’s great!
I had a question regarding your max_velocity_detector annotation function, which you use in sleep_annotation to determine the level of activity of a fly in
time_window_length
seconds.The logic you implement consists of retrieving the distance computed live on the ethoscopes, and you then divide by the time passed since the previous frame. This time difference is expressed in the
dt
column, which you compute in the beginning of the functionsleepr/R/motion_detectors.R
Line 44 in 59949e3
With the distance and the time difference, you then can compute a velocity
sleepr/R/motion_detectors.R
Line 47 in 59949e3
In the next lines you simulate beam crosses and mask behavior if an interaction occurs, which is not relevant for my question.
The next relevant line is the following:
sleepr/R/motion_detectors.R
Line 74 in 59949e3
Which according to the supplementary material in your PLOS One article https://journals.plos.org/plosbiology/article/file?id=10.1371/journal.pbio.2003026.s005&type=supplementary is designed to correct for the problem
i.e. you correct the velocity taking into account the FPS.
However, by having a close look to the code, I would argue that what you effectively do is instead getting the distance again and then normalizing with a. The result of this operation is called
velocity_corrected
, but it is basically a distance normalized by a. You then select the maximum value intime_window_length
and if the maximum is bigger than 1 i.e. the original distancedist
is greater than a, the fly is annotated as moving for that block of time, and not moving otherwise.Wouldn’t it be more correct to omit line 74 and just check if the velocity is greater than a? Or maybe divide again by dt (and not multiply). Under my reasoning, the fact that the velocity is multiplied with dt does not only not correct the velocity but also makes the time between frames irrelevant because it takes the magnitudes to the distance space, and not the velocity space.
This question is related to issue gilestrolab/ethoscope#97 in the ethoscope repository. We are trying to find what is the problem and misannotation could be one of the culprits.
Once again, thank you very much!
Best,
Antonio
The text was updated successfully, but these errors were encountered: