New GreedyHMA deinterlace filter from DScaler

[meleth]

Could this be the longest ongoing discussion ever? 200 replies now.

[ThePanda]

Can someone tell me, am I supposed to crop before or after I apply GreedyHMA? Or does it not matter?

Edit: I guess since it's supposed to be a multiple of 16 and everything, I'll just crop after

[Blight]

Tom any progress on the known bugs?

[trbarry]

None on the bottom line garbage thing. But I may understand the ghost image on some scene transitions. I managed to recreate it and I think there are unmatched fields and GreedyHMA falls into deinterlace but doesn't handle it well. Or else it should fall into deinterlace for one frame but doesn't because I changed the defaults in the last release. If either is the case then I can probably have a fix soon.

Sorry, but I actually have not been debugging as much as trying something new. I'm trying to add a efficient 5-tap vertical sharpening/softening (Un-Filter) feature that hopefully can undo some effects of prior filtering for interlace. It was just a casual question someone asked over on AV Science but it got me interested. And I need this for my upconverted HDTV Buffy captures.

- Tom

[Blight]

Ok, it seems there's yet "another" issue with Greedy. It darkens the image, losing a lot of black-detail.

Here are 4 sample images displaying this effect (before/after on each image):
Image 1 (http://www.inmatrix.com/temp/sample_00.jpg)
Image 2 (http://www.inmatrix.com/temp/sample_01.jpg)
Image 3 (http://www.inmatrix.com/temp/sample_02.jpg)
Image 4 (http://www.inmatrix.com/temp/sample_03.jpg)

On top of this, it seems there is a chroma issue, where the last image's chroma appears to be displayed for the current image. This would explain the "loss of color" during scene changes. It's more obvious on some video, I'm trying to get together a sample for you to experiment on.

[trbarry]

Blight -

I thought once that I had a fix for your ghost problem (which I think it is) but I'm pretty sure it is not just Greedy. Greedy just seems to cleverly make it worse somehow.

I had a bunch of examples where I could see similar problems in my own stuff. I could recreate it easily. But on further study, each one of those examples had the same problem in the source. Greedy just seems to make it worse. Here's what happens...

On many scene changes the source material would have a transition field (field, not frame) that was blended between the old and new scene. This is not an interlace artifact, it will actually show up as a blend, even if you throw away all the non-dominant fields and go to that frame number. Now Divx4 will put key frames on scene changes so when you skip to the next key frame in vdub edit you are apt to notice land there. But since it's a transition frame you can't see it when playing.

But you may not believe me, so here is an experiment. On the source from your 3rd clip above, run the following script:

SomeKindOfSOurce("whateverfilesample3.xxx")
SeparateFields
SelectOdd #or maybe SelectEven
HorizontalReduceBy2

Now go to frame 31809 showing in your vdub sample. Look carefully at both your sample pic above and the vdub screen. Just to the left of the girls mouth you can see some almost horizontal lines sloping downward to the right. I'll bet that on either the preceding or next frame those are part of the image. Note Greedy is not involved here yet.

Greedy will supposedly match each dominant frame to the best preceding or following match so I'm not sure exactly yet what's happening here. (very vexing) But it does appear that the blend is already in a single field of the source. That's why I've been calling them ghosts. GreedyHMA is not changing the color but it's picking up the darker luma from the preceding/next frame.

The only good thing is that if you never pause on scene changes you will probably never see them. It's just a one frame blend. The bad thing is that pause always happens on scene changes, or at least on key frames. :(

Any ideas appreciated here.

- Tom

[Blight]

I think you misunderstood something. The 4 images above are NOT scene changes. The entire video is darkened, every single frame seems to lose black-detail through the entire video.

When encoding "Alias" it was even worse, at certain scenes (not scene changes) there was a weird trailing "purple" motion artifact, as if a previous frame's color data was applied to the current frame. Once again, not on scene changes.

[trbarry]

Ok, I misunderstood. We weren't even chasing the same rabbit. I thought the above was a follow-up on the problem you posted on Nov 12. Please take my post as an answer to that one.

Are you sure these new ones are in YUV (YUY2) format? That's still all Greedy can handle, still no error checking. Otherwise I'm not even sure where to start looking.

I don't suppose you could post about 10-20 frames of one of these somewhere?

- Tom

[Blight]

Ok, this "darkness" issue isn't greedy's fault. However, there does seem to be a major bug in AVISynth, I'm going to post this on the main forum, be sure to check it out.

[Blight]

Ok, I finally found several good samples showing the problem with the color being dispayed one frame behind.

I took screen shots of two scenes, one shows a cut while the other is mid-scene. Both show the same "effect".

And as far as I can tell, these are properly structured IVTC (so the IVTC worked fine without deinterlacing).

Get the sample images here (http://www.inmatrix.com/temp/greedy_issues.rar).

[trbarry]

Hi Blight -

I see that it's incredibly ugly but don't know why. Would it be possible for you to post about 10 consecutive frames of your original untouched source for that second set (with her colored arm by the door).

And also your filter script if you could.

BTW, GreedyHMA is somewhat torn up right now. I implemented 5-tap vertical & horizontal sharpen/soften but I did it with the new DScaler 4.0 code base, so I have to retrofit to the GreedyHMA calling wrapper. Not really a big deal but it means I can't easily ship a quick fix to something even if I had one.

And as far as I can tell you are a MUCH faster coder than I am. ;)

- Tom

[Blight]

Sorry barry, I don't have the source, I'm operating from sources other encode.

The filter only does avi -> greedy (4) -> crop (after greedy) -> feed to vdub -> encode.

But I didn't see any deinterlacing artifacts in these samples, so the field matching seems to be working, it just seems as if the chroma is delayed by a frame.

And I do need this fixed quite urgently :)

[trbarry]

Blight -

There are multiple YUV formats and I suspect that you are using one of them that GreedyHMA does not handle very well. I don't yet know how in Avisynth to check (or even display) which they are but it is probably possible.

For instance as a test you could maybe put the following 2 statements before Greedy. This might put it into a different more standard format or it might not do anything other than slow things down.

ConvertToRGB
ConvertToYUY2

But I'd be interested in knowing since I can't try it myself.

I'm afraid I don't understand at all how Avisynth handles this stuff, but I'll find out.

- Tom

[Blight]

I believe the source is MJPEG encoded from a YUY2 source.

But I'd think no matter what the source was, the MJPEG would output a fixed format.

[trbarry]

Do you know which MJPEG codec it is?

[Blight]

PicVideo

[trbarry]

Blight -

I've been going through tables of YUV formats and as far as I can tell GreedyHMA will work correctly only with YUY2, which is 4:2:2 non-planar format. There is no checking for this but I'll put some in with the next release, and maybe even figure out how to handle some others. I know I saw some sample Avisynth code somewhere that did that but I can't find it now. Anyone?

But I strongly suspect that is not what you have.

- Tom

[Blight]

I'm trying to arrange MJPEG sources for you to inspect and use to fix this issue.

[trbarry]

Thanks, yes, that would certainly be helpful.

[b0b0b0b]

If it only works in 4:2:2, does that mean greedyhma is mistreating dvd content, which is 4:2:0?

Is hdtv typically 4:2:2?

Thanks

[Blight]

Oh man, I've gotten a piece of an Alias capture source, and this chroma delay is part of the source for heavens sake. Sorry for bugging you ...

Although, if you fix that bottom line bug thing, it would be nice ;)

Now I need to try finding a filter that will do 1-frame delay of luma. Wonder if there is such a thing.

[trbarry]

I even captured one Alias show in HDTV 720p for test data, though I no longer have it. But I have to say for a 1280x720p resolution I really didn't think it looked that good.

But it didn't look like yours. ;)

- Tom

[trbarry]

If it only works in 4:2:2, does that mean greedyhma is mistreating dvd content, which is 4:2:0?

Is hdtv typically 4:2:2?

b0b0b0b -

Actually I may have been needlessly spreading alarm. I did some more reading of Ben RJ's doc. As far as I can tell, Avisynth always works internally with YUY2 or RGB format. So as long as it's not RGB then GreedyHMA should be just fine.

But in case there is any doubt, just put in the following:


ConvertToYUY2
GreedyHMA(...)

Or, if you are just curious, cautious, and want an error check ...

Assert(IsYUY2, "GreedyHMA: input clip must be YUY2 format")
GreedyHMA(...)


The Avisynth doc says the ConvertToYUY2 won't do anything if it is already in that correct format, so it shouldn't be a performance hit.

- Tom

[Cmdr. Koenig]

I've got a quick question concerning using Greedy with TMPGEnc...

With Greedy set at 1,0,3,0,0,0,0,0 this will IVTC my NTSC Video source from 29.97 to 23.976, correct? How does this work with sound? Should the sound file be done seperately, for example through AviUtil, before bringing into TMPGEnc or will Greedy take of this in TMPGEnc?

And while I've got your attention, (sorry :D ), if my source video is Film why not use Force Film in DVD2AVI instead of designating in Greedy with AP=5? Is Greedy more reliable in this aspect than DVD2AVI?

If someone could provide some light on this I'd appreciate it.

I will say that I've found Greedy easy to use and a lot less cumbersome than some of the other methods.

Regards,
Cmdr. Koenig

[Schultz]

It don't matter weither you are at 23.97 or 29.97 for sound since they are based on time.. when you have 23.97 fps then you have less frames in your encode so it will be the same time length as the 29.97 and i don't belive Avisynth handles sound very good so i would suggest doing it seperatly but that is just my opinion. and not sure about the force film part since i generally deal with full NTSC or just part FILM.

[b0b0b0b]

You can use force film if your source is a >95%FILM DVD (according to dvd2avi).

Telecining is accomplished in that case by selectively repeating fields and interlacing them by setting special flags in the mpeg stream.

If you have, say, a video capture, then your video stream will not have these flags set, so there's no way to perform IVTC without analyzing the contents of each field, and that's where greedy comes in.

[Blight]

Ok barry, time to bug you again ...

During scene changes, when I presume a field is missing, what happens is, the luma of one field seems to be combined with the chroma of the other field. Usually comes out as the last frame on a scene being really desaturated since the next frame is black.

Is there a possibility of doing a real blend, where both luma and chroma are mixed evenly. Currently the image seems to retain it's luma so it stays bright while losing it's color...

This causes a sort of "flash" just before a frame change...

Any chance of this being fixed?

[trbarry]

Blight -

I tried it a bunch of ways when writing it for DScaler. Most ways that blend chroma in YUY2 seem to sometimes make strange rainbow effects and more chroma jitter, though I'm not sure why.

Right now GreedyHMA on scene changes will deinterlace one frame (or should if you have BadPulldown lvl set) in a way that will effectively deinterlace the luma but bob the chroma values.

I think what I need to do both for GreedyHMA and DScaler is recognize scene changes in otherwise film material and just bob one entire frame. This would happen whenever the best field match is too poor. But I'm not sure yet.

I do know that GreedyHMA always puts its worst foot forward since people analyze the results by pausing on a key frame. And keyframes are much more likely to be scene changes thanks to clever logic in DivX and others.

I should probably just disable pause. ;)

Seriously though I really do need some way to handle scene changes separately, besides just deinterlacing them. And it's not just a chroma problem.

And as I posted above (way above) some scene changes have already been blended with a double image in capture source (DVD also?). I'm not talking fadeins here but a single blended frame by whatever processing was used to transmit/telecine/whatever. I just flat out can't fix those types of ghost images besides maybe recognizing and dropping them.

I haven't notice the flash effect though. Do you have source for one of these? Snaps don't help as much.

- Tom

[b0b0b0b]

everybody should just watch in 60fps :)


what about this.. when you say "just bob one entire frame," you mean bobbing the last field of the scene that's ending, right? So the new scene will have both fields present for keyframing.

I guess my other question is, when you bob that one time, just before a scene change, is that enough to trick divx's scene change detector into sticking in an extra keyframe?

I guess I have a question about bobbing in general. What does it look like where instead of creating each missing scan line by copying the previous scan line, you had a 50/50 chance of copying a pixel from the previous scan line or the next scan line? Or what if you averaged the previous and next scan lines to create the missing ones?

[b0b0b0b]

another bob question:

what if you left the frame at half-height and just asked avisynth to do a bicubic/bilinear resize on it to double the height?

edit: I would guess a bilinear resize of this sort would be the same as averaging the prev/next scan lines.

[trbarry]

everybody should just watch in 60fps

b0b0b0b-

Actually true, or even 72. DScaler and Greedy/HM actually work this way and I'm considering implementing it in GreedyHMA. There are really 60 fields and therefore 60 deinterlaced/IVTC'd frames if we want to output them. And if you don't add any more I frames then DivX4 won't (I think) take up too much more space if I added this as an option. But most folks wouldn't yet be able to play them at any decent resolution without major frame droppage. :(


what about this.. when you say "just bob one entire frame," you mean bobbing the last field of the scene that's ending, right? So the new scene will have both fields present for keyframing.

On a scene change, both the first and last frame have about a 50% chance of being unmatched. Greedy should mostly bob here. By this I mostly mean doing a vertical interpolation from the data from only one field, not just line doubling.


I guess my other question is, when you bob that one time, just before a scene change, is that enough to trick divx's scene change detector into sticking in an extra keyframe?

No, but I'm not trying to trick divx, just make a nice frame with minimum artifacts. Of course, bobbing has jitter, jaggies, & shimmer.


I guess I have a question about bobbing in general. What does it look like where instead of creating each missing scan line by copying the previous scan line, you had a 50/50 chance of copying a pixel from the previous scan line or the next scan line? Or what if you averaged the previous and next scan lines to create the missing ones?

Normal processing GreedyHMA does have about a 50% chance of using a pixel (not line) from either the prev or next field. But it's not random, the pixels (deinterlace only) are chosen to give the lowest weave/comb/deinterlace factor. If the matching field actually exists then this usually selects the best one and hides the problem when it doesn't. That process is actually where the Greedy name came from. It was first just a part of an early version of Greedy/HM that wasn't finished. But I release it separately as Greedy (Low Motion) for slower DScaler machines and then stuck with the name.

You can somewhat see the result of Temporal Blending in DScaler Greedy/HM if you turn on the In-Between Frames option to reduce judder. It causes motion blur with fast motion.

I think there is also a Temporal Smoother around here somewhere.

what if you left the frame at half-height and just asked avisynth to do a bicubic/bilinear resize on it to double the height?


I think GreedyHMA can probably do it faster. But anyway you'd just get a smoothed line doubling. I thing interpolating is a bit better.

- Tom

[Blight]

Well, the "flash" effect usually happens like this:

The last frame of a scene change is brightly lit, the first frame of the new scene is total black (perhaps a fade-in), what happen is, the luma of the last frame of the first scene is used, and the chroma of the first frame of the second scene is used. What you end up with, all of a sudden the color on the last frame drops, and that quick color drops usually tags at the eye.

I think that even a standard deinterlace:blend between the two fields (like the internal deinterlace:blend in vdub) would be better here, more transitional...

[trbarry]

I think that even a standard deinterlace:blend between the two fields (like the internal deinterlace:blend in vdub) would be better here, more transitional...

It maybe would be. b0b0b0b also suggested this above. I had this code and in DScaler it sometimes caused minor rainbow effects like in cheap DVD players and also increase luma jitter on thin horizontal lines in still scenes.

But after explaining above (a couple posts) why I didn't like it I went away and thought about it a bit. There is no jitter problem in Avisynth because we are only doing 25/30 fps anyway. The same field is always dominant and the even/odd jitter problem doesn't occur.

It won't be right away but I'll see if I still have a copy of that code. Maybe I'll just make it an option. I never really understood why it increase the jitter anyway.

Also in deinterlace mode I've notice Greedy can have posterization problems on slow fades. This is probably for the same reason but it screws up heavily edited music videos with fancy colored lighting effects. This is a case where a Temporal Smoother after Greedy might help. But Greedy just hates superimposed images. It will keep trying to choose one or the other in deinterlace.

- Tom

[Blight]

Barry, I found a clip that seems to have a proper IVTC sequence (3 progressive:2 interlaced) but it fails badly with greedy ... I'm sending you a private message so you can grab a small clip (under 1mb).

[trbarry]

Blight -

I got it. Thanks. There are at least 2 issues going on here, one of which I don't understand.

1) I don't know how you are processing this but I assume the main issue is the very bad 1st scene after the scene change. This is an unmatched frame and should be deinterlaced. This would be ok except until I make another release it won't work in Force Film mode because I foolishly set the BadPulldownLVL to infinity in the last release in force film (ap=2 or 5) modes. But it would be handled if you used an explicit override (soon default) of

GreedyHMA(1,0,5,0,0,0,0,120)

2) The other issue is not specific to Greedy. Try running the following avs script on the data you sent me and step through the frames (fields) immediately after the scene change.

avisource("D:\VCR\ivtcfail.avi")
complementparity
separatefields

Each field 0 and 8 out every 10 is washed out with greatly lowered color saturation. Why is that? It will contribute to my chroma ghosting when I fall into deinterlace mode on unmatched frames. Now turn off the color on your display. You can probably no longer notice the problem. Greedy isn't even used here but the chroma wierdness appears, either in the DivX source or somewhere in the conversions.

How did this file get converted to DivX? And what format was it in before? Can you send me some of it? I'm I don't have any answers to this one yet, but I find something similar every time I go try and shoot this bug.

- Tom

[Blight]

I think DVD2AVI was used on the Bab5 disc.

It's not my encode so I don't have the source...

[Kb_cruncher]

Thanks trbarry for agreat filter.Yours worked for me when all else failed.


see this thread:

http://forum.doom9.org/showthread.php?s=&postid=201767#post201767