I have several points which I am grouping in this single message
rather sending a flood of new messages.
The necessary correction most definitly has something to do with the data in the source image. It is dependent on that, the display and the viewing conditions. Judging from your later posts, I think you have already realized this.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.
There is no such thing as the JPEG file format. There are two file formats in common use that store JPEG compressed images: JFIF and EXIF. The JFIF spec. does not include color space information. However it does provide application tags that can be used to store this information. One example of using an application tag is EXIF. EXIF, the output format of the majority of digital still cameras, uses an application tag and in it writes a lot of metadata about the image including the color space information. Vrtually all cameras include the color space information when writing this tag.I see nothing in the JPEGImageDecoder related to gamma. Is anything needed for this file format? I suspect people will not use JPEGs for anything they expect to be passed through verbatim to WebGL, such as encoding non-color information in the color channels of a texture.
Since we don't have blend shaders the only way to do this correctly is to create another renderbuffer and do another pass over the data. But since WebGL is already using a renderbuffer to composite the canvas with the page, the only approach that makes sense performance wise is for the browser to do the conversion while compositing the page. So the canvas to be in a physically linear space like the ICC profile connection space.All that is a pretty clear indication that the pixels in the canvas are expected to be in the sRGB color space and when they are composited they are transformed into the display's color space. An author who really cares, can render textures into the WebGL canvas knowing the image is in the sRGB space and that the final image in the canvas should be in the sRGB space, and apply the appropriate factors to make that so.
and* The PNG file format stores things in linear color space. If you plan to display them on a NON gamma corrected medium - then you need to apply gamma to it...which (I presume) is what that snippet of code that you presented actually does.
- no need to convert PNGs because they are already linear.
When the incoming image has unknown gamma (gAMA, sRGB, and iCCP all absent), choose a likely default gamma value, but allow the user to select a new one if the result proves too dark or too light. The default gamma can depend on other knowledge about the image, like whether it came from the Internet or from the local system.Nowhere does it suggest that a likely default value is 1.0 (linear). If any of the above chunks do exist, the decoder is supposed to use them to display the image correctly.
No. See above.I think if you reverse-gamma JPEG files and leave everything else alone, you'll be OK.
begin:vcard fn:Mark Callow n:Callow;Mark org:HI Corporation;Graphics Lab, Research & Development adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan email;internet:email@example.com title:Chief Architect tel;work:+81 3 3710 9367 x228 tel;fax:+81 3 5773 8660 x-mozilla-html:TRUE url:http://www.hicorp.co.jp, http://www.mascotcapsule.com version:2.1 end:vcard