[Bf-vfx] tracker constraints and camera reconstruction...

[Francesco Callari]

On Wed, Aug 14, 2013 at 5:42 AM, Sergey Sharybin <sergey.vfx at gmail.com>wrote:

>
> I'm not currently sure why plane would help a lot here, bundler shall
> handle this case just nice.
>
>
A plane (or indeed any known model) helps solving the scene because it
reduces the size of the search space.

Simple example: a rigid box of known size is in the scene, its vertices (or
any points on its surface) are tracked. You add a model and contrain it so
that it is forced to stay attached to the tracks. Then you can solve for
the location and pose of the box (6 parameters), instead of the 3D location
of the tracked points, which may be a lot more. And the solution will be
more robust because it will automatically average out the track errors.
Generalize, and you end up solving for a known scene graph, rather than
just a bunch of unconnected points. It's called "photomodeling".

Real-life example. In "Pirates of the Caribbean: Dead Man's Chest" (first
feature movie with on-set motion capture), the markers on the actors'
bodies had known shapes, and could deform only within known limits. These
facts, properly modeled in ILM's Zeno scene graph, were a tremendous help
for the matchmovers (or match-animators) to get solutions. In Zeno the
"Mars" bundler was completely integrated with the scene graph (in fact, it
was really a scene graph solver), and routinely used to solve for the
animation of scene elements.


>
> On Wed, Aug 14, 2013 at 2:40 AM, David Jeske <davidj at gmail.com> wrote:
>
>>  On Tue, Aug 13, 2013 at 10:04 AM, Sergey Sharybin <sergey.vfx at gmail.com>wrote:
>>
>>>  Another usage of plane track might be constraining point tracks to
>>>>> belong to this plane while tracking them. Which means we might support
>>>>> other-way-around usecase: you create point tracks, you create plane out of
>>>>> them, and then starts tracking this point tracks taking plane constraint
>>>>> into account.
>>>>>
>>>>
>>
>>> That wouldn't be 3d, that'd still be based on homography estimation and
>>> making so tracks fits this homography in a best way (well, difficult to
>>> explain this in text, whiteboard would be much easier). At this point i
>>> couldn't see why or how we'll reconstruct 3D from point tacks in that case.
>>>
>>
>> It seems like something down this path should allow us to both get better
>> and more reliable tracks, and more reliable camera solve.
>>
>> Which of these approaches do you think are easy-vs-hard with libmv/Ceres?
>>
>> 1) binding trackers together to help the tracker solve (maybe just
>> homography)
>>
>> 2) telling the camera solver when a set of tracks are 3d planar, to help
>> constrain the solver, and improve the relative positions of reconstructed
>> 3d track locations in more rotation-dominant sequences
>>
>> 3) add a workflow like Mocha/AE, where a surface can be spline-marked and
>> tracks are automatically managed within the surface.
>>
>> ...though when I was looking at this before, I was thinking just saving
>> camera-reconstruction constraints (origin, floor, scale) in the marker
>> would be nice, so they don't have to be re-applied every camera-solve
>> attempt.
>>
>>
>> _______________________________________________
>> Bf-vfx mailing list
>> Bf-vfx at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-vfx
>>
>>
>
>
> --
> With best regards, Sergey Sharybin
>
> _______________________________________________
> Bf-vfx mailing list
> Bf-vfx at blender.org
> http://lists.blender.org/mailman/listinfo/bf-vfx
>
>


-- 
Franco Callari <fgcallari at gmail.com>

            EC67 BEBE 62AC 8415 7591  2B12 A6CD D5EE D8CB D0ED

I am not bound to win, but I am bound to be true. I am not bound to
succeed, but I am bound to live by the light that I have. (Abraham Lincoln)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-vfx/attachments/20130816/16758cad/attachment.htm