`pipelineColourspace` with a device-independent colourspace has incorrect color management

[mertalev]

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 "import '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 26.5
    CPU: (14) arm64 Apple M4 Max
    Memory: 672.61 MB / 36.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.15.0 - /Users/mertalev/.local/share/mise/installs/node/24.15.0/bin/node
    npm: 11.12.1 - /Users/mertalev/.local/share/mise/installs/node/24.15.0/bin/npm
    pnpm: 11.22.0 - /Users/mertalev/.local/share/mise/installs/pnpm/11.22.0/pnpm
  npmPackages:
    sharp: ^0.35.4 => 0.35.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?

Using an image with an ICC profile as input, set a device-independent pipeline colourspace like pipelineColourspace('xyz'). The conversion produces incorrect colours / garbage.

Part of this is because sharp runs EnsureColourspace before icc_transform, so the input is treated as sRGB. The other part is that when icc_transform does happen, lcms is handed device-independent float input when it expects device-dependent integer input.

What is the expected behaviour?

It should transform to the pipeline colourspace using the embedded ICC profile and produce correct colours as output.

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

import sharp from 'sharp';

const raw = { width: 8, height: 8, channels: 3 };
const data = Buffer.alloc(8 * 8 * 3);
for (let i = 0; i < data.length; i += 3) data.set([200, 60, 30], i);

// one colour, encoded two ways
const srgb = await sharp(data, { raw }).png().toBuffer();
const p3 = await sharp(data, { raw }).png().withIccProfile('p3').toBuffer();

const render = async (src) => [...await sharp(src).pipelineColourspace('xyz').raw().toBuffer()].slice(0, 3);
console.log('from P3:  ', await render(p3));
console.log('from sRGB:', await render(srgb));

Output:

from P3:   [ 23, 14, 2 ]
from sRGB: [ 200, 60, 30 ]

This affects scrgb, xyz, yxy, lab, labs and lch; srgb and rgb16 are fine.

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

The code above works without a sample, but test/fixtures/p3.png reproduces the same issue: pipelineColourspace('srgb') gives 255,0,0, 'xyz' gives 39,17,0.

Additional info

#1317 is relevant as it described using the XYZ connection space to handle embedded input profiles. It seems that part never landed for pipelineColourspace.

The motivation of the change is to do resampling in linear-light to address this issue, which proved to be non-trivial in sharp.