MPCVR-Plus 1.9

MPCVR-Plus 1.9

Since 1.8 (865a7c4). Measured with the tools in tools/dlssnr_probe, on an RTX 3050.

Fixed: the Upscaling network ran on pictures it had nothing to enlarge

1.8 has this bug; please replace it. With FSRCNNX, RAVU-zoom or ArtCNN chosen, the network
ran on a film shown at its own size — 4K on a 4K screen — and on a film being reduced. In both
it doubled the picture for the resize shaders to bring straight back down: its whole cost, and
a worse picture than leaving it alone. The Scaling line did not name it; the prescale line gave
it away.

It came from lifting mpv's 1.3x threshold in 1.8, which lifted the direction along with it.
An enlarger now runs only where there is something to enlarge:

picture	what runs
shown at its own size	nothing
grows on one axis or both, however little	the Upscaling method you chose
shrinks	the Downscaling method
grows on one axis, shrinks on the other	one classic kernel an axis

One axis is enough: a PAL film is 720x576 shown at 768x576, enlarged in width alone, and it
gets the chosen method.

A lighter filter for small enlargements

That rule makes one case expensive. A 4K film cropped to 3838 across on a 3840 screen is an
enlargement, by a twentieth of one per cent, and a network doubles its source whatever the
target is: at 3836x2160 to 3840x2160, FSRCNNX 16 AR worked at 7672x4320 for about a second a
frame and skipped half of them.

Use a lighter filter for small enlargements, under Upscaling, with the same list of
filters. Ticked, that list is used whenever the picture grows by less than 5 % on both axes,
and the method above it everywhere else. In the same place RAVU-zoom took 21.4 ms and skipped
nothing, and Jinc2m cost nothing worth measuring. It goes by the ratio and not by the size, so
it holds on any screen. Off by default; the statistics name the method really in use.

The Downscaling list, ranked by measurement

Each downscaler was asked the two questions it exists to answer, on the shaders that ship: how
much of the detail that still fits does it keep, and how much of the detail that no longer
fits does it let fold back as aliasing — which is what crawls when the picture moves. The test
pictures are sinusoids whose correct reduction is known in closed form, so no reference
resizer is involved. 4K reduced by two; error is the root mean square of all six.

	kept 0.125	kept 0.250	kept 0.375	folded 0.60	folded 0.75	folded 0.90	halo	error
Lanczos	1.003	1.010	0.881	0.178	0.010	0.004	0.045	0.087
Bicubic sharp	1.063	1.118	0.936	0.136	0.118	0.044	0.075	0.097
Spline36	1.000	0.993	0.856	0.200	0.007	0.004	0.040	0.101
Bicubic	0.995	0.941	0.772	0.276	0.058	0.004	0.025	0.150
Bilinear	0.962	0.853	0.691	0.346	0.146	0.024	0.000	0.208
Hamming (default)	0.968	0.880	0.748	0.467	0.303	0.204	0.000	0.268
Box	0.981	0.924	0.831	0.588	0.382	0.153	0.000	0.303

The list is in that order now. The top three are within fifteen per cent of each other and
differ in taste: Spline36 is the flattest and rings least, Bicubic sharp folds least and adds
contrast the source did not have, Lanczos sits between them. The four below are not close.

This corrects 1.8, which called Spline36 the best from the shape of the kernels alone; that
reading did not count what each lets fold back.

Hamming, the default, is sixth of seven. It is upstream's default and is left where it is;
if you reduce often, pick one of the top three.

Your saved choice is kept: the list used to save the position it sat on and now carries its
value, which is what let it be sorted.

Also

• dlssnr_harness --tdownport checks that the downscaling shaders that ship are the kernels
  they are written from: the compiled objects the filter embeds, on the GPU, against the same
  convolution in double on the CPU. All seven agree to about one step of half float.
• dlssnr_harness --tdownscale is the ranking above; playback_test --small N exercises the
  lighter filter.

x64 and Win32, zero warnings.