Qmk_firmware: HSV numbers in Oryx generated source code
Hello,
I recently bought a Planck EZ; and while the Oryx Configurator is made for people like me, I'm hoping to make some simple modifications to the source code generated from my Oryx layout to enable some extra features.
I have successfully flashed my Planck EZ from the source code straight out of Oryx. All of the keymapping seems to be working; but the RGB lighting seems washed out, like there is some kind of colour conversion.
I can see where the colours are referenced in the keymap.c file—my understanding is that they are in HSV format, but all of the numbers appear to be in the 0–255 range. Is this right? Shouldn't HSV be represented as H=0-360°, S=0-100%, V=0-100%?
What is causing the shift in colour? (compared to the same layout compiled with Oryx).
Is it possible to work with RGB values instead of HSV?
Here is the contents of my keymap.c file:
keymap.txt
Let me know if I need to clarify anything!
Randall
Compiled in Oryx:
Compiled manually from Oryx source code:
ransworld
All 12 comments
@XScorpion2 you want to take a crack at explaining this?
yanfali
on 6 Oct 2019
360 vs 255 hue: Traditionally H in HSV is expressed in 0-360°, but when dealing with 8 bit MCUs, the range is shrunk to 255 as it's much faster to work with. For example, 0 to 360 range requires a 16 bit type with a range of 0-65535, which requires double the number of registers, and an additional rage check to ensure the value doesn't go over 360, while 255 does not require any of that extra code as it's an 8 bit type with a range of exactly 0-255.
What is causing the shift in colour?
This is probably due to a recent change I made in the HSV to RGB code here https://github.com/qmk/qmk_firmware/pull/6764 (color.c file). I moved where we do linear light adjustments to earlier in the math so more precision is retained for better behavior during value fades, however it's worse for visual color accuracy. You can see an ongoing discussion here about the issue https://github.com/qmk/qmk_firmware/pull/2350#issuecomment-533921297Is it possible to work with RGB values instead of HSV?
I have no idea. In source you can as you could just call the rgb_matrix_set_color api directly, but I don't know if the Oryx Configurator can do so as I've never heard of that.
XScorpion2
on 6 Oct 2019
@XScorpion2 thanks, appreciate the insight.
yanfali
on 6 Oct 2019
@ransworld we don't have anything to do with the Oryx configurator, so not sure their values will work with our stuff anyway. Hope this helps
yanfali
on 6 Oct 2019
@ransworld The Oryx configurator may be a bit behind QMK master, but we do try to keep it up to date (though, there will always be some lag time).
That said, there is already a PR to update the code to include the mentioned PR, so it should be push "soon".
drashna
on 6 Oct 2019
Thank you for the responses!
The HSV number conversion makes sense—thanks for clearing that up. Following one of @XScorpion2's links, I found a chart that should help me find the colours I want.
Hopefully Oryx catches up to the QMK master; or even better, incorporates some of the extra features I want, such as tap dancing and macros.
ransworld
on 7 Oct 2019
Well, I have PRs open to get it updated and the color change is one of them.
As for the tapdance and macros, I don't expect that to happen, at least any time soon. They're more complicated features, so implementing them in a simple, easy to use way isn't simple.
drashna
on 12 Oct 2019
Hey @drashna
Since the oryx codebase is not open, it's hard to follow when ur PR will be merged.
Any updates on this topic?
azerbe
on 11 Dec 2019
The oryx source is, but the repo it uses for the firmware is on github.
That said, the fix has been merged in, so it should be identical now.
drashna
on 18 Jan 2020
@drashna I am still seeing this occur on my Ergodox-EZ when using Oryx. Is there some additional thing I need to do to update the device specifically?
jpinnix
on 6 Feb 2020
I'm experiencing a similar thing with Oryx and my Planck EZ, but only with the the predefined colour palettes. If I mix colours manually, I can get fully saturated colours.
Edit: I should clarify, the preset colours used to be vibrant—at least at the time of my original post.
ransworld
on 8 Feb 2020
This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.
For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.
![stale[bot] picture](https://avatars3.githubusercontent.com/in/1724?v=4&s=40)
stale[bot]
on 9 May 2020
Related issues
kb3dow
·
3Comments
gesinger
·
3Comments
ghost
·
3Comments
mrceephax
·
4Comments
alaibe
·
4Comments
Most helpful comment
360 vs 255 hue: Traditionally H in HSV is expressed in 0-360°, but when dealing with 8 bit MCUs, the range is shrunk to 255 as it's much faster to work with. For example, 0 to 360 range requires a 16 bit type with a range of 0-65535, which requires double the number of registers, and an additional rage check to ensure the value doesn't go over 360, while 255 does not require any of that extra code as it's an 8 bit type with a range of exactly 0-255.
What is causing the shift in colour?
This is probably due to a recent change I made in the HSV to RGB code here https://github.com/qmk/qmk_firmware/pull/6764 (color.c file). I moved where we do linear light adjustments to earlier in the math so more precision is retained for better behavior during value fades, however it's worse for visual color accuracy. You can see an ongoing discussion here about the issue https://github.com/qmk/qmk_firmware/pull/2350#issuecomment-533921297
Is it possible to work with RGB values instead of HSV?
I have no idea. In source you can as you could just call the rgb_matrix_set_color api directly, but I don't know if the Oryx Configurator can do so as I've never heard of that.