How to change ONLY the hue of a HDR color without impacting its other qualities of brightness and saturation?
You can RGB2HSV it, adjust the H, then put it back with HSV2RGB.
These are all methods in the Color class.
For some reason I’d thought that RGB wasn’t able to handle HDR.
Thank you!
Well, you should stay away from using Color32 values as they use a byte for each channel and use the range 0 - 255. The Color struct uses 4 float values in the “usual” range of “0 - 1”. However since it’s a float it could go above 1. Unity does also have an HDR color picker in the editor.
Uhm, no, HDR stands for High Dynamic Range and is not related to High Definition. HDR is a technique to allow overbright or extremely dark areas within the same image. Most image formats do not support high dynamic range, but some do. Though we talk mainly about HDR rendering.
Well, that’s a way too broad statement The Color32 struct is a Untiy type. Yes most libraries which deal with images or image data would usually use 8bit per pixel, though that’s not something related to C#.
In the end this thread was about HDR rendering, so we should not go off on a tangent here.
ps: Are you sure your answer is not an AI powered response? If it is, we already have enough of those attempts which all failed miserably ^^
I’m more confused than before.
Will RGB2HSV → Hue change, then back via HSV2RGB work properly for HDR?
I’m going very bright and very dark in some of the things I’m doing, and want to do hue shifts in code, without losing/changing the brightness or saturation, and be sure of the result, as subsequent layers of additive blended objects are reliant on the underlying objects that are having their hue shifted. This works in the editor, but I’m wanting to animate ONLY hue, with script, and be sure of outcomes.
from the docs:
“The H, S, and V are output in the range 0.0 to 1.0.”
here:
seemingly meaning it doesn’t convert to anything that’d be brighter than normal dynamic range, nor darker (negative numbers).
Well, the HSV ↔ RGB conversion is just math and you can see it over here. I think the documentation was written before they had even HDR support. According to the code the hue would always be in the 0 to 1 range and as far as I can tell the saturation would also be in the 0 to 1 range. However the value (v) could end up higher.
AFAIK negative values aren’t really a thing here. Since we are dealing with floating point numbers you can get as close to 0 as you want. So you get a theoretical infinite range towards 0. There’s nothing darker than dark Though with HDR you actually can encode color information in almost dark pixels which are way below the usual range. With RGB byte values the smallest non-zero value is 1. That would be an actual value of 1/255 or about 0.0039. Since we have floating point numbers we can encode colors as low as 0.00000042 directly and scaling the value back up would more or less preserve the color information.
THANK YOU!!!
Seeing the code is a great relief. Had no idea that was possible with something like this. Should have checked with the Rider decompiler. Much thanks!!!