Trimming artifacts on the right side of small images

[wyanido]

Possible bug

Is this a possible bug in a feature of sharp, unrelated to installation?

• Running npm install sharp completes without error.
• Running node -e "require('sharp')" completes without error.

If you cannot confirm both of these, please open an installation issue instead.

Are you using the latest version of sharp?

• I am using the latest version of sharp as reported by npm view sharp dist-tags.latest.

If you cannot confirm this, please upgrade to the latest version and try again before opening an issue.

If you are using another package which depends on a version of sharp that is not the latest, please open an issue against that package instead.

What is the output of running npx envinfo --binaries --system --npmPackages=sharp --npmGlobalPackages=sharp?

System:
OS: Windows 11 10.0.22631
CPU: (20) x64 13th Gen Intel(R) Core(TM) i7-13700H
Memory: 20.07 GB / 31.53 GB
Binaries:
Node: 20.11.0 - C:\Program Files\nodejs\node.EXE
npm: 10.2.4 - C:\Program Files\nodejs\npm.CMD
npmPackages:
sharp: ^0.33.4 => 0.33.4

Does this problem relate to file caching?

The default behaviour of libvips is to cache input files, which can lead to EBUSY or EPERM errors on Windows.
Use sharp.cache(false) to switch this feature off.

• Adding sharp.cache(false) does not fix this problem.

Does this problem relate to images appearing to have been rotated by 90 degrees?

Images that contain EXIF Orientation metadata are not auto-oriented. By default, EXIF metadata is removed.

• To auto-orient pixel values use the parameter-less rotate() operation.

• To retain EXIF Orientation use keepExif().

• Using rotate() or keepExif() does not fix this problem.

What are the steps to reproduce?

1. Import a 32x32 PNG image with some whitespace into sharp
2. Attempt to crop the image to only the opaque pixels with .trim()
3. The resulting image will sometimes have stretched pixels on the right side, or may have trimed any opaque floating pixels entirely

What is the expected behaviour?

The image should be trimmed to remove whitespace from all edges, only containing the unmodified opaque area without removing floating pixels or stretching the right edge.

Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this problem

const sharp = require("sharp");

sharp("input.png")
  .trim({
    threshold: 10,
    background: { r: 0, g: 0, b: 0, alpha: 0 },
    lineArt: true,
  })
  .png({
    colours: 16,
    palette: true,
  })
  .toFile("output.png");

Please provide sample image(s) that help explain this problem

Original image

Trimmed image, with edge artifact

Expected output

[wyanido]

After testing some more, it only seems to occur when specifying max colours between 9 and 129 when using .png(). If a number of colours isn't specified at all, it seems to output the expected result consistently.

[lovell]

These look like dithering artefacts when mapping pixel values to a palette-based PNG. For line art you can usually reduce/remove these via .png({ dither: 0 }).

https://sharp.pixelplumbing.com/api-output#png