@chrisbrobs hm - I'm not sure. Imagine laying out an rgb color space onto a 2d texture. it could represent 255*255*255 colors or 2*2*2. It really doesn't matter. Obviously the color space and the texture size go hand in hand.
In the original image you then use the rgb value to essentially get texture coordinates for the look up table/ texture. Red = x, green = y, x+= blue * 255. In this case the lookup table is a very wide image where blocks of red and green have been laid out with increasing blue value. Does that make sense? The lookup table can then be altered anyway you like. You could make it super small and force a limited palette, you could use photshop to alter the levels and so on. The advantage is that you can have mathematically complex color conversions, arbitrary filters, etc, all at a low cost. The downside is that you have to create the lookup tables ahead of time.
The end result is that you can get an incredible amount of diversity of assets without creating that many assets. It also makes it possible in 3d games to have a general lighting scheme and then use lookup filters to drastically alter the mood of the scene. It has some great uses. Essentially you could even use it as a shade, tint, etc tool. Or hsv. But it works more efficiently than actually mathematically calculating/converting from rgb -> hsv -> change values ->rgb. This is most pronounced when doing lab space color corrections.
If none of this makes sense, check out this link. It is for Unity's color lookup, but the same principle can be applied to c2! http://docs.unity3d.com/Manual/script-C ... ookup.html
As is mentioned and worth noting again is the fact that you can use photoshop to generate the color transforms. Basically you could take a scene from the game and apply filters/levels/etc until you like the way it looks. You then do the same thing to the lookup texture. and poof! quality color correction
and at a very low cost.