>> are you sure this is not interlace artifacts?

Yes, absolutely.
For testing purpose I made a bmp-picture, green circle on blue background, imported it and rendered it to PAL-DV. Even here you can see those effects.
If I do a chroma-keying now, nothing will be enhanced. I cannot see any improvement as the SF-Codec is said to have when keying. There is no difference against using other DV-codecs except the picture quality itself.

It looks very similar to what we have by interlace artifacts, but only if I did render to PAL-DV. I made same test and rendered it to NTSC-DV and I had same artefacts but now vertical instead of horizontal.

>> do they show up in the final render?

Yes.

Now the VV-keying looks really bad. It's miles away from systems which do keying in YUV-colorspace. Only chance I have is blurring the color-edges as much as necassary/possible.
But I still hope there is a trick to be found to enable that "key-signal-interpolating-thing" ... ;-)

Marco

Now I started a progressiv scan project, imported the bmp-circle once again and rendered it to progressiv scan pal-dv. The result is the same.

I uploaded examples: zoomed sections of that circle - the original bmp, the VV-rendered pal-dv clip and the keyed pal-dv clip:

http://dolax.bei.t-online.de/misc/key/yuv/test.html

Same results I get if I do key a real video clip with curved color edges.

>>>I uploaded examples: zoomed sections of that circle - the original bmp, the VV-rendered pal-dv clip and the keyed pal-dv clip:
>>>http://dolax.bei.t-online.de/misc/key/yuv/test.html

I looked at your samples and did similar tests. my results were similar to yours. horizontal artifacts with PAL and vertical with NTSC. I don't know if it is a bug but if you've seen better results in another program... actually I have little experience chromakeying so I don't know what is good or bad. one lesson I learned today... avoid chromakeying with DV if possible! :D

Thanks Cheesehole for testing it.
Yes, some other apps do actually have better results.
I added an example keyed in 'CineStream', there you can see what YUV-interpolation would mean. Same adress as above:

http://dolax.bei.t-online.de/misc/key/yuv/test.html

This CineStream-keying looks perfect on video monitors.

Crazy thing is:
You'll never read any words about that nice keying enhancement feature of CineStream, it's just there ... ;-)
But here on SonicFoundry-Homepage you can read about Vegas Video:
"Vegas Video 3.0 includes a new high- quality DV codec developed by Sonic Foundry that offers pristine colors, incredibly sharp images, artifact-free compositing, and DV chromakeying for both NTSC and PAL."

I agree this codec is best available for any of those things mentioned above EXCEPT chroma-keying.
So it should not mean "Avoid chroma-keying with dv", but "take care which NLE you take for dv chroma-keying" ;-)

Marco

>>>So it should not mean "Avoid chroma-keying with dv", but "take care which NLE you take for dv chroma-keying" ;-)

yes I see the result is quite different from Cinestream compared to VV3. I wonder if VV4 will include some improvements there? you should send the link to SoFo product suggestion people. (click the support link at top of page)

I looked at your examples, and agree that the PAL DV looks pretty bad. I was able to reproduce your results by creating a green circle on a blue background, and rendering to PAL DV, so it's nothing unique to your system. This is due to the 4:2:0 chroma sub-sampling that PAL DV uses, and the interesting Cb/Cb/Cr/Cr pattern to the subsampling used. The SF DV codec is doing the best that it can given the extreme chroma and luma change at the edges of those colors. We just compared it against the Canopus, MainConcept and Microsoft DV codecs on the same test image, and they all produce similar results.

If you'd like to compare the MS DV codec with Microsoft's go into the General page of Preferences and check "Use MS DV Codec" and restart.

NTSC DV has different artifacts, because it is 4:1:1 compressed. The top and bottom of the circle are good, but the edges have some chroma aliasing, 4 pixels wide, as you'd expect.

However, keep in mind that you are using synthetic images. If you're working with synthetic images, you should be generating alpha keys instead, and avoiding compressed image formats. Chroma keying is really only intended for camera shoots where there is no matte image available.

If you're going to be doing chroma keying tests, do them with real footage.

///d@

First of all: Thanks for joining this thread! I was really waiting for an answer which could bring some light into this dark.

I already tested Panansonic-, MainConcept- and Microsoft-DV-Codecs and - yes same results, but them aren't as good as the SF-codec anyway.
I am surprised even the Canopus-Codec gives same keying results there, for they say it would render in YUV 4:2:2 color-space and this would overcome the DV keying-problem ...

Yes, you are right, the test image was synthetic, BUT I get same results in many of my real footage (which is all PAL only). Take a look at this page and see the upper edge of the pillow:

http://dolax.bei.t-online.de/misc/key/sf_key.jpg

Do you think same picture shot in NTSC would give better keying results?

Marco

You will not get the 4-2-2 sample rate using only Canopus software codec in render situation.
You only get 4-2-2 if you have the Real time Canopus hardware.
I get very good keys from the Canopus RT card.
In fact, because of VV, I only use Canopus card for chromakey and color corrections. The rest is done in VV.
My utopian NLE would be Realtime VV with Canopus hardware plugin.
So there is always the dream world.
W

>>>If you're going to be doing chroma keying tests, do them with real footage.

yes I agree no one should be trying to do this for a real project. this is just to compare the Cinestream chromakeying to VV chromakeying.

thanks for jumping in SonicDennis. one thing you didn't mention though is the difference between the keying methods shown. this isn't really a codec comparison, it is a 'chromakey using DV source' comparison using VV3 vs CineStream. it seems to me people will most likely be using DV source for chromakeying, so it would make sense to take special consideration in the chromakey plugin for DV source, which will always be 4:1:1 or 4:2:0.

it appears that Cinestream is interpolating the missing samples when it reads the DV source into it's chromakey filter. (I assume that when the DV footage is read in, it is converted to rgb color space or something else, then processed, then re-encoded as DV)

I'm not saying it's a fair comparison or even a good one, but it does show that there are ways of improving the way an NLE handles DV chromakeying (to reduce the telltale jaggies). doesn't it?

Mmh, I tested chroma-keying with some more real-shot DV stuff now. Some looks pretty good! Here is an example:

http://dolax.bei.t-online.de/misc/key_real/key_real.html

Need more testing stuff ... ;-)

Marco

Hi Watson,

> In fact, because of VV, I only use Canopus card for chromakey and color
> corrections.

I know that many Canopus users are disappointed with their color correction - not because of the bad quality but because of the few capabilities. So may I ask you if you are fully satisfied with it or is there something you are missing?

I'm asking you this question because I'm still unsure which editing system to buy.

Thank you!
Wolfgang

One trick I've learned is to check "show mask only" and use that b/w mask as an alpha in the track above the original shot. You can apply brightness and contrast, blur, or other filters to the mask only, and not affect the original image. Extra steps, yes, but you do get some more flexibility if you need to fine-tune beyond the chroma keyer capabilities.

You can also go all the way and export the b/w mask only as an .avi, bring that into Viscosity, AE or whatever and touch up the mask frame-by-frame, then re-render that to uncompressed and use it as an alpha mask. While that sounds time consuming, it is actually much faster than painting the wall and tweaking lights all day long...plus you can do it sitting down.