Hello, I originally posted this e-mail on the webgl dev list here, and it was recommend I ask my questions on this mailing list.
Diagnostic medical imaging went digital many years ago, for example in radiology. In fields such as digital mammography, it is very common-place for doctors to use a software+hardware+display configuration that supports at least 10-bit grayscale or 30-bit color imaging from acquisition all the way out to the display. In fact, acquisition devices are typically even higher bit depth, as the additional source bits are useful for various image processing before being visualized on the display.
Undoubtedly there are many other fields that also currently utilize & benefit from more than 8-bits per color channel.
So, I was surprised when I found out that WebGL is built on the OpenGL ES 2.0 spec, which is extremely limiting in regards to color depth. I'm sure the choice makes sense for a variety of other reasons (e.g., mobile device gfx capabilities), but in fact browsers are also commonly used on computers with graphics capabilities that far exceed ES 2.0.
I know that the OES_float_texture extension is widely supported, and this partially addresses being able to handle high-bit-depth source images. However, one cannot render into & display results from this texture format at more than 8-bits per color channel, in spite of AMD, nVidia, & others providing 30-bit desktop solutions.
Has anyone already considered a WebGL extension that would expose a way for clients to request a backbuffer with 10 or more bits per color channel? I suspect this would be quite simple to implement in the browser if people could agree on how to define the extension. I expect that many could benefit from such an extension in the interim years that we await for the advent of WebGL 2.0/ES 3.0. Or perhaps it makes sense to expose the GL_UNSIGNED_INT_2_10_10_10_REV_EXT or GL_EXT_texture_storage extensions in WebGL?
Speaking of WebGL 2.0, how soon could we expect this to be released (with ES 3.0 features), and to become available in Chromium? End of 2013? 2014? 2015?
In terms of aiming towards a timely solution, does it make sense to push for adoption of such an extension within Khronos, or as a browser-specific extension (I see that several already exist in Chromium)?