[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Adding internalformat param to all texImage2d variants

On 2010-05-19 00:23, Gregg Tavares wrote:
So if I understand this correctly the suggestion is a 1 channel PNG will be auto converted to a 1 channel texture GL_ALPHA or GL_LUMINANCE. a 2 channel will become GL_LUMINANCE_ALPHA. a 3 channel image to a GL_RGB and a 4 channel image to GL_RGBA

So are you adding the requirement that all browsers that support WebGL track this info when loading an img? Or will some browsers that happen convert a 1 channel png to RGB on loading be okay with generating an GL_RGB textures since that's what they have in memory?

If we add this I think we need to specify that the browser has to track the original format of all images or we will introduce potential incompatibilities between browsers.

It seems like this auto-conversion step is having WebGL extend itself outside of WebGL into the browser spec.

How about dropping the auto-conversion suggestion and just keeping the explicit conversions?

I suspect it might take some time to specify the behavior in a way that does not introduce incompatibilities, if we are not prepared to take the time to do so I think it would be better to just stick to what we have. I don't really have a strong opinion on if it should be added or not, but if we do add it we should make sure the spec is clear and does not introduce incompatibilities.

For example, what about jpeg with a format of CMYK/YCCK? They have 4 channels but no alpha (or red, green or blue). That is probably converted to RGB by the jpeg decoder in all browsers, but that does not make the original format of the image RGB or 3 components.

Should it only track the number of channels or also the depth of them and what they were (int the case of YCC and possibly others)?

I would also like to have it specified that the image will not necessary match the original image exactly to allow for different internal storage (conversion to rgb/rgba and back, changing the bit depth, YCC->RGB etc).

If we need to store the information about the format anyway, why not expose it in the Image object (or propose doing so to the relevant standards group)?


You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: