Specialize ImageData type for Depth

[bbernhar]

Per discussion in #130, this proposal suggests creating a specific DepthImage type where DepthImage.data creates a default Uint16ClampedArray view. In contrast to the ED 6.7, ImageData.data will not have an overloaded meaning (color vs depth) with the depth extension and equally (and more intuitively) access 16-bit dexels without further reconstruction (due to packing of D16 with RG88 for video+canvas sink). Implementation wise, the DepthImage object exposes a "view" of the internal ImageData.

Alternatively, the ImageData object could be modified (or extended) but this approach frees us from handling depth-specific design issues with the canvas authors.

https://msdn.microsoft.com/en-us/library/windowspreview.kinect.depthframe.aspx
https://bugs.chromium.org/p/chromium/issues/detail?id=624436

[huningxin]

We need revisit this for video+canvas sink as TPAC meeting attendees are not positive to the depth value reconstruction from RG88 solution.

@bbernhar , could you please elaborate a bit more about the DepthImage interface and laternative ImageData extension solutions?

[astojilj]

Short update on implementation in Chromium:
The idea is to use WebGL with extended precision formats; float (WebGL1+) or unsigned short (WebGL2):
https://crbug.com/624436#c43

If needed to get the data from texture, the test here contains the code:
https://codereview.chromium.org/2476693002/patch/100001/110005
In short, upload the video to texture and then bind that texture to named framebuffer and read back to Float32Array/uint16 using readPixels. This has it's constraints but it is possible to optimize access to mapped texture buffer as there is no draw while the framebuffer was bound.

[astojilj]

I'll start work on this. The plan is to remove approach reconstructing 16-bit value from low byte R and high byte G and define R16UI and Float WebGL approach with example.