[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WEBGL_texture_from_depth_video extension proposal



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 <thundercat@illyriad.co.uk> wrote:
Would 5-6-5 cause interpolation issues? Is it and rgb or float texture?


On 10 November 2014 20:33, Florian Bösch <pyalot@gmail.com> wrote:
On Mon, Nov 10, 2014 at 8:43 PM, Kenneth Russell <kbr@google.com> 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.