Page MenuHome

Tracking backwards fails after gap in track
Closed, ResolvedPublic

Description

System Information
Operating system: Linux-5.8.0-7642-generic-x86_64-with-glibc2.32 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.39

Blender Version
Broken: version: 2.93.0 Alpha, branch: tracking_scopes, commit date: 2021-03-01 15:22, hash: rB380a0b096a31
Worked: (newest version of Blender that worked as expected)

Short description of error
I found this bug while testing the tracking_scopes branch, but the same error occurs in 2.91 as well.
So I tracked a marker forwards until the feature was blocked. (Let's call this section A). A few frames later, when the feature is visible again I continued to track forwards. (Section B)
Now I went back to the start of section B in order to track a few frames backwards to narrow the gap. However, the tracking fails, even though the feature is clearly visible and the search area is big enough.
However, when I do Clear Track Path Before, thereby deleting section A, it tracks backwards perfectly.
I tested this with the old Fabrik shot as well, and could reproduce it there.

Exact steps for others to reproduce the error
Open the attached file and load the Fabrik_Eingang.mov (@Sergey Sharybin (sergey) should have it). Also known as MVI_4005.mov from Track Match Blend 01.

Try to track backwards from frame 135. At least here that fails.
Now do Clear Track Path Before and try again. It should track just fine.

Event Timeline

Falk David (filedescriptor) changed the task status from Needs Triage to Confirmed.Mar 4 2021, 10:42 AM

I can confirm this on the 2.92.0 release and the latest 2.93.0 Alpha, branch: master, commit date: 2021-03-04 06:43, hash: rBef7efc375197.

Wow, the Eldritch Bug! Love it!

From quick thought process and quick code investigation seems that its caused by tracking prediction always going forward.
Is surely not a recent regression, but is something super important to get fixed!

Note: If this does get a fix, the commit should be added to T85958.

@Falk David (filedescriptor) Hi. This is a really old bug (6 or 7 years) and it is not that trivial/safe. I do not really think we should rush it into a corrective release.