[MPlayer-users] lanczos or bicubic spline or..?

[D Richard Felker III]

On Wed, Feb 04, 2004 at 01:21:21PM -0800, * wrote:
> --- D Richard Felker III <dalias at aerifal.cx> wrote:
> > On Tue, Feb 03, 2004 at 10:56:52PM -0800, * wrote:
> > > --- D Richard Felker III <dalias at aerifal.cx> wrote:
> > > > On Sun, Feb 01, 2004 at 11:11:05PM -0800, * wrote:
> > > > > Thanks (again) Rich!  I think I'm a little less confused now.  I don't
> > > > > know if this is complete nonsense or not, but I ran a test upscaling 10
> > > > > times in a row to compare:
> > > > >
> > > > > mplayer movie.vob -nosound -vo png -vf crop=716:452:0:12,
> > > > > scale=720:384,scale=736:400,scale=768:416,scale=800:432,scale=832:448,
> > > > > scale=864:464,scale=896:480,scale=912:496,scale=944:512,scale=976:528
> > > > > -sws #
> > > >
> > > > IMO this is not a legitimate test. When encoding a movie you don't
> > > > scale 8 times, and you especially should never upscale. Try it with
> > > > just _one_ scale filter, to the size you'll actually be encoding, and
> > > > compare the results.
> > > >
> > > > Also, compare the results _after_ encoding to mpeg4, since that's what
> > > > will ultimately matter.
> > > >
> > > Okay, thanks for walking me through this.  With one scale filter there
> > > are the following PSNR:
> > >
> > > mencoder movie.vob -nosound -ovc lavc -lavcopts psnr:mbd=2:mv0:trell:
> > > cbp:precmp=2:cmp=2:subcmp=2:vmax_b_frames=1:predia=2:dia=2:preme=2:
> > > vme=4:v4mv:vbitrate=875 -vf scale=976:528 -ss 360 -frames 360 -sws #
> >
> > Why on earth are you upscaling your movie to encode it?? This will
> > only hurt the quality. Either leave the size alone and encode aspect
> > (but broken players won't support this), or scale it down to a
> > reasonable size. There's no way you'll get remotely tolerable quality
> > at 875 kbit/sec for 976x528 video. You'd need at least 2mbit. The only
> > reason the first few frames look ok is that the rate control hasn't
> > had time to kick in yet.
> >
> Sorry that was just to make the difference more visible.  For the movie
> above I would have used:
> 
> -vf crop=716:452:0:12,scale=720:384
> 
> But in fact I have never been sure what the proper scale should be.
> Whether I should always scale x/y so BOTH are smaller than the cropped
> x/y, or whether I should pick a value of y close to the cropped value
> and scale x accordingly.
> 
> It seems like the latter would preserve the most detail.  But then the
> bits will be spread out over a larger area.  I wish there was an
> objective way to find the optimum scaling.  I'm pretty sure I can't rely
> on PSNR (from lavc)- when I try scaling to 320x192 the PSNR reported is
> always higher than 720x384.

Unless you're going to use really high bitrates, you'll lose more
quality from bit starvation than you gain from keeping high
resolution. The basic principle for encoding a 1disc rip is to
_always_ use 640xHHH where HHH is the height that matches aspect,
rounded to the nearest multiple of 16.

If you're making a 2disc or even 3disc rip (or if your movie is very
short), then you can consider doing fancy stuff like keeping the full
resolution. But if you want to keep the full vertical resolution, you
_must_ either scale up horizontally to 860 or 976 or whatever (very
bad!) or use the aspect tag (not supported by all players).

Why is upscaling bad? It wastes a huge amount of space and makes your
movie impossible to play except on high-end hardware.

Personally my recommendation is almost always to drop down to 640xHHH.
The added quality you get from encoding fewer blocks seems to greatly
outweigh the loss in resolution.

> > > It is impossible for me to tell the difference between (2) and (6).  But
> >
> > (2) and (6) behave identically on the luma, but treat the chroma
> > differently. (2) uses bicubic scaling for both while (6) uses simple
> > bilinear scaling for chroma. This is both faster and makes more sense
> > usually, since chroma samples are too far apart for bicubic
> > interpolation to be reasonable.
> >
> Interesting.  Who knew?  I guess I should look for a simple book about
> this.

OK, here's a picture. X's are luma sample points, *'s are chroma
sample points:

X X X X X X X X
 *   *   *   *
X X X X X X X X

X X X X X X X X
 *   *   *   *
X X X X X X X X

Digital video is basically always sampled this way because the human
eye is not nearly as sensitive to color variation as to light
intensity, and it saves a lot of space. All mpeg-type formats use this
sampling.

Anyway, linear interpolation just interpolates between two sample
points in the source with a linear function. Cubic interpolates
between _four_ sample points by matching a third-order polynomial
curve to them. But since chroma samples are not very close to one
another, it's very possible that these extra 2 points you'd be using
in the cubic interpolation really don't tell you anything worthwhile,
and for practical purposes they'd just be noise. Of course in practice
this depends on the resolution and how much fine detail your picture
has.

> > There are many ways to measure "quality", which is a very subjective
> > term. One of them is by how much information is lost, i.e. how closely
> > you can recover the original image by inverting the scale operation.
> > Sinc will naturally win for this measure, but from a perceptual
> > standpoint, it looks very bad.
> >
> > A second, more reasonable way to measure quality would be according to
> > how good it looks to you, but this is very hard to measure without
> > double-blind (or multi-blind) testing.
> >
> Argh, this is not what I wanted to hear but thanks.  What if I am going
> blind and still want to encode movies for other people?  It seems like
> there should be some metric for measuring how much detail is preserved,
> or something like that.  I think I prefer a little bit of blockiness and
> more detail over a smoother picture with less detail.

OK, tell us a very good one and we'll give you a Ph.D! :)))))))))))

Maybe a Nobel prize in biology or whatever cognitive science falls
under, too..??   :)))))))))))))))))))

Rich