실행 파일 : TrackingProgram.py
핵심 코드 : CoreTech.py

2020.11.13
목차

1. 프로젝트 요구사항 확인
   1.1 개요
   1.2 제안사항
   1.3 방향성

2. 프로젝트 설계
   2.1 객체 인식 모델
   2.2 객체 추적 알고리즘
   2.3 유저 인터페이스

3. 모델 채택
   3.1 YOLOv4
   3.2 Deep Sort
   3.3 PyQt5

4. 모델 평가
   4.1 YOLOv4 평가
   4.2 Deep Sort 평가

5. 알고리즘 추가 &수정

6. 성능 평가
   6.1 평가지표의 필요성
   6.2 평가 방식
   6.3 평가 함수화
   6.4 평가 비교군 선정

7. 기능 개선
   7.1 기능 개선의 필요성
   7.2 Tracking On/Off/Reset 기능 추가
   7.3 캡처 비디오 프레임 사이즈 제한 기능 추가

8. 처리되지 못한 제한 사항들

9. 프로젝트 요구사항 확인
   1.1 개요
   1.1.1 목적: 피겨스케이팅 공연간에 각각의 공연자들에 대한 촬영
   1.1.2 문제점: 피겨스케이팅 특성상 공연자들의 이동이 빨라 카메라 감독이 직접 따라가며 촬영하기에 어려움을 겪어 촬영에 공백이 생기거나 놓치는 현상이 발생
   1.1.3 목표: 추적 알고리즘을 통해 메인 카메라에서 프레임 데이터에서 개별 인물의 추적 좌표를프로그램이 신호화 하여 촬영장비의 움직임을 제어하도록 하는 소프트웨어의 개발 시도
   1.2 제안사항
   1.2.1공연자 4명에 대한 인식과 개별 추적
   1.2.2실시간 추적이며 추적간 딜레이 2초 이하
   1.2.3 이 후 프로젝트 진행을 위한 제약사항 도출
   1.3 방향성
   1.3.1 알고리즘으로 공연자 위치추적 소프트웨어 적용 가능성을 확인하고 이후 프로젝트에서 실제 적용 고려

10. 프로젝트 설계
    2.1 객체 인식을 위한 디텍션모델
    2.1.1 디텍션 모델의 후보를 선정하고 프로젝트에 적합한 모델 채택
    2.2 객체 추적을 위한 트래킹알고리즘
    2.2.1 트래킹 알고리즘의 후보를 선정하여 프로젝트에 적합한 알고리즘 채택
    2.2.2 채택 후 평가를 통해 프로젝트의 목적성에 맞게 커스터마이징
    2.3 적용 결과 디스플레이를 위한 유저 인터페이스
    2.3.1 PC환경에서의 실행을 위한 PyQt와 모바일 환경에서 실행을 위한 Android 중 선택
     

11. 모델 채택
    3.1 YOLOv4
    3.1.1 인식 모델로 YOLOv4가 인식 기술 중 속도대비 성능이 가장 우수해 채택
    3.2 Deep Sort
    3.2.1 추적 알고리즘으로 Deep Sort가 가장 보편적으로 쓰이고 성능이 우수해 채택
    3.3 PyQt5
    3.3.1 인식과 추적을 모두 적용하고 실시간 처리를 해야 하며, 속도의 제한 역시 존재
    3.3.2 컴퓨팅 파워의 제한이 존재하는데 비해 모바일 환경에서의 구동 시의 이점이 의미가 없어 Python 기반 UI 플랫폼인 PyQt5 사용

12. 모델 평가
    4.1 YOLOv4
    4.1.1 성능은 실제 테스팅 영상에 적용시켰을 경우 약간의 예외상황이 존재하지만 성능이 준수하며 인식 모델 자체의 성능을 개선하는 것은 데이터, 시간적 측면에서 어렵다고 판단하여 모델의 버전만을 고려하여 채택
    4.2 Deep Sort
    성능은 준수하나 예외상황에 대한 처리가 부족해 다음과 같은 한계점을 정의
    4.2.1 인물의 역동성이나 조도차이로 같은 대상에 대해 다른 인덱스를 부여하는 인덱싱 추가 발생 현상 확인
    4.2.2 인물간의 겹침으로 인해 프레임안에 추적하던 대상이 사라졌다고 인식 모델이 판단하여, 추적 알고리즘에서도 해당 인물이 다시 등장하면 새로운 인물이라고 특정 짓는 추적 실패 발생
    4.2.3 프레임 안에 대상으로 하는 공연자를 외의 인물이 인식되었을 경우 인덱스가 추가 발생하여 추적 실패 발생
    4.2.4 인물간의 겹침으로 인해 인물이 사라질 때, 가장 가까운 인물에게 인덱스가 옮겨지는 인덱스 전이현상 발생
     

13. 알고리즘 추가 & 수정
    추적 알고리즘의 한계점들을 개선할 추가적인 알고리즘을 제시
    5.1 모든 경우의 추적 매칭 상황에 대해 가정하고 처리
    네명의 사람에 대한 추적 처리에 있어서 매칭에 성공한 사람, 매칭에 실패한 사람에 대한 경우의 수를 예외없이 처리할 수 있는 조건식이 필요
    따라서 가정할 수 있는 모든 경우에 대해 처리할 수 있는 조건식을 다음과 같이 설정함.
    5.1.1 조건1: 4명 이하로 처음 인식된 객체들에 대해서는 1~4의 인덱스를 순차 부여
    1.1 Detected: 0
    2.2 Detected: 1, Tracking: 0, Unmatched: 1
    3.2 Detected: 2, Tracking: 1, Unmatched: 1
    3.3 Detected: 2, Tracking: 0, Unmatched: 2
    4.2 Detected: 3, Tracking: 2, Unmatched: 1
    4.3 Detected: 3, Tracking: 1, Unmatched: 2
    4.4 Detected: 3, Tracking: 0, Unmatched: 3
    5.1.2 조건2: 인덱스 매핑 테이블에 접근하여 매핑 기록 확인
    5.1 Detected: 4, Tracking: 4, Unmatched: 0
    6.1 Detected: >=5, Tracking: 4, Unmatched: >=1

    그림1: 조건2에 대한 코드(CoreTech.py Line 282)

5.1.3 조건3: 매칭되지 않은 객체가 하나일 시1:1 매칭
5.2 Detected: 4, Tracking: 3, Unmatched: 1

그림2. 조건3에 대한 코드(CoreTech.py Line 309)   

5.1.4 조건4: 두명 이상 매칭되어있지않으면 유클리드 거리 비교로 매칭
5.3 Detected: 4, Tracking: 2, Unmatched: 2
5.4 Detected: 4, Tracking: 1, Unmatched: 3
5.5 Detected: 4, Tracking: 0, Unmatched: 4
5.1.5 조건5: 세명이 매칭되었지만 매칭되지 않은 인식 객체가 두개 이상이면 유클리드 거리 비교로 매칭
6.2 Detected: >=5, Tracking: 3, Unmatched: >=2
 

그림3: 조건4, 5에 대한 코드(CoreTech.py Line 338)    

그림4: Euclidean Distance code (CoreTech.py Line 87)   

6. 성능 평가
   6.1 평가지표의 필요성
   추가적인 알고리즘을 적용함에 따라 프로젝트 목표의 성능을 측정할 필요성을 느꼈지만추적에 대한 보편적인 평가지표를 찾기 어려웠고, 특히 다중 실시간 추적에 대한 평가지표가 없음.따라서 본 프로젝트의 성장에 대한 평가를 위한 평가지표를 자체 설정
   6.2 평가 방식
   인식에 대한 개선은 프로젝트의 방향성에서 제외했기 때문에 추적 기준을 인식 객체 수로 잡고, 인식 객체를 얼마나 성공적으로 추적했는지 측정

   그림5: 평가지표 TPD(Tracking object per Detection object)

   그림6: TPDevaluate code (TPD_evaluate.py)

6.3 평가 함수화
평가지표 측정을 위한 자동화 코드를 작업했으나, 서로 다른 객체간의 인덱스 교환현상이 고질적인 문제로 자리잡아 인식된 인덱스 만으로는 측정이 불가하고 객관적이지 못하다 판단해 미적용. 평가지표 측정을 위해서 프레임별 체크가 별도로 필요
6.4평가 비교군 선정
DeepSort Original과 알고리즘 적용간에 생긴 중간단계를 비교군으로 두어 최종 결과물에 대한 성능을 측정
최대 점수가 1.0인 측정지표에서 영상에 따라 다르지만 테스팅 영상에 대해 DeepSort Original은 0.81가량, 중간단계에서 0.93, 점점 상승하여 최종 결과물에서 1.0에 가까운 점수 획득

 
7. 기능 개선
7.1 기능 개선의 필요성
지속적인 알고리즘 추가&수정을 통해 성능은 많이 개선되었지만 프로젝트 목적 자체에 카메라 앵글이나 예상치 못한 에러발생 등의 제한적인 사항에 대해 해결할 방안을 마련할 필요성 확인
7.2 Tracking On/Off/Reset 기능 추가
최종 적용단계에서의 상황을 고려하면 실제 메인 카메라에서 인물 추적 정보를 신호의 형태로 전달하는 형태임.때문에 프로그램에 추적 기능의 적용에 대한 사용자의 제어의 필요성을 느낌.또한, 프로그램 테스팅 과정에서 동영상에 대한 추적 처리의 유동적 확인을 위해서는 인덱싱 에러가 발생하더라도 인덱스 상황을 초기화가 가능한 기능 추가
7.3 Capture Video의 프레임 사이즈 제한 기능 추가
탑 뷰의 카메라 배치의 가능성이 생겼지만, 영상 테스트 결과 같은 화질 대비 탑뷰에서 사람 인식성능이 좋지 못함을 확인함.때문에 지표면 기준 40~70도 정도의 위치에 카메라 배치가 적당하다고 판단함.하지만 카메라 배치의 각도가 낮아질 수록 관객석이 찍히는 등 프레임 안에 기준인원 이상의 객체가 인식될 가능성에 대해 고려함. 이를 위해 캡쳐 이미지 자체를 UI상에서 제한할 수 있는 기능을 추가
7.3.1 프레임 사이즈 제한의 효과
실제로 평가 영상에서 불필요한 인물이 등장하는 장면에 제한을 두어 성능이 향상하는효과를 확인했음.

그림7: Tracking On/Off/Reset 기능과 Capture Video의 프레임 사이즈 제한 기능   

 
8. 처리되지 못한 제한사항들
8.1 인덱스 교환 현상에 대한 이유를 발견하지 못함.
8.2 탑뷰에서의 인물 인식이 잘 안되거나 화질이 너무 낮으면 안되는 카메라 앵글과 프레임에 대한 제한이 있음.
8.2.1 YOLO 자체의 인식에서 인물의 정수리와 어깨만을 보고는 인식 성능 낮음.
8.2.2 YOLO 모델에 적절한 인물 사진을 전이 학습한다면 탑 뷰에 대한 가능성도 있다고 판단
8.3 4명의 공연자만을 대상으로 한 프로그램이기 때문에 그 이하나 이상의 인원에 대해서는 인덱싱 에러가 발생할 수 있음
8.3.1 코드커스터마이징을 통해 인식 인원을 늘리거나 줄이는 것에 자유로움
8.4 간헐적 인덱스 교환 에러 발생
8.4.1 Deep Sort 자체의 에러이지만 해당 에러에 대하여 원인을 색출하지 못하여 개선필요