Spaces:
Runtime error
Runtime error
Commit History
-
Upload your own Polycam zip, three bundled bedroom examples, upright portrait captures
- gr.File upload (500 MB cap) with Polycam Developer Mode / raw-export instructions. The GPU reservation is sized from the frame count (15 s + 0.5 s per frame, capped at 60 s) and captures over 150 frames are sampled with a uniform stride. - Examples: bedroom-bookshelf-landscape (default), bedroom-desk-landscape and bedroom-window-portrait, fetched from pablovela5620/polycam-example-data; examples missing on the hub are skipped instead of failing startup. - orientation.py: read the phone roll from the gravity-aligned ARKit poses and rotate only the logged images and the logged pinhole camera; inference and TSDF fusion stay in sensor orientation. tests/test_orientation.py checks back-projection invariance, the np.rot90 pixel mapping and the three bundled captures. - simplecv pinned to rerun-io/examples-monorepo@90a14181 so Polycam exports that omit the camera timestamp (2026-09 format) load. - export_rrd.py writes a standalone .rrd of a run; README describes the new flow…9d992b8
-
Shrink the stream 3x, keep time-indexed meshes, hide the LiDAR 3D view
The incomplete reconstruction Pablo saw on the deployed Space was the browser still downloading: a full run streamed ~900 MB of RRD and the status line said Complete while the viewer was 30+ s behind (reproduced locally with the browser throttled to 50 Mbps: partial mesh and sparse timeline 10 s after Complete, full room at 180 s). The previous static-mesh commit misdiagnosed this as viewer memory and is reverted: meshes are time-indexed again so scrubbing replays the growth. The three full-resolution 16-bit depth panes (4.7 MB per frame, ~495 MB per run) are now sent as 16-bit PNG through rr.EncodedDepthImage, 4.3x smaller at 8 ms per image. Their colour range is computed per frame from the teacher depth (2nd-98th percentile) and shared by the LiDAR, teacher and student panes, so colours stay comparable without collapsing close-ups into the dark end of the colormap. Measured full run: 53 chunks, 306 MB, GPU time 20.9 s, zero viewer console errors; at 50 Mbps the viewer is nearly curr…51f690c -
Log the fused meshes as static so the viewer keeps only the latest version
With an update every two frames the run logged 53 time-indexed versions of three meshes (1.9 MB and up each) on top of 105 frames of full-resolution depth images. The web viewer keeps every version, ran past its memory budget and dropped data, so the deployed reconstruction looked incomplete even though the server finished all 105 frames (34.8 s GPU on ZeroGPU). Static logging keeps one mesh per source: growth is still visible while the run streams, and replaying the timeline shows the final mesh at every frame. Local full run: 18.4 s GPU, zero viewer console errors, no memory-limit warnings. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>fd7f25e -
Fill the window with the viewer and stream every two frames
The viewer block is sized in the browser after the components mount (demo.load js): window height minus the block top and the footer, then a second pass subtracts whatever container padding still overflows, so the page never shows a scrollbar. Measured at 1728x993 / 1920x1080 / 1440x900 / 1280x720 with the Debug accordion open and closed: document height equals the window in every case; the viewer went from a fixed 760 px to 833 px at 1728x993. The Blocks-level js= hook does not fire on Gradio 6.13, and a fractional height defeats the idempotency check because the browser serializes it rounded, so heights are integer pixels. BATCH_SIZE defaults to 2 (TRIO_BATCH_SIZE overrides): the meshes and depth panes now update every two frames instead of every eight, which is what makes the reconstruction visibly grow. Cost on the RTX 5090 for the full 105-frame run: 19.4 s GPU time at batch 2 (23.0 s at batch 1) versus 15.6 s at batch 8, all with zero viewer console errors. Co-Authored-By: Clau…247e452 -
Hide the depth point clouds in the 3D views by default
A DepthImage under a Pinhole back-projects into a 786k-point cloud per entity in every 3D view; three entities times three views makes the web viewer GPU-bound on overdraw (the same failure Pablo profiled in July: 2.7M points, 120 -> 16 fps). Measured here on the dl-server headless Chrome after a full 105-frame run: 0.6 fps with the clouds visible, 7.0 fps hidden, identical GPU time. The depth images stay logged and visible in the 2D panes; the 3D views carry an EntityBehavior(visible=False) override that the viewer can toggle back on. TRIO_DEPTH_IN_3D=1 restores the old default for A/B. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>d391703 -
Anchor the data/ and models/ ignore rules to the repo root
The unanchored `models/` pattern also matched the vendored `monopriors/models/`, so the depth-completion modules never reached the Hub and the Space failed at import with "No module named monopriors.models". Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>e93cc9d -
Trio Space: ARKit LiDAR vs PromptDA-L vs ZipDepth-PromptDA v4 on ZeroGPU
One hard-coded Polycam capture (6G-room-example, 105 frames) runs through PromptDA-large and the 6.95M ZipDepth-PromptDA student; raw LiDAR, teacher and student each fuse into their own TSDF mesh and stream into the embedded Rerun viewer. Both models preload to cuda at module level (ZeroGPU pattern); a Debug accordion offers a one-frame quick check so remote smoke tests cost seconds of visitor quota. Dynamic duration: 15 s quick check, 60 s full run. Environment is Pixi-locked (linux-64, CUDA 13, torch 2.12.1, rerun-sdk 0.37.0, gradio 6.13.0, gradio-rerun 0.37.0, spaces 0.51.3). monopriors inference subset is vendored unpatched from rerun-io/examples-monorepo @73592b31 (see PROVENANCE.md); simplecv and trtkit are git-subdirectory deps at the same rev. Validated on an RTX 5090: 105 frames in ~17 s of GPU time (PromptDA-L ~110 ms/frame, ZipDepth 2.3 ms/frame), quick check ~1 s, zero viewer console errors. The 3D views exclude the projection-less pinhole_lowres images, which otherwise r…ec1868d -
initial commit
Verified signature399b29e