I thought Jahka did this already? <a href="http://users.utu.fi/jhkarh/code.html">http://users.utu.fi/jhkarh/code.html</a> under optical flow...<br><br><div class="gmail_quote">On Fri, Jan 9, 2009 at 7:17 AM, Xavier Thomas <span dir="ltr"><<a href="mailto:xavier.thomas.1980@gmail.com">xavier.thomas.1980@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I am thinking of another GSoC idea:<br>Motion estimation based frame rate conversion for the sequencer speed effect.<br>
<br>For now the sequencer speed effect works by avaraging frames, but other methods are possible:<br>- Skipping or duplicating frames (quicker)<br>
- Interpolation based on motion estimation of macroblocks (better results in most cases)<br><br>In theory it is quite easy, but in pratice there is some issues:<br>- Performances (need subpixel precision and bad vectors causes artifacts so full search is prefered)<br>
- Need to deal with background region masked by the foreground and with the image borders apearing during a camera pan.<br><br>Note:<br>- Motion estimation code can also be used for better deinterlacing<br>- FFmpeg motion estimation code will be hard to reuse because it is optimized for YUV and video compression pipeline<br>
<br><br>xavier<br><br><br><div class="gmail_quote">2009/1/9 Mathias Panzenböck <span dir="ltr"><<a href="mailto:grosser.meister.morti@gmx.net" target="_blank">grosser.meister.morti@gmx.net</a>></span><div><div></div>
<div class="Wj3C7c"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A GSoC Idea just came to my mind. I don't know if this is feasible or even<br>
worked on:<br>
<br>
Node Plugin Loading<br>
Change node-identifiers from #defined integers to strings, register nodes in a<br>
hashtable and make nodes loadable from .dll/.so files.<br>
<br>
I probably won't have time to do that... but maybe I would do it anyway, if you<br>
(blender developers) think it's a good idea and nobody else is working on it.<br>
(But not during the semester.)<br>
I think that way we would get a lot of new nodes that everyone can test/use,<br>
because you won't need to apply a patch and build a custom blender any more.<br>
Also I think this will reduce conflicts between new nodes. Currently everyone<br>
who writes a new node uses the next unused integer as the id. If two people make<br>
a patch for a new node at the same time there will be a conflict.<br>
Of course a naming conventions to prevent conflicts will have to be introduced.<br>
Maybe like java packages (com.example....) or like xml namespaces<br>
(<a href="http://example.com/..." target="_blank">http://example.com/...</a>)?<br>
<br>
I think more input value types that automatically get nice widgets assigned<br>
should also be possible. Like some kind of combobox (menu) that maps names<br>
(whats displayed) to function pointers (this *might* improve the performance of<br>
the math node(s)) or object, mesh and texture inputs (text fields for the<br>
objects name) etc. This all has to be documented (in the wiki?) so that plugin<br>
developers will find the information they need.<br>
<br>
Another GSoC idea: Profiling blender with gprof and papiex[1] (or similar tools)<br>
to detect hotspots and optimize them. This actually could be done every year,<br>
because of the fast speed of blenders development and the steady growth of new<br>
features. :)<br>
<br>
-panzi<br>
<br>
[1] <a href="http://icl.cs.utk.edu/%7Emucci/papiex/" target="_blank">http://icl.cs.utk.edu/~mucci/papiex/</a><br>
<br>
Chris Want schrieb:<br>
<div><div></div><div>> Malcolm Humphreys wrote:<br>
>> I don't have wiki developer permissions ( as I don't develop blender :) ).<br>
>><br>
>> If the project is deemed as worthy can someone add the following:<br>
>><br>
>> =Node Compositor=<br>
>> * Add an OpenFX (<a href="http://openfx.sourceforge.net/" target="_blank">http://openfx.sourceforge.net/</a>) plugin host to<br>
>> blender's compositor to allow the use of any OFX effects plug-in within<br>
>> a compositor node tree.<br>
>><br>
>> I'm not sure how the two software licenses would play together. But if<br>
>> they do I think being able to load OFX plugins inside blender could<br>
>> potentially be a very good thing.<br>
><br>
> Added, thanks (the license is BSD, which is indeed compatible).<br>
><br>
> Cheers,<br>
> Chris<br>
><br>
<br>
_______________________________________________<br>
Bf-committers mailing list<br>
<a href="mailto:Bf-committers@blender.org" target="_blank">Bf-committers@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br>
</div></div></blockquote></div></div></div><br>
<br>_______________________________________________<br>
Bf-committers mailing list<br>
<a href="mailto:Bf-committers@blender.org">Bf-committers@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-committers" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br>
<br></blockquote></div><br>