Log In
New Account
Home My Page Projects Blender 2.x BF release
Summary Activity Tracker SCM Files

Blender 2.6 Bug Tracker: Browse

[#32765] Different Tracking results on V2.64 and V2.63

Date:
2012-10-04 22:11
Priority:
3
State:
Closed
Submitted by:
Joachim Syga (joachims)
Assigned to:
Sergey Sharybin (nazgul)
Category:
Motion tracking
Status:
Fixed / Closed
Relates to:
Duplicates:
Patches:
 
Summary:
Different Tracking results on V2.64 and V2.63
Detailed description
Hi
I have a Tracking projekt startet with V2.63.18 r50584
12513 Frames / about30% tracked / Start at frame 8535 (i was tracking backward) /Error solve 0.3881

If i Solve Camera with the same file in Blender V2.64 r51026 Relase
I have the Result = Solve error: nan
and on the graph view the Blue line is going up to ~5000

System
Win764

Followup

Message
  • Date: 2012-10-04 23:03
  • Sender: Keir Mierle
  • I tried this out, and I know what is happening. The new path to always use the euclidean resection is sometimes catastrophically failing, and this is not getting detected. I will try some generous thresholds to see if it fixes it.
  • Date: 2012-10-20 16:04
  • Sender: Joachim Syga
  • Blender 2.64 was a VFX release. I´m sorry to ask again. But Tracking was a part of this. Is it to much work to kepp us informed ? OK for me i can use some old version, but wat is with the others ?
  • Date: 2012-10-20 22:30
  • Sender: Sergey Sharybin
  • This isn't so much an easy stuff. With current algorithm used you'll have rock solid solution for good tracks -- no camera flipping will happen. With old algorithm you'll have better solution with worse tracks but you could have camera flips even in cases when tracks were pretty good. We'll really need to figure some threshold here, but it takes time.
  • Date: 2012-11-05 11:20
  • Sender: Sergey Sharybin
  • I've made it an option to enable reprojection fallback method in cases euclidean resection failed in svn rev51883. Using this option and success threshold of 0.001 will bring back old solver behavior.

    However, noticed reconstruction error is not exactly the same as it was in 2.63a. Looks like it's caused by the fact equotions are not stable here and some precision stuff is involved here. Not sure we'll be actually able to change this.

    Will mark the report as solved for now, better solution will take some more time.
  • Date: 2012-11-05 19:16
  • Sender: Joachim Syga
  • sounds good to me, i will test it
    thank you
  • Date: 2012-11-06 21:19
  • Sender: Joachim Syga
  • Hello Sergey

    Report:

    I´m not able to follow your code, be course i´m just a PLC programmer.
    So it will helpful if you can give the formula with description that you r using.
    After testing, i think that in the new way to track, every error is added to the next frame.
    This i OK for short sequences, but i try to track a long video. And i can see that every error (above xxx value) is adding to the error solve. ( if i understand right )
    In the old way the error was calculated every frame. ( i think )

    I was trying different solving frames also.

    Also it is difficult to find out witch track has the error. Be course i think that the error of a
    track is not shown by frame, it can be wrong to delete the one with the highest error.

    Just thinking
    Joachim

    PS if you need my footage to resolve this, let me know
    Camera used: Canon Powershot SX40HS
    about 24mm on 35mm (equiv.) HD video
  • Date: 2012-11-07 12:57
  • Sender: Sergey Sharybin
  • I'm not sure what you mean. The only how tracking happens was changed and you should be able to see when track starts to slide off and correct it. You can also emulate old behavior using Prepass and Location tracking model.
    For camera solution if you'll enable Allow Fallback and set threshold to 0.001 the same algorightm as in 2.63 will be used. The way how reprojection error calculates wasn't changed.

    What's the exact issue here?
  • Date: 2012-11-07 19:30
  • Sender: Joachim Syga
  • Hello
    I was trying the fallback settings and in fact i had a better result then befor, on the half of the already tracked frames. So far so good. Then 1 track is added with an error in the thausends, but when i watch to the track frames every frame is ok. I´m a bit frustrated of this (sorry) but maby this is really not a problem of the trackingsoftware, maby is a problem of the footage or i produce the problem by my self an don´t find it. I will try a other footage to test. Maby also it was a bad idea from me to start as beginner with the difficult stuff.
    Thank you
 

Attached Files:

Name Date Download
1745_V264_030.blend 2012-10-04 22:11 Download
1745_V263_030.blend 2012-10-04 22:11 Download

Changes:

Field Old Value Date By
status_idOpen2012-11-05 11:20nazgul
close_dateNone2012-11-05 11:20nazgul
StatusInvestigate2012-11-05 11:20nazgul
assigned_tonone2012-10-04 22:26nazgul
StatusNew2012-10-04 22:26nazgul
File Added22269: 1745_V263_030.blend2012-10-04 22:11joachims
File Added22268: 1745_V264_030.blend2012-10-04 22:11joachims