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.
Code:MergeChroma(SeparateFields().Blur(0,1).Weave()) MergeChroma(last, SeparateFields(last).BilinearResize(width,height/4).BilinearResize(width,height/2).Weave())
Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or try DVDFab Passkey and copy Blu-ray and DVDs! :)
+ Reply to Thread
Results 1 to 19 of 19
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
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:
There are probably several others, but I'll leave it up to you to do the additional searching.
If you use UtoY() or VtoY() to view the chroma channels you'll see that MergeChroma(SeparateFields().Blur(0,1).Weave()) gives sharper chroma.
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
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.
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.
And you have a sample of these alleged Hanover bars you're working with, or should we keep guessing?
Last edited by LMotlow; 30th May 2018 at 17:06.- My sister Ann's brother
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).
Or, since you're likely to be converting to YV12 anyway, just use ConvertToYV12(interlaced=true).
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.
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
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?
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?
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