Hozirontal banding

[mg262]

I'm getting a weird banding pattern, and I've tried absolutely everything I can think of to fix it... I could really use some help figuring out whether it's line noise or hardware or what.

MSI tv@nywhere
ASUS P4C800-E mboard
PAL Panasonic NV-SV121 VCR (but I've also tried a JVC VCR)
S-video connection (composite gives no banding)

Capping at 720x576 25 fps in VirtualVCR (but same banding in other apps)

The problem is almost that alternate scan-lines are reddened and 'greenened', but that's not guite it - the lines are very slightly diagonal, and some banding is visible even in the luma channel

Here's a close-up:

http://testtesttesttest.50megs.com/images/banding.jpg

I've tried removng the TV, monitor, network card, DVD, floppy, case fan and 2nd HDD (so just VCR + minimal PC unit were connected) with no change in results. I've tried it at uni + at my parents with no change in results. I've tried connecting another s-video device (videocamera) and got no banding - but as noted above a different VCR does give banding. I've tried attaching fanheaters/lights on the same set of powerpoints and switching them on and off and thiss has no visible effect on the signal (don't know whether this rules out line noise). I've tried replacing the S-video cable with no change in results.

I could really really really use some help... what with waiting to return things and borrow things and the like I've been fighting with this for the last five months and I'm really stumped (and fed up!)... any advice would be much appreciated!

[Video Dude]

That looks like chroma noise. (A very common problem of VHS)

You can fix with AviSynth filters.
Example:
AVISource("c:\file.avi")
GuavaComb(mode="pal")

There is not much you can do besides post-processing your capture. AviSynth is a great way to post-process and clean up your clips.

Visit the AviSynth section of the forum if you need help using it.

[Arachnotron]

I think this is a common PAL problem known as 'Hanover blinds', and has to do with phase errors in the chroma signal. (Don't ask me to explain, since I don't fully understand is myself :) )

For an extremely technical explanation, look here:

http://www.snellwilcox.com/knowledgecenter/books/books/edecod.pdf

If you cap composite, the combfilter of your cap device will to some extend correct this, but at the price of some luma detail and other chroma artefacts.

I would try both guavacomb + svideo and capping composite, and see which one gives you the best results.

My guess would be your tapes are either recordings from a bad (broadcast-) source or were made on a broken VCR.

[mg262]

vstrip - thanks, it's useful to have a name for the phenomenon. I will mess around with filters in a bit, but I'd like to try everything else first or at least understand better where the problem is coming from.

Arachnotron - thanks yet again; you always seem to help me out when I'm in a mess. The link is brilliant. It suggests the following theoretical solution:

for even scanlines, replace U and V by:
U' = U cos(theta) - V sin(theta)
V' = U sin(theta) + V cos(theta)

for odd scanlines, replace U and V by:
U' = U cos(theta) + V sin(theta)
V' = -U sin(theta) + V cos(theta)

where you have to guess theta. (This assumes the phase shift is constant over time.)

I've coded up an AVISynth filter to do this, but unfortunately it doesn't fix the problem. (I can post it if it would be useful to anyone.) Studying the picture more carefully, the bands seem to be two scanlines thick - I'm really sorry I didn't get that right before. What's more if you look at the pixel U/V values in those bands, they don't just seem to be rotated values of each other...

Is there any possibility that it's line noise? Although with this VCR I can only see a problem in chroma, with another one I got banding in luma as well.

[Arachnotron]

Studying the picture more carefully, the bands seem to be two scanlines thick - I'm really sorry I didn't get that right before. What's more if you look at the pixel U/V values in those bands, they don't just seem to be rotated values of each other...

(as you will notice, I did not wrestle through this doc myself yet :) )

Just a long shot: when you talk about even and odd scanlines, are you talking about even and odd fields?

Don't these formula's apply to the even and odd lines belonging to the same field

[edit] I think this phenomenon results in alternating single line pattern in a field. So after merging the fields you will get a two line alternating pattern in your frame. If so, the formula's you mentioned should be applied after separating the fields first. You did do that?

[mg262]

I am an idiot. Thank you. (The cartoon seemed to be animated at 25fps so I wasn't even bothering to deinterlace.)

Unfortunately, even when I apply the filter fieldwise, it doesn't fix the problem. I've plotted some more U-V values in Excel and it doesn't look like rotation of alternate lines (in a field) at all.

Guavacomb doesn't really help either - but halving the chroma resolution in each field seems to work pretty well, so I'll probably stick with that for now - although I will keep thinking about it.


Thanks for your help!

[Wilbert]

Did you try the vdub filter rmpal (basically averages the chroma of the even and odd lines of a frame):

http://virtualdub.everwicked.com/index.php?act=ST&f=7&t=4988&hl=rmpal&

I can't find the filter anywhere, but in that thread I posted an equivalent AviSynth script.

Like Tina posted you can also try it fieldwise. Thus

SeparateFields()
the script I posted
Weave()

[mg262]

I will keep an eye out for rmpal... but I used the script below, which does the same as you describe & more or less fixes things.

Actually, I've found it here:

rmpal (http://homepages.fh-giessen.de/~hg6423/rmPal/index.englische-uebersetzung--translated-into-english.html)

but its a VDub filter and I prefer to stick with AVISynth + avoid colorspace conversions. Thanks for the heads-up, though!


I'm thinking of just separating fields and then converting to YV12 which only stores 'every other' chroma line... although I need to check that averages the 2 existing values.

Actually, a q. for anyone ... when I tried rotating the UV-data as described above, I assumed 0x80 was the baseline - i.e. I subtracted 0x80 from U&V before rotating + added it back later. Can anyone verify that this is correct?
______________________________

separatefields()

luma = greyscale()
chroma = Blankclip(last, color = $808080).mergechroma(last)
w = width()
h = height()
chromareduce = chroma.BilinearResize(w, h/2).BilinearResize(w, h)
luma.mergechroma(chromareduce)

weave()

[trevlac]

Originally posted by mg262

Actually, a q. for anyone ... when I tried rotating the UV-data as described above, I assumed 0x80 was the baseline - i.e. I subtracted 0x80 from U&V before rotating + added it back later. Can anyone verify that this is correct?


To center YCbCr chroma values you do indeed subtract 128. -128 to 127 would be the values.

However, Arachno's article may not have been talking about YCbCr (digital color), but about PAL YUV(analog color). In that case, IIRC, YUV has a different scale than YCbCr.

http://www.video-demystified.com/mm/tutor/ch03.pdf

I believe has some info on this. I'm not sure it makes a difference in the math ... but thought it would be good to know.

[Arachnotron]

I was just wondering, as a crude fix:

- separate fields
- separate each field again to fake fields

You now have two sets of two half fields with the same color shift

- 'repair' the shift manually (tweakcolor? Trev, that is your department :D)

- re-assemble the original frame.

It would have the advantage of not simply averaging out the damage done.

[mg262]

trevlac - thanks for the info; as you say, it won't change the maths but the maths is no use without proper decoding, which might explain why I couldn't get things to work earlier. The link says U lies between +/- 112 and V between +/- 157... and presumably these are mapped to 127/-128. But it's also just occurred to me that the saturation, etc. settings on capture cards might transform U & V in some weird manner...

I've tried plotting some U/V values to see if it obvious what is going on, but the result isn't very clear. (U on horiz, V on vert; blue/green correspond to alternating scanlines in a field.)

(largish pic, so I've left it as a URL)
http://testtesttesttest.50megs.com/images/scatter.jpg

(the values are simply the stored values - 128, not scaled.)

(the corresponding field is:
http://testtesttesttest.50megs.com/images/colors.jpg )

arachnotron - sounds interesting, though I don't know what tweakcolor is and neither does Google!

But anyway, though I'm not normally happy with hacks, the averaging looks pretty good in this case, probably because the eye is so much less sensitive to chroma.

[scharfis_brain]

the easiest solution for this PAL-chroma-error is:

separatefields()
mergechroma(blur(0,1))
weave()

it is IMO the same way, rmPAL is going...

but note: YV12 while capping will make it VERY hard to undo such errors, so ensure only capping in YUY2!


btw. what I do not understand: PAL has a delay line, that mixes the inverted previous line with the current line of a field, to avoid this kind of error. so I assume TV-Cards do not mix two following lines of a field to undo phase errors?

[mg262]

I was just about to post that

AssumeFrameBased()
ConverttoYV12()

fixes the problem exactly as the script I posted, as YV12 stores 1/2 the chroma res. (I checked that ConverttoYV12 averages rather than downsampling.) It also has the advantage that YV12 compresses much better and processes much faster. I think I am going to stick with this solution...

I don't know what hppens if you cap straight to YV12, but I'd be surprised if this precise problem happens.

Edit:
I've just compared the 2 methods, and yours is better for nasty cases, scharfis...

[Arachnotron]

@mg262
arachnotron - sounds interesting, though I don't know what tweakcolor is and neither does Google

tweak color is a extended version of tweak Trevlac programmed.
It is in this thread (http://forum.doom9.org/showthread.php?s=&threadid=74334&highlight=tweak+color).
I just picked that one as an example of a filter with which you can change colors.

[trevlac]

With regular Tweak you could also rotate the entire hue 180 degrees. TweakColor just lets you target specific color ranges. Like that bleeding red.

If you can seperate out the scan lines, you could try that to see if you could keep the color detail. But it doesn't sound like it is worth the effort.