Skip to content
This repository has been archived by the owner on Feb 1, 2022. It is now read-only.

From quantized depth to depth measurement in mm; need a convenience function? #112

Closed
anssiko opened this issue Mar 22, 2016 · 1 comment

Comments

@anssiko
Copy link
Member

anssiko commented Mar 22, 2016

Currently, web developers are expected to do some math themselves (see below) to convert the quantized depth value they get from the API to the actual depth measurement in millimeter units that tell the distance from the camera to the object at that particular point.

I'm asking for feedback whether we should:

  • Option 1: provide a convenience function that takes a quantized depth value d8bit and returns the corresponding depth measurement d in millimeters, or
  • Option 2: add a non-normative section that gives explicit guidance to web developers how they should do this conversion themselves, along with some practical examples.

This is what web developers are currently expected to do (option 2):

The depth measurement d (in millimeter units) is recovered by solving the depth to grayscale conversion for d as follows:

  • If the depth to grayscale conversion is linear, given d8bit, near and far, we first normalize d8bit to [0, 1] range:

normalize

... and then solve the rules to convert using range linear for d:

depth_from_linear

  • If the depth to grayscale conversion is inverse, given d8bit, near and far, we similarly first normalize d8bit to [0, 1] range:

normalize

... and then solve the rules to convert using range inverse for d:

depth_from_inverse

This translates into a couple of lines of boilerplate JavaScript code, that I assume, will be rolled into a JS library as usual at some point. I think I'm leaning toward option 2 for v1 at least, but wanted to loop you in before baking this into the spec.

(As a recap, the reason why we have two ways to do the depth to grayscale conversion is that inverse allocates more bits to the near depth values and fewer bits to the far values (think GPU z-buffer), more appropriate if the source depth map bit depth is greater than 8, while linear allocates the bits evenly, better to be used if the source depth map bit depth is 8 or less.)

@anssiko
Copy link
Member Author

anssiko commented Mar 29, 2016

We settled on using range inverse only in #115. I added a non-normative note how to reconstruct the depth measurement in #117 (commit c9d598c).

anssiko added a commit that referenced this issue Mar 29, 2016
Fix #112, #105: Add a note how to reconstruct depth & accessibility tweaks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant