회전 관측 보존: 기존 대비 개선과 기본값
2026-10-23, d34f484의 회전 관측 보존 기능을 같은 입력에서 껐다 켜며 비교했다.
이후 작업 트리에서 기본값 정책을 변경하고 회귀 검증했다. 알고리즘의 구현 기반은
737f0c5이며, 각 측정 기록에는 실제 HEAD, 변경 여부, 소스 해시가 있다.
이는 일반 영상 개발 계획의 첫 회전·관측 보존 단계다.
적용한 기본값
공급한 카메라 내부 파라미터로 실행하는 경로에서 rotationTracking을 기본 활성화했다.
회전으로 시작하는 구간의 연결과 깊이를 확정할 수 없는 관측의 보존에서 이득이 컸고,
비교한 일반 이동의 기하와 GPU 전송량은 유지됐다.
| 호출 조건 | 동작 |
|---|---|
focalSearch 생략 또는 false, rotationTracking 생략 |
활성화 |
rotationTracking: false |
기존 E/H 기반 관측 그래프 유지, tracking 메타데이터 없음 |
자동 focalSearch, rotationTracking 생략 또는 false |
비활성화; 후보 평가·최종 지도·세션 재개에서도 유지 |
자동 focalSearch와 명시적 rotationTracking: true 또는 설정 객체 |
기존과 같이 오류: 이 조합은 미지원 |
이 정책은 CPU mapper, scene mapper, GPU mapper, float 특징점 어댑터와 스트리밍 세션에 적용된다. 기존 TypeShade 연산, TypeCV 기하와 트랙 구성을 재사용하며 새 의존성은 없다. 잘못된 K를 자동으로 판별하거나 모르는 줌을 추정하는 기능은 아니다. 상대 회전은 새 깊이, 카메라 중심, 정적인 배경이라는 증명을 제공하지 않는다.
비교 방법
- CPU: 합성 12개 기본 시나리오, 인접 연결만 남긴 회전 시작 5개 노이즈 조건, 잘못 연결한 대응점 1개 조건의 총 18개. 내부 파라미터와 합성 대응점을 공급한 기하 실험이며 RGB 특징점 성능의 근거로 사용하지 않는다.
- RGB: 같은 방을 렌더링한 이동·회전·회전+줌 PNG와 실제 피라미드 샘플 8장.
디코딩한 픽셀에서 GPU FAST/BRIEF·매칭을 실행하고 동일한 결과를 양쪽 mapper에 공급한다.
합성 입력은 알려진 K, 피라미드는 가정한
0.8 × widthK를 사용한다. Lab의 SIFT/KLT를 대체하거나 게임플레이 성능을 대표하는 실험은 아니다. - 각 모드 1회 워밍업 뒤 6회 측정하며 off/on 순서를 번갈아 바꾼다. 두 벤치마크와 다른 검증을 동시에 실행하지 않는다. 입력 해시와 실행 후 불변성도 확인한다.
- 정답 포즈·깊이는 평가에만 사용한다. CPU는 초기 프레임의 정답 방향·중심과 초기 baseline 길이로 지도 전체에 하나의 좌표계를 정한다. 회전 구간의 거의 같은 카메라 중심만으로 정렬하면 생기는 모호성을 피한다. 프레임별로 정렬하지 않는다.
- 초기화 실패의 기존 내부 E/H 트랙도 별도 실행으로 직접 조사한다. 기존 API에 tracking 출력이 없다는 이유로 기존 트랙 수를 0으로 계산하지 않는다.
CPU 원시 기록: rotation-tracking-cpu-comparison.json. RGB 원시 기록: rotation-tracking-rgb-comparison.json. 기본값 변경의 명령·환경·소스 해시: 검증 기록.
정확도와 관측 보존
| 조건 | 비활성화 → 활성화 | 해석 |
|---|---|---|
| 회전 시작, 인접 프레임 연결, 노이즈 0 | 등록 3/5 → 5/5, 점 60 → 60 | 등록률 +40%p; 동일 점에 연결된 관측 180 → 300 |
| 같은 조건, 결정적 좌표 교란 진폭 0.1px | 등록 3/5 → 5/5 | 최대 회전 오차 0.086° → 0.052°, 점 RMSE 0.0846 → 0.0509 장면 단위 |
| 기존 지도에서 회전 중에만 본 새 점 | 점 40 → 40, 새 미삼각측량 트랙 20개 보존 | 카메라 이동만으로 미재관측 점의 깊이를 확정하지 않음 |
| 그 점을 이후 이동한 시점에서 재관측 | 점 60 → 60, pending 0 | 기존 삼각측량 조건이 충족돼야 구조로 승격 |
| RGB 회전 | 내부 트랙 136 → 357, 관측 306 → 871 | 트랙 +162.5%; 상대 회전 9개, 최대 오차 0.162° |
| RGB 회전+알려진 줌 | 내부 트랙 82 → 141, 관측 164 → 303 | 트랙 +72.0%; 상대 회전 4개, 최대 오차 0.074° |
| RGB 이동 / 실제 피라미드 | 등록 5/5·234점 / 8/8·333점 유지 | 보존된 트랙이 새로 필요한 조건이 아니면 등록 수 이득 없음 |
합성 순수 회전·회전+줌·평면·먼 배경과 잘못된 대응점 조건에서 두 모드 모두 잘못된 지도 초기화는 0회였다. 제공한 연결이 없는 부분 지도를 강제로 합치지 않았다. 이는 자동 컷 검출, 반복 에셋 식별, 잘못된 장소 검색 결과를 배제하는 검증을 뜻하지 않는다.
노이즈 0.3px와 0.7px 조건에서도 등록은 3/5에서 5/5로 늘지만 기하 정확도 합격으로 세지 않는다. 예를 들어 0.7px에서 점 RMSE는 48.99 → 47.75 장면 단위로 양쪽 모두 크다. 오류가 큰 구조에 대한 불확실성 보정·추가 거부 조건은 남아 있으며, 등록 수만으로 복원 성공을 판정하지 않는다. 1px에서는 양쪽 모두 5/5로 등록해 추가 등록 이득이 없다.
처리 비용과 실행 환경
회전 시작의 무노이즈 CPU 실행은 49.19 → 69.53ms로 늘었다. 두 카메라의 실제 PnP·최적화 작업도 추가되므로 전체 시간이 41.3% 늘며 속도 향상은 아니다. 잘못된 대응점만 있는 조건은 158.73 → 195.96ms(+23.5%)로, 회전 가설을 시도하는 비용만 발생했다. 비용이 더 중요한 호출은 명시적으로 끌 수 있다. 일반 이동·공전 등 작은 조건에서는 시간 차이가 양방향으로 흔들려 속도 개선의 근거로 삼지 않는다.
RGB 측정은 Google SwiftShader 소프트웨어 WebGPU, Chromium 154, Node 24.19.0에서 했다. 회전 가설은 기존 f64 CPU 수학으로 계산하며, GPU 회전 커널의 가속을 주장하지 않는다. 최종 반복 측정에서 공통 프런트엔드 시간을 더한 총시간은 다음과 같다. 단위는 ms다.
| RGB 조건 | 공통 프런트엔드 | mapper 비활성 → 활성 | 합산 총시간 비활성 → 활성 | 차이 |
|---|---|---|---|---|
| 이동 | 1534.4 | 863.00 → 932.75 | 2397.40 → 2467.15 | +2.91% |
| 회전 | 768.2 | 535.70 → 553.35 | 1303.90 → 1321.55 | +1.35% |
| 회전+줌 | 727.7 | 192.25 → 201.15 | 919.95 → 928.85 | +0.97% |
| 실제 피라미드 | 2802.3 | 1898.85 → 1933.80 | 4701.15 → 4736.10 | +0.74% |
mapper upload/readback 바이트와 read 호출 수는 같았다. 순서대로 683164/56016 bytes·147회, 34976/13220 bytes·70회, 6528/4608 bytes·30회, 1402168/114556 bytes·316회다. 상대 회전 계산 자체가 GPU 전송을 추가하지 않는다. 추후 트랙 덕분에 새 카메라·점이 등록되면 그 처리에 필요한 GPU 작업은 늘 수 있다.
RGB 기록의 전체 시간은 디코딩·특징점·업로드·매칭·readback·해제를 한 번 측정하고, 이를 각 mapper 측정에 더한 값이다. 전체 프런트엔드를 6번 다시 실행한 분포는 아니다. mapper 단계별 시간·전송·동기화 카운터와 메모리 피크를 기록했다. 활성 할당과 재사용 풀을 구분하며, 매 실행 후 활성 GPU 바이트와 최종 device 폐기 후 버퍼 수는 0이다. 메모리는 드라이버, 디코딩 픽셀과 host 그래프를 포함하지 않는다. 실제 하드웨어 GPU의 속도·메모리, 일반 게임 영상, 영상 코덱, MVS 및 Radiance 렌더링 성능은 측정하지 않았다. 각 모드의 시간 분포가 겹친다. 이 6회 측정의 차이로 안정적인 속도 개선이나 고정된 추가 비용을 보장하지 않는다.
재현과 남은 조건
npm run build
node scripts/benchmark-general-video.mjs --render-dir=data/general-video-fixtures --output=/tmp/general-video-geometry.json
node scripts/benchmark-rotation-tracking.mjs --repeats=6
TYPESHADE_CHROMIUM=/usr/bin/chromium node scripts/benchmark-rotation-tracking-rgb.mjs --repeats=6
회귀 검증은 기본값의 회전 구간 보류, 이후 baseline 연결, 명시적 비활성화, 자동 초점거리의 후보·최종·재개 경로, float 어댑터의 설정 전달을 포함한다. 핵심 273개, 영향받는 TypeShade CPU 12개, 소프트웨어 WebGPU 2개가 통과했다. 타입·포맷·빌드, Astro 검사(오류·경고 0, 기존 hint 4), 81페이지 생성과 정적 링크도 통과했다. 전체 TypeShade/WebGPU/UI 테스트 묶음을 재실행한 것은 아니다. 현재 단계의 API와 한계는 rotation-tracking.md에 있다. 알 수 없는 연속 줌, 스코프의 복수 투영, 동적 객체 분리, 자동 컷·재지역화, 세션 윈도 밖 미확정 관측의 장기 보존과 Radiance 동적 표현은 이번 기본값 변경에 포함하지 않는다.