sharp icon indicating copy to clipboard operation
sharp copied to clipboard

v0.31.0 - 256 colour palette-based PNG output reverts to full colour (non-palette)

Open FalkNisius opened this issue 2 years ago • 1 comments

Possible bug

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

  • [x] Running npm install sharp completes without error.
  • [x] 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?

  • [x] 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: macOS 12.5.1
    CPU: (8) x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
    Memory: 16.57 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
Binaries:
    Node: 14.19.3 - /usr/local/opt/node@14/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 8.14.0 - /usr/local/opt/node@14/bin/npm

What are the steps to reproduce?

  • take a 24Bit png with a accepatble dimension like 3000x2000px
  • call
const sharpImage = sharp('oldFilename.png')
await sharpImage
        .resize({ width: 800 })
        .png({
            compressionLevel: 8,
            palette: true,
            colors: 256,
            force: true
        })
        .toFile('newFilename.png')
  • the result is bigger in size than the originial
  • the result is more than two times bigger than running the same code with sharp 0.30.7
  • the result is created in nearly the halve time running the same code with sharp 0.30.7
  • I assume the pngquant is not included in the bundled library, or some othe issue

What is the expected behaviour?

  • the newFilename.png should be smaller in size of bytes than the original, like the same operation with sharp.0.30.7 and bundled libvips: libvips-8.12.2-darwin-x64.tar.br

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

  • please look above

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

[[https://nuggets-dev.equeo.de/sites/default/files/2022-04/Agenda_D_2_1.png]]

FalkNisius avatar Sep 07 '22 15:09 FalkNisius

Thanks for reporting, I can reproduce this. It occurs when using a PNG palette with 256 colours (default), and the effect is that the output switches to non-palette.

I think the regression was introduced in libvips v8.13.1 as part of the fix for https://github.com/libvips/libvips/issues/2986

Setting the colours option to 16 (a bit depth of 4) appears to work as expected.

(Note to self: need to add a unit test for 8-bit palette PNG output.)

lovell avatar Sep 07 '22 20:09 lovell

Fixed upstream via https://github.com/libvips/libvips/pull/3031 and test added to sharp via https://github.com/lovell/sharp/commit/1b0eb6ab53219f236ab5dd938e1a561c9bc2eae6

sharp v0.31.1 now available with libvips v8.13.2

lovell avatar Sep 29 '22 14:09 lovell