Windows Image Acquisition (WIA)

Windows Image Acquisition (WIA) is the still image acquisition platform in the Windows family of operating systems starting with Windows Millennium Edition (Windows Me) and Windows XP.


The WIA platform enables imaging/graphics applications to interact with imaging hardware and standardizes the interaction between different applications and scanners. This allows those different applications to talk to and interact with those different scanners without requiring the application writers and scanner manufactures to customize their application or drivers for each application-device combination.

Graphic showing the basic architecture of WIA as a two-way layer between imaging applications and devices.

Benefits of Windows Image Acquisition 2.0

WIA provides benefits to application developers, device manufacturers, and scanner users who need to interact with imaging hardware.

For Application Writers

  • Windows runs a certification process for WIA drivers so WIA applications are guaranteed to be base-level compatible with all WIA-based scanners.
  • WIA drivers are loaded in the WIA service process, thus providing a more stable driver environment.
  • Applications can be initiated from the scanner scan button via push events supported by the WIA subsystem.
  • The WIA includes a default segmentation filter that all drivers can take advantage of; this way, applications do not have to write code for multi-region scanning for purposes such as separating out a large number of photos spread over a flatbed scanner.

For Device Manufactures

  • WIA driver certification process helps driver developers in establishing that their driver is WIA-compliant.
  • WIA drivers can take advantage of a built-in segmentation filter, image processing filter and error handler, if they choose to do so.
  • WIA-based scanners work right out of the box on Windows with Windows scanning applications such as Windows Fax and Scan and Paint.
  • WIA drivers offer better integration with Windows such as the full device experience.
  • Windows Vista release includes a WSD-WIA class driver that enables all devices compliant with Web Services for Scanner (WS-Scan) protocol to work with WIA applications without any additional driver or software.

For Scanner Users

  • WIA-based scanners can be used from Windows applications such Windows Fax and Scan and Paint without the need for any additional software.
  • WIA-based applications and scanners can also take advantage of WIA add-ons such as the segmentation filter which enables such features as processing a number of pictures on the scanner and scanning them all to individual files without user intervention.
  • WIA-based devices offers a much better integration with other Windows features such as the Device Stage feature for Windows 7.
  • WIA provides a more robust, stable and reliable scanning experience by isolating the driver and the application.

Development of Windows Image Acquisition

The imaging architecture in Windows 2000 and Windows 95 or later consisted of a low-level hardware abstraction, Still Image Architecture (STI), and a high-level set of APIs known as TWAIN. In Windows XP and Windows Me WIA was introduced. WIA is an imaging architecture that builds on STI and does not require TWAIN, although TWAIN is still supported alongside WIA.

WIA 1.0 was introduced in Windows Me and Windows XP and supports scanners, digital cameras and digital video equipment. WIA 2.0 was released with Windows Vista. WIA 2.0 is targeted towards scanners but continues to offer support for legacy WIA 1.0 applications and devices through a WIA 1.0 to WIA 2.0 compatibility layer provided by the WIA service. However, video content support was removed from WIA for Windows Vista. We recommend Windows Portable Devices (WPD) API for digital cameras and digital video equipment in the future. WIA 1.0 as well as STI TWAIN drivers are still supported directly on Windows Vista and Windows 7 alongside native WIA 2.0 device drivers and imaging applications.

Overview of Windows Image Acquisition

WIA provides a framework that allows a device to present its unique capabilities to the operating system and allows imaging applications to invoke those unique capabilities.

The WIA platform includes a data acquisition protocol, a Device Driver Model and Interface (DDI), an API and a dedicated WIA service. The platform also includes a set of built-in kernel mode drivers that support communication with imaging devices locally connected through USB, serial/parallel, SCSI and FireWire interfaces. The WIA subsystem also includes a transparent compatibility layer which allows TWAIN compatible applications to employ and use WIA-driver-based devices.

Network connected imaging devices that support Web Services for Devices (WSD) protocol can also be used from WIA-compliant imaging applications on Windows Vista and Windows 7 out of the box via a WSD-WIA class driver that shipped as part of Windows Vista. The class driver converts WIA calls to WSD calls and vice versa and makes already existing WIA applications work with WSD based scanners without any additional driver.

WIA drivers are made up of a user interface (UI) component and a core driver component, loaded into two different process spaces: UI in the application space and the driver core in the WIA service space. The service runs in Local System context in Windows XP and runs in Local Service context starting with Windows Server 2003 and Windows Vista for enhanced security against buggy or malicious drivers.

Graphic showing the architecture of WIA and how it operates as a service.

The WIA API set exposes imaging applications to still image acquisition hardware functionality by providing support for:

  • Enumeration of available image acquisition devices.
  • Creating connections to multiple devices simultaneously.
  • Querying properties of devices in a standard and expandable manner.
  • Acquiring device data by using standard and high performance transfer mechanisms.
  • Maintaining image properties across data transfers.
  • Notification of device status and scan event handling.

Windows added scripting support to WIA by releasing the WIA Automation Library in 2002 that was incorporated in Windows Vista as Windows Image Acquisition (WIA) Automation Layer and continues to be a part of Windows 7. The WIA Automation Library provides end-to-end image acquisition capabilities to automation-enabled application development environments and programming languages such as Microsoft Visual Basic 6.0, Active Server Pages (ASP), VBScript and C#.

For Windows 7, WIA APIs have additional support to complement the already existing push-scanning support.

  • Auto-configured device initiated scanning with scan parameters configured at the scanner on the device front panel.
  • Automatic source selection for device-initiated scan.

Facts about Windows Image Acquisition 2.0

  • The data transfer mechanism in WIA 2.0 is stream based. The stream abstraction removes the distinction between different transfer types and also allows exchange of mutually agreed-upon metadata between device and application.
  • WIA 2.0 subsystem also includes a basic image processing filter driver add-on that is optionally replaceable by the scanner driver, if the driver chooses to provide a customized image processing filter. The built-in filter enables post processing of images acquired through the scanner. Image processing filter also enables live software previews when small settings such as brightness and contrast are adjusted.
  • The segmentation filter is another handy WIA component that can be replaced by a more customized filter by the scanner driver. The segmentation filter can be used for multi-region scanning. Multi-region scanning, as an example, allows an application to automatically detect different scan regions without any user intervention, such as identifying a bunch of photos lying randomly on the scanner flatbed.
  • WIA 2.0 provides a replaceable/extensible error handler to gracefully handle, and possibly recover from, software, hardware and configuration errors and delays. The error handler is another WIA component that can be replaced with a more customized version by the scanner driver. This extension provides status and error messages during data acquisitions such as "Lamp warming up," "Cover open," "Paper jam," and so on. This extension also allows cleaner support for "Cancel operations."

Developer Audience

The WIA API is designed for use by C/C++ programmers. Familiarity with the Windows  GUI and Component Object Model (COM) interfaces is required.

For developers familiar with Microsoft Visual Basic 6.0, Active Server Pages (ASP), or scripting, WIA provides an automation layer for Windows XP Service Pack 1 (SP1) or later that builds upon and simplifies access to the foundation provided by C/C++. For information about the automation layer, see Windows Image Acquisition Automation Layer.

Note  The WIA Automation Layer supersedes Windows Image Acquisition (WIA) 1.0 scripting.

Run-Time Requirements

Applications that use the WIA API require Windows XP or later.

WIA Topics

The WIA topics are organized as shown in the following table.

About Windows Image AcquisitionGeneral information about WIA
Windows Image Acquisition DriversWIA driver development
Windows Image Acquisition Automation LayerWIA Automation Layer
WIA TutorialWalkthrough of code included in the software development kit (SDK) that focuses on specific tasks
ReferenceInformation on WIA interfaces, methods, objects, and data types used in C/C++ and scripting.

[원본 :]

Posted by Golmong

댓글을 달아 주세요

[퍼온글] TWAIN

기술 이야기 2017.01.29 14:17 |

TWAIN : 스캐너등 이미지장치 인터페이스 API 규약


TWAIN 의 배경

1991년부터 Aldus, Caere, Eastman Kodak, Hewlett-Packard, Logitech 의 주도와 Adobe, Howtek, Software Architect 의 후원 속에 만들어진 TWAIN은 스캐너, 디지털 카메라와 같은 화상입력장치를 그래픽 처리 프로그램과 직접 연결시켜 이미지 데이터를 전달하는 소프트웨어 적인 표준 인터페이스입니다. 만약 스캐너를 새로 구입했는데 Photoshop에서 이미지를 직접 스캔받고 싶다면 먼저 그 스캐너의 TWAIN 드라이버를 PC에 설치하면 바로 사용할 수 있는 것입니다.
TWAIN 기능을 지원하기 위해서는 어플리케이션에는 TWAIN 인터페이스를 지원하는 코드를 집어 넣어야 하고, 주변장치에서는 자체의 TWAIN driver (Data Source)를 제공해야 합니다.
TWAIN이라는 표준 인터페이스를 사용함으로써 프로그램 개발자는 각기 다른 주변장치에 대한 고려 없이 TWAIN을 지원하는 모듈만을 갖춤으로써 모든 TWAIN 지원 장치를 이용할 수 있고, 주변장치 개발자는 여러 프로그램을 위한 드라이버를 모두 개발할 필요없이 TWAIN 인터페이스를 만족하는 드라이버만 개발하여 기존에 개발된 모든 TWAIN 지원 프로그램을 그대로 이용할 수 있게 되는 것입니다.
자세한 내용은 TWAIN Working Group의 홈페이지(를 방문하시면 최신 스펙과 프로그램 및 주변장치를 위한 샘플 소스, 그리고 설치 방법 등을 알 수 있습니다.

TWAIN 의 구성

TWAIN은 3 부분으로 구성됩니다.
첫 번째는 TWAIN을 지원하는 어플리케이션, 두 번째는 보통 TWAIN 드라이버라고 말하는 데이터 소스(DS), 그리고 세 번째는 이들의 중간에서 인터페이스를 해주는 TWAIN 매니저 입니다.
TWAIN 드라이버는 Windows OS의 경우 Windows 디렉토리 안에 TWAIN (16비트) 또는 TWAIN_32 (32비트) 디렉토리 밑에 설치해야 하며 확장자가 *.DS 로된 일종의 DLL (Dynamic Linked Library) 파일입니다. MacOS 의 경우는 코드리소스 파일형태이며 Preference 폴더의 TWAIN 폴더에 설치합니다.
TWAIN 매니저는 TWAIN.DLL (16비트) 와 TWAIN_32.DLL (32비트) 이고 Windows 디렉토리에 위치합니다.
참고로 twunk_16.exe 와 twunk_32.exe 는 thunking layer 로서, DDE 통신을 이용해 16비트 TWAIN 드라이버와 32비트 프로그램을 연결해 주거나 32비트 TWAIN 드라이버와 16비트 프로그램을 연결하는 것을 가능하게 해주는 유틸리티입니다.

TWAIN 의 3 가지 전송방식

TWAIN 인터페이스에는 3 가지 전송방식을 정의하고 있습니다.
첫 번째는 Native Mode Transfer 로 드라이버가 비트맵을 메모리에 로드하고 그 핸들을 프로그램에 넘겨주는 방법입니다.
두 번째는 Buffered Memory Mode Transfer 로 프로그램이 버퍼를 할당해 놓고 드라이버는 그 버퍼에 비트맵 데이타를 조금씩 나누어 복사하는 방법입니다.
세 번째는 Disk File Mode Transfer 로 프로그램이 파일명을 정해주면 드라이버가 그 파일명으로 비트맵을 저장하는 방법입니다.
첫 번째와 두 번째 방법은 모든 드라이버가 지원하도록 정하고 있으며 세 번째 방법은 드라이버에 따라 지원을 하지 않을 수도 있습니다.

TWAIN 의 기본 동작

1. 사용자가 프로그램에서 "Select source..." 명령을 선택한다.
2. TWAIN 매니저가 TWAIN 폴더와 TWAIN_32 폴더를 검색해 시스템에 설치된 TWAIN 드라이버의 목록을 나열한다.
3. 사용자가 그 중 하나를 선택하면 WIN.INI 파일의 [Default source] 항목에 기록한다.
4. 사용자가 "Acquire.." 명령을 선택하면 매니저가 Default source를 연다.
5. 프로그램과 드라이버 간에 지원하는 전송형식과 이미지 포맷등을 체크하는 capability negotiation 과정이 일어난다.
6. 드라이버의 윈도우가 나타나고 외부기기로 부터 이미지를 가져올 수 있게된다.
7. 이미지를 가져오게 하면 드라이버가 전송을 요청하고 프로그램은 지원하는 전송방식으로 이미지 전송을 한다.
8. 전송이 완료되면 프로그램은 드라이버에게 전송의 끝을 알린다.
9. 사용자가 드라이버의 윈도우를 닫으면 드라이버는 매니저에게 닫기를 요청하고 매니저가 드라이버를 닫음으로써 TWAIN 세션이 종료된다.


Q1) TWAIN을 지원하는 어플리케이션을 작성하고자 하는데 참고할 만한 자료는?
A1) TWAIN 지원 어플리케이션을 개발하는 경우 다음 자료를 참고하세요.
1. TWAIN Working Group의 sample 프로그램 Twack
2. EZTWAIN Toolkit (C/C++/Delphi/VB)
3. CTWAIN MFC 개발자를 위한 TWAIN 클래스

Q2) TWAIN 기능을 지원하려면 하드웨어가 바뀌어야 하나?
A2) TWAIN 은 소프트웨어 적인 인터페이스이기 때문에 하드웨어는 바뀔 필요가 없습니다.
기존의 serial, parallel, SCSI, USB 포트를 통해 데이터를 가져오는 부분에 TWAIN 인터페이스로 이미지를 전달하는 부분만 결합해주면 됩니다.

Q3) TWAIN 드라이버 설치방법은?
A3) TWAIN 홈 페이지에는 윈3.1, 윈95, 윈NT의 3가지 OS에 대한 설치방법을 설명하고 있습니다.
먼저 윈도우즈 디렉토리에 설치해야 할 TWAIN 관련 파일은 TWAIN.DLL, TWAIN_32.DLL, TWUNK_16.EXE, TWUNK_32.EXE 입니다.
추가적으로 윈3.1의 경우는 share.exe 가 autoexec.bat에서 실행되도록 해야하고 MSVCRT20.DLL 를 system 디렉토리에 설치합니다. 그리고 윈NT의 경우에는 system32 폴더에MSVCRT20.DLL 을 설치하도록 하고 있습니다. 추가 파일들은 OS에 따라 다르므로 TWAIN 홈에서 각 OS에 대해 필요한 파일을 각각 다운로드 받아야 합니다.
이제 TWAIN 드라이버는 16 비트 용의 경우에는 WINDOWS\TWAIN 디렉토리에, 32 비트 용인 경우에는 WINDOWS\TWAIN_32 디렉토리에 설치해야 합니다. TWAIN 매니저는 하위 디렉토리까지 검사를 하므로 기기의 이름과 같은 자신만의 서브 디렉토리를 만들어 설치하는 것이 깔끔하고 보기 좋습니다.

[원본 :]

Posted by Golmong

댓글을 달아 주세요



MQTT(Message Queue Telemetry Transport) 프로토콜은 기계간 통신(M2M)/IoT를 위한 프로토콜이다. HTTP의 request/response 방식 대신 브로커를 사용한 publish/subscribe 방식으로 메시지를 주고 받는다. 물론 MQTT 역시 HTTP와 마찬가지로 TCP/IP 프로토콜 위에서 동작한다. 이 프로토콜의 첫번째 버젼은 1999년 Andy Stanford-Clark와 Arlen Nipper에 의해 발표되었다. 2013년 IBM이 OASIS 표준화 기구에 MQTT v3.1을 제출하여 승인받았다. 또한 비 TCP/IP 네트웍 상에서 동작하는 MQTT의 변종도 존재한다. MQTT-SN은 ZigBee 기반 네트웍 상에서 사용된다.
MQTT는 최소한의 프로토콜 오버헤드만으로 동작할 수 있기 때문에 임베디드 시스템같이 한정된 자원을 가진 시스템이나 저대역폭(low bandwidth) 또는 불안정한 네트웍 환경에서도 사용할 수 있다. 또한 다양한 언어를 지원하는 라이브러리들이 공개되어 있다. mbed에서라면 mbed MQTT library, 아두이노에서는 arduino client for MQTT를 사용할 수 있다.
이 기술이 특히 흥미로운 것은 모든 데이터를 단일 transport 메커니즘으로 처리한다는 것이다. 즉 특정 서비스를 위해 각각 따로 방화벽을 설정할 필요 없이, 단일 TCP 포트만으로 모든 종류의 메시지를 전달하는데 충분하다.

MQTT에서 publish/subscribe를 위한 메시지 큐를 '네트웍의 트위터'라고 생각할 수도 있다. 클라이언트는 특정 토픽에 대한 메시지를 수신하기 위해 토픽을 구독(subscribe)하고, 다른 클라이언트는 그 토픽에 대한 메시지를 발행(publish)한다. 메시지들은 토픽으로 분류된다. 예를들어 nagios/mta, nagios/disk, test/kr/private 같은 식의 토픽을 가질 수 있다. 클라이언트는 임의 갯수의 토픽을 구독할 수 있고, 구독할 토픽에 와일드카드를 포함할 수도 있다. (예: nagios/#) MQTT에서 메시지는 최대 256MB 크기의 UTF-8 BLOB이다.

Publish/Subscribe 모델

MQTT는 일반적으로 웹에서 사용되는 client/server 모델 대신 publish/subscribe(발행/구독) 모델을 사용한다. Client/server 모델에서는 클라이언트가 그 상대방이 되는 서버와 직접 통신을 하게 된다. 하지만 publish/subscribe 모델은 특정 메시지를 보내는 클라이언트(즉 publisher)와 그 메시지를 받는 다른 클라이언트들(즉 subscriber)를 분리시켜 서로는 상대방의 존재 여부를 모른다. 그러므로 통신을 하기 위해서는 publisher와 subscriber 양측이 모두 다 알고 있는 broker라 불리는 3번째 컴포넌트가 필요하게 된다. (publisher건 subscriber건) 모든 클라이언트는 브로커와 통신을 하고, 브로커는 자신이 받은 메시지들을 필터링 해 적절하게 분배하게 된다.

위의 그림에서 온도센서가 publisher, 랩탑과 스마트폰이 subscriber, HiveMQ가 MQTT 브로커가 된다. Subscriber들이 구독하길 원하는 토픽(여기서는 'temperature')이 있으면 그 토픽에 대해 브로커에게 구독신청(subscribe)을 한다. 그 후 온도센서가 측정한 온도값을 'temperature'라는 토픽으로 브로커에게 발행(publish)하게 된다. MQTT 브로커는 'temperature' 토픽에 대한 메시지를 받으면 해당 토픽을 구독하고 있는 subscriber들(여기서는 랩탑과 스마트폰)에게 이 메시지를 전달해준다. 토픽을 구독하는 클라이언트는 여러대가 될 수도 있다. 이 경우 publisher는 자신이 발행한 토픽을 구독한 subscriber가 몇개인지 신경 쓸 필요가 없다. (해당 토픽을 구독한 subscriber가 하나도 없을수도 있다.) 메시지는 브로커를 통해 전달되기 때문에 publisher와 subscriber는 서로의 IP주소와 포트를 알고 있을 필요도 없고, 서로 동시에 실행되고 있을 필요도 없다.

QoS (Quality of Service)

모든 메시지는 QoS값을 가지고 publish 된다. MQTT에는 3가지 QoS 타입이 있다.

  • QoS_0 - "At most once" TCP/IP 네트웍 상에서 최대의 노력을 기울여 메시지가 전달되도록 함. 하지만 메시지가 중복되거나 분실될 수도 있음. 센서값이 한번 분실되어도 금새 다음번 값을 publish하기 때문에 분실되는 것이 큰 문제가 되지 않는 경우에 사용
  • QoS_1 - "At least once" 메시지가 전달되는걸 보장. 하지만 이로 인해 중복이 발생할 수도 있음
  • QoS_2 - "Exactly once" 메시지가 한번만 전달되는걸 보장. 과금 정보처럼 메시지 분실이나 중복이 문제를 발생시킬 수 있는 경우에 사용


그리고 publish/subscribe 모델은 기존의 client/server 모델에 비해 훨씬 더 큰 확장성을 가지고 있다. 브로커의 동작이 event-driven 방식이기 때문에 쉽게 병렬화가 가능하기 때문이다. 또한 메시지 캐슁과 지능적 라우팅이 확장성을 증가시키는데 결정적이다. 하지만 publish/subscribe를 동시에 수백~수천만개를 처리하도록 확장시키는건 역시 큰 문제이다. 하지만 이 경우도 클러스터 브로커 노드를 상요해 개별 서버의 로드를 로드밸런싱 하는 것으로 해결할 수 있다.

Posted by Golmong

댓글을 달아 주세요