0.32.5 - wrong color space / depth

[RadekHavelka]

Hello, our code stoped working after upgrading from 0.32.1 to 0.32.5. I've found issue similar in previous versions

#3605

our code, relevant part

 const readStream = this.storage
      .bucket(bucketName)
      .file(sourceCloudFilename)
      .createReadStream();

    const writeStream = this.storage
      .bucket(bucketName)
      .file(targetCloudFilename)
      .createWriteStream();

const transformStreamSharp = sharp({
      sequentialRead: true,
      failOnError: false,
    })
      .withMetadata()
      .toColorspace('rgb16')
      .png({
        compressionLevel: 5,
      })
      .trim()
      .toBuffer((_err, _buffer, outputInfo) =>
        this.uploadTrimmingInfo(trimInfoCloudFilename, bucketName, outputInfo),
      );
      
      await streamPromises.pipeline(
      readStream,
      transformStreamSharp,
      writeStream,
    );

Expected result: image with 16bit color depth
Actual result: image with 8bit color depth

(input data are ofc the same, image with 16bpc)

I think the function ".toColorspace('rgb16')" has some issues in recent version.

[lovell]

Hi, thanks for reporting, this is a regression in v0.32.5 due to the change for #3761. This is fixed by commit 9563568 that also adds a test to prevent further regression.

[7freaks-otte]

@lovell are you sure this is related to #3761 and v0.32.5?

I am still on v0.32.4 and the following code correctly generates a 16bit sRGB PNG

await sharp('test_p3-16bit.png')
  .pipelineColourspace('rgb16')
  .toColourspace('rgb16')
  //.withMetadata({ icc: 'p3' }) //this reduces 16bit to 8bit
  .resize({ width: 800, height: 800 })
  .png({ progressive: false, force: true })
  .toFile('test_out.png');

But as soon as withMetadata is uncommented, the output file will be an 8bit P3 PNG

It also affects raw() output when I'm trying to use the workaround #2910 (comment) to strip the original exif data

const { data, info } = await sharp('test_p3-16bit.png')
  .pipelineColourspace('rgb16')
  .toColourspace('rgb16')
  //.withMetadata({ icc: 'p3' }) //this reduces 16bit to 8bit
  .resize({ width: 800, height: 800 })
  .raw() //trying to force { depth: 'ushort' } breaks output
  .toBuffer({ resolveWithObject: true });
await sharp(data, { raw: info })
  .pipelineColourspace('rgb16')
  .toColourspace('rgb16')
  //.withMetadata({ icc: 'p3' }) //this reduces 16bit to 8bit
  .png({ progressive: false, force: true })
  .toFile('test_out.png');

Interestingly when omitting withMetadata({ icc: 'p3' }) the 16bit sRGB output in the first code block narrowed the gamut but the logo in the test file is still visible while with raw and toBuffer in my second code block clipped the out-of-gamut logo and produces a solid red rectangle.

Test file:

[lovell]

@7freaks-otte You've run into libvips/libvips#3558, the fix for which will be included in the future libvips 8.15.0 (and therefore a future version of sharp).

[7freaks-otte]

@lovell Thanks for the clarification, looking forward to seeing fixed this in the future. Any plans when this could arrive?

[lovell]

I've applied the equivalent of the upstream libvips fix to sharp ahead of libvips 8.15.0 being made available as doing so also simplifies the fix for the original issue - see follow-up commit 9c217ab

[lovell]

v0.32.6 now available, thanks for reporting.