[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Adding internalformat param to all texImage2d variants
On Fri, May 21, 2010 at 00:03, Chris Marrin <firstname.lastname@example.org> wrote:
> If the original image is grayscale and the implementation is storing it as RGB, then you know you can simply choose one of the channels.
Yes, and just choosing "arbitrarily" R works as well in this case.
>> This is not arbitrary if you consider that the conversion table fully
>> mirrors the behavior of samplers in ES / GL.
>> Imho what is arbitrary is to define how grayscaling should be done, as
>> Gregg put it earlier :
>> "What does it mean to convert to gray scale? ÂIs this a gamma biased
>> conversion? One that multiplies R G and B as appropriate for their
>> overall contribution to luminance? Take max of R, G, B? What if my app
>> needs it one way and yours another?"
> There has been a standard technique for converting RGB to grayscale for at least 50 years. If it's not what you want then you're free to load RGB and use the shader to do the conversion.
I assume the "standard" formula you are thinking about is L = 0.3*R +
0.59*G + 0.11*B.
Your argument that it can be done in the shader is exactly reverse of
mine, if you want to use formula above you can do it in the shaders...
On the other hand, you didn't consider the important implication that
this technique (in opposition to just using R) makes WebGL's
conversion incompatible with GL's conversion and sampling, whose
strict equivalence is the only way to guarantee equivalent results in
both software and shaders.
Also, your formula would make WebGL unable to just use glTexImage2D
directly on desktop GL (it uses the R component).
>> I would think that WebGL doing such conversion from an RGB that is not
>> already greyscale would be a little bit too implicit imo.
> Not at all. It's there to fill in the box in the table. As it turns out, it's extremely convenient to be able to use an RGB as a grayscale image. It allows you to use a JPG image to store a mask, for instance.
You can do that already, provided that the JPG image is grayscale (in
which case R = G = B).
What I meant by "too implicit" is that usage of an image as a mask
typically requires some preprocessing in the assets production
pipeline for meaningful results. Can you point to an example where
usage of a non-grayscale image is used as a mask in a meaningful way?
>> I argue that if the developer asks for the image to be stored in
>> LUMINANCE format it is his responsibility to ensure the image is
>> prepared for such usage (e.g normal|bump maps), if he wants instead to
>> present a greyscaled image on the screen this can be done easily and
>> dynamically in shaders with the RGB to greyscale formula of his
> Yes, it makes sense that the author needs to understand what they're doing. But if you have a feature that converts RGB to grayscale, why not do it the right way? Are you concerned about the expense?
No, I'm concerned about introducing a conversion that is not done by
GL in general or ES samplers in particular, for all reasons above.
That said I don't necessarily think that doing RGB-to-grayscale
conversion as in formula above is a bad idea, I just think it must be
explicit in order not to implicitly introduce all of the
incompatibilities mentioned, e.g with a DOM_GRAYSCALE texture
parameter boolean if we do have an extensible way to define new
DOM-to-texture conversion options as discussed in another thread.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: