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

Re: [Public WebGL] Retrieving number of texture channels



On Mon, Feb 22, 2010 at 1:14 PM, Johannes Behr
<johannes.behr@igd.fraunhofer.de> wrote:
>
> On 22 Feb 2010, at 22:01, Kenneth Russell wrote:
>
>> On Mon, Feb 22, 2010 at 11:50 AM, Johannes Behr
>> <johannes.behr@igd.fraunhofer.de> wrote:
>>> Hi,
>>>
>>>>>
>>>>> is there already a possibility to retrieve the number of present texture
>>>>> channels (intensity, luminance-alpha, rgb or rgba texture) in WebGL?
>>>>>
>>>>> Because according to the X3D lighting model a material's diffuse color
>>>>> modulates the color of the texture in case of a one or two channel texture,
>>>>> which we need to know for implementing this correctly in X3DOM. If instead
>>>>> the texture has three or four channels (the typical case), the color of the
>>>>> texture is used as the diffuse color.
>>>>> You can find an example demonstrating this issue here:
>>>>> http://x3dom.org/x3dom/example/x3dom_imageChannels.xhtml
>>>>
>>>> Unfortunately OpenGL ES seems to have dropped the
>>>> glGetTexLevelParameter query, which is needed to query the texture's
>>>> internal format, so WebGL doesn't currently contain it.
>>>>
>>>> We could probably emulate this call in WebGL implementations on top of
>>>> OpenGL ES by tracking the internal format used when the texture was
>>>> uploaded. In the short term, doing so in your library would be your
>>>> best workaround.
>>>
>>> But how should we track it in x3dom? AFAIK is there now method
>>> to ask a HTML image for some internal type or number of channels.
>>
>> How are you uploading the image data to WebGL? At least in the WebKit
>> WebGL implementation, currently all HTMLImages are uploaded as either
>> RGB or RGBA textures, depending on whether they have an alpha channel.
>> For example, we do not special case grayscale images as luminance
>> textures, and I don't know whether any of the supported image formats
>> handle two-channel images.
>
> At least png can handle 8 (and 16bit) grayscale image + alpha.

I see. I didn't know that.

It looks like PNGs can represent nearly all of the texture pixel
formats OpenGL ES 2.0 supports (ALPHA, RGB, RGBA, LUMINANCE, and
LUMINANCE_ALPHA), although there is ambiguity whether a single-channel
PNG would represent an alpha or luminance texture.

>> If you want better control over which channels you want in the
>> texture, you will currently need to upload the texture data as a
>> WebGLUnsignedByteArray, in which case you have explicit control over
>> the internal format.
>
> The internal format is another topic. The main problem is that
> we have to have some way to load any content and determine
> very late what kind of images we have.
>
> We can not provide some hints in the content pipeline.
> The X3D scene graph should be (by design) independent
> of the image files.
>
> Is there really no way to ask a HTML-Image for any
> kind of type information ?

As far as I can tell from looking at the DOM Level 1 and HTML 5 specs,
as well as the Canvas spec, the answer is no, it isn't possible to
query an HTML image for this level of information.

Given the ambiguity between luminance and alpha textures, and the
utility of both, I am dubious that X3D try to auto-detect what kind of
texture environment mode should be used based simply on the number of
channels in the texture. It seems to me that the scene graph should
provide control over this parameter.

It may be technically feasible for WebGL to return the internal format
for textures loaded from HTMLImageElements, and to choose the best one
for the incoming image, but it will be quite a bit of work. WebKit's
internal image decoder class does not currently provide the number of
channels in the original image; it always decodes to RGBA format, so
recovering the information that the incoming PNG was for example
grayscale + alpha will take a fair amount of plumbing. If you would
like to see this information exposed then please file an RFE against
WebGL on http://www.khronos.org/bugzilla/ so we can track it in the
spec and all implementations.

-Ken

> best regards
> johannes
>
>
>>
>> -Ken
>>
>>> best regards
>>> johannes
>>>
>>>
>>>>
>>>> However, there must have been a reason this call was dropped from
>>>> OpenGL ES. I suspect the reason is that glGetTexImage was removed, and
>>>> texture rectangle textures aren't supported, so the need to query the
>>>> texture's width, height and internal format is significantly reduced.
>>>>
>>>> I am not sure we should add this API into WebGL and diverge from
>>>> OpenGL ES. Other opinions?
>>>>
>>>> -Ken
>>>>
>>>>> Regards
>>>>> Yvonne
>>>>>
>>>>>
>>>>> --
>>>>> Yvonne Jung
>>>>> Fraunhofer-IGD    | Tel.: ++49-6151-155-290
>>>>> Fraunhoferstr. 5  | Fax.: ++49-6151-155-196
>>>>> 64283 Darmstadt   | email: yvonne.jung@igd.fraunhofer.de
>>>>> Germany           | http://www.igd.fhg.de/igd-a4
>>>>> -----------------------------------------------------------
>>>>> 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:
>>>>>
>>>>>
>>>
>>> --------
>>> Dr.-Ing. Johannes Behr  tel: +49-6151-155-510
>>> Fraunhoferstr. 5                        fax: +49-6151-155-196
>>> D-64283 Darmstadt               skype: johannesbehr
>>> Germany                         web: www.igd.fhg.de/www/igd-a4/
>>>
>>>
>>
>> -----------------------------------------------------------
>> 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:
>>
>
> --------
> Dr.-Ing. Johannes Behr  tel: +49-6151-155-510
> Fraunhoferstr. 5                        fax: +49-6151-155-196
> D-64283 Darmstadt               skype: johannesbehr
> Germany                         web: www.igd.fhg.de/www/igd-a4/
>
>

-----------------------------------------------------------
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: