Transforming Colors with Matrices
lisyarus.github.io
lisyarus.github.io
For example, the article "Computerized simulation of color appearance for dichromats" gives the matrix transforms to simulate "color-blindness". This gives this command:
`convert $input -color-matrix '0.11238 0.88759 0 0.11238 0.88762 0 0.004 -0.004 1' $input_dichrom.jpg`
With which one can quickly check if a map or graph would be readable by a color-blind person.
At a surface level you may think that having to use advanced mathemathics to change something as trivial as position or adding a tint might be an overkill. But matrix math isn't that complicated, been highly optimized and can be relegated to the CPU since forever.
The most illustrative use would be a model of a 3D tank. You want the whole tank to turn itself 30 degrees to the left, now you want the turret to turn 40 degrees right and you want the gun to be facing 20 degrees upwards. With matrices being applied on every level it's dead simple to calculate what's the actual bearing of the gun in world coordinates.
Same applies to graphics. You have a game character that's been hit. You want to make it flash to indicate the hit by changing it's brightness, but at the same time you want to turn it's eyes to red by adding a tint. Oh, and the whole screen is changing it's saturation during the process. Again, by using matrices, it's really easy to figure out what's the color of the eyes at any given moment of the animation thanks to matrices.
[1] https://developer.mozilla.org/en-US/docs/Web/SVG/Element/feC...
(Obviously preprocessing would be a lot better if you can get away with it.)
To me that starts to feel wasteful, even if GPUs can churn through that anyway. If you're merely implementing a color tweak in a game you can come up with plenty of simpler formulas that look nice.
I've written oklab and okhsl implementations — that cube amplifies errors greatly. The full-precision cbrt makes it definitely a one-way thing for real-time graphics.