[Public WebGL] WEBGL_texture_from_depth_video extension proposal

Florian Bösch [email protected]
Wed Nov 12 03:24:04 PST 2014

I'd really rather not have an extension, and lengthy discussion on the
nonsensical nature of it for something that's essentially a few lines of
code ala pseudocode:

if obj.isVideo
  if internalFormat.bitDepth == video.bitDepth
    texImage2D obj.bytes
   throw "bit depths do not match"

Not supporting the video formats, that the browser implements isn't a
"capability". It's a bug.

On Wed, Nov 12, 2014 at 11:55 AM, Florian Bösch <[email protected]> wrote:

> 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/65255539/attachment.html>

More information about the public_webgl mailing list