[Public WebGL] WEBGL_texture_from_depth_video extension proposal

Florian Bösch [email protected]
Wed Nov 12 02:55:31 PST 2014


In the right thread again, a bit more structured. I don't like this being
an extension, I don't think it's an extension to begin with. It's basically
just saying "a 16-bpp texture can be filled from an array of bytes with the
matching size", and then tacks on a tutorial on how to interprete those
bytes in a shader. It's an "extension" that regulates user behavior and
external image formats, that's got nothing todo with WebGL to begin with.

I'd propse adding a very simple change to the WebGL section of
http://w3c.github.io/mediacapture-depth/

The per-pixel bit depth of a depth video stream is 16-bit. It can be
> uploaded to any WebGL texture of matching per pixel bit depth. The depth is
> an unsigned short value and it can be interpreted in a shader as follows...


On Wed, Nov 12, 2014 at 1:26 AM, Jeff Gilbert <[email protected]> wrote:

> It seems like it would already require a bunch of code, to me. I'm not
> sure how using packed 565 instead of something else requires less code.
>
> The current proposal is an ugly hack, and I'd like to be sure there's no
> better way before considering implementing it.
> "We already have this working in prototype" is not a convincing argument
> for the quality of a spec.
>
> If all of the target devices support depth textures, but not GLES3, the
> spec should use depth textures.
>
> In GLES3, we get R16UI, though it isn't normalized. It has the same
> capabilities as DEPTH_COMPONENT16, anyways. (sampleable and renderable, but
> not filterable) It seems like you'd want normalization for something like
> this, but maybe not? If renderability isn't important, R32F could give
> normalization with sufficient precision.
>
> Regardless of all of this, like GL extensions do, it would be better if
> this extension proposal had a brief discussion of reasoning for why it
> makes the tradeoffs it does.
>
> -Jeff
>
> ----- Original Message -----
> From: "Rob Manson" <[email protected]>
> To: "Kenneth Russell" <[email protected]>
> Cc: "Daniel Koch" <[email protected]>, "Jeff Gilbert" <[email protected]>,
> "Florian Bösch" <[email protected]>, "public webgl" <
> [email protected]>, "Ningxin Hu" <[email protected]>
> Sent: Tuesday, November 11, 2014 4:11:06 PM
> Subject: Re: [Public WebGL] WEBGL_texture_from_depth_video extension
> proposal
>
> +1 for this and to us not creating more work for implementers.
>
>
> On 12/11/14 10:46 AM, Kenneth Russell wrote:
> > I still think it's reasonable to limit depth camera texture uploads to
> > just 5_6_5 textures in WebGL 1.0. WebGL 2.0 implementations are
> > actively being developed and spending excessive time on the 1.0 code
> > paths will just delay their release. Intel's already implemented the
> > depth stream upload path to 5_6_5 textures and shown some demos
> > publicly, so integrating this support will take very little time.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20141112/c4d456db/attachment.html>


More information about the public_webgl mailing list