Skip to content
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

Fix mistakes in functions srgb_to_linear() and linear_to_srgb() #90187

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

TON14
Copy link

@TON14 TON14 commented Apr 3, 2024

The correct formulas uses "<=", not just "<".
This can be seen in IEC 61966-2-1:1999 or in the Wikipedia article "sRGB".
Also, some mathematical operations do not make sense and can be removed.

@TON14 TON14 requested a review from a team as a code owner April 3, 2024 23:32
@@ -174,16 +174,17 @@ struct _NO_DISCARD_ Color {

_FORCE_INLINE_ Color srgb_to_linear() const {
return Color(
r < 0.04045f ? r * (1.0f / 12.92f) : Math::pow((r + 0.055f) * (float)(1.0 / (1.0 + 0.055)), 2.4f),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Multiply operations are slightly faster, so it cases like this, it's better to leave the multiplication in, otherwise you are adding CPU cycles where you don't have to.

Further, There is a subtle but real difference between * (1.0 / x) and / x which leads compilers to not optimize the line by replacing the divide with a multiply.

So this PR is likely adding CPU cycles at run time. Of course all compilers are slightly different, so the impact is hard to predict, but it's best not to remove the multiply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants