Log in

View Full Version : reinterpolate420 - eliminate chroma jaggyness of PAL-DV


Pages : 1 [2]

henryho_hk
11th December 2004, 15:40
Originally posted by scharfis_brain
if you need YV12 out of an DV-AVI, open it via directshowsource() and enable ffdshow as DV-Decoder. it will give you much better chroma...

I see. Does it mean that the YV12 output of the ffdshow decoder is free of these chroma glitches (even fixchromaupsampling)?

If I uninstall all other DV codecs, can I use the following instead of DirectshowSource?

AVISource("input.avi",audio=true,pixel_type="YV12",fourcc="DSVD")

scharfis_brain
11th December 2004, 15:48
this won't work.

henryho_hk
11th December 2004, 15:58
Originally posted by scharfis_brain
this won't work.

Too bad.... DirectshowSource does not always work in my computer, esp. on those big DV dumps.

scharfis_brain
11th December 2004, 16:14
maybe this function:

function reducetoyv12(clip x)
{
u=x.utoy().separatefields().separatefields().selecteven().converttoyv12().weave()
v=x.vtoy().separatefields().separatefields().selecteven().converttoyv12().weave()
x=x.converttoyv12()
ytouv(u,v)
x.mergechroma(last)

}


avisource("dv.avi")
reducetoyv12()
kerneldeint(order=0,sharp=true)
removegrain(mode=2)


is good for your purposes.
the funmction reducetoyv12 reduces the YUY2 chroma to YV12 chroma using pointsampling insted of weighted blending, like converttoyv12(interlaced=true) would do.

Wilbert
11th December 2004, 16:53
if you need YV12 out of an DV-AVI, open it via directshowsource() and enable ffdshow as DV-Decoder. it will give you much better chroma...
Nope, it won't. Like I said several times in this thread, DV-YV12 (pal) and MPEG2-YV12 are sampled differently. If you import it using DirectShowSource, and you either convert to another color format, or you just leave it as YV12 (and play it after encoding), your chroma will be messed up.

scharfis_brain
11th December 2004, 18:25
I found out, that U and V of DV-YV12 seems to be stored as normal YV12 ?!?

at least, the processing as normal YV12 won't suffer from chroma misalignement in my tests..

Wilbert
11th December 2004, 22:50
I found out, that U and V of DV-YV12 seems to be stored as normal YV12 ?!?
The storage is the same (Y plane, V plane followed by U plane), but the sampling is different. You posted a link in the first thread, so you should know :)

YUY2 layout:

frame:
YC Y YC Y line 1
YC Y YC Y line 2
YC Y YC Y line 3
YC Y YC Y line 4

MPEG-2
YUY2 -> YV12 (interlaced subsampling)

frame:
Y_Y_Y_Y line 1t
C___C__ chroma of YUY2_lines (0.75)*1t + (0.25)*3t
Y_Y_Y_Y line 2b

Y_Y_Y_Y line 3t
C___C__ chroma of YUY2_lines (0.25)*2b + (0.75)*4b
Y_Y_Y_Y line 4b

DV-PAL
YUY2 -> YV12 (interlaced subsampling)

It think it's just point-sampled (ie chroma removed):

frame:
YV1_Y_YV1_Y line 1t; V of YUY2_line 1t
YV2_Y_YV2_Y line 2b; V of YUY2_line 2b
YU3_Y_YU3_Y line 3t; U of YUY2_line 3t
YU4_Y_YU4_Y line 4b; U of YUY2_line 4b
YV5_Y_YV5_Y line 5t; V of YUY2_line 5t
YV6_Y_YV6_Y line 6b; V of YUY2_line 6b

I'm not sure, if have to look that up.

Suppose you upsample that using ConvertToYUY2(interlaced=true) (thus MPEG-2) sampling. What happens?

Consider line 5t. The chroma will be recreated as

chroma of YV12_lines (0.25)*1t + (0.75)*5t

Thus V5 = (0.25)*V1 + (0.75)*V5 and U5 = (0.25)*U3 + (0.75)*U7.

While it should be

Thus V5 = V5 and U5 = (0.5)*U3 + (0.5)*U7. I think ...

see http://www.avisynth.org/Sampling

scharfis_brain
11th December 2004, 23:31
Hey Wilbert. It is not, that I don't know about this sampling stuff
(After I learned a lot while being in this forums :) )

but it seems, that reality and theory differ (like the 1.066 and 1.094 PAR for the PAL-Stuff)

after examining some videos (two different cams),
I think that the chroma is sampled like conventional YV12.
Knows the devil why.

If you own an DV-Cam (I do not. I am only the person, who processes the videos...)
You may print out an image containing pure blue background with pure red diagonal objects on it (lines, blocks or circles). then you make a short still standing video of this (well lightened) picture.
This would be IMO the only possibility to check, whether the Cameras follow the standard or not.

Natural video is not that suited for checking for half pel chroma displacements, I think.
So I came to that (probably wrong) conclusion that DV Cams are building conventional YV12.

I also want to mention, that the canopus DV-Codec samples a RGB-Input with standard YV12.

Also its point-upsampling is in the grid of standard YV12.
Which (the point upsampling) is NOT a bad thing, after doing some tests!
Most MPEG-2 Encoders need RGB (TMPGenc) or YUY2 (CCE etc..) input, which gets downsampled to YV12 again by averaging nearby pixels (not 100% correct, I know...).
With IDENTICAL nearby pixels like it is the case with point-upsamples DV, the chroma won't bleed.

but if the DV-decoder would to a proper visual (with averaging) upsampling to YUY2 and the encoder the downsampling to YUY2 the chroma is bleeded like hell....

reinterpolate420() is only needed, if heaviy image manipulation (destroying pixel structure) is wished (deshaking, resizing...)
for linear editing it is completely obsolete, IMO.

when I need to deinterlace the stuff, I am currently not 100% sure, whether I shall use

reducetoyv12().YV12deinterlacer()
(gives lowest chroma manipulation as possible!)

or

reinterpolate420().YUY2deinterlacer()
(chroma-artifacts of the deinterlacer are not that visible, chrom is slightly bleeded)

Wilbert, what do you think?

abraxxa
12th December 2004, 02:50
@Wilbert: What deinterlaced did you use for the posted pictures in this thread? I just don't get those stair-steps away...

henryho_hk
12th December 2004, 07:04
Originally posted by scharfis_brain
maybe this function:

avisource("dv.avi")
reducetoyv12()
kerneldeint(order=0,sharp=true)
removegrain(mode=2)

is good for your purposes.



Thank you. As I will be using the Canopus codec, should I put
"FixBrokenChromaUpsampling()" back? Or is it unnecessary because of the YV12 point-sampling?

In addition, does "FixBrokenChromaUpsampling()" work for both NTSC and PAL DV?

scharfis_brain
12th December 2004, 07:54
no! you should have read the AVISynth documentation.

FixBrokenChromaUpsampling() will correct a progressively upsampled to interlaced upsampling. But that is NOT the case with the canopus decoder. it upsamples correctly in relation with interlacing.

henryho_hk
12th December 2004, 10:28
Originally posted by scharfis_brain
But that is NOT the case with the canopus decoder. it upsamples correctly in relation with interlacing.

I am referring to ScrollLock's sticky thread DV decoder differences (http://forum.doom9.org/showthread.php?s=&threadid=33526).

From your advice, as my target is YV12 (MPEG1 or WMV actually), I think I should either:

1) grab the YVY2 output of Canopus and then point-sample (reducetoyv12) it to YV12; or

2) try the YV12 output of ffdshow's VFW module.

I am particularly interested if ffdshow will deliver both PAL and NTSC outputs correctly.

scharfis_brain
12th December 2004, 14:56
if your chroma look coarse interlaced instead of being fine combed, you will need fixbrokenchromaupsampling().
otherwise you won't need it.

my canopus decoder is working correctly!

PAL can be used with ffdshow's YV12 output.

but for NTSC it is a mess, cause it puts out the 4:1:1 samples chroma as YV12 data, which is handled by AVISynth as 4:2:0 sampled chroma.

Just use normal NTSC-DV decoding as it is.
maybe use reinterpolate411() afterwards.
you will not gain anything by working with YV12 output here.

Wilbert
12th December 2004, 15:54
@scharfis_brain

Natural video is not that suited for checking for half pel chroma displacements, I think.
So I came to that (probably wrong) conclusion that DV Cams are building conventional YV12.
I disagree. But, perhaps it differs by DV codec. Let's consider MainConcept, and look at the following script


function translation(clip clip, clip "LClip", int "start_frame", int "beginX", int "beginY", int "end_frame",
\ int "endX", int "endY") {
return Animate(start_frame, end_frame, "layer", clip, LClip, "Add", 255, beginX, beginY,
\ clip, LClip, "Add", 255, endX, endY)
}


c = BlankClip(width=720,height=576,pixel_type="YUY2")
c2 = ImageSource("F:\411_vs_420\1-720-pal.bmp",0,250,25,false).ConvertToYUY2()

ct = translation(c, c2, 0, 0, 0, 99, 720, 288)
cf = ct.SeparateFields.SelectEven
cf.Weave
AssumeFPS(25)
c1 = last.KillAudio

c2 = DirectShowSource("F:\411_vs_420\mc_int.avi", fps=25) # interlaced YV12
#ConvertToYUY2(interlaced=true)
c1 = c1.ConvertToYV12(interlaced=true)

#Subtract(c1,c2)
StackVertical(c1,c2)


1) picture: http://www.geocities.com/wilbertdijkhof/pal.zip
2) mc_int.avi is the script (forming the clip "c1") encoded with MainConcept (also in pal.zip).

If mc_int.avi would have been upsampled to YV12 using MPEG-2 sampling, the clips c1 and c2 would be identical. As you can see, they are not.

ixpi2001
13th December 2004, 17:59
sorry to intefere in your discussion.. i wonder if there is a possibility to only display one of the color channels a time. not in interpolated fullscreened size, but with ie the red pixels in just the position they are stored:
l1:x x x
l2: blank
l3:x x x
would be interesting to see, dont you think?

henryho_hk
14th December 2004, 01:07
Originally posted by ixpi2001
i wonder if there is a possibility to only display one of the color channels a time.

I have a shot that a man in a grey suit is moving in front of a red background. I think it help beginners like me to see how interpolate420() and fixbrokenchromaupsampling() works.

Is the following script correct?
<<deleted>>

Video Dude
23rd June 2005, 19:57
Sorry for the late reply, but better late then never.

Its not a question of which better, but which format you use, PAL or NTSC, which depends on what county you live in.

Yes, I would recommend using the ReInterpolate411 filter if you are encoding NTSC DV into MPEG-2. It does a great job.

FredThompson
27th August 2005, 17:24
I have a shot that a man in a grey suit is moving in front of a red background. I think it help beginners like me to see how interpolate420() and fixbrokenchromaupsampling() works.Post your screenshots.

Wilbert
6th September 2005, 11:17
Still waiting for your screenshots :)

edit: oops sorry :)

# ffdshow
m_dvsd_yuy2=avisource("p3.avi",pixel_type="YUY2",fourcc="dvsd")
m_dvsd_yv12=avisource("p3.avi",pixel_type="YV12",fourcc="dvsd")

This can't be the DV codec which comes with ffdshow. The latter is a DirectShow based codec which can only be accessed by DirectShowSource. But perhaps i'm missing something :)

henryho_hk
6th September 2005, 12:57
This can't be the DV codec which comes with ffdshow. The latter is a DirectShow based codec which can only be accessed by DirectShowSource.

There is no vidc.dvsd setting in my registry but I've enabled ffdshow's DV decoding in its VFW & DS decoder. I do have a set of png files made by directshowsource but the forum does not allow me to post them (since they are identical to the dvsd vfw files).

FredThompson
6th September 2005, 17:23
You might also want to test the MainConcept and Ulead (Sony) codecs.

henryho_hk
8th September 2005, 07:05
Still waiting for your screenshots :)

They seem a bit off-topic. I have moved them to the thread "DV decoder differences - update". ;)

Fizick
21st July 2006, 23:44
I updated ReInterpolate420 plugin a little:

v3, 22 July 2006 -
color tint decreasing in progressive mode;
speed increasing in both modes by integer processing

romangal
21st June 2021, 17:03
So, now i m trying to use Canopus Dv codec 4.60 from Grass Valley Codec Option package. And im confused about necessary of using Reinterpolate420. Because last testing was done for Canopus DV 1.0.0.0. I made testing by myself with last canopus version but cant understand if its needed...sorry.

P.S. So for now i see. With new version of canopud DV (4.60) You dont need to use FixBrokenChromaUpsampling, but its preferable to use Reinterpolate420. Correct me please if i made wrong conclusion.