WPF MIL 프로젝트에서 MIL Image Acquisition (이미지 획득: Digitizer & DCF) 방법에 대해 MIL 영상 처리 라이브러리에서 다루는 내용을 이번 포스팅에서 정리하도록 하겠습니다. 이전 포스팅에서는 MIL 라이브러리의 Architecture 에 대해 나름 자세하게 정리했었습니다. Application Context 아래에 최상위 객체인 System 객체를 생성하고, System 에서 필요에 의해 사용하게 되는 각각의 객체 (Digitizer, Buffer, Display, Graphics Context, …) 등을 생성 하는 구조와 Image Processing (이미지 처리) 이후 생성된 객체에 대해 해제하는 순서를 자세하게 다뤘죠. 기억이 안난다면 이전 포스팅(#2)을 다시 한번 읽어 보길 권장합니다. 그리고 MIL 라이브러리에서 사용하는 API 함수들의 명명법에 대해서도 언급했었습니다. 이번 포스팅에서는 System 객체 아래에 속한 Digitiger 를 통해 Image Acquisition 에 대해 자세하게 정리해 보겠습니다.
MIL 영상 처리 라이브러리는 Digitizer 와 DCF 를 제공해서 효율적이고 안정적인 이미지 수집 시스템을 구축할 수 있도록 지원합니다. 이전 포스팅(#2)에서 Digitiger 에 대해 짧게 정리했었는데요. 이제 조금 깊게 정리해 보도록 하죠.
Image Acquisition : Digitizer & DCF
영상 처리 시스템에서 안정적인 Image Acqusition (이미지 획득) 은 모든 비전 시스템에서 기본적으로 선행되어야 하죠. 안정적인 시스템을 구축하기 위해서는 소프트웨어 라이브러리가 하드웨어를 제어하는 핵심 메커니즘을 정확히 이해하는 것이 필수적입니다. MIL 라이브러리의 이미지 획득을 위해 이전 포스팅에서 아키텍처에서 짧게 나마 다룬 Digitizer (디지타이저)와 처음 언급한 DCF (Digitizer Configuration Format)의 역할과 기능을 조금 심층적으로 분석하여, 영상 처리 시스템 을 어떻게 설계해야 하는지 차근차근 알아보죠.영상 처리 개발자라면 잘 알만한 용어인데요. 아래 그림을 참고해서 한번 정리하고 가도록 하죠.
| Term | Description |
| Image Board (Frame Grabber) | 카메라 또는 기타 이미징 장치로부터 비디오 데이터를 수집하고 조작할 수 있는 모든 하드웨어 보드를 지칭합니다. |
| Camera | 이미지 및 비디오 데이터를 생성하는 모든 장치를 의미하며, 프레임 그레버 또는 적절한 이미지 획득 장치에 연결하여 사용. |
| Acqusition Path (획득 경로) | 프레임 그레버 상에서 입력되는 비디오 신호를 디지털화 하고 캡처하는 경로이며, 독립적인 획득 경로의 수는 비디오 스트림 획득에 필요한 동기화 신호의 수에 따라 결정됨. 각각의 획득 경로는 digitiger 의 수를 결정하는 기반이 됨. |
Digitizer’s Role (디지타이저의 역활)
Digitizer (디지타이저)는 특정 유형의 카메라로부터 이미지를 가져오기(Grab) 위해 사용되는 하나 또는 그 이상의 수집 경로(Acquisition paths) 집합을 의미합니다. Frame grabber (프레임 그래버) 내의 수집 경로는 비디오 입력 신호를 디지털화하고 캡처하는 역할을 하며, 독립적인 동기화 신호를 수신할 수 있는 수집 경로의 수에 따라 프레임 그래버가 가질 수 있는 디지타이저의 수가 결정됩니다.
앞서도 언급했지만, Digitizer 는 물리적인 하드웨어를 추상화하는 논리적 단위 인데, 하나 또는 여러 수집 경로의 집합이라고 한것이 무슨 말이냐 하면, 특정 유형의 카메라로부터 이미지를 수집하는 데 사용되는 논리적 단위라는 것이며, 디지타이저의 핵심 기능은 카메라와 수집 하드웨어에 대한 설정을 자동으로 적용하여 사용자가 복잡한 하드웨어 레벨의 제어를 신경 쓰지 않도록 하는 것입니다.
특히 주목해야 하는 기능은 채널 스위칭(Channel Switching)인데요. 예를 들어, Frame grabber (프레임 그래버)가 물리적으로 4대의 카메라에 연결되어 있지만 독립적인 수집 경로는 2개 뿐인 상황을 가정해 보겠습니다. 채널 스위칭 기능을 사용하면 각 수집 경로에 대해 원하는 카메라를 동적으로 선택하여 한 번에 두 대의 카메라로부터 이미지를 수집할 수 있습니다. 이는 제한된 하드웨어 리소스를 효율적으로 활용하여 다중 카메라 시스템을 유연하게 구성할 수 있도록 지원합니다. 아래의 이미지를 참고해 주세요.
DCF(Digitizer Configuration Format)
DCF는 카메라와 수집 하드웨어 설정을 정의하는 텍스트 파일입니다. 애플리케이션에서 특정 Digitizer (디지타이저)를 할당하면, MIL 영상 처리 라이브러리는 해당 DCF 파일에 정의된 설정 값들을 자동으로 하드웨어에 적용합니다. 이 프로세스는 복잡한 설정 과정을 단순화하고, 여러 시스템에 걸쳐 동일한 구성을 일관되게 배포할 수 있도록 보장합니다. 이를 통해 가뜩이나 신경쓸게 많은 개발자는 설정 오류의 위험을 줄이고 애플리케이션 로직 개발에 집중할 수 있게 되는 거죠.
MIL 영상 처리 라이브러리는 자체 프레임 그래버 제품군 외에도 업계 표준인 GigE Vision 및 USB3 Vision 인터페이스를 사용하는 하드웨어도 완벽하게 지원하여 높은 호환성을 제공한다고 합니다.
요약 해보면, Digitiger와 DCF는 이미지 수집 하드웨어를 추상화 해서 일관된 방식으로 제어하기 위한 강력한 기반을 MIL 영상 처리 라이브러리가 제공한다는 것이 요지입니다. 그러면 이것들을 이용해서 어떻게 실제 이미지 데이터를 시스템 메모리로 Grab 해서 가져오는지 알아보도록 하겠습니다.
Basic Image Grab Mode : Monoshot & Continous
Image Acqusition 의 가장 기본적인 두 가지 방식은 단일 프레임을 캡처하는 Monoshot (MdigGrab)과 연속적으로 프레임을 캡처하는 Continuous (MdigGrabContinuous) 을 MIL 영상 처리 라이브러리에서 제공합니다. 이 두 가지 Grab (그랩) 방식의 작동 원리와 특징을 이해하는 것은 더 복잡하고 효율적인 Image Acqusition 을 하기 위해 반드시 알고 넘어가야 하는데, 이 내용을 하나씩 정리해 보죠.
Condition : Image Grab
Image Grab (이미지 그랩)은 데이터의 무결성과 연속성이 보장되어야 하는 실시간 작업입니다. 실시간 작업을 위해 MIL 라이브러리는 일부 Digitiger (디지타이저) 유형에 대해 PC RAM 내에 특별한 메모리 공간을 요구합니다. 이 공간을 Non-paged memory (비-페이지 메모리)라고 하며, 운영 체제(OS)가 임의로 접근하거나 swap (스왑)할 수 없도록 예약된 전용 RAM 영역입니다. 이 메모리는 Grab (그랩) 작업 중 데이터 손실을 방지하는 중요한 역할을 합니다.
단, GigE Vision 및 USB3 Vision과 같은 특정 디지타이저 유형에서는 이러한 비-페이지 메모리 할당이 필요하지 않지만, 사용하려는 하드웨어의 메모리 요구 사항을 반드시 확인해야 한다는 점 알아두세요.
MonoShot Grab (MdigGrab)
MIL 영상 처리 라이브러리에서 제공하는 MdigGrab() 함수의 핵심 기능은 단일 프레임 또는 필드를 캡처하여 지정된 이미지 버퍼에 저장하는 동작입니다. 이 기능은 두 가지 모드로 작동할 수 있는데요.
• 동기(Synchronous) 모드: 함수 호출 시, Image Grab (이미지 그랩)이 완전히 완료될 때까지 애플리케이션의 실행이 차단(blocking)됩니다. 즉, 시스템은 그랩이 끝날 때까지 대기 상태에 들어갑니다.
• 비동기(Asynchronous) 모드: 함수 호출 즉시 제어권이 애플리케이션으로 반환 되어, Image Grab (이미지 그랩)이 진행되는 동안에도 다른 작업을 동시에 수행할 수 있습니다. 이 방식은 시스템 리소스를 효율적으로 사용하고 전체 처리 시간을 단축할 수 있어 대부분의 애플리케이션에서 이 모드를 사용하고 있죠.
Continuous Grab (MdigGrabContinuous)
MIL 영상 처리 라이브러리에서 제공하는 MdigGrabContinuous() 함수의 핵심 기능은 정지 명령이 내려질 때까지 카메라로부터 프레임을 연속적으로 Capture (캡처)해서 지정된 이미지 버퍼에 저장하는 동작입니다. 이 모드는 태생 부터가 비동기 방식으로 작동합니다.
하지만 이 모드에는 치명적인 한계가 있습니다. 무엇인고 하면, 새로운 프레임이 수집될 때마다 이전 프레임을 동일한 버퍼에 덮어쓰기 때문에, Image Grab (이미지 그랩)이 진행되는 동안에는 안정적인 이미지 처리 작업을 수행할 수 없습니다. 따라서 이 기능은 주로 실시간 디스플레이나 특정 Trigger (트리거)를 기다리는 용도로 제한적으로 사용됩니다.
아쉽게도 두 가지 모드 (MonoShot Grab, Continuous Grab)는 실시간 데이터 스트림과 가변적인 처리 시간 사이의 충돌 문제를 해결하지 못합니다. 사실 영상의 Frame은 반드시 실시간으로 이루어져야 하지만, 이미지 처리는 반드시 예측 가능한 시간내에 처리가 되지 않기 때문이죠. (영상 처리 소요 시간의 예측이 불가능 하다는 말씀.) 이런 문제 때문에 데이터 손실의 위험이 발생하고, 고성능의 영상 처리 시스템에서는 더 정교한 Architecture 가 필요하게 됩니다. 뻔한 얘기지만, MIL 영상 처리 라이브러리에서 이런 문제를 알고 팔아 먹진 않았겠죠. MIL 영상 처리 라이브러리는 이것을 해결하기 위해 Image Grab과 Image Processing 을 분리 및 병렬 처리하는 API 를 제공합니다. 이제 그 내용을 다뤄 보도록 하죠.
Recommand Image Acqusition(Grab) and Image Processing
MIL 영상 처리 라이브러리에서 제공하는 MdigProcess() 함수는 MIL 라이브러리에서 가장 강력하고 효율적인 이미지 수집 방식으로, MIL 영상 처리 라이브러리를 이용한 대부분의 비전 애플리케이션에 권장하는 방식입니다. 이 API 함수는 Image Grab (이미지 그랩)과 Image Processing (영상 처리)를 지능적이고 효율적으로 병렬화 해서 단일 함수 호출만으로 복잡한 작업을 원활하게 수행하도록 합니다. 이제 MdigProcess() 함수가 어떻게 실시간 비전 애플리케이션의 성능과 안정성을 극대화하는지 알아보도록 하죠.
MdigProcess ()
위 그림처럼 MdigProcess() 함수는 MdigGrab 및 MdigGrabContinuous의 문제점 (한계?)를 극복하기 위해 설계되었습니다. 이 함수의 가장 큰 장점은 하나의 함수 호출로 프레임 획득과 처리를 모두 수행하여 코드 복잡성을 줄이고 성능을 최적화 한다는 점입니다. 이것은 다음 두 가지 핵심 개념을 통해 구현 됩니다.
• Multiple Buffering (다중 버퍼링): ‘Circular Buffering (순환 버퍼링)‘이라고도 불리는 이 방식은, 순차적으로 획득되는 프레임들을 저장하기 위해 미리 할당된 여러 개의 버퍼 리스트(list)를 사용합니다. 쉽게 말해 하나의 버퍼에 Image Grab (이미지 그랩)이 진행되는 동안 다른 버퍼에서는 처리 작업이 수행 하는 방식입니다.
• User-defined Hook Function (사용자 정의 후크 함수): 새로운 프레임이 Buffer List (버퍼 리스트) 중 하나에 성공적으로 획득 될 때마다, 사용자가 미리 정의한 후크 함수가 호출되도록 합니다. 이 함수는 Grab Thread (그랩 스레드)와는 독립된 별도의 병렬 처리 스레드에서 실행되어 해당 프레임에 대한 모든 처리 작업을 담당합니다.
이런 방식의 진짜 강점은 실시간 데이터 무결성 보장입니다. 만약 Processing Thread (처리 스레드)가 특정 프레임을 처리하는 데 예상보다 긴 시간이 소요되더라도, Grab Thread (그랩 스레드)는 Processing Thread (처리 쓰레드)에 영향을 받지 않고 다음 프레임들을 미리 할당된 다른 버퍼에 계속해서 실시간으로 수집하는 거죠.
이러한 Image Grab (이미지 그랩)과 Image Processing (영상 처리)의 분리 덕분에, 처리 작업의 일시적인 지연으로 인해 실시간 데이터를 놓치는 상황이 발생하지 않습니다. Processing Thread (처리 스레드)가 작업을 마치고 여유를 찾으면, Grab Thread (그랩 스레드)가 이미 수집해 놓은 다음 프레임을 즉시 가져와 처리할 수 있도록 하는 거죠. 이러한 Image Grab (이미지 그랩)과 Image Processing (영상 처리) 방식의 asynchronous decoupling (비동기적 분리)는 영상 처리 시스템을 견고하게 만들어 주는 거죠. Processing Thread (처리 스레드)에서 예외적인 지연이 발생하더라도 획득 파이프 라인은 전혀 영향을 받지 않으므로, 데이터 손실 없이 안정적인 장시간 운영이 가능해집니다.
MdigProcess 의 작동 모드 비교
MdigProcess는 애플리케이션의 요구 사항에 따라 Synchronous (동기) 또는 Asynchronous (비동기) 모드로 작동할 수 있습니다. 각 모드의 특징을 이미지와 함께 아래와 같이 비교해서 정리 하겠습니다.
| 특징 | 동기(Synchronous) 모드 | 비동기(Asynchronous) 모드 |
| Grab 제어 | M_SEQUENCE 파라미터를 사용해서 지정된 수의 프레임만 grab 하고 종료. | M_START 로 시작해서 M_STOP 으로 명시적으로 중지할 때 까지 연속적으로 grab. |
| Application Thread 동작 | 지정된 모든 프레임의 grab 및 Processing이 완료될 때 까지 Main Thread 가 차단(Blocking) | 메인 스레드가 차단되지 않아(Non-blocking), 그랩 및 처리와 동시에 다른 작업을 수행. |
| 버퍼 사용 방식 | 버퍼 리스트를 순차적으로 한 번만 사용 | 버퍼 리스트의 마지막 버퍼까지 사용하면 다시 첫 번째 버퍼로 돌아오는 순환(Round-robin) 방식으로 재 사용. |
| 주의 사항 | 전체 시퀀스가 완료될 때까지 메인 애플리케이션 스레드가 차단되므로, 다른 동시 작업(예: UI 업데이트)이 필요한 시스템에는 부적합. | 프레임 손실을 방지하려면, 평균 처리 시간이 평균 획득 시간보다 반드시 짧아야 함. |
MdigProcess() 함수는 다중 버퍼링과 병렬 처리 스레드를 통해 이미지 수집과 처리를 완벽하게 통합함으로써, 기존 방식의 한계를 뛰어넘는 효율성과 안정성을 제공합니다. 그렇다면, 반드시 Digitizer (디지타이저)가 구성된 경우에만 사용하여 개발할 수 있다면 개발하기 어렵겠죠? 그래서 이렇게 강력하다고 설레발 치는 기능을 실제 하드웨어 없이도 개발하고 테스트할 수 있는 방법을 알아 보도록 하겠습니다.
Simulation Digitizer
실제 이미지 수집 하드웨어가 준비되지 않은 환경에서도 비전 애플리케이션의 핵심 로직을 개발, 디버깅, 테스트할 수 있는 능력은 영상 처리 개발자의 개발 기간을 단축하고 유연성을 크게 향상시킵니다. 효율적인 개발 워크플로우는 프로젝트 성공의 핵심 요소이기도 하구요. 그래서 MIL 라이브러리의 시뮬레이션 디지타이저 기능의 개념과 활용하는 방법을 차근 차근 알아보도록 하죠.
Simulation Digitiger (시뮬레이션 디지타이저)의 목적은 이미지 획득 하드웨어가 없는 컴퓨터에서 비전 애플리케이션을 개발, 디버그 또는 테스트하기 위한 기능을 제공하는 것 이겠죠. 시뮬레이션 디지타이저는 실제 디지타이저와 동일한 API 인터페이스를 제공하므로, 개발자는 하드웨어 유무에 관계없이 동일한 코드로 애플리케이션 로직을 구현하고 검증할 수 있습니다.
Simulation Digitizer 사용 방법 및 순서
사용 방법에 대해 기술하기도 조금 민망하지만, Simulation Digitizer (시뮬레이션 디지타이저)를 사용하는 절차는 매우 간단합니다. 개발을 진행한 PC 또는 개인 노트북에서 아래와 같은 단계로 구성하면 되니까요.
1. 할당: Host System (호스트 시스템: PC)과 Digitizer (디지타이저)를 할당할 때, 파라미터로 물리적 장치 이름 대신 ‘에뮬레이션된 디지타이저(emulated digitizer)’를 지정합니다.
2. 이미지 로딩: 할당된 시뮬레이션 디지타이저를 사용하여 디스크에 저장된 이미지를 불러올 수 있습니다. 특정 폴더의 개별 이미지 파일 또는 전체 이미지 디렉터리를 지정하여 실제 하드웨어에서 이미지를 수집하는 것과 동일한 방식으로 처리 작업을 테스트할 수 있습니다.
3. 해제: 테스트 및 개발이 완료되면, 실제 디지타이저와 마찬가지로 반드시 할당된 리소스를 해제하여 메모리 누수를 방지해야 합니다.
정리
간단히 정리 될 줄 알고 시작했는데, 생각 보다 길어 지네요. ㅠ.ㅠ
이번 포스팅 내용을 정리하고 마무리 할게요.
이번 포스팅에서는 MIL 영상 처리 라이브러리를 활용해서 효율적으로 Image Acqusition 시스템을 구축하는 방법을 다뤘습니다. 핵심 내용은 아래에 정리한 것처럼 크게 3가지 정도로 요약 되겠네요.
• 다양한 그랩 모드: 시스템 요구 사항에 따라 단일 또는 다중 이미지를 캡처할 수 있는 다양한 그랩 모드(Monoshot, Continuous, MdigProcess)가 제공되며, 각 모드의 특징과 한계를 이해하고 사용하세요.
• MdigProcess() 함수의 효율성: 이미지 그랩과 처리를 병렬 스레드에서 하나의 함수 호출로 통합하는 MdigProcess() 함수는 대부분의 실시간 비전 애플리케이션에 가장 효율적이고 안정적인 솔루션입니다.
• 하드웨어 독립적 개발: Simulation Digitizer (시뮬레이션 디지타이저)를 활용하면 실제 수집 하드웨어 없이도 이미지 처리 로직을 사전에 개발하고 테스트할 수 있으니까, 영상 처리 애플리케이션을 개발할 때 꼭 활용해서 개발 생산성과 유연성을 크게 향상시키고, 야근/철야 하지말고 일찍 들어가세요!!! 살아야죠~!
이번 포스팅의 마지막 내용으로 성공적으로 영상 처리 시스템을 설계하기 위해 시스템 설계자와 개발자는 애플리케이션의 실시간 요구 사항, 데이터 처리의 복잡성, 그리고 시스템 리소스 등을 종합적으로 고려해야 합니다. MdigProcess() 는 대부분의 고성능 애플리케이션에 최적의 솔루션을 제공하지만, 동기 모드와 비동기 모드 사이의 선택은 애플리케이션의 구체적인 동작 모델에 따라 신중하게 이루어져야 합니다.
예를 들어, 컨베이어 벨트에서 고정된 수량의 제품을 검사하는 배치(batch) 기반 애플리케이션은 모든 처리가 끝날 때까지 대기하는 동기 모드가 이상적입니다. 반면, 사용자 인터페이스에 실시간 영상을 표시하면서 Back Ground (백그라운드)에서 분석을 수행하거나 외부 시스템과 지속적으로 통신해야 하는 복합적인 모니터링 시스템에는 Main Thread (메인 스레드)를 차단하지 않는 비동기 모드가 필수적입니다. 이처럼 애플리케이션의 동작 모델에 맞는 모드를 선택하는 것이 성공적인 영상 처리 시스템 설계의 핵심입니다.
다음 포스팅에서는 MIL 영상 처리 라이브러리에서 사용하는 buffer (버퍼) 에 대해 다뤄보도록 하겠습니다.
참고 자료
Computer Science Theory: Producer-Consumer Problem (버퍼링 이론적 배경)
Zebra Vision Academy: Acquisition Methods Video