# Pose NMS · 실제 서비스 확인

이번 자료는 실제 Analytics의 Pose→NMS→Tracking→INTRUSION→Redis 결과입니다.
JPEG와 JSON은 같은 run/frameSeq이며 캡처는 PTS20.6/23.6/26.6초, 정확히3초 간격입니다.
이전 offline20/23/26초 비교와는 Frame이 다르므로 bbox 수를 직접 동일조건 비교하지 않습니다.

- [Frame206 JPEG](visual/capture-a3b83530d1054e0893687edc27aff84b/frame-206.jpg)
- [Frame206 JSON](samples/frame-206.json)
- [Frame236 JPEG](visual/capture-a3b83530d1054e0893687edc27aff84b/frame-236.jpg)
- [Frame236 JSON](samples/frame-236.json)
- [Frame266 JPEG](visual/capture-a3b83530d1054e0893687edc27aff84b/frame-266.jpg)
- [Frame266 JSON](samples/frame-266.json)
- [객체별 관절 수](pose-counts.csv)
- [처리량·비용 요약](summary.csv)

## 피드백 목록

1. 중복 bbox가 줄었으며 서로 다른 사람이 잘못 사라진 것으로 보이지 않는가?
2. 선택 bbox와 skeleton이 같은 사람에 붙어 있는가?
3. ROI 밖 초록/침입 확정 빨강과 해부학적 좌우 skeleton 색이 구분되는가?
4. Frame236의7개 관절 객체가 skeleton 미표시인 것이 min10 기준의 의도에 맞는가?
5. 상단 문구 겹침이 해소됐고 NMS 제거와 관절 부족이 별도로 이해되는가?
6. JSON의 Frame 공통 keypointSchema names/values로 [x,y,score]와 관절 순서를 이해할 수 있는가?

## 기준

이번은 INTRUSION On이므로 person score>.5가 표시 기준을 소유합니다. 독립 Pose debug .25를
이번 그림의 bbox 기준으로 해석하지 않습니다. 관절 score>=.15/최소10개는 유지합니다.
NMS는 원본100개 후보 중 IoU>.85 중복을 억제하며 raw 후보 수를 실제 고유 사람 수로 세지 않습니다.
관절 개수 표는 NMS 뒤 bbox 표시된 객체를 대상으로 합니다. source Frame 내부 후보는 최신 결과에만
bounded 보존하고 일반 Redis에는 표시된 객체만 송신합니다.

결과/Redis 약9.9798FPS(15.531초), 실제 NMS 누적 평균3.107ms, result stale/queue drop0,
Stop 접수59.3ms와 실제cleanup2.217초입니다. NMS 값은 전체 실행 평균이고 FPS 측정구간과 다릅니다.
모델 원본과 FP16의 기존 raw numerical FAIL은 사용자 제한 수용으로 유지하며 numerical PASS로 바꾸지 않았습니다.
시간은 file PTS이며 RTP/Anchor 절대시각은 null입니다. Event는 NOT_SUBMITTED/Artifact URI null입니다.
단일 채널/짧은 실행만 확인했고16채널/장시간 안정성/전체 정확도는 미검증입니다.