-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
png resize artefacts related to premultiplication rounding? #4051
Comments
Hi, you can use pipelineColourspace to force the processing colourspace (and therefore force a bitdepth). For example, if you want floating-point RGB, try sharp("path to image")
.pipelineColourspace('scrgb')
.resize(20, 20)
... |
That seemed to do the trick. Thanks a lot! |
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. |
Hi again, and an update on this: We have now run a lot of tests using the |
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. |
Aside: I've removed the "experimental" status of |
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 |
@dannerei Were you able to make any progress with this? |
Unfortunately we were not able to reach satisfactory results in a consistent way using the proposed solution, so for now we're stuck with ImageMagick. I still hope that we can make the transition to sharp sometime in the future though, since it offers superior performance and a very pleasant API to work with. |
What are you trying to achieve?
We develop a product that relies heavily on image processing, and in particular on image resizing. We were previously using ImageMagick for this but wanted to transition to Sharp. Using Sharp 0.31.3 (or earlier), resizing (downscaling) png images with transparency works as expected (i.e the results using Sharp are almost indistinguishable from the results using ImageMagick), but using Sharp >= 0.32.0 downscaled pngs get weird color artefacts at the cross over from opaque to transparent. Our first thought was that libvips had changed something between 8.13 and 8.14, but using libvips directly proved that theory wrong. Hence, our best guess is that the change to "Prefer integer (un)premultiply for faster resizing of RGBA images", introduced in Sharp 0.32.0, is to blame for what we are seeing. If so, would it be possible to add a flag to opt out of using the integer premultiply when resizing?
When you searched for similar issues, what did you find that might be related?
#3658
Please provide a minimal, standalone code sample, without other dependencies, that demonstrates this question
sharp("path to image").resize(20, 20)
Please provide sample image(s) that help explain this question
These images are very small in size and zooming will be required to notice the artefacts I'm referring to. Larger images can be provided if needed.
Original (100x100)
Resized using Sharp 0.31.3 (20x20)
Resized using Sharp 0.33.3 (20x20). Notice the discoloring of the top opaque pixel row.
The text was updated successfully, but these errors were encountered: