8

I am working on a data visualization tool using OpenGL, and the LAB color space is the most comprehensible color space for visualization of the data I'm dealing with (3 axes of data are mapped to the 3 axes of the color space). Is there a fast (e.g. no non-integer exponentiation, suitable for execution in a shader) algorithm for approximate conversion of LAB values to and from RGB values?

Palec
  • 12,743
  • 8
  • 69
  • 138
Justin Olbrantz
  • 647
  • 3
  • 11
  • I hope there is, but I doubt it exists. The cube root portion is going to be hard to simulate. Maybe using linear interpolation between a small number of equivalent points? – Mark Ransom Mar 20 '15 at 19:30
  • Well, here's a subquestion: are the values specified in e.g. OpenGL such that RGB values are linear (gamma applied automatically), or not (explicit gamma compensation)? If they are linear, that would mean the XYZ->RGB step requires only a matrix multiplication, correct? – Justin Olbrantz Mar 20 '15 at 19:49

1 Answers1

1

If doing the actual conversion calculation in a shader is too complex/expensive, you can always use a lookup table. Since both color spaces have 3 components, you can use a 3D RGB texture to represent the lookup table.

Using a 3D texture might sound like a lot of overhead. Since 8 bits/component is often used to represent colors in OpenGL, you would need a 256x256x256 3D texture. At 4 bytes/texel, that's a 64 MByte texture, which is not outrageous, but very substantial.

However, depending on how smooth the values in the translation table are, you might be able to get away with a lower resolution. Keep in mind that texture sampling uses linear interpolation. If piecewise linear interpolation is good enough with a certain base-resolution of the lookup table, you can greatly reduce the size.

If you go this direction, and can't afford to use 64 MBytes for the LUT, you'll have to play with the size of the LUT, and make a possible size/performance vs. quality tradeoff.

Reto Koradi
  • 53,228
  • 8
  • 93
  • 133