# Pose 변환 전/후 사용자 확인

현재 자료는 승인 영상의 동일20/23/26초 Frame을 사용한 offline 변환 비교입니다.
왼쪽 reference, 오른쪽 FP16입니다. 실제 SDK Pipeline/Redis/Tracking 자료는 아닙니다.
JSON의 identity/objectRef는 이 비교의 fixture이며 trackId는 미측정 null입니다.
Frame seq는 영상 추출 위치 표시이고 actual decoded ingress 순번이 아닙니다.
RTP/Anchor/실제 ingress 시각은 미확보입니다. ingestTimeWallMs는 null로 표시합니다.

- [20초 비교](compare-20.jpg) / [대응 JSON](compare-20.json)
- [23초 비교](compare-23.jpg) / [대응 JSON](compare-23.json)
- [26초 비교](compare-26.jpg) / [대응 JSON](compare-26.json)
- [객체별 유효 관절 수 CSV](pose-counts.csv)
- [요약](summary.json)

## 확인할 항목

1. 좌/우 같은 사람의 bbox와 관절 위치 차이가 실무 확인에 허용 가능한가?
2. 관절 score .15, 최소10개에서 skeleton이 너무 많이/적게 보이는가?
3. 23초 왼쪽 끝 다수 bbox는 reference에도 있다. 해당 현상을 허용할지 후속 필터 검토가 필요한가?
4. 23초의 가까운 사람은9개 관절로 reference skeleton이 숨겨진다. 최소10개 기준의 의도와 맞는가?
5. 변환 차이가 허용 가능하다면 이 exact FP16을 다음 제한 SDK/Runtime 검증 후보로 수용할 것인가?

표의 수는 실제 고유 사람 수가 아니라 후보 수입니다. CSV skeleton_eligible=False 행이 필터링된
대상입니다. keypoints 원본은 JSON에 보존되고 표시 필터로 삭제되지 않습니다.
기존 그림의 상단 class/pose 문구 중첩은 source에서 교정했고 그림은 추가 재추론 없이 보존했습니다.
기존 FP16 raw numerical FAIL은 그대로이며 사용자 시각 수용으로 numerical PASS로 바꾸지 않습니다.
SDK ingress 실패가 별도로 남아 있어 이미지 수용만으로 실제 서비스 적용이 완료되지 않습니다.