[Bf-vfx] Footage proxying
Sergey I. Sharybin
g.ulairi at gmail.com
Tue Jun 7 16:45:06 CEST 2011
Your explanation is quite clear.
But there are such ideas: use use proxied footage for display and
non-proxied for footage, so solving would use "final" image sequence and
would be accurate.
Problem with non-proxied footage is that it'll be scaled anyway so the
whole frame would be visible in the screen. So maybe it should be more
like a mipmaps -- space clip would use the smallest mipmap for
displaying. Smallest in meaning scale factor would be the minial and
there would be no scaling up (increasing resolution from mipmap). So,
when you're zooming up mipmaps with higher levels (smaller resolution)
would be used, but when you're zooming in mipmaps with lower levels
(higher resolution) would be used.
Not sure if it'll give speedup -- maybe OGL is fast enough to display 4K
pixel buffer in realtime?
François T. wrote:
> I'm using DJV a lot which does have this kind of on-the-fly proxy
> stuff you can set.
> Nuke also have this ability where you can set the resolution of the
> proxy you want to.
> But for tracking, as a rule of thumb, we never downsample the footage,
> but track on the one which would be final (even if it's 4k and very
> slow :p). The reason for that is because downsampling could cause some
> slight shifting in the pixels which would cause a mismatch when
> applying the solve (which I've been done on the downsampling) onto the
> final 4K. Might not make a huge difference for most people, but it
> usually does for the one who is working on it, and we usually try to
> have a subpixel accurancy.
> Actually even the inverse (resample to create a better resolution) is
> available in most the matchmove packages (Syntheyes for instance has
> it). I only use it on really poor footages or fast moving camera,
> because those kind of resample would create thick edges which usually
> doesn't match the original footage.
> On a 64bit computer with 4/6 gb of memory, you can put a few seconds
> in RAM which is usually enough for tracking.
> I'm sorry if that doesn't sounds very clear :( . tell me if you need
> more explanation.
> 2011/6/7 Peter Schlaile <peter at schlaile.de <mailto:peter at schlaile.de>>
> Hi Sergey,
> you might want to take a look at the vse-proxies branch, which I
> want to
> merge very soon into trunk.
> It's working on ImBuf-level, so you could use it directly in other
> of blender, if you like.
> > I'm still working under camera tracking integration and need
> some help.
> > One of goals is to be able to deal with 4K footage. But to deal
> with it
> > fine, there should be some stuff which would reduce resolution
> to make
> > playback faster. Such transparent resolution changing is called
> proxying in
> > our development stuff.
> > So, questions are:
> > - How proxying should happen? Should it be slider to specify
> quality of
> > footage or it should be determined automatically using current
> zoom level,
> > space clip size and so?
> > - Should it be able to specify tracker which footage to use:
> original 4K or
> > proxied?
> > - Should user really care about this proxies or they should be
> > transparent for him?
> > --
> > With best regards, Sergey I. Sharybin
> Peter Schlaile
> Bf-vfx mailing list
> Bf-vfx at blender.org <mailto:Bf-vfx at blender.org>
> François Tarlier
> www.francois-tarlier.com <http://www.francois-tarlier.com>
> Bf-vfx mailing list
> Bf-vfx at blender.org
With best regards, Sergey I. Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-vfx