Message: 3
Subject: Re: [CinCVS] Towards a better cin ChromaKey
From: David McNab <[EMAIL PROTECTED]>
To: [email protected]
Date: Sat, 27 Oct 2007 13:08:26 +1300
Reply-To: [email protected]
On Wed, 2007-10-03 at 14:10 +0200, Herman Robak wrote:
> On Wed, 03 Oct 2007 05:26:54 +0200, Graham Evans
> <[EMAIL PROTECTED]> wrote:
>
> If the codec returns uncompressed 4:2:0 or 4:1:1 data, then the
temporary
> shouldn't just repeat the colour pixels in a 2x2 or 4x1 pattern. That's
> not upsampling!
I was originally repeating chroma pixels myself, then after hearing this
kind of talk on #cinelerra, I tried upsampling the chroma with linear
interpolation. Result? Lots of small border artefacts of strange
colours.
To those who believe pixel duplication is not the way to go, can you
point me to some digestible and specific algorithms (and preferably some
straightforward reference code as well) that gives better upsampling?
Better yet, something not polluted by patent encumbrance.
My google searches for 'chroma upsampling' point me mainly to patents
websites.
why not FORK blender3D? it´s GNU!
in the node editor there is this GREAT Chromakey node, and also exists as
part of the sequencer.
do you need to reinvent the weel over and over? some other people already
thougth of that, so use that knowledge.
http://www.artresnet.com/david/img/chroma.jpg
http://wiki.blender.org/index.php/Tutorials/Compositing/ChromaKey
http://paprmh.googlepages.com/greenscreen
Cheers.
Marquitux from Argentina
_________________________________________________________________
Sé uno de los primeros a testar el Windows Live Messenger beta.
http://imagine-msn.com/minisites/messenger/default.aspx?locale=es-ar
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
