A new idea that evolved in this thread -- use the hue, saturation, value color model to generate colormaps directly with Infragrammar. While this idea is not fully developed and has had some good criticisms from Ben, I thought this proof of concept was interesting enough to continue exploring.
I used this expression in the HUE field of the HSV input (i tweaked it a bit until it seemed to use an attractive span of the color wheel):
It accepts a color value from 0-360, and allows for negative values, it seems, like -180, since it's really just an angle on this kind of color wheel:
I used a maximum value of 1 for each of Saturation and Value. That resulted in this fairly nice image:
Compare that with the build-in colormapping function Ben implemented:
As i pointed out in the comments here yesterday, this HSV approach is pretty interesting and conceptually fun, but not ideal for real work with LUTs. I spent some time thinking about it and did some sketches of a new interface:
This might also include the "auto adjust" pictured which would basically just auto-set the range of the color table it'd actually use. We could let people do that with a couple sliders, too, as a more advanced feature, but automating in a consistent way is probably best.
The algorithm would be pretty similar to HSV, except that instead of looking up a color by converting from a 0-1 range into a color value from the color wheel, we'd just look up the color from the selected LUT, where the left edge is 0 and the right edge is 100%. Sorry if that's obvious.
I'm not sure if the LUTs should be computationally generated (Ben G provided for this in his own color mapping system -- his version of Chris's default green-cutoff LUT is actually generated, not stored) or just based on images we upload to the server. It could get kind of weird if we wanted to just do 6 block colors with no gradients... maybe we can stick to just images for now, not equations.