[Public WebGL] WEBGL_texture_from_depth_video extension proposal

Ben Adams [email protected]
Mon Nov 10 21:49:03 PST 2014


i.e. would this mean nearest sampling would be required where the mapping
between screen pixels and depth camera is not 1:1

(though I don't know if there is sampling types on a depth buffer :)

On 11 November 2014 05:34, Ben Adams <[email protected]> wrote:

> Would 5-6-5 cause interpolation issues? Is it and rgb or float texture?
>
>
> On 10 November 2014 20:33, Florian Bösch <[email protected]> wrote:
>
>> On Mon, Nov 10, 2014 at 8:43 PM, Kenneth Russell <[email protected]> wrote:
>>>
>>> It'll only be efficient to upload depth videos to WebGL textures using
>>> the internal format which avoids converting the depth values during
>>> the upload process. That's why UNSIGNED_SHORT_5_6_5 was chosen as the
>>> single supported format for uploading this content to WebGL 1.0. It's
>>> not desirable for either the browser implementer or the web developer
>>> to support uploading depth videos to lots of random texture formats if
>>> they won't be efficient. The Media Capture group should comment on
>>> what formats depth cameras tend to output, and are likely to output in
>>> the future.
>>>
>>
>> I think it's demonstratable that conversion between formats is reasonably
>> efficient if it can be done on-GPU, which is something that's just about
>> getting done for <video> now.
>>
>> The reason I'm not in favor of fixing this to ushort 5-6-5 is because it
>> is quite often the case that an app developer would want something else to
>> use. So for instance because you cannot interpolate 5-6-5 that's been
>> bastardized to hold a single depth value, you'd then proceed to write your
>> own framebuffer to decode it to say, byte, int, float or what have you.
>> Likewise, 5-6-5 smells smack of an internal format, that's liable to change
>> with whoever's putting out the next depth capture device, and so, latest by
>> that point, you'll be converting something like say, a floating point depth
>> TO 5-6-5, which would be more than a little ironic.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20141111/b8a162ef/attachment.html>


More information about the public_webgl mailing list