응용확률및랜덤프로세스

정규화가 total += hists[i] * hists[i] 후 sqrt, 즉 L2 노름이다. 이렇게 나누면 Σp_i = 1이 성립하지 않으므로 결과는 확률질량함수가 아니라 단위벡터다. 이어서 유사도는 hists[i] * nHists[i]의 합, 곧 두 단위벡터의 내적(코사인 유사도)이다.

강의자료가 다루는 Bhattacharyya 계수는 ρ(p,q) = Σ√(p_iq_i)이고, 이 값이 [0,1]에 갇히고 √(1−ρ)가 거리가 되는 근거는 p와 q가 확률분포라는 데서 나온다. 제곱근을 빼고 L1 정규화를 L2로 바꾸면 그 근거가 둘 다 사라진다. 남는 것은 추적에 쓸 수는 있지만 확률론적 해석이 없는 벡터 내적이다.

결정적인 대조는 같은 레포 안에 있다. example/open.c는 정석 형태를 그대로 갖고 있다.

더불어 커널 프로파일이 없다. 코드 전체에 Epanechnikov도 Gaussian도, 중심에서 멀어질수록 가중치를 줄이는 어떤 공간 가중도 존재하지 않는다. Comaniciu & Meer의 mean shift 벡터가 커널 미분에서 유도된다는 점을 생각하면, 이것은 구현 세부의 누락이 아니라 방법의 토대가 빠진 것이다.

후보 윈도를 만드는 :52는 Rect(x, y, w, h)의 첫 두 인자, 즉 좌상단 자리에 temp.x + temp.width/2를 넣는다. 그런데 이 값은 계산해 보면 nRect.x + nRect.width/2, 곧 객체의 중심이다. 따라서 nX는 "좌상단 좌표들의 가중평균"이 된다.

루프를 닫는 :71은 그 nX를 중심으로 보고 nX - width/2를 한다. 반면 루프 직후 박스 크기를 고르는 :79는 같은 nX를 좌상단으로 보고 그대로 쓴다. 둘 중 하나만 맞을 수 있다.

결과를 확인하려고 :42–91의 산술을 그대로 Python으로 옮겨 합성 프레임(320×240, 객체 (100,80,60,50))에서 돌렸다. 정지 화면에 정답 위치로 초기화했으므로 올바른 추적기라면 영원히 (100,80)에 머물러야 한다.

두 가지가 드러난다. 첫째, mean shift 루프 자체는 정확히 박스 절반만큼 어긋난 (70,54)에 수렴한다 — (100,80)에서 (30,25)를 뺀 값이다. 둘째, 화면에 그려지는 박스가 그래도 객체 위에 있는 이유는 :83의 nRect = temp;가 루프 결과를 덮어쓰기 때문이다. 즉 실제 위치 결정은 mean shift가 아니라 "박스 크기 자동조정" 단계가 하고 있고, mean shift 루프의 출력은 다음 반복의 탐색 중심으로만 쓰이다 폐기된다. 헤더가 자랑하는 부가기능(cv_tracker.h:7 "tracking object autosizing")이 본 알고리즘을 대체해 버린 셈이다.

부수 효과도 측정된다. 완전한 정지 화면인데도 박스가 x로 6px 밀리고 폭이 60에서 45–55 사이로 줄었다 늘었다 한다. 탐색창이 절반 어긋난 위치를 기준으로 잡히기 때문이다.

TrackerParam::max_itrs = 32(cv_tracker.h:56)은 정의돼 있지만, 코드 전체에서 이 값을 읽는 곳은 :331과 :339, 즉 OpenCV TermCriteria뿐이다. 자작 루프에는 반복 상한이 없다.

대신 종료 조건은 이동거리가 param.search_range 이하가 되는 것인데, 그 search_range를 루프 안에서 :69가 매 반복 줄인다. 새 계수는 twRatio > 0.25이면 1 - twRatio(최대 0.75), 아니면 0.75 + twRatio(최대 1.0)이다. 어느 쪽이든 1을 넘지 못하므로 탐색 반경은 단조 감소한다. 매 반복 임계값이 좁아지는 종료 조건이라 수렴 보장이 없다.

하한 SEARCH_MIN = 4는 :91, 즉 루프를 빠져나온 뒤에만 적용된다. 루프 안에서는 반경이 0에 임의로 가까워질 수 있다. 위 시뮬레이션에서 search_range는 1프레임 만에 하한 4.0에 붙어 그 뒤로 움직이지 않았고, 이는 헤더가 내건 "dynamic search range"(cv_tracker.h:6)가 사실상 무력화되었다는 뜻이다.

더 나쁜 잠재 위험이 :48에 있다. temp.width / param.sampling은 양쪽이 int이므로 정수 나눗셈이고, temp.width < 8이면 보폭이 0이 된다. 그러면 :49의 i += sRatioWidth가 영원히 전진하지 않는다. main.cc:97의 ROI 가드가 넓이만 보므로 4×30 같은 가늘고 긴 박스(넓이 120)면 이 경로에 들어갈 수 있다.

myHistogram은 호출될 때마다 calloc으로 새 배열을 할당해 반환한다. 이것을 매 후보 윈도마다 호출하는 것이 mySimilarity다. grep으로 확인한 결과 cv_tracker.cc와 main.cc를 통틀어 free() 호출은 0건이고, 유일한 delete는 main.cc:67에 주석 처리되어 있다.

프레임당 호출 횟수는 탐색 격자(:49–63, 약 50–80회) × 반복 횟수(측정값 3–6회)에 크기 탐색(:76–85, 약 25회)과 :99의 모델 갱신을 더한 값이다. 시뮬레이션에서 관측된 반복 수 기준으로 프레임당 200–500회, 회당 128바이트이면 프레임당 25–60KB가 새고 재생 시간에 비례해 선형으로 증가한다. 240프레임짜리 데모 하나가 수 MB 규모다.

initilize의 this->objectHists(:23)도 소멸자 Tracker::~Tracker(void) {}(:8)가 비어 있어 해제되지 않는다.

폭을 hsv.rows(세로 픽셀 수)로, 높이를 hsv.cols(가로 픽셀 수)로 자른다. 가로 영상에 작은 박스라면 클램프가 애초에 걸리지 않아 드러나지 않지만, 세로 영상이나 큰 ROI에서는 틀린 경계가 된다. 같은 실수가 example/open.c:97, :110에도 있다.

myHistogram은 256 / hist_bins로 나눠 bin을 정하는데(:152, :157), myHistogramValue는 hist_bins로 나눈다(:201). 두 값이 같아지는 경우는 hist_bins = 16뿐이고, 기본값이 정확히 16이라 지금은 동작한다. 파라미터를 바꾸는 순간 배열 밖을 읽는다.

덧붙여 matrixAt의 경계 검사 x > img.size().width(:191)는 >=여야 한다. 폭과 같은 좌표가 통과해 한 픽셀 너머를 읽는다.

:97의 if (param.search_range == SEARCH_MIN)은 "충분히 수렴했을 때만 모델을 갱신한다"는 의도의 가드다. 그런데 앞서 본 대로 :69의 계수가 1을 넘지 못해 탐색 반경은 첫 프레임에 하한 4.0에 도달한 뒤 계속 그 값이다(시뮬레이션 확인). 결과적으로 조건은 매 프레임 참이 되고, 모델은 현재 박스가 덮은 영역으로 무조건 0.05씩 끌려간다. 추적이 빗나가도 이를 막을 유사도 임계값은 없다. 전형적인 model drift 구조다.

OpenCV의 meanShift(InputArray, Rect& window, TermCriteria)는 두 번째 인자를 참조로 받아 갱신하는 것이 전부인 API다. 그런데 Tracker::cvMeanShift는 Rect를 값으로 선언했다. 갱신은 지역 복사본에서 끝나고 호출자의 cvRect는 initilize(:28)에서 설정된 최초 ROI에 영원히 고정된다.

즉 베이스라인은 매 프레임 같은 자리에서 다시 출발해 근처 모드로 수렴할 뿐, 상태를 이어받지 않는다. 추적이 아니라 매 프레임 독립 재검출이고, 목표가 최초 박스를 벗어나면 따라가지 못한다.

이 결함은 레포에 커밋된 증거로 직접 확인된다. README.md:12가 자랑스럽게 링크한 TESTED/tested.gif(726×442, 240프레임)에서 40번째와 90번째 프레임을 뽑아 보면, 초록 박스(:116, 자작)는 대상 물체를 따라 화면 중앙을 가로질러 이동하는데 빨간 박스(:332, OpenCV)는 왼쪽 하단 같은 자리에 머문 채 미세하게 떨기만 한다. 저자가 성공 데모라고 올린 파일이 베이스라인이 죽어 있다는 증거가 되어 있다.

프로젝트 전체에서 "대상을 잃었을 때"를 처리하는 코드는 cvCamShift 끝의 :343–347뿐이다. 박스가 1픽셀 이하로 쪼그라들면 탐색창을 다시 넓히는, 전형적인 CamShift 복구 패턴이다. 그런데 두 겹으로 죽어 있다.

첫째, 이 분기에 들어갈 방법이 없다. cvMeanshift는 cv_tracker.h:82에서 true로 하드코딩된 protected 멤버이고 setter도, 이를 바꾸는 UI도, 명령행 옵션도 없다. :126의 분기는 항상 meanShift 쪽으로만 간다. 둘째, 설령 들어가도 rc가 값 복사본이라 재조정 결과가 함수 밖으로 나가지 못한다.

자작 경로에도 실패 감지가 없다. mySimilarity의 최대값을 무조건 받아들일 뿐, "이 정도로 안 닮았으면 놓친 것"이라는 임계값이 없다. 앞서 본 무조건 모델 갱신과 합쳐지면 한 번 빗나갔을 때 되돌아올 경로가 존재하지 않는다.

ROI는 x - sPoint.x, y - sPoint.y로 만들어지므로 오른쪽 아래→왼쪽 위로 끌면 width와 height가 둘 다 음수가 된다. 그리고 유효성 검사가 rect.area() > 100이다. 음수 × 음수는 양수이므로 (200,200)→(100,100) 드래그는 넓이 10000으로 가드를 통과한다.

그대로 tracker.initilize로 들어가면 cv_tracker.cc:264의 Mat target(hsv, rc);가 음수 크기 ROI에 대해 cv::Exception을 던진다. try/catch가 없으므로 프로그램이 종료된다. 사용자가 박스를 반대 방향으로 그렸다는 것이 유일한 조건이다.

main.cc:60이 HSV / RGB / hue / gray 네 가지를 물어보지만, 자작 경로는 initilize(cv_tracker.cc:18)와 run(:39) 모두 무조건 CV_BGR2HSV로 변환하고, matrixAt(:195)은 channel_ratio {0.5, 0.25, 0.25}(cv_tracker.h:48)로 세 채널을 고정 비율 합산한다. 선택은 OpenCV 경로의 switch에만 닿는다. 사용자에게 네 개의 선택지를 주면서 실제로는 하나만 구현된 셈이다.

입력 검증도 없다. cin >> model 뒤 static_cast<COLOR_MODEL>(model - 1)(:65)에 5를 넣으면 범위 밖 enum이 되어 cvHistogram의 switch가 아무 case도 타지 않고, model3d가 빈 채로 calcBackProject에 들어간다. 숫자가 아닌 입력이면 model이 0이 되어 -1이 된다.

main.cc:120의 *vc >> frame; 직후 imshow를 호출하는데 frame.empty() 검사가 없다. 파일은 열리지만 첫 프레임 디코딩에 실패하는 경우(코덱 불일치 등) 그대로 예외다. 루프 안의 두 번째 읽기에는 :139에 검사가 있으므로 영상 종료 처리 자체는 되어 있다.

new VideoCapture(:50)에 대응하는 delete는 :66–67에 주석으로 남아 있다. 프로세스 종료로 회수되긴 하지만, 지웠다가 문제가 생겨 되돌린 흔적으로 읽힌다. cv_tracker.cc:94의 bRect = myRect = nRect;에서 bRect로의 대입도 지역 변수의 마지막 쓰기라 죽은 코드다.

슬라이드 13의 문구는 "Mean shift clustering of pixels with back projected weights"다. 이것이 강의자료가 가르치는 정석이다 — 각 픽셀에 역투영 값을 가중치로 주고, 그 가중치로 중심을 옮긴다.

실제 cv_tracker.cc:49–63은 다르다. 성긴 격자 위의 후보 윈도들을 순회하며, 각 윈도 전체의 히스토그램을 새로 계산해 모델과의 유사도를 구하고, 그 값을 가중치로 윈도 좌표들의 가중평균을 낸다. 픽셀 단위 가중이 아니라 윈도 단위 가중이고, 커널 가중 밀도의 모드를 오르는 것이 아니라 샘플링된 후보 집합의 가중 중심을 구하는 것이다. 동작은 비슷해 보일 수 있으나 mean shift의 수렴 보장(밀도 상승 방향으로의 이동)이 성립하는 구조가 아니다.

:106–112에 진짜 픽셀 단위 역투영이 있기는 하다. 다만 그것은 MY_histogram 창에 보여주기만 할 뿐, 위치 갱신에 쓰이지 않는다.

example/tracker_opencv/code/tracker_opencv.h는 "Written by darkpgmr (http://darkpgmr.tistory.com), 2013"이라고 명시된 제3자 코드다. 그리고 cv_tracker.h의 OpenCV 경로 설계는 이 헤더와 상당히 겹친다 — init/run 형태의 공개 API, hist_bins·max_itrs·color_model을 담은 파라미터 구조체, CM_GRAY/CM_HUE/CM_RGB/CM_HSV enum, m_model/m_model3d에 대응하는 model/model3d 보호 멤버까지.

참고 자료를 레포에 함께 남긴 것 자체는 오히려 투명한 행동이다. 다만 cv_tracker.h:3–8과 main.cc:1–6의 파일 헤더는 저자 본인의 GitHub 주소만 적고 있고, 발표자료 References 장에도 OpenCV 공식 문서와 강의자료만 있을 뿐 이 출처는 없다. 파생한 쪽에 한 줄 표기를 남기는 것이 맞다.

README.md는 13줄이고 그중 실질 내용은 "using OpenCV to test image processing[object tracking]" 한 줄과 데모 GIF 링크뿐이다. 빌드 방법, OpenCV 버전, 필요한 Visual Studio 구성, 조작법(마우스로 ROI를 끌고 ESC로 종료), 알고리즘 요약이 전부 없다. 정작 그 정보의 일부는 소스 파일 상단 주석(cv_tracker.h:10–18)에만 들어 있다. 문서가 코드보다 앞서가지 않는 대신, 아예 따라오지 않은 경우다.

작업 트리 699MB, .git 160MB다. 원인은 TESTED/의 미디어가 아니다 — 그쪽은 mp4 두 개 약 11MB와 gif 4MB로 전체의 2%에 불과하다. 압도적인 주범은 OpenCV 3.0 SDK 전체를 x86/x64 × vc11/vc12 네 조합으로 통째 커밋한 것이다.

덧붙일 점 셋. 첫째, 실제로 빌드에 쓰인 구성은 Debug|Win32 하나(imageProcessing.vcxproj:92,97, opencv_world300d.lib)이므로 나머지 세 조합의 라이브러리는 한 번도 쓰이지 않았다. 둘째, example/.gitignore가 VTD_data_videos/, tracker_opencv/ 등을 나열하지만 그 파일들은 이미 커밋된 뒤라(901de66, 295122a) 아무 효과가 없다. 셋째, 당시 Visual Studio 프로젝트에서 SDK를 동봉하는 것이 드문 관행은 아니었으나, 그렇다고 60MB짜리 샘플 영상 animal.avi까지 함께 넣을 이유는 없었다.

find로 확인한 결과 레포 전체에 LICENSE, COPYING, NOTICE 류 파일이 하나도 없다. OpenCV는 3-clause BSD이고, 그 조항은 바이너리 형태로 재배포할 때 저작권 고지와 조건문을 동봉할 것을 요구한다. 지금 레포에서 BSD 전문이 존재하는 곳은 벤더링된 헤더 파일 내부 주석뿐이며(include/opencv/cv.h 등), lib/ 아래 DLL·LIB 8쌍에 대응하는 고지는 없다. 저자 자신의 코드에 대한 라이선스도 명시되지 않아 재사용 조건이 불분명하다.

macOS에서는 빌드가 불가능하며 그 사실은 명확히 기록해 둔다 — main.cc:20이 <Windows.h>를 포함하고, 파일 선택 대화상자가 OPENFILENAME과 ::GetOpenFileName(main.cc:165–180)으로 구현되어 있으며, cv_tracker.h:23–26의 include 경로가 역슬래시("opencv2\core\core.hpp")다. C++ 표준에서 역슬래시가 든 헤더명은 구현 정의 동작이고 POSIX 툴체인에서는 그대로 깨진다. 프로젝트도 PlatformToolset v140, WindowsTargetPlatformVersion 8.1에 묶여 있다. 따라서 아래 모든 판정은 빌드가 아니라 정독과 산술 포팅 시뮬레이션에 근거한다.

그와 별개로 Debug|x64 구성은 Windows에서도 빌드되지 않았을 것이다. include 경로가 드라이브 루트 기준 \include이고 라이브러리 경로가 \lib\x86\vc12\lib, 즉 x64 구성이 x86 라이브러리를 루트 절대경로로 가리킨다. 다른 세 구성이 쓰는 프로젝트 상대경로 .\include와 대조된다.