What is this alternating brightness in Video8 -> DV ?

[mleise]

In the frame on the left you can see alternating brightness every two lines. This pattern starts with exactly one bright line, so the even fields are bright,dark,bright,... and the odd fields dark,bright,dark,... . The videos were from Video8 tapes recorded with (I think) Kyocera camcorders and then digitized with a Sony (Digital8) camcorder that can play analog tapes. (Insert rant about loss of chroma detail and cheap equipment here.)

I'm trying to understand what caused this. Without access to the tapes nor an analog playback device I'm counting on your experience. My first idea was that because in PAL DV, even lines contain Cr samples and odd lines contain Cb samples, the color conversion from analog to digital messed with the luma in the sense that Cr lines get a different luma than Cb lines. I ditched that idea because while chroma samples have the same position in each field, the line pattern alternates between them. My next idea was AC interference, but at 64µs per line in PAL, neither 50Hz or 60Hz is evenly divisible. So I'm still in the blue here.


[Attachment 42985 - Click to enlarge]

[Attachment 42986 - Click to enlarge]

Next is the question how to fix this in a way that it doesn't overcompensate where one or both fields are less affected, like in the frame at the bottom. I'm using AviSynth+ 32-bit and QTGMC with additional temporal denoising and due to its stable nature, the line pattern is mistaken for static detail in skies, walls and other flat areas that sticks out even more when most other noise is removed. (It also doesn't help compression.)

I've tried DeFreq() with a vertical frequency of 100% and different window sizes on the separate fields, but it didn't single out the high frequency line pattern effectively. It does look like a straight forward mathematical solution should exist, but if not I might try to mask and blur the areas that look like the pattern in flat areas.

[johnmeyer]

What caused it? Don't know. Could be a head issue in the original camcorder or the transfer equipment. If you still have the tapes, try capturing them on a different deck or camcorder.

To fix? I can't really tell without having a 3-10 second sample of your actual capture. Those horizontal lines look to me like they are more than one scan line high. I can't recommend anything until I can see what's really going on. From the enlargement of your still shots, its also looks like you have some horrible time base errors. Those will be very tough to fix with software: the only real solution is to do a better capture with better equipment.

[mleise]

Here is a short clip of a ferris wheel ride where the issue is more severe. Yes the horizontal lines cover two scanlines in whole frames and one after separating the fields. About the TB errors: Did you enlarge the image twice? Because after the second zoom in (raw image) the house edges don't look that horrible any more. The scanlines are still not perfectly aligned, but not as horrible as the vBulletin image viewer might suggest. There's also some "internal" drift now and then where the line start looks good, but half way through vertical details become jagged. I wonder if good hardware can help with that as well or if it only keeps line starts in sync? At least I have made 3 DV copies of each tape, so I can work with their Median().

[mleise]

I'm getting some effect from DeFreq() for the extreme cases now with x=0%, y=-100%. It's still leaves a lot of the line pattern in the picture. Manually reducing the average brightness difference between between adjacent lines also works for flat areas, but overcompensates on stuff like horizontal chrome rails where the harsh difference in brightness between two adjacent lines is desired.

[poisondeathray]

Not sure what causes it, but you can use vinverse() or vinverse2 on separated fields

eg.

SeparateFields()
Vinverse()
Weave()

[mleise]

Kudos poisondeathray! That Vinverse2() function is surprisingly effective for this purpose. I'll use that.

[themaster1]

hanovers bars of some kind maybe ?
https://en.wikipedia.org/wiki/Hanover_bars

[mleise]

hanovers bars of some kind maybe ?
https://en.wikipedia.org/wiki/Hanover_bars

Good idea, but then the chroma would be affected and the luma practically unchanged if I understand them correctly.

[jagabo]

They're not hanover bars but they may have something to do with chroma leaking into the luma. You can see that not all colors show the bars to the same degree, and it doesn't appear to be simply a matter of brighter areas showing stronger bars. But there's not enough different colors in the shot to say exactly what's going on. A sequence like:

SeparateFields()
AssumeFrameBased()
SeparateFields()

f0 = SelectEvery(4,0).ColorYUV(gain_y=-10)
f1 = SelectEvery(4,1)
f2 = SelectEvery(4,2).ColorYUV(gain_y=-2)
f3 = SelectEvery(4,3).ColorYUV(gain_y=-10)
Interleave(f0,f1,f2,f3)
Weave()
AssumeFieldBased()
Weave()

eliminates the bars in the cyan/blue hills in the background but creates new ones in the yellow struts.