png resize artefacts related to premultiplication rounding? about sharp HOT 8 OPEN

that feature is experimental, so can we rely on it?

Experimental insofar as there are probably still some untested code paths, with the aim to add more test cases as bugs are found and fixed. I don't expect to remove this feature.

from sharp.

Aside: I've removed the "experimental" status of pipelineColourspace via commit f67228e

from sharp.

Hi, you can use pipelineColourspace to force the processing colourspace (and therefore force a bitdepth).

For example, if you want floating-point RGB, try scrgb:

sharp("path to image")
  .pipelineColourspace('scrgb')
  .resize(20, 20)
  ...

from sharp.

That seemed to do the trick. Thanks a lot!
One thing though. According to the documentation that feature is experimental, so can we rely on it?

from sharp.

Hi again, and an update on this:

We have now run a lot of tests using the pipelineColourspace('scrgb') setting, and although the originally reported rounding artefacts are gone, we have noticed that the resulting images look sharpened in a way that is not to our liking. Especially in transitional areas between bright and dark, the edges get unrealistically sharpened. Therefore I ask again, would it be possible to add a flag to opt out of using the integer premultiply when resizing (the 0.31.3 behaviour)?

from sharp.

we have noticed that the resulting images look sharpened in a way that is not to our liking

Please can you provide sample images and minimal code that allows someone else to reproduce. Please also include more information about expected vs actual output.

from sharp.

Here are a few samples using sharp 0.33.3 with and without pipelineColourspace. We expected the outputs to be very similar, but as can be seen there are major differences in the actual results.

Resize sample 1:

Original image:

Result using sharp("path to image").resize(240, 240)

Result using sharp("path to image").pipelineColourspace('scrgb').resize(240, 240)

Resize sample 2:

Original image:

Result using sharp("path to image").resize(240, 240)

Result using sharp("path to image").pipelineColourspace('scrgb').resize(240, 240)

from sharp.

Thanks for the examples, my best guess would be that the use of wide-gamut, linear scRGB is producing more accurate luminance levels in the output compared with non-linear sRGB.

If you would prefer less accurate luminance, perhaps try experimenting with gamma levels e.g. in=2.2, out=1.0.

from sharp.