[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Adding internalformat param to all texImage2d variants
On May 19, 2010, at 11:28 AM, Cedric Vivier wrote:
> On Thu, May 20, 2010 at 01:51, Chris Marrin <email@example.com> wrote:
>> I don't think specifying an RGB to Luminance conversion complicates the spec significantly.
> Ok, indeed in proposed section it would just change one case in the chart.
>> If the implementation happens to know that the image is greyscale, then it is free to use one of the color channels, as long as the result is the same.
> This is an information that sounds impractical and expensive to get, I
> can see it possible only by checking that the 3 components are equal
> for every pixel of the image, or there is some other way I overlook?
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.
>> Arbitrarily choosing one of the color channels for a grayscale image seems like the wrong way to spec conversion functionality.
> 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 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.
> 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? Even on a mobile device, doing 3 multiplies isn't particularly expensive. And there are many techniques that avoid multiplies altogether.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: