Prophesee의 객체 계수 예제는 검출선마다 누적 개수를 저장하고, 그중 가장 큰 값을 전체 계수로 사용합니다. 선별 개수를 더하면 같은 입자가 여러 선을 통과한 횟수까지 합쳐집니다. 입력 단계에서는 한 극성의 이벤트만 선택해 한 물체의 밝아지는 경계와 어두워지는 경계가 중복 검출되는 문제를 줄입니다. 이 두 처리는 각각 다른 종류의 중복을 다룹니다.
여기서 설명하는 대상은 2026년 10월 15일 확인한 Metavision SDK 5.3.1의 Object Counting C++ 예제입니다. 위에서 아래로 지나가는 작은 물체를 수평선에서 세는 구성입니다. 이벤트 자체가 낯설다면 이벤트 카메라와 프레임 카메라의 측정 방식을 먼저 보면 극성의 의미를 이해하기 쉽습니다.
입자 하나가 세 줄을 지나가도 물체는 하나다
가상의 입자 하나가 위·가운데·아래 검출선을 차례로 통과한다고 해봅시다. 각 선이 통과를 정확히 한 번 검출한다는 설명용 가정입니다. 초기값이 모두 0일 때 누적 계수는 다음처럼 달라집니다.
| 입자의 위치 | 위 선 | 가운데 선 | 아래 선 | 선별 값의 합 | 예제의 전체 계수 |
|---|---|---|---|---|---|
| 위 선을 지난 직후 | 1 | 0 | 0 | 1 | 1 |
| 가운데 선을 지난 직후 | 1 | 1 | 0 | 2 | 1 |
| 아래 선을 지난 직후 | 1 | 1 | 1 | 3 | 1 |
각 열은 서로 다른 물체 집합이 아니라 같은 흐름을 다른 위치에서 관찰한 기록입니다. 따라서 합계 3을 입자 3개로 읽으면 안 됩니다. 공식 예제의 MonoCountingStatus는 선마다 local counter를 갖고, global counter를 이 값들의 최댓값으로 정의합니다. 기본 설정은 수평선 4개이며 선의 수와 위치는 실행 옵션으로 바꿀 수 있습니다.
여러 입자가 흐르는 중에 선별 값이 [10, 9, 8]이라면 전체 값은 10입니다. 아래 선에 아직 도달하지 않은 입자가 있는 장면으로 이해할 수 있습니다. 다만 이 숫자만으로 차이가 모두 이동 지연 때문이라고 단정할 수는 없습니다. 특정 선에서 검출이 빠져도 차이가 생깁니다. 선별 값을 함께 보면 차이가 잠시 후 줄어드는지, 특정 위치에서 계속 남는지를 구분할 수 있습니다.
최댓값 연산 자체에는 물체 식별자를 비교하는 단계가 없습니다. 한 선이 같은 입자를 잘못 두 번 세었다면 그 큰 값도 전체 값에 반영됩니다. 여러 선을 쓴다는 이유만으로 앞단의 오검출이 제거되는 것은 아니므로, 이상한 총계가 보이면 합산식보다 먼저 어느 선의 값이 증가했는지 살펴보는 편이 낫습니다.
밝기 변화의 두 경계를 두 입자로 읽지 않으려면
밝은 배경 앞을 어두운 입자가 지나가는 장면을 생각해봅시다. 고정된 한 픽셀에서는 입자가 들어올 때 어두워지고, 빠져나간 뒤에는 다시 밝아집니다. 두 변화는 반대 극성의 이벤트를 만들 수 있습니다. 물체의 이동을 보여 주는 신호가 둘이라는 뜻이지, 물체가 둘이라는 뜻은 아닙니다.
공식 예제는 선택적 전처리로 PolarityFilterAlgorithm을 제시합니다. 한 극성만 통과시켜 모양을 더 선명하게 만들고 같은 물체의 여러 번 계수를 줄이는 방식입니다. 검출선들의 최댓값은 서로 다른 선 사이의 집계 규칙이고, 극성 필터는 한 선에 들어가기 전 이벤트의 형태를 다듬습니다. 둘 중 하나로 다른 하나를 대체할 수는 없습니다.
극성을 하나만 남겨도 물체에 구멍이 있거나 이벤트가 여러 덩어리로 끊어지면 별개 검출로 나뉠 여지가 있습니다. 예제가 물체에서 발생한 이벤트를 가능한 한 모이게 하고, 구멍 때문에 여러 번 검출되지 않도록 요구하는 이유입니다. ActivityNoiseFilterAlgorithm은 잡음에 의한 거짓 계수를 줄이는 별도 전처리입니다. 먼저 어떤 이벤트 모양이 한 물체로 들어오는지 확인해야 필터를 선택할 근거가 생깁니다.
초점과 이동 방향이 계수 알고리즘의 입력을 바꾼다
CountingAlgorithm은 위에서 아래로 움직이는 물체를 전제로 합니다. 다른 방향으로 설치한 경우 문서는 이벤트 방향을 바꾸는 TransposeEventsAlgorithm을 선택지로 안내합니다. 이 샘플을 곧바로 양방향 왕복 통행의 순개수 측정기로 읽기 어려운 이유도 여기에 있습니다. 먼저 변환 뒤의 이동 방향이 예제가 요구하는 방향과 맞는지 보아야 합니다.
물리적 크기가 같은 입자도 렌즈와 거리 때문에 영상에서 차지하는 픽셀 수가 달라집니다. 공식 설정 안내는 고정된 카메라, 맞는 초점, 배경과의 충분한 대비를 요구하고, 입자가 영상에서 적어도 5픽셀 크기로 보이도록 광학계와 거리를 고르기를 권합니다. 이 5픽셀은 해당 샘플의 설정 권고입니다. 입자의 최소 크기를 밀리미터 하나로 바꾸려면 사용한 렌즈와 작업 거리가 먼저 정해져야 합니다.
문서에 실린 코드는 CountingCalibration::calibrate에 센서 가로·세로 크기, 물체의 최소 크기, 평균 속도, 카메라와의 거리를 넘깁니다. 반환된 cluster_ths와 accumulation_time_us가 계수 알고리즘 생성에 사용됩니다. 밝기 변화가 어느 범위에 얼마나 모이는지를 다루므로, 초점이 흐리거나 입력한 속도·크기가 실제 장면과 다르면 같은 입자의 이벤트를 묶는 조건부터 어긋날 수 있습니다. 조명 깜박임을 줄이고 고속 물체에 맞게 센서 bias를 조정하라는 안내도 이 입력 품질과 연결됩니다.
화면이 새로 그려질 때마다 총계를 더하면 안 된다
이 카운터는 처리 함수를 호출할 때마다 0으로 돌아가지 않고 시퀀스 동안 누적됩니다. 결과도 입력 이벤트 버퍼마다 하나씩 나오는 방식이 아니라, 정해진 갱신 주기에 맞춰 비동기로 전달됩니다. 표시용 영상은 그 결과 콜백에서 만들어지므로 화면의 새로고침 횟수와 새 입자 수는 별개입니다.
예를 들어 같은 계수 실행 안에서 전체 값이 10에서 14로 바뀌었다면, 두 관찰 시점 사이의 증가량은 4입니다. 두 화면의 값을 더한 24가 아닙니다. 이 역시 설명용 계산이며, 중간에 카운터를 초기화하거나 다른 기록 파일로 바꿨다면 두 값은 같은 누적 구간으로 묶을 수 없습니다.
실제 처리량 기록을 만들 때는 표시된 총계와 시각, 선별 누적 값, 계수 구간의 시작을 함께 남기는 방식이 유용합니다. 총계가 갑자기 튄 경우 특정 선의 오검출인지, 입력 조건 변경인지 돌아볼 수 있기 때문입니다. 이 글은 공식 문서와 공개된 코드 조각을 읽어 해석했으며, 카메라 계수 샘플을 직접 실행하거나 정확도를 측정하지 않았습니다.