Is it possible to load up a texture image, one channel at a time? Eg. first the red, then the green and then blue? I’ve been looking at the specs, but I can’t find any way of doing this.
The reason I would need this is that I’m using a 3rd party image decompressor that creates multi spectral images, and writes each channel into a separate buffer. I can interleave the channels myself, but it’s expensive and eats up a lot of memory.
SGI developed an extension for this:
http://oss.sgi.com/projects/ogl-sample/registry/SGIS/texture_color_mask.txt
However, I don’t think it was ever deployed on anything but a few SGI systems (if that).
An alternative might be to use 3 or 4 separate single-channel textures (either GL_LUMINANCE or GL_INTENSITY), one for each color channel, then use a fragment program to sample them and assemble the fragment color.
-Brian
That’s too bad… 
Is there any HW limitation why this extension never got implemented, or is it just the lack of interest?
Can’t this be done by uploading R, G and B separately to FB(O) with ColorMask()?
Given a color plane (R, G or B), set ColorMask appropriately and DrawPixels using a luminance source format (as memory size was an issue). Repeat for all planes. Copy FB to texture.
Actually, looking for a reference for this process I came by the following quote from the 1.1 Red Book:
“Masking in RGBA mode is useful less often, but you can use it for loading separate image files into the red, green, and blue bitplanes, for example.”
Yeah, I’ll probably end up doing something like this. Maybe I could even use DrawPixels for rendering into the FBO attached texture. Still it’s a lot of extra work, considering the simple thing I want…
Is there any HW limitation why this extension never got implemented, or is it just the lack of interest?
It’s probably because doing this is incredibly slow. Here’s how the implementation would work.
You provide a buffer with one of the components. The driver downloads the texture from the graphics memory (if it’s up there to begin with). It then reads, byte by byte, from your buffer and does a read/mask/write operation with each individual pixel on the texture, storing the byte into the correct component for each pixel. Then, it uploads that texture back to the card.
Effectively, it would be doing the code work that you’re doing. Even worse, because of the constant uploading/downloading, it’s slower for the driver to handle this than for your code. No hardware supports the concept of textures that have their components stored in disperate locations.
In short, it’s probably most efficient to do the combination yourself. Even the glDrawPixels method will probably be slower than doing it yourself.