[Bf-committers] Google Summer of Code 2009

[Xavier Thomas]

I am thinking of another GSoC idea:
Motion estimation based frame rate conversion for the sequencer speed
effect.

For now the sequencer speed effect works by avaraging frames, but other
methods are possible:
- Skipping or duplicating frames (quicker)
- Interpolation based on motion estimation of macroblocks (better results in
most cases)

In theory it is quite easy, but in pratice there is some issues:
- Performances (need subpixel precision and bad vectors causes artifacts so
full search is prefered)
- Need to deal with background region masked by the foreground and with the
image borders apearing during a camera pan.

Note:
- Motion estimation code can also be used for better deinterlacing
- FFmpeg motion estimation code will be hard to reuse because it is
optimized for YUV and video compression pipeline


xavier


2009/1/9 Mathias Panzenböck <grosser.meister.morti at gmx.net>

> A GSoC Idea just came to my mind. I don't know if this is feasible or even
> worked on:
>
> Node Plugin Loading
> Change node-identifiers from #defined integers to strings, register nodes
> in a
> hashtable and make nodes loadable from .dll/.so files.
>
> I probably won't have time to do that... but maybe I would do it anyway, if
> you
> (blender developers) think it's a good idea and nobody else is working on
> it.
> (But not during the semester.)
> I think that way we would get a lot of new nodes that everyone can
> test/use,
> because you won't need to apply a patch and build a custom blender any
> more.
> Also I think this will reduce conflicts between new nodes. Currently
> everyone
> who writes a new node uses the next unused integer as the id. If two people
> make
> a patch for a new node at the same time there will be a conflict.
> Of course a naming conventions to prevent conflicts will have to be
> introduced.
> Maybe like java packages (com.example....) or like xml namespaces
> (http://example.com/...)?
>
> I think more input value types that automatically get nice widgets assigned
> should also be possible. Like some kind of combobox (menu) that maps names
> (whats displayed) to function pointers (this *might* improve the
> performance of
> the math node(s)) or object, mesh and texture inputs (text fields for the
> objects name) etc. This all has to be documented (in the wiki?) so that
> plugin
> developers will find the information they need.
>
> Another GSoC idea: Profiling blender with gprof and papiex[1] (or similar
> tools)
> to detect hotspots and optimize them. This actually could be done every
> year,
> because of the fast speed of blenders development and the steady growth of
> new
> features. :)
>
>        -panzi
>
> [1] http://icl.cs.utk.edu/~mucci/papiex/<http://icl.cs.utk.edu/%7Emucci/papiex/>
>
> Chris Want schrieb:
> > Malcolm Humphreys wrote:
> >> I don't have wiki developer permissions ( as I don't develop blender :)
> ).
> >>
> >> If the project is deemed as worthy can someone add the following:
> >>
> >> =Node Compositor=
> >> * Add an OpenFX (http://openfx.sourceforge.net/) plugin host to
> >> blender's compositor to allow the use of any OFX effects plug-in within
> >> a compositor node tree.
> >>
> >> I'm not sure how the two software licenses would play together. But if
> >> they do I think being able to load OFX plugins inside blender could
> >> potentially be a very good thing.
> >
> > Added, thanks (the license is BSD, which is indeed compatible).
> >
> > Cheers,
> > Chris
> >
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20090109/bb4c3204/attachment.htm