Ensure that bevy_color works with HDR

[eero-lehtinen]

What problem does this solve or what need does it fill?

Currently bevy_color stresses everywhere in its documentation that values should be contained in [0.0, 1.0]. This assumption is incorrect when working with HDR values.

There is also no simple way to construct HDR values from SDR values. Before it could be done with Color::RED * 5.0 (I'm not sure if this is correct but I'm doing it this way).

What solution would you like?

We could update documentation with all color spaces to include HDR values. Then make sure that all color functions support these extended values. E.g. adjust_luminance currently does explicit clamping which is broken with HDR.

Supporting straight up multiplications for constructing HDR values seems error prone, but some kind of function for this would be convenient.

What alternative(s) have you considered?

We could also do a separate HDR color type. Not sure how that would work with our current color spaces.

Additional context

[viridia]

I've been using the palette crate as inspiration for what methods and traits to support - but only as a starting point, not as a rigid spec. Now, palette doesn't have any traits or methods that would address HDR issues, but they do have some traits that deal with the inverse: Clamp and IsWithinBounds.

[eero-lehtinen]

I guess at this point I would be happy if there was a small mention in the documentation that large values are allowed with HDR, and Mul implementation for Srgb and LinearRgb to manipulate HDR brightness (palette has this too).

All color space conversions may not work very well with HDR but maybe it doesn't matter if they weren't even designed for that.

[eero-lehtinen]

I've been using the palette crate as inspiration for what methods and traits to support - but only as a starting point, not as a rigid spec. Now, palette doesn't have any traits or methods that would address HDR issues, but they do have some traits that deal with the inverse: Clamp and IsWithinBounds.

It is a bit weird that the whole palette crate has only a single mention of HDR, but we need to clarify it.

I feel that clamping functions aren't needed for this issue, but could be a future enhancement.

[bushrat011899]

So I think this needs a well considered solution beyond just "clamping" like palette does. The real problem is we need a tone mapping solution. Clamping is a form of tone mapping, where [0,∞) is mapped to [0, 1] by clamping all values above 1. This is a simple solution with great performance, but can look less than ideal since all that information is just lost.

[eero-lehtinen]

We do have a tonemapping pipeline already, if this is what you mean. We don't need to do any tonemapping in bevy_color.

[eero-lehtinen]

Ok I found that the palette library has a stimulus trait, that does at least mention that high color values exist. Color is called stimulus in our tonemapping shader too.