BiCubicResize versus BilinearResize

[ritmo2k]

OK, the manual says BiCubicResize(x,y,0.333,0.333) is the best for BiCubicResize. Everyone seems to use the vdub one, BiCubicResize(x,y,0.0,0.75).

Also the manual says if your going down, use BilinearResize, its even better!

So WTF? Which one is best, and if its BiCubicResize, which params are best. i am encoding 3 flix tonight with each to test, but i am doubtfull Ill notice!

Whats you guys opinion?

[western shinma]

0,0.5 is what I usually use (or 0.6 in VirtualDub). If I'm doing VCD I might use 0,0.75 to make it a bit sharper. .333,.333 is too blurry for my tastes, as is bilinear.

[philippas]

With the bilinear resize the movie becomes more compressible.
If the movie is not very clean you will see the noise easier with bicubic resize.
For 1 cd go always for bilinear. For 2 cd's if the movie is very clean and short in length choose soft bicubic or neutral bicubic. I rarely use sharp bicubic.

[jarthel]

have a look at nicky's guide. His explanation is very clear.

[dinesh]

Yes, The thumb rule is use BilinearResize for reducing and BiCubicResize for Enlarging.

[rmatei]

I have to disagree with dinesh that bilinear is best for downsizing. My personal preference is:
- Bilinear for harder 1cds
- Bicubic 0.333,0.333 for regular 1cds
- Bicubic 0,0.5 for harder 2cds
- Bicubic 0,0.75 for the best quality 2cds.
- Noisy movies are an exception, I usually use bilinear regardless on those.

Nobody can argue that bicubic is a must for enlarging. The reason why some only recommend it for enlarging and not downsizing is that when you downsize a lot (>400 width) it produces some stairstepping effects on inclined lines and other very sharp areas. Still, IMHO that's only a concern for image processing and that sort of thing, and I don't have a problem using bicubic for any resolution.

And one last thing, ritmo2k, you will notice the difference very easily when you play back full screen.

[dinesh]

Thanks rmatei. I am sorry , I had just quoted something I had read somewhere. I shall take note of your recommendations.

[daxab]

@rmatei

Can you give any clues as to how you arrived at your guidelines? Was this trial and error? What's your sense of what the two bicubic parameters do?

[daxab]

I was curious so I looked into the bicubic resize some more. The bicubic resize comes from frequently quoted paper by Mitchell and Netravali. The two parameters, b and c, are sometimes referred to as `blurring' and `ringing,' respectively. With settings b = 0, c = 0.5, you get a Catmull-Rom filter -- I don't know what that means, but apparently it's a well-established spline with good characteristics. Mitchell and Netravali themselves recommend b = 1/3, c = 1/3 as good general-purpose values.

I'm somewhat suspicious of b = 0, c = 0.75, as this will definitely produce ringing, according to the original paper. I believe in a 2-d resize this will show up as shadows around sharp edges -- something I have definitely seen with b = 0, c = 0.75.

[DDogg]

Steady spoke to this subject at length several months ago. I believe 0,50 was settled on as the best compromise. Try the search feature and look at his posts in this forum and the gknot forum.

.75 was judged too "hot" for most encoding jobs. Personally I use .60 on anything using bicubic.

[trbarry]

I had thought Bilinear would have been good for downsizing but when I looked at the code it appeared it was maybe softer than it would hve to be. I'd rather add a filter if I wanted to soften and much material is already somewhat filtered.

So I just used a 2 tap linear interpolation for downsizing faster with SimpleResize.

...

Since everyone is talking about resizing here, let me ask a question.

Is there any demand for an InterlacedResize that could work BEFORE IVTC or deinterlace? That's usually not a good idea but I noticed today I'd be able to add it with not much code in a way we could get probably away with it. It might even be enough that DivX4 could handle the interlaced results for some cases, but I'm not sure how that works. Just an idea.

- Tom

[Antti]

Vertical resizing with interlaced material isn't possible in theory. Yes, you can do SeparateFields(), resize and then Weave(), but the result isn't correct. Usually you won't see that, though.

[trbarry]

Well, I was thinking about it and it should be possible but needs just a small amount of special purpose code. It would not give you the same answer as separate/resize but it (I think) should work.

Just look at the pixels as sample points on a graph, a whole frame at a time. You interpolate an odd output pixel value based only upon odd input samples, etc., but using the coordinates of the whole graph. The results of this shouldn't confuse a subsequent IVTC/deinterlace much. And in some cases it might be useful. But maybe not. In any event I'll only have to add a very few lines of code to SimpleResize to make InterlacedResize so instead of speculating I may just try it and see.

But assume for speculation that it was possible and I could even do it correctly (you never know ;) ). Would it then be useful to anyone?

- Tom

[daxab]

I assume the reason you would want this is if you were time-limited and wanted to feed a smaller frame to a subsequent IVTC algorithm. Then it would be useful.

Another reason you would need this is if you wanted to resize but preserve interlacing. So if someone wanted to encode interlaced video to MPEG-2 with a smaller vertical size, such a resize would be useful.

[trbarry]

The whole DeinterlacedResize idea was a result of an argument over on Avscience forum (which I pretty much lost) about how to display video sourced interlaced DVD's if you were upscaling to a 1080i display. It seemed to me that the current DVD players didn't handle video source very well and didn't often have the extra cpu resources to properly deinterlace it.

So I asked why the graphics hardware couldn't do an interlaced resize and was fairly soundly lectured. But when I finally wrote a faster resize routine I thought about that again and realized that it was not only possible, but easy, with no real complexity or performance penalty.

So it was just a question of whether to bother. But I did read that DivX4 had rudimentary support for interlaced source and warned not to resize first. So I thought this might be useful there.

Also, depending upon the function used, it's possible (dunno?) that SimpleResize might be faster than IVTC/deinterlace. In this case it would be maybe faster to downsize first and do IVTC/deinterlace on a smaller result. Since I often start with 1920x1088i digital captures that are just pig slow to process it seemed worth a shot.

- Tom

[DJ Bobo]

@ trbarry
Well, if it really works, it's gonna be great! I think, the increase in speed will be considrable! it would be "the mp3 for resizing" :D

[manono]

Hi
I believe that what you're referring to is sometimes called Edge Enhancement. Although I don't use the Bicubic Resize 0.75 setting (I'm with DDogg and Western Shinma), and for all I know, that setting can introduce the ringing you refer to, it's not necessarily introduced by that Sharp Bicubic setting, but by the source material itself.

The Hollywood studios, in order to save on bit rate, will soften-smooth the movies when being mastered for DVD, and to counter that will then artificially sharpen them afterwards, thus producing the ringing. Maybe you've seen this page before:

Edge Enhancement (http://home.t-online.de/home/bjoern.roy/Guide_EE/Html/Page_01.htm)

But I found it a bit of an eye opener when I first came across it. And if SharpBicubic(0,0.75) also produces that stuff, then I think that's reason enough to keep away from it.

[daxab]

@manono

Thanks for the link, Manono -- great stuff. I hadn't seen that before, and after reading the page, I realize that a lot of what I've been seeing is Edge Enhancement inherent in the DVD transfer itself. And I thought it was my DVD player, or my TV, or the resizing algorithm, or... By the way, they do refer to the halos and shadows as ringing artifacts, so we're talking about the same thing here.

Slightly off the topic of resizing, but on the topic of DVD quirks: I recently was doing an anime encode and at one point I noticed that a character froze and got pixely -- it looked like he went to half resolution for a second or so. I thought it might be something funky with the IVTC plugin I was using, so I went and looked at the DVD source itself -- and the freeze and derez was right there in the original source. I've seen this before in anime; it must be a glitch in the way DVD transfers are done on anime.

[manono]

Yep-EE, ringing, echoes,shadows, halos-all the same thing. My TV isn't good enough to generally spot the stuff, but now that I know how to look for it, I can sometimes see it.

I've noticed similar things as you on anime DVDs as well, and recently after encoding some Battle Athletes Victory, I noticed all this crud appearing at the bottom or the top of frames right around a keyframe, and just as you, I didn't know what to blame (I also thought it was the IVTC)-but it was in the DVD. And quite a few scenes in various Cowboy Bebop episodes sort of shimmer or flash, from jagged lines every so often. And although bad IVTC can create it, I discovered that quite a bit is on the source DVD as well (thanks DG).

I think as more people get high end HDTVs and can see artifacts of different kinds more easily, that the consumer won't stand for that stuff any longer (or will buy more Superbits type DVDs), and more care will be taken in the production of DVDs. But I agree that the anime DVD creators are particularly guilty of putting out bad product.