Re: [mediacapture-depth] (16-bit) Grayscale conversion of (16-bit) depth map is wrong

The section could be replaced altogether by e.g. a link to definition in OpenGL ES 3.0 (WebGL2) specification:
https://www.khronos.org/registry/OpenGL/specs/es/3.0/es_spec_3.0.pdf

2.1.6.1 ConversionfromNormalizedFixed-PointtoFloating-Point 
2.1.6.2 ConversionfromFloating-PointtoNormalizedFixed-Point 

This is because we don't actually need to expose the information that the depth is 16-bit (and we don't do it via API) but we follow WebGL specification that the same value can be expressed as.
Note that we should probably remove any mention of 16-bit values from the spec as there is no need to force it. This would be aligned to media capture + video HTML5 API in general as there is no mention of video bit depth: 8-bit and HDR-10 bit are already implemented (at least in Chromium) and the access to color components information is the same - if user uses 8-bit API (Canvas or WebGL) there is obvious data loss (if the video is HDR-10).

The depth map value captured from the original device can be, using HTML5 canvas or WebGL API be expressed using various different formats and the value needs to be consistent regardless of the form used to represent it:

1. normalized fixed point
   a. 8-bit is accessible if using 2D canvas API or if user uploads depth video to UNSIGNED_BYTE texture.
   b. 16-bit format (is original for 16-bit depth capture) but at the moment is not accessible through the API in original form. There is a proposal to create WebGL EXT_texture_norm16 extension to expose this - as float/half float is available on all relevant platforms we should probably do it first before starting the work on extension.
  c. 10-bit format if using RGB10_A2 WebGL texture.
2. float format - if using GL_FLOAT texture
3. half-float format  - if using GL_HALF_FLOAT texture.

I'll make a PR for this.


-- 
GitHub Notification of comment by astojilj
Please view or discuss this issue at https://github.com/w3c/mediacapture-depth/issues/142#issuecomment-289063374 using your GitHub account

Received on Friday, 24 March 2017 15:56:18 UTC