PAL Hannover bars, what was the solution if you have them?

[zerowalker]

Hi,

remember those Orange/Green bars you get sometimes with PAL depending on the Device and such?

I am trying to recall how to solve it, i thought it was using ConvertToYV12 without interlace, but that clearly wasn't the solutions as it messes up the chrome every other frame.

Then i found the code i was looking for, but there's 2 versions, and i can't find out more about them and which of them is the more correct one.

MergeChroma(SeparateFields().Blur(0,1).Weave())
MergeChroma(last, SeparateFields(last).BilinearResize(width,height/4).BilinearResize(width,height/2).Weave())

[themaster1]

With an upsize of X2 with billinear it work better to my eyes than X4 (chroma is less smooth) but i tried it on a progressive test pattern with hanover bars here

MergeChroma(SeparateFields().Blur(0,1).Weave())
MergeChroma(last, SeparateFields(last).BilinearResize(width,height/2).BilinearResize(width,height/2).Weave())

[johnmeyer]

You might want to check out the doom9.org forum. I had never heard of Hanover bars (I live in NTSC-land), but a few years ago someone posted about them.

Here are a few threads that might be useful:

https://forum.doom9.org/showthread.php?t=173276

https://forum.doom9.org/showthread.php?t=78687

https://forum.doom9.org/showthread.php?t=78016

There are probably several others, but I'll leave it up to you to do the additional searching.

[jagabo]

If you use UtoY() or VtoY() to view the chroma channels you'll see that MergeChroma(SeparateFields().Blur(0,1).Weave()) gives sharper chroma.

[zerowalker]

Glad to see the old veterans still active;P

Didn't know aboubt the UtoY() thing, i can see that it does indeed give sharper chroma, visible at certain edges.

Confused though to have it's actually supposed to work (as you aren't supposed to get it in a recording to begin with).

Isn't the first and second frame supposed to share the chrome, but they are supposed to be in a different phase (whatever that means),
which kinda confuses me, cause i don't see how this works in interlaced, as two field-frames could be completely different

[jagabo]

It's the way the video was broadcast. In fact, it's in the name: Phase Alternating Line. I think the idea is that at 50 fields per second and from far enough away your eyes would spacially and temporally blend the bars together.

[zerowalker]

But from my understanding, it's not supposed to actually behave like this, if you read here: https://en.wikipedia.org/wiki/Hanover_bars

It says that it's supposed to do some fancy stuff, but if it doesn't, then you will get those artifacts instead.

Cause i think it depends on the device, cause a friend of mine has the same Capture Card, my VCR (at least one of them) does Not produce the bars,
his VCR does, but i told him to try a Console (N64 PAL) which didn't produce them. Which makes me think it must be the Device sending the signal and not the decoder itself.

[LMotlow]

And you have a sample of these alleged Hanover bars you're working with, or should we keep guessing?

[zerowalker]

My bad, didn't think about examples as i knew some ppl know about the bug/issue and that it was all that was needed, here comes two examples
I must say they do look a lot better than my own examples back in the day if i remember, they were extremely visible on Orange surfaces (got some old pictures).

[jagabo]

Or, since you're likely to be converting to YV12 anyway, just use ConvertToYV12(interlaced=true).

[zerowalker]

Problem with that approach, if i am not mistaken, is that it causes a small color switch every frame.
It doesn't occur when i just blur the the line with MergeChrome, which i thought would be dependent on AssumeTFF/BFF which it doesn't seem to be.

[jagabo]

Problem with that approach, if i am not mistaken, is that it causes a small color switch every frame.

Color switch? What's that? With ConvertToYV12 You can control the chroma downsample with the ChromaSample argument and the placement with ChromaPlacement and ChromaOutPlacement arguments.

[zerowalker]

That the colors, i guess hue, is different every other frame basically, guess cause every other line has different chroma?
Will check those arguments, don't often play with them and just go with default so usually forget they exist;P

[jagabo]

That the colors, i guess hue, is different every other frame

Ah, I see. With the default resampler that happens. If you specify

ConvertToYV12(interlaced=true, chromaresample="spline36")

the color doesn't change from frame to frame. The docs say the default resampler is bicubic. But if you specify chromaresample="bicubic" the color doesn't change.

[zerowalker]

Oh i actually noticed that setting the ChromaOutPlacement worked (except DV which didn't and was wrong on other ways),
but none was like the default, which didn't make sense to me.

What's wrong with not specifying them, seems like a bug to me;S?

[jagabo]

What's wrong with not specifying them, seems like a bug to me;S?

I guess it's a bug.

[zerowalker]

Hmm, weird, will have to take this up with some Avisynth developer, cause this should mean it causes other issues as well,
just that it might not be noticeable unless you got these Hannover Bars.

Was sure it made sense though for it to change color if every other frame had different chrome, it made sense for it to mess up to me if you did it in interlaced mode?

[poisondeathray]

It has something to do with planar vs. interleaved handling. But "normal" 4:2:2 sources should probably be examined before notifying a developer

YV16 (planar) does not exhibit the behaviour

ie.
AVISource("blah.avi", pixel_type="YUY2")
ConvertToYV12(interlaced=true)

vs

AVISource("blah.avi", pixel_type="YV16")
ConvertToYV12(interlaced=true)

[zerowalker]

So it's this problem, found it yesterday.

http://avisynth.nl/index.php/Known_Issues