On May 20, 2010, at 9:23 AM, Gregg Tavares wrote:
On Thu, May 20, 2010 at 8:53 AM, Chris Marrin <email@example.com>
On May 19, 2010, at 7:40 PM, Gregg Tavares wrote:
>I don't see how loading a grayscale as RGB is the same as LUMINANCE. The OpenGL texturing engine deals with LUMINANCE textures differently from RGB. The problem the information that an original image was one channel is lost in the browser implementations. Even if not (if the browsers were forced to pass along the original image format information) implementations would have to have internal format conversion to get the image into the right format. So why not expose that to the author?
> What I don't get is why the need for these conversions? If you load a grayscale image as RGB you'll get the same visual result as LUMINANCE. So it seems like the valid reason to do these conversions is for memory savings since you can always create RGB or RGBA textures that will give you the same visual result.
Can you point out the difference between an RGB image where R == G == B and a LUMINANCE texture? I'm unaware of this difference.
I feel very old. There was a time that LUMINANCE textures behaved differently that RGB in the face of the various texturing modes. Those are all gone in a shader based world. So you're right, there is no difference.
Right, but I don't think we can underestimate the significance of that memory savings, especially in embedded devices. It can easily mean the difference between content working and exhausting memory. So I reiterate my opinion that we should add internalformat to texImage2D in the 4 cases that take HTML objects.
As far as I can tell there is no difference. There's also no difference between an RGBA image were R == G == B and a LUMINANCE_ALPHA texture.
So arguably, the only point in providing the conversions is memory savings. Otherwise there's no functional difference.