On Sep 2, 2010, at 7:34 PM, Cedric Vivier wrote:
On Fri, Sep 3, 2010 at 10:01, Kenneth Russell <firstname.lastname@example.org>
1. What should the name of the new (boolean) pixelStorei parameter be?
The name which would most closely match the other parameters would
probably be UNPACK_CORRECT_GAMMA_WEBGL, where "correct" is a verb.
However, this name is probably confusing (why would you ever want
"incorrect" gamma?). UNPACK_PERFORM_GAMMA_CORRECTION_WEBGL?
The latter certainly sounds less confusing.
2. What should the default value of this flag be? If it were false,
then for images uploaded from the browser to WebGL, the default
behavior would be for the pixels to be completely untouched. However,
this might be surprising behavior to applications displaying images on
screen with very simple shader code (no lighting) and expecting them
to look the same as surrounding browser content.
IMHO this use case would only be likely with WebGL-based image editing, in most other applications (games, object viewers, etc) the final pixels might be too transformed through perspective, filtering, mipmapping, lighting, normal maps, light maps and so on, for slight gamma correction to really matter, so default should be false for least surprise when using non-image data.
But I'm not sure how "surprising" it would be to use a gamma corrected image in these cases. With all those manipulations on the texture, I'm not sure if most authors would even notice if the image is gamma corrected or not. So it seems like have it true gives you the more basic case, and switching it to false is a more advanced usage.
However how does the browser typically handle gamma correction? Does it perform it depending on image metadata? Display color profile? A mixture or both?
AFAIK, gamma correction is done to make images look right on the selected display. It has nothing to do with data in the source image. I believe some images might have color correction information in them, but that's different from gamma correction.