Output of profile conversion in combination with `negate` seems off about sharp HOT 4 OPEN

My best guess would be that this relates to (a lack of) gamut.

Does the following change help? It should ensure the input CMYK profile is respected when present, preventing the narrower, built-in CMYK profile being introduced and therefore allow the removal of pipelineColourspace(), which is hopefully a bit simpler (and matches your "Attempt 1" example).

--- a/src/pipeline.cc
+++ b/src/pipeline.cc
@@ -348,6 +348,7 @@ class PipelineWorker : public Napi::AsyncWorker {
         baton->colourspacePipeline != VIPS_INTERPRETATION_CMYK
       ) {
         image = image.icc_transform(processingProfile, VImage::option()
+          ->set("embedded", TRUE)
           ->set("input_profile", "cmyk")
           ->set("intent", VIPS_INTENT_PERCEPTUAL));
       }

It's also possible that Photoshop's idea of inverting CMYK values is different to libvips. In addition sharp always tells the underlying lcms to use perceptual rendering intent, which might differ from Photoshop's treatment.

from sharp.

Thanks for the suggestion. I've did some tests without negating to see if the built-in CMYK profile is introduced by comparing with the output from vips.

Attached a 1000x1000 tiff file with all pixels set to 0 / 100 / 100 / 0 with embedded profile Coated Fogra39.

# Get source pixel value (output: 0 255 255 0)
vips getpoint fogra.tif 0 0

# Convert to U.S. Web Coated (SWOP) v2
vips icc_transform fogra.tif swop.tif swop.icc

# Get destination pixel valuex (output: 10 255 255 1)
vips getpoint swop.tif 0 0

The destination pixels match exactly those of Photoshop when converting to the SWOP profile using relative colorimetric intent and black point compensation turned off (= the defaults of vips icc_transform).

I did the same icc transform using sharp with every combination oftoColourspace and pipelineColourspace:

await sharp('fogra.tif').toColourspace('cmyk').pipelineColourspace('cmyk').withIccProfile('swop.icc').toFile('swop1.tif');
await sharp('fogra.tif').toColourspace('cmyk').withIccProfile('swop.icc').toFile('swop2.tif');
await sharp('fogra.tif').pipelineColourspace('cmyk').withIccProfile('swop.icc').toFile('swop3.tif');
await sharp('fogra.tif').withIccProfile('swop.icc').toFile('swop4.tif');

Here's the output pixel values:

After applying your code change in pipeline.cc, I see no change in these output values so I suspect the built-in CMYK profile is still being introduced somehow.

Happy to test any other suggestion.

from sharp.

Thank you, this is useful info, and points to the difference being rendering intent:

$ vips icc_transform fogra.tif swop.tif swop.icc --intent=perceptual
$ vips getpoint swop.tif 0 0
25 255 255 4 

sharp uses perceptual intent to try to avoid too much visually-obvious gamut clipping, but this can come at the cost of saturation levels, which from these examples appears to adversely affect CMYK-to-CMYK transformations.

Maybe we should switch to always using relative intent when transforming CMYK images?

from sharp.

Thank you for taking a look at this. I have tested the initial bug and played around in pipeline.cc by moving the image.icc_transform which is triggered by the withIccProfile parameter to the beginning of the pipeline.

It seems that when the conversion happens before the negate that the right result is produced.

So in the case below, when withIccProfile is set on the sharp instance before the negate. I think the conversion should happen before the negate operation is executed.

await sharp('tiger-cmyk-fogra.tif')
  .toColourspace('cmyk')
  .pipelineColourspace('cmyk')
  .withIccProfile(swopPath)
  .negate()
  .toFile('tiger-cmyk-swop-inverted-attempt4.tif');

Place in the pipeline where the conversion to ICC happens:

Negate works when moved to:

I hope this helps! Thanks again for your help.

from sharp.