This diff fixes issues with [T60619], where inserting a big value would overflow the hex and when the hex field was selected the incorrect (overflown) hex value would be applied.
I think this also fixes [T60577]
The UI for the V (HSV) is not 100% because even setting the max to 1, the bar shows only partially filled after entering a big number.
Details
Details
- Reviewers
Jacques Lucke (JacquesLucke) Brecht Van Lommel (brecht) - Maniphest Tasks
- T60577: 2.8 Color sampling alters color value
T60619: Clicking away from colour picker wih hex value selected changes the colour - Commits
- rBS8db514f81dc1: Fix T60441, T60619: incorrect values for color values > 1.0
rB8db514f81dc1: Fix T60441, T60619: incorrect values for color values > 1.0
Diff Detail
Diff Detail
- Repository
- rB Blender
Event Timeline
Comment Actions
RGB values outside the 0..1 are actually valid, limiting them is not the correct solution for this bug. For example a HDRI background can emit with arbitrarily high color values.
There should be clamping right before clamping to hexadecimal though, if it's not already there.
Comment Actions
In this case, I tried to clamp the values before generating the HEX value, but the color still changes. The problem is that HEX is not able to represent HDR, so when the colorspace conversion function is applied, some weird color is generated instead. Since this is a limitation of the hexadecimal representation, there is no fix for this issue. So, we decided to prevent the user from editing the HEX input field if the RGB value cannot be represented as HEX. The only problem is that when the user actually wants to input a HEX value in place of a non-representable value, the RGB values will have to be corrected before the HEX field becomes editable.
Comment Actions
Hex values are colourspace dependent and have little use outside of other facets. They are a *very* bad idea.
Comment Actions
I'll commit just the part that does the module, which makes no sense. Disabling the button is not needed I think.