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
Support sRGB color space in RenderTexture #1757
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sakarah
force-pushed
the
srgb_rendertexture
branch
from
April 1, 2021 10:44
b7beca8
to
8af5921
Compare
Sakarah
commented
Apr 1, 2021
Sakarah
force-pushed
the
srgb_rendertexture
branch
from
April 14, 2021 10:55
8af5921
to
ff86b35
Compare
Sakarah
changed the title
WIP: Support sRGB color space in RenderTexture
Support sRGB color space in RenderTexture
Apr 14, 2021
Independently on how we plan to solve the issue, I updated the code to test the PR in a more reproducible way. |
When the sf::ContextSettings asks for an sRGB capable buffer, set the rendered image to sRGB mode and convert pixels when drawing. This is the choice of simplicity compared to actually support textures with more color depth.
This fixes wrong rendering for RenderTexture that need sRGB encoding along a non-sRGB window. We cannot simply always enable GL_FRAMEBUFFER_SRGB because some drivers enable sRGB encoding on non-sRGB window surfaces. Also add a isSrgb() method to tell if a RenderTarget is encoding into sRGB color space.
Sakarah
force-pushed
the
srgb_rendertexture
branch
from
April 21, 2021 13:32
ff86b35
to
83a8cb5
Compare
@binary1248 Any remarks on the current state of this PR ? |
binary1248
approved these changes
May 11, 2021
Looks good to me now. Test works on my system. |
eXpl0it3r
approved these changes
May 11, 2021
ChrisThrasher
added a commit
to SFML/CSFML
that referenced
this pull request
Jul 6, 2023
ChrisThrasher
added a commit
to SFML/CSFML
that referenced
this pull request
Jul 6, 2023
ChrisThrasher
added a commit
to SFML/CSFML
that referenced
this pull request
Jul 6, 2023
ChrisThrasher
added a commit
to SFML/CSFML
that referenced
this pull request
Jul 6, 2023
ChrisThrasher
added a commit
to SFML/CSFML
that referenced
this pull request
Jul 7, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR tries to fix #1092.
When the sf::ContextSettings asks for an sRGB capable buffer, set the rendered image to sRGB mode and convert pixels when drawing.
This is the choice of simplicity compared to actually support textures with more than 8 bit color depth: see my post in forum (https://en.sfml-dev.org/forums/index.php?topic=20358.msg175496#msg175496).
It differs from #1093 because now we try to both convert to sRGB space when writing to the texture and when decoding from the texture. This repairs the rendering on multisampled textures, and on non-FBO implementations.
It also repairs rendering for sRGB RenderTexture used along a non-sRGB window (or no window at all).
Tasks
How to test this PR?
To test the PR, you should run the following code and check that it matches the reference output for all parameter combination.
You will need to following image: Gradient.png
GitHub's image compression makes it slightly hard to see, but it is normal if configurations
lS -> sT -> lW
andsS -> lT -> sW
show color banding, the other configurations must not.Enabling or disabling antialiasing should not change the output at all.
The code is adapted from the issue by @Fewes in the forum thread https://en.sfml-dev.org/forums/index.php?topic=20358.msg146448#msg146448.