Are color look up tables obsolete in OpenGL?

Question

Level 1

4 points

Are color look up tables obsolete in OpenGL?

Back in my X-Windows days. I used to like to use color look up tables to interact with complex graphical displays. By assigning one of 255 colors to each category of graphic, I could "flash" particular data points by toggling the color that was assigned to them. Although Apple's 2012 OpenGL documentation demonstrates a query for GL_SGI_color_table (which I assume is what I want), my current GPU gives no hint that it supports such functionality. Has this technique become unfashionable? Or is it something that has been subsumed into vertex shaders or the like?

RBN

Posted on Sep 17, 2015 6:34 PM

Reply

Answer 1

Sep 17, 2015 6:53 PM in response to dnerf

Has this technique become unfashionable?

Limiting to 256 colors, which then uses a color lookup table, is what has become unfashionable. nominal 24-bit color does not need a lookup table any more.

Put your old "cute trick" aside and attack the problem directly. Maintainability is the most important attribute of your software, so be clear and direct.

Reply

Answer 2

dnerf Author

Level 1

4 points

Sep 17, 2015 8:21 PM in response to Grant Bennet-Alder

Maintainability is the most important attribute of your software

No, usability is the most important attribute of my software.

I am trying to help the user understand the categorization of points suspended in 3D space. 24 bits of color are overkill when the average person can distinguish fewer than two dozen. In the 1950's, the late George Miller wrote "The Magic Number Seven, Plus or Minus Two." where he showed human limitations in remembering sequences and distinguishing colors, tones, etc. Way before computers, astronomers used blink comparators to find transient phenomena such as asteroids, comets, and nova in complex fields of view. Hand/eye coordination is much more effective than simple observation. I am trying to do something similar, to avoid the perceptual limitations of labeling with continuous colors.

To me, the code that rewrites colors assigned to some subset of the vertices when the user presses a button is far less clear and direct than simply changing the color in a single entry of a look up table.

What clear and direct algorithm do you suggest?

Reply

Answer 3

Sep 18, 2015 8:00 AM in response to dnerf

I did not intend to find fault with a limited color palette or with your wish to make points blink. I was trying to be helpful, and even if my comments were not helpful, no offense was intended.

I find fault with program "tricks" that can make your software hard to understand, and therefore hard to maintain.

Loop:

select points whose colors are to be changed

change each to a temporary color,

--(possibly based on a program-controlled table of current colors and their alternate "blink" colors)

wait the appropriate amount of time with the alternate color displayed

change all back to fundamental colors

wait the appropriate amount of time at the fundamental color

repeat

Edit: Is there a built-in function that can make things on screen blink for you, instead of having to run a timed loop? that would be even better.

Reply

Answer 4

dnerf Author

Level 1

4 points

Sep 18, 2015 1:07 PM in response to Grant Bennet-Alder

Grant,

I appreciate that you take the time to respond and to discuss.

Since I haven't any working code, what I'm pondering may fall under Donald Knuth's "Premature optimization is the root of all evil".

What I'm focused on is the use of bandwidth between CPU and GPU.

If I have N points I want to categorize (where I'd like N~=1,000,000, but whatever large number OpenGL can support), then initially I have to transmit N coordinates + N colors (your algorithm) or N coordinates and N category bytes (my hope).

When the user pushes the "Blink" button your algorithm has to send f*N colors, where f is the fraction of points being blinked, to the GPU. The look-up-table algorithm only has to send one index byte and one color word to the look-up-table. The GPU is responsible for figuring out which colors get changed.

BTW, I want the blink to be synchronous with the button press/release, rather than some timer-controlled cycle.

To me, the use of a color look-up-table isn't any more confusing to a maintainer than the use of nib file that connect outlets and actions.

My experience with GL dates to when it was Silicon Graphics proprietary software. Anybody know whether I can emulate look-up-tables in vertex-shader code?

RBN

Reply