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

[FalkNisius]

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: 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]]

[lovell]

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 libvips/libvips#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]

Fixed upstream via libvips/libvips#3031 and test added to sharp via 1b0eb6a

sharp v0.31.1 now available with libvips v8.13.2