blinking line on top or bottom when yadif bob

[MasterYGM]

with yadif(mode=1) some dvd show blinking thin line on top or bottom.

usally i crop this by letterbox(0,2) or letterbox(2,0) because this will reduce compressiblilty.

why this blinking happen? and how can I handle this with one general script?

[Forteen88]

Have you tried
TempGaussMC_beta1mod(EdiMode="NNEDI2").SelectEven()
instead?

[MasterYGM]

Have you tried
TempGaussMC_beta1mod(EdiMode="NNEDI2").SelectEven()
instead?

I know TGMC is best for quality. but it's too slow for me.

[Didée]

On the topmost and bottommost line, there are not enough neighbor pixels to make a spatial estimation from.

The issue can be worked around by manually padding the input clip:

mpeg2source(...)
pointresize(width,height+8,0,-4,width,height+8.001)
Yadif(mode=1).crop(0,4,-0,-4)

Et voila, no more blinking lines on top or bottom. BTW, that's the same padding method that TGMC uses.


Edit: just got aware of because this will reduce compressiblilty.
Just to have it noted ... I surely understand if you consider TGMC as too slow for you. But, consider also that TGMC usually will give a result that is *way* more compressible than what Yadif (or any other deinterlacer/bobber) produces. It depends on the source and used settings, but 10~20% better compressability are almost guaranteed. I've seen cases where TGMC after q2-encoding had almost *half* the filesize of Yadif...

[Gavino]

Didée, why the extra .001?

[Didée]

Because occasionally, I'm still using AS v2.5.6. And it is realistic to assume that other people out there still do, too.

Remember that in 2.5.6, the resampler went NOP when in/out sizes were exactly the same, no matter the offset.

Yes it looks strange, but it works in all Avisynth versions. "Keep backward compatibility as long as possible!"

I prefer it that way. Else, people might try it, find "what crap is he telling, it does not work", and keep wondering in silence.


Edit:
Okay, I've beaten myself: In this case here, that epsilon thingy would not be needed.
I rephrase: In AS 2.5.6, the resizer would go NOP under some certain conditions.
... And since I can't remember for sure which the exact conditions are, I keep adding the epsilon thingy to be always on the safe side. ;)

[Gavino]

Ah, I thought it might be something like that.
2.5.6 was before my time, so I'm not sure exactly what form the bug took. But here the in/out heights are not the same,
In: height
Out: height+8

[Didée]

Yeah ... thinking about it, it could be the bug first stroke me when doing subpixelshift-correction for NNEDI, where input/output sizes are equal. Forbear with a dodderer. :D

Just to confirm my claim about compressibility, I've run the "Musicians" test sequence through Yadif(mode=1) and TGMC(2,2,1,4,4,0,"bcbc"), encoded to Xvid@q2. (see, a dodderer)

Here they are:

Yadif (http://www.mediafire.com/download.php?z5jznkmytzl) - 14320 kB
TGMC (http://www.mediafire.com/download.php?tqrtghzwzdw) - 7452 kB

I'm not sure if it's the visual appearance or the different bitrate requirement which is more remarkable.

***

For completeness: the Yadif sample was done *with* forementioned calming of the blinking lines. Without that, the resulting filsize was 14396 kB.

Easy math: calming of the blinking scanlines "improved" Yadif's compressibility by 0.005%. { (14396-14320)/14396 }
Whereas TGMC improved compressibility by 48%. { (14320-7452)/14320 }

(This falsely includes container overhead, but with those numbers that's completely irrelevant.)

[MasterYGM]

workaround script could produce artifact. is there any better way?

Original
http://img225.imageshack.us/img225/738/ringslgorig.th.png (http://img225.imageshack.us/i/ringslgorig.png/)

Resize and crop
http://img225.imageshack.us/img225/1595/after.th.png (http://img225.imageshack.us/i/after.png/)

[Didée]

Workaround script does not produce artifacts. You certainly produced error in script. Post your script.

[MasterYGM]

ImageReader("rings_lg_orig.png")
pointresize(width,height+8,0,-4,width,height+8.001)
crop(0,4,-0,-4)

I tested script to resize test pattern image.
rings_lg_orig.png is 'Original' from previous post.

that script could fill top or bottom blinking line. but could produce another artifact.

[Gavino]

ImageReader("rings_lg_orig.png")
pointresize(width,height+8,0,-4,width,height+8.001)
crop(0,4,-0,-4)
Did you forget to put in the deinterlacer?
What you have there is an identity filter.

Or at least it should be. Are you in fact saying that it isn't?

EDIT: I've just tested it with Compare and it produces 100% identical image to original.

[MasterYGM]

see the second image i posted with 100% actual size. then you can see horizental crack about 100pixel below from top.
image is already changed before deinterlacer. so putting deinterlacer or not is not important.
if you see 100% idential image after script then it's maybe you are using another simple image as source or using another script.

[Didée]

Bad news for you, but ... using exactly the "ringslgorig.png" provided by you, and using exactly the script you posted, I get a result that is exactly identical to the input. No artifacts anywhere. And that's exactly what is expected to happen.

BTW, the artifact you show is not ~about~ 100 pixels from the top, it appears exactly at the 128th line. A funny number, that might indicate that some routine of some application somewhere on the long way to the compressed output might have a problem. Whatever it might be, don't know. But it's extremely unlikely that Avisynth is the culprit. And the script is correct.

Now it's up to you to provide more information about which programs (and their versions) you're using to open the script, and to save the PNG. In case of doubt, use VirtualDub (or -Mod).

[MasterYGM]

I'm using AvsP 2.0.2 to run script and capture
AviSynth version is 2.57 tsp MT version 5

[Gavino]

Try this script:

ImageReader("rings_lg_orig.png")
orig = last
pointresize(width,height+8,0,-4,width,height+8.001)
crop(0,4,-0,-4)
Compare(orig)

You will see a difference of zero, showing the two are identical.

[Didée]

Strange, but interesting.

I never used AvsP up to now, and Im not running any special MT-version ov Avisynth. (I've only single-core PCs, that's why.)

The script is expected to work (because it is correct), and it does work correct with the official Avisynth versions 2.56 and 2.58, in VirtualDub (and /Mod), and in all mediaplayers I tried (ZoomPlayer and mplayer2.exe).

So it seems that either AvsP, or the MT build of Avisynth is to blame.

Try to use just "+8" instead of "+8.001" (which is perfectly okay), perhaps the rounding is off for some reason.

If that ain't help, try vanilla VirtualDub instead of AvsP.

If that ain't help, try a standard Avisynth build.

[MasterYGM]

with 8.001 and Compare...

Main Abs Dev: 90.1333 (90.133/90.133/0.006)
Mean Dev: +0.0064 (+0.006/+0.006/+0.006)
Max Pos Dev: 228
Max Neg Dev: -228
PSNR: 7.78 dB (7.78/7.78/7.78)
Overall PSNR: 7.78 dB

I'll try other version of AviSynth later.

Edit: same result with AviSynth 2.58, Build Dec 22 2008 [08:46:51]

and same with VirtualDub too.

http://img180.imageshack.us/img180/4998/29166331.th.png (http://img180.imageshack.us/i/29166331.png/)

[Didée]

Hmmm ... I remember vaguely some discussion about pointresize and sample positioning, though long time ago. Perhaps the internal code for pointresize isn't the same in MT-Avisynth?

Try with e.g. bicubic instead:

ImageReader("rings_lg_orig.png")
orig = last
bicubicresize(width,height+8, .33,.33, 0,-4,width,height+8)
crop(0,4,-0,-4)
Compare(orig)

Better, or is it the same disaster?

[Gavino]

The problem is due to RGB 'starting at the bottom'.

pointresize(width,height+8,0,-4,width,height+8.001)
needs to be replaced by
pointresize(width,height+8,0,-4,width,height+7.999)
but
pointresize(width,height+8,0,-4,width,height+8)
works OK anyway.

When I tested it yesterday, I used a YV12 clip, so 8.001 worked.

See the problem you caused with your outdated 2.5.6 attachment Didée... :)

[MasterYGM]

I inserted ConvertToYV12() after ImageReader and artifact removed~

but...

with 7.999 it procude artifact again.

YV12 8.001 - no artifact
YV12 7.999 - artifact
RGB 8.001 - artifact
RGB 7.999 - no artifact

[Gavino]

That's right, that's what I meant.
RGB and YUV behave differently with non-integral offsets.

But...
YV12 8 - no artifact
RGB 8 - no artifact

The 8.001 was never needed in the first place! :)

[Didée]

Erhm ... how do I get out of that? (Not at all, I fear ...) :o

However: the cases where people have interlaced RGB input are quite seldom. And which were the deinterlacers for Avisynth that do process RGB input?


(Not an excuse for the unnecessary irritations - but hey, I need to distract, somehow..... ...after all, the thread started about deinterlacing a DVD source.)

[Gavino]

We forgive you, Didée. :)

At least it served as a reminder (to both you and me) of the differences between RGB and YUV when it comes to PointResize, which can lead to puzzling results (as in this case).

[MasterYGM]

Back to the beginning... I just want to remove blinking after deinterlacer.

I tested it to two clip. (top blinking clip and bottom blinking clip)
8.001 and 8.000 removed blinking.
but 7.999 result act strange. some part move correctly but some part move back and forward (like wrong ordered bob deinterlacer)

I still don't understand how resize did this.
I thought 8.000 will produce exactly same clip. so no change will occur.
but there was change. blinking gone.

I guess
maybe resize did nothing. but yadif coudn't handle top and bottom border collectly if black line appear and disappear every field.
and resize made padding there so this confuse gone. am I right?

If yadif has this logical bug then
pointresize(width,height+8,0,-4,width,height+8)
Yadif(mode=1)
crop(0,4,-0,-4)
need every time yadif bob.

[Gavino]

I still don't understand how resize did this. I thought 8.000 will produce exactly same clip. so no change will occur. but there was change. blinking gone.
resize+crop produces the same clip, yes, because the crop reverses the resize.
But resize+yadif+crop gives yadif a larger clip, adding 4 copies of the top and bottom lines, which affects how it treats those lines. The crop then removes the (now processed) extra lines, restoring the original size, with the original edges correctly handled.

If yadif has this logical bug then
pointresize(width,height+8,0,-4,width,height+8)
Yadif(mode=1)
crop(0,4,-0,-4)
need every time yadif bob.
That's a good point.
Didée (or anyone else), is there any reason why Yadif cannot do the equivalent process itself internally?
Or is it something that should not be done on all clips?

[Didée]

Oh, I can't really tell anything about fine details of plugin implementations ... y'know, I do only scripting. (and even that overstrains me - see this thread ...) ;)

However, I don't see serious reason why it shouldn't be possible to implement. It seems rather easy, in contrary. I guess something along the lines of "too lazy", or "nobody will care anyway", or perhaps even "let's implement it when people ask for it" ...
(The latter would be my style) ;-)