[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Adding internalformat param to all texImage2d variants
Am Mi, 19.05.2010, 20:08, schrieb Chris Marrin:
> On May 19, 2010, at 10:47 AM, Yvonne Jung wrote:
>>> ...This is where things get problematic. If we provide a mechanism to
>>> convert to
>>> the desired internalformat, without the NO_CONVERT option, most authors
>>> all the information they need. They can force the format they want,
>>> of the input format, and write their shaders accordingly. It might be
>> Considering that only 8 bit textures are available and no floating point/
>> depth precision can be forced, the internalFormat param might more or less
>> only be interesting for transparencies and the aforementioned texture memory
>> But querying the original image format can have different use cases,
>> particularly in the web, where data can originate from everywhere...
>>> to just provide the explicit conversion options (without NO_CONVERT) and
>>> come up with a different method of discovering the image formats. You
>>> be able to determine the basic image type from the mime-type, right? In the
>>> case of JPG, this defines the format. Is there any way to use XHR to read
>> No, JPG can also be e.g. LUMINANCE.
> In X3D, how can you know if you want to use a JPEG image as Luminance rather
> than RGB?
The author of a concrete X3D scene not only provides the 3D models but also
the correspondin textures. These are designed in the format he thinks fits
best to his application under consideration of the X3D lighting model.
The developer of the X3D player cannot know in advance in which format the
texture will be provided, hence when loading the image not only the pixels but
also this information needs to be queried.
When e.g. using the C library jpeglib for loading a JPG, this information is
available not until after having called jpeg_start_decompress(). Then, based
on this information, the appropriate shading model is chosen internally.
>>> header of a PNG image and read the format tag from that?
>> I don't know if it's possible at all, but retrieving the image via XHR (or
>> only the header, which I doubt is possible) seems to be a big overhead
>> concerning bandwidth and processing power since the browser has to fetch the
>> image anyway.
> It may not be a bandwidth issue, if the browser is properly caching. I would
> have to try it, but I think responseText will give you the raw bytes if you
> use the overrideMimetype() trick. Then you just get the IHDR chunk (which must
> be the first tag), which gives you width, height, bit depth and color type
> (which gives you the format:grayscale, rgb, indexed, grayscale-alpha, or
> Seems like it should be possible, but again, I have not tried it.
> Hopefully in the future you'll be able to get an ArrayBuffer from XHR, which
> will make things a bit easier.
If this really works (I also haven't tried it), then this could be a
workaround -- but only for those image types, that encode all relevant
information such as the number of channels in their header, without requiring
to first decompress the image etc.
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: