Restrict IDs to ROI in masks with multiple ROIs / allow user defined "Look back (frames)" #32
Comments
|
@ayexander I can look into trying to restrict tracks to ROIs but that won't be straightforward and I won't have time to look into this before a couple of months at least. This being said, your choice of parameters is part of the issue I think. I should document that better but the "Maximum Distance" parameter is per frame. This means that if it is set to 30 pixels, trackR will consider all past tracks that end within 30 pixels in the immediately previous frame, within 60 pixels 2 frames back, within 90 pixels 3 frames back, etc. With such a wide "Maximum Distance" and "Look Back", you're bound to see the large jumps that you describe. I recommend setting the "Maximum Distance" to between 1.5 and 2 times the maximum expected distance moved by an ant between two frames (in your case, I'm guessing it will be something like 1.5 * 10 pixels at most), and "Look Back" to only a few frames, assuming that ants are consistently detected when in the field of view. I'd be happy to have a quick video chat with you to help you identify the best tracking parameters. |
|
Hi Simone,
Thanks for considering this, and no problem regarding the time or complication to implement it (if possible without major work).
Thanks for your suggestions! I understand now that the Max Distance is a multiplier to the Look Back frames. The current settings I’ve used with Look Back = 150 and Max Distance up to 30 pixels gives me a nice number of final tracks of 24 - 27 in most cases (where I expect 24), despite some ROI jumps. Reducing Look back to even 50 or less often gives me hundreds of tracks. This is because O. biroi is a painfully slow moving ant and they can remain out of view of the camera for a few hundred frames at a time (I image at 5fps). The track number then goes up within each ROI as more new track IDs are added, and as the ROI jumping occurs since sometimes several ants are occluded from view simultaneously. Despite this, when the ants are in view they are tracked reliably. I’ll continue to play with these settings as you suggest (perhaps a fractional Max Distance will be best) to see if I can maintain the expected 24 tracks and reduce the ROI jumps issue.
Best,
Alex
On Jan 22, 2023, at 10:06 AM, Simon Garnier ***@***.******@***.***>> wrote:
Caution: External email
@ayexander<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ayexander&d=DwMCaQ&c=JeTkUgVztGMmhKYjxsy2rfoWYibK1YmxXez1G3oNStg&r=mHjEnPoAuJYsJzTvHpmQ89iguDIrEOFVqB0oDxTqxTE&m=8ZZYz8U0L3r1cuAgvwRPQPMBsmluqU5qoLpMg7L97cVlgkrXFcICB_het0FZtEX3&s=sbT6z6H-0jm__xGzjEKxmExixKvtgHZS7SX0R4bU6eA&e=> I can look into trying to restrict tracks to ROIs but that won't be straightforward and I won't have time to look into this before a couple of months at least. This being said, your choice of parameters is part of the issue I think. I should document that better but the "Maximum Distance" parameter is per frame. This means that if it is set to 30 pixels, trackR will consider all past tracks that end within 30 pixels in the immediately previous frame, within 60 pixels 2 frames back, within 90 pixels 3 frames back, etc. With such a wide "Maximum Distance" and "Look Back", you're bound to see the large jumps that you describe.
I recommend setting the "Maximum Distance" to between 1.5 and 2 times the maximum expected distance moved by an ant between two frames (in your case, I'm guessing it will be something like 1.5 * 10 pixels at most), and "Look Back" to only a few frames, assuming that ants are consistently detected when in the field of view. I'd be happy to have a quick video chat with you to help you identify the best tracking parameters.
—
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_swarm-2Dlab_trackR_issues_32-23issuecomment-2D1399514358&d=DwMCaQ&c=JeTkUgVztGMmhKYjxsy2rfoWYibK1YmxXez1G3oNStg&r=mHjEnPoAuJYsJzTvHpmQ89iguDIrEOFVqB0oDxTqxTE&m=8ZZYz8U0L3r1cuAgvwRPQPMBsmluqU5qoLpMg7L97cVlgkrXFcICB_het0FZtEX3&s=BpiUT1HuHsfE2eXStntSp5auycp1PitE0uZkrjEAoqI&e=>, or unsubscribe<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_A5KTX54WGSTJV42VPC2CL7DWTVEIDANCNFSM6AAAAAAT7U7NSQ&d=DwMCaQ&c=JeTkUgVztGMmhKYjxsy2rfoWYibK1YmxXez1G3oNStg&r=mHjEnPoAuJYsJzTvHpmQ89iguDIrEOFVqB0oDxTqxTE&m=8ZZYz8U0L3r1cuAgvwRPQPMBsmluqU5qoLpMg7L97cVlgkrXFcICB_het0FZtEX3&s=BD-1hnoA7fTWqyKkrN91JDJrLmiQu6_ZjCrTXWOUaLI&e=>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@ayexander I think I understand your problem. If you have a bit of coding experience, it might be easier to actually reconnect the tracks programmatically during post-processing. Since the tracks are restricted to specific areas, clustering them a posteriori shouldn't be too difficult. Happy to jump on a call with you to explain how to go about with that. |
Error description:
I'm using trackR to track individual ants in a multi-chamber setup, which I mask with multiple non-overlapping ROI's. trackR works well to track the ants, but often the resulting ID's/tracks erroneously jump from one ROI to another despite the ants being physically unable to move between chambers. Also, the ROI jumps are longer than the set "Maximum Distance" and occur when ants disappear from view for a number of frames both shorter and longer than the max allowed "Look back (frames)" value of 150.
Possible Solution:
Is it possible to add an option for multiple unique ROI's, such that the ROI's could be numbered and the track ID's assigned to ants/objects within each ROI be restricted to each ROI.
Alternative / Additional Suggestion:
I'm unsure, but it seems that another feature update that might help would be to make the "Look back (frames)" have a max value of the total #frames in the video.
Example Images:
Example images of ROI ID jumps of about 400 pixels in 5 frames and 31 frames despite "Maximum Distance = 30 pixels" when ants disappear for only 5 and 31 frames despite "Look back = 150" is included:
The text was updated successfully, but these errors were encountered: