[Bf-committers] Google Summer of Code 2009

[Ken & Grace Williamson]

I thought Jahka did this already? http://users.utu.fi/jhkarh/code.html under
optical flow...

On Fri, Jan 9, 2009 at 7:17 AM, Xavier Thomas
<xavier.thomas.1980 at gmail.com>wrote:

> 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
>>
>
>
> _______________________________________________
> 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/b73b3327/attachment.htm