DROID GT Depth 기반 VGGT-Ω 백본 재검증 및 Scale 안정성 정정

TL;DR

정확도 재확인: DROID 실측 GT depth(24 ep) 기준 VGGT-Ω AbsRel 0.120으로 전 metric 1위 — RoboCasa(sim)와 순위 완전 동일(VGGT-Ω>VGGT>Any4D>DA3)
정정: 기존 채택 근거였던 "VGGT-Ω sim3 scale 0.93~1.11 안정"은 과장 — 실제 재계산 결과 VGGT-Ω는 ep4에서 1.95~2.10으로 폭주, |1-scale| 평균은 VGGT(0.053)보다 3배 나쁨(0.167)

0.120

VGGT-Ω DROID AbsRel

DROID ep (GT 3-cam)

1.95~2.10

VGGT-Ω ep4 scale 폭주

1 배경 / 목적

260629 결정 카드(260630-vggt_omega_reward_backbone_decision.html)는 VGGT-Ω를 Phase 4 reward backbone으로 채택하며 근거를 3개로 들었다: ① RoboCasa GT 정량(AbsRel 0.296, 1위), ② DROID 정성(viser), ③ DROID sim3 temporal scale 안정성(VGGT-Ω 0.93~1.11). 그런데 ②③은 DROID에 GT depth가 없어서 정성 관찰과 scale-consistency 프록시로만 판단한 것이었다.

한계 두 가지: (1) 채택 결정이 사실상 RoboCasa(sim) 단일 정량 근거에 의존 — 실제 로봇 도메인 일반화 미보장. (2) sim3 scale 프록시는 "정확도"가 아니라 "윈도우 간 일관성"인데, 기존 카드는 이를 사실상 정확도처럼 인용했다.

사용자가 DROID 실측 GT depth 경로(/home/nas_main/dongyoonhwang/datasets/PointWorld-DROID-restored/droid/, ZED metric, 3-cam)를 제공하면서 (1)을 직접 검증할 수 있게 됐고, 이 과정에서 (2)의 원래 계산이 과장돼 있었다는 것도 함께 확인됐다.

2 작업 내용

① DROID GT 정량 검증

GT depth: depth_320x180/<uuid>_depth.h5 → [T,180,320] uint16(mm), ZED metric, valid 85~96% RGB: droid_raw/.../recordings/MP4/<serial>.mp4 (1280x720, GT h5 키와 1:1 대응) 정합: MP4 301f ↔ GT depth 301f, 프레임 인덱스 그대로 대응 (metadata frame_count 일치) 탐색: cameras/*.json의 scene_path 파싱으로 raw 경로 직접 해석 → NAS 광범위 스캔 없이 lab별 24 ep 선택 스크립트: scripts/eval_backbones_droid.py(+.sh) — eval_backbones_rgb.py(RoboCasa) 모델/metric 재사용, 데이터 소스만 교체 프로토콜(RoboCasa와 동일): timestep별 3-cam 1 multiview set, per-clip median-ratio scale align, valid=GT∈[0.1,5.0]m intrinsics/extrinsics 불필요 — 정확도는 GT↔pred depth map을 픽셀별 median-ratio align 후 비교하면 됨(unprojection 불필요) Job 67536 (1 GPU, extra QOS): 5분 31초 COMPLETED

② Scale 안정성 재계산 (기존 260629 카드 수치 정정)

DROID엔 GT depth가 없다는 전제로, 오버랩 윈도우(K frame) 사이를 Umeyama sim3(s,R,t)로 anchor해 cumulative scale per window를 추출했었다. 이번에 |1-scale| 평균과 에피소드별 분포를 다시 확인해보니, 기존 카드가 인용한 "VGGT-Ω 0.93~1.11 안정" 범위는 8개 에피소드 중 다수를 대표한 값이었을 뿐, 아웃라이어(ep4)가 빠져 있었다.

3 결과 (수치)

DROID 실측 GT — 정확도 (24 ep × 8 frame × 3 cam)

Model	AbsRel ↓	RMSE ↓	δ<1.25 ↑	δ<1.25² ↑	δ<1.25³ ↑	scale
VGGT-Ω	0.1197	0.2683	0.8935	0.9560	0.9729	1.17
VGGT	0.1691	0.3566	0.7953	0.9136	0.9512	1.06
Any4D	0.2433	0.3245	0.6948	0.8622	0.9304	0.67
DA3	0.2766	0.3695	0.6211	0.8194	0.9219	1.01

RoboCasa와 순위 완전 동일: VGGT-Ω > VGGT > Any4D > DA3 (AbsRel 기준). VGGT-Ω vs VGGT 격차는 RoboCasa 23%(0.386→0.296) → DROID 29%(0.169→0.120)로 실사 도메인에서 더 커짐. 전 모델이 DROID(실사)에서 RoboCasa(시뮬)보다 AbsRel이 낮음 — 백본들이 실사로 학습됐기 때문으로, RoboCasa 시뮬이 오히려 OOD.

Scale 안정성 정정 — |1-scale| 평균 (오버랩 윈도우, 8 ep)

Model	K=2	K=4	비고
VGGT	0.053	0.037	가장 안정
Any4D	0.086	0.048	-
VGGT-Ω	0.167	0.083	7/8 ep ≈1.0, ep4에서 1.95~2.10 폭주
DA3	0.322	0.384	ep0/1/5/6 등에서 0.18까지 체계적 붕괴

정정: 기존 260629 카드는 "VGGT-Ω 0.93~1.11 안정 (VGGT와 동급 rank-1)"이라 기술했으나, 전체 에피소드로 재집계하면 VGGT-Ω는 Any4D보다도 불안정하고(0.167 vs 0.086), DA3보다만 낫다. scale 일관성 ≠ depth 정확도 — Any4D는 scale은 안정적이나 RoboCasa/DROID 절대 정확도는 최하위권이었던 것과 대칭적인 함정.

4 Takeaway

의미

채택 결정 자체는 살아남는다. VGGT-Ω의 depth 정확도 우위(RoboCasa+DROID 양쪽 GT, 전 metric 1위, 실사에서 격차 더 큼)는 이번 검증으로 오히려 강화됐다. 단, 결정 근거 중 "scale 안정성"을 든 부분은 사실이 아니었다 — VGGT-Ω는 특정 에피소드(ep4)에서 2배 가까운 scale 폭주가 있고, 전체 평균으로 보면 Any4D보다도 불안정하다.

reward backbone 선택 기준을 "depth 정확도"로 유지하는 한 결정은 바뀌지 않지만, reward 설계에서 scale normalization 없이 raw depth를 그대로 쓰면 VGGT-Ω의 occasional scale blowup이 reward 신호를 오염시킬 수 있다는 점을 새로 고려해야 한다. 문서 위생 측면에서도, 기존 카드의 근거 하나가 재검토 없이 인용되며 부풀려진 사례 — 프록시 지표(sim3 scale)를 정확도처럼 요약하면 안 된다는 교훈.

5 Next Steps

미해결 한계

VGGT-Ω ep4 scale 폭주(1.95~2.10)의 원인 미분석 — 특정 장면 특성(반사/저텍스처/카메라 배치) 때문인지, 모델 자체의 실패 모드인지 구분 안 됨. 24 ep는 정확도 검증엔 충분하나 scale 안정성 실패율(1/8) 추정엔 표본이 작음.

다음 실험

(1) reward 설계 시 raw depth scale을 그대로 쓰지 않고 per-window/per-clip normalization을 넣어 VGGT-Ω의 occasional blowup에 대한 robustness 확보. (2) ep4류 실패 사례를 viser로 직접 재생해 원인(장면 특성 vs 모델 실패) 규명. (3) DROID GT로 reward 변환 시 signal-to-noise sanity check(제안: RoboCasa GT처럼 reward saturate 여부 확인) — 260629 카드의 "Next"에 이미 있던 항목이나 이번 scale 발견으로 우선순위 상향.