Search code examples
variablescolorsrgbdata-visualizationgraphic

Graphic - choosing colours to represent a variablespace - more design than programming


I've written a basic visualisation tool that pulls some data from a MySQL database into a few views, and does some maths in python.

I've built the tool, for the most part; I now have a somewhat odd problem…

I'm trying to convey as much simple data as I can, using the graphics and the colour of the main tool I have at my disposal.

Without going into the minutiae of the project: I have two primary variables, A and B. A has 4 values, and B has 5.

I want to use Green when A=4, Yellow for A=3, Orange when A=2 and Red when A=1. In the B-variable space, I thought I'd use saturation - 100% @ 5, 80% @ 4, 60% @ 3, 40% @ 2 and 20% @ 1

I'm not wedded to these values – they make a kind of logical sense qua the story I want to tell, as well as mathematical sense, by their suggestion of distinct 'levels,' or boundaries in the data.

Only, they don't. The colors don’t convey this information to the user. It is hard to visually differentiate the 100% colours from the 80% – I guess this is due to the fact that our colour response isn’t linear.

I wonder if anyone has any thoughts about how I might divvy up my two variable plans in a decently perceptible fashion, using colour?

I appreciate this question might be in the wrong place – I'm not sure where else I could ask about such a thing.


Solution

  • The RGB colorspace has more to do with the light that monitors and other devices use to make the color, rather than your perception of the individual channels. There are many colorspaces, each with their own characteristics.

    For example, the LMS colorspace is modeled after the actual spectral power distribution curves that describe the way the human eye's transducers respond to light:

    http://en.wikipedia.org/wiki/LMS_color_space

    ... The curves of which can be approximated with compounded 8-bit RGB values, but bluntly.

    For you, I would recommend either the Lab* colorspace, which is in many ways the most optimal compromise, at the intersection of what we (as in we humans) can conceptually grasp, what we can mathematically model, and how we see.

    If you find that daunting, HSV values are your friend. HSV isn't technically a different colorspace from RGB, in terms of gamut -- it's a sort-of distorted view of RGB space, with numerical representations that are more amenable to your cause:

    the HSV color space

    The 'H' in HSV is the number of degrees around the hue circle (from 0 to 360 -- you may see it in radians, expressed over the range [0..2π] too); S and V are saturation (how much chroma) and value (the modulated luma value), respectively. HSV is a sort-of transposition of HSL, in which L is a more literal measure of luma.

    The point of all that is: it's relatable. If you vary the H value, moving the hue around the circle while holding S and V constant, the change is much more perceptible to a user than (say) if you're changing 0xEFEEEE to 0xEFEFEF and putting the value onto an LCD pixel. And so, the nice thing about working with HSV or HSL values is: you can losslessly convert them back to RGB, when you do need to display them.

    The conversion math between RGB and Lab* is much less straightforward -- it's an abstract color space, whose axes and dimensions aren't keyed to specific qualia of human vision -- but playing around with any colorspace math is worth at least 1000 words, so to speak.

    Best of luck, it sounds like a good project.