Aliasing problem due to shrink-on-load(?)

I discovered this bug by chance while testing some images. See this testcase:

const sharp = require("sharp");

sharp('test_800x600.jpg')
  .resize(400)
  .toFile('test_800x600_aliasing.jpg');

^{(original picture can be downloaded from here)}

Output (tested with sharp v0.17.3): ^{(nasty aliasing artifacts at the roof)}

Expected output: ^{(with vipsthumbnail)}

The thumbnail operator from libvips has fixed this by leaving at least a factor of two for the final resize step. See thumbnail.c#L203-L217, and the wiki.

While looking at the source code of sharp, I noticed that the shrink-on-load doesn’t take this into account. See pipeline.cc#L230-L241.

In an attempt to fix this, I came to this patch (line 230-241 in pipeline.cc):

-        if (xshrink >= 8) {
+        if (xshrink >= 16) {
          xfactor = xfactor / 8;
          yfactor = yfactor / 8;
          shrink_on_load = 8;
-        } else if (xshrink >= 4) {
+        } else if (xshrink >= 8) {
          xfactor = xfactor / 4;
          yfactor = yfactor / 4;
          shrink_on_load = 4;
-        } else if (xshrink >= 2) {
+        } else if (xshrink >= 4) {
          xfactor = xfactor / 2;
          yfactor = yfactor / 2;
          shrink_on_load = 2;
        }

But that doesn’t seem to work (maybe I’m missing something).

[lovell]

Commit e398b47 adds the dynamic shrink(-on-load) behaviour to ensure a kernel-based reduction will always occur. This will be in v0.18.0. Thanks again for your original, well-written report about this.

[lovell]

“worth experimenting with applying this change only when there will be no floating point residual”

Quick update: I’ve got a prototype working that dynamically varies the use of shrink-on-load and box shrink based on the level of kernel-based reduction. The tl;dr is “same high performance most of the time, occasionally take a slight performance hit to ensure high quality”.