reinterpolate420 - eliminate chroma jaggyness of PAL-DV

[scharfis_brain]

function reinterpolate420(clip x)
{
	u=x.utoy()
	v=x.vtoy()
	
	u=u.separatefields().separatefields().selectevery(4,1,2).tomsmocomp(1,-1,0).assumefieldbased().weave()
	v=v.separatefields().separatefields().selectevery(4,1,2).tomsmocomp(1,-1,0).assumefieldbased().weave()

	ytouv(u,v,x)
}

this function will only work properly, if your DV-Decoder upsamples the interplaced YUV420 (YV12) Chroma to yuy2 using point-sampling!

the results are IMO very good:



It becomes quite useful, if you intend to deinterlace your PALDV for achieving some kind of Film-Look, for deshaking-pre-processing further filtering etc.

[Wilbert]

Which DV codec did you use here?

[scharfis_brain]

the VDub- File Info tells me, it is using the Mainconcept-DV-CoDec for decoding.

I'll test some other codecs after work.

[dionisos]

the results were AMAZING!
i never thought that reinterpolate would do such a miracle!

[Wilbert]

Could you try the following plugin

http://www.geocities.com/wilbertdijk...late420_v1.zip

and add a screenshot. Progressive only (for now). Syntax

AviSource(...)
ReInterpolate420()

[ADLANCAS]

In theory, should work also in NTSC DV ?

[Video Dude]

Originally posted by ADLANCAS
In theory, should work also in NTSC DV ?

NTSC DV is 4:1:1

PAL DV is 4:2:0

So the answer is no.


There is an AviSynth filter called ReInterpolate411 by trbarry that has been around for some time.

[Wilbert]

Added interlaced support

http://www.geocities.com/wilbertdijk...late420_v2.zip

syntax

AviSource(..)
ReInterpolate420(interlaced=true) # false by default

@scharfis_brain,

Could you compare it to your script?

[scharfis_brain]

jep, it works!
You're using simple lineare interpolation, aren't you?

my method using edge directed interpolation using tomsmocomp (tdeint(mode=1) should work, too) has a better chroma definition on diagonales.

[smok3]

scharfis_brain: cool, do you think this will work (as preproc) in favor of a 'better' chroma key?

[scharfis_brain]

of course!
my reinterpolate420 tries to find diagonal edge to enhance the chroma resolution. but currently something seems to be slight weird. the chroma is shifted by about 1 or two pixels upwards (wilberts plugin, too!)

but, try some comparisions of your chroma-keying with and without reinterpolate420, and report your results!

[scharfis_brain]

according to this: http://www.mir.com/DMG/chroma.html
(SMPTE PAL-DV)

Cb & Cr are spatially displaced by one line per field.

Do we need to include this weirdness in our reinterpolation?

I tend to say, that there is always a slight chroma-shift in PAL-DV depending on the color.

arggggghhhhhhhhhhhhh!
I hate this crappy YUV420. I will never step behind the thoughts of those engineers.
All they did was causing confusion........

[Wilbert]

You're using simple lineare interpolation, aren't you?

Yup.

my method using edge directed interpolation using tomsmocomp (tdeint(mode=1) should work, too) has a better chroma definition on diagonales.

If I would know how that works, I can try to implement it

Cb & Cr are spatially displaced by one line per field.

Do we need to include this weirdness in our reinterpolation?

I did. Let me tell you how I interpolate:

1) Assume clip is interlaced. The layout of the *frame* is as follows

YV1 ...
YV2 ...
YU3 ...
YU4 ...
YV5 ...
YV6 ...
YU7 ...
YU8 ...

when converting to YUY2 by the codec, the existing chroma is untouched. The missing chroma is either duplicated or point sampled (not sure which one it is).

ReInterpolate creates the missing chroma (the existing chroma is left untouched) as follows:

YV1 ... U1 = as done by codec
YV2 ... U2 = as done by codec
YU3 ... V3 = 0.5*( V1 + V5 )
YU4 ... V4 = 0.5*( V2 + V6 )
YV5 ... U5 = 0.5*( U3 + U7 )
YV6 ... U6 = 0.5*( U4 + U8 )
YU7 ...
YU8 ...

2) Assume clip is progressive. I assume that the conversion is always field-based (so codec always upsamples assuming interlaced). Perhaps this is false?

The layout of the *frame* is as follows

ReInterpolate creates the missing chroma (the existing chroma is left untouched) as follows:

YV1 ... U1 = as done by codec
YV2 ... U2 = as done by codec
YU3 ... V3 = 0.666*V2 + 0.333*V5
YU4 ... V4 = 0.333*V2 + 0.666*V5
YV5 ... U5 = 0.666*U4 + 0.333*U7
YV6 ... U6 = 0.333*U4 + 0.666*U7
YU7 ...
YU8 ...

Should I do it differently? Btw, I assume your made your YV12 test clip correctly (feeding the codec with interlaced/progressive YUY2).

Last question

my reinterpolate420 tries to find diagonal edge to enhance the chroma resolution. but currently something seems to be slight weird. the chroma is shifted by about 1 or two pixels upwards (wilberts plugin, too!)

Could you post some screenshots of this?

[scharfis_brain]

thanks for your explantation!

Could you post some screenshots of this?

the screenshot above has this issue!

but, I am not sure, whether the Codec places the chroma correctly, or reinterpolate420 does ?!?

[MGRip]

Where to add this code in the avisynth script? (I'm newbie with avisynth)

[scharfis_brain]

to use this function, you need to place it at the top of your script:

[code]
function reinterpolate420(clip x)
{
u=x.utoy()
v=x.vtoy()

u=u.separatefields().separatefields().selectevery(4,1,2).tomsmocomp(1,-1,0).assumefieldbased().weave()
v=v.separatefields().separatefields().selectevery(4,1,2).tomsmocomp(1,-1,0).assumefieldbased().weave()

ytouv(u,v,x)
}

loadplugin("drive:\path\tomsmocomp.dll")

avisource("dv-video-pal.avi")
reinterpolate420()

[MGRip]

Thanks,
I've just added ConvertToYUY2() before the reinterpolate420() (because there was an error without this)

[scharfis_brain]

if your source is RGB, this should be okay, but if the source is YV12
(check with avisource("ccc").info())
then, you should not use reinterpolate420 jet.

[MGRip]

Somehow it says that even my captured footage is RGB24, how can it be? I captured it with adobe premiere.

[communist]

Are you using the PanasonicDV codec? It accepts and outputs only RGB
Try ffdshows DV decoder and set it to output YV12. Also you cant have a DV file with RGB color space - DV is stored in YV12 and I dont know of any encoder (codec) that employs RGB colorspace in DV streams - but than again these wouldn be DV streams anymore