Clamping color values to within [0, 1]#613
Conversation
Signed-off-by: Addisu Z. Taddese <addisu@openrobotics.org>
Signed-off-by: Addisu Z. Taddese <addisu@openrobotics.org>
|
I've added enforcement of the color values range [0, 1] in 5f0ae54. Some of the test values needed to be updated because the clamping is different now: instead of dividing by 255 when a value is greater than 1, it's clamped to 1. While I was trying to fix tests, I noticed that the functions that convert between RGB and YUV are not well defined. It's not clear what the input range is for YUV values. I also couldn't find a good reference for the equations used for the conversion. In fact, checking wikipedia, it looks like the math might be incorrect. As far as I can tell, these functions are not being used anywhere in Gazebo, so I propse we deprecate them. |
|
the YUV conversion code matches one of the formula in this post: https://www.vbforums.com/showthread.php?728455-What-is-the-CORRECT-conversion-for-YUV-to-RGB. the HSV conversion code seems to come from: https://stackoverflow.com/a/6930407 I tried a few online color converters using the values from our test and the results don't really match. I agree we should either fix the code or deprecate / remove it. |
|
Yes, there seems to be many conventions around this and I don't think any of us are experts in this area. I'll deprecate it in a follow-up PR. |
🦟 Bug fix
Toward #200
Summary
This removes the clamping of color values, but it doesn't yet enforce the invariant for channels being within [0, 1]. The best way to do that would be to throw an exception, but we don't do that anywhere in the gz-math codebase.
Checklist
codecheckpassed (See contributing)Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining
Signed-off-bymessages.🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸