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
Closed, ResolvedPublicDifferent Tracking results on V2.64 and V2.63
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.
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 ?
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.
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.
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.
PS if you need my footage to resolve this, let me know
Camera used: Canon Powershot SX40HS
about 24mm on 35mm (equiv.) HD video
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?
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.