fast color lookups

Can anyone suggest an alternative to Nvidia’s texture shaders for doing color table lookups? I have code that currently uses dependent texture reads (2 256x256 AR and BG textures). I’d like to have this code work on non-Nvidia cards and even Mesa. glColorTable is way to slow and I’d like something that’s fast and portable. Thanks!

(PS: I’m a little new to color tables and such so lemme know if something doesn’t make sense.)

There’s the ATI pixel shader extension if you want to go that route. There’s no good standard way of doing dependent reads until ARB_fragment_program, which is very nice and general, but only released on Radeon 9700/9500 (and, soon, GeForce FX). I expect support will be available on most newer cards thata support DirectX 9.

Looking at some older posts, I seemed to have made the error of confusing glColorTable with glColorTableEXT. I’ve definitely had slow results with glColorTable. I’ll have to try glColorTableEXT. My main concern is to be able to do color correction fast; whether it be via ColorTable, dependent textures, or some other method.

Do you only need to do it coming out of the frame buffer? Then I suggest using SetDeviceGammaRamp(), which is part of the GDI API. If you need to color correct texture samples before they go into the frame buffer, you’d need some kind of dependent read for decent performance.

This is before anything goes into the frame buffer. Can anything coming out of the frame buffer be corrected at a decent speed? I haven’t head of the GDI api before.

EDIT: Just looked up GDI. Haven’t heard of it cause I do all of my development in Linux, not Windows

Originally posted by jwatte:
Do you only need to do it coming out of the frame buffer? Then I suggest using SetDeviceGammaRamp(), which is part of the GDI API. If you need to color correct texture samples before they go into the frame buffer, you’d need some kind of dependent read for decent performance.

[This message has been edited by djdjdjdjdj (edited 01-02-2003).]

Believe it or not, there seems to be an X library function to change the gamma, too, although I’m not sure how widespread support there is.

The speed of gamma correction is infinite, in the sense that it’s always on so there’s never any difference. It’s usually implemented using the palette look-up hardware, so it often doesn’t work in indexed mode. But who needs that anymore?