-
-
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
Add pipelineColourspace operator #2704
Conversation
So the coverage report lists the On another note, while all the tests pass with this branch since you have to explicitly opt-in to a potentially higher bit depth pipeline via the operator, I also decided out of curiosity to try what happens if I set
Looking at the overall results, I think the general outcome can be categorized into a few different pools:
Someone more familiar with the codebase can probably weigh in on these, though I'd like to reiterate that all the failing tests I just talked about only pop up if you set |
Thank you very much for this PR, I will make some time for a proper review of the code and your detailed notes (thank you) as soon as I can. |
Quick update: I haven't forgotten this PR, but sadly have been rather busy during the last month to dedicate time for the review that this improvement deserves. ❤️ |
Thanks again, I've finally made/found some time to review PRs and this all looks great. I plan to merge this into the |
Landed via commit 8ad02e6 - thank you very much for this, it will be part of v0.29.0. |
Lovely! Looking forward to retiring my previous double pipeline hack in favor of this when 0.29 is out 🎉 |
This pull request adds a new operator:
pipelineColourspace
(and a pairing aliaspipelineColorspace
). You can use it like such:Currently, sharp runs the pipeline in the colorspace of the input image, which means that if you feed sharp an image with 8 bits per channel (bpc), it will process the image in 8bpc, and similarly with 16bpc input the pipeline will run in 16bpc. This operator provides control over the pipeline colorspace independent of the input image, allowing the user to easily run the pipeline in 16bpc even with 8bpc input. This is relevant eg. if you want to avoid banding issues when using the gamma operator.
While this implementation is not exactly what was proposed in #1317, it fulfils the goals of it with the control it provides - you could do
.pipelineColourspace('rgb16')
or.pipelineColourspace('scrgb')
depending on your exact needs. This is relevant because of the performance impact a given choice can have:Some other things of note with this PR:
pipelineColourspace
currently disablesfastShrinkOnLoad
. This was pondered on in Enhancement: provide wideGamut option to process in 16-bit linear colourspace #1317 and it made sense to me as this is essentially very much a "quality over speed" operator..toColourspace
JSDoc because it was pointing to the wrong thing due to changes in the libvips master branch since the link was first added. It now points to a static commit, which should keep the link more stable.gradient-rgb8.png
test image was made by me, simulating an image where I first spotted the banding issue I was having with the gamma operator and an 8bpc pipeline.gamma
operator documentation about using.pipelineColourspace('rgb16')
to avoid banding.Channel_digital_image_CMYK_color.jpg
test file which has an embedded ICC profile, and using.pipelineColourspace('rgb16')
did not seem to have any impact on color accuracy when dealing with it.