[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Retrieving number of texture channels
Am Mi, 24.02.2010, 03:46, schrieb Kenneth Russell:
> On Tue, Feb 23, 2010 at 5:59 PM, Mark Callow <firstname.lastname@example.org> wrote:
>> Hi Chris,
>> On 24/02/2010 07:25, Chris Marrin wrote:
>>> On Feb 22, 2010, at 6:21 PM, Mark Callow wrote:
>>>> I agree with Ken that adding support to WebGL for deciphering HTMLImages
>>>> that are PNG files to automatically determine the format to use for
>>>> TexImage2D is an enhancement. A query will clearly need to be part of
>>>> this enhancement.
>>> We don't need queries for this. We simply need to know what the resultant
>>> internal format is for each type of image loaded. As I mentioned in other
>>> responses, adding a format param would provide this.
>> "Query will clearly (be) need(ed)" was predicated on "automatically
>> determine the format". If you add a format specifier to the TexImage2D
>> that accepts an HTMLImage then I completely agree a query is not needed.
>> We had the same problem vis-a-vis one-channel luminance vs. alpha when
>> loading PNG files in M3G. We added a format parameter there too.
>> When writing the spec. for this format parameter bear in mind that OGL
>> ES does not support internal format conversions. Therefore perhaps you
>> should throw an exception if, e.g. the app. tries to load a one-channel
>> PNG image as RGB. In other words require that the specified format match
>> the HTMLImage contents.
> It will be difficult to enforce this requirement in the current
> WebKit. The knowledge of the number of channels in the original image
> is lost during image decoding (AFAIK). It would be simpler to define
> rules for how images of varying numbers of channels are converted (on
> the CPU) before uploading via OpenGL / OpenGL ES / D3D / etc.
> I suspect that the X3D folks will not be completely happy with this
> solution because they really want to figure out what the number of
> channels was in the source image, not force it into a particular
> format. Yvonne, Johannes, any comment?
The issue simply is, that X3D provides means to declaratively display content
for people that can't or won't program graphics. Thus, the programmer of the
X3D runtime certainly cannot know, what kind of content (textures etc.) for
instance John Smith wants to render with X3D next year.
But nevertheless, the X3D implementation is required to display this content
in always the same manner as described in the spec for being reliable. Thus,
we need to be able to figure out the image format at runtime, as we don't know
in advance, which particular image a scene author wants to use.
And as the number of channels ( and bytes in case of an fp tex -- BTW, is it
planned to support this? :) ) is already given in the original image and must
be known before uploading to OGL, to me it probably makes more sense, if this
the beginning I was expecting it to be there), so that one can call s.th. like
format = img.getFormat(); // with format one of Image.LUMINANCE and so on.
Hope I could clearify this problem a bit, but if the browsers' image loaders
really always call a reformat() to RGBA before setting the image, I absolutely
understand when this issue is very low on your priority list...
> You are currently subscribe to email@example.com.
> To unsubscribe, send an email to firstname.lastname@example.org with
> the following command in the body of your email:
Fraunhofer-IGD | Tel.: ++49-6151-155-290
Fraunhoferstr. 5 | Fax.: ++49-6151-155-196
64283 Darmstadt | email: email@example.com
Germany | http://www.igd.fhg.de/igd-a4
You are currently subscribe to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: