Enhancement: more complete magicksave support

[Saraiby]

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.

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.

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

  System:
    OS: Linux 6.1 Debian GNU/Linux trixie/sid
    CPU: (8) x64 Intel(R) Core(TM) Ultra 9 185H
    Memory: 6.67 GB / 7.72 GB
    Container: Yes
    Shell: 5.2.15 - /bin/bash
  Binaries:
    Node: 20.18.0 - /usr/local/bin/node
    Yarn: 1.22.22 - /usr/local/bin/yarn
    npm: 10.8.2 - /usr/local/bin/npm
  npmPackages:
    sharp: ^0.33.5 => 0.33.5 

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. Install sharp into empty project with custom libvips and ImageMagick on debian 12.
2. Read a bmp image.
3. resize the image and toBuffer.
4. Failed with messages:

> test-sharp@1.0.0 start
> node ./src/index.js

test
{
  format: 'magick',
  width: 363,
  height: 363,
  space: 'srgb',
  channels: 3,
  depth: 'uchar',
  density: 72,
  isProgressive: false,
  pages: 1,
  resolutionUnit: 'cm',
  formatMagick: 'BMP3',
  hasProfile: false,
  hasAlpha: false,
  orientation: 1
}
/root/test-sharp/node_modules/sharp/lib/output.js:163
  const stack = Error();
                ^

Error: Unsupported output format magick
    at Sharp.toBuffer (/root/test-sharp/node_modules/sharp/lib/output.js:163:17)
    at test (/root/test-sharp/src/index.js:17:6)

Node.js v20.18.0

What is the expected behaviour?

Could save bmp image to buffer or to file with ImageMagick support.

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

    let origImg = sharp(imgPath);
    console.log(await origImg.metadata());

    let newImg = await origImg.resize({ width: 200, height: 200, fit: "outside", background: { r: 255, g: 255, b: 255, alpha: 1 } })
    .toBuffer();

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

[lovell]

Although #1372 partially relates to this, it was only ever really needed for GIF output, and there's a dedicated non-magick solution for doing this now.

Rather than re-open #1372 let's use this issue to track a more complete implementation of magicksave and magicksave_buffer. It will require exposing its format option, which might lead to a slightly confusing API as the sharp "format" will still be the value "magick" (rather than the magick "format" of the desired output format e.g. "bmp").

[Saraiby]

Although #1372 partially relates to this, it was only ever really needed for GIF output, and there's a dedicated non-magick solution for doing this now.

Rather than re-open #1372 let's use this issue to track a more complete implementation of magicksave and magicksave_buffer. It will require exposing its format option, which might lead to a slightly confusing API as the sharp "format" will still be the value "magick" (rather than the magick "format" of the desired output format e.g. "bmp").

how about:

1. Wrap magick* invoking in sharp toFile and toBuffer.
   Sharp automatically invokes magicksave and magicksave_buffer, when the target format is not supported by sharp but is supported by *Magick.

2. Add a prefix to the formats supported by Magick, such as "magick_bmp".
   This may also impact on sharp.format:FormatEnum.