Windows Imaging Component & glTexImage2D()

[tranders]

Be careful using opengl.org for documentation because it is not without its flaws. For example, the 3.3 pages refer to a set of tables of valid internal formats but fails to include the tables. For the record, the 1.1 specification for glTexImage2d did not use "magic" numbers since the literal values 1,2,3, and 4 actually referred to the number of components as indicated in the argument's description. For historical reference these values mapped to the following internal base formats:

1 = GL_LUMINANCE
2 = GL_LUMINANCE_ALPHA
3 = GL_RGB
4 = GL_RGBA

I really can't understand why the GL_LUMINANCE & GL_ALPHA formats were dropped from the specification considering these have been retained in the OpenGLES 1/2/3 specifications. There was absolutely no technical reason to do this considering the internal conversion is trivial.

[Alfonse Reinheart]

There was absolutely no technical reason to do this considering the internal conversion is trivial.

Probably because you can get the exact same effect with texture swizzling. And according to the ES 3.0 spec, the only reason Luminance et. al are still around is for backwards compatibility with ES 2.0.

[tranders]

Probably because you can get the exact same effect with texture swizzling. And according to the ES 3.0 spec, the only reason Luminance et. al are still around is for backwards compatibility with ES 2.0.

There's a lot to be said for backwards compatibility -- especially when maintaining that support is for all practical purposes free -- something that cannot be said for the additional formats that have been added to the specification. On that I'm sure we will have to agree to disagree.

[Alfonse Reinheart]

There's a lot to be said for backwards compatibility

Yes. But once you've made the decision to break backwards compatibility, it ceases to be a concern. Because you're breaking it. Deliberately. It's one thing to make a general statement that they shouldn't break backwards compatibility, period. But once that decision has been made, LUMINANCE is pretty indefensible. It's an obvious piece of redundancy next to generic swizzling, and therefore should be cut. Although it would have been nice if they'd introduced texture swizzling into core GL before they cut LUMINANCE, leaving us with a good year or so where you just couldn't get the behavior without hardcoding it into your shader.

In any case, if you're making people give up fixed-function and all of the other crap they removed for 3.1, they're not exactly going to be screaming and crying about losing LUMINANCE. Which is why they should have cut all of the unsized internal formats when they had the chance. But at least the glTexStorage functions don't take them, so there's a win.

Of course, this means you can't use LUMINANCE et. al. with glTexStorage. Even in OpenGL ES. So "backwards compatibility" only applies to old APIs

something that cannot be said for the additional formats that have been added to the specification

... what are you referring to here? Swizzling is free too. So are the Red and RG textures.