Color math should ideally always be in floats
See original GitHub issueVersion: All, master
Platform(s): All, but mostly affects newer devices
Color math should ideally be done with float
to support arbitrary precision. It’s somewhat common to have 10-bpc and 12-bpc displays, and HDR color math often needs 16 bits per channel. float
aka Single precision floats have 23 bits of significant binary digits which is plenty for colors.
Floats also avoid the problem of clipping, as colors above 1 still work fine. Even if they clip when displayed, if the brightness is reduced for the whole image, the brightness differences in bright areas is preserved when using floats.
Floats are also more friendly to the user. It’s easier to understand that “0.5” is 50% strength than “127”.
Xenko already has Color3
and Color4
classes which already work with floats. However, there’s not much point to Color3
in my opinion. You can just have constructors and methods that take the alpha value as an optional parameter for use cases that don’t need it.
If it were up to me, I’d do the following:
-
Modify
Color4
to make the alpha value optional. Consider deprecatingColor3
. This isn’t a breaking change. -
Rename
Color
toColor8
and consider deprecating it. This is a breaking change. -
Rename
Color4
toColor
. This is a breaking change.
These don’t all necessarily have to be done at once. In fact it may be preferable to leave a time gap between 2 and 3 to avoid people using “Color” in their code and having the implementation change without them knowing.
Obviously it’s the Xenko team’s decision of what to do, but I do think that something should be done, since color math being done with bytes is not ideal. Having a “Color” class with nothing after the name implies that it’s the recommended / default choice.
Issue Analytics
- State:
- Created 5 years ago
- Comments:15 (10 by maintainers)
Top GitHub Comments
I think you did not understand the point of
Color3
.@Kryptos-FR No, using optional parameters, it would be done like this:
Then you can write code in either of these two ways: