Re: [Bf-committers] Camera tracking UI
I also would expect Solve Camera in the Reconstruction mode, instead of in Tracking mode. I understand why, but for a workflow matter I disagree. When you are going to fine tune your solve to low down the error, you'll tweak your trackers a lot and hit solve very often. If you have to change mode each time its going to be a huge pain. That why we decide with Seb to keep it the tracking mode. Becareful that the logic don't get in the way of confortable workflow. -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera tracking UI
First of all wanted to mention that there's no Enhanced or Super mega cool slow trackers. Well, there can be Super mega cool but it'll be _really_ slow. KLT and SAD are just different and there can be different kinds of features and motions when SAD would give much nicer result than KLT. Also, i don't think it's possible to describe in two words when SAD works better than KLT. IMO it's just more like: test default settings, if result isn't good enough try to tweak some parameters and try again, if fails let's try different algorithm. yeah right :p and you think the algorithm in other software are called Enhanced tracking :p and yes I think CC is terrible as well and dont mean a thing to me :) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera tracking UI
I'm not sure if having Solve button in reconstruciton mode is good idea. Ofcourse you can re-adjust tracks position and resolve. But most probably it'll lead to movement of some bundles which you used to use as reference points. And it was feedback from actual users of motion tracking in blender how to organize panels in clip editor ;) François T. wrote: I also would expect Solve Camera in the Reconstruction mode, instead of in Tracking mode. I understand why, but for a workflow matter I disagree. When you are going to fine tune your solve to low down the error, you'll tweak your trackers a lot and hit solve very often. If you have to change mode each time its going to be a huge pain. That why we decide with Seb to keep it the tracking mode. Becareful that the logic don't get in the way of confortable workflow. -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera tracking UI
Hi again, Commited some interface changes to tomato branch, Please check commit message for details: http://projects.blender.org/scm/viewvc.php?view=revroot=bf-blenderrevision=41744 -- With best regards, Sergey I. Sharybin ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Camera tracking UI
Hi, i see that camera tracker related UI is spread all over the place with no clear definition. Camera tracking is a corner case use of Blender, I'd suggest that UI elements belonging to it get clearer names *and* get pulled together in boxes or their own panels ie: follow track constraint http://www.pasteall.org/pic/show.php?id=20349 why would any regular user of know that this is camera tracking stuff, or what is a Bundle? it's worst in the N Panel http://www.pasteall.org/pic/show.php?id=20350 Shading, Textured solid.. reconstruction? reconstruction of what?? bundle, bundle, bundle and then the old quad view! Daniel Salazar 3Developer.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera tracking UI
yeah I kind of agree with all that. So far all those naming as been chosen based on a technical naming side (ie bundles means something to a computer vision developer, doesn't mean a thing to an artist) Same confusion with, markers, trackers, Same with algorithm FAST, SAD, ... all technical stuff that doesn't mean a thing if you havn't done any computer vision dev in your life But in another hand, matchmove is something you have to get interest in as well. it is a discipline and not just a camera to move around :p. There are terms you got to know as well. Reconstruction is a common one for instance. So yeah on the overall, lots of cleaning stuff to do, and lets drop the geeky dev side. This is a tool for artist and not for devs as far as I'm concern 2011/11/9 Daniel Salazar - 3Developer.com zan...@gmail.com Hi, i see that camera tracker related UI is spread all over the place with no clear definition. Camera tracking is a corner case use of Blender, I'd suggest that UI elements belonging to it get clearer names *and* get pulled together in boxes or their own panels ie: follow track constraint http://www.pasteall.org/pic/show.php?id=20349 why would any regular user of know that this is camera tracking stuff, or what is a Bundle? it's worst in the N Panel http://www.pasteall.org/pic/show.php?id=20350 Shading, Textured solid.. reconstruction? reconstruction of what?? bundle, bundle, bundle and then the old quad view! Daniel Salazar 3Developer.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers -- François Tarlier www.francois-tarlier.com www.linkedin.com/in/francoistarlier ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera tracking UI
*+bf-vfx*
On Wed, Nov 9, 2011 at 4:40 AM, François T. francoistarl...@gmail.comwrote:
yeah I kind of agree with all that. So far all those naming as been chosen
based on a technical naming side (ie bundles means something to a computer
vision developer, doesn't mean a thing to an artist)
What do you propose instead? There has to be some name, either point or
track. The problem with track is that it's highly overloaded. Same with
marker. It's not an issue of computer vision, it's an issue of simply
deciding on names. It IS important to have a way to refer to each of the
different concepts so that there is no confusion.
The naming we've chosen for Blender at the moment is:
A marker - a 2D coordinate on a single image. Literally, a struct of (x, y,
image#, track#)
A track - A collection of markers, one per frame, that point to the same
physical location in the scene. In other words, a collection of {(x, y,
image#)}. There is a 1-to-many relationship between a track and markers.
A bundle - The reconstructed 3D point for a track. Called a bundle
because if you visualize a ray from the camera to each marker, they
(should) intersect at a single point for a good reconstruction. The word
bundle is used to distinguish a reconstructed point from any regular
point. There is a 1-to-1 correspondence between a track and a bundle.
Here's where the overloading gets confusing:
A track*er* - The algorithm that tracks a marker from frame A to frame A+1.
In libmv right now, this is KLT and SAD. Ok, there's a few KLT variants but
they're similar. This is pattern matching across frames. There needs to be
documentation about why you would use one over the other (SAD is faster but
less accurate, KLT is very accurate but sometimes slow)
A tracker - Also the name used for general matchmoving software, e.g.
syntheyes, boujou, etc. Confusing! But there you go.
Feature detector - An algorithm to identify good features to track in the
image, for automatic tracking. Again, the best algorithm depends on the
scene. I wish there was One True Feature Detector To Rule Them All but
there isn't.
Same confusion with, markers, trackers,
Same with algorithm FAST, SAD, ... all technical stuff that doesn't mean a
thing if you havn't done any computer vision dev in your life
I don't think we can avoid having good documentation.
But in another hand, matchmove is something you have to get interest in as
well. it is a discipline and not just a camera to move around :p. There are
terms you got to know as well. Reconstruction is a common one for instance.
The difficulty is that if everything is made automatic with no choices,
then the tool is less useful since in many situations the difference in
whether you can track a shot or not depends on which algorithm you pick.
Welcome to computer vision, where the pixels don't care what you want :)
So yeah on the overall, lots of cleaning stuff to do, and lets drop the
geeky dev side. This is a tool for artist and not for devs as far as I'm
concern
Do you have concrete proposals to do so?
Keir
2011/11/9 Daniel Salazar - 3Developer.com zan...@gmail.com
Hi, i see that camera tracker related UI is spread all over the place
with no clear definition. Camera tracking is a corner case use of
Blender, I'd suggest that UI elements belonging to it get clearer
names *and* get pulled together in boxes or their own panels
ie: follow track constraint
http://www.pasteall.org/pic/show.php?id=20349
why would any regular user of know that this is camera tracking stuff,
or what is a Bundle?
it's worst in the N Panel
http://www.pasteall.org/pic/show.php?id=20350
Shading, Textured solid.. reconstruction? reconstruction of what??
bundle, bundle, bundle and then the old quad view!
Daniel Salazar
3Developer.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
--
François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera tracking UI
*What do you propose instead? There has to be some name, either point or
*
* track. The problem with track is that it's highly overloaded. Same
with
marker. It's not an issue of computer vision, it's an issue of simply
deciding on names. It IS important to have a way to refer to each of the
different concepts so that there is no confusion.
The naming we've chosen for Blender at the moment is:
A marker - a 2D coordinate on a single image. Literally, a struct of (x, y,
image#, track#)
A track - A collection of markers, one per frame, that point to the same
physical location in the scene. In other words, a collection of {(x, y,
image#)}. There is a 1-to-many relationship between a track and markers.
A bundle - The reconstructed 3D point for a track. Called a bundle
because if you visualize a ray from the camera to each marker, they
(should) intersect at a single point for a good reconstruction. The word
bundle is used to distinguish a reconstructed point from any regular
point. There is a 1-to-1 correspondence between a track and a bundle.
Here's where the overloading gets confusing:
A track*er* - The algorithm that tracks a marker from frame A to frame A+1.
In libmv right now, this is KLT and SAD. Ok, there's a few KLT variants but
they're similar. This is pattern matching across frames. There needs to be
documentation about why you would use one over the other (SAD is faster but
less accurate, KLT is very accurate but sometimes slow)
A tracker - Also the name used for general matchmoving software, e.g.
syntheyes, boujou, etc. Confusing! But there you go.
Feature detector - An algorithm to identify good features to track in the
image, for automatic tracking. Again, the best algorithm depends on the
scene. I wish there was One True Feature Detector To Rule Them All but
there isn't.*
exactly what I meant I don't care about all this different stuff. On a
artist point of view the workflow is simple.
You have 2d Tracks and a solve tada, the rest (structure, set of
frames, blablabla,) don't take it the wrong way but nobody cares :)
That's the reason why, like you said, the general software just call that
trackers. But I'm sure the coders from those software have some crazy names
as well to make a slight different between a structure thing and keyframe
other thing ... don't even know what I'm talking about :p
Same confusion with, markers, trackers,
Same with algorithm FAST, SAD, ... all technical stuff that doesn't mean
a
thing if you havn't done any computer vision dev in your life
I don't think we can avoid having good documentation.
If one is better than the other but slower called it enhanced tracker or
super mega cool slow tracker :)
But in another hand, matchmove is something you have to get interest in as
well. it is a discipline and not just a camera to move around :p. There
are
terms you got to know as well. Reconstruction is a common one for
instance.
The difficulty is that if everything is made automatic with no choices,
then the tool is less useful since in many situations the difference in
whether you can track a shot or not depends on which algorithm you pick.
Welcome to computer vision, where the pixels don't care what you want :)
Dont give me wrong, I have been working on both side RD and Artist. I know
the need of all the details stuff on the dev side. But front-end doesn't
need all that. And by no mean I meant everything should be hidden or
automatic. I also know that FAST or SAD WON'T mean a thing to most peoples.
And even if they look into matchmoving books or tutorial from other
software (since our workflow is similar to other any technics could be
applied)... they won't find the anwser. They'll have to get into computer
vision (the dark side for the artist) to understand the difference.
It's like go ask a modeler what a matrix is :) ... he won't even know it
does exist, and still he is using it each time he moves something around
So yeah on the overall, lots of cleaning stuff to do, and lets drop the
geeky dev side. This is a tool for artist and not for devs as far as I'm
concern
Do you have concrete proposals to do so?
We can definetly work on that and take time to do a nice proposal.
Keir
2011/11/9 Daniel Salazar - 3Developer.com zan...@gmail.com
Hi, i see that camera tracker related UI is spread all over the place
with no clear definition. Camera tracking is a corner case use of
Blender, I'd suggest that UI elements belonging to it get clearer
names *and* get pulled together in boxes or their own panels
ie: follow track constraint
http://www.pasteall.org/pic/show.php?id=20349
why would any regular user of know that this is camera tracking stuff,
or what is a Bundle?
it's worst in the N Panel
http://www.pasteall.org/pic/show.php?id=20350
Shading, Textured solid.. reconstruction? reconstruction of what??
Re: [Bf-committers] Camera tracking UI
Instead of being in the N panel couldn't the reconstruction display options be moved to the camera properties display options? This seems a more natural place for accessing this. I don't mind the terminology in general, but can see how some may think it's complex. I definitely don't need to know that KLT stands for Kanade-Lucas-Tomasi... but it helps me to know it is Slower but more precise. I also would expect Solve Camera in the Reconstruction mode, instead of in Tracking mode. Sure stuff could be cleaned up a bit, and I'm sure it will, but I don't hope you intend to turn this into My First Tracking App ;) /Ejner ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Camera tracking UI
Hi,
First of all wanted to mention that there's no Enhanced or Super mega
cool slow trackers. Well, there can be Super mega cool but it'll be
_really_ slow. KLT and SAD are just different and there can be different
kinds of features and motions when SAD would give much nicer result than
KLT. Also, i don't think it's possible to describe in two words when SAD
works better than KLT. IMO it's just more like: test default settings,
if result isn't good enough try to tweak some parameters and try again,
if fails let's try different algorithm.
I've looked into naming problems this morning. Here's image i've already
sent to bf-vfx: http://www.pasteall.org/pic/show.php?id=20402
Also Follow Track constraint can be cleaned a bit: replace
Track|Bundle selector with checkbox I want this object be parented to
track in 3d space.
But all this bundles, klt and so is just a terminology like
catmull-clark. Why you aren't bored with CC but totally bored with KLT?
One more thing: probably that other software where you don't care about
tracking algorithm and so are doing some adjustment internally, but we
can't do such kind of things (@keir: or we can?). Anyway, i don't want
this to be main goal for next months.
François T. wrote:
*What do you propose instead? There has to be some name, either point or
*
* track. The problem with track is that it's highly overloaded. Same
with
marker. It's not an issue of computer vision, it's an issue of simply
deciding on names. It IS important to have a way to refer to each of the
different concepts so that there is no confusion.
The naming we've chosen for Blender at the moment is:
A marker - a 2D coordinate on a single image. Literally, a struct of (x, y,
image#, track#)
A track - A collection of markers, one per frame, that point to the same
physical location in the scene. In other words, a collection of {(x, y,
image#)}. There is a 1-to-many relationship between a track and markers.
A bundle - The reconstructed 3D point for a track. Called a bundle
because if you visualize a ray from the camera to each marker, they
(should) intersect at a single point for a good reconstruction. The word
bundle is used to distinguish a reconstructed point from any regular
point. There is a 1-to-1 correspondence between a track and a bundle.
Here's where the overloading gets confusing:
A track*er* - The algorithm that tracks a marker from frame A to frame A+1.
In libmv right now, this is KLT and SAD. Ok, there's a few KLT variants but
they're similar. This is pattern matching across frames. There needs to be
documentation about why you would use one over the other (SAD is faster but
less accurate, KLT is very accurate but sometimes slow)
A tracker - Also the name used for general matchmoving software, e.g.
syntheyes, boujou, etc. Confusing! But there you go.
Feature detector - An algorithm to identify good features to track in the
image, for automatic tracking. Again, the best algorithm depends on the
scene. I wish there was One True Feature Detector To Rule Them All but
there isn't.*
exactly what I meant I don't care about all this different stuff. On a
artist point of view the workflow is simple.
You have 2d Tracks and a solve tada, the rest (structure, set of
frames, blablabla,) don't take it the wrong way but nobody cares :)
That's the reason why, like you said, the general software just call that
trackers. But I'm sure the coders from those software have some crazy names
as well to make a slight different between a structure thing and keyframe
other thing ... don't even know what I'm talking about :p
Same confusion with, markers, trackers,
Same with algorithm FAST, SAD, ... all technical stuff that doesn't mean
a
thing if you havn't done any computer vision dev in your life
I don't think we can avoid having good documentation.
If one is better than the other but slower called it enhanced tracker or
super mega cool slow tracker :)
But in another hand, matchmove is something you have to get interest in as
well. it is a discipline and not just a camera to move around :p. There
are
terms you got to know as well. Reconstruction is a common one for
instance.
The difficulty is that if everything is made automatic with no choices,
then the tool is less useful since in many situations the difference in
whether you can track a shot or not depends on which algorithm you pick.
Welcome to computer vision, where the pixels don't care what you want :)
Dont give me wrong, I have been working on both side RD and Artist. I know
the need of all the details stuff on the dev side. But front-end doesn't
need all that. And by no mean I meant everything should be hidden or
automatic. I also know that FAST or SAD WON'T mean a thing to most peoples.
And even if they look into matchmoving books or tutorial from other
software (since our workflow is similar to other any technics could be
applied)... they
