You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of now the timestamping is done on the OpenEphys side, we need to define the timestamps of incoming frames the moment they arrive to Bonsai to remove this variable latency.
This latency is not a problem on LED setups; however, we use DeepLabCut. Thresholding images is faster than GPU-based DNN predictions (DLC live benchmarks). We want to make sure that the latency introduced by DeepLabCut is inngeligible.
I was planning to work on a PR that allows an optional argument to be sent from Bonsai storing the timestamp the moment the frame arrives. What do you think about overloading the timestamp-generating function(s)?
The text was updated successfully, but these errors were encountered:
I don't have time to work on this unfortunately.
Feel free to make a PR! I'd be happy to review it ;)
I think that the best solution would be to store the Bonsai timestamp as an extra field in the binary message. This would allow, for posprocessing, to have both the OE timestamps and the Bonsai timestamps and to make benchmark comparisons.
As of now the timestamping is done on the OpenEphys side, we need to define the timestamps of incoming frames the moment they arrive to Bonsai to remove this variable latency.
This latency is not a problem on LED setups; however, we use DeepLabCut. Thresholding images is faster than GPU-based DNN predictions (DLC live benchmarks). We want to make sure that the latency introduced by DeepLabCut is inngeligible.
I was planning to work on a PR that allows an optional argument to be sent from Bonsai storing the timestamp the moment the frame arrives. What do you think about overloading the timestamp-generating function(s)?
The text was updated successfully, but these errors were encountered: