2.0: ONNX export, depth estimation from a photo, browser demo - #3
Merged
Conversation
Gradients were computed on raw pixel values, so a 16-bit depth map produced gradients 256 times larger than the 8-bit copy of the same surface and `strength` meant something different in each file. Depth is now rescaled to a fixed 0-255 range first (`--range auto|minmax|raw`, `raw` keeps the old behaviour), so both copies produce identical normals. Around that: - `export` writes the conversion as a standalone ONNX graph (dynamic H/W, strength as a graph input) that matches the NumPy path to within one level out of 255, and runs about 5x faster. - `--estimate` runs Depth Anything V2 Small through ONNX Runtime, so a photograph is a valid input. The model is downloaded once, checksummed and cached. - `web/` is a no-build browser demo running both models client side. - SciPy is gone: all three gradient methods are separable, so pure NumPy matches it to 1e-13 at the same speed and 19.5 MB less to install. - Borders reflect instead of repeating the edge pixel, which is what makes the exported graph match exactly. - README rewritten, `run.py` dropped, Python 3.14 added to CI.
… 3.11+ The converter still runs on 3.10; only depth estimation is gated. Verified by running the suite on 3.10, where the ONNX Runtime tests skip.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this is
depth2normaldid the easy half. You still needed a depth map to start, and Python to run the result. This covers both ends, and fixes a bug in the middle.The bug
Gradients were computed on raw pixel values, so a 16-bit depth map produced gradients 256 times larger than the 8-bit copy of the same surface. Measured on
assets/depth.pngat the defaults:The two 2.0 rows are the same bytes.
--range rawreproduces the old behaviour.What is new
depth2normal export): two Conv nodes and a normalisation, 1.1 to 6.1 KB, dynamic height and width,strengthas a graph input. Agrees with the NumPy path to within one level out of 255 on at most 2.8% of pixels, and runs about 5x faster (sobel: 41 ms to 5 ms on a 2048x1152 map).--estimate): Depth Anything V2 Small (Apache-2.0) through ONNX Runtime, downloaded once, checksummed, cached. 230 ms for a 640x480 photo on an M4 Pro CPU.web/): no build step, both models run client side, nothing is uploaded. Verified end to end in Chrome.--invertfor depth maps where bright means far.Housekeeping
README rewritten with measured numbers,
run.pydropped, Python 3.14 added to the CI matrix, plus a CI check that the committed web models still match the code. 71 tests, ruff clean.The CLI keeps its old shape:
depth2normal depth.png -o normal.pngworks exactly as before.