REFERENCE MANUAL

XCLIBtm
Imaging Board 'C' Library

VERSION 3.7

For use with:
PIXCI® Imaging Boards



Copyright © 1998-2011 EPIX, Inc.
No part of this document may be reproduced, transmitted, photocopied, or translated into another language without the written consent of EPIX, Inc. Information in this document is subject to change without obligation or notice. EPIX, Inc. makes no warranty of any kind with regard to this document, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. EPIX, Inc. assumes no responsibility for any errors that may appear in this document. EPIX, Inc. reserves the right to make changes to the specifications of hardware and software at any time, without obligation or notice.

4MIP, SVIP, XCIP, XCAP, 4MEG VIDEO, 1MEG VIDEO, SILICON VIDEO MUX, QUICK SET VIDEO, 12-7MUX, IMAGE MEMORY EXPANSION, COC40, and COC402 are trademarks of EPIX, Inc.

EPIX, SILICON VIDEO, and PIXCI are registered trademarks of EPIX, Inc.

Other brand, product, and company names are trademarks or registered trademarks of their respective owners.

Printing: 05-Sep-2012

EPIX, Inc.
381 Lexington Drive
Buffalo Grove IL 60089
847.465.1818
847.465.1919 (fax)
epix@epixinc.com
www.epixinc.com

Table of Contents


 

 

 

1. Installation, Configuration, and Usage — Compile Time


 

1.1. Introduction

This manual describes the XCLIB and XCLIB-Lite ``C'' Library for use with the EPIX® PIXCI® A, A310, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, SI, SI1, SI2, SI4, SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, and SV7 imaging boards. The library supports all current and previous versions of the PIXCI® imaging boards, allowing convenient control and access to the features of single imaging boards, of multiple imaging boards, or of one or more imaging boards with multiple functional units.[1]

This common manual discusses all PIXCI® imaging boards, clearly identifying the common features and the distinguishing features as seen through the XCLIB and XCLIB-Lite ``C'' Library. An imaging board specific introduction to using XCLIB and XCLIB-Lite can be found in the ''Getting Started with XCLIB'' chapter of the imaging board's specific manual, such as the PIXCI® SV5 User's Manual, PIXCI® D2X User's Manual, PIXCI® CL1 User's Manual, etc.

A comprehensive example Windows program named xclibex2.cpp is included with the library, and demonstrates many of the library's functions. In particular, it demonstrates a variety of techniques for capturing and displaying video on the graphics display (S/VGA), including the display of nondestructive overlays, and the use of events to receive notification of captured images. The example also demonstrates access to numeric pixel data.

An example DOS and Windows command line program named xclibex1.c is included with the library, and demonstrates capturing images, access to numeric pixel data, and saving images in standard formats. Under DOS, and in conjunction with the PXIPL Image Processing Library, the example also demonstrates displaying video on the graphics display (S/VGA).

An example Visual Basic program named xclibex3.txt, an example VB.NET program named xclibex6.txt, and an example C#.NET program named xclibex7.txt are included with the library, demonstrating the fundamental library functions.

An example Windows program named xclibex4.cpp is included with the library, and demonstrates capture of image sequences at video rate and subsequent display on the graphics display (S/VGA). An example Windows program named xclibex5.cpp is included with the library, and demonstrates simultaneous operation of two imaging boards at different resolutions. An example Windows program named xclibexp.cpp is included with the library, and demonstrates live display of processed video images.

An example Windows program named xclibexd.cpp is included with the library for use with the SILICON VIDEO® 1281M, 1281C, 1310, 1310C, 2112, 2112C, 5C10, 5M10, 642M, 642C, 643M, 643C, 9C10, 9M001, 9M001C, 9T001C, 10C6, 10M6, 10C-CL, 10M-CL, WGA-C, and WGA-M cameras, and demonstrates camera specific controls as well as capturing and displaying video on the graphics display (S/VGA). An example VB.NET program named xclibexd.txt provides a similar example.

An example Linux command line program named xclibel1.c is included with the library, and demonstrates capturing images, access to numeric pixel data, and saving images in standard formats.

An example Linux GUI program named xclibel3.c is included with the library, and demonstrates capturing images, and displaying video on the graphics display (S/VGA), using the Gnome Desktop.

These example programs can be compiled and executed, and the source code of each read in conjunction with this manual, to gain familiarity with the library. Instructions on setting options and compilation appear within each program as comments.

A word about conventions used in this manual. Highlighted phrases such as Introduction are a reference to a section of this manual. Highlighted phrases such as FUNDAMENTALS OF DIGITAL IMAGE PROCESSING are a reference to this manual or another publication. Highlighted phrases such as file.xyz are a reference to a file. Highlighted phrases such as threshold typically refer to a function's parameters. Some HTML browsers may not show these variations in a distinguished manner. Unless explicitly differentiated otherwise, references to XCLIB include XCLIB-Lite.

This manual groups the library functions according to expected patterns of use, or common effect. The Index provides an alphabetically sorted listing of function names.

 

1.2. Library Installation

While XCLIB is easy to install, like most manufacturers of PC software we recommend as a precaution that a hard disk backup be performed before installing XCLIB.

To install XCLIB on a PC with hard disk:

  1. For Windows: If XCLIB is provided on CD:

    1. If your PC is set to allow automatic execution of loaded CDs, the CD's interactive index program will be executed automatically. Otherwise, execute the index program, from a command prompt, or via the Windows ''Start'', ''Run'':
          > Z:SETUP       (replace Z with drive letter for your CD)
      

    2. Select ''Setup PIXCI(R) Imaging Software'' and one of:
          XCLIB-Lite 'C' Library for Win 95/98/ME
          XCLIB-Lite 'C' Library for Win NT/2000/XP/Vista/7
          XCLIB 'C' Library for Win 95/98/ME
          XCLIB 'C' Library for Win NT/2000/XP/Vista/7
          XCLIB 'C' Library for Win XP/Vista)/7 (x64)
          XCLIB 'C' Library for DOS+Watcom+Tenberry
          XCLIB+PXIPL `C' Library for Win 95/98/ME
          XCLIB+PXIPL `C' Library for Win NT/2000/XP/Vista/7
          XCLIB+PXIPL `C' Library for Win XP/Vista)/7 (x64)
          XCLIB+PXIPL `C' Library for DOS+Watcom+Tenberry
      
      as appropriate. Click ''OK''.

    3. Follow the installation program's directions, such as to select an installation directory.

  2. For any operating system: If XCLIB is provided on CD:

    1. Browse the CD's index.txt file, or browse the CD's XCLIB directory, to find and execute the appropriate .EXE (for DOS and Windows) or .bin (for Linux) XCLIB installation program file.

    2. Follow the installation program's directions, such as to select an installation directory.

  3. If XCLIB is provided via the internet:

    1. As directed by your customer service representative, download the specified .EXE or .bin file from the EPIX, Inc. web or ftp site.

    2. For Windows or DOS: Execute the downloaded program from a command prompt, or via the Windows ''Start'', ''Run'':
          > THE.EXE
      
      or via the desktop explorer.

    3. For Linux: Execute the downloaded program from a terminal prompt or via the Linux desktop browser.

    4. Follow the installation program's directions, such as to select an installation directory.

    5. Delete the downloaded .EXE or .bin file from your PC's hard drive.
After installation, any files in the chosen directory named *.TXT etc. contain distribution listings, corrections, or additions to this manual, or other up-to-date information.

The example xclibex1.c, xclibex2.cpp, xclibex3.txt, xclibex4.cpp, xclibex5.cpp, xclibex6.txt, xclibex7.txt, xclibexd.cpp, xclibexd.txt, xclibel1.c, or xclibel3.c program, or your application program, can now be compiled and run.

 

1.3. Compiling

The library is compatible with the following compilers, versions, memory models, and environments:

Execution Run Time
Compiler Model Library Name Compiled w. Options Environment Modules

Any 32 bit Microsoft XCLIBW95.LIB -GB -MT -LD Windows 95 XCLIBW95.DLL
Compatible Compiler or Windows 98 EPIXXCW5.VXD
XCLYBW95.LIB Windows ME EPIXXCW5.INF
EPIXXC.SYS (optional)

Any 32 bit Microsoft XCLIBWNT.LIB -GB -MT -LD Windows NT XCLIBWNT.DLL
Compatible Compiler or EPIXXCWT.SYS
XCLYBWNT.LIB EPIXXCWT.INF

Any 32 bit Microsoft XCLIBWNT.LIB -GB -MT -LD Windows 2000 XCLIBWNT.DLL
Compatible Compiler or Windows XP EPIXXCW2.SYS
XCLYBWNT.LIB Windows Vista EPIXXCW2.INF
Windows 7 EPIXXCW2.CAT

Any 32 bit Microsoft XCLIBWNT.LIB -GB -MT -LD Windows XP(x64) XCLIBWNT.DLL
Compatible Compiler Windows Vista(x64) EPIXXCW6.SYS
Windows 7(x64) EPIXXCW6.INF
EPIXXCW6.CAT

Any 64 bit Microsoft XCLIBW64.LIB -GB -MT -LD Windows XP(x64) XCLIBW64.DLL
Compatible Compiler Windows Vista(x64) EPIXXCW6.SYS
Windows 7(x64) EPIXXCW6.INF
EPIXXCW6.CAT

GNU V3 or V4 xclib_i386.a Linux 2.4 kernels pixci_i386.o
32 bit

GNU V3 or V4 xclib_i386_pic.a -fPIC Linux 2.4 kernels pixci_i386.o
32 bit

GNU V3 or V4 xclib_i386.a Linux 2.6 kernels pixci_i386.ko
32 bit

GNU V3 or V4 xclib_i386_pic.a -fPIC Linux 2.6 kernels pixci_i386.ko
32 bit

GNU V3 or V4 xclib_x86_64.a Linux 2.6 kernels pixci_x86_64.ko
64 bit

GNU V3 or V4 xclib_x86_64_pic.a -fPIC Linux 2.6 kernels pixci_x86_64.ko
64 bit

Watcom C/C++ V11.0 f, 32 bit XCLBW1DF.LIB -4r -mf -w3 -ox DOS4GW none
Professional

For Linux, the XCAP application includes a driver recompilation kit, allowing compiling a XCLIB driver so as to exactly match the current kernel.

The Compiled w. Options column shows the significant options used for creation of each library. The exact options shown are neither necessary, nor necessarily desirable, when compiling an application program.

1.3.1. Stack

The available stack space required by the base XCLIB ``C'' Library is 4096 bytes plus 8 times the memory space required for an image's line or column. If the optional PXIPL Image Processing Library is used, the additional stack space required is 4096 bytes plus 4 times the memory space required for an image's line or column. The application program may require significant amounts of additional stack space. Under some operating systems, additional stack space may have to be declared during compilation or linkage to accommodate the total requirement.


Note. For efficiency, the XCLIB library is compiled without explicit stack checks (probes). Invoking a library function with insufficient available stack space will produce strange and catastrophic results.

1.3.2. Heap

The XCLIB ``C'' Library does not require any large malloc'ed storage, other than the host memory allocated for image frame buffers. In addition, smaller amounts of host memory (approximately 64 or 128 bytes per frame buffer) are used for per-buffer status information such as time stamps.

The PIXCI® CL3SD and SI2 use on-board memory instead of host memory for image frame buffers. Host memory (approximately 1 MByte) is needed as a DMA buffer and for per-buffer status information such as time stamps.

With the PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, SI, SI1, SI2, or SI4 imaging board, when used with a color camera where XCLIB provides white balancing, approximately 8*2BitsPerPixel bytes of malloc'ed storage is required for each video state.

Several small amounts of storage, of a few hundred bytes each, are malloc'ed for storage of video state and internal structures.

1.3.3. Memory Allocation Hooks

The XCLIB library invokes the ``C'' library function malloc to obtain memory for temporary use. The application programmer may modify the memory allocation used by XCLIB. This substitution is not available when XCLIB is embedded in a Windows DLL.

Most memory allocated and freed by XCLIB, except memory allocated for image frame buffers, and most memory allocated and freed by the PXIPL Image Processing Library, if used, is actually obtained and released by invoking internal functions pxmalloc, pxfree, pxrealloc, pxmallocf16, and pxfreef16 which are defined in module PXMALLOC.OBJ as:[2]

/* 16/32 bit environments */
void *     _cfunfcc pxmalloc(uint len)          { if(!len)return(NULL);
                                                  return(malloc(len));   }
void       _cfunfcc pxfree(void*buf)            { free(buf);             }
void *     _cfunfcc pxrealloc(void*p, uint len) { if(!p&&!len)return(NULL);
                                                  return(realloc(p,len));}

/* 16 bit environments */ void _far* _cfunfcc pxmallocf16(uint len) { if(!len)return(NULL); return(_fmalloc(len)); } void _cfunfcc pxfreef16(void _far*buf) { _ffree(buf); }
/* 32 bit environments */ void * _cfunfcc pxmallocf16(uint len) { if(!len)return(NULL); return(malloc(len)); } void _cfunfcc pxfreef16(void*buf) { free(buf); }
The application program may provide alternate functions with the same name and semantics, to be selected by the linker in preference to the above definitions.

 

1.4. Compile Time Inclusions

The xcliball.h file directly or indirectly contains all prototype function declarations and definitions of constants and declaration of structures needed for XCLIB. Proper use of library functions requires inclusion of xcliball.h by using the statement:

#include "xcliball.h"
at the start of each source file of the application program that uses XCLIB functions.

If using xcliball.h within a C++ program, then:

extern "C" {
#include "xcliball.h"
}
should be used.[3]

If using xcliball.h in a Windows environment, a

#include <windows.h>
must (not necessarily immediately) precede
#include "xcliball.h"

Several examples shown in this manual utilize the ``C'' construct ''NULL'' to represent ''(void *) 0''. Application programs which use NULL must include the appropriate ``C'' include file, such as stdio.h or stdlib.h.

 

1.5. Common Types and Concepts

Common concepts, data types, and modifiers are discussed below, rather than repeatedly discussed with each function. These concepts and data types are applicable to the SCF Style Interface, the SCF+ Style Interface, and the Structured Style Interface.

1.5.1. Types

The following data types are automatically provided via inclusion of xcliball.h; the programmer need not ''define'' or ''typedef'' these symbols.

Types defined by ``C'':

Symbol ``C'' Definition Use

size_t typically unsigned int size of memory objects
or unsigned long (i.e. malloc())

Extended data types:

Symbol ``C'' Definition Use

uchar unsigned char general
ushort unsigned short general
uint unsigned int general
ulong unsigned long general
schar signed char general
sshort signed short general
sint signed int general
slong signed long general
pxcoord_t int x, y, z image coordinates
pximcnt_t unsigned int image data transfer size
pxim1size_t unsigned int image line size
pxim2size_t unsigned int image size
pxim3size_t uint32 (32 bit library) image sequence size
pxim3size_t uint64 (64 bit library) image sequence size
pxbuffer_t long image buffer number/index
pxvbtime_t uint32 (32 bit library) video field counts/time
pxvbtime_t uint32 (64 bit library) video field counts/time
pximaplen_t uint32 (32 bit library) length of 'imap' mapping
pximaplen_t uint64 (64 bit library) length of 'imap' mapping
pxapiadrs_t uint32 (32 bit library) frame buffer memory address and length
pxapiadrs_t uint64 (64 bit library) frame buffer memory address and length
_farimap _far or blank farness of an 'imap' pointer

1.5.2. Modifiers

The following function calling convention modifiers are automatically provided via inclusion of xcliball.h; the programmer need not ''define'' or ''typedef'' these symbols:
Symbol Typical Definition

_cfunfcc _fastcall or _pascal or _stdcall
_cfunvcc _cdecl or blank
_cfunacc _cdecl or blank
These modifiers vary in different environments, accommodating different conventions under DOS, Windows, and various compilers. Function prototypes apply modifiers automatically, thus the programmer need not normally be aware of their existence, nor are the modifiers normally shown in documentation. The exception to the programmer's need of awareness, and shown in the documentation, are modifiers for functions that are ''called back'' from library functions.

1.5.3. Call Back Types

The following call back function calling convention modifiers are automatically provided via inclusion of xcliball.h; the programmer need not ''define'' or ''typedef'' these symbols:
Symbol Use

pxabortfunc_t premature termination callback predicate function

1.5.3.1. The pxabortfunc_t

Some services, such as the ::bufferSaveStream and ::bufferLoadStream accept an abortp parameter of type pxabortfunc_t, which is declared in xcliball.h as:
typedef int (_cfunfcc pxabortfunc_t)(void*,int,int);
If abortp≠NULL, the service will periodically invoke:
(*abortp)(abortp, ipos, npos);
and prematurely terminate if the return value is nonzero, echoing the same return value. Use of termination values less than 0 is required; use of the particular value PXERBREAK is suggested.

The values passed as done and total indicate the approximate progress of the service. If total>0, then the service, or one phase of the service, is approximately done*100.0/total percent complete. If total=0 and done=0, that invocation of *abortp is not updating the progress information, or the service does not provide progress information.

If total<0, then the processing is being done in phases, with each phase independently reporting progress from 0 to 100%; the number of phases is -total, of which the current phase is done, where 1<=done<=-total. The processing time required may differ among the phases.

If total=0 and done≠0, then the value done should be added to an internal ''disable'' counter whose initial value is 0. While the disable counter is less than 0, interpretation of invocations with total>0 (percent completion) or total<0 (operation phase) should be ignored.

The total and done values are intended solely for optionally advising an interactive user of computational progress, and have accuracy suitable only for such use.

1.5.4. Usage Assumptions

Except where noted otherwise, the library functions expect that the library is currently open for use. The most notable exceptions are, of course, pxd_PIXCIopen, pxe_PIXCIopen or xclib_open which open the library, and pxe_XCLIBinstantiate or pxe_XCLIBuninstantiate to (un)instantiate instances of the library. The pxd_mesgFault, pxd_mesgFaultText, and/or pxd_mesgErrorCode can be used if the open failed, to obtain additional information on the cause of failure.

1.5.5. On Frame Buffers and Memory

For PIXCI® A, A310, CL1, CL2, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, SI, SI1, SI4, SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, or SV7 imaging boards which do not have on-board frame buffer memory, the XCLIB library architecture uses a fixed amount of frame buffer memory. Under Windows 95, 98, ME, NT, 2000, XP, XP(x64), Vista, Vista(x64), 7, and 7(x64), the frame buffer memory is allocated when Windows boots; the total size is fixed until the next reboot. Under DOS+Tenberry, the frame buffer memory is allocated when the XCLIB library is opened; the total size is fixed until the XCLIB library is re-opened. Under Linux, the frame buffer memory is allocated when Linux boots; the total size is fixed until the next reboot.

For all PIXCI® imaging boards, the frame buffer memory is partitioned into image frame buffers, based upon the number of PIXCI® imaging boards in use and the video format configuration and resolution for each imaging board. The frame buffer memory is re-partitioned whenever the number of PIXCI® imaging boards in use changes, or the video format configuration changes.

An XCLIB function such as:

    pxd_goLive(..., 1);
which commands live capture of all fields or frames into image frame buffer 1, does not produce a ''history'' of all fields or frames captured, nor use any memory other than image frame buffer 1; each newly captured field or frame overlays the data of the previously captured field or frame. Similarly,
    pxd_doSnap(..., 1, ...);
    pxd_doSnap(..., 1, ...);
snaps two fields or frames into image frame buffer 1, with the latter overlaying the former.

The image frame buffers for each imaging board are numbered consecutively starting with 1. Thus when using multiple imaging boards, the XCLIB library function

    pxd_goLive(0x03, 1);
which commands both the first and second imaging boards to begin capturing into buffer number 1, does not cause conflict or overwriting of image data; each board has its own, unique, buffer number 1. Similarly, when accessing pixel data or saving the contents of the frame buffer to a file, the appropriate functions require a buffer number as well as a qualifying imaging board number (i.e. ''unit'').

Video capture is always into one of these image frame buffers, and never to a malloc'ed buffer provided by the application program. The XCLIB library provides functions to read/write all or portions of a frame buffer to a program's array or malloc'ed buffer. The XCLIB library also provides the application program with a pointer into the actual image frame buffer.[4]

Since the total number of image frame buffers cannot be increased arbitrarily (for a given number of image boards and a fixed video format resolution), a live sequence capture with:

    pxd_LiveSeq(...)
is limited to the number of image frame buffers. However, nothing precludes the application from executing a continuous live sequence capture using the image frame buffers in a circular fashion, and copying the contents of a newly captured image frame buffer elsewhere (such as malloc'ed memory, or to disk) before the live sequence capture ''returns'' and re-uses that buffer.

1.5.6. On the Semantics of Snap

Functions to snap a video field or frame, such as pxd_goSnap, capture the next field or frame following its invocation; that is, the function ''arms'' the PIXCI® imaging board to capture the next field or frame into a frame buffer. This is in contrast to having the imaging board consume resources continuously capturing every field or frame, and having a hypothetical snap function retrieve the last field or frame captured. This hypothetical behavior can be obtained in XCLIB using pxd_goLivePair or similar functions, but it isn't the behavior of the snap functions.

1.5.7. On Imaging Boards with Multiple Functional Units

The PIXCI® E1DB, ECB2, EL1DB, E4DB, and E8DB imaging boards contain multiple, independent functional units within a single physical board and replaces two PIXCI® E1, ECB1, EL1, E4, or E8 imaging boards, respectively. The PIXCI® ELS2 imaging board contains multiple, independent functional units within a single physical board and provides features similar to two PIXCI® SI imaging boards. The PIXCI® SI2, and SI4 imaging boards contain multiple, independent functional units within a single physical board and provides features similar to two or four PIXCI® SI1 imaging boards, respectively. The PIXCI® SV7 imaging board contains multiple, independent functional units within a single physical board and provides features similar to two PIXCI® SV5B imaging boards.

The XCLIB Library presents the two halves or four quarters of the PIXCI® E1DB, E4DB, E8DB, ECB2, EL1DB, ELS2, SI2, SI4, SV7 imaging board as two or four PIXCI® E1, E4, E8, ECB1, EL1, SI, SI1, SI1, SV5B imaging boards, respectively. If opened together, the halves or quarters are accessed and controlled via a unitmap parameter as described below. Each half or quarter of the PIXCI® E1DB, E4DB, E8DB, ECB2, EL1DB, ELS2, SI2, SI4, SV7 imaging board may also be opened and used independently, except under DOS, Windows 95, 98, ME, and NT in which the first half or quarter must be opened before later functional units. Within software documentation, ''imaging board'' is synonomous with ''functional units'' unless explicitly stated otherwise.

1.5.8. On Multiple Imaging Boards

Each open instance of the library allows operation of one or more identical imaging boards; the imaging boards may have independent video format and resolution. Relevant XCLIB functions allow simultaneous control of multiple boards via the unitmap parameter.[5]

Multiple instances of the library may be opened for mutually exclusive subsets of imaging boards. Different open instances are independent; they do not share Video State ID's or Video Format Configuration's. A single invocation of a XCLIB function can't control multiple imaging boards across multiple open instances of the library.

Only one instance of the library may be opened via the SCF Style Interface. Multiple instances of the library may be opened via the SCF+ Style Interface or the Structured Style Interface.

1.5.9. On Multiple Identical Imaging Boards

A single open instance of XCLIB supports the operation of multiple, identical PIXCI® imaging boards, typically referred to as ''units''. Each relevant XCLIB function provides a unitmap parameter to select which board, or boards, an invocation of that function is to affect. The unitmap is a bit-map; the i'th bit has value 1 to select the i'th imaging board.

Some functions allow operation on multiple imaging boards with a single invocation; they describe unitmap with the phrasing ''on each of the multiple boards selected by ...''.

Some functions only allow operation on a single imaging board with a single invocation; they describe unitmap with the phrasing ''the single imaging board selected by ...''. Should the unitmap have more than one bit set to 1, the imaging board corresponding to the rightmost 1 bit is selected for use.

1.5.10. On Serial Ports

PIXCI® imaging cards for use with Camera Link cameras include a serial port (i.e. similar to asynchronous RS-232) for configuring cameras through the Camera Link cable.

Under Windows, in compliance with the Camera Link standard, the clserEPX.dll, available separately, provides the standard Camera Link Serial API with clSerialInit and related functions for sending and receiving serial data. The clserEPX.dll is most often used by application programs that need an imaging-board independent method to access Camera Link serial ports, such as a camera manufacturer's configuration application. The clserEPX.dll supports all standard Camera Link baud rates.

Under Linux with 2.6 and later kernels, the

    /dev/ttyPIXCI0
    /dev/ttyPIXCI1
    ..
nodes offer ''tty'' style access to the serial port for functional unit 0, functional unit 1, etc. All Camera Link standard baud rates are supported. The ''tty'' style access is most often used by application programs that need an imaging-board independent method to access Camera Link serial ports, such as a camera manufacturer's configuration application.

For convenience of application programs, XCLIB also, directly, includes the clSerialInit and related functions for sending and receiving serial data. These functions support all standard Camera Link baud rates. These functions are also available under Linux.

XCLIB also has alternative functions, pxd_serialConfigure, pxd_serialRead, and pxd_serialWrite for sending and receiving serial data. These may be simpler to use than the clSerialInit and related functions, and, for some PIXCI® imaging cards, these functions support additional, non-standard, baud rates.

For application programs already using XCLIB for video capture, use of the integrated clSerialInit functions or the pxd_serialConfigure functions is more efficient than invoking clSerialInit in the separate clserEPX.dll, or accessing the /dev/ttyPIXCI0, /dev/ttyPIXCI1, etc. nodes. Also, under Windows 95, 98, and ME, XCLIB cannot share access to the PIXCI® imaging board(s) with clserEPX.dll requiring use of the integrated functions. Under Linux with 2.4 kernels, which doesn't support /dev/ttyPIXCI0, etc. nodes, use of the integrated functions is similarly necessary.

1.5.11. On Video Format Configuration

The Video Format Configuration is a group of dozens of parameters that defines the video format (i.e. whether NTSC, RS-170, PAL, or CCIR for applicable imaging boards, or camera manufacturer and model for other imaging boards), the resolution (i.e. capturing more or fewer pixels per line or column), and other settings related to the imaging board's hardware.

The XCLIB library provides a suitable default Video Format Configuration for each PIXCI® imaging board, model, and submodel. The library of defaults is compiled into XCLIB and cannot be changed in the field.

For PIXCI® imaging boards supporting multiple standard formats such as NTSC, RS-170, PAL, or CCIR, a standard format can be selected by name as the second parameter to pxd_PIXCIopen or pxe_PIXCIopen, or as the fourth parameter to xclib_open.

The easiest and suggested method of creating an alternate Video Format Configuration is to use the XCAP application. XCAP uses an identical and compatible[6] Video Format Configuration, although XCAP uses the term ''Video Setup''. In XCAP, use:

    PIXCI®
    PIXCI® Open/Close
    Close
    Camera & Format
    .. select alternate camera or format
    OK
    Open
to select an alternate camera or format from XCAP's predefined selections. Or, use:
    Capture (in PIXCI® Image Viewer)
    Adjustments
to open the Capture & Adjust dialog (if not already open), and select camera and format options within the Capture & Adjust dialog. Or, upon advice of EPIX® Technical Support, use:
    PIXCI® Video Setup
    .. adjust video configuration followed by OK ..
Regardless of method, export the video setup with:
    PIXCI®
    PIXCI® Export Video Setup
After running XCAP, specify the path name of the saved video setup file as the third parameter to pxd_PIXCIopen or pxe_PIXCIopen, or as the fifth parameter to xclib_open.

The contents of the saved video setup file is readable and editable text; the pxlibvs.h and xclibvs.h files describe the various fields. Using the Structured Style Interface,[7] the structures composing the Video Format Configuration, as described in pxlibvs.h and xclibvs.h, can be manipulated directly.

Alternately, using the SCF Style Interface a video setup file can be ''loaded'' without re-opening XCLIB by using[8] pxd_videoFormatAsIncluded. To use SCF style or SCF+ style functions with multiple imaging boards at different formats and resolutions, a saved video setup file, created with XCAP configured with

    PIXCI®
    PIXCI® Open/Close
    Multiple Devices
    Use Individual Formats & Controls
    OK
must be specified as the third parameter to pxd_PIXCIopen or pxe_PIXCIopen.

The XCLIB library does not implicitly use a video format name or saved video setup file; neither the Windows registry, Windows' SYSTEM.INI file, nor Windows' or Linux' environment variables (i.e. via ''SET'' commands) are implicitly used by XCLIB to select a video format name or a video setup file. The application program is free to create its own convention, such as using the C/C++ library's RegQueryValueEx(), GetPrivateProfileString(), or getenv(), for run time selection of the video format name or video setup file.

1.5.12. On Video State ID's

For efficiency, XCLIB maintains copies of Video Format Configurations and associates a unique ''video state id'' integer, greater than zero, with each. Thereafter, the video state id may be used to refer to the Video Format Configuration. In XCLIB, the process of association is termed ''defining a video state''.

1.5.13. On Error Codes

Library functions return a common set of return codes, indicating success or failure. These codes are defined via inclusion of xcliball.h with mnemonic names beginning with ''PXER''. All error return codes are negative values. Specific error conditions can be differentiated by reading the definitions of these codes in pxerrno.h, or by use of the pxd_mesgErrorCode function.

1.5.14. On Structures and Signatures

Various structures which might change between versions of XCLIB utilize a ''signature'', so that an application compiled with an older version of XCLIB can't declare an older, smaller, structure and have it accepted by a newer library expecting a newer, larger, structure. Structures that are changed typically define the added fields so that a zero value maintains the previous structure's effect.

Applications should initialize ''new'' instances of structures by zeroing the entire structure to 0, and setting the ddch.len and ddch.mos to the size of the structure, and to a signature constant, respectively. For example,

    struct pxdevfault fault_structure;

memset(&fault_structure, 0, sizeof(fault_structure)); fault_structure.ddch.len = sizeof(fault_structure); fault_structure.ddch.mos = PXMOS_DEVFAULT;
initializes the pxdevfault structure.

 

1.6. Common Structures

Common structures are discussed below, rather than repeatedly discussed with each function. These concepts and data types are applicable to the Structured Style Interface, and are not needed for the SCF Style Interface or the SCF+ Style Interface. Declaration of all structures are automatically provided via inclusion of xcliball.h.

Most structures have an abbreviated name typedef'ed. These follow the convention of the structure's name followed by ''_s''. For example, either of:

    struct  pxy     a_pair_of_xy_coordinates;
            pxy_s   another_pair_of_xy_coordinates;
may be used.

1.6.1. Coordinates, Images, and Image Window Structures

The pxy struct provides a pair of x, y coordinates defining a point in two dimensions:

struct pxy {
    pxcoord_t   x;
    pxcoord_t   y;
};
typedef struct pxy pxy_s;
typedef struct pxy pxypoint_s;
The pxyz struct provides a triplet of x, y, z coordinates defining a point in three dimensions:
struct pxyz {
    pxcoord_t   x;
    pxcoord_t   y;
    pxcoord_t   z;
};
typedef struct pxyz pxyz_s;
typedef struct pxyz pxyzpoint_s;

The pxywindow struct provides a pair of x, y coordinates defining a rectangle in two dimensions:

struct pxywindow {
    struct  pxy nw;   // north west corner inclusive
    struct  pxy se;   // south east corner, usually exclusive
};
typedef struct pxywindow pxywindow_s;
The pxyzwindow struct provides a pair of x, y, z coordinates defining a rectangle in three dimensions:
struct pxyzwindow {
    struct  pxyz nw;  // north west corner inclusive
    struct  pxyz se;  // south east corner, usually exclusive
};
typedef struct pxywindow pxyzwindow_s;

The pximage struct is used as an object[9] defining: (a) An image, (b) The dimensions of the image, (c) A rectangular area of interest, (d) The means of accessing the image, (e) Other parameters for internal use. The pximage must be initialized[10] using a provided function, such as pxd_defineImage or ::initPximage.

The following abstract of the pximage shows some of the fields of interest to the application programmer.

struct pximage {
    struct  pxywindow imdim; // nw.x = nw.y = 0. se.x & se.y is dimension of image
    struct  pxywindow wind;  // subwindow within imdim
        ...         ...
};
typedef struct pximage pximage_s;
The pximage.imdim provides the image's dimensions. The pximage.wind defines an area of interest within the image; the pximage.wind may be directly altered by the application programmer.

Similarly, the pximage3 defines a sequence of images (or depending on point of view, a three-dimensional image), and means of access. The following abstract of the pximage3 shows some of the fields of interest to the application programmer.

struct pximage3 {
    struct  pxyzwindow imdim; // nw.x = nw.y = nw.z = 0. se.x, se.y & se.z is dimension of image
    struct  pxyzwindow wind;  // subwindow within imdim
        ...         ...
};
typedef struct pximage3 pximage3_s;

1.6.2. Imaging Board, Driver, and Video Format Configuration Structures

The structures used for access to and control of the imaging board(s), driver, and Video Format Configuration are listed. Each structure is declared and described in the specified file.

Structure
Name Use File

pxddch Version signatures pxlibvs.h

pxvidstate Video Format Configuration pxlibvs.h
pxvidformat .. substructure pxlibvs.h
pxvidimage .. substructure pxlibvs.h
pxviddim .. substructure pxlibvs.h
pxvidres .. substructure pxlibvs.h
pxvidphys .. substructure pxlibvs.h
pxvidmode .. substructure pxlibvs.h
pxvidopt .. substructure pxlibvs.h
pxvidmem .. substructure pxlibvs.h
pxcamcntl .. substructure pxlibvs.h
xcsv2format .. substructure xclibvs.h
xcsv2mode .. substructure xclibvs.h
xcdxxformat .. substructure xclibvs.h
xcsv7format .. substructure xclibvs.h
xca310format .. substructure xclibvs.h
xca310mode .. substructure xclibvs.h

pxbufstatus Buffer status pxlibsv.h
pxbufstatusfile Buffer status for external file pxlibsv.h
pxdevinfo Driver and board info pxlibsv.h
pxdevfault Logged fault pxlibsv.h
pximagebuf Non-frame image buffer pxlibsv.h
pximage3buf Non-frame image buffers pxlibsv.h
pxtimestamp Time stamp pxlibsv.h
pxtrigspec Trigger specification pxlibsv.h
pxvidstatus Video and capture status pxlibsv.h
xcdevinfo Extended driver and board info xclibsv.h
xcdevparms Driver configuration xclibsv.h
xcvidstatus Extended video and capture status xclibsv.h

xclibs Access to XCLIB services xclibsv.h
pxauxservice .. substructure pxlibsv.h
pxdevservice .. substructure pxlibsv.h
xcdevservice .. substructure pxlibsv.h
xclibservice .. substructure pxlibsv.h

 

 

 

2. Installation and Configuration — Run Time

The following installation instructions are oriented to the application program developer, following installation of the library files, as described above. Application programs intended for distribution to third parties must be provided with the appropriate run time support modules and suitable installation instructions. The entire XCLIB distribution is not required for third parties using application programs, and is normally not licensed for distribution to third parties.

 

2.1. Driver Configuration Parameters

Configuration parameters can be specified in a Driver Configuration Parameter string which is passed to pxd_PIXCIopen, pxe_PIXCIopen, or xclib_open; or, depending upon the run time environment (see below), specified in an alternate manner.

The Driver Configuration Parameter string may contain any of the following parameters, separated by spaces, in any order. Each parameter's flag is followed by a number, whose value is interpreted as hexadecimal if preceded by ''0x'' or ''0X'', octal if preceded by ''0o'' or ''0O'', binary if preceded by ''0b'' or ''0B'', and is otherwise interpreted as decimal.


-BH n
If ≠0, the amount of memory space, in kByte, directly below the 4 GByte address which overlaps other hardware resources such as BIOS, memory mapped I/O, PCI configuration space, etc. and is unavailable to either the operating system or for use as frame buffers.[11] The usable frame buffer memory is therefore reduced by the amount by which the -IA address up to the -IA address plus -IM size overlap the 4 GByte address minus -BH size up to the 4 GByte address. Only used with forceful image frame buffer allocation, under Windows NT, 2000, XP, XP(x64), Vista, Vista(x64), 7, 7(x64), Linux 32 Bit, and Linux 64 Bit. Default: 0.

-BS n
If ≠0, per-frame buffer capture status is maintained. If =0, per-frame buffer capture status is not maintained. Also see the -MU parameter. Default: 1.

-DM n
A bit map selecting which of the PIXCI® imaging boards present should be used. The i'th bit of the bit-map selects the i'th board found, sequentially, on the PCI, PCIe, or ExpressCard bus(es). The relationship between bit i and the order of motherboard slots is motherboard, BIOS, and OS dependent and can not be specified or queried via XCLIB.

For example, 0x01 selects the first board, 0x04 selects the third board, and 0b1001 selects the first and fourth board.

For the PIXCI® E1DB, E4DB, E8DB, ECB2, EL1DB, ELS2, SI2, and SV7 imaging boards which contain two independent functional units within a single physical board, and for the PIXCI® SI4 imaging boards which contain four independent functional units within a single physical board: Under Windows 2000, XP, XP(x64), Vista, Vista(x64), 7, 7(x64), Linux 32 Bit and Linux 64 Bit, each functional unit is handled as an independent imaging board and may be opened and closed independently. Under other operating systems, the first functional unit (i.e. half or quarter) must be opened before latter functional units of the same physical board. A bit map of 0b1101 selects the first half of the first physical PIXCI® E1DB, E4DB, E8DB, ECB2, EL1DB, ELS2, SI2, or SV7 imaging board and both halves of the second physical PIXCI® E1DB, E4DB, E8DB, ECB2, EL1DB, ELS2, SI2, or SV7; 0b11111001 selects the first and fourth quarter of the first physical PIXCI® SI4 imaging board and all quarters of the second physical PIXCI® SI4.

After the library is open, the customary unitmap function parameter selects one or more of the opened boards, not potentially opened boards. Thus, while -DM 0x0A selects opening of the second and fourth PIXCI® imaging boards, valid values of the unitmap would be 0x01 to select the first actually open (second potentially opened), 0x02 to select the second actually open (fourth potentially opened), or 0x03 to select the first and second actually open (second and fourth potentially opened) imaging board(s). Default: 0x01, except under a Windows Plug & Play O.S. where the default is a bitmap of all functional units of the first physical board.


-IA n
If ≠0, the physical address of memory, in kByte, at which image frame buffers are assumed to start. Only used with forceful image frame buffer allocation, under Windows 95, 98, ME, NT, 2000, XP, XP(x64), Vista, Vista(x64), 7, 7(x64), Linux 32 Bit, and Linux 64 Bit. Default: 0.

-IM n
Requested size, in kByte, to be reserved for the entire image frame buffer memory. Default: 32768 kByte under Windows NT, 2000, XP, Vista, and 7, 32768 kByte under Windows XP(x64), Vista(x64), 7(x64) and Linux 64 Bit, 4096 kByte for others.

For the PIXCI® CL3SD and SI2 which have on-board frame buffer memory, memory reserved by this parameter is needed for DMA buffers (approximately 1 MByte). Memory reserved by this parameter is also, optionally, used for support of recording per-frame buffer capture status, i.e. support for pxd_buffersFieldCount, pxe_buffersFieldCount, pxd_buffersSysTicks, pxe_buffersSysTicks, pxd_buffersGPIn, pxe_buffersGPIn, and ::goingBufStatus functions, as specified by the ''-MU'' parameter. Currently, 64 bytes are needed for each frame buffer's capture status. Default: 4096 kByte.


-I2C n
Bit rate of the I2C or other two wire serial bus used within some PIXCI® imaging boards. Specifies an upper bound for the bit rate; actual bit rate is dependent on PC characteristics and is typically slower. Value of 0 selects predefined, board-dependent, default values.

Particularly useful for use with SILICON VIDEO® 1281M, 1281C, 1310, 1310C, 2112, 2112C, 5C10, 5M10, 642M, 642C, 643M, 643C, 9C10, 9M001, 9M001C, 9T001C, 10C6, 10M6, 10C-CL, 10M-CL, WGA-C, and WGA-M cameras; these SILICON VIDEO® camera heads use a I2C or similar two wire serial bus to control camera head features.

Does not affect the serial baud rate of Camera Link compatible imaging boards.

Default: 0.


-LX n
If bit 0x20 is set, a high resolution kernel timer (''do_gettimeofday'') is used for time stamping video events instead of ''jiffies'' and ''HZ''; however, the high resolution timer incurs additional overhead. Only used with Linux 32 Bit and Linux 64 Bit. The new -TI option supercedes this option.

If bit 0x80 is set with non forceful memory allocation, frame buffer memory below 4 GByte is requested; on 64 bit systems with more than 4 GByte of memory, this allows allows use of 32 bit PCI cards. Option is quietly ignored for kernels that don't support the necessary feature(s).

Other bits to be described. Default: 0.


-MB n
If ≠0, the image frame buffer memory, of size specified by ''-IM'', is split into partitions of this size, in kByte. Depending on operating system and ''-IA'' parameters, this may imply that each partition is individually allocated, so that a larger, total amount of memory can be allocated. Or that the contiguous memory is treated as individual partitions for the sake of the operating system and processor's virtual memory management, which could not otherwise ''map'' the entire frame buffer memory at once. In either case, (a) A single frame buffer can't extend across partitions, (b) The partition size should be a multiple of the frame buffer size so as to maximize the number of buffers and minimize wasted space, and (c) A maximum of 256 partitions is supported. Default: 0.

-MH n
If ≠0, the amount of lower memory, in kByte, to pass over before allocating the requested image frame buffer memory. This may be necessary for use with some graphics display (S/VGA) or network interface cards which, a) May be allocating memory later than the PIXCI® driver, and b) May require memory with lower addresses. Only used with non-forceful image frame buffer allocation, under Windows NT, 2000, XP, XP(x64), Vista, Vista(x64), 7, and 7(x64). Default: 0 kByte under Windows NT, 2000, XP, Vista, and 7; 512 kByte under Windows XP(x64), Vista(x64), and 7(x64).

-MO n
Reserved for future use. Default: 0.

-MU n
If bit 0x01 is not set, the frame buffer memory is not mapped directly into the application's address space. If bit 0x02 is set, the frame buffer memory is not permanently mapped into the driver's address space. These options minimize use of the operating systems memory management resources, but may increase overhead in accessing frame buffer memory. These options are typically required when using very large amounts of frame buffer memory (typically, more than 1 or 2 GByte under under Windows NT, 2000, XP, and XP(x64) or more than a few hundred MByte under Windows 95/98/ME), but are not currently supported for all Video Format Configurations.

If bit 0x04 is not set, the frame buffer memory is not cleared after allocation, minimizing delay, particularly when using several GBytes of frame buffer memory.

If bit 0x08 is not set, a portion of frame buffer memory is reserved for recording each per-frame buffer's capture status, such as stamping the time of capture. Use of frame buffer memory for capture status may not be supported when using forceful image frame buffer allocation. If bit 0x08 is set, memory is allocated dynamically from the operating system for recording each frame buffer's capture status. The amount of space reserved, or the amount of space allocated, is proportional to the number of frame buffers. The dynamic memory allocation option is not available under Windows 95, 98, or ME; and the per-frame buffer status is discarded upon closing the PIXCI® imaging board(s).

If bit 0x20 is not set, a portion of frame buffer memory is reserved for serial data buffers used in conjunction with Camera Link serial communication. (For the PIXCI® CL3SD which has on-board frame buffer memory, a small static buffer is used in place of frame buffer memory). If bit 0x20 is set, memory is allocated dynamically from the operating system for serial data buffers. The dynamic memory allocation option is not available under Windows 95, 98, or ME.

Default: 0x01 under Windows 95, 98, ME. 0x28 under Linux 32 Bit and Linux 64 Bit. 0x29 under Windows NT, 2000, XP, XP(x64), Vista, Vista(x64), 7, 7(x64).


-PO n
If ≠0, the polling period, in µseconds, for driver features that are not driven by an interrupt. Ignored under Tenberry DOS4GW DOS extender. Default: 5000 µseconds.

-QP n
The XCLIB library normally installs a bimodal interrupt handler so that XCLIB interrupts are handled in both real and protected modes. The Tenberry DOS4GW DOS extender included with Watcom C/C++ does not have all of the features (DPMI services) required by XCLIB, the Tenberry DOS4GW Professional DOS extender must be used. Alternately, if ≠0, an assigned auxiliary interrupt number (not IRQ number!) within Tenberry's range of auto pass-up interrupts: 0x08 to 0x2E. Only used with the Tenberry DOS4GW DOS extender. Default: 0.

-QS n
If ≠0, allow sharing the imaging boards' assigned hardware interrupt with other devices. Ignored under Tenberry DOS4GW DOS extender and Linux. Default: 1.

-QU n
If ≠0, utilize the imaging boards' hardware interrupts. For PIXCI® A, A310, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, SI4, SV4, SV5, SV5A, SV5B, SV5L, and SV7 imaging boards, the interrupt may be disabled if the polling period (-PO) is small relative to a field's period. For PIXCI® SV2 and SV3, disabling the interrupt will adversely affect all capture modes other than snap. For PIXCI® D, D24, and D32, the interrupt may be disabled only if the interrupt is not shared. For all PIXCI® imaging boards operated under Tenberry DOS4GW DOS extender, use of hardware interrupts is required. Disabling use of interrupts is intended primarily for diagnosing interrupt conflicts, and is not recommended. Default: 1.

-SM n
Total amount of memory, in kByte, on the computer system. This parameter and value is currently ignored by the PIXCI® driver, but used by XCAP's Driver Assistant in conjunction with -IM and -IA to note the ''context'' under which the -IM and -IA values were set.

Default: 0.


-XM n
If ≠0, reserve the proportionate share of image frame buffer memory for imaging boards not opened by the first application, for use with other imaging boards opened later. If 0, all image frame buffer memory is shared amongst the imaging boards opened by the first application. Affects PIXCI® imaging boards other than CL3SD and SI2, which have on-board frame buffer memory. Default: 1.

-SV5 n
Setting bit 0x02 enables compatibility with 430FX PCI controllers. Setting bit 0x04 enables compatibility with VIA/SIS PCI controllers. Only used with PIXCI® SV5, SV5A, SV5B, SV5L. Default: 0.

-TI n
If =0, time stamping video events is disabled.

Under Linux: If =1, the ''jiffies'' and ''HZ'' are used for time stamping video events. If =2, the high resolution kernel timer (''do_gettimeofday'') is used for time stamping video events.

Under Windows 95, 98, and ME: If =1, the ''Get_Last_Updated_System_Time'' is used for time stamping video events.

Under Windows NT: If =1, the ''KeQuerySystemTime'' is used for time stamping video events.

Under Windows 2000, XP, XP(x64), Vista, Vista(x64), 7, 7(x64): If =1, the ''KeQuerySystemTime'' is used for time stamping video events. If =2, the ''KeQueryPerformanceCounter'' is used for time stamping video events. If =3, the ''KeQueryInterruptTime'' is used for time stamping video events. If =4, the ''KeQueryTickCount'' is used for time stamping video events.

Each option has various advantages and disadvantages, as described by the operating system's documentation. Default: For backward compatiblity, time stamping as per -WT or -LX is used.


-WT n
If bits 0x05 are set to 0x01 or to 0x05, alternate methods of Windows NT resource allocation are used, avoiding problems seen on some motherboards where the same resources are assigned to multiple imaging boards. Only used with Windows NT.

If bit 0x20 is set, a high resolution kernel timer is used for time stamping video events. Windows documentation states that use of this timer incurs additional overhead. Only used with Window NT, 2000, XP, XP(x64), Vista, Vista(x64), 7, and 7(x64). The new -TI option supercedes this option.

If bit 0x80 is set, frame buffer memory below 4 GByte is requested; on 64 bit systems with more than 4 GByte of memory, this allows allows use of 32 bit PCI cards, and/or allows allows use of 32 bit applications.

Other bits to be described. Default: 0x20.


-XU n
If ≠0, allow other applications to share use of imaging boards previously opened for use by the first application. Not supported under Windows 95, 98, ME: Default: 0. Supported under Windows NT, 2000, XP, XP(x64), Vista, Vista(x64), 7, and 7(x64): Default: 1. Supported under Linux: Default: 0. Not supported under Tenberry DOS4GW DOS: Default: 0.

 

2.2. Windows 95, 98, ME Environment

The EPIXXCW5.VXD driver, the XCLIBW95.DLL, and the PXIPLW95.DLL if the PXIPL Image Processing Library is used, must be installed in order to operate any application program using XCLIB.

Typically, XCAP is used to install the driver, specify frame buffer memory allocation, specify other Driver Configuration Parameters, and verify proper operation; these settings are then available to the application using the XCLIB library. The options in XCAP's:

    PIXCI
    PIXCI Open/Close
    Advanced
directly correspond to the Driver Configuration Parameters. Alternately, the details of manual installation of the EPIXXCW5.VXD driver and specification of frame buffer memory allocation, are described in the XCAP Reference Manual and also the PIXCI® User's Manual.

Driver Configuration Parameters may be specified in the Windows' SYSTEM.INI file:

[EPIX_XC]
PIXCI=<DriverConfigurationParameters>
Windows must be rebooted for the new specification to take effect.

The ''-IA'', ''-IM'', ''-MH'', and ''-MB'' parameters are effective only when specified in SYSTEM.INI, and can't be specified with pxd_PIXCIopen, pxe_PIXCIopen, or xclib_open.

The XCLIBW95.DLL, and the PXIPLW95.DLL if the PXIPL Image Processing Library is used, must be available in order to operate any application program using XCLIB, such as by placing the DLL(s) in the same directory as the application program, or by placing the DLL(s) in the Windows directory.

Frame buffer memory is allocated once during Windows initialization; the contents of frame buffer memory is retained as the driver is closed and opened, but lost if Windows is restarted.

Video events are time stamped with the system time (i.e. Get_Last_Updated_System_Time), in 1 millisecond units with a resolution of approximately 50 milliseconds.

 

2.3. Windows NT, 2000, XP, XP(x64), Vista, Vista(x64), 7, 7(x64) Environment

The EPIXXCWT.SYS driver for Windows NT, or the EPIXXCW2.SYS driver for Windows 2000, XP, Vista, and 7, or the EPIXXCW6.SYS driver for Windows XP(x64), Vista(x64), and 7(x64), must be installed in order to operate any application program using XCLIB. The XCLIBWNT.DLL and the PXIPLWNT.DLL (if the PXIPL Image Processing Library is used) must be installed in order to operate a 32 bit application program using XCLIB under Windows NT, 2000, XP, Vista, 7, XP(x64), Vista(x64), and 7(x64). The XCLIBW64.DLL and the PXIPLW64.DLL (if the PXIPL Image Processing Library is used) must be installed in order to operate a 64 bit application program using XCLIB under Windows XP(x64), Vista(x64), and 7(x64).

Typically, XCAP is used to install the driver, specify frame buffer memory allocation, specify other Driver Configuration Parameters, and verify proper operation; these settings are then available to application using the XCLIB library. The options in XCAP's:

    PIXCI
    PIXCI Open/Close
    Advanced
directly correspond to the Driver Configuration Parameters. Alternately, the details of manual installation of the EPIXXCWT.SYS, EPIXXCW2.SYS, EPIXXCW6.SYS driver and specification of frame buffer memory allocation, are described in the XCAP Reference Manual and also the PIXCI® User's Manual.

Driver Configuration Parameters may be specified in the Windows NT registry:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EPIXXCWT
    PIXCI   =  <DriverConfigurationParameters>
or the Windows 2000, XP, Vista, and 7 registry:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EPIXXCW2
    PIXCI   =  <DriverConfigurationParameters>
or the Windows XP(x64), Vista(x64), and 7(x64) registry:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EPIXXCW6
    PIXCI   =  <DriverConfigurationParameters>
Within the registry entry, the ''Value'' named ''PIXCI'' must be of type string (i.e. ''REG_SZ''). Windows must be rebooted for the new specification to take effect.

The ''-IA'', ''-IM'', ''-MH'', ''-MB'', and ''-BH'' parameters are effective only when specified in the Windows registry, and can't be specified with pxd_PIXCIopen, pxe_PIXCIopen, or xclib_open.

The XCLIBWNT.DLL and the PXIPLWNT.DLL (if the PXIPL Image Processing Library is used) for 32 bit applications, or the XCLIBW64.DLL and the PXIPLW64.DLL (if the PXIPL Image Processing Library is used) for 64 bit applications, must be available in order to operate any application program using XCLIB, such as by placing the DLL(s) in the same directory as the application program, or by placing the DLL(s) in the Windows directory.

Frame buffer memory is allocated once during Windows initialization; the contents of frame buffer memory is retained as the driver is closed and opened, but lost if Windows is restarted.

Video events are time stamped using one of several system timers, as selected by the Driver Configuration Parameters. If KeQuerySystemTime is selected, the units are 100 nanosecond with resolution of approximately 10 milliseconds. If KeQueryPerformanceCounter is selected, the units and resolution are dependent on the host computer. If KeQueryInterruptTime is selected, the units are 100 nanosecond with resolution dependent upon the host computer. If KeQueryTickCount is selected, the units and resolution are dependent on the host computer.

 

2.4. Tenberry DOS4GW DOS Extender Environment

No run time module is needed for execution of application programs in the Watcom/DOS4GW environment.

It is suggested that EMM386.SYS be removed from C:\CONFIG.SYS and not be used with XCLIB, as it significantly slows hardware interrupts. Also, according to the manufacturer of DOS4GW, some versions of EMM386.SYS have bugs that affect the operation of DOS4GW.

Frame buffer memory is allocated when pxd_PIXCIopen, pxe_PIXCIopen, or xclib_open is invoked; the contents of frame buffer memory is lost when XCLIB is closed.

Video events are time stamped with the system time, which is in 54.94 millisecond (i.e. 1/18.2 Hz) units with the same resolution.

 

2.5. Linux 32 Bit & Intel i386 Environment

The ''pixci_i386.o'' (for 2.4 kernels) or ''pixci_i386.ko'' (for 2.6 kernels) loadable driver must be installed by insmod in order to operate any application program using XCLIB.

Driver Configuration Parameters may be specified as an option to insmod, by assignation to module parameter ''PIXCIPARM'', such as:

    insmod -o pixci [ -force ] pixci_i386.o  [ PIXCIPARM=<driver_config_parameters> ]
or
    insmod pixci_i386.ko [ PIXCIPARM=<driver_config_parameters> ]
Some versions of insmod under 2.6 kernels object to quoted spaces in the Driver Configuration Parameters; an underscore (i.e. ''_'') may be used instead of a space.

The ''-IA'', ''-IM'', ''-BH'', and ''-MB'' parameters are effective only when specified with insmod, and can't be specified with pxe_PIXCIopen, pxe_PIXCIopen, or xclib_open.

Frame buffer memory is allocated when the ''pixci_i386.o'' or ''pixci_i386.ko'' is loaded; the contents of frame buffer memory is lost when ''pixci_i386.o'' or ''pixci_i386.ko'' is unloaded.

Video events are time stamped using one of two system timers, as selected by the Driver Configuration Parameters. If jiffies and HZ are selected, the system time units are dependent on the Linux version and host computer; for common 2.4 and 2.6 kernels on a PC, the system time is in 10 millisecond units with the same resolution. If the high resolution do_gettimeofday is selected, the units are 1 microsecond, with resolution dependent on the host computer.

 

2.6. Linux 64 Bit & Intel x86-64 Environment

The ''pixci_x86_64.ko'' (for 2.6 kernels) loadable driver must be installed by insmod in order to operate any application program using XCLIB.

Driver Configuration Parameters may be specified as an option to insmod, by assignation to module parameter ''PIXCIPARM'', such as:

    insmod pixci_x86_64.ko [ PIXCIPARM=<driver_config_parameters> ]
Some versions of insmod under 2.6 kernels object to quoted spaces in the Driver Configuration Parameters; an underscore (i.e. ''_'') may be used instead of a space.

The ''-IA'', ''-IM'', ''-BH'', and ''-MB'' parameters are effective only when specified with insmod, and can't be specified with pxd_PIXCIopen, pxe_PIXCIopen, or xclib_open.

Frame buffer memory is allocated when the ''pixci_x86_64.ko'' is loaded; the contents of frame buffer memory is lost when ''pixci_x86_64.ko'' is unloaded.

Video events are time stamped using one of two system timers, as selected by the Driver Configuration Parameters. If jiffies and HZ are selected, the system time units are dependent on the Linux version and host computer; for common 2.4 and 2.6 kernels on a PC, the system time is in 10 millisecond units with the same resolution. If the high resolution do_gettimeofday is selected, the units are 1 microsecond, with resolution dependent on the host computer.


 

 

 

3. SCF Style Interface

The so-called Simple ``C'' Function Style Interface provides sufficient services for most common applications using a single imaging board, or using multiple, identical, imaging boards, or using one or more identical imaging boards each with multiple functional units.

The SCF style interface differs from the Structured Interface Functions in several regards. First, the SCF functions do not (explicitly) use structures and minimize the use of pointers. These functions can be easily used by casual ``C'' programmers, and invoked from languages other than ``C'', such as Visual Basic, VB.NET, Borland Delphi, LabView, Matlab, or any other Windows programming environment that allows calling an arbitrary function in an arbitrary DLL. In contrast, the Structured functions provide a ''structured'' and ''object oriented'' interface, providing an alternate API for advanced C/C++ programmers.

Second, the SCF functions do not allow low level changes to the video format configuration. Rather, the video format configuration is either chosen from the predefined selections, or loaded from a video format file,[12] previously saved by the XCAP application. In contrast, the Structured functions provide full access to all of the dozens of parameters with which the video format configuration can be customized.

Third, while the SCF functions support multiple imaging boards, or imaging boards with multiple functional units, the boards or units must be identical. In contrast, the Structured functions support multiple identical imaging boards and functional units with independent video format and resolution, or by opening multiple instances of the library the Structured functions support access to multiple, non-identical, imaging boards.[13]

Fourth, the SCF functions share common names with libraries for other families of EPIX, Inc. imaging boards. This allows easier porting of application programs from one board family to another, but complicates using boards from both families within the same program. In contrast, the Structured functions do not share common names with libraries for other families of EPIX, Inc. imaging boards, requiring additional editing of source code when porting the application program.

The SCF functions are not intended to be used in conjunction with Structured functions; though upon advice of EPIX, Inc, Technical Support, the pxd_xclibEscape and pxd_xclibEscaped functions can be used in special circumstances.[14]

The source for many of the SCF function ''wrappers'' for programmers wishing to understand their manner of implementation in terms of the Structured functions, is available from EPIX, Inc. Technical Support.


Set A/D Gain and Offset --- pxd_setAdcGainOffset
Set A/D Gains and Offsets --- pxd_setAdcColorGainOffsets
Get A/D Gain A --- pxd_getAdcGainA
Get A/D Gain B --- pxd_getAdcGainB
Get A/D Color Gains A --- pxd_getAdcGainsA
Get A/D Color Gains B --- pxd_getAdcGainsB
Get A/D Color Gains A --- pxd_getAdcOffsetsA
Get A/D Color Gains B --- pxd_getAdcOffsetsB
Get A/D Color Offsets A --- pxd_getAdcOffsetA
Get A/D Color Offsets B --- pxd_getAdcOffsetB



Summary
int     pxd_setAdcGainOffset(unitmap,rsvd,gainA,offsetA,gainB,offsetB);
int     pxd_setAdcColorGainOffsets(unitmap,rsvd,gainsA,gainsB,offsetsA,offsetsB);
double  pxd_getAdcGainA(unitmap);
double  pxd_getAdcGainB(unitmap);
int     pxd_getAdcGainsA(unitmap,gainsA);
int     pxd_getAdcGainsB(unitmap,gainsB);
int     pxd_getAdcOffsetsA(unitmap,offsetsA);
int     pxd_getAdcOffsetsB(unitmap,offsetsB);
double  pxd_getAdcOffsetA(unitmap);
double  pxd_getAdcOffsetB(unitmap);

int unitmap; // Unit selection bit map (1 for single unit) int rsvd; // Reserved, should be 0 double gainA; // Pre-gain, dB. double gainB; // Post-gain, dB. double offsetA; // Pre-offset, scaled to 1.0 for max pixel value double offsetB; // Post-offset, scaled to 1.0 for max pixel value double[4] gainsA; // Color specific A-gains, Gb/B/R/Gr, dB, or NULL double[4] gainsB; // Color specific B-gains, Gb/B/R/Gr, dB, or NULL double[4] offsetsA; // Color specific A-offsets, Gb/B/R/Gr, // scaled to 1.0 for max pixel value, or NULL double[4] offsetsB; // Color specific B-offsets, Gb/B/R/Gr, // scaled to 1.0 for max pixel value, or NULL



Description

The pxd_setAdcGainOffset and pxd_setAdcColorGainOffsets sets gain and offsets (black level) of the analog to digital converter of selected PIXCI® imaging boards.

The per-color A-gain for green-next-to-blue, blue, red, and green-next-to-red is set to gainsA[0], gainsA[1], gainsA[2], and gainsA[3] dB, respectively. For A/D converters that do not implement per-color A-gain, the gain is set to the average of gainsA[0], gainsA[1], gainsA[2], and gainsA[3]. For A/D converters that only provide color A-gain for red, green, and blue the gains are set to gainsA[2], gainsA[1], and the average of gainsA[0] and gainsA[3], respectively. Alternately, the A/D converter's A-gain(s), whether providing per-color gains or not, are each set to gainA dB.

The A/D converter's per-color, or non-per-color B-gain is set to gainsB and/or gainB, dB. following the same conversion rules for per-color vs non-per-color A/D converters as above.

The A/D converter's per-color, or non-per-color A-offset (black level) is set to offsetsA and/or offsetA, following the same conversion rules for per-color vs non-per-color A/D converters as above. The A/D converter's per-color, or non-per-color B-offset (black level) is set to offsetsB and/or offsetB, following the same conversion rules for per-color vs non-per-color A/D converters as above. The offsetsA, offsetA, offsetsB, and offsetB are interpreted such that increased values of offset cause increased pixel values, and are scaled such that an offset of 1.0 or -1.0 corresponds to the maximum pixel value or its negative. However, the A/D converters of the various PIXCI® imaging boards do not necessarily provide the full range of offsets.

Each of the gainsA, gainsB, offsetsA, and offsetsB may be NULL; the A/D converter's corresponding gain or offset is unchanged.

Some A/D converters may not provide A-gain, B-gain, A-offset, or B-offset; the corresponding values are ignored. Any invalid gain or offset value is corrected to the nearest valid value.

The pxd_getAdcGainA returns the current A-gain, in dB. For A/D converters with per-color A-gain, the average value is returned. The pxd_getAdcGainsA ''returns'' the current per-color A-gain, in dB in gainsA. For A/D converters without per-color A-gain, the four elements of gainsA are set to the gain. For A/D converters with per-color red, green, and blue gain, the gainsA[0] and gainsA[3] are both set to the green gain.

The pxd_getAdcGainB returns the current B-gain, in dB; the pxd_getAdcGainsB ''returns'' the current per-color B-gain, in dB in gainsB; following the same conversion rules for per-color vs non-per-color A/D converters as above.

The pxd_getAdcOffsetA returns the current A-offset; the pxd_getAdcOffsetsA ''returns'' the current per-color A-offset, in offsetsA; the pxd_getAdcOffsetB returns the current B-offset; the pxd_getAdcOffsetsB ''returns'' the current per-color B-offset, in offsetsB; following the same conversion rules for per-color vs non-per-color A/D converters as above, all scaled such that an offset of 1.0 or -1.0 corresponds to the maximum pixel value or its negative.

Some A/D converters may not provide A-gain, B-gain, A-offset, and/or B-offset; a value of 0 is returned.

Note: The relative order of the gain and offset parameters differ between pxd_setAdcGainOffset and pxd_setAdcColorGainOffsets. It is not a typographical error.


Model Specific. For PIXCI® A310: The imaging board provides per-color analog A-gain in the range of 0.0 to 6.02 dB, per-color analog A-offset in the range of -124/1024 to 124/1024, per-color digital B-gain in the range of 0.0 to 6.00 dB, and per-color digital B-offset in the range of -512/1024 to 511/1024. Each provides red, green, and blue gain or offset.


Returns

The pxd_getAdcGainA, pxd_getAdcGainB, pxd_getAdcOffsetA, and pxd_getAdcOffsetB returns values as described above, or 0 if the library is not open for use, or the wrong imaging board is in use.

The remaining functions return:


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Buffer's Capture Field Count --- pxd_buffersFieldCount
Buffer's Capture General Purpose Input --- pxd_buffersGPIn
Buffer's Capture System Time --- pxd_buffersSysTicks
Buffer's Capture System Time --- pxd_buffersSysTicks2



Summary
pxvbtime_t pxd_buffersFieldCount(unitmap, buffer);
int        pxd_buffersGPIn(unitmap, buffer);
uint32     pxd_buffersSysTicks(unitmap, buffer);
int        pxd_buffersSysTicks2(unitmap, buffer, ticks);

int unitmap; // Unit selection bit map (1 for single unit) pxbuffer_t buffer; // Image frame buffer uint32 ticks[2]; // System time



Description

Information about the specified, captured, frame buffer is returned.

The pxd_buffersFieldCount returns the video field count when the specified frame buffer was captured, on the single unit specified by unitmap. The field count is initialized to 0 when pxd_PIXCIopen is invoked, and (typically, but dependent upon imaging board) counts all video fields, whether captured or not.

The pxd_buffersGPIn returns the value(s) of the general purpose input signal(s), if any, when the specified frame buffer was captured. The return value is in the same imaging board dependent format as for pxd_getGPIn. For the PIXCI® SV2 and SV3 imaging boards, the pxd_buffersGPIn is not available and always returns 0.

The pxd_buffersSysTicks returns the low 32 bits of the system time when the specified frame buffer was captured,[15] on the single unit specified by unitmap. The pxd_buffersSysTicks2 ''returns'' the low and high 32 bits of the system time in ticks[0] and ticks[1], respectively, when the specified frame buffer was captured,[15] on the single unit specified by unitmap.

The return values of the pxd_buffersFieldCount, pxd_buffersGPIn, and pxd_buffersSysTicks functions, and the ''returned'' contents of ticks for pxd_buffersSysTicks2, is undefined if the specified frame buffer has not yet been captured, or if the Video Format Configuration has been changed thereby causing frame buffer memory to be reorganized.

Capture status information may not stored for each frame buffer, depending on frame buffer memory configuration such as use of forceful memory allocation and/or the ''-MU'' flag as described in Driver Configuration Parameters.


Returns

As described above. The pxd_buffersFieldCount, pxd_buffersGPIn, and pxd_buffersSysTicks return 0 if the library is not open or the feature is not available. The pxd_buffersSysTicks2 returns:


0
Function performed.

PXERNOTOPEN
The library is not open for use.

PXER...
Other error codes as appropriate.



See Also

See pxd_capturedFieldCount, pxd_capturedSysTicks, and pxd_getGPIn which provide similar information if invoked in a timely manner, and are supported for all PIXCI® imaging boards and Driver Configuration Parameters. See pxd_infoSysTicksUnits for the units and scaling of the pxd_buffersSysTicks and pxd_buffersSysTicks2.


Camera Link CC Output Signal: Set --- pxd_setCameraLinkCCOut
Camera Link CC Output Signal: Get --- pxd_getCameraLinkCCOut



Summary
int  pxd_setCameraLinkCCOut(unitmap, setoutdata);
int  pxd_getCameraLinkCCOut(unitmap, getoutdata);

int unitmap; // Unit selection bit map (1 for single unit) int setoutdata; // Binary value(s) to set, bit value 0x1 for CC1, // bit value 0x2 for CC2, etc. int getoutdata; // Reserved. Should be 0



Description

The pxd_setCameraLinkCCOut sets the current value of the Camera Link CC output signals to setoutdata, for those CC lines which are not otherwise in use for video control, as specified in the video format. Both for historical reasons and to be conservative, video formats typically reserve all of the CC lines to be used for video control so as to avoid accidental interference with video. Changes via pxd_setCameraLinkCCOut take effect immediately; changes are not synchronized to horizontal or vertical video timing.

The pxd_getCameraLinkCCOut gets the current value of the Camera Link CC output signals returning a value in the same format as the setoutdata parameter of pxd_setCameraLinkCCOut. For CC lines which remain under video control, the returned bits of pxd_getCameraLinkCCOut are undefined. The getoutdata is ignored.

For pxd_getCameraLinkCCOut the unitmap specifies the single unit for which the Camera Link CC output signals are sensed. For pxd_setCameraLinkCCOut the unitmap specifies the multiple units for which the Camera Link CC output signals are set.

The pxd_setCameraLinkCCOut and pxd_getCameraLinkCCOut are not available for use with the PIXCI® CL1 and CL3SD imaging boards, nor for PIXCI® imaging boards which do not support Camera Link. For most, if not all, PIXCI® imaging boards, the pixel clock from the camera must be present for the state of the Camera Link CC lines to change.


Returns

The pxd_getCameraLinkCCOut return values as described above, and may also return:


PXERNOTOPEN
The library is not open for use.

PXER...
Other error codes as appropriate.

The pxd_setCameraLinkCCOut returns:


0
Function performed.

PXERNOTOPEN
The library is not open for use.

PXER...
Other error codes as appropriate.

Last Captured Buffer: Buffer Number --- pxd_capturedBuffer
Last Captured Buffer: Field Count --- pxd_capturedFieldCount
Last Captured Buffer: System Time --- pxd_capturedSysTicks



Summary
pxbuffer_t pxd_capturedBuffer(unitmap);
pxvbtime_t pxd_capturedFieldCount(unitmap);
uint32     pxd_capturedSysTicks(unitmap);

int unitmap; // Unit selection bit map (1 for single unit)



Description

Information about the last captured frame buffer is returned.

The pxd_capturedBuffer returns the buffer number into which the last frame was captured, on the single unit specified by unitmap.

The pxd_capturedFieldCount returns the video field count when the last frame was captured, on the single unit specified by unitmap. The field count is initialized to 0 when pxd_PIXCIopen is invoked, and (typically, but dependent upon imaging board) counts all video fields, whether captured or not.

The pxd_capturedSysTicks returns the low 32 bits of the system time when the last frame was captured,[16] on the single unit specified by unitmap.


Returns

As described above. All functions return 0 if the library is not open for use or no frame has even been captured since the library was opened.


See Also

See pxd_buffersFieldCount and pxd_buffersSysTicks which provide similar information saved on a per buffer basis, rather than having to be retrieved before another video frame is captured. See pxd_infoSysTicksUnits for the units and scaling of the pxd_capturedSysTicks.


Get PXIMAGE: Access Imaging Board Frame Buffer --- pxd_defineImage
Get PXIMAGE3: Access Imaging Board Frame Buffers --- pxd_defineImage3
Get PXIMAGE: Access Imaging Board Frame Buffer --- pxd_definePximage
Get PXIMAGE3: Access Imaging Board Frame Buffers --- pxd_definePximage3
Get PXIMAGE: Release Access to Imaging Board Frame Buffers --- pxd_definePximageFree
Get PXIMAGE3: Release Access to Imaging Board Frame Buffers --- pxd_definePximage3Free



Summary
struct pximage  * pxd_defineImage (unitmap, framebuf, ulx, uly, lrx, lry, colorspace);
struct pximage3 * pxd_defineImage3(unitmap, startbuf, endbuf, ulx, uly, lrx, lry, colorspace);

struct pximage * pxd_definePximage (unitmap, framebuf, ulx, uly, lrx, lry, colorspace); struct pximage3 * pxd_definePximage3(unitmap, startbuf, endbuf, ulx, uly, lrx, lry, colorspace); void pxd_definePximageFree(image); void pxd_definePximage3Free(image3)

int unitmap; // Unit selection bit map (1 for single unit) pxbuffer_t framebuf; // Image frame buffer pxcoord_t ulx; // Upper left x coord. of area of interest pxcoord_t uly; // Upper left y coord. of area of interest pxcoord_t lrx; // Lower right x coord. exclusive of AOI pxcoord_t lry; // Lower right y coord. exclusive of AOI char *colorspace; // Name of requested color representation
pxbuffer_t startbuf; // First image frame buffer pxbuffer_t endbuf; // Last image frame buffer
struct pximage image; // Image access to be released struct pximage3 image3; // Image access to be released



Description

A reference to an image frame buffer and an area of interest within the image frame buffer, or a reference to a sequence of image frame buffers and an area of interest within each image frame buffer, is constructed and returned.

These functions are useful for constructing a reference which specifies an image frame buffer and an area of interest for use with other library functions, in particular functions in the PXIPL Image Processing Library, which expect a ''struct pximage *'' or ''struct pximage3 *'', to specify image access, and where the programmer prefers to avoid the (explicit) use of structures and pointers.

The unitmap specifies the single unit to be accessed. For pxd_defineImage, the framebuf, where 1<=framebuf<=pxd_imageZdim(), specifies the image frame buffer to be accessed. For pxd_defineImage3, the startbuf and endbuf, where startbuf<=endbuf, 1<=startbuf<=pxd_imageZdim(), and 1<=endbuf<=pxd_imageZdim(), specify the first and last, inclusively, image frame buffer to be accessed. The ulx and uly respectively specify the horizontal (x) and vertical coordinate (y) of the upper left corner of an area of interest in the frame buffer to be used. The lrx and lry respectively specify a value one greater than the horizontal and vertical coordinate of the lower right corner of an area of interest in the frame buffer (i.e. an exclusive corner point) to be used. The lrx and lry may each be abbreviated to -1 to specify the extreme right horizontal coordinate (i.e. pxd_imageXdim) or the extreme bottom vertical coordinate (i.e. pxd_imageYdim), respectively.

The colorspace specifies the color space and color component(s) in which the image frame buffer(s) are to be accessed. Valid choices are:

colorspace Number of Components Color Representation

"Default" ? Image frame buffer's default representation,
typically Grey, RGB, BGR, or YCrCb.

"Display" ? Optimum representation for display purposes,
typically Grey, RGB, BGR, RGBx, or BGRx.

"RGB" 3 Red, Green, Blue
"RofRGB" 1 Red
"GofRGB" 1 Green
"BofRGB" 1 Blue
"BGR" 3 Blue, Green, Red (RGB reordered)
"BofBGR" 1 Blue
"GofBGR" 1 Green
"RofBGR" 1 Red
"BSH" 3 Brightness, Saturation, Hue (HSB reordered)
"BofBSH" 1 Brightness
"SofBSH" 1 Saturation
"HofBSH" 1 Hue
"RGBx" 4 Red, Green, Blue, Pad
"RofRGBx" 1 Red
"GofRGBx" 1 Green
"BofRGBx" 1 Blue
"BGRx" 4 Blue, Green, Red, Pad (RGB reordered)
"BofBGRx" 1 Blue
"GofBGRx" 1 Green
"RofBGRx" 1 Red
"Grey" 1 Grey Scale
"GREY" 1 Grey Scale (alternate spelling for "Grey")
"Gray" 1 Grey Scale (alternate spelling for "Grey")
"GRAY" 1 Grey Scale (alternate spelling for "Grey")
"YCrCb" 3 Intensity, Red Chroma, Blue Chroma
"YofYCrCb" 1 Intensity
"RofYCrCb" 1 Red Chroma
"BofYCrCb" 1 Blue Chroma
"YCrCbX" 4 Intensity, Red Chroma, Blue Chroma, Pad
"YofYCrCbX" 1 Intensity
"RofYCrCbX" 1 Red Chroma
"BofYCrCbX" 1 Blue Chroma
"Bayer" 1 Raw Bayer Pattern Values
"CbYCrY" 2 UYVY (Blue & Intensity, Red & Intensity)
"CMY" 3 Cyan, Magenta, Yellow
"CofCMY" 1 Cyan
"MofCMY" 1 Magenta
"YofCMY" 1 Yellow

The ''BGRx'' selection, when read into a ''uchar'' buffer on Intel machines with little-endian architecture (i.e. least significant byte of multi-byte word has lowest address), with the buffer typecast to the Windows ''COLORREF'' type, results in pixels that are compatible with Windows' RGB() data type.

The ''Bayer'' selection is available only in conjunction with cameras that actually output raw Bayer pattern values, and where the XCLIB library would otherwise be responsible for converting the values to RGB(x) or BGR(x).

The ''CbYCrY'' selection is available only in conjunction with imaging boards that actually capture CbYCrY (UYVY) values, and where the XCLIB library would otherwise be responsible for converting the values to RGB(x), BGR(x), or YCrCb.

The ''Display'' selection chooses an optimum color representation for use with pxio8_GDIDisplay and similar display functions (in the PXIPL Image Processing Library), and is dependent upon the camera, video format configuration, and current graphics display system (S/VGA card).

For ease of use, the pxd_defineImage and pxd_defineImage3 return ''struct pximage *'' or ''struct pximage3 *'' that need not (and must not) be free'ed. Instead, pxd_defineImage and pxd_defineImage3 provide references to a limited number of statically allocated structures. The limit is sufficient to support the convenient use of any library function in the manner shown in the example below; invoking pxd_defineImage or pxd_defineImage3 as ''in-line'' functions. The returned ''struct pximage *'' or ''struct pximage3 *'' should not be assigned to a pointer variable and used repeatedly.

In contrast, the pxd_definePximage and pxd_definePximage3 return a ''struct pximage *'' or ''struct pximage3 *'' that after use must be released via pxd_definePximageFree or pxd_definePximage3Free, respectively. The pxd_definePximage and pxd_definePximage3 alternatives are appropriate when accessing the library from a multi-threaded environment, or when the programmer chooses to assign the return values to a pointer variable for repeated use. The pxd_definePximage and pxd_definePximage3 creates a copy of the image access structures in malloc'ed memory, but does not copy the image contents; each use of the returned ''struct pximage *'' or ''struct pximage3 *'' accesses the current contents of the frame buffer.

The XCLIB-Lite library does not support this feature.


Returns

As described above.

Returns NULL if the library is not open for use, if the XCLIB-Lite library is being used, if the colorspace or other parameter is invalid, or for pxd_definePximage and pxd_definePximage3 if memory could not be malloc'ed.


Example

Consider the typical image processing library function pxip8_pixand, which should be invoked as:

int pxip8_pixand(abortp, sip, dip, mask);
pxabortfunc_t   **abortp;   // premature termination function, or NULL
struct  pximage *sip;       // source
struct  pximage *dip;       // destination
int     mask;               // and mask
The following invokes this library function, operating on the upper left quadrant of image frame buffer 1 and placing the result in the lower right quadrant of image frame buffer 2, without explicitly using structures or pointers.
int xdim, ydim;

xdim = pxd_imageXdim(); ydim = pxd_imageYdim(); pxip8_pixand(NULL, // no abort pxd_defineImage(1, 1, 0, 0, xdim/2, ydim/2, "Default"), pxd_defineImage(1, 2, xdim/2, ydim/2, xdim, ydim, "Default"), 0xC0 ); // chosen mask value

Consider the typical image processing library function pxio8_tifwriteseq, which saves a sequence of images. It may be invoked as:

pxio8_tifwriteseq(NULL,
                  pxd_defineImage3(1, 1, pxd_imageZdim(), 0, 0, -1, -1, "Default"),
                  NULL, "test.tif", 8, 0, 0, NULL);
to save the entire AOI of all image frame buffers.
Windows: Register Event upon Video Field --- pxd_eventFieldCreate
Windows: Register Event upon Video Field --- pxd_eventFieldCreate2
Windows: Unregister Event upon Video Field --- pxd_eventFieldClose
Windows: Register Event upon Captured Video Field --- pxd_eventCapturedFieldCreate
Windows: Register Event upon Captured Video Field --- pxd_eventCapturedFieldCreate2
Windows: Unregister Event upon Captured Video Field --- pxd_eventCapturedFieldClose
Windows: Register Event upon General Purpose Trigger --- pxd_eventGPTriggerCreate
Windows: Register Event upon General Purpose Trigger --- pxd_eventGPTriggerCreate2
Windows: Unregister Event upon General Purpose Trigger --- pxd_eventGPTriggerClose
Windows: Register Event upon Fault --- pxd_eventFaultCreate
Windows: Register Event upon Fault --- pxd_eventFaultCreate2
Windows: Unregister Event upon Fault --- pxd_eventFaultClose
Windows: Register Event upon Serial --- pxd_eventSerialCreate
Windows: Unregister Event upon Serial --- pxd_eventSerialClose



Summary
HANDLE pxd_eventFieldCreate(unitmap);
HANDLE pxd_eventFieldCreate2(unitmap, type);
void   pxd_eventFieldClose(unitmap, hEvent);
HANDLE pxd_eventCapturedFieldCreate(unitmap);
HANDLE pxd_eventCapturedFieldCreate2(unitmap, type);
void   pxd_eventCapturedFieldClose(unitmap, hEvent);
HANDLE pxd_eventGPTriggerCreate(unitmap, gpwhich, rsvd);
HANDLE pxd_eventGPTriggerCreate2(unitmap, gpwhich, rsvd, type);
void   pxd_eventGPTriggerClose(unitmap, gpwhich, rsvd, hEvent);
HANDLE pxd_eventFaultCreate(unitmap, rsvd);
HANDLE pxd_eventFaultCreate2(unitmap, rsvd, type);
void   pxd_eventFaultClose(unitmap, rsvd, hEvent);
HANDLE pxd_eventSerialCreate(unitmap, serwhich, rsvd, type);
void   pxd_eventSerialClose(unitmap, serwhich, rsvd, hEvent);

int unitmap; // Unit selection bit map (1 for single unit) HANDLE hEvent; // HANDLE returned by previous create int gpwhich; // Which of N triggers to use, N >= 0 int rsvd; // Reserved, should be 0 int type; // 's': synchronization style event // 'n': notification style event int serwhich; // Reserved, should be 0



Description

The pxd_eventFieldCreate and pxd_eventFieldCreate2 return a handle to a Windows event which is signaled once per video field, whether captured or not, on the single unit specified by unitmap. For PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, and SV5L: The event is signaled at (approximately) the start of vertical drive. For PIXCI® SV7: The event is signaled at (approximately) the middle of vertical drive. For PIXCI® A, A310, CL1, CL2, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4: The event is signaled at (approximately) the end of vertical drive. For PIXCI® CL3SD: The event is signaled at vertical drive, which is so short as to make end vs. start distinctions irrelevant.

The pxd_eventCapturedFieldCreate and pxd_eventCapturedFieldCreate2 return a HANDLE to a Windows event which is signaled once per captured video field, on the single unit specified by unitmap. The event is signaled at (approximately) after the last pixel captured within the field.

The pxd_eventGPTriggerCreate and pxd_eventGPTriggerCreate2 return a HANDLE to a Windows event which is signaled once per trigger initiated by the general purpose trigger input signal(s), if any, on the single unit specified by unitmap. The gpwhich specifies which of several trigger input(s) is to be sensed.

The pxd_eventFaultCreate and pxd_eventFaultCreate2 return a HANDLE to a Windows event which is signaled once per fault, on the single unit specified by unitmap. These are the faults retrieved by pxd_mesgFault or pxd_mesgFaultText.

The pxd_eventSerialCreate returns a HANDLE to a Windows event which is signaled once per serial activity on the single unit specified by unitmap on PIXCI® CL1, CL2, CL3SD, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB imaging boards. The serial port must be configured via pxd_serialConfigure or clSerialInit. The event is signalled upon character received, character transmitted, character receive overrun, and receive framing errors.

Under Windows NT, 2000, XP, Vista, and 7 the pxd_eventFieldCreate, pxd_eventCapturedFieldCreate, pxd_eventGPTriggerCreate, and pxd_eventFaultCreate create synchronization style events. The pxd_eventFieldCreate2, pxd_eventCapturedFieldCreate2, pxd_eventGPTriggerCreate2, pxd_eventFaultCreate2, and pxd_eventSerialCreate create a Windows synchronization style event if type='s', and create a Windows notification style event if type='n'. Under Windows 95, 98, and ME there is only one event type and the type parameter is ignored.

The Windows HANDLE returned by pxd_eventFieldCreate, pxd_eventFieldCreate2, pxd_eventCapturedFieldCreate, pxd_eventCapturedFieldCreate2, pxd_eventGPTriggerCreate, pxd_eventGPTriggerCreate2, pxd_eventFaultCreate, pxd_eventFaultCreate2, or pxd_eventSerialCreate can be used with WaitForSingleObject or any other appropriate Windows' API function, such as:

    HANDLE  hEvent = pxd_eventFieldCreate(0x1);
    for (;;) {
        WaitForSingleObject(hEvent, INFINITE);
        // do something upon signal
    }
If using multiple threads in conjunction with WaitForSingleObject or similar functions, note that entry into XCLIB functions must synchronized by the application to prevent overlapping entry by multiple threads.

The pxd_eventFieldClose, pxd_eventCapturedFieldClose, pxd_eventGPTriggerClose, pxd_eventFaultClose, or pxd_eventSerialClose terminates the event previously created with pxd_eventFieldCreate, pxd_eventFieldCreate2, pxd_eventCapturedFieldCreate, pxd_eventCapturedFieldCreate2, pxd_eventGPTriggerCreate, pxd_eventGPTriggerCreate2, pxd_eventFaultCreate, pxd_eventFaultCreate2, or pxd_eventSerialCreate respectively.


Returns

The pxd_eventFieldCreate, pxd_eventFieldCreate2, pxd_eventCapturedFieldCreate, pxd_eventCapturedFieldCreate2, pxd_eventGPTriggerCreate, pxd_eventGPTriggerCreate2, pxd_eventFaultCreate, pxd_eventFaultCreate2, and pxd_eventSerialCreate return a Windows' HANDLE, or NULL if error.


See Also

The pxd_eventGPTriggerCreate, pxd_eventGPTriggerCreate2, and pxd_getGPTrigger provide signals or counts, respectively, upon the same general purpose trigger input(s). See pxd_getGPTrigger for additional discussion on the availability and use of general purpose trigger input(s).

See Windows MSDN documentation for the distinction between synchronization versus notification style events and the advantages of each.


DOS: Register Callback upon Video Field --- pxd_eventFieldCreate
DOS: Unregister Callback upon Video Field --- pxd_eventFieldClose
DOS: Register Callback upon Captured Video Field --- pxd_eventCapturedFieldCreate
DOS: Unregister Callback upon Captured Video Field --- pxd_eventCapturedFieldClose
DOS: Register Callback upon General Purpose Trigger --- pxd_eventGPTriggerCreate
DOS: Unregister Callback upon General Purpose Trigger --- pxd_eventGPTriggerClose
DOS: Register Callback upon Fault --- pxd_eventFaultCreate
DOS: Unregister Callback upon Fault --- pxd_eventFaultClose
DOS: Register Callback upon Serial --- pxd_eventSerialCreate
DOS: Unregister Callback upon Serial --- pxd_eventSerialClose



Summary
int pxd_eventFieldCreate(unitmap, irqfunc, statep);
int pxd_eventFieldClose(unitmap, irqfunc);
int pxd_eventCapturedFieldCreate(unitmap, irqfunc, statep);
int pxd_eventCapturedFieldClose(unitmap, irqfunc);
int pxd_eventGPTriggerCreate(unitmap, gpwhich, rsvd, irqfunc, statep);
int pxd_eventGPTriggerClose(unitmap, gpwhich, rsvd, irqfunc);
int pxd_eventFaultCreate(unitmap, rsvd, irqfunc, statep);
int pxd_eventFaultClose(unitmap, rsvd, irqfunc);
int pxd_eventSerialCreate(unitmap, serwhich, rsvd, irqfunc, statep);
int pxd_eventSerialClose(unitmap, serwhich, rsvd, irqfunc);

typedef int (_cfunfcc pxasyncfunc_t)(void*,int,int); // _cfunfcc is a predefined function modifier int unitmap; // Unit selection bit map (1 for single unit) pxasyncfunc_t irqfunc // Callback function void *statep; // Argument to call back function int gpwhich; // Which of N triggers to use, >= 0 int rsvd; // Reserved, should be 0 int serwhich; // Reserved, should be 0



Description

The pxd_eventFieldCreate registers a callback function to be invoked once per video field, whether captured or not, on the single unit specified by unitmap. For PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, and SV5L: The function is invoked at (approximately) the start of vertical drive. For PIXCI® SV7: The function is invoked at (approximately) the middle of vertical drive. For PIXCI® A, A310, CL1, CL2, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4: The function is invoked at (approximately) the end of vertical drive. For PIXCI® CL3SD: The function is invoked at vertical drive, which is so short as to make end vs. start distinctions irrelevant.

The pxd_eventCapturedFieldCreate registers a callback function to be invoked once per captured video field, on the single unit specified by unitmap. The function is invoked at (approximately) after the last pixel captured within the field.

The pxd_eventGPTriggerCreate registers a callback function to be invoked once per trigger initiated by the general purpose trigger input signal(s), if any, on the single unit specified by unitmap. The gpwhich specifies which of several trigger input(s) is to be sensed.

The pxd_eventFaultCreate registers a callback function to be invoked once per fault, on the single unit specified by unitmap. These are the faults retrieved by pxd_mesgFault or pxd_mesgFaultText.

The pxd_eventSerialCreate registers a callback function to be invoked once per serial activity, on the single unit specified by unitmap on PIXCI® CL1, CL2, CL3SD, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB imaging boards. The serial port must be configured via pxd_serialConfigure or clSerialInit. The event is signalled upon character received, character transmitted, character receive overrun, and receive framing errors.

The irqfunc specifies the callback function to be invoked, such as:

    int _cfunfcc my_irq_callback(void *statep, int unitmap, int reserved)
    {
    }
where statep is the value previously passed to pxd_eventFieldCreate, pxd_eventCapturedFieldCreate, pxd_eventGPTriggerCreate, pxd_eventFaultCreate, or pxd_eventSerialCreate, where unitmap specifies the unit upon which the event occurred, and where reserved is currently unused and 0.

As any other interrupt handler, the irqfunc must operate under severe constraints. It, and all functions it invokes, must not be pageable (i.e under VM), must be compiled to avoid stack checks (probes), must not use excessive stack or time, must not use most DOS or BIOS functions (including printf). The irqfunc should not be declared with the compiler's ''_interrupt'' or ''__interrupt'' adjective.

The pxd_eventFieldClose, pxd_eventCapturedFieldClose, pxd_eventGPTriggerClose, pxd_eventFaultClose, or pxd_eventSerialClose unregisters the callback function previously registered with pxd_eventFieldCreate, pxd_eventCapturedFieldCreate, pxd_eventGPTriggerCreate, pxd_eventFaultCreate, or pxd_eventSerialCreate, respectively.


Returns


0
Operation complete.

PXER...
Other error codes as appropriate.



See Also

The pxd_eventGPTriggerCreate and pxd_getGPTrigger provide callbacks or counts, respectively, upon the same general purpose trigger input(s). See pxd_getGPTrigger for additional discussion on the availability and use of general purpose trigger input(s).


Linux: Register Signal upon Video Field --- pxd_eventFieldCreate
Linux: Unregister Signal upon Video Field --- pxd_eventFieldClose
Linux: Register Signal upon Captured Video Field --- pxd_eventCapturedFieldCreate
Linux: Unregister Signal upon Captured Video Field --- pxd_eventCapturedFieldClose
Linux: Register Signal upon General Purpose Trigger --- pxd_eventGPTriggerCreate
Linux: Unregister Signal upon General Purpose Trigger --- pxd_eventGPTriggerClose
Linux: Register Signal upon Fault --- pxd_eventFaultCreate
Linux: Unregister Signal upon Fault --- pxd_eventFaultClose
Linux: Register Signal upon Serial --- pxd_eventSerialCreate
Linux: Unregister Signal upon Serial --- pxd_eventSerialClose



Summary
int pxd_eventFieldCreate(unitmap, signum, rsvd2);
int pxd_eventFieldClose(unitmap, signum);
int pxd_eventCapturedFieldCreate(unitmap, signum, rsvd2);
int pxd_eventCapturedFieldClose(unitmap, signum);
int pxd_eventGPTriggerCreate(unitmap, gpwhich, rsvd, signum, rsvd2);
int pxd_eventGPTriggerClose(unitmap, gpwhich, rsvd, signum);
int pxd_eventFaultCreate(unitmap, rsvd, signum, rsvd2);
int pxd_eventFaultClose(unitmap, rsvd, signum);
int pxd_eventSerialCreate(unitmap, serwhich, rsvd, signum, rsvd2);
int pxd_eventSerialClose(unitmap, serwhich, rsvd, signum);

int unitmap; // Unit selection bit map (1 for single unit) int signum; // Signal number int gpwhich; // Which of N triggers to use, >= 0 int rsvd; // Reserved, should be 0 void *rsvd2; // Reserved, should be NULL int serwhich; // Reserved, should be 0



Description

The pxd_eventFieldCreate registers a signal number to be signaled once per video field, whether captured or not, on the single unit specified by unitmap. For PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, and SV5L: The signal is issued at (approximately) the start of vertical drive. For PIXCI® SV7: The signal is issued at (approximately) the middle of vertical drive. For PIXCI® A, A310, CL1, CL2, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4: The signal is issued at (approximately) the end of vertical drive. For PIXCI® CL3SD: The signal is issued at vertical drive, which is so short as to make end vs. start distinctions irrelevant.

The pxd_eventCapturedFieldCreate registers a signal number to be signaled once per captured video field, on the single unit specified by unitmap. The function is invoked at (approximately) after the last pixel captured within the field.

The pxd_eventGPTriggerCreate registers a signal number to be signaled once per trigger initiated by the general purpose trigger input signal(s), if any, on the single unit specified by unitmap. The gpwhich specifies which of several trigger input(s) is to be sensed.

The pxd_eventFaultCreate registers a signal number to be signaled once per fault, on the single unit specified by unitmap. These are the faults retrieved by pxd_mesgFault or pxd_mesgFaultText.

The pxd_eventFaultCreate registers a signal number to be signaled once per serial activity, on the single unit specified by unitmap on PIXCI® CL1, CL2, CL3SD, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB imaging boards. The serial port must be configured via pxd_serialConfigure or clSerialInit. The event is signalled upon character received, character transmitted, character receive overrun, and receive framing errors.

The signum specifies the Linux signal number to be used, such as SIGUSR1. (see Linux's signal.h). Handling the signal, such as with signal() or sigaction() is the caller's responsibility.

If the caller's signal handling function is to call XCLIB functions, note that entry into XCLIB functions must be synchronized by the application to prevent overlapping entry by multiple threads.

The pxd_eventFieldClose, pxd_eventCapturedFieldClose, pxd_eventGPTriggerClose, pxd_eventFaultClose, or pxd_eventSerialClose unregisters the signaling previously registered with pxd_eventFieldCreate, pxd_eventCapturedFieldCreate, pxd_eventGPTriggerCreate, pxd_eventFaultCreate, or pxd_eventSerialCreate, respectively.


Returns


0
Operation complete.

PXER...
Other error codes as appropriate.



See Also

The pxd_eventGPTriggerCreate and pxd_getGPTrigger provide signals or counts, respectively, upon the same general purpose trigger input(s). See pxd_getGPTrigger for additional discussion on the availability and use of general purpose trigger input(s).


Set EXSYNC and PRIN Counter Values --- pxd_setExsyncPrin
Get EXSYNC Counter Value --- pxd_getExsync
Get PRIN Counter Value --- pxd_getPrin



Summary
int  pxd_setExsyncPrin(unitmap, exsync, prin);
uint pxd_getExsync(unitmap);
uint pxd_getPrin(unitmap);

int unitmap; // Unit selection bit map (1 for single unit) uint exsync; // The EXSYNC counter value uint prin; // The PRIN counter value



Description

The EXSYNC and PRIN counter values for PIXCI® A, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 imaging boards, are set, or the current values obtained. Depending upon camera and video format configuration, these values typically control the camera integration time and frame period. The allowable range and units of time of these values is camera and video format configuration specific, and discussed in the PIXCI® User's Manual.

The pxd_setExsyncPrin sets the EXSYNC counter value to exsync and the PRIN counter value to prin on the multiple units specified by unitmap. The pxd_getExsync returns the current EXSYNC counter value on the single unit selected by unitmap. The pxd_getPrin returns the current PRIN counter value on the single unit selected by unitmap.

For PIXCI® D2X, ELS2, SI, SI1, SI2, and SI4 imaging boards used with SILICON VIDEO® cameras, use of the pxd_SILICONVIDEO_setVideoAndTriggerMode and pxd_SILICONVIDEO_setCtrlRates functions imply setting EXSYNC and PRIN counter values and are the preferred mechanism. The pxd_setExsyncPrin could be used alone, but should not be used in conjunction with the pxd_SILICONVIDEO_ functions.

The XCLIB-Lite library does not support this feature.


Returns

The pxd_getExsync and pxd_getPrin return values as described above, or 0 if the library is not open for use, XCLIB-Lite is being used, or the wrong imaging board is in use.

The pxd_setExsyncPrin returns:


0
Function performed.

PXERNOTOPEN
The library is not open for use.

PXERNOOPTION
Wrong imaging board.

PXER...
Other error codes as appropriate.

Set EXSYNC and PRINC Mode Bits --- pxd_setExsyncPrincMode
Get EXSYNC Mode Bits --- pxd_getExsyncMode
Get PRINC Mode Bits --- pxd_getPrincMode



Summary
int  pxd_setExsyncPrincMode(unitmap, exsyncbits, princbits);
uint pxd_getExsyncMode(unitmap);
uint pxd_getPrincMode(unitmap);

int unitmap; // Unit selection bit map (1 for single unit) uint exsyncbits; // The EXSYNC mode bits uint princbits; // The PRINC mode bits



Description

The EXSYNC and PRIN mode bits for PIXCI® A, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 imaging boards, are set, or the current values obtained. Depending upon camera, these values typically control the camera's operating mode, such as pixel clock, binning, resolution, trigger mode, synchronization, and scaling of the EXSYNC and/or PRIN counter values used by pxd_setExsyncPrin. The allowable bits and their meaning are camera specific, and discussed in the PIXCI® User's Manual.

Only those bits which control the camera's pixel clock frequency, scaling of EXSYNC and/or PRIN counter values, or similar features should be changed by using pxd_setExsyncPrincMode. Other features, such as a change to binning, resolution, or trigger mode also require a change to the video format configuration, which this function does not automatically perform. Use of pxd_PIXCIopen or pxd_videoFormatAsIncluded with a video format configuration exported by XCAP should be used to effect change to all EXSYNC and PRINC values and bits.

The pxd_setExsyncPrincMode sets the EXSYNC mode bits to exsyncbits and the PRINC mode bits to princbits on the multiple units specified by unitmap. The pxd_getExsyncMode returns the current EXSYNC mode bits on the single unit selected by unitmap. The pxd_getPrincMode returns the current PRIN mode bits on the single unit selected by unitmap.

For PIXCI® D2X, ELS2, SI, SI1, SI2, and SI4 imaging boards used with SILICON VIDEO® cameras, use of the pxd_SILICONVIDEO_setVideoAndTriggerMode and pxd_SILICONVIDEO_setCtrlRates functions imply setting EXSYNC and PRIN mode bits and are the preferred mechanism. The pxd_setExsyncPrincMode could be used alone, but should not be used in conjunction with the pxd_SILICONVIDEO_ functions.

Some versions of the PIXCI® User's Manual may discuss the EXSYNC counter value, the PRIN counter value, the EXSYNC mode bits, and the PRINC mode bits in conjunction with the XCOBJ library functions named pxd_setDalsa01 pxd_setHitachi01 or pxd_setBasler01. Each of these XCOBJ functions is actually identical, and they are equivalent to:

    #define pxd_setDalsa01(p,e) { \
                pxd_setExsyncPrin(1,e>>16,p>>16); \
                pxd_setExsyncPrincMode(1,e&0xFFFF,p&0xFFFF); \
                                }

The XCLIB-Lite library does not support this feature.


Returns

The pxd_getExsyncMode and pxd_getPrincMode returns values as described above, or 0 if the library is not open for use, XCLIB-Lite is being used, or the wrong imaging board is in use.

The pxd_setExsyncPrincMode returns:


0
Function performed.

PXERNOTOPEN
The library is not open for use.

PXERNOOPTION
Wrong imaging board.

PXER...
Other error codes as appropriate.

General Purpose Input Signal: Sense --- pxd_getGPIn
General Purpose Input Signal: Reset --- pxd_setGPIn
General Purpose Output Signal: Set --- pxd_setGPOut
General Purpose Output Signal: Get --- pxd_getGPOut



Summary
int  pxd_getGPIn(unitmap, getindata);
int  pxd_setGPIn(unitmap, setindata);
int  pxd_setGPOut(unitmap, setoutdata);
int  pxd_getGPOut(unitmap, getoutdata);

int unitmap; // Unit selection bit map (1 for single unit) int data; // Binary value(s) to set or reset



Description

The general purpose input and output signals are sensed, set, or reset.

The pxd_getGPIn obtains the current value of the general purpose input signals, if any. The getindata is ignored.

The pxd_setGPIn resets the current value of the general purpose input signals, if any, as per setindata, for imaging boards where the general purpose inputs are latched rather than level sensitive.

The pxd_setGPOut sets the current value of the general purpose output signals, if any, to setoutdata.

The pxd_getGPOut gets the current value of the general purpose output signals, if any, returning a value in the same format as the setoutdata parameter of pxd_setGPOut. The getoutdata is ignored.

For pxd_getGPIn and pxd_getGPOut, the unitmap specifies the single unit for which the general purpose input signals are sensed or the current value of the general purpose output signals are obtained. For pxd_setGPIn and pxd_setGPOut, the unitmap specifies the multiple units for which the general purpose input signals are reset or the general purpose output signals are set.

For the PIXCI® SV2, SV3, SV4, SV5, and SV5A imaging boards: The boards' four general purpose output signals, XD4, XD5, XD6, and XD7, are set to the bits 0x01, 0x02, 0x04, and 0x08 of setoutdata, respectively. The boards' four general purpose input signals, XD0, XD1, XD2, and XD3, are sensed in bits 0x01, 0x02, 0x04, and 0x08, respectively, of the returned value of pxd_getGPIn. The general purpose inputs are level sensitive, the pxd_setGPIn has no effect.

For the PIXCI® SV5B imaging boards: The board does not provide general purpose input or output signals.

For the PIXCI® SV5L imaging board: The board's general purpose output signal, XD4, is set to bit 0x01 of setoutdata. The board's general purpose input signal, XD0, are sensed in bit 0x01 of the returned value of pxd_getGPIn. The general purpose input is level sensitive, the pxd_setGPIn has no effect.

For the PIXCI® D, D24, and D32 imaging boards: The availability of general purpose inputs and outputs depends upon the board model, revision level, and video format configuration. The boards may have a single general purpose latched input signal, sensed as bit 0x01 of the returned value of pxd_getGPIn, and reset as bit 0x01 of the setindata of pxd_setGPIn. The boards may have a single general purpose latched output signal, set to bit 0x01 of setoutdata.

For the PIXCI® A310, CL2, CL3SD, D2X, D3X, E1, E4, E8, EB1, EB1-PoCL, EC1, EL1, SI, and SI1 imaging boards and for each functional unit of the PIXCI® E1DB, E4DB, E8DB, EL1DB, ELS2, SI2, SI4, and SV7 imaging boards: The two general purpose output signals are set to bits 0x01 and 0x02 of setoutdata. The two general purpose input signals are sensed in bits 0x01 and 0x02 of the returned value of pxd_getGPIn. The general purpose inputs are level sensitive, the pxd_setGPIn has no effect.

For the PIXCI® ECB1 imaging board and for each functional unit of the PIXCI® ECB2 imaging board: The one general purpose output signal is set to bit 0x01 of setoutdata. The one general purpose input signal is sensed in bit 0x01 of the returned value of pxd_getGPIn. The general purpose inputs are level sensitive, the pxd_setGPIn has no effect.

For the PIXCI® ECB1-34 imaging board: The board does not provide general purpose input or output signals.

For the PIXCI® CL1 imaging board: The board's one (revision 1 boards) or two (revision 2 and later boards) general purpose output signals are set to bits 0x01 and 0x02 of setoutdata. The board's one (revision 1 boards) or two (revision 2 and later boards) general purpose input signals are sensed in bits 0x01 and 0x02 of the returned value of pxd_getGPIn. The general purpose inputs are level sensitive, the pxd_setGPIn has no effect.

Note: The general purpose input(s) and output(s) are those ''auxiliary'' features available on some imaging boards where, at the hardware level, the signal has no direct effect on video capture. The general purpose input(s) and output(s) are not related to, and not needed for, camera specific, hardware supported, typically asynchronous exposure, triggering features available on some cameras when used with the PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4 imaging board.


Returns

The pxd_getGPIn and pxd_getGPOut return values as described above, and may also return:


PXERNOTOPEN
The library is not open for use.

PXER...
Other error codes as appropriate.

The pxd_setGPIn and pxd_setGPOut return:


0
Function performed, however this returned value is not proof that the imaging board supports the general purpose input(s) and output(s).

PXERNOTOPEN
The library is not open for use.

PXER...
Other error codes as appropriate.

General Purpose Trigger Input Count: Sense --- pxd_getGPTrigger



Summary
int  pxd_getGPTrigger(unitmap, which);

int unitmap; // Unit selection bit map (1 for single unit) int which; // Which of N trigger inputs to sense, >= 0



Description

The pxd_getGPTrigger obtains the current count of the number of triggers initiated by the general purpose trigger input signal(s), if any. The unitmap specifies the single unit for which the general purpose trigger count is obtained. The which specifies which of several trigger input(s) is to be sensed.

For the PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, and SV5L imaging boards: There are no general purpose trigger inputs.

For the PIXCI® A310, CL1, CL2, CL3SD, D, D24, D32, D2X, D32, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, SI4, and SV7 imaging boards: The availability of general purpose trigger inputs, and whether they are sensitive to rising edges or falling edges depends upon the board model, revision level, and video format configuration.

Note: The general purpose trigger input(s) are those ''auxiliary'' features available on some imaging boards where, at the hardware level, the signal has no direct effect on video capture. Use of this function to obtain the general purpose trigger count is not needed when the PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4 and attached camera are in a hardware supported, camera specific, typically asynchronous exposure, trigger mode.


Returns

As described above, and may also return:


PXERNOTOPEN
The library is not open for use.

PXER...
Other error codes as appropriate.

Get Frame Buffer Image Aspect Ratio --- pxd_imageAspectRatio
Get Frame Buffer Image Aspect Ratio --- pxd_imageAspectRatios
Get Frame Buffer Image Bit Depth --- pxd_imageBdim
Get Frame Buffer Image Bit Depth --- pxd_imageBdims
Get Frame Buffer Image Color Components --- pxd_imageCdim
Get Frame Buffer Image Color Components --- pxd_imageCdims
Get Frame Buffer Image Field Dimension --- pxd_imageIdim
Get Frame Buffer Image Field Dimension --- pxd_imageIdims
Get Frame Buffer Image Horizontal Dimension --- pxd_imageXdim
Get Frame Buffer Image Horizontal Dimension --- pxd_imageXdims
Get Frame Buffer Image Vertical Dimension --- pxd_imageYdim
Get Frame Buffer Image Vertical Dimension --- pxd_imageYdims
Get Frame Buffer Image Count --- pxd_imageZdim
Get Frame Buffer Image Count --- pxd_imageZdims



Summary
double pxd_imageAspectRatio();
int    pxd_imageBdim();
int    pxd_imageCdim();
int    pxd_imageIdim();
int    pxd_imageXdim()
int    pxd_imageYdim();
int    pxd_imageZdim();
double pxd_imageAspectRatios(unitmap);
int    pxd_imageBdims(unitmap);
int    pxd_imageCdims(unitmap);
int    pxd_imageIdims(unitmap);
int    pxd_imageXdims(unitmap)
int    pxd_imageYdims(unitmap);
int    pxd_imageZdims(unitmap);

int unitmap; // Unit selection bit map (1 for single unit)



Description

The dimensions or other characteristics of the image frame buffer(s) are returned.

The pxd_imageAspectRatio returns the aspect ratio of a single pixel of the image; defined as the pixel's height divided by the pixel's width. For some cameras and/or imaging boards, the aspect ratio may not be known - a value of 0 is returned.

The pxd_imageBdim returns the number of significant bits in each color component of a pixel, or in the single monochrome component of a pixel. For example, for a high quality so-called ''10 bit per pixel color camera'' which produces 30 bits of RGB for each pixel, the pxd_imageBdim returns 10.[17]

The pxd_imageCdim returns the number of component values per pixel, often referred to as ''pixies'', typically one for monochrome imagery or three for color imagery. The value returned is the number of component colors in the natural or common interpretation of the image, and not necessarily the number of components output by the camera or imaging board. For example, three is returned, representing the common RGB interpretation, for each of: a) An imaging board which stores YUYV or YCrCb 4:2:2 as two components per pixel, b) An imaging board which stores Bayer pattern color as one component per pixel, c) An imaging board which stores RGB+Pad as 4 components per pixel.

The pxd_imageIdim returns the number of video fields in an image frame buffer. The value is one for non-interlaced video formats. For interlaced video formats the value may be two if each frame buffer provides storage for both fields, or one if each frame buffer provides storage for a single field.[18]

The pxd_imageXdim returns the number of pixels in a horizontal line.

The pxd_imageYdim returns the number of pixels in a vertical column.[19]

The pxd_imageZdim returns the number of image frame buffers. If multiple imaging boards are in use, the pxd_imageZdim returns the number of image frame buffers assigned to each imaging board.

If multiple imaging boards are in use and operated at different resolutions, the analogous pxd_imageAspectRatios, pxd_imageBdims, pxd_imageCdims, pxd_imageIdims, pxd_imageXdims, pxd_imageYdims, and pxd_imageZdims functions allow obtaining characteristics relating to the single selected unit; the pxd_imageAspectRatio, pxd_imageBdim, pxd_imageCdim, pxd_imageIdim, pxd_imageXdim, pxd_imageYdim, and pxd_imageZdim each provide characteristics for unitmap=1.


Returns

As described above.

If the library is not open for use, the pxd_imageAspectRatio and pxd_imageAspectRatios returns 0, the other functions return PXERNOTOPEN.


Set Bright White Balance --- pxd_setImageBrightBalance
Set Dark White Balance --- pxd_setImageDarkBalance



Summary
int pxd_setImageDarkBalance(unitmap, referenceRGB[3], targetRGB[3], gamma);
int pxd_setImageBrightBalance(unitmap, referenceRGB[3], targetRGB[3], gamma);

int unitmap; // Unit selection bit map (1 for single unit) uint referenceRGB[3]; // Observed pixel values, R/G/B uint targetRGB[3]; // Target pixel values, R/G/B double gamma; // Gamma correction, or 0 to disable balancing



Description

The pxd_setImageDarkBalance sets the dark balance subtractive correction so that pixel values of referenceRGB[0], referenceRGB[1], and referenceRGB[2] map to targetRGB[0], targetRGB[1], and targetRGB[2], respectively. The pxd_setImageBrightBalance sets the bright (white) balance multiplicative correction so that pixel values of referenceRGB[0], referenceRGB[1], and referenceRGB[2] map to targetRGB[0], targetRGB[1], and targetRGB[2], respectively. The referenceRGB and targetRGB should range between 0 and the maximum pixel value (255 for 8 bit pixels).

The gamma sets the non-linear gamma correction. There is only a single gamma correction, which can be specified with either pxd_setImageDarkBalance or pxd_setImageBrightBalance. A gamma=0 disables dark balancing, bright balancing, and gamma correction.

For PIXCI® A, A310, SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, and SV7 imaging boards: The pxd_setImageDarkBalance and pxd_setImageBrightBalance are not used.

For PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 imaging boards: The pxd_setImageDarkBalance and pxd_setImageBrightBalance are intended for use only with Bayer output color cameras.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Read Pixel Values as Unsigned Char --- pxd_readuchar
Read Pixel Values as Unsigned Short --- pxd_readushort
Write Pixel Values as Unsigned Char --- pxd_writeuchar
Write Pixel Values as Unsigned Short --- pxd_writeushort



Summary
int pxd_readuchar  (unitmap, framebuf, ulx, uly, lrx, lry, membuf, cnt, colorspace);
int pxd_readushort (unitmap, framebuf, ulx, uly, lrx, lry, membuf, cnt, colorspace);
int pxd_writeuchar (unitmap, framebuf, ulx, uly, lrx, lry, membuf, cnt, colorspace);
int pxd_writeushort(unitmap, framebuf, ulx, uly, lrx, lry, membuf, cnt, colorspace);

int unitmap; // Unit selection bit map (1 for single unit) pxbuffer_t framebuf; // Image frame buffer pxcoord_t ulx; // Upper left x coord. of area of interest pxcoord_t uly; // Upper left y coord. of area of interest pxcoord_t lrx; // Lower right x coord. exclusive of AOI pxcoord_t lry; // Lower right y coord. exclusive of AOI uchar membuf[]; // Program's buffer to receive (readuchar) or // originate (writeuchar) unsigned char values ushort membuf[]; // Program's buffer to receive (readushort) or // originate (writeushort) unsigned short values size_t cnt; // Size of program's buffer referenced by membuf // in unsigned char's or unsigned short's char *colorspace; // Name of requested color representation



Description

Pixel values from an image frame buffer and area of interest are copied into, or copied from, an array or other memory buffer provided by the application program.

The unitmap specifies the single unit from which, or to which, pixel values are to be read or written. The framebuf, 1<=framebuf<=pxd_imageZdim(), specifies the image frame buffer from which, or to which, pixel values are to be read or written. The ulx and uly respectively specify the horizontal (x) and vertical coordinate (y) of the upper left corner of an area of interest in the frame buffer to be used. The lrx and lry respectively specify a value one greater than the horizontal and vertical coordinate of the lower right corner of an area of interest in the frame buffer (i.e. an exclusive corner point) to be used. The lrx and lry may each be abbreviated to -1 to specify the extreme right horizontal coordinate (i.e. pxd_imageXdim) or the extreme bottom vertical coordinate (i.e. pxd_imageYdim), respectively.

The membuf specifies a program provided array or buffer which pixel values are to be copied into, or copied from. The cnt specifies the number of unsigned chars (for pxd_readuchar and pxd_writeuchar) or unsigned shorts (for pxd_readushort and pxd_writeushort), in the array or buffer referenced by membuf. The membuf and cnt must be large enough to contain all of the pixel values implied by ulx, uly, lrx, lry, and colorspace; the cnt is not intended to be used to limit the number of pixel values transferred, but is rather intended to assert the maximum allowable transfer size and induce an error if the membuf and cnt is too small.

The colorspace specifies the color space and color component(s) in which pixel values are to be read into, or written from, the program provided array or buffer. Valid choices are:

colorspace Number of Components Color Representation

"RGB" 3 Red, Green, Blue
"RofRGB" 1 Red
"GofRGB" 1 Green
"BofRGB" 1 Blue
"BGR" 3 Blue, Green, Red (RGB reordered)
"BofBGR" 1 Blue
"GofBGR" 1 Green
"RofBGR" 1 Red
"BSH" 3 Brightness, Saturation, Hue (HSB reordered)
"BofBSH" 1 Brightness
"SofBSH" 1 Saturation
"HofBSH" 1 Hue
"RGBx" 4 Red, Green, Blue, Pad
"RofRGBx" 1 Red
"GofRGBx" 1 Green
"BofRGBx" 1 Blue
"BGRx" 4 Blue, Green, Red, Pad (RGB reordered)
"BofBGRx" 1 Blue
"GofBGRx" 1 Green
"RofBGRx" 1 Red
"Grey" 1 Grey Scale
"GREY" 1 Grey Scale (alternate spelling for "Grey")
"Gray" 1 Grey Scale (alternate spelling for "Grey")
"GRAY" 1 Grey Scale (alternate spelling for "Grey")
"YCrCb" 3 Intensity, Red Chroma, Blue Chroma
"YofYCrCb" 1 Intensity
"RofYCrCb" 1 Red Chroma
"BofYCrCb" 1 Blue Chroma
"YCrCbX" 4 Intensity, Red Chroma, Blue Chroma, Pad
"YofYCrCbX" 1 Intensity
"RofYCrCbX" 1 Red Chroma
"BofYCrCbX" 1 Blue Chroma
"Bayer" 1 Raw Bayer Pattern Values
"CbYCrY" 2 UYVY (Blue & Intensity, Red & Intensity)
"CMY" 3 Cyan, Magenta, Yellow
"CofCMY" 1 Cyan
"MofCMY" 1 Magenta
"YofCMY" 1 Yellow

The ''BGRx'' selection, when used with a ''uchar'' membuf, on Intel machines with little-endian architecture (i.e. least significant byte of multi-byte word has lowest address), with the buffer typecast to the Windows ''COLORREF'' type, results in pixels that are compatible with Windows' RGB() data type.

The ''Bayer'' selection is available only in conjunction with cameras that actually output raw Bayer pattern values, and where the XCLIB would otherwise be responsible for converting the values to RGB(x) or BGR(x).

The ''CbYCrY'' selection is available only in conjunction with imaging boards that actually capture CbYCrY (UYVY) values, and where the XCLIB would otherwise be responsible for converting the values to RGB(x), BGR(x), or YCrCb.

While these functions could be used to read or write a single pixel value with each invocation, they are intended, and more efficient, for reading or writing lines, columns, or entire images of pixel values.

Any data type, ''uchar'' or ''ushort'', and any colorspace can be chosen regardless of the image frame buffer's actual format. However, data type and color conversions may require additional computational overhead.

Each pixel value component is copied from, or copied into, a single ''uchar'' or ''ushort''; pixel values are not ''bit-packed''. If the data type has fewer bits that the pixel value component, the most significant bits of the pixel value component are copied into the data type, or are copied from the data type with lower order bits set to 0; e.g. a 10 bit per pixel component value of 1023 is stored in an 8 bit ''uchar'' as value 255. If the data type has more bits than the pixel value component, the pixel value component is copied into, or copied from, the data type's least significant bits; e.g. a 10 bit per pixel component value of 1023 is stored in an 16 bit ''ushort'' as value 1023.

Pixels are read or written, from or to the image, to or from membuf, in the order left-to-right and top-to-bottom. For color pixels with multiple components, the component values are read or written in packed, not planer, order.

The XCLIB-Lite library only supports the ''RGB'', ''BGR'', ''RGBx'', ''BGRx'', ''Grey'', ''Gray'', ''GREY'', and ''GRAY'' selections. The XCLIB-Lite library does not provide data conversions; pxd_readuchar and pxd_writeuchar must be used with 1 through 8 bit component values, pxd_readushort and pxd_writeushort must be used with 9 through 16 bit values.


Returns


≥0
Returns the number of pixel value components copied into, or copied from, the membuf.

PXERNOTOPEN
The library is not open for use.

PXERROR
Invalid parameters.

PXERTOOSMALL
The membuf and cnt is too small to contain the number of pixel value components specified by ulx, uly, lrx, lry, and colorspace.

PXERBADMNEMONIC
The colorspace is invalid.

PXER...
Other error codes as appropriate.



Example

The center pixel in each image frame buffer of each imaging board is read and displayed numerically as both RGB and monochrome. For convenience, the example uses ''ushort'' data types regardless of the image frame buffer's pixel bit-depth, letting the library perform conversions as needed.

ushort  membuf[3];  // room for 1 pixel with three components
int     unit, buf;

for (unit = 0; unit < pxd_infoUnits(); units++) { for (buf = 1; buf < pxd_imageZdim(); buf++) { pxd_readushort(1<<unit, buf, pxd_imageXdim()/2, pxd_imageYdim()/2, 1+(pxd_imageXdim()/2), 1+(pxd_imageYdim()/2), membuf, 3, // dimension of membuf "Grey"); printf("Unit: %d, Buffer: %d, Grey Value: %u\n", unit, buf, membuf[0]); pxd_readushort(1<<unit, buf, pxd_imageXdim()/2, pxd_imageYdim()/2, 1+(pxd_imageXdim()/2), 1+(pxd_imageYdim()/2), membuf, 3, // dimension of membuf "RGB"); printf("Unit: %d, Buffer: %d, RGB Value: %u/%u/%u\n", unit, buf, membuf[0], membuf[1], membuf[2]); } }

Get Imaging Board Driver ID --- pxd_infoDriverId
Get Imaging Board Include Files ID --- pxd_infoIncludeId
Get Imaging Board Library ID --- pxd_infoLibraryId
Get Imaging Board's Frame Buffer Size --- pxd_infoMemsize
Get Imaging Board's Model --- pxd_infoModel
Get Imaging Board's Submodel --- pxd_infoSubmodel
Get Imaging Board Unit Count --- pxd_infoUnits



Summary
char*  pxd_infoDriverId();
char*  pxd_infoIncludeId();
char*  pxd_infoLibraryId();
ulong  pxd_infoMemsize(unitmap);    // Under 32 bit Windows & Linux
uint64 pxd_infoMemsize(unitmap);    // Under 64 bit Windows & Linux
int    pxd_infoModel(unitmap);
int    pxd_infoSubmodel(unitmap);
int    pxd_infoUnits();

int unitmap; // Unit selection bit map (1 for single unit)



Description

Identification or other characteristics of the library, driver, and imaging board(s) are returned.

The pxd_infoDriverId returns the identification string of the current PIXCI® imaging board driver.

The pxd_infoIncludeId ''returns'' the identification string of the current include (i.e. the ''.h'') files. As pxd_infoIncludeId is intended to provide the the identification string of the current include files, it can't be an actual pre-compiled function. However, it can be used as if it were, such as:

    printf("%s", pxd_infoIncludeId());
or
    if (strcmp(pxd_infoIncludeId(), pxd_infoLibraryId))
        printf("Probable DLL mismatch\n");

The pxd_infoLibraryId returns the identification string of the current imaging board library.

The pxd_infoMemsize returns the size in bytes of the frame buffer memory associated with the single selected unitmap.

The pxd_infoModel returns the model designation associated with the single selected unitmap. Current values are:

    PIXCI_A         // the PIXCI® A Imaging Board
    PIXCI_A310      // the PIXCI® A310 Imaging Board
    PIXCI_CL1       // the PIXCI® CL1 Imaging Board
    PIXCI_CL2       // the PIXCI® CL2 Imaging Board
    PIXCI_CL3SD     // the PIXCI® CL3SD Imaging Board
    PIXCI_D         // the PIXCI® D, D24, D32 Imaging Board
    PIXCI_D24       // the PIXCI® D24 Imaging Board
    PIXCI_D32       // the PIXCI® D32 Imaging Board
    PIXCI_D2X       // the PIXCI® D2X Imaging Board
    PIXCI_D3X       // the PIXCI® D3X Imaging Board
    PIXCI_E1        // the PIXCI® E1 Imaging Board
    PIXCI_E1DB      // the PIXCI® E1DB Imaging Board
    PIXCI_E4        // the PIXCI® E4 Imaging Board
    PIXCI_E4DB      // the PIXCI® E4DB Imaging Board
    PIXCI_E8        // the PIXCI® E8 Imaging Board
    PIXCI_E8DB      // the PIXCI® E8DB Imaging Board
    PIXCI_EB1       // the PIXCI® EB1 Imaging Board
    PIXCI_EB1POCL   // the PIXCI® EB1-PoCL Imaging Board
    PIXCI_EC1       // the PIXCI® EC1 Imaging Board
    PIXCI_ECB1      // the PIXCI® ECB1 Imaging Board
    PIXCI_ECB134    // the PIXCI® ECB1-34 Imaging Board
    PIXCI_ECB2      // the PIXCI® ECB2 Imaging Board
    PIXCI_EL1       // the PIXCI® EL1 Imaging Board
    PIXCI_EL1DB     // the PIXCI® EL1DB Imaging Board
    PIXCI_ELS2      // the PIXCI® ELS2 Imaging Board
    PIXCI_SI        // the PIXCI® SI Imaging Board
    PIXCI_SI2       // the PIXCI® SI2 Imaging Board
    PIXCI_SI4       // the PIXCI® SI4 Imaging Board
    PIXCI_SI1       // the PIXCI® SI1 Imaging Board
    PIXCI_SV2       // the PIXCI® SV2 Imaging Board
    PIXCI_SV3       // the PIXCI® SV3 Imaging Board
    PIXCI_SV4       // the PIXCI® SV4 Imaging Board
    PIXCI_SV5       // the PIXCI® SV5, SV5A, SV5B, SV5L Imaging Board
    PIXCI_SV7       // the PIXCI® SV7 Imaging Board
where these are constants defined by inclusion of xcliball.h. Note that PIXCI® D24, and D32 imaging boards may be identified as a PIXCI® D imaging board.

The pxd_infoSubmodel returns the submodel designation associated with the single selected unitmap. For PIXCI® SV2, SV3, SV4, SV5, and SV7 imaging boards the value is 0. For PIXCI® SV5A imaging boards the value is the predefined constant PIXCI_SV5_SV5A. For PIXCI® SV5B imaging boards the value is the predefined constant PIXCI_SV5_SV5B. For PIXCI® SV5L imaging boards the value is the predefined constant PIXCI_SV5_SV5L. For PIXCI® A, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 imaging boards the value is a code indicating the specific camera for which the imaging board is intended, as coded into the PIXCI®'s EEPROM.

The pxd_infoUnits returns the number of imaging boards (i.e. ''units'') that the library has open and available for use.


Returns

As described above

If the library is not open for use, the pxd_infoLibraryId and pxd_infoDriverId return NULL, the other functions return 0.


Get Imaging Board Driver's System Time Units --- pxd_infoSysTicksUnits
Get Imaging Board Driver's System Time --- pxd_infoSysTicks



Summary
int pxd_infoSysTicksUnits(ticku);
int pxd_infoSysTicks(ticks);
uint32          ticku[2];       // System time tick units, rational, microsec.
uint32          ticks[2];       // System time ticks: low & high 32 bits



Description

The units, in microseconds, of the system time ticks provided by pxd_capturedSysTicks pxd_buffersSysTicks, pxd_buffersSysTicks2, and pxd_infoSysTicks is ''returned'' in ticku. The ticku units are fixed and will not change while the library is open.

The current time, in system ticks, is ''returned'' in ticks.


Returns


0
Function performed.

PXERNOTOPEN
The library is not open for use.

PXER...
Other error codes as appropriate.



Example

The relative time that an image was last captured into buffer 2 is reported.

uint32 ticks[2];
uint32 ticku[2];
pxd_buffersSysTicks2(0x1, 2, ticks);
pxd_infoSysTicksUnits(ticku);
sint64 ticks64 = ticks[0] | ((uint64)ticks[1] << 32);
printf("image last captured at %f seconds \n",
        ticks64 * (double)ticku[0] / (ticku[1]*1.0E6));

Load Image: BMP Format --- pxd_loadBmp
Load Image: TIFF Format --- pxd_loadTiff
Save Image: BMP Format --- pxd_saveBmp
Save Image: PCX Format --- pxd_savePcx
Save Image: TARGA Format --- pxd_saveTga
Save Image: TIFF Format --- pxd_saveTiff



Summary
int pxd_loadBmp (unitmap, pathname, framebuf, ulx, uly, lrx, lry, loadmode, options);
int pxd_loadTiff(unitmap, pathname, framebuf, ulx, uly, lrx, lry, loadmode, options);
int pxd_saveBmp (unitmap, pathname, framebuf, ulx, uly, lrx, lry, savemode, options);
int pxd_savePcx (unitmap, pathname, framebuf, ulx, uly, lrx, lry, savemode, options);
int pxd_saveTga (unitmap, pathname, framebuf, ulx, uly, lrx, lry, savemode, options);
int pxd_saveTiff(unitmap, pathname, framebuf, ulx, uly, lrx, lry, savemode, options);

int unitmap; // Unit selection bit map (1 for single unit) char *pathname; // File path name to load from, or save to pxbuffer_t framebuf; // Image frame buffer pxcoord_t ulx; // Upper left x coord. of area of interest pxcoord_t uly; // Upper left y coord. of area of interest pxcoord_t lrx; // Lower right x coord. exclusive of AOI pxcoord_t lry; // Lower right y coord. exclusive of AOI int loadmode; // Resize: 'b': Bilinear, 'n': Nearest neighbor // Color Space: 0x100: convert, 0: no convert int savemode; // Reserved, should be 0 int options; // Reserved, should be 0



Description

An image frame buffer, or an area of interest within the frame buffer, is loaded from, or saved to, a file named pathname. For pxd_loadBmp and pxd_saveBmp the image is loaded or saved in the Windows Device Independent Bitmap File format (i.e. ''.bmp'' or ''.dib''). For pxd_loadTiff and pxd_saveTiff the image is loaded or saved in the Tagged Image File Format (TIFF) (i.e. ''.tif''). For pxd_savePcx the image is saved in the ''PCX'' graphics file format (i.e. ''.pcx''). For pxd_saveTga the image is saved in the ''Targa'' file format (i.e. ''.tga'').

The pathname may include a directory path,[20] and may include a file suffix (i.e. ''.bmp'', ''.tif'', ''.tga'', or ''.pcx'') as desired; these functions do not require, or force, any specific suffix. For pxd_saveBmp, pxd_saveTiff, pxd_savePcx, and pxd_saveTga any existing file pathname is deleted and a new file pathname created.

The unitmap specifies the single unit from which, or to which, an image is to be saved or loaded. The framebuf, 1<=framebuf<=pxd_imageZdim(), specifies the image frame buffer from which, or to which, an image is to be saved or loaded. The ulx and uly respectively specify the horizontal (x) and vertical coordinate (y) of the upper left corner of an area of interest in the frame buffer to be used. The lrx and lry respectively specify a value one greater than the horizontal and vertical coordinate of the lower right corner of an area of interest in the frame buffer (i.e. an exclusive corner point) to be used. The lrx and lry may each be abbreviated to -1 to specify the extreme right horizontal coordinate (i.e. pxd_imageXdim) or the extreme bottom vertical coordinate (i.e. pxd_imageYdim), respectively.

For pxd_loadBmp and pxd_loadTiff: The loaded image is resized, as necessary, to fit the specified frame buffer and area of interest. If loadmode='b', the image is resized by bilinear interpolation, which is suitable for continuous tone images. If loadmode='n', the image is resized by nearest neighbor interpolation, which is particularly suitable for graphics or false colored images, as it avoids the generation of pixel values, via interpolation, which may not exist in the original image. If loadmode&0x100 the loaded image's pixels are converted to the specified frame buffer's color space. Pixel values are converted to be most significant bit aligned; for example a TIFF file with 1 bit per pixel loaded into an image frame buffer with 8 bit pixels yields pixel values of 0 and 128.

For pxd_saveBmp: Color image frame buffers are saved as 24 bit RGB pixels without compression. Monochrome image frame buffers are saved as 8 bit pixels with a monochrome, identity, palette without compression.

For pxd_saveTiff: Color image frame buffers are saved as RGB pixels without compression, monochrome image frame buffers are saved as monochrome pixels without compression, each with the same number of bits per pixel as the image frame buffer.

For pxd_savePcx: Color image frame buffers are saved as 24 bit RGB pixels. Monochrome image frame buffers are saved as 8 bit pixels without a palette.

For pxd_saveTga: Color image frame buffers are saved as 24 bit RGB pixels. Monochrome image frame buffers are saved as 8 bit pixels without a palette.


Returns


0
Image frame buffer loaded or saved.

PXERNOTOPEN
The library is not open for use.

PXERROR
Invalid parameters.

PXERNOMODE
File format uses unsupported options (for pxd_loadBmp and pxd_loadTiff).

PXERFILEFORM
Invalid file format (for pxd_loadBmp and pxd_loadTiff).

PXERMALLOC
Memory allocation error.

PXERDOSIO
Operating system I/O error while reading or writing file.

PXERNEWFILE
Can't create pathname (for pxd_saveBmp, pxd_saveTiff, pxd_savePcx, and pxd_saveTga).

PXERNOFILE
Can't find pathname (for pxd_loadBmp and pxd_loadTiff).

PXER...
Other error codes as appropriate.



Example

The entire AOI of all image frame buffers are saved to a sequence of TIFF formatted files.

int     framebuf;
char    name[20];

for (framebuf = 1; framebuf <= pxd_imageZdim(); framebuf++) { sprintf(name, "abc%.5d.tif", framebuf); pxd_saveTiff(1, name, framebuf, 0, 0, -1, -1, 0, 0); }

Load Frame Buffers --- pxd_loadRawBuffers
Save Frame Buffers --- pxd_saveRawBuffers



Summary
int pxd_loadRawBuffers(unitmap, pathname, startbuf, endbuf, filehandle, fileoffset, alignment, options);
int pxd_saveRawBuffers(unitmap, pathname, startbuf, endbuf, filehandle, fileoffset, alignment, options);

int unitmap; // Unit selection bit map (1 for single unit) char *pathname; // File path name to load from, or save to pxbuffer_t startbuf; // Starting image frame buffer pxbuffer_t endbuf; // Ending image frame buffer, inclusive void *filehandle; // Existing file handle to be read or written, or NULL pxbuffer_t fileoffset; // Offset into file, in units of image frame buffers uint32 alignsector; // Pad image frame buffer size to multiple of ... int options; // Options, should be 0, except as described below



Description

A sequence of one or more consecutive image frame buffers is saved to, for pxd_saveRawBuffers, or loaded from, for pxd_loadRawBuffers, a file.

If pathname≠NULL, the image frame buffers are saved to, or loaded from, the pathname; for pxd_saveRawBuffers an already existing pathname is not deleted and recreated, but partially or fully overwritten allowable replacement of one or more images within an existing file.[21] Alternately, a filehandle≠NULL, to a file previously opened by the application may be supplied. Under Windows the filehandle is expected to be a HANDLE provided by CreateFile. Under Linux the filehandle is expected to be a ''file descriptor'' provided by _open.

The unitmap specifies the single unit from which, or to which, image frame buffers are to be saved or loaded. The startbuf and endbuf, startbuf<=endbuf, specify the first and last image frame buffers, inclusive, to be saved or loaded. The entire image frame buffer is loaded or saved.

Each image frame buffer is saved to, or loaded from, the file sequentially starting at position fileoffset, where fileoffset is interpreted in units of the size of an image frame buffer. For example, fileoffset=0 starts at the beginning of the file, while fileoffset=1 starts with the second image frame buffer in the file. If alignsector≠0, the size of each saved image frame buffer, and thus the starting position relative to the beginning of the file, is padded to a multiple of alignsector bytes; typically so that each saved image frame buffer can be aligned on a multiple of the file system's sector size, or the operating system's virtual page size.

If options&1, then additional capture status information is prepended to each image frame buffer as saved, or the capture status information is set as each image frame buffer is loaded. The information saved or loaded includes date and time of capture, and value of general purpose input signals at time of capture. Currently, this additional information adds 64 bytes per image frame buffer saved or loaded; all discussion above regarding the frame buffer size in the context of fileoffset and alignsector should be interpreted as the frame buffer size plus 64 bytes. Depending on frame buffer memory configuration, the capture status information may not be available, or a frame buffer being saved may never have been captured; when saving, the applicable fields of the capture status are set to 0 values.

The image frame buffers are saved or loaded with a file format which is an exact copy, byte for byte, of the imaging board's frame buffer memory. The file format is intended for efficient saving and loading of image frame buffers; the actual format will vary with different imaging boards, with different video formats using a common imaging board, with different cameras, and with different camera modes. Use of these functions, and the file format created, is contraindicated for export to other (i.e. non-EPIX® imaging software) applications. Use is also contraindicated for archival storage, as reloading an image requires the presence of the same imaging board set to the same video format.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXERNOFILE
File doesn't exist (for pxd_loadRawBuffers).

PXERNEWFILE
File can't be created (for pxd_saveRawBuffers).

PXER...
Other error codes as appropriate.

Errors: Translate Error Code to String --- pxd_mesgErrorCode



Summary
char* pxd_mesgErrorCode(errorcode);
int                 errorcode;          // Error return code



Description

Any of the ''PXER...'' error codes returned by various library functions, given as the errorcode parameter, is translated and returned as a suitable, concise, NULL terminated error message string. A NULL value is returned if errorcode is not a recognized ''PXER...'' code.

The ''PXER...'' codes are defined in pxerrno.h, included via xcliball.h. Programs should never assume specific values of these error codes, but may assume that all error codes are negative and that 0 and positive values are reserved for nonerror conditions. Thus, if an arbitrary ''library_function'' is described to return ''PXER...'' codes, the assumptions utilized in:

int i;
if ((i = library_function(...)) < 0) {
   printf("error %s\n", pxd_mesgErrorCode(i));
   return;
}
or in:
char *cp;
if ((cp = pxd_mesgErrorCode(library_function(...)))) {
   printf("error %s\n", cp);
   return;
}
are valid.

The pxd_mesgErrorCode may be invoked even if the library is not open for use.

The pxd_mesgErrorCode is functionally identical to the pxerrnomesg mentioned in the PXIPL Image Processing Library Reference Manual.


Returns

A char * to an error message, or NULL.


Errors: Check & Report Faults --- pxd_mesgFault
Errors: Check & Report Faults --- pxd_mesgFaultText



Summary
int pxd_mesgFault(unitmap);
int pxd_mesgFaultText(unitmap, buf, bufsize);
int                 unitmap;        // Unit selection bit map (1 for single unit)
char                *buf;           // 'Returned' fault text
size_t              bufsize;        // Size of *buf



Description

The pxd_mesgFault checks whether a fault has occurred since the last check, and if so displays a description of the fault. The pxd_mesgFaultText checks whether a fault has occurred since the last check, and if so ''returns'' a description of the fault in buf. The unitmap specifies the single unit for which faults are checked and displayed.

Under Windows, the pxd_mesgFault displays the description of the fault in a Windows MessageBox. Under other environments, the pxd_mesgFault displays the description of the fault to ''stderr''.

Alternately, the pxd_mesgFaultText returns into buf, which is assumed to be of size bufsize, essentially the same description as would be displayed by pxd_mesgFault but without the ''boilerplate'' such as:

    "Configuration Error or Fault"
        ...
        ...
    "Check Configuration!"
    "See `Installation' and `In Case of Trouble' in ..."
The pxd_mesgFaultText's return code does not indicate whether the buf was too small; if after calling pxd_mesgFaultText
    strlen(buf) == bufsize-1
then the buf was too small and the remainder of the fault's description was lost. A bufsize of 1024 is sufficient for current fault descriptions and is suggested.

Faults are not related to PXER... error codes. Rather, faults are typically asynchronous events, such as reporting that the video signal has been interrupted or corrupted. Faults are not the error description, if any, of the last called library function, with the exception that after pxd_PIXCIopen fails, the pxd_mesgFault or pxd_mesgFaultText may show additional information about the cause of failure.


Returns


1
Fault occurred and was displayed.

0
No fault occurred.

PXER...
Other error codes as appropriate.

PIXCI® Imaging Board: Open and Set Video Format Configuration --- pxd_PIXCIopen
PIXCI® Imaging Board: Close --- pxd_PIXCIclose



Summary
int pxd_PIXCIopen(driverparms, formatname, formatfile);
int pxd_PIXCIclose();

char *driverparms; // Driver configuration parms, or NULL or "" char *formatname; // Video format configuration name, or NULL or "" char *formatfile; // Video format configuration file name, or NULL or ""



Description

The PIXCI® XCLIB Library and Driver is opened using driver configuration parameters specified by driverparms and either the name of a predefined video format specified by formatname or the file name of a saved video format specified by formatfile.[22] The library and driver must be opened before any other library function is invoked, except for those functions that explicitly note otherwise. Once open, the PIXCI® library and driver should be closed by pxd_PIXCIclose before the program exits.

The driverparms should be a Driver Configuration Parameter string as described in Installation and Configuration — Run Time. When building an application program whose end-users would need to select the hardware configuration parameters, the driverparms might be obtained from the ``C'' function getenv (use of the environment name ''PIXCI'' is suggested), or via the Windows function GetProfileString (use of the environment name ''[EPIX_XC]'' and entry ''PIXCI'' is suggested), or from the Windows registry via the Windows function RegQueryValueEx.

The formatname or formatfile allows setting the initial video format configuration. One and only one of formatname or formatfile should be specified, the other should be NULL or the empty string "". The formatname is not case sensitive.

For PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, and SV5L imaging boards: The following predefined formatname's allow setting for standard video format configurations:


"RS-170"
The video format is initially set for RS-170 composite video, capturing 752 pixels per line, 480 lines, monochrome grey level pixels, using video input channel 2. This specification is supported on PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, and SV5L.

"NTSC"
The video format is initially set for NTSC composite video, capturing 752 pixels per line, 480 lines, color YCrCb (for PIXCI® SV2, SV3) or color RGB (for PIXCI® SV4, SV5, SV5A, SV5B, SV5L) pixels, using video input channel 2. This specification is supported on PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, and SV5L.

"NTSC/YC"
The video format is initially set for NTSC S-VIDEO (Super VHS), capturing 752 pixels per line, 480 lines, color YCrCb (for PIXCI® SV2, SV3) or color RGB (for PIXCI® SV4, SV5, SV5L) pixels, using video input channel 1. This specification is supported on PIXCI® SV2, SV3, SV4, SV5, and SV5L.

"CCIR"
The video format is initially set for CCIR composite video, capturing 920 pixels per line, 576 lines, monochrome grey level pixels, using video input channel 2. This specification is supported on PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, and SV5L.

"PAL"
The video format is initially set for PAL (B,D,G,H,I) composite video, capturing 920 pixels per line, 576 lines, color YCrCb (for PIXCI® SV2, SV3) or color RGB (for PIXCI® SV4, SV5, SV5A, SV5B, SV5L) pixels, using video input channel 2. This specification is supported on PIXCI® SV2, SV4, SV4, SV5, SV5A, SV5B, and SV5L.

"PAL/YC"
The video format is initially set for PAL (B,D,G,H,I) S-VIDEO (Super VHS), capturing 920 pixels per line, 576 lines, color YCrCb (for PIXCI® SV2, SV3) or color RGB (for PIXCI® SV4, SV5, SV5L) pixels, using video input channel 1. This specification is supported on PIXCI® SV2, SV3, SV4, SV5, and SV5L.

"PAL(M)"
The video format is initially set for PAL(M) composite video, capturing 920 pixels per line, 576 lines, color YCrCb (for PIXCI® SV3) or color RGB (for PIXCI® SV4, SV5, SV5A, SV5B, SV5L) pixels, using video input channel 2. This specification is supported on PIXCI® SV3, SV4, SV5, SV5A, SV5B, and SV5L.

"PAL(M)/YC"
The video format is initially set for PAL(M) S-VIDEO (Super VHS), capturing 920 pixels per line, 576 lines, color YCrCb (for PIXCI® SV3) or color RGB (for PIXCI® SV4, SV5, SV5L) pixels, using video input channel 1. This specification is supported on PIXCI® SV3, SV4, SV5, and SV5L.

"PAL(N)"
The video format is initially set for PAL(N) composite video, capturing 920 pixels per line, 576 lines, color YCrCb (for PIXCI® SV3) or color RGB (for PIXCI® SV4, SV5, SV5A, SV5B, SV5L) pixels, using video input channel 2. This specification is supported on PIXCI® SV3, SV4, SV5, SV5A, SV5B, and SV5L.

"PAL(N)/YC"
The video format is initially set for PAL(N) S-VIDEO (Super VHS), capturing 920 pixels per line, 576 lines, color YCrCb (for PIXCI® SV3) or color RGB (for PIXCI® SV4, SV5, SV5L) pixels, using video input channel 1. This specification is supported on PIXCI® SV3, SV4, SV5, and SV5L.

"SECAM"
The video format is initially set for SECAM composite video, capturing 920 pixels per line, 576 lines, color YCrCb (for PIXCI® SV3) or color RGB (for PIXCI® SV4, SV5, SV5A, SV5B, SV5L) pixels, using video input channel 2. This specification is supported on PIXCI® SV3, SV4, SV5, SV5A, SV5B, and SV5L.

"SECAM/YC"
The video format is initially set for SECAM S-VIDEO (Super VHS), capturing 920 pixels per line, 576 lines, color YCrCb (for PIXCI® SV3) or color RGB (for PIXCI® SV4, SV5, SV5L) pixels, using video input channel 1. This specification is supported on PIXCI® SV3, SV4, SV5, and SV5L.

"DEFAULT"
For PIXCI® SV2, SV3, SV4, SV5, and SV5L: Same as "NTSC/YC". For PIXCI® SV5A and SV5B: Same as "NTSC".

For PIXCI® SV7 imaging boards: The following predefined formatname's allow setting for standard video format configurations:


"RS-170"
The video format is initially set for RS-170 composite video, capturing 720 pixels per line, 480 lines, monochrome grey level pixels.

"NTSC"
The video format is initially set for NTSC composite video, capturing 720 pixels per line, 480 lines, color YCrCb pixels.

"NTSC(J)"
The video format is initially set for NTSC(J) composite video, capturing 720 pixels per line, 480 lines, color YCrCb pixels.

"NTSC(4.43)"
The video format is initially set for NTSC(4.43) composite video, capturing 720 pixels per line, 480 lines, color YCrCb pixels.

"CCIR"
The video format is initially set for CCIR composite video, capturing 720 pixels per line, 576 lines, monochrome grey level pixels.

"PAL"
The video format is initially set for PAL (B,D,G,H,I) composite video, capturing 720 pixels per line, 576 lines, color YCrCb pixels.

"PAL(M)"
The video format is initially set for PAL(M) composite video, capturing 720 pixels per line, 576 lines, color YCrCb pixels.

"PAL(N)"
The video format is initially set for PAL(N) composite video, capturing 720 pixels per line, 576 lines, color YCrCb pixels.

"PAL(60)"
The video format is initially set for PAL(60) composite video, capturing 720 pixels per line, 576 lines, color YCrCb pixels.

"DEFAULT"
Same as "NTSC".

For PIXCI® A, CL1, CL3SD, D, D24, D32, D2X, D3X, ELS2, SI, SI1, SI2, and SI4 imaging boards: The following predefined formatname's are allowed:


"DEFAULT"
The video format is initially set as appropriate for the camera for which the current PIXCI® imaging board is intended, as coded into the PIXCI® imaging board's EEPROM.

For PIXCI® CL2, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB imaging boards: The following predefined formatname's are allowed:


"DEFAULT"
The video format is initially set as appropriate for the camera for which the current PIXCI® imaging board is intended, as coded into the PIXCI® imaging board's EEPROM. If no selection is coded, or ''Generic Camera Link'' is coded, the capture resolution is set for 888 pixels per line by 888 lines.

For PIXCI® A310 imaging boards: The following predefined formatname's allow setting for standard video format configurations:


"RS-170"
The video format is initially set for RS-170 composite video, capturing 720 pixels per line, 480 lines, monochrome grey level pixels.

"CCIR"
The video format is initially set for CCIR composite video, capturing 720 pixels per line, 574 lines, monochrome grey level pixels.

"Video 720x480i 60Hz"
The video format is initially set for composite interlaced video, 525 total lines per frame, 60 Hz, capturing 720 pixels per line, 480 lines, monochrome grey level pixels. Same as "RS-170".

"Video 720x480i 60Hz RGB"
The video format is initially set for interlaced RGB component video, composite sync on green, 525 total lines per frame, 60 Hz, capturing 720 pixels per line, 480 lines, RGB color pixels.

"Video 720x576i 50Hz"
The video format is initially set for composite interlaced video, 625 total lines per frame, 50 Hz, capturing 720 pixels per line, 576 lines, monochrome grey level pixels. Same as "CCIR".

"Video 720x576i 50Hz RGB"
The video format is initially set for interlaced RGB component video, composite sync on green, 625 total lines per frame, 50 Hz, capturing 720 pixels per line, 576 lines, RGB color pixels.

"Video 1920x1080i 60Hz"
The video format is initially set for composite interlaced video, 60 Hz, capturing 1920 pixels per line, 1080 lines, monochrome grey level pixels.

"Video 1920x1080i 60Hz RGB"
The video format is initially set for interlaced RGB component video, composite sync on green, 60 Hz, capturing 1920 pixels per line, 1080 lines, RGB color pixels.

"Video 1920x1080i 50Hz"
The video format is initially set for composite interlaced video, 50 Hz, capturing 1920 pixels per line, 1080 lines, monochrome grey level pixels.

"Video 1920x1080i 50Hz RGB"
The video format is initially set for interlaced RGB component video, composite sync on green, 50 Hz, capturing 1920 pixels per line, 1080 lines, RGB color pixels.

"Video 1280x720p 60Hz"
The video format is initially set for composite progressive video, 60 Hz, capturing 1280 pixels per line, 720 lines, monochrome grey level pixels.

"Video 1280x720p 60Hz RGB"
The video format is initially set for progressive RGB component video, composite sync on green, 60 Hz, capturing 1280 pixels per line, 720 lines, RGB color pixels.

"Video 1280x720p 50Hz"
The video format is initially set for composite progressive video, 50 Hz, capturing 1280 pixels per line, 720 lines, monochrome grey level pixels.

"Video 1280x720p 50Hz RGB"
The video format is initially set for progressive RGB component video, composite sync on green, 50 Hz, capturing 1280 pixels per line, 720 lines, RGB color pixels.

"XGA 1024x768 60Hz RGB"
The video format is initially set for progressive RGB+HSYNC+VSYNC component XGA video, 60 Hz, capturing 1024 pixels per line, 768 lines, RGB color pixels.

"VGA 640x480 60Hz RGB"
The video format is initially set for progressive RGB+HSYNC+VSYNC component VGA video, 59.94 Hz, capturing 640 pixels per line, 480 lines, RGB color pixels.

"SVGA 800x600 60Hz RGB"
The video format is initially set for progressive RGB+HSYNC+VSYNC component SVGA video, 60.371 Hz, capturing 800 pixels per line, 600 lines, RGB color pixels.

"RS343 875i 60Hz"
The video format is initially set for composite interlaced RS-343 video, 875 total lines per frame, 60 Hz, capturing 1332 pixels per line, 806 lines, monochrome grey level pixels.

"RS343 875i 60Hz RGB"
The video format is initially set for interlaced RS-343 RGB component video, composite sync on green, 875 total lines per frame, 60 Hz, capturing 1332 pixels per line, 806 lines, RGB color pixels.

"DEFAULT"
One of the above selections, as coded into the PIXCI® A310's EEPROM. If no selection is coded, the capture resolution is set for 888 pixels per line by 888 lines.

Alternately, the formatfile is taken to be the name of a file containing a video format configuration (also referred to as a video state) previously exported by the XCAP program or the XCLIB library. Video capture parameters, such as the video format, video resolution, pixel color space, video input channel, and white balancing, (as appropriate for the imaging board in use) are all imported from formatfile.

Note: When the XCLIB DLL is called from Visual Basic, VB.NET, LabView, Matlab, or many other non C/C++ environments, the alternative empty string ("") should be used, not NULL, for driverparms, formatname, or formatfile as required. In Visual Basic, VB.NET, LabView, or Matlab, a NULL isn't the same as a C/C++ NULL.


Returns


0
The PIXCI® XCLIB Library and Driver is open and ready for use.

PXERROR
The PIXCI® imaging board could not be accessed; either the PIXCI® driver or hardware is not installed correctly.

PXERMALLOC
Memory allocation error.

PXERNOFILE
No file named formatfile found.

PXERDOSIO
Can't read file named formatfile.

PXERSEARCH
The formatname was invalid.

PXERVIDFORM
The formatname was one of the strings described above, but the specified format is not supported on the current imaging board.

PXERBADPARM
The parameters in driverparms are invalid.

PXERFILEFORM
The file format of formatfile is invalid.

PXERISOPEN
The library and driver are already open for use.

PXER...
Other error codes as appropriate.
For all error codes, but specifically for PXERROR, calling pxd_mesgFault or pxd_mesgFaultText may provide more information about the cause of the error.


See Also

See the PIXCI® USER'S MANUAL for discussion of configuration options and settings.


Example

A PIXCI® A310, SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, or SV7 imaging board is opened for RS-170 format.

int i;
if ((i = pxd_PIXCIopen("", "RS-170", "")) < 0) {
    printf("Open Error: %s\n", pxd_mesgErrorCode(i));
    pxd_mesgFault(1);   // display more information about the open error
    exit(1);
}
printf("Open OK\n");

Any PIXCI® imaging board is opened for use with default format and resolution.

int i;
if ((i = pxd_PIXCIopen("", "default", NULL)) < 0) {
    printf("Open Error: %s\n", pxd_mesgErrorCode(i));
    pxd_mesgFault(1);   // display more information about the open error
    exit(1);
}
printf("Open OK\n");

Windows: Create Device Independent Bitmap (DIB) --- pxd_renderDIBCreate
Windows: Release Device Independent Bitmap (DIB) --- pxd_renderDIBFree



Summary
HGLOBAL pxd_renderDIBCreate(unitmap, framebuf, ulx, uly, lrx, lry, mode, options);
int     pxd_renderDIBFree(hDIB);

int unitmap; // Unit selection bit map (1 for single unit) pxbuffer_t framebuf; // Image frame buffer pxcoord_t ulx; // Upper left x coord. of area of interest pxcoord_t uly; // Upper left y coord. of area of interest pxcoord_t lrx; // Lower right x coord. exclusive of AOI pxcoord_t lry; // Lower right y coord. exclusive of AOI int mode; // Reserved, should be 0 int options; // Reserved, should be 0
HGLOBAL hDIB; // Previously created bitmap



Description

An image frame buffer, or an area of interest within the image frame buffer, is copied to a newly created Windows Device Independent Bitmap (DIB) in global memory (e.g. using the Windows' GlobalAlloc) and the handle to the DIB returned by pxd_renderDIBCreate. The bitmap created must be freed by pxd_renderDIBFree when no longer needed.

The unitmap specifies the single unit from which the image frame buffer is to be copied. The framebuf, 1<=framebuf<=pxd_imageZdim(), specifies the image frame buffer to be copied. The ulx and uly respectively specify the horizontal (x) and vertical coordinate (y) of the upper left corner of an area of interest in the frame buffer to be used. The lrx and lry respectively specify a value one greater than the horizontal and vertical coordinate of the lower right corner of an area of interest in the frame buffer (i.e. an exclusive corner point) to be used. The lrx and lry may each be abbreviated to -1 to specify the extreme right horizontal coordinate (i.e. pxd_imageXdim) or the extreme bottom vertical coordinate (i.e. pxd_imageYdim), respectively.

Color image frame buffers are copied as 24 bit RGB pixels without compression. Monochrome image frame buffers are copied as 8 bit pixels with a monochrome, identity, palette without compression.

The number of pixels per line, i.e. lrx-ulx, should be a multiple of four; as some Windows drivers do not properly support Device Independent Bitmaps which violate this condition.


Returns

The pxd_renderDIBCreate returns a handle to GlobalAlloc memory, or 0 if the library is not open for use, or a parameter is invalid.

The pxd_renderDIBFree returns 0 if successful or a PXER... code as appropriate.


Windows: Direct Video Display, Init --- pxd_renderDirectVideoInit
Windows: Direct Video Display, Done --- pxd_renderDirectVideoDone



Summary
int pxd_renderDirectVideoInit(unitmap, hWnd);
int pxd_renderDirectVideoDone(unitmap, hWnd);

int unitmap; // Unit selection bit map (1 for single unit) HWND hWnd; // Handle to window



Description

A connection to the DirectX/DirectDraw feature of Windows is created in preparation for displaying live video on the graphics display (S/VGA). The hWnd specifies the window to which DirectX/DirectDraw access is requested on the single unit specified by unitmap.[23]

Since initial connection to DirectX/DirectDraw may require 200 msec or more, the pxd_renderDirectVideoInit may be initialized once, after which pxd_renderDirectVideoLive may be used multiple times without repeating the connection delay. When done, pxd_renderDirectVideoDone should be called to release the connection.


Returns


0
Connection established.

PXERROR
Invalid parameters.

PXERMALLOC
Memory allocation error.

PXERNOMODE
The current imaging board does not provide live video to the graphics display (S/VGA).

PXERNOFEATURE
A connection could not be established to DirectX/DirectDraw; that feature may not be installed in the current Windows.

PXERNOTNOW
Another application has exclusive DirectX/DirectDraw use of the graphics display (S/VGA).

PXERNOTOPEN
A connection to DirectX/DirectDraw was not created via pxd_renderDirectVideoInit.

PXER...
Other error codes as appropriate.

Windows: Direct Video Display, Start --- pxd_renderDirectVideoLive
Windows: Direct Video Display, Stop --- pxd_renderDirectVideoUnLive



Summary
int pxd_renderDirectVideoLive(unitmap, hWnd, nX, nY, nWidth, nHeight, ClrKey1, ClrKey2);
int pxd_renderDirectVideoUnLive(unitmap, hWnd);

int unitmap; // Unit selection bit map (1 for single unit) HWND hWnd; // Handle to window uint nX; // X position in Window uint nY; // Y position in Window uint nWidth; // Display width in Window, or UINT_MAX uint nHeight; // Display height in Window, or UINT_MAX COLORREF ClrKey1; // Color key, a RGB(,,) or CLR_INVALID COLORREF ClrKey2; // Color key, a RGB(,,) or CLR_INVALID



Description

The pxd_renderDirectVideoLive initiates displaying of live video directly to the graphics display (S/VGA), using the Windows DirectX/DirectDraw feature. The pxd_renderDirectVideoUnLive terminates displaying of live video directly to the graphics display (S/VGA). The pxd_renderDirectVideoInit must have been used previously to create a connection to the DirectX/DirectDraw feature. The pxd_renderDirectVideoLive and related functions handle the entire DirectX/DirectDraw interface; the user need not be familiar with the DirectX/DirectDraw API, nor use the DirectX/DirectDraw SDK. Familiarity with the standard Windows API is, of course, helpful.

The hWnd specifies the window upon which live video is displayed, from the single unit specified by unitmap.[24] Live video is displayed at an upper left coordinate of nX and nY relative to the hWnd window, with a maximum width and height of nWidth and nHeight. The nWidth and nHeight are reduced so as to not exceed the window's size; use of nX=0, nY=0, nWidth=UINT_MAX, and nHeight=UINT_MAX fills as much of the window as possible. The displayed video may be smaller than the requested size, as limited by the current video resolution (see pxd_imageXdim and pxd_imageYdim). The video resolution will be decreased, as needed, to fit within the display area, but will not be automatically enlarged.

If ClrKey1≠CLR_INVALID, the color key (chroma key) feature of the graphics display (S/VGA) is enabled, so as to allow presenting live video only where the graphics display (S/VGA) screen has the color of ClrKey1. This allows presentation of graphics over live video, through the use of Windows GDI, so long as the intended graphics are a color different than ClrKey1. If ClrKey2≠CLR_INVALID, the color ClrKey2 is drawn on the window prior to activating live video. Typically, ClrKey2 is the same value as ClrKey1; but setting ClrKey1≠CLR_INVALID and ClrKey2=CLR_INVALID, allows the user to assume responsibility for filling the window with the ClrKey1 color wherever live video is to appear.

After use of pxd_renderDirectVideoLive, it is the application's responsibility to monitor Windows' WM_MOVE, WM_SIZE, WM_WINDOWPOSCHANGED, and WM_WINDOWPOSCHANGING, messages, and upon receipt, invoke pxd_renderDirectVideoUnLive to stop displaying live video in the old size or window location, and invoke pxd_renderDirectVideoLive again to resume displaying live in the new size or location.

Graphics display systems (S/VGA cards), and their drivers, differ widely in their support of live video. The minimal requirements are:

  1. Graphics display system (S/VGA) drivers supporting DirectDraw.

  2. Hardware overlay feature.

  3. For PIXCI® SV2 and SV3 imaging boards: Overlay surface that accepts UYVY format video. For PIXCI® SV4, SV5, SV5A, SV5B, and SV5L imaging boards: Overlay surface that accepts UYVY, VYUY, YUY2, or YVYU format video.

  4. Hardware cursor/sprite/icon support.

  5. Hardware chroma key support (optional).
In addition, the DirectX/DirectDraw feature must be installed in Windows.

Each graphics display system (S/VGA card) differs in whether it supports the necessary features in all modes (i.e. 8 bits per pixel, 24 bits per pixel, etc.) and resolution (i.e. 640x480, 1024x768, etc.). The pxd_renderDirectVideoLive tries to provide live video using the graphics display system's (S/VGA card's) current mode and resolution, it does not change the graphics display system's current mode or resolution.

For PIXCI® A, CL1, CL2, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, and SI4: No known graphics display system (S/VGA card) supports the data formats produced by these imaging boards.

For PIXCI® CL3SD and SI2: The imaging board can't directly display live video to the graphics display (S/VGA).

The pxd_renderDirectVideoLive and pxd_renderDirectVideoUnLive do not support use of multiple imaging boards at different video formats and resolutions.


Returns


0
Operation successful.

PXERROR
Invalid parameters.

PXERNOTOPEN
A connection to DirectX/DirectDraw was not created via pxd_renderDirectVideoInit.

PXERNOMODE
The current graphics display (S/VGA) card can't accept live video, at least not in a form compatible with the imaging board's current video format.

PXERNODEVMEM
Insufficient memory on the graphics display system (S/VGA card) for the specified video resolution.

PXERNOFEATURE
The current graphics display system (S/VGA card) doesn't provide color keying, pxd_renderDirectVideoLive can only be used with ClrKey1=CLR_INVALID.

PXER...
Other error codes as appropriate.



Example

The xclibex2.cpp example program demonstrates use of pxd_renderDirectVideoLive and pxd_renderDirectVideoUnLive, including the use of chroma keying and use of WM_MOVE, WM_SIZE, WM_WINDOWPOSCHANGED, and WM_WINDOWPOSCHANGING, to track changes to the window's position.

The xclibex2.cpp also demonstrates other techniques for displaying live video, which may be used regardless of whether the graphics display (S/VGA) and imaging board features support pxd_renderDirectVideoLive.


Windows: Display Image Frame Buffer On Device Context --- pxd_renderStretchDIBits



Summary
int pxd_renderStretchDIBits(unitmap,buffer,ulx,uly,lrx,lry,options,hDC,nX,nY,nWidth,nHeight,winoptions);
int                 unitmap;        // Unit selection bit map (1 for single unit)
pxbuffer_t          buffer;         // Image frame buffer
pxcoord_t           ulx;            // Upper left x coord. of area of interest
pxcoord_t           uly;            // Upper left y coord. of area of interest
pxcoord_t           lrx;            // Lower right x coord. exclusive of AOI
pxcoord_t           lry;            // Lower right y coord. exclusive of AOI
int                 options;        // Reserved, should be 0
HDC                 hDC;            // Device context
uint                nX;             // Display x position in hDC
uint                nY;             // Display y position in hDC
uint                nWidth;         // Display width in hDC
uint                nHeight;        // Display height in hDC
int                 winoptions;     // Reserved, should be 0



Description

An image frame buffer, or an area of interest within the image frame buffer, is copied/rendered/displayed to a Windows device context, typically a display window or a printer context.

The unitmap specifies the single unit from which the image frame buffer is to be copied. The framebuf, 1<=framebuf<=pxd_imageZdim(), specifies the image frame buffer to be copied. The ulx and uly respectively specify the horizontal (x) and vertical coordinate (y) of the upper left corner of an area of interest in the frame buffer to be used. The lrx and lry respectively specify a value one greater than the horizontal and vertical coordinate of the lower right corner of an area of interest in the frame buffer (i.e. an exclusive corner point) to be used. The lrx and lry may each be abbreviated to -1 to specify the extreme right horizontal coordinate (i.e. pxd_imageXdim) or the extreme bottom vertical coordinate (i.e. pxd_imageYdim), respectively.

The image is rendered on the device context defined by hDC, starting at the nX and nY coordinate, with a width and height of nWidth and nHeight.

As may be inferred from the name, pxd_renderStretchDIBits uses the Windows GDI StretchDIBits function; pxd_renderStretchDIBits builds a Device Independent Bitmap of the specified image frame buffer and area of interest, and invokes:

StretchDIBits(hDC,nX,nY,nWidth,nHeight,0,0,lrx-ulx,lry-uly,*,*,DIB_RGB_COLORS,SRCCOPY);
or
StretchDIBits(hDC,nX,nY+nHeight-1,nWidth,-nHeight,0,0,lrx-ulx,lry-uly,*,*,DIB_RGB_COLORS,SRCCOPY);
The StretchDIBits documentation provides additional discussion regarding the nX, nY, nWidth, and nHeight parameters.[25]

The number of pixels per line, i.e. lrx-ulx, should be a multiple of four, as some Windows display drivers do not properly support Device Independent Bitmaps which violate this condition. The number of pixels displayed per line, i.e. nWidth should also be a multiple of four, as some Windows display drivers do not properly support resizing into a display area which violates this condition.

For some graphics display (S/VGA) drivers, the quality of the rendered image can be significantly improved by using:

SetStretchBltMode(hDC, STRETCH_DELETESCANS);
before pxd_renderStretchDIBits.

Because pxd_renderStretchDIBits relies upon the Windows StretchDIBits for rendering and resizing, the visual result and rendering speed is completely dependent upon the graphics display adapter (e.g. S/VGA adapter) and its driver. For example, in 16 color (4 bit per pixel) S/VGA mode, monochrome images might be rendered using only 3 grey levels, with significant ''banding''. Good results will be obtained with S/VGA adapters providing at least 16 bits per pixel for monochrome images, or at least 24 bits per pixel for color images.[26]

Alternately, the pxd_renderDIBCreate can be used to create a standard Windows Device Independent Bitmap (DIB) which can then be rendered via DrawDibDraw or via the Video for Windows (MultiMedia) API. The visual result and rendering speed is still completely dependent upon the graphics display adapter (e.g. S/VGA adapter) and its driver; however, the Windows MultiMedia API, being newer, tends to perform better than the older Windows StretchDIBits.

Finally, the alternate pxio8_GDIDisplay, pxio8_DirectXDisplay, or pxio8_DrawDibDisplay functions provided with the PXIPL Image Processing Library, allows pseudo-grey level generation (useful in 16 color S/VGA modes), selectable methods of image resizing, provides for integrated drawing of a cross-hair or other image cursor, performs resizing within the PXIPL function, avoids the overhead of copying the image into a DIB format and allows applying a look-up table (palette) as the image is being rendered.

Because pxd_renderStretchDIBits uses hDC, a handle to a device context rather than a handle to a window, it may also be used to print images, given a handle to a printer's device context.


Returns


0
Image frame buffer copied/rendered/displayed.

PXERNOTOPEN
The library is not open for use.

PXERROR
Invalid parameters.

PXERMALLOC
Memory allocation error.

Serial Port: Set Configuration --- pxd_serialConfigure
Serial Port: Read --- pxd_serialRead
Serial Port: Write --- pxd_serialWrite



Summary
int pxd_serialConfigure(unitmap, rsvd0, baud, bits, parity, stopbits, rsvd1, rsvd2, rsvd3);
int pxd_serialRead(unitmap, rsvd0, data, cnt);
int pxd_serialWrite(unitmap, rsvd0, data, cnt);

int unitmap; // Unit selection bit map (1 for single unit) double baud; // Serial baud rate, or 0 int bits; // Bits per character int stopbits; // Stop bits per character, times 10 int parity; // 0: None int rsvd0; // Reserved, should be 0 int rsvd1; // Reserved, should be 0 int rsvd2; // Reserved, should be 0 int rsvd3; // Reserved, should be 0 char data[]; // Program's buffer to receive or originate data int cnt; // Size of data[]



Description

The pxd_serialConfigure, pxd_serialRead, and pxd_serialWrite allow use of the serial port on PIXCI® CL1, CL2, CL3SD, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB imaging boards.

The pxd_serialConfigure sets the serial port's parameters on the single unit selected by unitmap. The baud specifies the baud rate, the bits specifies the number of bits per character, the stopbits specifies the number of stop bits per character multiplied by 10, and parity specifies the type of parity bit. For the PIXCI® CL1 before Rev. 3 and the PIXCI® CL3SD, the baud rate may be any value between 95.4 and 6,250,000.0 baud, the number of bits must be 8, the number of stop bits must be 1 (i.e. stopbits=1) and parity must be none (i.e. parity=0). For the PIXCI® CL2, and the PIXCI® CL1 Rev. 3 and later the baud rate may be any value between 192.0 and 12,500,000.0 baud, the number of bits must be 8, the number of stop bits must be 1 (i.e. stopbits=1) and parity must be none (i.e. parity=0). For the PIXCI® E1, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, EL1, E4, and E8 the baud rate may be any value between 512.4 and 12,500,000.0 baud, the number of bits must be 8, the number of stop bits must be 1 (i.e. stopbits=1) and parity must be none (i.e. parity=0). For the PIXCI® E1DB, ECB2, EL1DB, E4DB, and E8DB the baud rate may be any of the values 9600, 19200, 38400, 57600, 115200, 230400, 460800, or 921600 baud (i.e. the Camera Link V2.0 Specification baud rates), the number of bits must be 8, the number of stop bits must be 1 (i.e. stopbits=1) and parity must be none (i.e. parity=0). The baud may also be 0, disabling the serial port; other serial port parameters are ignored.

The pxd_serialRead reads any previously received but unread data into the ''char'' array or buffer provided by the application on the single unit selected by unitmap. The cnt specifies the size of the array or buffer referenced by data, and the maximum amount of data to be read. The pxd_serialRead never waits for data to be received, reading only previously received data, and returns the number of char's read. If data=NULL or cnt=0, the pxd_serialRead returns the number of char's available to be read without reading or deleting the unread data.

The pxd_serialWrite writes data from the ''char'' array or buffer provided by the application on the single unit selected by unitmap. The cnt specifies the size of the array or buffer referenced by data, and the amount of data to be written. The pxd_serialWrite may wait for the data to be queued for transmission (i.e. until all the data can be copied into the internal transmit buffers) but does not wait until the data is actually transmitted. If buf=0 or cnt=0, the pxd_serialWrite returns the amount of available space in the internal transmit buffers, and thus the amount of data that can be written by pxd_serialWrite without having to wait.

The size of the transmit and received buffers are currently each 1024 bytes and may not be changed.

Note: The Visual Basic declarations for pxd_serialWrite and pxd_serialRead are written to expect that the data will be passed as a VB dimensioned array, not as a VB double-quoted string. This allows easier use with cameras whose serial commands are binary rather than ASCII. For cameras with ASCII style commands, the ASCII characters can be inserted into a dimensioned array, or the VB declaration can be manually changed.


Returns


≥0
Operation complete (pxd_serialRead and pxd_serialWrite).

0
Operation complete (pxd_serialConfigure).

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.



See Also

See clSerialInit, clSerialClose, clSerialRead, clSerialWrite and related functions.


Example

An example of sending a camera one command and waiting for a response. Each camera's commands and responses differ; the example command and response are for a hypothetical camera using ASCII style commands.

    char    databuffer[50];   // buffer large enough for command and response
    int     dataread;
    int     r;
    char    c;
    DWORD   time;
    //
    // Init serial port if not done already
    //
    r = pxd_serialConfigure(0x1, 0,  9600, 8, 0, 1, 0, 0, 0);
    if (r < 0)
        return; // error
    //
    // Format command and send.
    // Here we use an example of an ASCII style, \n terminated, command.
    // If the camera used binary commands, we would likely construct the
    // databuffer byte by byte instead of using sprintf, and we
    // would know the length a priori instead of using strlen().
    //
    sprintf(databuffer, "Set Gain=%f\n", 12.345);
    r = pxd_serialWrite(0x1, 0, databuffer, strlen(databuffer));
    if (r < 0)
        return; // error
    //
    // Wait for and read response. Don't wait forever, in
    // case the camera is not connected or not powered on.
    //
    dataread = 0;
    time = GetTickCount();  // Windows: current time in milliseconds
    for (;;) {
        //
        // Another character arrived?
        //
        r = pxd_serialRead(0x1, 0, &c, 1);
        if (r < 0)
            return;     // error
        if (r == 0) {
            Sleep(1);   // be nice to multitasking OS
            continue;   // nothing arrived since last check
        }
        //
        // Store next character, building up response
        //
        databuffer[dataread++] = c;
        //
        // Have we read a complete response? The test is camera dependent!
        // Here we assume an ASCII response, terminated with a \n .
        //
        if (c == '\n')
            break;
        //
        // If not, have we filled the buffer?
        //
        if (dataread == sizeof(databuffer))
            return;     // error: can't interpret response
        //
        // Have we waited long enough to give up?
        //
        if (GetTickCount()-time > 1000)
            return;     // error: timeout
    }
    //
    // Check the response. This test is camera dependent!
    //
    if (strstr(databuffer, "ACK"))
        return;     // positive acknowledge seen
    if (strstr(databuffer, "NAK"))
        return;     // negative acknowledge seen
    return;         // error: can't interpret response
The above example reads the response one character at a time for sake of clarity, not necessity. The first half of the ''for'' loop can be replaced with:
    for (;;) {
        //
        // Read up to as many characters as will fit in the remainder
        // of the data buffer.
        //
        r = pxd_serialRead(0x1, 0, &databuffer[dataread], sizeof(databuffer)-dataread);
        if (r < 0)
            return;     // error
        if (r == 0) {
            Sleep(1);   // be nice to multitasking OS
            continue;   // nothing arrived since last check
        }
        dataread += r;
        //
        // Have we read a complete response?
        //
        if (databuffer[dataread-1] == '\n')
            break;
        ...
    }

Camera Link Serial: Initialize --- clSerialInit
Camera Link Serial: Close --- clSerialClose
Camera Link Serial: Read --- clSerialRead
Camera Link Serial: Write --- clSerialWrite
Camera Link Serial: Read Available --- clGetNumBytesAvail
Camera Link Serial: Read Flush --- clFlushPort
Camera Link Serial: Error Text --- clGetErrorText
Camera Link Serial: Ports --- clGetNumSerialPorts
Camera Link Serial: Ports ID --- clGetSerialPortIdentifier
Camera Link Serial: Manufacturer ID --- clGetManufacturerInfo
Camera Link Serial: Get Baud Rates --- clGetSupportedBaudRates
Camera Link Serial: Set Baud Rate --- clSetBaudRate



Summary
int clSerialInit(...);
int clSerialClose(...);
int clSerialRead(...);
int clSerialWrite(...);
int clGetNumBytesAvail(...);
int clFlushPort(...);
int clGetErrorText(...);
int clGetNumSerialPorts(...);
int clGetSerialPortIdentifier(...);
int clGetManufacturerInfo(...);
int clGetSupportedBaudRates(...);
int clSetBaudRate(...);



Description

Under Windows, the clSerialInit, clSerialClose, clSerialRead, clSerialWrite, clGetNumBytesAvail, clFlushPort, clGetErrorText, clGetNumSerialPorts, clGetSerialPortIdentifier, clGetManufacturerInfo, clGetSupportedBaudRates, and clSetBaudRate provide functions to access the serial port of PIXCI® imaging boards. These functions' API obeys the Camera Link V1.1 Serial API,[27] except that the instantiation of these functions within the XCLIB DLL only provide access after XCLIB has been pxd_PIXCIopen'ed; the ''serialIndex'' (a Camera Link API parameter) is the index of a board opened by pxd_PIXCIopen (i.e. log2 unitmap).

These functions are alternatives to using pxd_serialConfigure, pxd_serialRead, and pxd_serialWrite.

These functions are not a replacement for somewhat similar, but not identical, functions in the Camera Link's clallserial.dll as described in clallserial.h; which provides single point-of-call access to all Camera Link serial ports on the current computer regardless of board manufacturer, by virtue of finding all installed clserXXX.DLL's and redirecting function calls to them.


Returns

As described in the Camera Link V1.1 specification.


Set Video Input Multiplexer --- pxd_setVidMux
Set Video Contrast and Brightness --- pxd_setContrastBrightness
Set Video Hue and Saturation --- pxd_setHueSaturation
Get Video Input Multiplexer --- pxd_getVidMux
Get Video Contrast --- pxd_getContrast
Get Video Brightness --- pxd_getBrightness
Get Video Hue --- pxd_getHue
Get Video U Saturation --- pxd_getUGain
Get Video V Saturation --- pxd_getVGain



Summary
int     pxd_setVidMux(unitmap, inmux);
int     pxd_setContrastBrightness(unitmap, contrast, brightness);
int     pxd_setHueSaturation(unitmap, hue, Ugain, Vgain);
int     pxd_getVidMux(unitmap);
double  pxd_getContrast(unitmap);
double  pxd_getBrightness(unitmap);
double  pxd_getHue(unitmap);
double  pxd_getUGain(unitmap);
double  pxd_getVGain(unitmap);

int unitmap; // Unit selection bit map (1 for single unit) int mux; // Multiplexer selection double contrast; // Percent change of contrast, default=100 double brightness; // Percent change of brightness, default=0 double hue; // Percent change of hue, default=100 double Ugain; // Percent change of U Gain, default=100 double Vgain; // Percent change of V Gain, default=100



Description

The multiplexer selection, contrast, brightness, and other A/D characteristics of PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, and SV7 imaging boards, are set, or the current value obtained.

For the PIXCI® SV2, SV3, SV4, SV5, or SV5L, the pxd_setVidMux sets the current multiplexer setting, on the multiple units specified by unitmap, with inmux=1 selecting the S-Video connector, inmux=2 selecting the BNC (or mini-BNC on the SV5L) connector nearest the S-Video connector, and inmux=3 selecting the last BNC (or mini-BNC on the SV5L) connector (on SV3, SV4, and SV5 only).

For the PIXCI® SV5A, the pxd_setVidMux sets the current multiplexer setting, on the multiple units specified by unitmap, with inmux=1 selecting top BNC connector, inmux=2 selecting the middle BNC connector, and inmux=3 selecting the bottom BNC connector (nearest the DB-15 connector).

For the PIXCI® SV5B and SV7, which have a single video input, the pxd_setVidMux has no effect.

The pxd_getVidMux returns the current multiplexer setting, on the single unit specified by unitmap, with the same interpretation as used for the inmux parameter of pxd_setVidMux.

The pxd_setContrastBrightness sets the A/D contrast and brightness, on the multiple units specified by unitmap, to contrast and brightness.

For the PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, and SV5L: The contrast, between 0.0 and 237.07, is the percent of the default contrast (gain). The brightness, between -50 and +49.61, is the percent of the maximum pixel value below or above default brightness.

For the PIXCI® SV7, The contrast, between 0.00 and 199.22, is the percent of the default contrast (gain). The brightness, between -76.22 and +75.64 IRE units, is the adjustment below or above default brightness.

The pxd_getContrast and pxd_getBrightness return the current contrast and brightness setting, on the single unit specified by unitmap, with the same interpretation as used for the contrast and brightness parameters of pxd_setContrastBrightness.

The pxd_setHueSaturation sets the A/D hue and saturation, on the multiple units specified by unitmap, to hue Ugain and Vgain.

For the PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, and SV5L: The hue, between -90.0 and 89.30, is the color phase shift, in degrees. The Ugain and Vgain, between 0.0 to 201.68, is the percent of the default U gain and V gain, respectively.

For the PIXCI® SV7: The hue, between -45.0 and 45.0, is the color phase shift, in degrees. The Ugain between 0.0 to 199.22, is the percent of the default saturation. The Vgain is not used.

The pxd_getHue, pxd_getUgain, and pxd_getVgain return the current hue, U gain, and V gain on the single unit specified by unitmap, with the same interpretation as used for the hue, Ugain, and Vgain parameters of pxd_setHueSaturation.


Returns

The pxd_getVidMux, pxd_getContrast, pxd_getBrightness, pxd_getHue, pxd_getUGain, and pxd_getVGain returns values as described above, or 0 if the library is not open for use or the wrong imaging board is in use.

The pxd_setVidMux, pxd_setContrastBrightness, and pxd_setHueSaturation return:


0
Function performed.

PXERNOTOPEN
The library is not open for use.

PXERNOOPTION
Wrong imaging board.

PXER...
Other error codes as appropriate.

Video Snap and Wait --- pxd_doSnap



Summary
int pxd_doSnap(unitmap, buffer, timeout);

int unitmap; // Unit selection bit map (1 for single unit) pxbuffer_t buffer; // Image frame buffer ulong timeout; // Snap timeout, in milliseconds int



Description

The pxd_doSnap initiates capture of a single image into the buffer, on each of the multiple units specified by unitmap, and waits for capture to be complete before returning.

The timeout specifies a period of time after which the snap should be aborted and the function return without having completed acquisition of a frame buffer. If timeout=0, a default timeout, as appropriate for the current video format configuration, is used; if unitmap selects multiple imaging boards and the multiple boards are being operated with different video format configurations, the default timeout used is the maximum of the defaults for each of the selected imaging boards.

For the PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 imaging board configured for triggered capture, the pxd_doSnap ''arms'' the imaging board to capture the next externally triggered frame, or both ''arms'' and initiates a software triggered frame, according to the Video Format Configuration.


Returns


0
Function performed.

PXERNOTOPEN
The library is not open for use.

PXERRESOURCEBUSY
Video is already being captured and must be terminated before initiating a new capture.

PXERTIMEOUT
The operation was aborted due to timeout.

PXERDEVFAULT
Capture was not completed properly, the pxd_mesgFault may provide additional information.

PXER*
Other error codes as appropriate.

Video Snap --- pxd_goSnap
Video Snap Pair --- pxd_goSnapPair
Video Live --- pxd_goLive
Video Live Pair Alternate --- pxd_goLivePair
Video Live Sequence --- pxd_goLiveSeq
Video UnLive --- pxd_goUnLive
Video Abort --- pxd_goAbortLive



Summary
int pxd_goSnap(unitmap, buffer);
int pxd_goSnapPair(unitmap, buffer1, buffer2);
int pxd_goLive(unitmap, buffer);
int pxd_goLivePair(unitmap, buffer, buffer2);
int pxd_goLiveSeq(unitmap, startbuf, endbuf, incbuf, numbuf, videoperiod);
int pxd_goUnLive(unitmap);
int pxd_goAbortLive(unitmap);

int unitmap; // Unit selection bit map (1 for single unit) pxbuffer_t buffer; // Image frame buffer pxbuffer_t buffer2; // Second image frame buffer pxbuffer_t startbuf; // Starting image frame buffer pxbuffer_t endbuf; // Ending image frame buffer pxbuffer_t incbuf; // Image frame buffer number increment pxbuffer_t numbuf; // Number of captured images int videoperiod; // Period between captured images



Description

The pxd_goSnap initiates capture of a single image into the buffer, on each of the multiple units specified by unitmap.

The pxd_goLive initiates continuous capture of images into the buffer, on each of the multiple units specified by unitmap.

The pxd_goLivePair initiates continuous capture into buffer and buffer2, alternately (i.e. ''ping-pong''), on each of the multiple units specified by unitmap.

The pxd_goLiveSeq initiates sequence capture of images into startbuf through endbuf, on each of the multiple units specified by unitmap. The sequence capture starts into startbuf and continues into frame buffers startbuf+incbuf*1, startbuf+incbuf*2, etc., wrapping around from the endbuf back to the startbuf. Typically incbuf=1 for use of consecutive ascending frame buffers. The numbuf specifies the number image frame buffers to be captured. Typically, numbuf is endbuf-startbuf+1 for simple sequence capture, or 0 for continuous (i.e. ''circular'') sequence capture. The videoperiod specifies the time interval, in video fields or frames, between captured image frame buffers. Typically, videoperiod=1 for video rate capture. For non-interlaced video formats, the videoperiod is in fields. For interlaced video formats, the videoperiod is in units of frames, unless, a) Each image frame buffer is configured to contain only one field, and b) Video ''switching'' is configured to take place after the ''next'', rather than after an ''odd'' or an ''even'' field.

The pxd_goSnapPair initiates capture of a single image into the buffer1 and initiates capture of the following image into the buffer2, on each of the multiple units specified by unitmap; it is intended for use only with cameras with a so-called ''Triggered Dual Exposure'' mode.

The pxd_goUnLive terminates a previously initiated pxd_goLive, pxd_goLivePair, pxd_goLiveSeq, pxd_goLiveTrig, or pxd_goLiveSeqTrig after the current field or frame, on each of the multiple units specified by unitmap.

The pxd_goAbortLive terminates a previously initiated pxd_goSnap, pxd_goLive, pxd_goLivePair, pxd_goLiveSeq, pxd_goLiveTrig, or pxd_goLiveSeqTrig, immediately, even if in the middle of a field, line, or pixel, on each of the multiple units specified by unitmap.

Except for pxd_goAbortLive, these functions return ''immediately'' without waiting for the beginning or conclusion of their stated effect.[28] The pxd_goAbortLive both has effect and returns ''immediately''.

For PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 configured for triggered capture, the pxd_goSnap ''arms'' the imaging board to capture the next externally triggered frame, or both ''arms'' and initiates a software triggered frame, according to the Video Format Configuration.

For PIXCI® CL3SD, the pxd_goAbortLive currently behaves the same as pxd_goUnLive.


Returns


0
Function performed.

PXERNOTOPEN
The library is not open for use.

PXERRESOURCEBUSY
Video is already being captured and must be terminated before initiating a new capture (for pxd_goSnap, pxd_goLive, pxd_goLivePair, or pxd_goLiveSeq).

PXER...
Other error codes as appropriate.



See Also

See pxd_capturedBuffer, pxd_capturedSysTicks, and pxd_capturedFieldCount to determine when an image frame buffer has been captured, and thereby whether the above functions have completed their complete capture (such as for pxd_goSnap) or have completed the next step of their capture process (such as for pxd_goLivePair or pxd_goLiveSeq).

See pxd_goneLive to determine whether any video capture is in progress.

See pxd_doSnap for an alternative to pxd_goSnap that also waits for completion.


Example

This example illustrates a typical video rate analysis task, analyzing one captured video frame while the next video frame is being captured into a different frame buffer.

    pxbuffer_t  lastbuf = 0;
    //
    // Initiate live, alternate, capture
    // in frame buffers 1 and 2.
    //
    pxd_goLivePair(1, 1, 2);
    //
    for (;;) {
        //
        // If a new buffer was not yet captured, wait.
        //
        if (pxd_capturedBuffer(1) == lastbuf) {
            Sleep(5);   // optional
            continue;
        }
        lastbuf = pxd_capturedBuffer(1);
        //
        // Call user-defined processing
        // on one buffer, while video
        // is being captured into the
        // alternate buffer.
        //
        user_process(lastbuf);
    }

Video Live Trigger --- pxd_goLiveTrig



Summary
int pxd_goLiveTrig(unitmap, buffer, gpin10mask,gpout20value,gpout20mask,gpout20when,
                                    gpin30wait,gpin30mask,gpout40value,gpout40mask,
                                    option50,field50,gpout50value,gpout50mask,delay60,
                                    gpout60value,gpout60mask,delay70,field70,capture70,
                                    gpin80mask,gpout80value,gpout80mask);

int unitmap; // Unit selection bit map (1 for single unit) pxbuffer_t buffer; // Image frame buffer
// Phase 1: initial reset of g.p.in: uint gpin10mask; // g.p.in bit mask (for latching g.p.in)
// Phase 2: initial set of g.p.out uint gpout20value; // g.p.out bit values uint gpout20mask; // g.p.out bit mask uint gpout20when; // 0: async to VB, 1: sync to VB
// Phase 3: wait for g.p.in change: uint gpin30wait; // 0: no wait // 1: wait for change as sampled at VB // 3: wait for rising edge as sampled at VB // 5: wait for falling edge as sampled at VB uint gpin30mask; // bit mask
// Phase 4: notify g.p.in change: uint gpout40value; // g.p.out bit values uint gpout40mask; // g.p.out bit mask
// Phase 5 & 6: optional trig control: uint option50; // 0: ignore, 1: do uint field50; // at next PXFIELD_NXT/ODD/EVN field uint gpout50value; // .. g.p.out bit values uint gpout50mask; // .. g.p.out bit mask uint delay60; // wait N fields uint gpout60value; // .. g.p.out bit values uint gpout60mask; // .. g.p.out bit mask
// Phase 7: delay and capture: uint delay70; // wait N fields uint field70; // at next PXFIELD_NXT/ODD/EVN field uint capture70; // 0: capture
// Phase 8: notify capture: uint gpin80mask; // reset g.p.in bits (for latching bits) uint gpout80value; // g.p.out bit values uint gpout80mask; // g.p.out bit mask



Description

The pxd_goLiveTrig initiates triggered capture of a single image into the buffer, on each of the multiple units specified by unitmap, using the General Purpose Input/Output signals to sense external events, and control external devices as described by the gpin10mask through gpout80mask parameters.

The pxd_goLiveTrig is not intended, and not needed for PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 imaging boards where the PIXCI® combined with the camera hardware provides dedicated triggering, typically asynchronous exposure, and ''single-shot'' capabilities. The pxd_goLiveTrig is intended for cameras producing continuous (free-run) video, and where the imaging board's General Purpose Input signals are used to sense external events and implement an initiation or termination of sequence capture without involvement of any special feature of the camera.

The pxd_goLiveTrig implements continuous capture of multiple fields or frames (i.e. effectively a pxd_goLive) into the same buffer which at the appropriate time is terminated (i.e. effectively a pxd_goUnLive) leaving the last captured field or frame.

The pxd_goLiveTrig is not available for PIXCI® SV2 and SV3 imaging boards. For PIXCI® D, D24, and D32 imaging boards, the actual non-zero value of gpin30wait is immaterial; the imaging board's hardware determines the edge sensitivity of the General Purpose Input. See pxd_getGPIn and pxd_getGPOut for discussion of how many General Purpose Inputs and Outputs are available on various imaging boards.


Returns


0
Function performed.

PXERNOTOPEN
The library is not open for use.

PXERRESOURCEBUSY
Video is already being captured and must be terminated before initiating a new capture.

PXER...
Other error codes as appropriate.

Video Live Sequence Trigger --- pxd_goLiveSeqTrig



Summary
int pxd_goLiveSeqTrig(int unitmap, startbuf, endbuf, incbuf, numbuf, videoperiod,
                      rsvd1,rsvd2,trig20wait,trig20slct,trig20delay,rsvd3,rsvd4,
                      rsvd5,rsvd6,rsvd7,rsvd8,rsvd9,trig40wait,trig40slct,
                      trig40delay,rsvd10,rsvd11,rsvd12,rsvd13,rsvd14,rsvd15);

int unitmap; // Unit selection bit map (1 for single unit) pxbuffer_t startbuf; // Starting image frame buffer pxbuffer_t endbuf; // Ending image frame buffer pxbuffer_t incbuf; // Image frame buffer number increment pxbuffer_t numbuf; // Number of captured images int videoperiod; // Period between captured images
uint trig20wait; // Trigger start of sequence upon: // bits 0x001, 0x002, ... : a g.p. input // bits 0x100, 0x200, ... : a g.p. trigger uint trig20slct; // 1: wait for change as sampled at VB // 3: wait for rising edge as sampled at VB // 5: wait for falling edge as sampled at VB pxvbtime_t trig20delay; // Delay effect by .. fields.
uint trig40wait; // Trigger end of sequence upon: // bits 0x001, 0x002, ... : a g.p. input // bits 0x100, 0x200, ... : a g.p. trigger uint trig40slct; // 1: wait for change as sampled at VB // 3: wait for rising edge as sampled at VB // 5: wait for falling edge as sampled at VB pxvbtime_t trig40delay; // Delay effect by .. fields.
int rsvd1; // Reserved, should be 0. ... int rsvd15; // Reserved, should be 0.



Description

The pxd_goLiveSeqTrig initiates sequence capture of images into startbuf through endbuf, on each of the multiple units specified by unitmap. The pxd_goLiveSeqTrig is a variation of pxd_goLiveSeq; the startbuf, endbuf, incbuf, numbuf, and videoperiod parameters have the same effect as the corresponding parameter for pxd_goLiveSeq.

Unlike pxd_goLiveSeq, the pxd_goLiveSeqTrig allows initiating or allows terminating (but currently not both), the sequence capture in response to a General Purpose Input, or a General Purpose Trigger.

While waiting for an initiating input or trigger, the pxd_goLiveSeqTrig implements continuous capture of multiple fields or frames (i.e. effectively a pxd_goLive) into the startbuf.

If trig20wait≠0, the sequence capture starts in response to a General Purpose Input, or a General Purpose Trigger. Bit 0x01 of trig20wait selects the first General Purpose Input, bit 0x02 of trig20wait selects the second General Purpose Input (if any), etc. Bit 0x0100 of trig20wait selects the first General Purpose Trigger, bit 0x0200 of trig20wait selects the second General Purpose Trigger (if any), etc. Only one bit of trig20wait should be set. For General Purpose Inputs, the trig20slct selects which transition is to be used. The effect on the start of sequence capture is delayed by trig20delay fields.

If trig40wait≠0, the sequence capture terminates in response to a General Purpose Input, or a General Purpose Trigger. Bit 0x01 of trig40wait selects the first General Purpose Input, bit 0x02 of trig40wait selects the second General Purpose Input (if any), etc. Bit 0x0100 of trig40wait selects the first General Purpose Trigger, bit 0x0200 of trig40wait selects the second General Purpose Trigger (if any), etc. Only one bit of trig40wait should be set. For General Purpose Inputs, the trig40slct selects which transition is to be used. The effect on the termination of sequence capture is delayed by trig40delay fields.

The pxd_goLiveSeqTrig is not intended, and not needed for PIXCI® CL1, CL2, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 imaging boards where the PIXCI® combined with the camera hardware provides dedicated triggering, typically asynchronous exposure, and ''single-shot'' capabilities. The pxd_goLiveSeqTrig is intended for cameras producing continuous (free-run) video, and where the imaging board's General Purpose Input or General Purpose Trigger signals are used to sense external events and implement an initiation or termination of sequence capture without involvement of any special feature of the camera.

The pxd_goLiveSeqTrig is currently available only for PIXCI® CL1, CL2, CL3SD, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 imaging boards for use with non-interlaced cameras.[29] See pxd_getGPIn and pxd_getGPTrigger for discussion of how many General Purpose Inputs and General Purpose Triggers are available on various imaging boards.


Returns


0
Function performed.

PXERNOTOPEN
The library is not open for use.

PXERRESOURCEBUSY
Video is already being captured and must be terminated before initiating a new capture.

PXER...
Other error codes as appropriate.

Video Initiated Status Check --- pxd_goneLive



Summary
int pxd_goneLive(unitmap, rsvd);
int                 unitmap;        // Unit selection bit map (1 for single unit)
int                 rsvd;           // Reserved, should be 0



Description

The pxd_goneLive returns 0 if video capture via pxd_doSnap, pxd_goSnap, pxd_goLive, pxd_goLivePair, pxd_goLiveSeq, pxd_goLiveTrig, or pxd_goLiveSeqTrig on any of the multiple units specified by unitmap is not currently in effect. Otherwise, a non-zero value is returned.


Returns

As described above.


Get Video Field Count --- pxd_videoFieldCount



Summary
pxvbtime_t pxd_videoFieldCount(unitmap);
int                 unitmap;        // Unit selection bit map (1 for single unit)



Description

The number of elapsed vertical blanking intervals, i.e. video fields, is returned. Video fields are counted regardless of whether or not the field is captured, such as with pxd_goSnap or pxd_goLive. The counter's frequency is dependent upon the video format and/or external video sources; for NTSC or RS-170 the frequency is 60 Hz for CCIR or PAL the frequency is 50 Hz.

For PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, and SV7 imaging boards: The count increments even when no video source is connected to the imaging board. When no video source is connected, these imaging boards substitute an internal ''video'' source, generating a synthetic image that can be captured with pxd_doSnap, pxd_goSnap, pxd_goLive, etc.

For PIXCI® A, A310, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 imaging boards: The count increments only when a video source is connected to the imaging board.


Returns

As described above.


Get Video Field Characteristic --- pxd_videoFieldsPerFrame
Get Video Field Characteristic --- pxd_videoFieldsPerFrames



Summary
int pxd_videoFieldsPerFrame();
int pxd_videoFieldsPerFrames(unitmap);

int unitmap; // Unit selection bit map (1 for single unit)



Description

The number of video fields in each video frame, for the current video format, is returned. This does not return a measured characteristic of the current video signal, but an expectation defined by the current video format.

The similar pxd_imageIdim returns the number of stored fields within a frame buffer, while pxd_videoFieldsPerFrame returns the number of video fields within a video frame. The former may be 1 even if the latter is 2, such as when capturing in a ''field'' mode with each new captured field replacing the former within the ''field buffer''.

If multiple imaging boards are in use and operated at different resolutions, the analogous pxd_videoFieldsPerFrames function allows obtaining characteristics relating to the single selected unit; the pxd_videoFieldsPerFrame provides characteristics for unitmap=1.


Returns

As described above.


Set Video Configuration as per Compiled Include --- pxd_videoFormatAsIncluded
Set Video Configuration as per Compiled Init --- pxd_videoFormatAsIncludedInit



Summary
     pxd_videoFormatAsIncludedInit(rsvd);
int  pxd_videoFormatAsIncluded(rsvd);

int rsvd; // Reserved, should be 0



Description

The pxd_videoFormatAsIncludedInit and pxd_videoFormatAsIncluded are macros that allows configuring XCLIB as per a video format configuration (also referred to as a video state) previously exported by the XCAP program or the XCLIB library. Unlike use of pxd_PIXCIopen which loads a video format configuration from a file at run-time, the pxd_videoFormatAsIncluded changes the video format configuration without closing the XCLIB library, and allows use of a video format configuration which has been compiled into the application.

The expected use of pxd_videoFormatAsIncludedInit and pxd_videoFormatAsIncluded is:

    {
        int r;
        #include "format.fmt"
        pxd_videoFormatAsIncludedInit(0);
        r = pxd_videoFormatAsIncluded(0);
    }
where the ''format.fmt'' is a video format configuration file (also referred to as a video state) previously exported by the XCAP program or the XCLIB library.

A ''format.fmt'' exported from a 64 bit application can't be used by pxd_videoFormatAsIncluded in a 32 bit application, or vice versa.

Some cameras have ''excessive'' serial commands, requiring use of variable length structures within the ''format.fmt''; for such cameras the pxd_videoFormatAsIncluded can only be used if the ''format.fmt'' is exported without serial commands.

When using multiple imaging boards at different formats and resolutions, the pxd_videoFormatAsIncluded only configures the first imaging board; simple variants of the pxd_videoFormatAsIncludedInit macro can be defined to configure each of the other imaging boards.

The pxd_videoFormatAsIncluded terminates any video capture currently in progress, and may result in a change to the values reported by pxd_imageXdim, pxd_imageYdim, pxd_imageCdim, pxd_imageBdim, pxd_imageZdim, pxd_imageIdim, pxd_imageAspectRatio and similar functions.

The XCLIB-Lite library does not support this feature.


Returns


0
Function performed.

PXERNOTOPEN
The library is not open for use.

PXER...
Other error codes as appropriate.



Example

Multiple formats can be included for selection; each must be in its own C/C++ ''block''. For example:

    int selectformat(int format)
    {
        if (format == 0) {
            #include "format0.fmt"
            pxd_videoFormatAsIncludedInit(0);
            pxd_videoFormatAsIncluded(0);
        }
        if (format == 1) {
            #include "format1.fmt"
            pxd_videoFormatAsIncludedInit(0);
            pxd_videoFormatAsIncluded(0);
        }
        ...
    }

Escape to Access Structured Interface Services --- pxd_xclibEscape
Escaped to Access Structured Interface Services --- pxd_xclibEscaped



Summary
struct xclibs * pxd_xclibEscape(rsvd1, rsvd2, rsvd3);
int             pxd_xclibEscaped(rsvd1, rsvd2, rsvd3);

int rsvd1; // Reserved, should be 0 int rsvd2; // Reserved, should be 0 int rsvd3; // Reserved, should be 0



Description

The pxd_xclibEscape provides a reference to a xclibs structure with which Structured Interface services can be accessed; that is, the same xclibs used by pxd_PIXCIopen when it invoked xclib_open.

The pxd_xclibEscaped should be invoked after Structured Interface services have been accessed via the xclibs provided by pxd_xclibEscape.

These functions are intended for use only upon advice of EPIX, Inc. Technical Support, to allow special extensions to the SCF Style Interface.


Returns

The pxd_xclibEscape returns a reference to a xclibs structure, or NULL if XCLIB is not currently open via pxd_PIXCIopen.

The pxd_xclibEscaped returns:


0
Function performed.

PXER...
Other error codes as appropriate.

Set SILICON VIDEO Exposure, Gain, and Offset --- pxd_SILICONVIDEO_setExposureGainOffset
Set SILICON VIDEO Exposure, Gains, and Offsets --- pxd_SILICONVIDEO_setExposureColorGainOffsets
Set SILICON VIDEO Exposure --- pxd_SILICONVIDEO_setExposure
Get SILICON VIDEO Exposure --- pxd_SILICONVIDEO_getExposure
Get SILICON VIDEO Gain A --- pxd_SILICONVIDEO_getGainA
Get SILICON VIDEO Gain B --- pxd_SILICONVIDEO_getGainB
Get SILICON VIDEO Color Gains A --- pxd_SILICONVIDEO_getGainsA
Get SILICON VIDEO Color Gains B --- pxd_SILICONVIDEO_getGainsB
Get SILICON VIDEO Color Offset A --- pxd_SILICONVIDEO_getOffsetA
Get SILICON VIDEO Color Offset B --- pxd_SILICONVIDEO_getOffsetB
Get SILICON VIDEO Color Offsets A --- pxd_SILICONVIDEO_getOffsetsA
Get SILICON VIDEO Color Offsets B --- pxd_SILICONVIDEO_getOffsetsB



Summary
int    pxd_SILICONVIDEO_setExposureGainOffset(unitmap,rsvd,exposure,gainA,offsetA,
                                              gainB,offsetB);
int    pxd_SILICONVIDEO_setExposureColorGainOffsets(unitmap,rsvd,exposure,
                                              gainsA,gainsB,offsetsA,offsetsB);
double pxd_SILICONVIDEO_getExposure(unitmap);
double pxd_SILICONVIDEO_getGainA(unitmap);
double pxd_SILICONVIDEO_getGainB(unitmap);
int    pxd_SILICONVIDEO_getGainsA(unitmap,gainsA);
int    pxd_SILICONVIDEO_getGainsB(unitmap,gainsB);
double pxd_SILICONVIDEO_getOffsetA(unitmap);
double pxd_SILICONVIDEO_getOffsetB(unitmap);
int    pxd_SILICONVIDEO_getOffsetsA(unitmap,offsetsA);
int    pxd_SILICONVIDEO_getOffsetsB(unitmap,offsetsB);

int unitmap; // Unit selection bit map (1 for single unit) int rsvd; // Reserved, should be 0 double exposure; // Exposure period, in milliseconds double gainA; // Pre-gain, in dB. double gainB; // Post-gain, in dB. double offsetA; // Pre-offset, scaled to 1.0 for max pixel value double offsetB; // Post-offset, scaled to 1.0 for max pixel value double[4] gainsA; // Color specific A-gains, Gb/B/R/Gr, in dB, or NULL double[4] gainsB; // Color specific B-gains, Gb/B/R/Gr, in dB, or NULL double[4] offsetsA; // Color specific A-offsets, Gb/B/R/Gr, // scaled to 1.0 for max pixel value, or NULL double[4] offsetsB; // Color specific B-offsets, Gb/B/R/Gr, // scaled to 1.0 for max pixel value, or NULL



Description

The pxd_SILICONVIDEO_setExposureGainOffset, pxd_SILICONVIDEO_setExposureColorGainOffsets, and pxd_SILICONVIDEO_setExposure, sets the exposure (shutter) period, gain and offsets (black level) of SILICON VIDEO® 1281M, SILICON VIDEO® 1281C, SILICON VIDEO® 1310, SILICON VIDEO® 1310C, SILICON VIDEO® 2112, and SILICON VIDEO® 2112C cameras connected to PIXCI® D2X and D2X1 imaging boards, of SILICON VIDEO® 5C10, SILICON VIDEO® 5M10, SILICON VIDEO® 642M, SILICON VIDEO® 642C, SILICON VIDEO® 643M, SILICON VIDEO® 643C, SILICON VIDEO® 9C10, SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 9M001, SILICON VIDEO® 9M001C, SILICON VIDEO® 9T001C, SILICON VIDEO® HAS21, SILICON VIDEO® WGA-C, and SILICON VIDEO® WGA-M cameras connected to PIXCI® SI, SI1, SI2, and SI4 imaging boards, and of SILICON VIDEO® 10C-CL and SILICON VIDEO® 10M-CL, cameras connected to PIXCI® EB1-PoCL and E8 imaging boards.

The camera's exposure (shutter) period is set to exposure milliseconds. The allowable values are dependent on the camera's current operating mode, such as the pixel clock frequency, AOI width and height, and subsampling.

The camera's per-color A-gain for green-next-to-blue, blue, red, and green-next-to-red is set to gainsA[0], gainsA[1], gainsA[2], and gainsA[3] dB, respectively. For cameras that do not implement per-color A-gain, the gain is set to the average of gainsA[0], gainsA[1], gainsA[2], and gainsA[3]. For cameras that only provide color A-gain for red, green, and blue the gains are set to gainsA[2], gainsA[1], and the average of gainsA[0] and gainsA[3], respectively. Alternately, the camera's A-gain(s), whether the camera provides per-color gains or not, are each set to gainA dB.

The camera's per-color, or non-per-color B-gain is set to gainsB and/or gainB dB, following the same conversion rules for per-color vs non-per-color cameras as above.

The camera's per-color, or non-per-color A-offset (black level) is set to offsetsA and/or offsetA, following the same conversion rules for per-color vs non-per-color cameras as above. The camera's per-color, or non-per-color B-offset (black level) is set to offsetsB and/or offsetB, following the same conversion rules for per-color vs non-per-color cameras as above. The offsetsA, offsetA, offsetsB, and offsetB are interpreted such that increased values of offset cause increased pixel values, and are scaled such that an offset of 1.0 or -1.0 corresponds to the maximum pixel value or its negative. However, various camera models do not necessarily provide the full range of offsets. Also, for cameras that implement an analog offset, the correspondance to maximum pixel value is only approximate.

Each of the gainsA, gainsB, offsetsA, and offsetsB may be NULL; the camera's corresponding gain or offset is unchanged.

    pxd_SILICONVIDEO_setExposureColorGainOffsets(..., 0, exposure,
                                                 NULL, NULL, NULL, NULL);
is a convenient method of changing only the camera's exposure.

Some cameras may not provide A-gain, B-gain, A-offset, or B-offset; the corresponding values are ignored. Any invalid exposure, gain, or offset value is corrected to the nearest valid value.

The pxd_SILICONVIDEO_getExposure returns the current exposure setting, in milliseconds.

The pxd_SILICONVIDEO_getGainA returns the current A-gain, in dB. For cameras with per-color A-gain, the average value is returned. The pxd_SILICONVIDEO_getGainsA ''returns'' the current per-color A-gain, in dB in gainsA. For cameras without per-color A-gain, the four elements of gainsA are set to the gain. For cameras with per-color red, green, and blue gain, the gainsA[0] and gainsA[3] are both set to the green gain.

The pxd_SILICONVIDEO_getGainB returns the current B-gain, in dB; the pxd_SILICONVIDEO_getGainsB ''returns'' the current per-color B-gain, in dB in gainsB; following the same conversion rules for per-color vs non-per-color cameras as above.

The pxd_SILICONVIDEO_getOffsetA returns the current A-offset; the pxd_SILICONVIDEO_getOffsetsA ''returns'' the current per-color A-offset, in offsetsA; the pxd_SILICONVIDEO_getOffsetB returns the current B-offset; the pxd_SILICONVIDEO_getOffsetsB ''returns'' the current per-color B-offset, in offsetsB; following the same conversion rules for per-color vs non-per-color cameras as above, all scaled such that an offset of 1.0 or -1.0 corresponds to the maximum pixel value or its negative.

Some cameras may not provide A-gain, B-gain, A-offset, and/or B-offset; a value of 0 is returned.

Note: The pxd_PIXCIopen performs partial, quick initialization of XCLIB; initialization for the pxd_SILICONVIDEO_ functions is delayed until the first such function is called. Time sensitive applications should call any pxd_SILICONVIDEO_set or pxd_SILICONVIDEO_get function once before entering the application's time critical phase.

Note: The relative order of the gain and offset parameters differ between pxd_SILICONVIDEO_setExposureGainOffset and pxd_SILICONVIDEO_setExposureColorGainOffsets. It is not a typographical error.


Camera Specific. For SILICON VIDEO® 1281M and SILICON VIDEO® 1281C: The camera provides a single A-gain in the range of 3.5 to 31.9 dB. The camera provides a single A-offset in the range of 0 to .24.

For SILICON VIDEO® 1310 and SILICON VIDEO® 1310C: The camera provides a single A-gain in the range of -23.2 to 17.50 dB and green-next-to-blue, blue, red, and green-next-to-red B-gain in the range of -23.2 to 8.8 dB. The camera provides a single A-offset in the range of -.11 to +11. Different per-color gains can be set for the SILICON VIDEO® 1310 (i.e. monochrome) camera - the gain settings affect various pixels according to their placement in what would be a Bayer pattern. Normally, the gains are identical for monochrome cameras.

For SILICON VIDEO® 2112 and SILICON VIDEO® 2112C: The camera provides red, green, and blue A-gain each in the range of 0.0 to 14.0 dB. Different per-color gains can be set for the SILICON VIDEO® 2112 (i.e. monochrome) camera - the gain settings affect various pixels according to their placement in what would be a Bayer pattern. Normally, the gains are identical for monochrome cameras.

For SILICON VIDEO® 5C10 and SILICON VIDEO® 5M10: The camera provides green-next-to-blue, blue, red, and green-next-to-red integrated analog/digital A-gain in the range of 0 to 42.1 dB. Different per-color gains can be set for the SILICON VIDEO® 5M10 (i.e. monochrome) camera - the gain settings affect various pixels according to their placement in what would be a Bayer pattern. Normally, the gains are identical for monochrome cameras.

For SILICON VIDEO® 642M and SILICON VIDEO® 642C: The camera provides green-next-to-blue, blue, red, and green-next-to-red A-gain in the range of -6.0 to 19.1 dB in low gain range mode, or 0 to 25.1 dB in high gain range mode. Different per-color gains can be set for the SILICON VIDEO® 642M (i.e. monochrome) camera - the gain settings affect various pixels according to their placement in what would be a Bayer pattern. Normally, the gains are identical for monochrome cameras.

For SILICON VIDEO® 643M and SILICON VIDEO® 643C: The camera provides a single A-gain in the range of 0 to 23.7 dB. The camera provides a single A-offset in the range of 0 to 2.5.

For SILICON VIDEO® 9C10: The camera provides green-next-to-blue, blue, red, and green-next-to-red analog A-gain in the range of 0 to 27.5 dB. The camera provides a single digital B-gain in the range of 0 to 16.9 dB.

For SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 10C-CL, and SILICON VIDEO® 10M-CL: The camera provides green-next-to-blue, blue, red, and green-next-to-red analog A-gain in the range of 0 to 30.0 dB. The camera provides a single digital B-gain in the range of 0 to 16.9 dB. Different per-color gains can be set for the SILICON VIDEO® 10M6 (i.e. monochrome) camera - the gain settings affect various pixels according to their placement in what would be a Bayer pattern. Normally, the gains are identical for monochrome cameras.

For SILICON VIDEO® 9M001 and SILICON VIDEO® 9M001C: The camera provides green-next-to-blue, blue, red, and green-next-to-red analog A-gain in the range of 0 to 23.5 dB. Different per-color gains can be set for the SILICON VIDEO® 9M001 (i.e. monochrome) camera - the gain settings affect various pixels according to their placement in what would be a Bayer pattern. Normally, the gains are identical for monochrome cameras.

For SILICON VIDEO® 9T001C: The camera provides green-next-to-blue, blue, red, and green-next-to-red integrated analog/digital A-gain in the range of 0 to 42.1 dB.

For SILICON VIDEO® HAS21: The camera provides a single PGA A-gain in the range of 0.0 to 18.1 dB. The camera provides a single PGA A-offset in the range of 0.3 to 1.3 V; the offset is not normalized so that an offset of 1.0 or -1.0 corresponds to the maximum pixel value or its negative.

For SILICON VIDEO® WGA-C and SILICON VIDEO® WGA-M: The camera provides a single analog A-gain in the range of 0 to 12.0 dB. The camera provides a single digital B-gain in the range of 0 to 11.5 dB.


Returns

The pxd_SILICONVIDEO_getGainA, pxd_SILICONVIDEO_getGainB, pxd_SILICONVIDEO_getOffsetA, and pxd_SILICONVIDEO_getOffsetB return values as described above, or 0 if the library is not open for use, or the wrong imaging board is in use.

The remaining functions return:


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Set SILICON VIDEO Resolution and Timing --- pxd_SILICONVIDEO_setResolutionAndTiming
Get SILICON VIDEO Subsample --- pxd_SILICONVIDEO_getSubsample
Get SILICON VIDEO Aoi Left Edge --- pxd_SILICONVIDEO_getAoiLeft
Get SILICON VIDEO Aoi Top Edge --- pxd_SILICONVIDEO_getAoiTop
Get SILICON VIDEO Aoi Width --- pxd_SILICONVIDEO_getAoiWidth
Get SILICON VIDEO Aoi Height --- pxd_SILICONVIDEO_getAoiHeight
Get SILICON VIDEO Scan Direction --- pxd_SILICONVIDEO_getScanDirection
Get SILICON VIDEO Pixel Clock Frequency --- pxd_SILICONVIDEO_getPixelClock
Get SILICON VIDEO Frame Period --- pxd_SILICONVIDEO_getFramePeriod



Summary
int     pxd_SILICONVIDEO_setResolutionAndTiming(unitmap,rsvd1,subsample,aoileft,aoitop,aoiwidth,
                                    aoiheight,scandirection,bitdepth,rsvd3,rsvd4,pixelClkFreq,
                                    framePeriod,rsvd5,rsvd6,rsvd7);
int     pxd_SILICONVIDEO_getSubsample(unitmap);
int     pxd_SILICONVIDEO_getAoiLeft(unitmap);
int     pxd_SILICONVIDEO_getAoiTop(unitmap);
int     pxd_SILICONVIDEO_getAoiWidth(unitmap);
int     pxd_SILICONVIDEO_getAoiHeight(unitmap);
int     pxd_SILICONVIDEO_getScanDirection(unitmap);
double  pxd_SILICONVIDEO_getPixelClock(unitmap);
double  pxd_SILICONVIDEO_getFramePeriod(unitmap);

int unitmap; // Unit selection bit map (1 for single unit) int rsvd1; // Reserved, should be 0 int rsvd3; // Reserved, should be 0 int rsvd4; // Reserved, should be 0 double rsvd5; // Reserved, should be 0 double rsvd6; // Reserved, should be 0 double rsvd7; // Reserved, should be 0 int subsample; // Subsample/decimation // High byte X, Low byte Y, 0x0101 for none int aoileft; // Left edge of partial scan AOI int aoitop; // Top edge of partial scan AOI int aoiwidth; // Width of partial scan AOI int aoiheight; // Height of partial scan AOI // aoi* are in reference to sensor // and independent of subsampling int scandirection; // ('L'<<8)|'T': Left-Right/Top-Bottom (default) // ('L'<<8)|'B': Left-Right/Bottom-Top // ('R'<<8)|'T': Right-Left/Top-Bottom // ('R'<<8)|'B': Right-Left/Bottom-Top int bitdepth; // bits per pixel value component double pixelClkFreq; // Pixel clock frequency, in MHz. double framePeriod; // Frame period, in msec.



Description

The pxd_SILICONVIDEO_setResolutionAndTiming sets the pixel clock frequency, frame period (in free-run modes), pixel bit depth, scan direction, partial scan AOI, and subsampling/decimation of SILICON VIDEO® 1281M, SILICON VIDEO® 1281C, SILICON VIDEO® 1310, SILICON VIDEO® 1310C, SILICON VIDEO® 2112, and SILICON VIDEO® 2112C cameras connected to PIXCI® D2X and D2X1 imaging boards, of SILICON VIDEO® 5C10, SILICON VIDEO® 5M10, SILICON VIDEO® 642M, SILICON VIDEO® 642C, SILICON VIDEO® 643M, SILICON VIDEO® 643C, SILICON VIDEO® 9C10, SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 9M001, SILICON VIDEO® 9M001C, SILICON VIDEO® 9T001C, SILICON VIDEO® HAS21, SILICON VIDEO® WGA-C, and SILICON VIDEO® WGA-M cameras connected to PIXCI® SI, SI1, SI2, and SI4 imaging boards, and of SILICON VIDEO® 10C-CL and SILICON VIDEO® 10M-CL, cameras connected to PIXCI® EB1-PoCL and E8 imaging boards.

The subsample selects readout subsampling of the sensor. If subsample=0x0101, subsampling is disabled, if subsample=0x0202, the readout and captured image consists of every 2'nd pixel, both horizontally and vertically, if subsample=0x0404, the readout and captured image consists of every 4'th pixel, both horizontally and vertically. If subsample=V+H*256, the readout and captured image consists of every H'th pixel horizontally and V'th pixel vertically. On some cameras, the subsample may select bin-averaging of W×H groups of pixels, or bin-summing of W×H groups of pixels; in all cases, the common effect of subsample is to reduce the resulting image resolution by a factor of H horizontally and V vertically.

The aoileft, aoitop, aoiwidth, and aoiheight select partial scan readout of the sensor, selecting the coordinates of the left edge and top edge of the readout AOI, and width and height of the readout AOI. These parameters are always relative to the sensor's full resolution, and are not to be scaled due to use of subsample.

The scandirection selects readout scan direction. If scandirection=('L'<<8)|'T', the readout is left to right, top to bottom and is the normal default. If scandirection=('L'<<8)|'B', the readout is left to right, bottom to top. If scandirection=('R'<<8)|'T', the readout is right to left, top to bottom; if scandirection=('R'<<8)|'B', the readout is right to left, bottom to top.

The bitdepth selects the bit depth of each pixel value component; i.e. for color pixels, it is the bit depth of each color component.

The pixelClkFreq specifies the sensor's pixel clock frequency, in MHz. Lower frequencies provide for longer exposures, but slower frame rates. Higher frequencies provide higher frame rates, but shorter exposures and typically more fixed pattern noise.

The framePeriod specifies the sensor's frame period, or inverse of frame rate, in free-run mode, in milliseconds. A longer frame period allows for longer exposures.

Some cameras may not provide subsampling, partial scan, scan direction, selectable bit depth, selectable pixel clock, or selectable frame period; the corresponding values are ignored. Any invalid values are corrected to the nearest valid value. In particular, framePeriod=0 can be used to specify the minimum frame period (maximum frame rate) obtainable with the specified subsample, aoileft, aoitop, aoiwidth, aoiheight, bitdepth, and pixelClkFreq.

The pxd_SILICONVIDEO_getSubsample returns the current subsample setting, coded as described above.

The pxd_SILICONVIDEO_getAoiLeft, pxd_SILICONVIDEO_getAoiTop, pxd_SILICONVIDEO_getAoiWidth, and pxd_SILICONVIDEO_getAoiHeight return the current partial scan AOI left and top edges, and width and height, respectively. These parameters are always relative to the sensor's full resolution, and are not scaled due to use of subsample.

The pxd_SILICONVIDEO_getScanDirection returns the current scan direction setting, coded as described above.

The pxd_SILICONVIDEO_getPixelClock returns the current pixel clock frequency, as described above.

The pxd_SILICONVIDEO_getFramePeriod returns the current frame period, or inverse of frame rate, as described above.


Camera Specific. For SILICON VIDEO® 1281M and SILICON VIDEO® 1281C: The camera does not provide subsampling, selectable scan direction, or selectable bit depth. The allowable frame period depends on the pixel clock frequency, AOI height, and AOI width.

For SILICON VIDEO® 1310 and SILICON VIDEO® 1310C: The camera supports subsampling ×1, ×2, ×4, and ×8 both horizontally and vertically, in all combinations. The camera supports all four scan directions. The camera supports 8 and 10 bit depths. The allowable frame period depends on the pixel clock frequency, subsampling, AOI height, and AOI width.

For SILICON VIDEO® 2112 and SILICON VIDEO® 2112C: The camera supports subsampling ×1, ×2, and ×4 both horizontally and vertically, in all combinations. The camera supports all four scan directions. The camera supports 8 and 10 bit depths. The allowable frame period depends on the pixel clock frequency, subsampling, and AOI height.

For SILICON VIDEO® 5C10 and SILICON VIDEO® 5M10: The camera supports subsampling ×1, ×2, and ×4 horizontally and subsampling ×1, ×2, ×4, and ×8 vertically, in all combinations. The camera supports all four scan directions. The camera supports 8 and 12 bit depths. The allowable frame period depends on the pixel clock frequency, subsampling, AOI height, and AOI width.

For SILICON VIDEO® 642M and SILICON VIDEO® 642C: The camera does not provide subsampling or selectable scan direction. The camera supports 8 and 10 bit depths. The allowable frame period depends on the pixel clock frequency and AOI height.

For SILICON VIDEO® 643M and SILICON VIDEO® 643C: The camera does not provide subsampling or selectable scan direction. The camera supports 8 and 10 bit depths. The allowable frame period depends on the pixel clock frequency, AOI height, and AOI width.

For SILICON VIDEO® 9C10: The camera supports subsampling ×1, ×2, and ×4 horizontally and subsampling ×1, ×2, ×4, ×8, ×16, and ×32 vertically, in all combinations. The camera supports all four scan directions. The camera supports 8 and 12 bit depths. The allowable frame period depends on the pixel clock frequency, subsampling, AOI height, and AOI width.

For SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 10C-CL, and SILICON VIDEO® 10M-CL: The camera supports subsampling ×1, ×2, and ×4 horizontally and subsampling ×1, ×2, ×4, ×8, ×16, and ×32 vertically, in all combinations. The camera supports all four scan directions. The camera supports 8 and 12 bit depths. The allowable frame period depends on the pixel clock frequency, subsampling, AOI height, and AOI width. The pixel clock frequency is not adjustable for SILICON VIDEO® 10C-CL and SILICON VIDEO® 10M-CL cameras.

For SILICON VIDEO® 9M001 and SILICON VIDEO® 9M001C: The camera supports subsampling ×1, ×2, ×4, and ×8 both horizontally and vertically, in all combinations. The camera supports ('L'<<8)|'T' and ('L'<<8)|'B' scan directions. The camera supports 8 and 10 bit depths. The allowable frame period depends on the pixel clock frequency, subsampling, AOI height, and AOI width.

For SILICON VIDEO® 9T001C: The camera supports subsampling ×1, ×2, ×4, and ×8 both horizontally and vertically, in all combinations. The camera does not provide selectable scan direction. The camera supports 8 and 10 bit depths. The allowable frame period depends on the pixel clock frequency, subsampling, AOI height, and AOI width.

For SILICON VIDEO® HAS21: The allowable frame period depends on the pixel clock frequency, AOI height, AOI width, and exposure.

For SILICON VIDEO® WGA-C and SILICON VIDEO® WGA-M: The camera supports subsampling ×1, ×2, and ×4 vertically. The camera supports all four scan directions. The camera supports 8 and 10 bit depths. The allowable frame period depends on the pixel clock frequency, subsampling, AOI height, and AOI width.


Returns

The pxd_SILICONVIDEO_getSubsample, pxd_SILICONVIDEO_getAoiLeft, pxd_SILICONVIDEO_getAoiTop, pxd_SILICONVIDEO_getAoiTop, pxd_SILICONVIDEO_getAoiTop, pxd_SILICONVIDEO_getScanDirection, pxd_SILICONVIDEO_getPixelClock, and pxd_SILICONVIDEO_getFramePeriod returns values as described above, or 0 if the library is not open for use, or the wrong imaging board is in use.

The remaining functions return:


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Set SILICON VIDEO Video And Trigger Modes --- pxd_SILICONVIDEO_setVideoAndTriggerMode
Set SILICON VIDEO Controlled Rates --- pxd_SILICONVIDEO_setCtrlRates
Get SILICON VIDEO Video Mode --- pxd_SILICONVIDEO_getVideoMode
Get SILICON VIDEO Controlled Frame Rate --- pxd_SILICONVIDEO_getCtrlFrameRate
Get SILICON VIDEO Controlled Video Mode --- pxd_SILICONVIDEO_getCtrlVideoMode
Get SILICON VIDEO Controlled Trigger Mode --- pxd_SILICONVIDEO_getCtrlTriggerMode



Summary
int    pxd_SILICONVIDEO_setVideoAndTriggerMode(unitmap,rsvd,videomode,controlledmode,
                                        controlledtrigger,rsvd1,rsvd2,rsvd3,rsvd4);
int    pxd_SILICONVIDEO_setCtrlRates(unitmap,rsvd,rsvd11,framerate,rsvd12,rsvd13,rsvd14);
int    pxd_SILICONVIDEO_getVideoMode(unitmap);
int    pxd_SILICONVIDEO_getCtrlVideoMode(unitmap);
double pxd_SILICONVIDEO_getCtrlFrameRate(unitmap);
int    pxd_SILICONVIDEO_getCtrlTriggerMode(unitmap);

int unitmap; // Unit selection bit map (1 for single unit) int rsvd; // Reserved, should be 0 int rsvd1; // Reserved, should be 0 int rsvd2; // Reserved, should be 0 int rsvd3; // Reserved, should be 0 int rsvd4; // Reserved, should be 0 double rsvd11; // Reserved, should be 0 double rsvd12; // Reserved, should be 0 double rsvd13; // Reserved, should be 0 double rsvd14; // Reserved, should be 0 int videomode; // Camera video mode: // 'f': free-run, // 'c': controlled/triggered // 'c'|('g'<<8) controlled w. global reset int controlledmode; // Controlled mode: 'c': continuous, 's': singleshot int triggermode; // Controlled trigger: 'n': none, 'b': snap function // '+': rising, '-': falling, ' double framerate; // Controlled frame rate, Hz. // Or inverse is singleshot min. retrigger period, sec.



Description

The pxd_SILICONVIDEO_setVideoAndTriggerMode sets the video and trigger modes of SILICON VIDEO® 1281M, SILICON VIDEO® 1281C, SILICON VIDEO® 1310, SILICON VIDEO® 1310C, SILICON VIDEO® 2112, and SILICON VIDEO® 2112C cameras connected to PIXCI® D2X and D2X1 imaging boards, of SILICON VIDEO® 5C10, SILICON VIDEO® 5M10, SILICON VIDEO® 642M, SILICON VIDEO® 642C, SILICON VIDEO® 643M, SILICON VIDEO® 643C, SILICON VIDEO® 9C10, SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 9M001, SILICON VIDEO® 9M001C, SILICON VIDEO® 9T001C, SILICON VIDEO® HAS21, SILICON VIDEO® WGA-C, and SILICON VIDEO® WGA-M cameras connected to PIXCI® SI, SI1, SI2, and SI4 imaging boards, and of SILICON VIDEO® 10C-CL and SILICON VIDEO® 10M-CL, cameras connected to PIXCI® EB1-PoCL and E8 imaging boards.

Within controlled/trigger mode(s), the pxd_SILICONVIDEO_setCtrlRates sets the controlled frame rate.

If videomode='f', the camera is free-running; the controlledmode, triggermode, and framerate parameters have no effect.

If videomode='c', or videomode='c'|('g'<<8), initiation of each video field is controlled via the PIXCI® imaging board. If controlledmode='c' and triggermode='n' video fields are continuously and automatically triggered. The framerate specifies the field repetition rate. If controlledmode='s' and triggermode='b', video fields are triggered only upon demand; video fields are triggered by pxd_doSnap or pxd_goSnap, the trigger signal is not used.

If controlledmode='s' and triggermode='+' or triggermode='-', video fields are triggered only upon demand; video fields are triggered by a rising or falling, respectively, edge of the trigger signal; the pxd_doSnap or pxd_goSnap must be invoked before the hardware trigger so as to ''arm'' the imaging board. The framerate specifies the inverse of the minimum retrigger period after a trigger, any additional trigger signals arriving within the minimum retrigger period are ignored; use 1.0E99 (or other excessively large frame rate) to obtain the minimal retrigger period and effectively disable same.

The pxd_SILICONVIDEO_getVideoMode, pxd_SILICONVIDEO_getCtrlVideoMode, and pxd_SILICONVIDEO_getCtrlTriggerMode, returns the camera's video mode, the controlled video mode, and the controlled trigger mode, respectively, coded as described above. The pxd_SILICONVIDEO_getCtrlFrameRate returns the controlled frame rate, in Hz.

The pxd_SILICONVIDEO_setVideoAndTriggerMode and pxd_SILICONVIDEO_setCtrlRates eliminate having to use ''raw'' values via pxd_setExsyncPrin to set the controlled exposure and/or frame rate.


Camera Specific. For SILICON VIDEO® 1281M and SILICON VIDEO® 1281C: The camera supports free-run mode with videomode='f' and controlled mode with videomode='c'.

For SILICON VIDEO® 1310 and SILICON VIDEO® 1310C: The camera supports free-run mode with videomode='f' and controlled mode with videomode='c'.

For SILICON VIDEO® 2112 and SILICON VIDEO® 2112C: The camera supports free-run mode with videomode='f' and controlled mode with videomode='c'.

For SILICON VIDEO® 5C10 and SILICON VIDEO® 5M10: The camera supports free-run mode with videomode='f'; controlled mode with videomode='c' selecting rolling reset and rolling shutter, providing the same exposure period for each line, but lines are exposed in succession; and controlled mode with videomode='c'|('g'<<8) selecting global reset and rolling shutter, providing shorter delay from trigger to exposure, but expecting use of strobed flash illumination.

For SILICON VIDEO® 642M and SILICON VIDEO® 642C: The camera supports free-run mode with videomode='f' and controlled mode with videomode='c'.

For SILICON VIDEO® 643M and SILICON VIDEO® 643C: The camera supports free-run mode with videomode='f' and controlled mode with videomode='c'.

For SILICON VIDEO® 9C10: The camera supports free-run mode with videomode='f'; and controlled mode with videomode='c'|('g'<<8) selecting global reset and rolling shutter, providing shorter delay from trigger to exposure, but expecting use of strobed flash illumination.

For SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 10C-CL, and SILICON VIDEO® 10M-CL: The camera supports free-run mode with videomode='f'; and controlled mode with videomode='c'|('g'<<8) selecting global reset and rolling shutter, providing shorter delay from trigger to exposure, but expecting use of strobed flash illumination.

For SILICON VIDEO® 9M001 and SILICON VIDEO® 9M001C: The camera supports free-run mode with videomode='f' and controlled mode with videomode='c'.

For SILICON VIDEO® 9T001C: The camera supports free-run mode with videomode='f'; controlled mode with videomode='c' selecting rolling reset and rolling shutter, providing the same exposure period for each line, but lines are exposed in succession; and controlled mode with videomode='c'|('g'<<8) selecting global reset and rolling shutter, providing shorter delay from trigger to exposure, but expecting use of strobed flash illumination.

For SILICON VIDEO® HAS21: The camera supports free-run mode with videomode='f' and controlled mode with videomode='c'.

For SILICON VIDEO® WGA-M and SILICON VIDEO® WGA-C: The camera supports free-run mode with videomode='f' and controlled mode with videomode='c'.


Returns

The pxd_SILICONVIDEO_getVideoMode, pxd_SILICONVIDEO_getCtrlVideoMode, pxd_SILICONVIDEO_getCtrlTriggerMode, and pxd_SILICONVIDEO_getCtrlFrameRate, returns values as described above, or 0 if the library is not open for use, or the wrong imaging board is in use.

The pxd_SILICONVIDEO_setVideoAndTriggerMode and pxd_SILICONVIDEO_setCtrlRates returns:


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Set SILICON VIDEO AGC and AEC --- pxd_SILICONVIDEO_setAxC
Get SILICON VIDEO AGC A Gain --- pxd_SILICONVIDEO_getAgcA
Get SILICON VIDEO AGC B Gain --- pxd_SILICONVIDEO_getAgcB
Get SILICON VIDEO AEC Exposure --- pxd_SILICONVIDEO_getAec



Summary
int    pxd_SILICONVIDEO_setAxC(unitmap,rsvd,agcA,agcB,rsvd2,rsvd3,aec,
                                              rsvd4,rsvd5,rsvd6,rsvd7);
int    pxd_SILICONVIDEO_getAgcA(unitmap);
int    pxd_SILICONVIDEO_getAgcB(unitmap);
int    pxd_SILICONVIDEO_getAec(unitmap);

int unitmap; // Unit selection bit map (1 for single unit) int rsvd; // Reserved, should be 0 int agcA; // AGC for A-gain. 0: off, >0: AGC rate int agcB; // AGC for B-gain. 0: off, >0: AGC rate int aec; // AEC. 0: off, >0: AEC rate int rsvd2; // Reserved, should be -1 int rsvd3; // Reserved, should be -1 int rsvd4; // Reserved, should be -1 int rsvd5; // Reserved, should be -1 int rsvd6; // Reserved, should be -1 int rsvd7; // Reserved, should be -1



Description

The pxd_SILICONVIDEO_setAxC sets the automatic gain control (AGC) and automatic exposure control (AEC) hardware features of SILICON VIDEO® WGA-C and SILICON VIDEO® WGA-M cameras connected to PIXCI® D2X, D2X1, SI, SI1, SI2, and SI4 imaging boards.

If agcA=0, the AGC control of the camera's A-gain is disabled. If agcA>0, the AGC control of the camera's A-gain is enabled, the value of agcA sets the AGC ''speed'', the degree to which AGC responds to, or ignores, transient changes in image brightness. Larger values select quicker responses to changes.

The agcB is similar, affecting the B-gain.

The aec is similar, affecting the exposure.

Some cameras may not provide A-gain, B-gain, or exposure automatic control; the corresponding values are ignored.

The pxd_SILICONVIDEO_getAgcA returns the current A-gain AGC setting.

The pxd_SILICONVIDEO_getAgcB returns the current B-gain AGC setting.

The pxd_SILICONVIDEO_getAec returns the current exposure AEC setting.

Some cameras may not provide A-gain, B-gain, or exposure automatic gain control; a value of 0 is returned.

Note: The pxd_PIXCIopen performs partial, quick initialization of XCLIB; initialization for the pxd_SILICONVIDEO_ functions is delayed until the first such function is called. Time sensitive applications should call any pxd_SILICONVIDEO_set or pxd_SILICONVIDEO_get function once before entering the application's time critical phase.


Camera Specific. For SILICON VIDEO® 1281M and SILICON VIDEO® 1281C: The camera does not provide hardware AGC or AEC features.

For SILICON VIDEO® 1310 and SILICON VIDEO® 1310C: The camera does not provide hardware AGC or AEC features.

For SILICON VIDEO® 2112 and SILICON VIDEO® 2112C: The camera does not provide hardware AGC or AEC features.

For SILICON VIDEO® 5C10 and SILICON VIDEO® 5M10: The camera does not provide hardware AGC or AEC features.

For SILICON VIDEO® 642M and SILICON VIDEO® 642C: The camera does not provide hardware AGC or AEC features.

For SILICON VIDEO® 643M and SILICON VIDEO® 643C: The camera does not provide hardware AGC or AEC features.

For SILICON VIDEO® 9C10: The camera does not provide hardware AGC or AEC features.

For SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 10C-CL, and SILICON VIDEO® 10M-CL: The camera does not provide hardware AGC or AEC features.

For SILICON VIDEO® 9M001 and SILICON VIDEO® 9M001C: The camera does not provide hardware AGC or AEC features.

For SILICON VIDEO® 9T001C: The camera does not provide hardware AGC or AEC features.

For SILICON VIDEO® HAS21: The camera does not provide hardware AGC or AEC features.

For SILICON VIDEO® WGA-C and SILICON VIDEO® WGA-M: The camera provides AGC control of the A-gain and AEC control of the exposure (shutter). In addition to value 0, allowable values for agcA and aec are 1 (slow AGC/AEC), 2 (medium AGC/AEC), 3 (fast AGC/AEC).


Returns

The pxd_SILICONVIDEO_getAgcA, pxd_SILICONVIDEO_getAgcB, and pxd_SILICONVIDEO_getAec, returns values as described above, or 0 if the library is not open for use, or the wrong imaging board is in use.

The remaining functions return:


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Get SILICON VIDEO Min/Max Exposure --- pxd_SILICONVIDEO_getMinMaxExposure
Get SILICON VIDEO Min/Max Frame Period --- pxd_SILICONVIDEO_getMinMaxFramePeriod
Get SILICON VIDEO Min/Max Controlled Frame Rate --- pxd_SILICONVIDEO_getMinMaxCtrlFrameRate
Get SILICON VIDEO Min/Max Pixel Clock Frequency --- pxd_SILICONVIDEO_getMinMaxPixelClock
Get SILICON VIDEO Min/Max Gain A --- pxd_SILICONVIDEO_getMinMaxGainA
Get SILICON VIDEO Min/Max Gain B --- pxd_SILICONVIDEO_getMinMaxGainB
Get SILICON VIDEO Min/Max Offset A --- pxd_SILICONVIDEO_getMinMaxOffsetA
Get SILICON VIDEO Min/Max Offset B --- pxd_SILICONVIDEO_getMinMaxOffsetB
Get SILICON VIDEO Min/Max AOI Width --- pxd_SILICONVIDEO_getMinMaxAoiWidth
Get SILICON VIDEO Min/Max AOI Height --- pxd_SILICONVIDEO_getMinMaxAoiHeight
Get SILICON VIDEO Min/Max AGC A Gain --- pxd_SILICONVIDEO_getMinMaxAgcA
Get SILICON VIDEO Min/Max AGC B Gain --- pxd_SILICONVIDEO_getMinMaxAgcB
Get SILICON VIDEO Min/Max AEC Exposure --- pxd_SILICONVIDEO_getMinMaxAec



Summary
double pxd_SILICONVIDEO_getMinMaxExposure(unitmap, exposure);
double pxd_SILICONVIDEO_getMinMaxFramePeriod(unitmap, framePeriod);
double pxd_SILICONVIDEO_getMinMaxCtrlFrameRate(unitmap, frameRate);
double pxd_SILICONVIDEO_getMinMaxPixelClock(unitmap, pixelClkFreq);
double pxd_SILICONVIDEO_getMinMaxGainA(unitmap, gainA);
double pxd_SILICONVIDEO_getMinMaxGainB(unitmap, gainB);
double pxd_SILICONVIDEO_getMinMaxOffsetA(unitmap, offsetA);
double pxd_SILICONVIDEO_getMinMaxOffsetB(unitmap, offsetB);
int    pxd_SILICONVIDEO_getMinMaxAoiWidth(unitmap, aoiwidth);
int    pxd_SILICONVIDEO_getMinMaxAoiHeight(unitmap, aoiheight);
int    pxd_SILICONVIDEO_getMinMaxAgcA(unitmap, agcA);
int    pxd_SILICONVIDEO_getMinMaxAgcB(unitmap, agcB);
int    pxd_SILICONVIDEO_getMinMaxAec(unitmap, aec);

int unitmap; // Unit selection bit map (1 for single unit) double exposure; // Exposure period, in milliseconds double framePeriod; // Frame period, in msec. double frameRate; // Frame rate, in Hz double pixelClkFreq; // Pixel clock frequency, in MHz. double gainA; // Pre-gain, in dB. double gainB; // Post-gain, in dB. double offsetA; // Pre-offset, scaled to 1.0 for max-pixel value double offsetB; // Post-offset, scaled to 1.0 for max pixel value int aoiwidth; // Width of partial scan AOI int aoiheight; // Height of partial scan AOI int agcA; // AGC for A-gain. 0: off, >0: AGC rate int agcB; // AGC for B-gain. 0: off, >0: AGC rate int aec; // AEC. 0: off, >0: AEC rate



Description

The pxd_SILICONVIDEO_getMinMaxExposure and pxd_SILICONVIDEO_getMinMaxFramePeriod corrects the prospective exposure period and free-run mode framePeriod, respectively, to the nearest valid value. The corrected value is returned, in milliseconds. The camera's settings and function are not affected.

The pxd_SILICONVIDEO_getMinMaxCtrlFrameRate corrects the prospective controlled, continuous mode frameRate to the nearest valid value. The corrected value is returned, in milliseconds. The camera's settings and function are not affected.

The pxd_SILICONVIDEO_getMinMaxPixelClock corrects the prospective pixelClkFreq to the nearest valid value. The corrected value is returned, in MHz. The camera's settings and function are not affected.

The pxd_SILICONVIDEO_getMinMaxGainA and pxd_SILICONVIDEO_getMinMaxGainB corrects the prospective gainA and gainB, respectively, to the nearest valid value. The corrected value is returned, in dB. The camera's settings and function are not affected.

The pxd_SILICONVIDEO_getMinMaxOffsetA and pxd_SILICONVIDEO_getMinMaxOffsetB corrects the prospective offsetA and offsetB, respectively, to the nearest valid value. The corrected value is returned, scaled in the same manner as used for pxd_SILICONVIDEO_getOffsetsA and pxd_SILICONVIDEO_getOffsetsB The camera's settings and function are not affected.

The pxd_SILICONVIDEO_getMinMaxAoiWidth and pxd_SILICONVIDEO_getMinMaxAoiHeight corrects the prospective aoiwidth and aoiheight, respectively, to the nearest valid value. The corrected value is returned. The camera's settings and function are not affected.

The pxd_SILICONVIDEO_getMinMaxAgcA, pxd_SILICONVIDEO_getMinMaxAgcB, and pxd_SILICONVIDEO_getMinMaxAec corrects the prospective agcA, agcB, and aec, respectively, to the nearest valid value. The corrected value is returned. The camera's settings and function are not affected.

The allowable ranges of the exposure, frame period, pixel clock frequency, gain, offset, AOI width and height, AGC settings, and AEC settings vary depending on camera model. For some cameras, the allowable ranges are also dependent on the camera's settings. For example, the allowable values for exposure are often dependent on the camera's pixel clock frequency, AOI width & height, and subsampling. These functions allow obtaining the current minimum and maximum allowable values, such as by invoking pxd_SILICONVIDEO_getMinMaxExposure with exposure=0.0 or exposure=-9E99 to obtain the minimum allowable exposure, and by invoking with exposure=9E99 to obtain the maximum allowable exposure.


Returns

Returns values as described above, or 0 if the library is not open for use, or the wrong imaging board is in use.


 

 

 

4. SCF+ Style Interface

The so-called Simple ``C'' Function Plus Style Interface is similar to the SCF Style Interface functions, but allows access to multiple, non-identical, image boards.[30]


PIXCI® Imaging Board Library: Create Instance --- pxe_XCLIBinstantiate
PIXCI® Imaging Board Library: Uncreate Instance --- pxe_XCLIBuninstantiate



Summary
pxdstate_s * pxe_XCLIBinstantiate();
void         pxe_XCLIBuninstantiate(instance);

pxdstate_s * instance; // Library instance



Description

The pxe_XCLIBinstantiate creates an instance of the PIXCI® XCLIB Library and returns a pointer to the instance. The pxe_XCLIBuninstantiate frees the resources acquired by pxe_XCLIBinstantiate, after which the pointer to the instance should not be used.

An explicit instance of the PIXCI® XCLIB Library is needed to use the various pxe_ style functions which allow opening and using multiple imaging boards of different types. In contrast, the slightly simpler pxd_ functions use an implicit instance of the PIXCI® XCLIB Library, but can only operate multiple imaging boards of the same type.


Returns

The pxe_XCLIBinstantiate returns a pointer to a new instance, or NULL for malloc error.


Example

Assume three PIXCI® imaging boards. The first two are of the same type and will be opened within one instance for convenience of common controls.

    pxdstate_s  *xclib1 = NULL;
    pxdstate_s  *xclib2 = NULL;
    int i;

xclib1 = pxe_XCLIBinstantiate(); xclib2 = pxe_XCLIBinstantiate(); if (xclib1 == NULL || xclib2 == NULL) { printf("Instantiation Error\n"); pxe_XCLIBuninstantiate(xclib1); pxe_XCLIBuninstantiate(xclib2); exit(1); } // the DM parameter is a bitmap selection of physical units: 3 = units #0 & #1 if ((i = pxe_PIXCIopen(xclib1, "-DM 3", "Default", "")) < 0) { printf("Open Error\n"); pxe_mesgFault(xclib1, 3); pxe_XCLIBuninstantiate(xclib1); pxe_XCLIBuninstantiate(xclib2); exit(1); } // the DM parameter is a bitmap selection of physical units: 4 = unit #2 if ((i = pxe_PIXCIopen(xclib2, "-DM 4", "Default", "")) < 0) { printf("Open Error\n"); pxe_mesgFault(xclib2, 3); pxe_PIXCIclose(xclib1) pxe_XCLIBuninstantiate(xclib1); pxe_XCLIBuninstantiate(xclib2); exit(1); } // the unitmap parameter is a bitmap selection of // those units opened within that instance. // As the xclib2 instance has only one board open, // its unitmap is always 1! pxe_doSnap(xclib1, 1, 5, 0); // snap imaging board 1 into its buffer #5 pxe_doSnap(xclib1, 2, 5, 0); // snap imaging board 2 into its buffer #5 pxe_doSnap(xclib1, 3, 5, 0); // snap imaging board 1&2 into their respective buffer #5 pxe_doSnap(xclib2, 1, 5, 0); // snap imaging board 3 into its buffer #5 ... pxe_PIXCIclose(xclib1) pxe_PIXCIclose(xclib2) pxe_XCLIBuninstantiate(xclib1); pxe_XCLIBuninstantiate(xclib2); exit(0);

Set A/D Gain and Offset --- pxe_setAdcGainOffset
Set A/D Gains and Offsets --- pxe_setAdcColorGainOffsets
Get A/D Gain A --- pxe_getAdcGainA
Get A/D Gain B --- pxe_getAdcGainB
Get A/D Color Gains A --- pxe_getAdcGainsA
Get A/D Color Gains B --- pxe_getAdcGainsB
Get A/D Color Gains A --- pxe_getAdcOffsetsA
Get A/D Color Gains B --- pxe_getAdcOffsetsB
Get A/D Color Offsets A --- pxe_getAdcOffsetA
Get A/D Color Offsets B --- pxe_getAdcOffsetB
Buffer's Capture Field Count --- pxe_buffersFieldCount
Buffer's Capture General Purpose Input --- pxe_buffersGPIn
Buffer's Capture System Time --- pxe_buffersSysTicks
Buffer's Capture System Time --- pxe_buffersSysTicks2
Camera Link CC Output Signal: Set --- pxe_setCameraLinkCCOut
Camera Link CC Output Signal: Get --- pxe_getCameraLinkCCOut
Last Captured Buffer: Buffer Number --- pxe_capturedBuffer
Last Captured Buffer: Field Count --- pxe_capturedFieldCount
Last Captured Buffer: System Time --- pxe_capturedSysTicks
Get PXIMAGE: Access Imaging Board Frame Buffer --- pxe_defineImage
Get PXIMAGE3: Access Imaging Board Frame Buffers --- pxe_defineImage3
Get PXIMAGE: Access Imaging Board Frame Buffer --- pxe_definePximage
Get PXIMAGE3: Access Imaging Board Frame Buffers --- pxe_definePximage3
Get PXIMAGE: Release Access to Imaging Board Frame Buffers --- pxe_definePximageFree
Get PXIMAGE3: Release Access to Imaging Board Frame Buffers --- pxe_definePximage3Free
Windows: Register Event upon Video Field --- pxe_eventFieldCreate
Windows: Register Event upon Video Field --- pxe_eventFieldCreate2
Windows: Unregister Event upon Video Field --- pxe_eventFieldClose
Windows: Register Event upon Captured Video Field --- pxe_eventCapturedFieldCreate
Windows: Register Event upon Captured Video Field --- pxe_eventCapturedFieldCreate2
Windows: Unregister Event upon Captured Video Field --- pxe_eventCapturedFieldClose
Windows: Register Event upon General Purpose Trigger --- pxe_eventGPTriggerCreate
Windows: Register Event upon General Purpose Trigger --- pxe_eventGPTriggerCreate2
Windows: Unregister Event upon General Purpose Trigger --- pxe_eventGPTriggerClose
Windows: Register Event upon Fault --- pxe_eventFaultCreate
Windows: Register Event upon Fault --- pxe_eventFaultCreate2
Windows: Unregister Event upon Fault --- pxe_eventFaultClose
Windows: Register Event upon Serial --- pxe_eventSerialCreate
Windows: Unregister Event upon Serial --- pxe_eventSerialClose
DOS: Register Callback upon Video Field --- pxe_eventFieldCreate
DOS: Unregister Callback upon Video Field --- pxe_eventFieldClose
DOS: Register Callback upon Captured Video Field --- pxe_eventCapturedFieldCreate
DOS: Unregister Callback upon Captured Video Field --- pxe_eventCapturedFieldClose
DOS: Register Callback upon General Purpose Trigger --- pxe_eventGPTriggerCreate
DOS: Unregister Callback upon General Purpose Trigger --- pxe_eventGPTriggerClose
DOS: Register Callback upon Fault --- pxe_eventFaultCreate
DOS: Unregister Callback upon Fault --- pxe_eventFaultClose
DOS: Register Callback upon Serial --- pxe_eventSerialCreate
DOS: Unregister Callback upon Serial --- pxe_eventSerialClose
Linux: Register Signal upon Video Field --- pxe_eventFieldCreate
Linux: Unregister Signal upon Video Field --- pxe_eventFieldClose
Linux: Register Signal upon Captured Video Field --- pxe_eventCapturedFieldCreate
Linux: Unregister Signal upon Captured Video Field --- pxe_eventCapturedFieldClose
Linux: Register Signal upon General Purpose Trigger --- pxe_eventGPTriggerCreate
Linux: Unregister Signal upon General Purpose Trigger --- pxe_eventGPTriggerClose
Linux: Register Signal upon Fault --- pxe_eventFaultCreate
Linux: Unregister Signal upon Fault --- pxe_eventFaultClose
Linux: Register Signal upon Serial --- pxe_eventSerialCreate
Linux: Unregister Signal upon Serial --- pxe_eventSerialClose
Set EXSYNC and PRIN Counter Values --- pxe_setExsyncPrin
Get EXSYNC Counter Value --- pxe_getExsync
Get PRIN Counter Value --- pxe_getPrin
Set EXSYNC and PRINC Mode Bits --- pxe_setExsyncPrincMode
Get EXSYNC Mode Bits --- pxe_getExsyncMode
Get PRINC Mode Bits --- pxe_getPrincMode
General Purpose Input Signal: Sense --- pxe_getGPIn
General Purpose Input Signal: Reset --- pxe_setGPIn
General Purpose Output Signal: Set --- pxe_setGPOut
General Purpose Output Signal: Get --- pxe_getGPOut
General Purpose Trigger Input Count: Sense --- pxe_getGPTrigger
Get Frame Buffer Image Aspect Ratio --- pxe_imageAspectRatio
Get Frame Buffer Image Aspect Ratio --- pxe_imageAspectRatios
Get Frame Buffer Image Bit Depth --- pxe_imageBdim
Get Frame Buffer Image Bit Depth --- pxe_imageBdims
Get Frame Buffer Image Color Components --- pxe_imageCdim
Get Frame Buffer Image Color Components --- pxe_imageCdims
Get Frame Buffer Image Field Dimension --- pxe_imageIdim
Get Frame Buffer Image Field Dimension --- pxe_imageIdims
Get Frame Buffer Image Horizontal Dimension --- pxe_imageXdim
Get Frame Buffer Image Horizontal Dimension --- pxe_imageXdims
Get Frame Buffer Image Vertical Dimension --- pxe_imageYdim
Get Frame Buffer Image Vertical Dimension --- pxe_imageYdims
Get Frame Buffer Image Count --- pxe_imageZdim
Get Frame Buffer Image Count --- pxe_imageZdims
Set Bright White Balance --- pxe_setImageBrightBalance
Set Dark White Balance --- pxe_setImageDarkBalance
Read Pixel Values as Unsigned Char --- pxe_readuchar
Read Pixel Values as Unsigned Short --- pxe_readushort
Write Pixel Values as Unsigned Char --- pxe_writeuchar
Write Pixel Values as Unsigned Short --- pxe_writeushort
Get Imaging Board Driver ID --- pxe_infoDriverId
Get Imaging Board Library ID --- pxe_infoLibraryId
Get Imaging Board's Frame Buffer Size --- pxe_infoMemsize
Get Imaging Board's Model --- pxe_infoModel
Get Imaging Board's Submodel --- pxe_infoSubmodel
Get Imaging Board Unit Count --- pxe_infoUnits
Get Imaging Board Driver's System Time Units --- pxe_infoSysTicksUnits
Get Imaging Board Driver's System Time --- pxe_infoSysTicks
Load Image: BMP Format --- pxe_loadBmp
Load Image: TIFF Format --- pxe_loadTiff
Save Image: BMP Format --- pxe_saveBmp
Save Image: PCX Format --- pxe_savePcx
Save Image: TARGA Format --- pxe_saveTga
Save Image: TIFF Format --- pxe_saveTiff
Load Frame Buffers --- pxe_loadRawBuffers
Save Frame Buffers --- pxe_saveRawBuffers
Errors: Check & Report Faults --- pxe_mesgFault
Errors: Check & Report Faults --- pxe_mesgFaultText
PIXCI® Imaging Board: Open and Set Video Format Configuration --- pxe_PIXCIopen
PIXCI® Imaging Board: Close --- pxe_PIXCIclose
Windows: Create Device Independent Bitmap (DIB) --- pxe_renderDIBCreate
Windows: Release Device Independent Bitmap (DIB) --- pxe_renderDIBFree
Windows: Direct Video Display, Init --- pxe_renderDirectVideoInit
Windows: Direct Video Display, Done --- pxe_renderDirectVideoDone
Windows: Direct Video Display, Start --- pxe_renderDirectVideoLive
Windows: Direct Video Display, Stop --- pxe_renderDirectVideoUnLive
Windows: Display Image Frame Buffer On Device Context --- pxe_renderStretchDIBits
Serial Port: Set Configuration --- pxe_serialConfigure
Serial Port: Read --- pxe_serialRead
Serial Port: Write --- pxe_serialWrite
Set Video Input Multiplexer --- pxe_setVidMux
Set Video Contrast and Brightness --- pxe_setContrastBrightness
Set Video Hue and Saturation --- pxe_setHueSaturation
Get Video Brightness --- pxe_getBrightness
Get Video Contrast --- pxe_getContrast
Get Video Hue --- pxe_getHue
Get Video U Saturation --- pxe_getUGain
Get Video V Saturation --- pxe_getVGain
Get Video Input Multiplexer --- pxe_getVidMux
Video Snap and Wait --- pxe_doSnap
Video Snap --- pxe_goSnap
Video Snap Pair --- pxe_goSnapPair
Video Live --- pxe_goLive
Video Live Pair Alternate --- pxe_goLivePair
Video Live Sequence --- pxe_goLiveSeq
Video UnLive --- pxe_goUnLive
Video Abort --- pxe_goAbortLive
Video Live Trigger --- pxe_goLiveTrig
Video Live Sequence Trigger --- pxe_goLiveSeqTrig
Video Initiated Status Check --- pxe_goneLive
Get Video Field Count --- pxe_videoFieldCount
Get Video Field Characteristic --- pxe_videoFieldsPerFrame
Get Video Field Characteristic --- pxe_videoFieldsPerFrames
Set Video Configuration as per Compiled Include --- pxe_videoFormatAsIncluded
Set Video Configuration as per Compiled Init --- pxe_videoFormatAsIncludedInit
Escape to Access Structured Interface Services --- pxe_xclibEscape
Escaped to Access Structured Interface Services --- pxe_xclibEscaped


Summary
int               pxe_setAdcGainOffset(instance,unitmap,rsvd,gainA,offsetA,gainB,offsetB);
int               pxe_setAdcColorGainOffsets(instance,unitmap,rsvd,gainsA,gainsB,offsetsA,offsetsB);
double            pxe_getAdcGainA(instance,unitmap);
double            pxe_getAdcGainB(instance,unitmap);
int               pxe_getAdcGainsA(instance,unitmap,gainsA);
int               pxe_getAdcGainsB(instance,unitmap,gainsB);
int               pxe_getAdcOffsetsA(instance,unitmap,offsetsA);
int               pxe_getAdcOffsetsB(instance,unitmap,offsetsB);
double            pxe_getAdcOffsetA(instance,unitmap);
double            pxe_getAdcOffsetB(instance,unitmap);
pxvbtime_t        pxe_buffersFieldCount(instance,unitmap,buffer);
int               pxe_buffersGPIn(instance,unitmap,buffer);
uint32            pxe_buffersSysTicks(instance,unitmap,buffer);
int               pxe_buffersSysTicks2(instance,unitmap,buffer,ticks);
int               pxe_setCameraLinkCCOut(instance,unitmap,setoutdata);
int               pxe_getCameraLinkCCOut(instance,unitmap,getoutdata);
pxbuffer_t        pxe_capturedBuffer(instance,unitmap);
pxvbtime_t        pxe_capturedFieldCount(instance,unitmap);
uint32            pxe_capturedSysTicks(instance,unitmap);
struct pximage  * pxe_defineImage (instance,unitmap,framebuf,ulx,uly,lrx,lry,colorspace);
struct pximage3 * pxe_defineImage3(instance,unitmap,startbuf,endbuf,ulx,uly,lrx,lry,colorspace);
struct pximage  * pxe_definePximage (instance,unitmap,framebuf,ulx,uly,lrx,lry,colorspace);
struct pximage3 * pxe_definePximage3(instance,unitmap,startbuf,endbuf,ulx,uly,lrx,lry,colorspace);
void              pxe_definePximageFree(instance,image);
void              pxe_definePximage3Free(instance,image3)
HANDLE            pxe_eventFieldCreate(instance,unitmap);
HANDLE            pxe_eventFieldCreate2(instance,unitmap,type);
void              pxe_eventFieldClose(instance,unitmap,hEvent);
HANDLE            pxe_eventCapturedFieldCreate(instance,unitmap);
HANDLE            pxe_eventCapturedFieldCreate2(instance,unitmap,type);
void              pxe_eventCapturedFieldClose(instance,unitmap,hEvent);
HANDLE            pxe_eventGPTriggerCreate(instance,unitmap,which,rsvd);
HANDLE            pxe_eventGPTriggerCreate2(instance,unitmap,which,rsvd,type);
void              pxe_eventGPTriggerClose(instance,unitmap,which,rsvd,hEvent);
HANDLE            pxe_eventFaultCreate(instance,unitmap,rsvd);
HANDLE            pxe_eventFaultCreate2(instance,unitmap,rsvd,type);
void              pxe_eventFaultClose(instance,unitmap,rsvd,hEvent);
HANDLE            pxe_eventSerialCreate(instance,unitmap,serwhich,rsvd,type);
void              pxe_eventSerialClose(instance,unitmap,serwhich,rsvd,hEvent);
int               pxe_eventFieldCreate(instance,unitmap,irqfunc,statep);
int               pxe_eventFieldClose(instance,unitmap,irqfunc);
int               pxe_eventCapturedFieldCreate(instance,unitmap,irqfunc,statep);
int               pxe_eventCapturedFieldClose(instance,unitmap,irqfunc);
int               pxe_eventGPTriggerCreate(instance,unitmap,which,rsvd,irqfunc,statep);
int               pxe_eventGPTriggerClose(instance,unitmap,which,rsvd,irqfunc);
int               pxe_eventFaultCreate(instance,unitmap,rsvd,irqfunc,statep);
int               pxe_eventFaultClose(instance,unitmap,rsvd,irqfunc);
int               pxe_eventSerialCreate(instance,unitmap,serwhich,rsvd,irqfunc,statep);
int               pxe_eventSerialClose(instance,unitmap,serwhich,rsvd,irqfunc);
int               pxe_eventFieldCreate(instance,unitmap,signum,rsvd2);
int               pxe_eventFieldClose(instance,unitmap,signum);
int               pxe_eventCapturedFieldCreate(instance,unitmap,signum,rsvd2);
int               pxe_eventCapturedFieldClose(instance,unitmap,signum);
int               pxe_eventGPTriggerCreate(instance,unitmap,which,rsvd,signum,rsvd2);
int               pxe_eventGPTriggerClose(instance,unitmap,which,rsvd,signum);
int               pxe_eventFaultCreate(instance,unitmap,rsvd,signum,rsvd2);
int               pxe_eventFaultClose(instance,unitmap,rsvd,signum);
int               pxe_eventSerialCreate(instance,unitmap,serwhich,rsvd,signum,rsvd2);
int               pxe_eventSerialClose(instance,unitmap,serwhich,rsvd,signum);
int               pxe_setExsyncPrin(instance,unitmap,exsync,prin);
uint              pxe_getExsync(instance,unitmap);
uint              pxe_getPrin(instance,unitmap);
int               pxe_setExsyncPrincMode(instance,unitmap,exsyncbits,princbits);
uint              pxe_getExsyncMode(instance,unitmap);
uint              pxe_getPrincMode(instance,unitmap);
int               pxe_getGPIn(instance,unitmap,getindata);
int               pxe_setGPIn(instance,unitmap,setindata);
int               pxe_setGPOut(instance,unitmap,setoutdata);
int               pxe_getGPOut(instance,unitmap,getoutdata);
int               pxe_getGPTrigger(instance,unitmap,which);
double            pxe_imageAspectRatio(instance);
int               pxe_imageBdim(instance);
int               pxe_imageCdim(instance);
int               pxe_imageIdim(instance);
int               pxe_imageXdim(instance)
int               pxe_imageYdim(instance);
int               pxe_imageZdim(instance);
double            pxe_imageAspectRatios(instance,unitmap);
int               pxe_imageBdims(instance,unitmap);
int               pxe_imageCdims(instance,unitmap);
int               pxe_imageIdims(instance,unitmap);
int               pxe_imageXdims(instance,unitmap)
int               pxe_imageYdims(instance,unitmap);
int               pxe_imageZdims(instance,unitmap);
int               pxe_setImageDarkBalance(instance,unitmap,referenceRGB[3],targetRGB[3],gamma);
int               pxe_setImageBrightBalance(instance,unitmap,referenceRGB[3],targetRGB[3],gamma);
int               pxe_readuchar(instance,unitmap,framebuf,ulx,uly,lrx,lry,membuf,cnt,colorspace);
int               pxe_readushort(instance,unitmap,framebuf,ulx,uly,lrx,lry,membuf,cnt,colorspace);
int               pxe_writeuchar(instance,unitmap,framebuf,ulx,uly,lrx,lry,membuf,cnt,colorspace);
int               pxe_writeushort(instance,unitmap,framebuf,ulx,uly,lrx,lry,membuf,cnt,colorspace);
char*             pxe_infoDriverId(instance);
char*             pxe_infoLibraryId(instance);
ulong             pxe_infoMemsize(instance,unitmap);    // Under 32 bit Windows & Linux
uint64            pxe_infoMemsize(instance,unitmap);    // Under 64 bit Windows & Linux
int               pxe_infoModel(instance,unitmap);
int               pxe_infoSubmodel(instance,unitmap);
int               pxe_infoUnits(instance);
int               pxe_loadBmp(instance,unitmap,pathname,framebuf,ulx,uly,lrx,lry,loadmode,options);
int               pxe_loadTiff(instance,unitmap,pathname,framebuf,ulx,uly,lrx,lry,loadmode,options);
int               pxe_saveBmp(instance,unitmap,pathname,framebuf,ulx,uly,lrx,lry,savemode,options);
int               pxe_savePcx(instance,unitmap,pathname,framebuf,ulx,uly,lrx,lry,savemode,options);
int               pxe_saveTga(instance,unitmap,pathname,framebuf,ulx,uly,lrx,lry,savemode,options);
int               pxe_saveTiff(instance,unitmap,pathname,framebuf,ulx,uly,lrx,lry,savemode,options);
int               pxe_loadRawBuffers(instance,unitmap,pathname,startbuf,endbuf,filehandle,fileoffset,alignment,options);
int               pxe_saveRawBuffers(instance,unitmap,pathname,startbuf,endbuf,filehandle,fileoffset,alignment,options);
int               pxe_mesgFault(instance,unitmap);
int               pxe_mesgFaultText(instance,unitmap,buf,bufsize);
int               pxe_PIXCIopen(instance,driverparms,formatname,formatfile);
int               pxe_PIXCIclose(instance);
HGLOBAL           pxe_renderDIBCreate(instance,unitmap,framebuf,ulx,uly,lrx,lry,mode,options);
int               pxe_renderDIBFree(instance,hDIB);
int               pxe_renderDirectVideoInit(instance,unitmap,hWnd);
int               pxe_renderDirectVideoDone(instance,unitmap,hWnd);
int               pxe_renderDirectVideoLive(instance,unitmap,hWnd,nX,nY,nWidth,nHeight,ClrKey1,ClrKey2);
int               pxe_renderDirectVideoUnLive(instance,unitmap,hWnd);
int               pxe_renderStretchDIBits(instance,unitmap,buffer,ulx,uly,lrx,lry,options,hDC,nX,nY,nWidth,nHeight,winoptions);
int               pxe_serialConfigure(instance,unitmap,rsvd0,baud,bits,parity,stopbits,rsvd1,rsvd2,rsvd3);
int               pxe_serialRead(instance,unitmap,rsvd0,data,cnt);
int               pxe_serialWrite(instance,unitmap,rsvd0,data,cnt);
int               pxe_setVidMux(instance,unitmap,inmux);
int               pxe_setContrastBrightness(instance,unitmap,contrast,brightness);
int               pxe_setHueSaturation(instance,unitmap,hue,Ugain,Vgain);
int               pxe_getVidMux(instance,unitmap);
double            pxe_getBrightness(instance,unitmap);
double            pxe_getContrast(instance,unitmap);
double            pxe_getHue(instance,unitmap);
double            pxe_getUGain(instance,unitmap);
double            pxe_getVGain(instance,unitmap);
int               pxe_doSnap(instance,unitmap,buffer,timeout);
int               pxe_goSnap(instance,unitmap,buffer);
int               pxe_goSnapPair(instance,unitmap,buffer1,buffer2);
int               pxe_goLive(instance,unitmap,buffer);
int               pxe_goLivePair(instance,unitmap,buffer,buffer2);
int               pxe_goLiveSeq(instance,unitmap,startbuf,endbuf,incbuf,numbuf,videoperiod);
int               pxe_goUnLive(instance,unitmap);
int               pxe_goAbortLive(instance,unitmap);
int               pxe_goLiveTrig(instance,unitmap,buffer,
                                gpin10mask,gpout20value,gpout20mask,gpout20when,
                                gpin30wait,gpin30mask,gpout40value,gpout40mask,
                                option50,field50,gpout50value,gpout50mask,delay60,
                                gpout60value,gpout60mask,delay70,field70,capture70,
                                gpin80mask,gpout80value,gpout80mask);
int               pxe_goLiveSeqTrig(instance,int unitmap,startbuf,endbuf,incbuf,numbuf,videoperiod,
                                rsvd1,rsvd2,trig20wait,trig20slct,trig20delay,rsvd3,rsvd4,
                                rsvd5,rsvd6,rsvd7,rsvd8,rsvd9,trig40wait,trig40slct,
                                trig40delay,rsvd10,rsvd11,rsvd12,rsvd13,rsvd14,rsvd15);
int               pxe_goneLive(instance,unitmap,rsvd);
pxvbtime_t        pxe_videoFieldCount(instance,unitmap);
int               pxe_videoFieldsPerFrame(instance);
int               pxe_videoFieldsPerFrames(instance,unitmap);
int               pxe_videoFormatAsIncluded(rsvd);
                  pxe_videoFormatAsIncludedInit(rsvd);
struct xclibs *   pxe_xclibEscape(instance,rsvd1,rsvd2,rsvd3);
int               pxe_xclibEscaped(instance,rsvd1,rsvd2,rsvd3);

pxdstate_s * instance; // Library instance



Description

Each of these pxe_ functions has the same functionality as the corresponding pxd_ function, except the former uses an explicit instance of the PIXCI® XCLIB Library and has an extra instance parameter as provided by pxe_XCLIBinstantiate, while the latter uses an implicit instance of the PIXCI® XCLIB Library.

An explicit instance of the PIXCI® XCLIB Library is needed to use the various pxe_ style functions and allow opening and using multiple imaging boards of different types. In contrast, the slightly simpler pxd_ functions use an implicit instance of the PIXCI® XCLIB Library, but can only operate multiple imaging boards of the same type.


Returns

See the corresponding pxd_ functions.


Example

See pxe_XCLIBinstantiate.


Set SILICON VIDEO Exposure, Gain, and Offset --- pxe_SILICONVIDEO_setExposureGainOffset
Set SILICON VIDEO Exposure, Gains, and Offsets --- pxe_SILICONVIDEO_setExposureColorGainOffsets
Set SILICON VIDEO Exposure --- pxe_SILICONVIDEO_setExposure
Get SILICON VIDEO Exposure --- pxe_SILICONVIDEO_getExposure
Get SILICON VIDEO Gain A --- pxe_SILICONVIDEO_getGainA
Get SILICON VIDEO Gain B --- pxe_SILICONVIDEO_getGainB
Get SILICON VIDEO Color Gains A --- pxe_SILICONVIDEO_getGainsA
Get SILICON VIDEO Color Gains B --- pxe_SILICONVIDEO_getGainsB
Get SILICON VIDEO Color Offset A --- pxe_SILICONVIDEO_getOffsetA
Get SILICON VIDEO Color Offset B --- pxe_SILICONVIDEO_getOffsetB
Get SILICON VIDEO Color Offsets A --- pxe_SILICONVIDEO_getOffsetsA
Get SILICON VIDEO Color Offsets B --- pxe_SILICONVIDEO_getOffsetsB
Set SILICON VIDEO Resolution and Timing --- pxe_SILICONVIDEO_setResolutionAndTiming
Get SILICON VIDEO Subsample --- pxe_SILICONVIDEO_getSubsample
Get SILICON VIDEO Aoi Left Edge --- pxe_SILICONVIDEO_getAoiLeft
Get SILICON VIDEO Aoi Top Edge --- pxe_SILICONVIDEO_getAoiTop
Get SILICON VIDEO Aoi Width --- pxe_SILICONVIDEO_getAoiWidth
Get SILICON VIDEO Aoi Height --- pxe_SILICONVIDEO_getAoiHeight
Get SILICON VIDEO Scan Direction --- pxe_SILICONVIDEO_getScanDirection
Get SILICON VIDEO Pixel Clock Frequency --- pxe_SILICONVIDEO_getPixelClock
Get SILICON VIDEO Frame Period --- pxe_SILICONVIDEO_getFramePeriod
Set SILICON VIDEO Video And Trigger Modes --- pxe_SILICONVIDEO_setVideoAndTriggerMode
Set SILICON VIDEO Controlled Rates --- pxe_SILICONVIDEO_setCtrlRates
Get SILICON VIDEO Video Mode --- pxe_SILICONVIDEO_getVideoMode
Get SILICON VIDEO Controlled Frame Rate --- pxe_SILICONVIDEO_getCtrlFrameRate"
Get SILICON VIDEO Controlled Video Mode --- pxe_SILICONVIDEO_getCtrlVideoMode
Get SILICON VIDEO Controlled Trigger Mode --- pxe_SILICONVIDEO_getCtrlTriggerMode
Set SILICON VIDEO AGC and AEC --- pxe_SILICONVIDEO_setAxC
Get SILICON VIDEO AGC A Gain --- pxe_SILICONVIDEO_getAgcA
Get SILICON VIDEO AGC B Gain --- pxe_SILICONVIDEO_getAgcB
Get SILICON VIDEO AEC Exposure --- pxe_SILICONVIDEO_getAec
Get SILICON VIDEO Min/Max Exposure --- pxe_SILICONVIDEO_getMinMaxExposure
Get SILICON VIDEO Min/Max Frame Period --- pxe_SILICONVIDEO_getMinMaxFramePeriod
Get SILICON VIDEO Min/Max Controlled Frame Rate --- pxe_SILICONVIDEO_getMinMaxCtrlFrameRate
Get SILICON VIDEO Min/Max Pixel Clock Frequency --- pxe_SILICONVIDEO_getMinMaxPixelClock
Get SILICON VIDEO Min/Max Gain A --- pxe_SILICONVIDEO_getMinMaxGainA
Get SILICON VIDEO Min/Max Gain B --- pxe_SILICONVIDEO_getMinMaxGainB
Get SILICON VIDEO Min/Max Offset A --- pxe_SILICONVIDEO_getMinMaxOffsetA
Get SILICON VIDEO Min/Max Offset B --- pxe_SILICONVIDEO_getMinMaxOffsetB
Get SILICON VIDEO Min/Max AOI Width --- pxe_SILICONVIDEO_getMinMaxAoiWidth
Get SILICON VIDEO Min/Max AOI Height --- pxe_SILICONVIDEO_getMinMaxAoiHeight
Get SILICON VIDEO Min/Max AGC A Gain --- pxe_SILICONVIDEO_getMinMaxAgcA
Get SILICON VIDEO Min/Max AGC B Gain --- pxe_SILICONVIDEO_getMinMaxAgcB
Get SILICON VIDEO Min/Max AEC Exposure --- pxe_SILICONVIDEO_getMinMaxAec



Summary
int               pxe_SILICONVIDEO_setExposureGainOffset(instance,unitmap,rsvd,exposure,gainA,offsetA,
                                gainB,offsetB);
int               pxe_SILICONVIDEO_setExposureColorGainOffsets(instance,unitmap,rsvd,exposure,
                                gainsA,gainsB,offsetsA,offsetsB);
double            pxe_SILICONVIDEO_getExposure(instance,unitmap);
double            pxe_SILICONVIDEO_getGainA(instance,unitmap);
double            pxe_SILICONVIDEO_getGainB(instance,unitmap);
int               pxe_SILICONVIDEO_getGainsA(instance,unitmap,gainsA);
int               pxe_SILICONVIDEO_getGainsB(instance,unitmap,gainsB);
int               pxe_SILICONVIDEO_getOffsetsA(instance,unitmap,offsetsA[4]);
int               pxe_SILICONVIDEO_getOffsetsB(instance,unitmap,offsetsB[4]);
int               pxe_SILICONVIDEO_setResolutionAndTiming(instance,unitmap,rsvd1,subsample,aoileft,aoitop,aoiwidth,
                                aoiheight,scandirection,bitdepth,rsvd3,rsvd4,pixelClkFreq,
                                framePeriod,rsvd5,rsvd6,rsvd7);
int               pxe_SILICONVIDEO_getSubsample(instance,unitmap);
int               pxe_SILICONVIDEO_getAoiLeft(instance,unitmap);
int               pxe_SILICONVIDEO_getAoiTop(instance,unitmap);
int               pxe_SILICONVIDEO_getAoiWidth(instance,unitmap);
int               pxe_SILICONVIDEO_getAoiHeight(instance,unitmap);
int               pxe_SILICONVIDEO_getScanDirection(instance,unitmap);
double            pxe_SILICONVIDEO_getPixelClock(instance,unitmap);
double            pxe_SILICONVIDEO_getFramePeriod(instance,unitmap);
int               pxe_SILICONVIDEO_setVideoAndTriggerMode(instance,unitmap,rsvd,videomode,controlledmode,
                                controlledtrigger,strobemode,rsvd2,rsvd3,rsvd4);
int               pxe_SILICONVIDEO_setCtrlRates(instance,unitmap,rsvd,rsvd11,framerate,rsvd12,rsvd13,rsvd14);
int               pxe_SILICONVIDEO_getVideoMode(instance,unitmap);
int               pxe_SILICONVIDEO_getCtrlVideoMode(instance,unitmap);
int               pxe_SILICONVIDEO_getCtrlTriggerMode(instance,unitmap);
double            pxe_SILICONVIDEO_getCtrlFrameRate(instance,unitmap);
int               pxe_SILICONVIDEO_setAxC(instance,unitmap,rsvd,agcA,agcB,rsvd2,rsvd3,aec,
                                                         rsvd4,rsvd5,rsvd6,rsvd7);
int               pxe_SILICONVIDEO_getAgcA(instance,unitmap);
int               pxe_SILICONVIDEO_getAgcB(instance,unitmap);
int               pxe_SILICONVIDEO_getAec(instance,unitmap);
double            pxe_SILICONVIDEO_getMinMaxExposure(instance,unitmap,exposure);
double            pxe_SILICONVIDEO_getMinMaxFramePeriod(instance,unitmap,framePeriod);
double            pxe_SILICONVIDEO_getMinMaxCtrlFrameRate(instance,unitmap,frameRate);
double            pxe_SILICONVIDEO_getMinMaxPixelClock(instance,unitmap,pixelClkFreq);
double            pxe_SILICONVIDEO_getMinMaxGainA(instance,unitmap,gainA);
double            pxe_SILICONVIDEO_getMinMaxGainB(instance,unitmap,gainB);
double            pxe_SILICONVIDEO_getMinMaxOffsetA(instance,unitmap,offsetA);
double            pxe_SILICONVIDEO_getMinMaxOffsetB(instance,unitmap,offsetB);
int               pxe_SILICONVIDEO_getMinMaxAoiWidth(instance,unitmap,aoiwidth);
int               pxe_SILICONVIDEO_getMinMaxAoiHeight(instance,unitmap,aoiheight);
int               pxe_SILICONVIDEO_getMinMaxAgcA(instance,unitmap,agcA);
int               pxe_SILICONVIDEO_getMinMaxAgcB(instance,unitmap,agcB);
int               pxe_SILICONVIDEO_getMinMaxAec(instance,unitmap,aec);

pxdstate_s * instance; // Library instance



Description

Each of these pxe_ functions has the same functionality as the corresponding pxd_ function, except the former uses an explicit instance of the PIXCI® XCLIB Library and has an extra instance parameter as provided by pxe_XCLIBinstantiate, while the latter uses an implicit instance of the PIXCI® XCLIB Library.

An explicit instance of the PIXCI® XCLIB Library is needed to use the various pxe_ style functions and allow opening and using multiple imaging boards of different types. In contrast, the slightly simpler pxd_ functions use an implicit instance of the PIXCI® XCLIB Library, but can only operate multiple imaging boards of the same type.


Returns

See the correspond pxd_ functions.


Example

See pxe_XCLIBinstantiate.


 

 

 

5. Structured Style Interface - Open, Close, Information, and Fault Services

The Open, Close, Information, and Fault services open the library for use, close the library after use, identify the types of imaging board(s) and/or functional units present as well as the versions of library and driver, and provide descriptions of operational faults.[31]


Get Imaging Board Include Files ID --- xclib_libincid
Get Imaging Board Library ID --- xclib_liblibid



Summary
int     xclib_liblibid(info);
#define xclib_libincid(info)

struct pxdevinfo *info; // Only 'libraryid' field used



Description

The xclib_liblibid fills the libraryid field of the info instance of the pxdevinfo structure with an identification string of the current imaging board library.

The xclib_libincid fills the libraryid field of the info instance of the pxdevinfo structure with an identification string of the current include (i.e. ''.h'') files.

Both xclib_liblibid and xclib_libincid may be used with the XCLIB library closed.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXERBADSTRUCT
The info's ddch.mos or ddch.len signature was incorrect (xclib_liblibid only).

PIXCI® Imaging Board: Structured Open --- xclib_open
PIXCI® Imaging Board: Structured Close --- xclib_close



Summary
int xclib_open (xclib, drivermodes, driverparms, formatname, formatfile);
int xclib_close(xclib);

struct xclibs *xclib; // Existing instance of struct xclibs char *drivermodes; // Driver open mode char *driverparms; // Driver configuration parms, or NULL or "" char *formatname; // Video format configuration name, or NULL or "" char *formatfile; // Video format configuration file name, or NULL or ""



Description

The xclib_open opens the PIXCI® XCLIB Library and Driver for use. The xclib instance of the xclibs structure, provided by the application, is initialized by xclib_open; thereafter library and driver services are accessed through function pointers within the xclib. Once open, the PIXCI® library and driver should be closed by xclib_close upon the same xclib before the program exits; most services accessed through the same xclib after closing return a PXERNOTOPEN error.

If drivermodes=NULL or drivermodes="", the library, driver, and imaging boards(s) are open for use.

If drivermodes contains the string "-offline", the library is opened only for use of off-line services, namely: ::allocStateCopy, ::compareStateCopy, ::exportStateCopy, ::freeStateCopy, ::importStateCopy, ::initStateCopy, and ::errorCodeString. The driver and/or imaging board need not be present.

If drivermodes contains the string "-configure", the library and driver is opened only for use of configuration services, namely: ::allocStateCopy, ::compareStateCopy, ::exportStateCopy, ::freeStateCopy, ::importStateCopy, ::initStateCopy, ::setDevParms, ::getDevParms, and ::errorCodeString.

The driverparms may be a Driver Configuration Parameter string as described in Installation and Configuration — Run Time.

The formatfile may be the file name of a Video Configuration Format previously saved with ::exportStateCopy or with the XCAP application.[32] The formatfile is imported and all of its Video Configuration Formats are defined for later use via ::defineState.

The formatname may be the predefined name of a standard video configuration format suitable for the imaging board in use; the valid predefined names are described in pxd_PIXCIopen. The specified standard Video Configuration Format is defined via ::defineState for later use with a video state id of PXMODE_DIGI.

The formatfile and formatname may be NULL. If both are NULL, a video state must be defined via ::importStateCopy, or by filling the actual video configuration format structures and ::defineState, before capturing, displaying or accessing image frame buffers. If both are specified, the formatname is define first; the formatfile re-defines any video state id of PXMODE_DIGI that was previously defined.

If the xclib_open fails, the ::getFault, ::faultMessageBox, ::faultPrintf, and ::errorCodeString services may used to obtain additional information about the cause of failure.


Returns


0
The PIXCI® XCLIB Library and Driver is open and ready for use.

PXERROR
Invalid parameters.

PXERBADSTRUCT
The xclib's ddch.mos or ddch.len signature was incorrect.

PXERMALLOC
Memory allocation error.

PXERNOFILE
No file named formatfile found.

PXERFILEFORM
The file format of formatfile is invalid.

PXERDOSIO
Can't read file named formatfile.

PXERSEARCH
The formatname was invalid.

PXERVIDFORM
The formatname was a valid string, but the specified format is not supported on the current imaging board.

PXERBADPARM
The parameters in driverparms are invalid.

PXER...
Other error codes as appropriate.

Get Imaging Board and Driver Information --- ::pxdev.getDevInfo
Get Extended Imaging Board and Driver Information --- ::xcdev.getDevInfo



Summary
int (pxdev.getDevInfo) (&pxdev, unitmap, rsvd, pxinfo);
struct pxdevservice pxdev;          // A pxdevservice instance
int                 unitmap;        // Unit selection bit map (1 for single unit)
int                 rsvd;           // Reserved, should be 0
struct pxdevinfo    *pxinfo;        // Filled with information

int (xcdev.getDevInfo) (&xcdev, unitmap, rsvd, xcinfo); struct xcdevservice xcdev; // A xcdevservice instance int unitmap; // Unit selection bit map (1 for single unit) int rsvd; // Reserved, should be 0 struct xcdevinfo *xcinfo; // Filled with information



Description

Information about the driver and about the single selected unitmap imaging board is ''returned'' in the pxinfo instance of the pxdevinfo structure, or the xcinfo instance of the xcdevinfo structure.

A non-exhaustive list of information provided includes the imaging board model, imaging board submodel (if applicable), imaging board revision level (if applicable), the number of imaging boards open for use, the total amount of image frame buffer memory per imaging board, a driver identification string, and a library identification string.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXERBADSTRUCT
The pxinfo's or the xcinfo's ddch.mos or ddch.len signature was incorrect.

PXER...
Other error codes as appropriate.

Obtain Last Logged Fault --- ::pxdev.getFault



Summary
int (pxdev.getFault) (&pxdev, unitmap, rsvd, fault);
struct pxdevservice pxdev;          // A pxdevservice instance
int                 unitmap;        // Unit selection bit map (1 for single unit)
int                 rsvd;           // Reserved, should be 0
struct pxdevfault   *fault;         // Fault information



Description

The ::getFault checks whether a new fault has occurred since the last check, and if so ''returns'' the fault information, filling the fault instance of the pxdevfault structure. The unitmap specifies the single unit upon which faults are checked and displayed.

Faults are not related to PXER... error codes. Rather, faults are typically asynchronous events, such as reporting that the video signal has been interrupted or corrupted. Faults are not the error description, if any, of the last called library function, with the exception that after xclib_open fails, the ::getFault may provide additional information about the cause of failure.


Returns


1
Information about a new logged fault has been returned.

0
No new logged fault exists, no information has been returned.

PXERROR
Invalid parameters.

PXERBADSTRUCT
The fault's ddch.mos or ddch.len signature was incorrect.

PXER...
Other error codes as appropriate.

Get Driver Parameters --- ::xcdev.getDevParms
Set Driver Parameters --- ::xcdev.setDevParms



Summary
int (xcdev.getDevParms) (&xcdev, unitmap, rsvd, parms);
int (xcdev.setDevParms) (&xcdev, unitmap, rsvd, parms);

struct pxdevservice pxdev; // A pxdevservice instance int unitmap; // Unit selection bit map (1 for single unit) int rsvd; // Reserved, should be 0 struct xcdevparms devparm; // Driver configuration parameters



Description

The ::getDevParms returns the current Driver Configuration Parameters for the single selected unitmap in the devparm instance of the xcdevparms structure. These are the same parameters as set by the third argument of xclib_open, although expressed as structure fields rather than as a string. The ::setDevParms returns an error; parameters can't be changed once the driver and imaging board are open for use.

If the XCLIB library has been opened in "-configure" mode (see xclib_open), the ::getDevParms returns the default Driver Configuration Parameters in the devparm instance of the xcdevparms structure, and the ::setDevParms sets the default Driver Configuration Parameters from devparm. The unitmap is ignored.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXERBADSTRUCT
The devparm's ddch.mos or ddch.len signature was incorrect.

PXER...
Other error codes as appropriate.

 

 

 

6. Structured Style Interface - Video Format Configuration Services

The Video Format Configuration & Video State ID services provide for the manipulation of the Video Format Configuration structures, and associating a Video Format Configuration with a numeric video state id.

The pxvidstate is the primary Video Format Configuration structure, which incorporates several substructures,

The ::allocStateCopy, ::compareStateCopy, ::exportStateCopy, ::freeStateCopy, ::importStateCopy, and ::initStateCopy services perform off-line manipulation of Video Format Configuration structures; their manipulation has no direct effect on the XCLIB library's or the imaging board's state. Their names of ''...StateCopy'' are intended to suggest that the Video Format Configuration structures manipulated are off-line copies; not that the Video Format Configuration structures manipulated are necessarily copies of any video state in use.

Other services manipulate Video Format Configuration structures in the context of the imaging board in use, with effect upon the library's state.


Allocate Copy of Video State --- ::pxlib.allocStateCopy
Free Copy of Video State --- ::pxlib.freeStateCopy



Summary
int (pxlib.allocStateCopy)    (&pxlib, options, stateid, statepp);
int (pxlib.freeStateCopy)     (&pxlib, options, stateid, statepp);

struct pxlibservice pxlib; // A pxlibservice instance int options; // Reserved, should be 0 int stateid; // Video state id, should be 0 struct pxvidstate **statepp; // Pointer to video state pointer



Description

The ::allocStateCopy malloc's a set of Video Format Configuration structures. The stateid is reserved and should be 0. The *statepp must initially be NULL; the pointer to the allocated pxvidstate structure and substructures is ''returned'' at *statepp. The ''returned'' pxvidstate structure and substructures are initialized to zero, with the ddch.len and ddch.mos signatures set.

The ::freeStateCopy free's a set of previously malloc'ed Video Format Configuration structures referenced by *statepp. The stateid is reserved and should be 0. After ::freeStateCopy, the *statepp is invalid, set to NULL, and must not be used with any function.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXERMALLOC
Memory allocation error.

PXER...
Other error codes as appropriate.

Compare Pair of Video State Copies --- ::pxlib.compareStateCopy



Summary
int (pxlib.compareStateCopy)  (&pxlib, options, stateid, statep, state2p);
struct pxlibservice pxlib;          // A pxlibservice instance
int                 options;        // Reserved, should be 0
int                 stateid;        // Video state id, should be 0
struct pxvidstate   *statep;        // Pointer to video state
struct pxvidstate   *state2p;       // Pointer to second video state



Description

The ::compareStateCopy compares Video Format Configuration settings of the Video Format Configurations referenced by the statep and state2p instances of the pxvidstate structure. Value 1 or 0 is returned if the settings are identical or not identical, respectively. The stateid is reserved and should be 0.

The ::compareStateCopy is not equivalent to a simple memcmp of statep and state2p; substructures within each are referenced by pointers which may point to different instances of Video Format Configuration substructures.


Returns


1
The Video Format Configuration are identical.

0
The Video Format Configuration are not identical.

PXERROR
Invalid parameters.

PXERBADSTRUCT
The statep's or state2p's ddch.mos or ddch.len signature was incorrect.

PXER...
Other error codes as appropriate.

Define Video State --- ::pxlib.defineState
Delete Video State --- ::pxlib.deleteState
Get Video State --- ::pxlib.getState
Get & Allocate Video State --- ::pxlib.getAllocState



Summary
int (pxlib.defineState)     (&pxlib, options, stateid, statep);
int (pxlib.deleteState)     (&pxlib, options, stateid, statep);
int (pxlib.getState)        (&pxlib, options, stateid, statep);
int (pxlib.getAllocState)   (&pxlib, options, stateid, statepp);


struct pxlibservice pxlib; // A pxlibservice instance int options; // Reserved, should be 0 int stateid; // Video state id struct pxvidstate *statep; // Pointer to video state struct pxvidstate **statepp; // Pointer to video state pointer



Description

The ::defineState copies and stores the Video Configuration Parameters contained in the statep instance of the pxvidstate structure, assigning it a video state id of stateid. The stateid may be an arbitrary integer greater than 0. After ::defineState, the statep may be free'ed or changed without affecting the Video Configuration Parameters associated with the stateid.

The ::deleteState deletes any Video Configuration Parameters associated with the stateid. The statep is ignored.

The ::getState retrieves and copies the Video Configuration Parameters associated with the stateid into the statep instance of the pxvidstate structure.

The ::getAllocState retrieves and copies the Video Configuration Parameters associated with the stateid into a malloc'ed set of Video Format Configuration structures. The *statepp must initially be NULL; the pointer to the allocated pxvidstate structure and substructures is ''returned'' at *statepp. When no longer needed, the allocated pxvidstate structure and substructures should be free'ed with ::freeStateCopy.

Using ::defineState or ::deleteState on a video state id already in use as the current Video Configuration Parameters for a video capture or display activity does not automatically affect the video capture or display activity.

Circa 2011, the pxcamcntl substructure of the pxvidstate was extended to be variable length to support cameras with larger serial command sets; the ::getState may truncate serial commands to the fixed length portion of the pxcamcntl. Use of ::getAllocState instead of ::getState is recommended when the contents of the pxcamcntl substructure is required.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXERBADSTRUCT
The statep's ddch.mos or ddch.len signature was incorrect.

PXERMALLOC
Memory allocation error.

PXERNOITEM
The specified stateid was not previously defined (for ::deleteState and ::getState).

PXER...
Other error codes as appropriate.

Export Copy of Video State --- ::pxlib.exportStateCopy
Import Copy of Video State --- ::pxlib.importStateCopy
Import & Allocate Copy of Video State --- ::pxlib.importAllocStateCopy



Summary
int (pxlib.exportStateCopy)(&pxlib, options, stateid, statep, stateindex,
                            pathname, filemode, progname, filecomment);
int (pxlib.importStateCopy)(&pxlib, options, stateid, statep, stateindex,
                            pathname, filemode);
int (pxlib.importAllocStateCopy)(&pxlib, options, stateid, statepp, stateindex,
                            pathname, filemode);

struct pxlibservice pxlib; // A pxlibservice instance int options; // Reserved, should be 0 int stateid; // Video state id struct pxvidstate *statep; // Pointer to video state struct pxvidstate **statepp; // Pointer to video state pointer int stateindex; // Index into file char *pathname; // File path and name char *filemode; // File open mode, or NULL char *progname; // Optional name of program char *filecomment; // Optional additional comment



Description

The ::exportStateCopy exports the Video Format Configuration settings contained in the statep instance of the pxvidstate structure to a file in a format compatible with ::importStateCopy, ::importAllocStateCopy, and with the XCAP application (using the same version of libraries).

The ::importStateCopy imports one set of Video Format Configuration settings into the provided statep instance of the pxvidstate structure.

The ::importAllocStateCopy imports one set of Video Format Configuration settings into an malloc'ed set of Video Format Configuration structures. The *statepp must initially be NULL; the pointer to the allocated pxvidstate structure and substructures is ''returned'' at *statepp. When no longer needed, the allocated pxvidstate structure and substructures should be free'ed with ::freeStateCopy.

Circa 2011, the pxcamcntl substructure of the pxvidstate was extended to be variable length to support cameras with larger serial command sets; the ::importStateCopy may truncate serial commands to the fixed length portion of the pxcamcntl. Use of ::importAllocStateCopy instead of ::importStateCopy is recommended.

The pathname specifies the file's path name.[33] The filemode specifies the file's fopen mode, or may be NULL for default. For ::exportStateCopy and the default filemode, any existing file pathname is deleted and a new file pathname created.

For ::exportStateCopy, the optional progname and filecomment provide text for comments to be written into the file. The stateindex is reserved and should be 0. The stateid is an arbitrary, non-zero, numeric state identification which distinguishes the Video Format Configuration settings from others in the same file. It does NOT necessarily reference a video state id currently defined in the library.

For ::importStateCopy and ::importAllocStateCopy, the pathname may contain multiple Video Format Configurations. If stateid>0, a Video Format Configuration previously saved with the same stateid is imported. stateid<0, the stateindex'th sequential Video Format Configuration in the pathname is imported; where the stateindex is 1 for the first, 2 for the second, etc. The stateid does NOT necessarily reference a video state id currently defined in the library.


Returns


9999
A complete set of Video Format Configuration structures and substructures imported (for ::importStateCopy).

≥0
The number of Video Format Configuration substructures imported (for ::importStateCopy and ::importAllocStateCopy).

0
Operation complete (for ::exportStateCopy).

PXERROR
Invalid parameters.

PXERBADSTRUCT
The statep's ddch.mos or ddch.len signature was incorrect.

PXERNOFILE
File can't be read (for ::importStateCopy and ::importAllocStateCopy).

PXERNEWFILE
File can't be created or written (for ::exportStateCopy).

PXERFILEFORM
The file format is invalid.

PXER...
Other error codes as appropriate.

Fixup Video State --- ::xclib.fixxStateCopy
Fill Video State --- ::xclib.fillStateCopy
Sign Video State --- ::xclib.signStateCopy



Summary
int (xclib.fixxStateCopy)  (&xclib, options, stateid, statep);
int (xclib.fillStateCopy)  (&xclib, options, stateid, statep, buffer);
int (xclib.signStateCopy)  (&xclib, options, stateid, statep, adrsspace, mode);

struct xclibservice xclib; // A xclibservice instance int options; // Reserved, should be 0 int stateid; // Video state id, should be 0 struct pxvidstate *statep; // Pointer to video state pxbuffer_t buffer; // Image frame buffer
int mode; // 's': sign, 'c': check signature, 'r': get adrsspace int adrsspace; // 'i': image frame buffer memory // 'p': physical memory // 'u': application memory



Description

The ::fixxStateCopy normalizes the Video Configuration Parameters referenced by the statep instance of the pxvidstate structure. The Video Configuration Parameters are normalized to be internally consistent (typically by reference to the contents of the pxvidformat structure), and to be consistent with the capabilities of the current imaging board.

The ::fillStateCopy fills the pxvidphys structure of the Video Configuration Parameters to refer to image frame buffer number buffer, buffer≥1, within the imaging board's frame buffer memory.

The ::signStateCopy signs the pxvidphys structure of the Video Configuration Parameters as containing valid addresses which refer to memory other than the image frame buffer memory, or checks whether the pxvidphys structure of the Video Configuration Parameters is properly signed.


Returns


0
Operation complete.

PXERROR
Invalid parameters. In particular, for ::fillStateCopy, a buffer which is less than one or greater than the number of buffers which fit within frame buffer memory.

PXERBADSTRUCT
The statep's ddch.mos or ddch.len signature was incorrect.

PXER...
Other error codes as appropriate.

Set Default Configuration Copy of Video State --- ::pxlib.initStateCopy

Set Default Configuration & Allocate Copy of Video State --- ::pxlib.initAllocStateCopy



Summary
int (pxlib.initStateCopy)     (&pxlib, options, stateid, statep, infop, formatname, vidmode);
int (pxlib.initAllocStateCopy)(&pxlib, options, stateid, statepp, infop, formatname, vidmode);

struct pxlibservice pxlib; // A pxlibservice instance int options; // Reserved, should be 0 int stateid; // Video state id, should be 0 struct pxvidstate *statep; // Pointer to video state struct pxvidstate **statepp; // Pointer to video state pointer struct pxdevinfo *info; // Description of imaging board char *formatname; // A predefined name of video format int vidmode; // A PXMODE_ value



Description

The ::initStateCopy initializes the statep instance of the pxvidstate structure to the default Video Configuration Parameters appropriate to the imaging board described in info, with the formatname predefined name of a standard video configuration format, and suitable to an activity specified by vidmode.

The ::initAllocStateCopy initializes a malloc'ed set of Video Format Configuration structures to the default Video Configuration Parameters appropriate to the imaging board described in info, with the formatname predefined name of a standard video configuration format, and suitable to an activity specified by vidmode. The *statepp must initially be NULL; the pointer to the allocated pxvidstate structure and substructures is ''returned'' at *statepp. When no longer needed, the allocated pxvidstate structure and substructures should be free'ed with ::freeStateCopy.

The info for the current imaging board may be obtained from ::getDevInfo. The allowable predefined names of standard video configuration format are described in pxd_PIXCIopen. The vidmode is a PXMODE_ type value, such as PXMODE_DIGI to indicate that the Video Configuration Parameters are to be used for capturing.

Circa 2011, the pxcamcntl substructure of the pxvidstate was extended to be variable length to support cameras with larger serial command sets; the ::initStateCopy may truncate the serial commands to the fixed length portion of the pxcamcntl. Use of ::initAllocStateCopy instead of ::initStateCopy is recommended.


0
Operation complete.

PXERROR
Invalid parameters.

PXERBADSTRUCT
The statep's ddch.mos or ddch.len signature was incorrect.

PXERSEARCH
The formatname was invalid.

PXERVIDFORM
The formatname is a valid string, but the specified format is not supported on the imaging board described by info.

PXER...
Other error codes as appropriate.

Declare Instance of Video Format Configuration Structures --- xclib_DeclareVidStateStructs
Initialize Instance of Video Format Configuration Structures --- xclib_InitVidStateStructs
Declare Instance of Video Format Configuration Structures --- xclib_DeclareVidStateStructs2
Initialize Instance of Video Format Configuration Structures --- xclib_InitVidStateStructs2



Summary
#define xclib_DeclareVidStateStructs(Name)              // deprecated
#define xclib_InitVidStateStructs(Name)                  // deprecated
#define xclib_DeclareVidStateStructs2(Name, Model)
#define xclib_InitVidStateStructs2(Name, Model)



Description

The xclib_DeclareVidStateStructs2 macro declares a instance of a pxvidstate structure named Name, and all of the pxvidstate substructures with decorated names starting with Name, suitable for frame grabber model Model. The Model should be a model designation as returned by pxd_infoModel.

The xclib_InitVidStateStructs2 initializes the structures previously declared by xclib_DeclareVidStateStructs2, setting the pxvidstate fields to point its substructures, and setting the ddch.mos and ddch.len structure signatures.

These macros provide only C/C++ declaration and initialization of structures; there is no effect on the XCLIB library's or the imaging board's state.

Use of xclib_InitVidStateStructs2 and xclib_DeclareVidStateStructs2 to allocate the pxvidstate structure and substructures in ''auto'' storage (i.e on the stack) is, potentially, slightly more efficient than using ::allocStateCopy.

Circa 2011, the pxcamcntl substructure of the pxvidstate was extended to be variable length to support cameras with larger serial command sets; use of xclib_InitVidStateStructs2 and xclib_DeclareVidStateStructs2 followed by ::getState may truncate serial commands to the fixed length portion of the pxcamcntl. Use of ::getAllocState instead of xclib_InitVidStateStructs2 and xclib_DeclareVidStateStructs2 is recommended when the contents of the pxcamcntl substructure is required.

Circa 2011, the xclib_DeclareVidStateStructs and xclib_InitVidStateStructs which do not use a Model designator, were deprecated. The older xclib_DeclareVidStateStructs and xclib_InitVidStateStructs will work with PIXCI® A, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1POCL, EC1, ECB1, ECB134, ECB2, EL1, EL1DB, ELS2, SI, SI2, SI4, SI1, SV2, SV3, SV4, SV5, and SV7 imaging boards but not with the PIXCI® A310 imaging board. The xclib_DeclareVidStateStructs2 and xclib_InitVidStateStructs2 will work with all PIXCI® imaging boards.


 

 

 

7. Structured Style Interface - Memory Access Services

The Memory Access services provide several methods of accessing image data or other memory associated with the imaging board.

The ::initPximage, ::initPximage3, ::initFilteredPximage, and ::initFilteredPximage3, are the suggested services for accessing imaging board memory. Use of the low level ::io, ::getImap, and ::freeImap services should be minimized.


Obtain Pointer into Imaging Board Memory --- ::pxdev.getImap
Free Pointer into Imaging Board Memory --- ::pxdev.freeImap



Summary
int (pxdev.getImap)  (pxdevservice_s *me, options, unitmap, adrs, altspace, accessptr, accesslen);
int (pxdev.freeImap) (pxdevservice_s *me, options, unitmap, adrs, altspace, accessptr, accesslen);

struct pxdevservice pxdev; // A pxdevservice instance int options; // Reserved, should be 0 int unitmap; // Unit selection bit map (1 for single unit) uint32 adrs; // Address of imaging board memory uint altspace; // 0: image frame buffer memory uchar _farimap **accessptr; // Returned pointer to imaging board memory address pximaplen_t *accesslen; // Returned access length, may be NULL // _farimap is a predefined adjective: // <blank> [in Windows 32 bit environments] // <blank> [in Windows 64 bit environments] // <blank> [in Linux 32 bit environments] // <blank> [in Linux 64 bit environments] // _far [in DOS+Tenberry environments]



Description

The ::getImap obtains and returns a pointer into memory associated with the imaging board, if available. The ::freeImap frees a pointer previously obtained with ::getImap.

The unitmap specifies the single unit to which a pointer is to be obtained. The adrs specifies the zero based address within the imaging board memory. The altspace=0 selects the image frame buffer memory.

If a pointer to the requested memory can be obtained, the pointer is ''returned'' at *accessptr, and the length in bytes for which the pointer is valid is ''returned'' at *accesslen. The accesslen may be NULL; no length information is returned.

The *accessptr and *accesslen allows accessing a range of memory without additional use of ::getImap; the bytes of imaging board memory from adrs through adrs+accesslen-1 can be accessed by using *accessptr through *accessptr+accesslen-1.

The availability of a direct pointer into imaging board memory varies with the type of imaging board, the state of the imaging board, the current operating system, and the current Driver Configuration Parameters.

Under Windows 95, 98, ME, NT, 2000, XP, XP(x64), Vista, Vista(x64), 7 and 7(x64): The access pointer provided by ::getImap can be used by the application to access imaging board memory, but cannot be passed to other applications or to system services such as file I/O.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Obtain pximage Access into Imaging Board Memory --- ::pxlib.initPximage
Obtain pximage3 Access into Imaging Board Memory --- ::pxlib.initPximage3
Obtain Filtered pximage Access into Imaging Board Memory --- ::pxlib.initFilteredPximage
Obtain Filtered pximage3 Access into Imaging Board Memory --- ::pxlib.initFilteredPximage3



Summary
int (pxlib.initPximage)         (&pxlib, unitmap, ip,  ipcnt, colorhint, altspace, stateid,
                                 framebuf, mbpcihint);
int (pxlib.initPximage3)        (&pxlib, unitmap, ip3, ipcnt, colorhint, altspace, stateid,
                                 unused,   mbpcihint);
int (pxlib.initFilteredPximage) (&pxlib, unitmap, ip,  ipcnt, colorhint, altspace, stateid,
                                 framebuf, mbpcihint, colormap);
int (pxlib.initFilteredPximage3)(&pxlib, unitmap, ip3, ipcnt, colorhint, altspace, stateid,
                                 unused,   mbpcihint, colormap);

struct pxlibservice pxlib; // A pxlibservice instance int unitmap; // Unit selection bit map (1 for single unit) struct pximage ip[]; // Array of pximage's struct pximage ip3[]; // Array of pximage3's int ipcnt; // Dimension of ip or ip3 int colorhint; // Requested color representation uint altspace; // 0: image frame buffer memory int stateid; // Video state id pxbuffer_t framebuf; // Image frame buffer int mbpcihint; // Reserved, should be 0 int colormap; // Pixel value component selection



Description

A pximage or pximage3 is initialized so as to provide access to the imaging board's frame buffers, or to other memory associated with the imaging board. The ::initPximage provides access to a single image frame buffers, in the color space(s) directly obtainable from the image frame buffer. The ::initPximage3 provides access to a sequence of all image frame buffers, in the color space(s) directly obtainable from the image frame buffer. The ::initFilteredPximage and ::initFilteredPximage3 are similar, but initializes additional conversions, as needed, to provide any supported color space interpretation of the image frame buffers.

These services initialize the pximage or pximage3 structures provided; thereafter these structures can be used to access pximage or pximage3 services.

The unitmap specifies the single unit to which access is to be provided. The stateid specifies a video state id previously defined by ::defineState, against which the framebuf is interpreted.

The ip or ip3 specify instances of an array of pximage or pximage3 structures; the ipcnt specifies the number of structures provided. In the worst case, ::initPximage and ::initPximage3 may require ipcnt=PXMAX_IRBGF, ::initFilteredPximage and ::initFilteredPximage3 may require ipcnt=PXMAX_FIRBGF.

The colorhint is a PXHINT... type value specifying the desired color space. The colorhint may not be available; the ip or ip3 may be initialized so as to access the image frame buffers with a different color space. More colorhint's are available through use of ::initFilteredPximage and ::initFilteredPximage3 instead of ::initPximage and ::initPximage3.

For ::initFilteredPximage and ::initFilteredPximage3, the colormap selects which color component values are to be accessed. The colormap is a bit-map; the i'th bit selects the i'th color component.

If altspace=0, access is provided to image frame buffers. For PIXCI® A, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 imaging boards, using altspace=(('t'<<8)|'s') provides access to the four byte video field counter attached to each captured frame buffer.


Returns


≥1
Operation complete. The return value indicates the number of pximage or pximage3 structures used.

PXERROR
Invalid parameters.

PXERMORESPACE
There are insufficient pximage or pximage3 structures to provide access.

PXER...
Other error codes as appropriate.

Read/Write Imaging Board Memory --- ::pxdev.io
Read/Write Imaging Board Memory, Sparsely --- ::pxdev.iosparse



Summary
int (pxdev.io)       (&pxdev, options, unitmap, adrs, altspace, buf, cnt, rw, async, time);
int (pxdev.iosparse) (&pxdev, options, unitmap, adrs, altspace, buf, cnt, rw, async, time,blksize,blkpitch);
struct pxdevservice pxdev;          // A pxdevservice instance
int                 options;        // Reserved, should be 0
int                 unitmap;        // Unit selection bit map (1 for single unit)
uint32              adrs;           // Address of imaging board memory
uint                altspace;       // 0: image frame buffer memory
void                *buf;           // Application program buffer
size_t              cnt;            // Transfer count, bytes
uint                rw;             // PXREAD: Copy into application buffer
                                    // PXRITE: Copy from application buffer
pxasync_s           *async;         // Reserved, should be NULL
pxtimespec_s        *time;          // Reserved, should be NULL
size_t              blksize;        // Count   sparse
size_t              blkpitch;       // Address sparse



Description

The contents of imaging board memory is copied to or from an array or buffer provided by the application.

The unitmap specifies the single unit from which memory is to be copied. The adrs specifies the zero based address within the imaging board memory. The altspace=0 selects the image frame buffer memory. The buf specifies an array or buffer provided by the application. The cnt specifies the number of bytes to be read or written. The rw=PXREAD chooses read of the imaging board memory into the *buf; rw=PXRITE chooses write of the imaging board memory from the *buf.

For ::iosparse, the cnt bytes are accessed at non consecutive locations in frame buffer memory, to or from consecutive locations in the array or buffer provided by the application; blksize bytes at location adrs, followed by blksize bytes at location adrs+blkpitch, etc.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

 

 

 

8. Structured Style Interface - Video Services


Get Live/Snap Status --- ::xcdev.getLiveStatus



Summary
int (xcdev.getLiveStatus) (&xcdev, unitmap, rsvd1, mode);
struct xcdevservice xcdev;          // A xcdevservice instance
int                 unitmap;        // Unit selection bit map (1 for single unit)
int                 rsvd1;          // Reserved, should be 0
int                 mode;           // Status to check



Description

The status of the current video snap or live modes initiated by ::setSnapBuf, ::setSnapPairBuf, ::setLiveBuf, ::setLivePairBuf, ::setLiveSeqBuf, ::setLiveTrigBuf, ::setLivePhys, ::setUnLive, or ::setAbortLive is returned.

The mode specifies the status to be returned.

mode status returned

PXVIST_QUEUED | PXVIST_STATEID video state id in queue for captured
PXVIST_QUEUED | PXVIST_BUFFER image frame buffer in queue for captured
PXVIST_QUEUED | PXVIST_VIDMODE video mode (PXMODE...) in queue for captured
PXVIST_RUNNING | PXVIST_STATEID video state id now being captured
PXVIST_RUNNING | PXVIST_BUFFER image frame buffer now being captured
PXVIST_RUNNING | PXVIST_VIDMODE video mode (PXMODE...) now being captured
PXVIST_DONE | PXVIST_STATEID video state id of last captured buffer
PXVIST_DONE | PXVIST_BUFFER image frame buffer of last captured buffer
PXVIST_DONE | PXVIST_VIDMODE video mode (PXMODE...) of last captured buffer
PXVIST_DONE | PXVIST_VCNT video field count of last captured buffer
PXVIST_DONE | PXVIST_SYSTICKS0 low uint of system time of last captured buffer
PXVIST_DONE | PXVIST_SYSTICKS1 high uint of system time of last captured buffer
With mode=PXVIST_DONE|PXVIST_SYSTICKS0 and mode=PXVIST_DONE|PXVIST_SYSTICKS1 the return value should be interpreted as, and cast to, a ''uint''. The return value is 0 if the status request does not apply, such as using PXVIST_RUNNING|PXVIST_STATEID when the imaging board is done capturing.

For mode=PXVIST_DONE|PXVIST_SYSTICKS0 and mode=PXVIST_DONE|PXVIST_SYSTICKS1: The time provided by the operating system is recorded by software's response to a hardware interrupt after the frame is captured, and provided on request. No claim is made regarding the operating system clock's accuracy, repeatability, or resolution, nor the latency between the end of frame capture and software's recording of the time.

The ::getLiveStatus normally obtains the status of the single unit selected by unitmap. If the mode is OR'ed with PXVIST_ORUNITS, ::getLiveStatus obtains the status of the multiple units selected by unitmap; OR'ing the individual status of each unit together and returning the result. This, combined with the default return value of 0 when the status request does not apply, allows checking whether all units have completed a snap or live operation with a single invocation.

The differentiation and exact timing of whether or when an imaging board's status qualifies for PXVIST_RUNNING or for PXVIST_QUEUED is imaging board dependent. For example, when ::setSnapBuf is issued, and before the start of the next video frame arrives, the pending request might considered either PXVIST_RUNNING or PXVIST_QUEUED. Similarly, after issuing ::setLiveBuf and continuously capturing into a single buffer, during the blanking period between frames the PXVIST_RUNNING modes may return zero.


Returns

Returns video status. Also may return PXER... codes.


Get Current Video Status --- ::pxdev.getVidStatus
Get Extended Video Status --- ::xcdev.getVidStatus
Get Current Video Status Value --- ::pxdev.getVidStatusValue



Summary
int    (pxdev.getVidStatus)      (&pxdev, unitmap, rsvd1, pxstatus, mode);
int    (xcdev.getVidStatus)      (&xcdev, unitmap, rsvd1, xcstatus, mode);
uint32 (pxdev.getVidStatusValue) (&pxdev, unitmap, rsvd1, mode, offset);

struct pxdevservice pxdev; // A pxdevservice instance struct xcdevservice xcdev; // A xcdevservice instance int unitmap; // Unit selection bit map (1 for single unit) int rsvd1; // Reserved, should be 0 int mode; // Selection mode struct pxvidstatus *pxstatus; // Video status struct pxvidstatus *xcstatus; // Extended video status size_t offset; // Offset to single value in pxvidstats



Description

The ::pxdev.getVidStatus obtains the current video status of the single imaging board selected by unitmap, ''returning'' the status in the pxstatus instance of the pxvidstatus structure.

The ::xcdev.getVidStatus obtains the current extended video status of the single imaging board selected by unitmap, ''returning'' the status in the xcstatus instance of the xcvidstatus structure.

The ::getVidStatusValue returns one ''uint32'' value of the current video status of the single imaging board selected by unitmap, avoiding having to transfer an entire structure in order to observe one value. The most common use is to obtain the current video field count:

    xclib.pxdev.getVidStatusValue(&xclibs.pxdev, 1, 0, PXSTAT_LASTIRQ, Offset(pxvidstatus2, time.vcnt));
where the Offset macro is defined in the C/C++ library.

If mode=PXSTAT_LASTIRQ, the video status returned is as of the last interrupt, regardless of the interrupt's cause. If mode=PXSTAT_LASTVSP, the video status returned is as of the last Vertical Switch Point interrupt; typically the start or end (imaging board dependent) of vertical drive at which a ''switch'' of capture video status is performed. If mode=PXSTAT_UPDATED, the video status returned is that as of the instant of execution of ::pxdev.getVidStatus, ::xcdev.getVidStatus, or ::getVidStatusValue.


Returns

For ::pxdev.getVidStatus and ::xcdev.getVidStatus:


0
Operation complete

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

The ::getVidStatusValue returns the requested value, or a PXER... code cast to a uint32.


Get Current Buffer Status --- ::pxlib.goingBufStatus



Summary
int    (pxlib.goingBufStatus)    (&pxlib, options, unitmap, buffer, status);

struct pxlibservice pxlib; // A pxlibservice instance int options; // Reserved, should be 0 int unitmap; // Unit selection bit map (1 for single unit) pxbuffer_t buffer; // Image frame buffer int mode; // Selection mode struct pxbufstatus *status; // Buffer status



Description

The ::pxlib.goingBufStatus obtains the status of image frame buffer of the single imaging board selected by unitmap, ''returning'' the status in the status instance of the pxbufstatus structure.

Some of the status information returned is similar or identical to that obtained via ::getLiveStatus. However, the ::getLiveStatus returns information on the current status, or the status when the last buffer was captured. In contrast, the ::pxlib.goingBufStatus obtains status information about a specific buffer, returning status information stored with the buffer.

Capture status information may not stored for each frame buffer, depending on frame buffer memory configuration such as use of forceful memory allocation and/or the ''-MU'' Driver Configuration Parameters.


Returns


0
Operation complete

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Initiate Snap into Frame Buffer --- ::xcdev.setSnapBuf
Initiate Snap Pair into Frame Buffers --- ::xcdev.setSnapPairBuf
Initiate Continuous Capture into Frame Buffer --- ::xcdev.setLiveBuf
Initiate Continuous Alternate Capture into Frame Buffers --- ::xcdev.setLivePairBuf
Initiate Continuous Capture into Memory Space --- ::setLivePhys



Summary
int (xcdev.setSnapBuf)     (&xcdev, unitmap, rsvd1, stateid, statep, time, buf1, tracker1);
int (xcdev.setSnapPairBuf) (&xcdev, unitmap, rsvd1, stateid, statep, time, buf1, tracker1, buf2,
                            tracker2);
int (xcdev.setLiveBuf)     (&xcdev, unitmap, rsvd1, stateid, statep, time, buf1, tracker1);
int (xcdev.setLivePairBuf) (&xcdev, unitmap, rsvd1, stateid, statep, time, buf1, tracker1, buf2,
                            tracker2, period);
int (xcdev.setLivePhys)    (&xcdev, unitmap, rsvd1, stateid, statep, time, vidphys);

struct xcdevservice xcdev; // A xcdevservice instance int unitmap; // Unit selection bit map (1 for single unit) int rsvd1; // Reserved, should be 0 int stateid; // Video state id, or 0 struct pxvidstate *statep; // Pointer to video state, or NULL struct pxtimespec *time; // Reserved, should be NULL pxbuffer_t buf1; // Image frame buffer pxbuffer_t buf2; // Image frame buffer int tracker1; // Reserved, should be 0 int tracker2; // Reserved, should be 0 int period; // Reserved, should be 1 struct pxvidphys vidphys[]; // Memory space specification



Description

The ::setSnapBuf initiates a snap of a single video field or frame on the multiple units selected by unitmap into image frame buffer buf1.

The ::setSnapPairBuf initiates a snap of a pair of video fields or frames on the multiple units selected by unitmap into image frame buffers buf1 and buf2; it is intended for use only with cameras with a so-called ''Triggered Dual Exposure'' mode.

The ::setLiveBuf initiates continuous capture of video fields or frames on the multiple units selected by unitmap into image frame buffer buf1.

The ::setLivePairBuf initiates continuous capture of video fields or frames on the multiple units selected by unitmap into alternating image frame buffers buf1 and buf2.

If stateid≠0, the Video Format Configuration associated with that video state id by ::defineState is used to interpret the buf1 and buf2. If statep≠NULL, the Video Format Configuration contained in the statep instance of the pxvidstate structure is used to interpret the buf1 and buf2. The stateid≠0 and statep≠NULL should not both be specified.

The ::setVideoConfig must have been previously invoked to configure the imaging board to the Video Format Configuration specified by stateid or statep.

The ::setLivePhys initiates continuous capture of video fields or frames on the multiple units selected by unitmap into the memory space specified by vidphys. There must be one element of vidphys for each unit selected by unitmap; e.g. for unitmap=9, the vidphys[0] is used for unit 0, and the vidphys[1] is used for unit 3.

The ::setSnapBuf, ::setSnapPairBuf, ::setLiveBuf, ::setLivePairBuf, and ::setLivePhys have effect and return ''immediately''; i.e. without regards to, or waiting for, video sync or completion of capture of the video field or frames.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXERRESOURCEBUSY
Video is already being captured and must be terminated before initiating a new capture.

PXER...
Other error codes as appropriate.

Initiate Sequence Capture into Frame Buffers --- ::setLiveSeqBuf



Summary
int (xcdev.setLiveSeqBuf)(&xcdev, unitmap, rsvd1, stateid, statep, time, startbuf, endbuf,
                          incbuf, numbuf, period, trackers);

struct xcdevservice xcdev; // A xcdevservice instance int unitmap; // Unit selection bit map (1 for single unit) int rsvd1; // Reserved, should be 0 int stateid; // Video state id, or 0 struct pxvidstate *statep; // Pointer to video state, or NULL struct pxtimespec *time; // Reserved, should be NULL pxbuffer_t startbuf; // Image frame buffer start pxbuffer_t endbuf; // Image frame buffer end pxbuffer_t incbuf; // Image frame buffer increment pxbuffer_t numbuf // Number of Image frame buffers int period; // Period between captured fields or frames int trackers; // Reserved, should be 0



Description

The ::setLiveSeqBuf initiates a snap of a sequence of video fields or frames on the multiple units selected by unitmap.

The ::setLiveSeqBuf initiates sequence capture of images into startbuf through endbuf. The sequence capture starts into startbuf and continues into frame buffers startbuf+incbuf*1, startbuf+incbuf*2, etc., wrapping around from the endbuf back to the startbuf. Typically incbuf=1 for use of consecutive ascending frame buffers. The numbuf specifies the number image frame buffers to be captured. Typically, numbuf is endbuf-startbuf+1 for simple sequence capture, or 0 for continuous (i.e. ''circular'') sequence capture. The videoperiod specifies the time interval, in video fields or frames, between captured image frame buffers. Typically, videoperiod=1 for video rate capture. For non-interlaced video formats, the videoperiod is in fields. For interlaced video formats, the videoperiod is in units of frames, unless, a) Each image frame buffer is configured to contain only one field, and b) Video ''switching'' is configured to take place after the ''next'', rather than after an ''odd'' or an ''even'' field.

If stateid≠0, the Video Format Configuration associated with that video state id by ::defineState is used to interpret the startbuf through endbuf. If statep≠NULL, the Video Format Configuration contained in the statep instance of the pxvidstate structure is used to interpret the startbuf through endbuf. The stateid≠0 and statep≠NULL should not both be specified.

The ::setVideoConfig must have been previously invoked to configure the imaging board to the Video Format Configuration specified by stateid or statep.

The ::setLiveSeqBuf has effect and returns ''immediately''; i.e. without regards to, or waiting for, video sync or completion of capture of the video field or frames.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXERRESOURCEBUSY
Video is already being captured and must be terminated before initiating a new capture.

PXER...
Other error codes as appropriate.

Initiate Triggered Capture into Frame Buffer --- ::setLiveTrigBuf



Summary
int (xcdev.setLiveTrigBuf)(&xcdev, unitmap, rsvd1, stateid, statep, time, buf, tracker, trigspec);

struct xcdevservice xcdev; // A xcdevservice instance int unitmap; // Unit selection bit map (1 for single unit) int rsvd1; // Reserved, should be 0 int stateid; // Video state id, or 0 struct pxvidstate *statep; // Pointer to video state, or NULL struct pxtimespec *time; // Reserved, should be NULL pxbuffer_t buffer; // Image frame buffer int tracker; // Reserved, should be 0 struct pxtrigspec trigspec; // Trigger specification



Description

The ::setLiveTrigBuf initiates a triggered capture of a video field or frame on the multiple units selected by unitmap.

The ::setLiveTrigBuf is not intended, and not needed for PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 imaging boards where the PIXCI® and/or camera hardware provides dedicated (typically asynchronous) triggering and ''single-shot'' capabilities. The ::setLiveTrigBuf is intended for cameras producing continuous video, and where the imaging board's General Purpose Input/Output signals are used to sense external events, and control external devices.

The trigspec instance of the pxtrigspec structure specifies how the General Purpose Input signal(s) are to be sensed, how the General Purpose Output signals are to be controlled, how many fields or frames to wait at each step, and when to conclude the capture.

The ::setLiveTrigBuf is not available for PIXCI® SV2 and SV3 imaging boards. For PIXCI® D, D24, and D32 imaging boards, the actual non-zero value of trigspec.gpin30wait is immaterial; the imaging board's hardware determines the edge sensitivity of the General Purpose Input.

If stateid≠0, the Video Format Configuration associated with that video state id by ::defineState is used to interpret the buffer. If statep≠NULL, the Video Format Configuration contained in the statep instance of the pxvidstate structure is used to interpret the buffer. The stateid≠0 and statep≠NULL should not both be specified.

The ::setVideoConfig must have been previously invoked to configure the imaging board to the Video Format Configuration specified by stateid or statep.

The ::setLiveTrigBuf has effect and returns ''immediately''; i.e. without regards to, or waiting for, video sync or completion of capture of the video field or frames. In execution, the ::setLiveTrigBuf implements continuous capture of multiple fields or frames (i.e. effectively a ::setLiveBuf) into the same buffer which at the appropriate time is terminated (i.e. effectively a ::setUnLive) leaving the last captured field or frame.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXERRESOURCEBUSY
Video is already being captured and must be terminated before initiating a new capture.

PXER...
Other error codes as appropriate.

Terminate Live/Snap into Frame Buffer --- ::xcdev.setUnLive
Abort Live/Snap into Frame Buffer --- ::xcdev.setAbortLive



Summary
int (xcdev.setUnLive)    (&xcdev, unitmap, rsvd1, stateid, statep, time);
int (xcdev.setAbortLive) (&xcdev, unitmap, rsvd1, stateid, statep, time);

struct xcdevservice xcdev; // A xcdevservice instance int unitmap; // Unit selection bit map (1 for single unit) int rsvd1; // Reserved, should be 0 int mode; // Status to check int stateid; // Reserved, should be 0 struct pxvidstate *statep; // Reserved, should be NULL struct pxtimespec *time; // Reserved, should be 0



Description

The current video capture mode initiated by ::setSnapBuf, ::setSnapPairBuf, ::setLiveBuf, ::setLivePairBuf, ::setLiveSeqBuf or ::setLiveTrigBuf is terminated. The ::setUnLive causes video capture to be terminated at the next appropriate field or frame boundary. The ::setAbortLive causes video capture to be terminated immediately, regardless of video timing.

Both ::setUnLive and ::setAbortLive return ''immediately'' without waiting for completion.

For PIXCI® CL3SD, the ::setAbortLive currently behaves the same as ::setUnLive.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Set Camera Configuration --- ::xcdev.setCameraConfig



Summary
int (xcdev.setCameraConfig) (&xcdev, unitmap, rsvd1, stateid, statep, time);

struct xcdevservice xcdev; // A xcdevservice instance int unitmap; // Unit selection bit map (1 for single unit) int rsvd1; // Reserved, should be 0 int stateid; // Video state id, or 0 struct pxvidstate *statep; // Pointer to video state, or NULL struct pxtimespec time; // Reserved, should be NULL



Description

The ::setCameraConfig configures the cameras connected to multiple imaging boards selected by unitmap to the camera control component of a Video Format Configuration.

The camera control component of a Video Format Configuration currently supports:

  1. Serial commands for Camera Link cameras. Only selected Camera Link cameras are supported.

  2. I2C commands for SILICON VIDEO® cameras.
The camera control component of a Video Format Configuration is intended to allow initializing the camera to a desired state; a state consistent with the portions of the Video Format Configuration used by ::setVideoConfig. XCLIB does not modify or maintain the camera control component; specifically, it does not record the commands send via other XCLIB services.

If stateid≠0, the Video Format Configuration associated with that video state id by ::defineState is used. If statep≠NULL, the Video Format Configuration contained in the statep instance of the pxvidstate structure is used. The stateid≠0 and statep≠NULL should not both be specified.

The ::setCameraConfig has effect and returns ''immediately''; i.e. without regards to video timing.

For most cameras, ::setCameraConfig checks the camera's response to each command. Thus, for most cameras, ::setCameraConfig will fail if the Video Format Configuration contains camera commands and the camera is not connected.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXERNOFEATURE
The camera control component of a Video Format Configuration did not contain any camera commands appropriate to the selected PIXCI® imaging card.

PXER...
Other error codes as appropriate.

Set Video Configuration --- ::xcdev.setVideoConfig
Adjust Video Configuration --- ::xcdev.setVideoAdjust



Summary
int (xcdev.setVideoConfig) (&xcdev, unitmap, rsvd1, stateid, statep, time);
int (xcdev.setVideoAdjust) (&xcdev, unitmap, rsvd1, stateid, statep, time);

struct xcdevservice xcdev; // A xcdevservice instance int unitmap; // Unit selection bit map (1 for single unit) int rsvd1; // Reserved, should be 0 int stateid; // Video state id, or 0 struct pxvidstate *statep; // Pointer to video state, or NULL struct pxtimespec time; // Reserved, should be NULL



Description

The ::setVideoConfig configures the multiple imaging boards selected by unitmap to a Video Format Configuration. Configuration always implies terminating any video capture currently in progress; termination is always immediate.

The ::setVideoAdjust adjusts the multiple imaging boards selected by unitmap to a Video Format Configuration. Only those features which can be adjusted without reconfiguration of image frame buffers or without terminating any video capture in progress are set.

If stateid≠0, the Video Format Configuration associated with that video state id by ::defineState is used. If statep≠NULL, the Video Format Configuration contained in the statep instance of the pxvidstate structure is used. The stateid≠0 and statep≠NULL should not both be specified.

The ::setVideoConfig and ::setVideoAdjust have effect and return ''immediately''; i.e. without regards to video timing.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

 

 

 

9. Structured Style Interface - Miscellaneous Services


General Purpose Input Signal: Sense --- ::xcdev.getGpin
General Purpose Input Signal: Reset --- ::xcdev.setGpin
General Purpose Output Signal: Set --- ::xcdev.setGpout
General Purpose Output Signal: Get --- ::xcdev.getGpout



Summary
int (xcdev.getGpin) (&xcdev, unitmap, time, rsvd1, rsvd2);
int (xcdev.setGpin) (&xcdev, unitmap, time, rsvd1, value);
int (xcdev.getGpout)(&xcdev, unitmap, time, rsvd1, rsvd2);
int (xcdev.setGpout)(&xcdev, unitmap, time, rsvd1, value);

struct xcdevservice xcdev; // A xcdevservice instance int unitmap; // Unit selection bit map (1 for single unit) struct pxtimespec *time; // Reserved, should be 0 int rsvd1; // Reserved, should be 0 int value; // Binary value(s) to set or reset



Description

The general purpose input and output signals are sensed, set, or reset.

The ::getGpin obtains the current value of the general purpose input signals, if any.

The ::setGpin resets the current value of the general purpose input signals, if any, as per value, for imaging boards where the general purpose inputs are latched rather than level sensitive.

The ::setGpout sets the current value of the general purpose output signals, if any, to value.

The ::getGpout gets the current value of the general purpose output signals, if any, returning a value in the same format as the value parameter of ::setGpout.

For ::getGpin and ::getGpout, the unitmap specifies the single unit for which the general purpose input signals are sensed or the current value of the general purpose output signals are obtained. For ::setGpin and ::setGpout, the unitmap specifies the multiple units for which the general purpose input signals are reset or the general purpose output signals are set.

For the PIXCI® SV2, SV3, SV4, SV5, and SV5A imaging boards: The boards' four general purpose output signals, XD4, XD5, XD6, and XD7, are set to the bits 0x01, 0x02, 0x04, and 0x08 of value, respectively. The boards' four general purpose input signals, XD0, XD1, XD2, and XD3, are sensed in bits 0x01, 0x02, 0x04, and 0x08, respectively, of the returned value of ::getGpin. The general purpose inputs are level sensitive, the ::setGpin has no effect.

For the PIXCI® SV5B imaging boards: The board does not provide general purpose input or output signals.

For the PIXCI® SV5L imaging board: The board's general purpose output signal, XD4, is set to bit 0x01 of value. The board's general purpose input signal, XD0, is sensed in bit 0x01 of the returned value of ::getGpin. The general purpose input is level sensitive, the ::setGpin has no effect.

For the PIXCI® ECB1-34 imaging board: The board does not provide general purpose input or output signals.

For the PIXCI® D, D24, and D32 imaging boards: The availability of general purpose inputs and outputs depends upon the board model, revision level, and video format configuration. The boards may have a single general purpose latched input signal, sensed as bit 0x01 of the returned value of ::getGpin, and reset as bit 0x01 of the value of ::setGpin. The boards may have a single general purpose latched output signal, set to bit 0x01 of value.

For the PIXCI® A310, CL2, CL3SD, D2X, D3X, E1, E4, E8, EB1, EB1-PoCL, EC1, EL1, SI, and SI1 imaging boards, and for each functional unit of the PIXCI® E1DB, EL1DB, E4DB, E8DB, ELS2, SI2, SI4, and SV7 imaging boards: The two general purpose output signals are set to bits 0x01 and 0x02 of value. The two general purpose input signals are sensed in bits 0x01 and 0x02 of the returned value of ::getGpin. The general purpose inputs are level sensitive, the ::setGpin has no effect.

For the PIXCI® ECB1 imaging board and for each functional unit of the PIXCI® ECB2 imaging board: The one general purpose output signal is set to bit 0x01 of value. The one general purpose input signal are sensed in bit 0x01 of the returned value of ::getGpin. The general purpose inputs are level sensitive, the ::setGpin has no effect.

For the PIXCI® CL1 imaging boards: The board's one (revision one boards) or two (revision two and later boards) general purpose output signals are set to bits 0x01 and 0x02 of value. The board's one (revision one boards) or two (revision two and later boards) general purpose input signals are sensed in bits 0x01 and 0x02 of the returned value of ::getGpin. The general purpose inputs are level sensitive, the ::setGpin has no effect.

Note: The general purpose input(s) and output(s) are those ''auxiliary'' features available on some imaging boards where, at the hardware level, the signal has no direct effect on video capture. The general purpose input(s) and output(s) are not related to, and not needed for, camera specific, hardware supported, typically asynchronous exposure, triggering features available on some cameras when used with the PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4.


Returns


0
Function performed, however this returned value is not proof that the imaging board supports the general purpose input(s) and output(s).

PXER...
Other error codes as appropriate.

Device Control --- ::pxdev.ioctl



Summary
int (pxdev.ioctl) (&pxdev,options,unitmap,adrs,space,subspace,buf,cnt,rw,async,time);
struct pxdevservice pxdev;          // A pxdevservice instance
int                 options;        // Reserved, should be 0
int                 unitmap;        // Unit selection bit map (1 for single unit)
uint32              adrs;           // Address of device
uint                space;          // Device selection space
uint                subspace;       // Device selection subspace
void                *buf;           // Application program buffer
size_t              cnt;            // Transfer count, bytes
uint                rw;             // PXREAD: Copy into program buffer
                                    // PXRITE: Copy from program buffer
pxasync_s           *async;         // Reserved, should be NULL
pxtimespec_s        *time;          // Reserved, should be NULL



Description

Various imaging board features are accessed and controlled.

For the PIXCI® CL1, CL2, CL3SD, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB, using ::ioctl with space=CCCC('U','A','R','T') provides access and control to the serial ports.[34] The unitmap specifies the single unit's serial port to be accessed and controlled.

If subspace=CCCC('C','F','G','a') and rw=PXRITE, the serial port is configured. The buf and cnt are expected to be a pointer to, and size of:

    int config[5];

config[0] = 96000; // baud rate * 10 config[1] = 0; // reserved config[2] = 8; // data bits config[3] = 'n'; // parity selection config[4] = 1; // stop bits
which specify the serial format. Values shown above correspond to the Camera Link standard. The PIXCI® CL2, and the PIXCI® CL1 Rev. 3 and later supports any baud rate between 192.0 and 12,500,000.0 baud, other serial format characteristics are fixed in hardware. The PIXCI® CL1 before Rev. 3 and the PIXCI® CL3SD support any baud rate between 95.4 and 6,250,000.0 baud, other serial format characteristics are fixed in hardware. The PIXCI® E1, E4, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, and EL1 supports any baud rate between 512.4 and 12,500,000.0 baud, other serial format characteristics are fixed in hardware. The PIXCI® E1DB, ECB2, EL1DB, E4DB, and E8DB supports any of the baud rates 9600, 19200, 38400, 57600, 115200, 230400, 460800, or 921600 baud (the Camera Link V2.0 Specification baud rates), other serial format characteristics are fixed in hardware.

If rw=PXREAD, cnt=0, and subspace=CCCC('R','C','V','1'), subspace=CCCC('R','C','V','0'), or subspace=CCCC('R','C','V','2'), the number of received characters waiting to be transferred from the internal receive queue, the space in characters available in the internal receive queue, or the size in characters of the internal receive queue, respectively, is returned. The buf must be a valid pointer, even though it is not used.

If subspace=CCCC('R','C','V','!'), rw=PXREAD, and cnt>0, received characters are transferred from the internal receive queue to the buffer buf, and deleted from the receive queue. The number of characters transferred is the smaller of cnt and the number of characters waiting in the receive queue; the same number is returned.

If subspace=CCCC('R','C','V','@') and rw=PXREAD, all characters in the internal receive queue are deleted and lost. The buf must be a valid pointer, even though it is not used.

If rw=PXREAD, cnt=0, and subspace=CCCC('X','M','T','0'), subspace=CCCC('X','M','T','1'), or subspace=CCCC('X','M','T','2'), the number of characters of empty space available in the transmit queue, the number of characters used in the transmit queue, or the size in characters of the transmit queue, respectively, is returned. The buf must be a valid pointer, even though it is not used.

If subspace=CCCC('U','A','R','T'), rw=PXRITE, and cnt>0, cnt characters are transferred from buffer buf to the transmit queue. The number of characters actually added to the transmit queue is the smaller of cnt and the number of characters of empty space available in the transmit queue; the same number is returned.

If subspace=CCCC('X','M','T','@') and rw=PXRITE, all characters in the internal transmit queue are deleted and lost. The buf must be a valid pointer, even though it is not used.

None of the serial port features wait for data to be received, or data to be transmitted; all return ''immediately'', save minimal execution time.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

 

 

 

10. Structured Style Interface - Auxiliary Services

The group of Auxiliary Services provides ''convenience'' features. These features could also be obtained by using more fundamental Structured Style Interface services, either combining several such services, or combining such services along with the Windows API, the ''C'' library API, and/or the PXIPL Image Processing Library functions.

For example, the ::imageReadUChar, and ::imageWriteUChar, is a combination of ::initPximage along with the pximage's ::ioread; the ::imageLoadBmp and ::imageSaveBmp combines ::initPximage with pxio8_bmpread and pxio8_bmpwrite of the PXIPL Image Processing Library; and the ::MessageBoxFault combines ::getFault with MessageBox of the Windows API.


Load Frame Buffers as Stream --- ::pxaux.bufferLoadStream
Save Frame Buffers as Stream --- ::pxaux.bufferSaveStream



Summary
int (pxaux.bufferSaveStream) (&pxaux, abortp, options, unitmap, stateid, startbuf,
                              endbuf, pathname, filehandle, fileoffset, alignsector,
                              rsvd2, rsvd3);
int (pxaux.bufferLoadStream) (&pxaux, abortp, options, unitmap, stateid, startbuf,
                              endbuf, pathname, filehandle, fileoffset, alignsector,
                              rsvd2, rsvd3);

struct pxauxservice pxaux; // A pxauxservice instance pxabortfunc_t **abortp; // Premature termination function, or NULL int options; // Options, should be 0, except as described below int unitmap; // Unit selection bit map (1 for single unit) int stateid; // Video state id pxbuffer_t startbuf; // First image frame buffer pxbuffer_t endbuf; // Last image frame buffer, inclusive char *pathname; // File path name to be read or written, or NULL void *filehandle; // Existing file handle to be read or written, or NULL pxbuffer_t fileoffset; // Offset into file, in units of image frame buffers uint32 alignsector; // Pad image frame buffer size to multiple of ... uint32 rsvd2; // Reserved, should be 0 uint32 rsvd3; // Reserved, should be 0



Description

A sequence of one or more consecutive image frame buffers is saved to, for ::bufferSaveStream, or loaded from, for ::bufferLoadStream, a file.

If pathname≠NULL, the image frame buffers are saved to, or loaded from, the pathname; for ::bufferSaveStream an already existing is not deleted and recreated, but partially or fully overwritten allowable replacement of one or more images within an existing file.[35] Alternately, a filehandle≠NULL, to a file previously opened by the application may be supplied. Under Windows the filehandle is expected to be a HANDLE provided by CreateFile. Under Linux the filehandle is expected to be a ''file descriptor'' provided by _open.

The unitmap specifies the single unit from which, or to which, image frame buffers are to be saved or loaded. The startbuf and endbuf, startbuf<=endbuf, specify the first and last image frame buffers, inclusive, to be saved or loaded. The entire image frame buffer is loaded or saved. The stateid specifies a video state id previously defined by ::defineState, against which the startbuf and endbuf are interpreted.

Each image frame buffer is saved to, or loaded from, the file sequentially starting at position fileoffset, where fileoffset is interpreted in units of the size of an image frame buffer. For example, fileoffset=0 starts at the beginning of the file, while fileoffset=1 starts with the second image frame buffer in the file. If alignsector≠0, the size of each saved image frame buffer, and thus the starting position relative to the beginning of the file, is padded to a multiple of alignsector bytes; typically so that each saved image frame buffer can be aligned on a multiple of the file system's sector size, or the operating system's virtual page size.

The image frame buffers are saved or loaded with a file format which is an exact copy, byte for byte, of the imaging board's frame buffer memory. The file format is intended for efficient saving and loading of image frame buffers; the actual format will vary with different imaging boards, or different video formats with a single imaging board. Use of these functions, and the file format created, is contraindicated for export to other (i.e. non-EPIX® imaging software) applications. Use is also contraindicated for archival storage, as reloading an image requires the presence of the same imaging board set to the same video format.

If options&1, then additional capture status information is prepended to each image frame buffer as saved, or the capture status information is set as each image frame buffer is loaded. The information saved or loaded is similar to that obtained via ::pxlib.goingBufStatus, but encoded within a pxbufstatusfile structure instead of a pxbufstatus structure. The pxbufstatusfile currently has a size of 64 bytes; all discussion above regarding the frame buffer size in the context of fileoffset and alignsector should be interpreted as the frame buffer size plus the size of the pxbufstatusfile structure. Depending on frame buffer memory configuration, the capture status information may not be available, or a frame buffer being saved may never have been captured; when saving, the applicable fields of the pxbufstatusfile structure are set to 0 values.

Use of the phrase ''stream'' is intended to suggest that memory containing multiple frame buffers can be saved or loaded efficiently, without delays due to frame buffer boundaries. It is not intended to suggest that these functions, by themselves, continuously save or load an ongoing video stream.

The operation will terminate prematurely if abortp≠NULL, and (*abortp)(...), tested periodically, returns a nonzero value.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXERNOFILE
File doesn't exist (for ::bufferLoadStream).

PXERNEWFILE
File can't be created (for ::bufferSaveStream).

PXER...
Other error codes as appropriate.

Errors: Translate Error Code to String --- ::pxaux.errorCodeString



Summary
int  (pxaux.errorCodeString) (&pxaux, errorcode);

struct pxauxservice pxaux; // A pxauxservice instance int errorcode; // Error return code



Description

Any of the ''PXER...'' error codes returned by various library functions, given as the errorcode parameter, is translated and returned as a suitable, concise, NULL terminated error message string. A NULL value is returned if errorcode is not a recognized ''PXER...'' code.

The ::errorCodeString is identical to pxd_mesgErrorCode.


Returns

A char * to an error message, or NULL.


Errors: Check & Report Faults --- ::pxaux.faultMessageBox
Errors: Check & Report Faults --- ::pxaux.faultPrintf



Summary
int (pxaux.faultMessageBox) (&pxaux, options, unitmap, fault, hWnd, lpCaption, uType);
int (pxaux.faultPrintf)     (&pxaux, options, unitmap, fault, stdio, head, tail);

struct pxauxservice pxaux; // A pxauxservice instance int options; // Reserved, should be 0 int unitmap; // Unit selection bit map (1 for single unit) struct pxdevfault *fault; // Fault to report, or NULL to check for new fault
HWND hWnd; // Parent Window for MessageBox LPCSTR lpCaption; // Caption for MessageBox, or NULL for default UINT uType; // Type of MessageBox, or 0 for default.
FILE *stdio; // Pointer to stream char *head; // Header to displayed fault, or NULL char *tail; // Footer to displayed fault, or NULL



Description

The ::faultMessageBox and ::faultPrintf display faults as described in a pxdevfault structure.

If fault=NULL, ::faultMessageBox and ::faultPrintf check whether a fault has occurred since the last check, and if so displays the fault. The unitmap specifies the single unit for which faults are checked and displayed.

If fault≠NULL, ::faultMessageBox and ::faultPrintf display the fault described by the fault instance of the pxdevfault structure; no check is made for any faults that may have occurred since the last check and unitmap is ignored.

For ::faultMessageBox, the fault's description is displayed in a Windows MessageBox; the Hwnd, lpCation, and uType are the window handle, caption, and type parameters passed to the MessageBox. If lpCation=NULL, a default caption is used. If uType=0, a type of MB_OK|MB_TASKMODAL is used.

For ::faultPrintf, the fault's description is output via the ''C'' standard I/O stream referenced by stdio. The optional head and tail may contain new-line ('\n') terminated text to be output above and below the fault's description.


Returns


1
Fault displayed.

0
No fault displayed.

PXERROR
Invalid parameters.

PXERBADSTRUCT
The fault's ddch.mos or ddch.len signature was incorrect.

PXER...
Other error codes as appropriate.



See Also

See ::getFault for additional discussion regarding the cause and nature of faults.


Load Image: BMP Format --- ::pxaux.imageLoadBmp
Load Image: TIFF Format --- ::pxaux.imageLoadTiff
Save Image: BMP Format --- ::pxaux.imageSaveBmp
Save Image: PCX Format --- ::pxaux.imageSavePcx
Save Image: TARGA Format --- ::pxaux.imageSaveTga
Save Image: TIFF Format --- ::pxaux.imageSaveTiff



Summary
int  (pxaux.imageLoadBmp) (&pxaux,options,unitmap,stateid,framebuf,ulx,uly,lrx,lry,pathname,loadmode);
int  (pxaux.imageLoadTiff)(&pxaux,options,unitmap,stateid,framebuf,ulx,uly,lrx,lry,pathname,loadmode);
int  (pxaux.imageSaveBmp) (&pxaux,options,unitmap,stateid,framebuf,ulx,uly,lrx,lry,pathname,loadmode);
int  (pxaux.imageSavePcx) (&pxaux,options,unitmap,stateid,framebuf,ulx,uly,lrx,lry,pathname,loadmode);
int  (pxaux.imageSaveTga) (&pxaux,options,unitmap,stateid,framebuf,ulx,uly,lrx,lry,pathname,loadmode);
int  (pxaux.imageSaveTiff)(&pxaux,options,unitmap,stateid,framebuf,ulx,uly,lrx,lry,pathname,loadmode);

struct pxauxservice pxaux; // A pxauxservice instance int options; // Reserved, should be 0 int unitmap; // Unit selection bit map (1 for single unit) int stateid; // Video state id pxbuffer_t framebuf; // Image frame buffer pxcoord_t ulx; // Upper left x coord. of area of interest pxcoord_t uly; // Upper left y coord. of area of interest pxcoord_t lrx; // Lower right x coord. exclusive of AOI pxcoord_t lry; // Lower right y coord. exclusive of AOI char *pathname; // File path name to load from, or save to int loadmode; // Resize: 'b': Bilinear, 'n': Nearest neighbor // Color Space: 0x100: convert, 0: no convert int savemode; // Reserved, should be 0



Description

An image frame buffer, or an area of interest within the frame buffer, is loaded from, or saved to, a file named pathname.

The ::imageLoadBmp, ::imageLoadTiff, ::imageSaveBmp, ::imageSavePcx, ::imageSaveTga, and ::imageSaveTiff, are identical to pxd_loadBmp, pxd_loadTiff, pxd_saveBmp, pxd_savePcx, pxd_saveTga, and pxd_saveTiff, respectively, except allowing use with an explicit instance of the XCLIB library via the pxaux parameter and using an explicit video state id specified by stateid, previously defined by ::defineState, against which the framebuf and other parameters are interpreted. All other parameters of ::imageLoadBmp, ::imageLoadTiff, ::imageSaveBmp, ::imageSavePcx, ::imageSaveTga, and ::imageSaveTiff, correspond in name and meaning to the parameters of pxd_loadBmp, pxd_loadTiff, pxd_saveBmp, pxd_savePcx, pxd_saveTga, and pxd_saveTiff.


Returns

Same as pxd_loadBmp, pxd_loadTiff, pxd_saveBmp, pxd_savePcx, pxd_saveTga, and pxd_saveTiff.


Read Pixel Values as Unsigned Char --- ::pxaux.imageReadUChar
Read Pixel Values as Unsigned Short --- ::pxaux.imageReadUShort
Read Pixel Values as Unsigned Int --- ::pxaux.imageReadUInt
Write Pixel Values as Unsigned Char --- ::pxaux.imageWriteUChar
Write Pixel Values as Unsigned Short --- ::pxaux.imageWriteUShort
Write Pixel Values as Unsigned Int --- ::pxaux.imageWriteUInt



Summary
int  (pxaux.imageReadUChar)  (&pxaux,options,unitmap,stateid,framebuf,nwx,nwy,sex,sey,ucharbuf,
                              cnt,colorspace,colormap,iomode,iodata);
int  (pxaux.imageReadUShort) (&pxaux,options,unitmap,stateid,framebuf,nwx,nwy,sex,sey,ushortbuf,
                              cnt,colorspace,colormap,iomode,iodata);
int  (pxaux.imageReadUInt)   (&pxaux,options,unitmap,stateid,framebuf,nwx,nwy,sex,sey,uintbuf,
                              cnt,colorspace,colormap,iomode,iodata);
int  (pxaux.imageWriteUChar) (&pxaux,options,unitmap,stateid,framebuf,nwx,nwy,sex,sey,ucharbuf,
                              cnt,colorspace,colormap,iomode,iodata);
int  (pxaux.imageWriteUShort)(&pxaux,options,unitmap,stateid,framebuf,nwx,nwy,sex,sey,ushortbuf,
                              cnt,colorspace,colormap,iomode,iodata);
int  (pxaux.imageWriteUInt)  (&pxaux,options,unitmap,stateid,framebuf,nwx,nwy,sex,sey,uintbuf,
                              cnt,colorspace,colormap,iomode,iodata);

struct pxauxservice pxaux; // A pxauxservice instance int options; // Reserved, should be 0 int unitmap; // Unit selection bit map (1 for single unit) int stateid; // Video state id pxbuffer_t framebuf; // Image frame buffer pxcoord_t ulx; // Upper left x coord. of area of interest pxcoord_t uly; // Upper left y coord. of area of interest pxcoord_t lrx; // Lower right x coord. exclusive of AOI pxcoord_t lry; // Lower right y coord. exclusive of AOI uchar ucharbuf[]; // Program's buffer to receive or originate values ushort ushortbuf[]; // Program's buffer to receive or originate values uint uintbuf[]; // Program's buffer to receive or originate values size_t cnt; // Size of ucharbuf, ushortbuf, or uintbuf, // in uchar's, ushort's or uint's, respectively. int colorspace; // Requested color representation int colormap; // Pixel value component selection int iomode; // Reserved, should be 0 int iodata; // Reserved, should be 0



Description

Pixel values from an image frame buffer are copied into, or copied from, an array or other memory buffer provided by the application program.

The ::imageReadUChar copies pixels from an image frame buffer into an ''unsigned char'' array or buffer provided by the application; the ::imageWriteUChar does the reverse. The ::imageReadUShort copies pixels from an image frame buffer into an ''unsigned short'' array or buffer provided by the application; the ::imageWriteUShort does the reverse. The ::imageReadUInt copies pixels from an image frame buffer into an ''unsigned int'' array or buffer provided by the application; the ::imageWriteUInt does the reverse.

The unitmap specifies the single unit from which, or to which, pixel values are to be read or written. The framebuf specifies the image frame buffer from which, or to which, pixel values are to be read or written. The ulx and uly respectively specify the horizontal (x) and vertical coordinate (y) of the upper left corner of an area of interest in the frame buffer to be used. The lrx and lry respectively specify a value one greater than the horizontal and vertical coordinate of the lower right corner of an area of interest in the frame buffer (i.e. an exclusive corner point) to be used. The lrx and lry may each be abbreviated to -1 to specify the extreme right horizontal coordinate (i.e. pxd_imageXdim) or the extreme bottom vertical coordinate (i.e. pxd_imageYdim), respectively. The stateid specifies a video state id previously defined by ::defineState, against which the framebuf, ulx, uly, lrx, and lry are interpreted.

The colorspace and colormap specifies the color space and color component(s) in which pixel values are to be read into, or written from, the program provided array or buffer. Valid choices for colorspace are:

colorspace Number of Components Color Representation

PXHINTRGB 3 Red, Green, Blue
PXHINTBGR 3 Blue, Green, Red (RGB reordered)
PXHINTBSH 3 Brightness, Saturation, Hue (HSB reordered)
PXHINTRGBX 4 Red, Green, Blue, Pad
PXHINTBGRX 4 Blue, Green, Red, Pad (RGB reordered)
PXHINTGREY 1 Grey Scale
PXHINTYCRCB 3 Intensity, Red Chroma, Blue Chroma
PXHINTYCRCBX 4 Intensity, Red Chroma, Blue Chroma, Pad
PXHINTBAYER 1 Raw Bayer Pattern Values
PXHINTCBYCRY 2 UYVY (Blue & Intensity, Red & Intensity)
PXHINTCMY 3 Cyan, Magenta, Yellow

The ''PXHINTBGRX'' selection, when read into a ''uchar'' buffer on Intel machines with little-endian architecture (i.e. least significant byte of multi-byte word has lowest address), with the buffer typecast to the Windows ''COLORREF'' type, results in pixels that are compatible with Windows' RGB() data type.

The ''PXHINTBAYER'' selection is available only in conjunction with cameras that actually output raw Bayer pattern values, and where the XCLIB would otherwise be responsible for converting the values to RGB(x) or BGR(x).

The ''PXHINTCBYCRY'' selection is available only in conjunction with imaging boards that actually capture CbYCrY (UYVY) values, and where the XCLIB would otherwise be responsible for converting the values to RGB(x), BGR(x), or YCrCb.

The colormap specifies which color components of the selected colorspace are to be read into, or written from, the program provided array or buffer. The colormap is a bit-map; the i'th bit selects the i'th color component. Example (but not an exhaustive list of) choices are:

colorspace colormap Color Components Selected

PXHINTRGB 0x01 Red
PXHINTRGB 0x02 Green
PXHINTRGB 0x04 Blue
PXHINTRGB 0x07 Red, Green, Blue
PXHINTRGBX 0x0F Red, Green, Blue, Pad
PXHINTBGR 0x01 Blue
PXHINTBGR 0x02 Green
PXHINTBGR 0x04 Red
PXHINTBGR 0x07 Blue, Green, Red
PXHINTBGRX 0x0F Blue, Green, Red, Pad
PXHINTBSH 0x01 Brightness
PXHINTBSH 0x02 Saturation
PXHINTBSH 0x04 Hue
PXHINTBSH 0x07 Brightness, Saturation, Hue (HSB reordered)
PXHINTGREY 0x01 Grey Scale
PXHINTYCRCB 0x01 Intensity
PXHINTYCRCB 0x02 Red Chroma
PXHINTYCRCB 0x04 Blue Chroma
PXHINTYCRCB 0x07 Intensity, Red Chroma, Blue Chroma
PXHINTCBYCRY 0x03 UYVY (Blue & Intensity, Red & Intensity)
Typically, only values of colormap which either select a single component, or select all components, are supported. Values of colormap which select other combinations of components are generally not supported.

The ucharbuf, ushortbuf, or uintbuf specifies a program provided array or buffer which pixel values are to be copied into, or copied from. The cnt specifies the number of unsigned chars , unsigned shorts or unsigned ints in the array or buffer referenced by ucharbuf, ushortbuf, or uintbuf, respectively. The cnt and the ucharbuf, ushortbuf, or uintbuf must be large enough to contain all of the pixel values implied by ulx, uly, lrx, lry, colorspace, and colormap; the cnt is not intended to be used to limit the number of pixel values transferred, but is rather intended to assert the maximum allowable transfer size and induce an error if the cnt is too small.

While these functions could be used to read or write a single pixel value with each invocation, they are intended, and more efficient, for reading or writing lines, columns, or entire images of pixel values.

Any data type, ''uchar'', ''ushort'', or ''uint'', and any colorspace can be chosen regardless of the image frame buffer's actual format. However, data type and color conversions may require additional computational overhead.

Each pixel value component is copied from, or copied into, a single ''uchar'', ''ushort'', or ''uint''; pixel values are not ''bit-packed''. If the data type has fewer bits that the pixel value component, the most significant bits of the pixel value component are copied into the data type, or are copied from the data type with lower order bits set to 0; e.g. a 10 bit per pixel component value of 1023 is stored in an 8 bit ''uchar'' as value 255. If the data type has more bits than the pixel value component, the pixel value component is copied into, or copied from, the data type's least significant bits; e.g. a 10 bit per pixel component value of 1023 is stored in an 16 bit ''ushort'' as value 1023.

Pixels are read or written, from or to the image, to or from membuf, in the order left-to-right and top-to-bottom. For color pixels with multiple components, the component values are read or written in packed, not planer, order.


Returns


≥0
Returns the number of pixel value components copied into, or copied from, the membuf.

PXERNOTOPEN
The library is not open for use.

PXERROR
Invalid parameters.

PXERTOOSMALL
The cnt is too small to contain the number of pixel value components specified by ulx, uly, lrx, lry, colorspace, and colormap.

PXER...
Other error codes as appropriate.



See Also

The ::initPximage, ::initPximage3, ::initFilteredPximage, and ::initFilteredPximage3 provides alternate methods of reading and writing pixel values, including top-to-bottom and left-to-right order, and, depending on memory configuration and colorspace options, direct pointer access to the pixel data.


Windows: Make Device Independent Bitmap --- ::pxaux.makeDIB
Windows: Free Device Independent Bitmap --- ::pxaux.freeDIB



Summary
int  (pxaux.makeDIB) (&pxaux,options,unitmap,stateid,framebuf,ulx,uly,lrx,lry,Hdibp);
int  (pxaux.freeDIB) (&pxaux,options,unitmap,stateid,framebuf,ulx,uly,lrx,lry,Hdibp);

struct pxauxservice pxaux; // A pxauxservice instance int options; // Reserved, should be 0 int unitmap; // Unit selection bit map (1 for single unit) int stateid; // Video state id pxbuffer_t framebuf; // Image frame buffer pxcoord_t ulx; // Upper left x coord. of area of interest pxcoord_t uly; // Upper left y coord. of area of interest pxcoord_t lrx; // Lower right x coord. exclusive of AOI pxcoord_t lry; // Lower right y coord. exclusive of AOI HANDLE *Hdibp // *NULL, becomes *HGLOBAL to DIB



Description

An image frame buffer, or an area of interest within the image frame buffer, is copied to a newly created Windows Device Independent Bitmap (DIB) in global memory (e.g. using the Windows' GlobalAlloc) and the handle to the DIB returned.

The ::makeDIB is identical to pxd_renderDIBCreate except allowing use with an explicit instance of the XCLIB library via the pxaux parameter and using an explicit video state id specified by stateid, previously defined by ::defineState, against which the framebuf and other parameters are interpreted. The *Hdibp must initially be NULL; the handle to the DIB is ''returned'' at *Hdibp.

The bitmap created must be freed by ::freeDIB when no longer needed. The options, unitmap, stateid, framebuf, ulx, uly, lrx, and lry parameters are not used and must be 0. After ::freeDIB, the *Hdibp is invalid, set to NULL, and must not be used with any function.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Windows: Display Image Frame Buffer On Device Context --- ::pxaux.StretchDIBits



Summary
int  (pxaux.StretchDIBits) (&pxaux, options, unitmap, stateid, framebuf, ulx, uly, lrx, lry,
                            winopts, hDC, nX, nY, nWidth, nHeight);

struct pxauxservice pxaux; // A pxauxservice instance int options; // Reserved, should be 0 int unitmap; // Unit selection bit map (1 for single unit) int stateid; // Video state id pxbuffer_t framebuf; // Image frame buffer pxcoord_t ulx; // Upper left x coord. of area of interest pxcoord_t uly; // Upper left y coord. of area of interest pxcoord_t lrx; // Lower right x coord. exclusive of AOI pxcoord_t lry; // Lower right y coord. exclusive of AOI HDC hDC; // Device context uint nX; // Display x position in hDC uint nY; // Display y position in hDC uint nWidth; // Display width in hDC uint nHeight; // Display height in hDC int winoptions; // Reserved, should be 0



Description

An image frame buffer, or an area of interest within the image frame buffer, is copied-rendered-displayed to a Windows device context, typically a display window or a printer context.

The ::StretchDIBits, is identical to pxd_renderStretchDIBits except allowing use with an explicit instance of the XCLIB library via the pxaux parameter and using an explicit video state id specified by stateid, previously defined by ::defineState, against which the framebuf and other parameters are interpreted. All other parameters of ::StretchDIBits, correspond in name and meaning to the parameters of pxd_renderStretchDIBits.


Returns

Same as pxd_renderStretchDIBits.


 

 

 

11. Structured Style Interface - Camera Services


Camera Control: SILICON VIDEO® 2112 --- PXCam_SILICONVIDEO2112



Summary
int PXCam_SILICONVIDEO2112(cmnd, rsvd, unitmap, porttype, port, camstatep, camstate2p, vidstatep);
int                 cmnd;           // A PXCam_ command verb
int                 rsvd;           // Reserved, should be 0
int                 unitmap;        // Unit selection bit map (1 for single unit)
int                 porttype;       // A PXCam_ port selection verb
void                *port;          // Point to port instance, dependent on porttype
PXCam_SV2112State_s *camstatep;     // Pointer to SILICON VIDEO parameters
PXCam_SV2112State_s *camstate2p;    // Pointer to SILICON VIDEO parameters
struct pxvidstate   *vidstatep;     // Pointer to video state

struct PXCam_SV2112State { struct pxddch ddch;
int id; // sensor id, as reported by camera int frameMode; // 's': still frame, 'v': video int aoiLeft; // AOI. These values are .. int aoiTop; // .. always relative to .. int aoiWidth; // .. full resolution and .. int aoiHeight; // .. independent of decimation int testRamp; // 0: off, 1: on int pixelRegistration; // 0: off, 1: on int scanDirection; // ('L'<<8)|'T': L-R/T-B // ('R'<<8)|'T': R-L/T-B // ('L'<<8)|'B': L-R/B-T // ('R'<<8)|'B': R-L/B-T int decimation; // encoded as 0xHHVV // 0x0101: none // 0x0202: 2x2 // 0x0404: 4x4 double gain[3]; // for R,G,B respectively, in db double exposure; // in milliseconds int rgbGainLock; // 0: off, 1: on double extendedLineTime; // in microseconds double pixelClkFreq; // in MHz. Info only which must be supplied
struct { // controlled mode: int mode; // 's', 'c' double framerate; // rate in 'c' mode, Hz. // min. retrigger period // in 's' mode (1/Hz). double exposure; // millisec int trigger; // 'n', '+', '-' int strobe; // 'n', 'p' int bits; // 8, 10 ... // internal use } adj; }; typedef struct PXCam_SV2112State PXCam_SV2112State_s;



Description

The PXCam_SILICONVIDEO2112 allows controlling the various options of the SILICON VIDEO® 2112 and SILICON VIDEO® 2112C cameras, by downloading and uploading camera parameters. It also allows mapping video state parameters into the camera parameters, or vice versa, so that the PIXCI® state can be consistent with that of the camera.

If cmnd=PXCam_SetDefaultValuesInCameraState, the camera state referenced by camstatep is initialized with camera default parameters. Other function arguments are not used.

If cmnd=PXCam_SetCorrectValuesInCameraState, the camera state referenced by camstatep is corrected so that the parameters are valid and consistent. Other function arguments are not used.

If cmnd=PXCam_MapCameraStateToVideoState, the camera state referenced by camstatep is used to modify the video state referenced by vidstatep so as to be consistent. This does not, by itself, implement the modified video state. Other function arguments are not used.

If cmnd=PXCam_MapVideoStateToCameraState, the video state referenced by vidstatep is used to modify the camera state referenced by camstatep so as to be consistent. This does not, by itself, implement the modified camera state. Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateViaHandle, the camera state referenced by camstatep is uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateDeltaViaHandle those portions of the camera state referenced by camstatep which is different than the corresponding portions of the camera state referenced camstate2p are uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_DownloadCameraStateViaHandle, the camera state referenced by camstatep is downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_DownloadCameraIDStateViaHandle, the ID portions of the camera state referenced by camstatep are downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_InitCameraStateViaHandle, the camera is (re)initialized with standard defaults. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_SetMinimumValuesInCameraState or cmnd=PXCam_SetMaximumValuesInCameraState the camera state referenced by camstate2p is filled with minimal or maximal allowed values, respectively, relative to the current camera state referenced by camstatep. Only the exposure, aoiWidth, aoiHeight, and gain members of the camera state referenced by camstate2p are currently set. Other function arguments are not used.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.



Example

The following example adjusts the camera's exposure and gain. It does not assume that the camera's current parameters are being kept in a PXCam_SV2112State_s from one invocation to the next. Should the programmer choose to maintain a copy of the camera's current parameters, much of the following function could be simplified.

int set2112ExposureAndGain(int unitmap, double exposure, double redgain, double grngain, double blugain)
{
    extern xclibs_s     xclib;          /* library instance, assumed opened */
    PXCam_SV2112State_s camstate;
    int r;

memset(&camstate, 0, siz(camstate)); camstate.ddch.len = siz(camstate)); camstate.ddch.mos = PXMOS_CAMSV2112STATE; // // Must get camera clock frequency from video state! // Or the camera's downloaded exposure and other values // won't be computed properly! // { xclib_DeclareVidStateStructs(vidstate); xclib_InitVidStateStructs(vidstate); xclib.pxlib.getState(&xclib.pxlib, 0, PXMODE_DIGI, &vidstate); r = PXCam_SILICONVIDEO2112(PXCam_MapVideoStateToCameraState, 0, 0, 0, NULL, &camstate, NULL, &vidstate); if (r < 0) return(r); } // // Get camera's current state. // r = PXCam_SILICONVIDEO2112(PXCam_DownloadCameraStateViaHandle, 0, unitmap, PXCam_PortIspxdevservice, &xclib.pxdev, &camstate, NULL, NULL); if (r < 0) return(r); // // Modify the portions corresponding to gain and exposure. // camstate.gain[0] = redgain; camstate.gain[1] = grngain; camstate.gain[2] = blugain; camstate.exposure = exposure; // // In case the caller had supplied invalid parameters, correct. // r = PXCam_SILICONVIDEO2112(PXCam_SetCorrectValuesInCameraState, 0, 0, 0, NULL, &camstate, NULL, NULL); if (r < 0) return(r); // // Upload state to camera. // The frame grabber's video state isn't affected by changes // to exposure and gain, and need not be reflected back. // r = PXCam_SILICONVIDEO2112(PXCam_UploadCameraStateViaHandle, 0, unitmap, PXCam_PortIspxdevservice, &xclib.pxdev, &camstate, NULL, NULL); return(r); }
The following example adjusts the camera's area of interest. Unlike the example above, the change of the camera area of interest must also be reflected to the frame grabber.
int set2112AOI(int unitmap, int ulx, int uly, int width, int height)
{
    extern xclibs_s     xclib;            /* library instance, assumed opened */
    PXCam_SV2112State_s camstate;
    int r;
    xclib_DeclareVidStateStructs(vidstate);
    xclib_InitVidStateStructs(vidstate);

memset(&camstate, 0, siz(camstate)); camstate.ddch.len = siz(camstate)); camstate.ddch.mos = PXMOS_CAMSV2112STATE; // // Must get camera clock frequency from video state! // Or the camera's downloaded exposure and other values // won't be computed properly! // xclib.pxlib.getState(&xclib.pxlib, 0, PXMODE_DIGI, &vidstate); r = PXCam_SILICONVIDEO2112(PXCam_MapVideoStateToCameraState, 0, 0, 0, NULL, &camstate, NULL, &vidstate); if (r < 0) return(r); // // Get camera's current state. // r = PXCam_SILICONVIDEO2112(PXCam_DownloadCameraStateViaHandle, 0, unitmap, PXCam_PortIspxdevservice, &xclib.pxdev, &camstate, NULL, NULL); if (r < 0) return(r); // // Modify the portions corresponding to area of interest. // camstate.aoiLeft = ulx; camstate.aoiTop = uly; camstate.aoiWidth = width; camstate.aoiHeight = height; // // In case the caller had supplied invalid parameters, correct. // r = PXCam_SILICONVIDEO2112(PXCam_SetCorrectValuesInCameraState, 0, 0, 0, NULL, &camstate, NULL, NULL); if (r < 0) return(r); // // Video capture should have been turned off before // calling this service. Make sure, but don't wait for // end-of-frame termination. // r = xclib.xcdev.setAbortLive(&xclib.xcdev, unitmap, 0, PXMODE_DIGI, NULL, NULL); if (r < 0) return(r); // // Upload state to camera. // The frame grabber's video state isn't affected by changes // to exposure and gain, and need not be reflected back. // r = PXCam_SILICONVIDEO2112(PXCam_UploadCameraStateViaHandle, 0, unitmap, PXCam_PortIspxdevservice, &xclib.pxdev, &camstate, NULL, NULL); if (r < 0) return(r); // // Reflect AOI into video state. // r = PXCam_SILICONVIDEO2112(PXCam_MapCameraStateToVideoState, 0, unitmap, 0, NULL, &camstate, NULL, &vidstate); if (r < 0) return(r); // // Load video state into frame grabber. // r = xclib.pxlib.defineState(&xclib.pxlib, 0, PXMODE_DIGI, &vidstate) if (r < 0) return(r); r = xclib.xcdev.setVideoConfig(&xclib.xcdev, unitmap, 0, PXMODE_DIGI, NULL, NULL); if (r < 0) return(r); return(0); }

Camera Control: SILICON VIDEO® 1310 --- PXCam_SILICONVIDEO1310



Summary
int PXCam_SILICONVIDEO1310(cmnd, rsvd, unitmap, porttype, port, camstatep, camstate2p, vidstatep);
int                 cmnd;           // A PXCam_ command verb
int                 rsvd;           // Reserved, should be 0
int                 unitmap;        // Unit selection bit map (1 for single unit)
int                 porttype;       // A PXCam_ port selection verb
void                *port;          // Point to port instance, dependent on porttype
PXCam_SV1310State_s *camstatep;     // Pointer to SILICON VIDEO parameters
PXCam_SV1310State_s *camstate2p;    // Pointer to SILICON VIDEO parameters
struct pxvidstate   *vidstatep;     // Pointer to video state

struct PXCam_SV1310State { struct pxddch ddch;
int id; // sensor id, as reported by camera int negADCRef; // mV int posADCRef; // mV int power; // 1 or 0 int videoMode; // 'c': free-run, 's': controlled int subsampleMode; // 0: default: 'm': mono, 'b': bayer int subsample; // encoded as 0xHHVV // 0x101: none 0x102: 0x208: 0x802: // 0x202: 2x2 0x104: 0x401: 0x804: // 0x404: 4x4 0x108: 0x402: // 0x808: 8x8 0x201: 0x408: // etc. 0x204: 0x801: int aoiLeft; // AOI. these values are .. int aoiTop; // .. always relative to .. int aoiWidth; // .. full resolution and .. int aoiHeight; // .. independent of subsample int readoutDirection; // CC('L', 'T'): L-R/T-B // CC('R', 'T'): R-L/T-B // CC('L', 'B'): L-R/B-T // CC('R', 'B'): R-L/B-T int offsetCorrection[64+1]; // mV * 10 int frameWidth; // extended columns to increase frame period int frameHeight; // extended rows to increase frame period int expGainMode; // 0: raw, 1: lin1, 2: lin2 int clrGainMode; // 0: raw, 1: lin1 int analogOffset; // mV double colorGain[4]; // gain for Bayer mosaic, Gr, R, B, Gb double gain; // common gain double exposure; // msec double framePeriod; // msec int aoiFramePeriodMin; // rsvd // 0: off int strobeMode; // 0: disabled // '1': One Line // 'e': exposure int shA; // internal use int shB; // internal use int sofDelay; // internal use int frameClampHeight; // internal use int frameClampTop; // internal use int frameClamp; // 1: auto frame clamp on, 0: off
double pixelClkFreq; // in MHz. Info only which must // be supplied
struct { // controlled mode: int mode; // 's', 'c' double framerate; // rate in 'c' mode, Hz. // min. retrigger period // in 's' mode (1/Hz). double maxframerate; // internal use int trigger; // 'n', '+', '-', 'b' int strobe; // 'n', 'p' int bits; // 8, 10 ... // internal use } adj; }; typedef struct PXCam_SV1310State PXCam_SV1310State_s;



Description

The PXCam_SILICONVIDEO1310 allows controlling the various options of the SILICON VIDEO® 1310 and SILICON VIDEO® 1310C cameras, by downloading and uploading camera parameters. It also allows mapping video state parameters into the camera parameters, or vice versa, so that the PIXCI® state can be consistent with that of the camera.

If cmnd=PXCam_SetDefaultValuesInCameraState, the camera state referenced by camstatep is initialized with camera default parameters. Other function arguments are not used.

If cmnd=PXCam_SetCorrectValuesInCameraState, the camera state referenced by camstatep is corrected so that the parameters are valid and consistent. Other function arguments are not used.

If cmnd=PXCam_MapCameraStateToVideoState, the camera state referenced by camstatep is used to modify the video state referenced by vidstatep so as to be consistent. This does not, by itself, implement the modified video state. Other function arguments are not used.

If cmnd=PXCam_MapVideoStateToCameraState, the video state referenced by vidstatep is used to modify the camera state referenced by camstatep so as to be consistent. This does not, by itself, implement the modified camera state. Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateViaHandle, the camera state referenced by camstatep is uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateDeltaViaHandle those portions of the camera state referenced by camstatep which is different than the corresponding portions of the camera state referenced camstate2p are uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_DownloadCameraStateViaHandle, the camera state referenced by camstatep is downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_DownloadCameraIDStateViaHandle, the ID portions of the camera state referenced by camstatep are downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_InitCameraStateViaHandle, the camera is (re)initialized with standard defaults. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_SetMinimumValuesInCameraState or cmnd=PXCam_SetMaximumValuesInCameraState the camera state referenced by camstate2p is filled with minimal or maximal allowed values, respectively, relative to the current camera state referenced by camstatep. Only the colorGain, aoiWidth, and aoiHeight members of the camera state referenced by camstate2p are currently set. Other function arguments are not used.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Camera Control: SILICON VIDEO® 1281 --- PXCam_SILICONVIDEO1281



Summary
int PXCam_SILICONVIDEO1281(cmnd, rsvd, unitmap, porttype, port, camstatep, camstate2p, vidstatep);
int                 cmnd;           // A PXCam_ command verb
int                 rsvd;           // Reserved, should be 0
int                 unitmap;        // Unit selection bit map (1 for single unit)
int                 porttype;       // A PXCam_ port selection verb
void                *port;          // Point to port instance, dependent on porttype
PXCam_SV1281State_s *camstatep;     // Pointer to SILICON VIDEO parameters
PXCam_SV1281State_s *camstate2p;    // Pointer to SILICON VIDEO parameters
struct pxvidstate   *vidstatep;     // Pointer to video state

struct PXCam_SV1281State { struct pxddch ddch;
int productID1; // as reported int productID2; // as reported int productID3; // as reported int blacklevel; // black level, 0 thru 62 int sleep; // sleep mode. 0: off, 1: on int videomode; // CC('v','i'): video mode // CC('s','x'): controlled mode int aoiLeft; // capture AOI int aoiTop; // .. int aoiWidth; // .. int aoiHeight; // .. int extendHBlank; // lengthen H blanking int extendVBlank; // lengthen V blanking // (no effect on current chips) double gain; // dB. log(1.5) thru log(39.375) double exposure; // msec double frameperiod; // rsvd double pixelClkFreq; // in MHz. Info only which must be supplied
// // Chip tweaks which are almost never changed. // int bandgap; // 0: internal, 1: external. reference int clkSchmitt; // Schmitt trigger. 0: off, 1: on int autoblack; // 0: internal, 1: external reference int _1stcolamp_rst_cnt; // internal use int _pre_int_rst_cnt; // internal use int _ds_rst_cnt; // internal use int _row_sel_wait_cnt; // internal use int _feed_thru_cnt; // internal use int rsvd[8]; // internal use
struct { // controlled mode: int mode; // 's', 'c' int trigger; // 'n', '+', '-', 'b' double framerate; // rate in 'c' mode, Hz. // min. retrigger period // in 's' mode (1/Hz). double exposure; // msec. not used ... // internal use } adj; }; typedef struct PXCam_SV1281State PXCam_SV1281State_s;



Description

The PXCam_SILICONVIDEO1281 allows controlling the various options of the SILICON VIDEO® 1281M and SILICON VIDEO® 1281C cameras, by downloading and uploading camera parameters. It also allows mapping video state parameters into the camera parameters, or vice versa, so that the PIXCI® state can be consistent with that of the camera.

If cmnd=PXCam_SetDefaultValuesInCameraState, the camera state referenced by camstatep is initialized with camera default parameters. Other function arguments are not used.

If cmnd=PXCam_SetCorrectValuesInCameraState, the camera state referenced by camstatep is corrected so that the parameters are valid and consistent. Other function arguments are not used.

If cmnd=PXCam_MapCameraStateToVideoState, the camera state referenced by camstatep is used to modify the video state referenced by vidstatep so as to be consistent. This does not, by itself, implement the modified video state. Other function arguments are not used.

If cmnd=PXCam_MapVideoStateToCameraState, the video state referenced by vidstatep is used to modify the camera state referenced by camstatep so as to be consistent. This does not, by itself, implement the modified camera state. Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateViaHandle, the camera state referenced by camstatep is uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateDeltaViaHandle those portions of the camera state referenced by camstatep which is different than the corresponding portions of the camera state referenced camstate2p are uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_DownloadCameraStateViaHandle, the camera state referenced by camstatep is downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_DownloadCameraIDStateViaHandle, the ID portions of the camera state referenced by camstatep are downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_InitCameraStateViaHandle, the camera is (re)initialized with standard defaults. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_SetMinimumValuesInCameraState or cmnd=PXCam_SetMaximumValuesInCameraState the camera state referenced by camstate2p is filled with minimal or maximal allowed values, respectively, relative to the current camera state referenced by camstatep. Only the gain, blacklevel, aoiWidth, and aoiHeight members of the camera state referenced by camstate2p are currently set. Other function arguments are not used.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Camera Control: SILICON VIDEO® 9M001 --- PXCam_SILICONVIDEO9M001
Camera Control: SILICON VIDEO® 9T001 --- PXCam_SILICONVIDEO9M001
Camera Control: SILICON VIDEO® 5M10/5C10 --- PXCam_SILICONVIDEO9M001
Camera Control: SILICON VIDEO® 9C10 --- PXCam_SILICONVIDEO9M001
Camera Control: SILICON VIDEO® 10C6/10M6 --- PXCam_SILICONVIDEO9M001
Camera Control: SILICON VIDEO® 10C-CL/10M-CL --- PXCam_SILICONVIDEO9M001



Summary
int PXCam_SILICONVIDEO9M001(cmnd, rsvd, unitmap, porttype, port, camstatep, camstate2p, vidstatep);
int                 cmnd;           // A PXCam_ command verb
int                 rsvd;           // Reserved, should be 0
int                 unitmap;        // Unit selection bit map (1 for single unit)
int                 porttype;       // A PXCam_ port selection verb
void                *port;          // Point to port instance, dependent on porttype
PXCam_SV9M001State_s *camstatep;    // Pointer to SILICON VIDEO parameters
PXCam_SV9M001State_s *camstate2p;   // Pointer to SILICON VIDEO parameters
struct pxvidstate   *vidstatep;     // Pointer to video state

struct PXCam_SV9M001State { struct pxddch ddch;
int ID; // sensor id, as reported by camera int aoiLeft; // capture AOI int aoiTop; // .. int aoiWidth; // .. int aoiHeight; // .. int subsample; // encoded as 0xHHVV // 0x0101: none 0x0204: 2x4 // 0x0202: 2x2 0x0208: 2x8 // 0x0404: 4x4 0x0401: 4x1 // 0x0808: 8x8 0x0402: 4x2 // 0x0102: 1x2 0x0408: 4x8 // 0x0104: 1x4 0x0801: 8x1 // 0x0108: 1x8 0x0802: 8x2 // 0x0201: 2x1 0x0804: 8x4 // 0x0110: 1x16 0x0210: 2x16 // 0x0120: 1x32 0x0220: 2x32 // 0x0410: 4x16 // 0x0420: 4x32 // SV9M001/SV9T001: no x__10, x__20 // SV5x10: no x08__, x__10, x__20 // SV9C10: no x08__ // SV10x6/SV10x-CL: no x08__ int subbinning; // Bit 0=0: subsample is subsampling // Bit 0=1: subsample is binning // SV9T001/SV5x10/SV10x6/SV10x-CL only // Bit 1=0: binning is averaging // Bit 1=1: binning is summing // SV5x10 only int scanDirection; // CC('R','T'): L-R/T-B // CC('R','B'): L-R/B-T // SV9M001/SV5x10/SV9C10/SV10x6/SV10x-CL only // CC('L','T'): R-L/T-B // CC('L','B'): R-L/B-T // SV5x10/SV9C10/SV10x6/SV10x-CL only int testdata; // 0: off, 1: on // SV9M001/SV9T001 // 0: off, 1 thru 9: on-various // SV5x10 // 0: off, 1-4, 256-258: on-various // SV9x10 // 0: off, 1-4, 256-257: on-various // SV10x6/SV10x-CL int chipenable; // 1: on, 0: off // SV9M001/SV9T001 only int videoMode; // 'c': free-run, 's': controlled // SV5x10: 'g'^'s': controlled global // SV9T001:'r'^'s': controlled global // SV9C10: 'g'^'s': controlledglobal // SV9C10/SV10x6/SV10x-CL: no 's' int hBlank; // lengthen H blanking - set via framePeriod // SV9C10/SV10x6/SV10x-CL: actual line length int vBlank; // lengthen V blanking - set via framePeriod // SV9C10/SV10x6/SV10x-CL: actual frame length int blackLevelMode; // 'n': auto/ADC, 'c': auto (SV9M001 only) // 'm': manual, 'd': disabled (SV9M001 only) int strobeMode; // 0 : disabled // 'e': exposure // '1': one line // SV9M001/SV9T001 only // 0 : disabled // 'e': enabled // 'i': inverted // SV5x10 only // 'p': programmed // SV9C10/SV10x6/SV10x-CL only int microExposure; // 1: allow short exposure less than 1 line, // 0: don't // SV9M001 only int macroExposure; // 1: allow long exposure // 0: don't // SV9T001/SV5x10/SV9C10/SV10x6/SV10x-CL only int blackrgb[4]; // rsvd. 0 int blacklevel; // black level // SV9T001 only int strobeStart; // 0/1/2/3: select start timing // SV5x10 only int strobeEnd; // 0/1/2/3: select strobe duration // SV5x10 only ... // internal use double gainrgb[4]; // Gb/B/R/Gr dB double exposure; // exposure period, msec double shutterDelay; // rsvd. 0 double framePeriod; // frame period, msec double pixelClkFreq; // in MHz. Info only which must be supplied double digitalgain; // SV9M001: not used // SV9T001: deprecated, dB // SV5x10: not used // SV9C10: used // SV10x6/SV10x-CL: used double strobePeriod; // strobe period, msec // SV9C10/SV10x6/SV10x-CL only ... // internal use
struct { // controlled mode: int mode; // 's', 'c' int trigger; // 'n', '+', '-', 'b' double framerate; // rate in 'c' mode, Hz. // min. retrigger period // in 's' mode (1/Hz). double exposure; // msec. not used int bits; // 8, 10 (SV9M001/SV9T001) // 8, 12 (SV5x10/SV9C10/SV10x6/SV10x-CL) int bitpack; // 0: off, 1: on w. bits!=8 // only w. PIXCI(R) SI1, SI2, SI4 int strobepolarity: 1; // 0: normal, 1: invert strobe // SV5x10/SV9C10/SV10x6/SV10x-CL: not needed int smaoutSI4; // sma trig output connector is // sma trig in or camera N expose // PIXCI SI4 only ... // internal use } adj; }; typedef struct PXCam_SV9M001State PXCam_SV9M001State_s;



Description

The PXCam_SILICONVIDEO9M001 allows controlling the various options of the SILICON VIDEO® 9M001, SILICON VIDEO® 9M001C, SILICON VIDEO® 9T001C, SILICON VIDEO® 5C10, SILICON VIDEO® 5M10, SILICON VIDEO® 9C10, SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 10C-CL, and SILICON VIDEO® 10M-CL, cameras, by downloading and uploading camera parameters. It also allows mapping video state parameters into the camera parameters, or vice versa, so that the PIXCI® state can be consistent with that of the camera.

If cmnd=PXCam_DownloadCameraIDStateViaHandle, the ID portions of the camera state referenced by camstatep are downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used. Because PXCam_SILICONVIDEO9M001 is intended to operate several similar, but different, cameras, the cmnd=PXCam_DownloadCameraIDStateViaHandle must be used to obtain the camera ID so that other commands, below, can adapt properly.

If cmnd=PXCam_SetDefaultValuesInCameraState, the camera state referenced by camstatep is initialized with camera default parameters. Other function arguments are not used.

If cmnd=PXCam_SetCorrectValuesInCameraState, the camera state referenced by camstatep is corrected so that the parameters are valid and consistent. Other function arguments are not used.

If cmnd=PXCam_MapCameraStateToVideoState, the camera state referenced by camstatep is used to modify the video state referenced by vidstatep so as to be consistent. This does not, by itself, implement the modified video state. Other function arguments are not used.

If cmnd=PXCam_MapVideoStateToCameraState, the video state referenced by vidstatep is used to modify the camera state referenced by camstatep so as to be consistent. This does not, by itself, implement the modified camera state. Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateViaHandle, the camera state referenced by camstatep is uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateDeltaViaHandle those portions of the camera state referenced by camstatep which is different than the corresponding portions of the camera state referenced camstate2p are uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_DownloadCameraStateViaHandle, the camera state referenced by camstatep is downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_InitCameraStateViaHandle, the camera is (re)initialized with standard defaults. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_SetMinimumValuesInCameraState or cmnd=PXCam_SetMaximumValuesInCameraState the camera state referenced by camstate2p is filled with minimal or maximal allowed values, respectively, relative to the current camera state referenced by camstatep. Only the gainrgb[], aoiWidth, aoiHeight, and exposure, and digitalgain members of the camera state referenced by camstate2p are currently set. Other function arguments are not used.

For SILICON VIDEO® 9T001C cameras, use of the digitalgain member is deprecated; the former, separate digital gain has been integrated into the gainrgb[].


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Camera Control: SILICON VIDEO® 642 --- PXCam_SILICONVIDEO642



Summary
int PXCam_SILICONVIDEO642(cmnd, rsvd, unitmap, porttype, port, camstatep, camstate2p, vidstatep);
int                 cmnd;           // A PXCam_ command verb
int                 rsvd;           // Reserved, should be 0
int                 unitmap;        // Unit selection bit map (1 for single unit)
int                 porttype;       // A PXCam_ port selection verb
void                *port;          // Point to port instance, dependent on porttype
PXCam_SV642State_s  *camstatep;     // Pointer to SILICON VIDEO parameters
PXCam_SV642State_s  *camstate2p;    // Pointer to SILICON VIDEO parameters
struct pxvidstate   *vidstatep;     // Pointer to video state

struct PXCam_SV642State { struct pxddch ddch;
int aoiLeft; // capture AOI int aoiTop; // .. int aoiWidth; // .. int aoiHeight; // .. int hBlank; // lengthen H blanking - set via framePeriod int vBlank; // lengthen V blanking - set via framePeriod int gainrange; // 10: high range, 5: low range int videoMode; // CCC('m','c','i'): free-run // CCC('s','s','e'): controlled // CCC('m','c','e'): master/Cont/Seq // CCC('s','c','e'): slave/Cont/Seq int interlaceMode; // 0: progressive // 1: interlaced // 2: one field int macroExposure; // 1: allow long exposure // 0: don't
int VLNAMP; // voltage references and internal int VLNOUT; // default versus explicit selection int VLN1; // .. int VLN2; // .. int VLN2BOOST; // .. int VLP; // .. int VREF; // .. int VOFF; // .. int VREF1; // .. int VREF2; // .. int vref; // .. int vref2; // .. int vref1; // .. int voff; // .. int rsvd1[8];
double exposure; // exposure period, msec double framePeriod; // frame period, msec double gainrgb[4]; // Gb/B/R/Gr dB double pixelClkFreq; // in MHz. Info only which must // be supplied ... // internal use
struct { // controlled mode: int mode; // 's', 'c' int trigger; // 'n', '+', '-', 'b' int bits; // 8, 10 ... // internal use double framerate; // rate in 'c' mode, Hz. // min. retrigger period // in 's' mode (1/Hz). double exposure; // msec. not used double maxframerate; ... // internal use } adj;
}; typedef struct PXCam_SV642State PXCam_SV642State_s;



Description

The PXCam_SILICONVIDEO642 allows controlling the various options of the SILICON VIDEO® 642M and SILICON VIDEO® 642C cameras, by downloading and uploading camera parameters. It also allows mapping video state parameters into the camera parameters, or vice versa, so that the PIXCI® state can be consistent with that of the camera.

If cmnd=PXCam_DownloadCameraIDStateViaHandle, the ID portions of the camera state referenced by camstatep are downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_SetDefaultValuesInCameraState, the camera state referenced by camstatep is initialized with camera default parameters. Other function arguments are not used.

If cmnd=PXCam_SetCorrectValuesInCameraState, the camera state referenced by camstatep is corrected so that the parameters are valid and consistent. Other function arguments are not used.

If cmnd=PXCam_MapCameraStateToVideoState, the camera state referenced by camstatep is used to modify the video state referenced by vidstatep so as to be consistent. This does not, by itself, implement the modified video state. Other function arguments are not used.

If cmnd=PXCam_MapVideoStateToCameraState, the video state referenced by vidstatep is used to modify the camera state referenced by camstatep so as to be consistent. This does not, by itself, implement the modified camera state. Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateViaHandle, the camera state referenced by camstatep is uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateDeltaViaHandle those portions of the camera state referenced by camstatep which is different than the corresponding portions of the camera state referenced camstate2p are uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_DownloadCameraStateViaHandle, the camera state referenced by camstatep is downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_InitCameraStateViaHandle, the camera is (re)initialized with standard defaults. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_SetMinimumValuesInCameraState or cmnd=PXCam_SetMaximumValuesInCameraState the camera state referenced by camstate2p is filled with minimal or maximal allowed values, respectively, relative to the current camera state referenced by camstatep. Only the gainrgb[], aoiWidth, and aoiHeight members of the camera state referenced by camstate2p are currently set. Other function arguments are not used.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Camera Control: SILICON VIDEO® 643 --- PXCam_SILICONVIDEO643



Summary
int PXCam_SILICONVIDEO643(cmnd, rsvd, unitmap, porttype, port, camstatep, camstate2p, vidstatep);
int                 cmnd;           // A PXCam_ command verb
int                 rsvd;           // Reserved, should be 0
int                 unitmap;        // Unit selection bit map (1 for single unit)
int                 porttype;       // A PXCam_ port selection verb
void                *port;          // Point to port instance, dependent on porttype
PXCam_SV643State_s  *camstatep;     // Pointer to SILICON VIDEO parameters
PXCam_SV643State_s  *camstate2p;    // Pointer to SILICON VIDEO parameters
struct pxvidstate   *vidstatep;     // Pointer to video state

struct PXCam_SV643State { struct pxddch ddch;
int aoiLeft; // capture AOI int aoiTop; // .. int aoiWidth; // .. int aoiHeight; // .. int scanDirection; // CC('R', 'B'): L-R/T-B // CC('R', 'T'): L-R/B-T int subsample; // 0x0101: none // 0x0102: none int videoMode; // 'c': free-run // 's': controlled int pixelClkGran; // internal use int frameTransfer; // internal use int macroExposure; // 1: allow long exposure // 0: don't int expmode; // 1: normal // 2: dual slope // 3: triple slope ... // internal use
double pixelClkFreq; // in MHz. Info only which must // be supplied double gain; // dB. 20*log10( 1.00) // thru 20*log10(15.38) double framePeriod; // frame period, msec double exposure; // free-run exposure period, msec double Vcal; // A-D voltage. See Cypress data sheet double Vblack; // A-D voltage. See Cypress data sheet double Voffset; // A-D voltage. See Cypress data sheet double exposure2; // dual slope exposure/reset double exposure3; // triple slope exposure/reset ... // internal use
struct { // controlled mode: int mode; // 's', 'c' int trigger; // 'n', '+', '-', 'b' int bits; // 8, 10 int strobepolarity; // 'p', 'n' int bitpack; // 0: off, 1: on w. bits!=8 // only w. PIXCI(R) SI1, SI2, SI4 // only w. PIXCI(R) EB1-PoCL (for SV10x-CL) ... double framerate; // rate in 'c' mode, Hz. // min. retrigger period // in 's' mode (1/Hz). double exposure; // controlled exposure, msec ... // internal use } adj; }; typedef struct PXCam_SV643State PXCam_SV643State_s;



Description

The PXCam_SILICONVIDEO643 allows controlling the various options of the SILICON VIDEO® 643M and SILICON VIDEO® 643C cameras, by downloading and uploading camera parameters. It also allows mapping video state parameters into the camera parameters, or vice versa, so that the PIXCI® state can be consistent with that of the camera.

If cmnd=PXCam_SetDefaultValuesInCameraState, the camera state referenced by camstatep is initialized with camera default parameters. Other function arguments are not used.

If cmnd=PXCam_SetCorrectValuesInCameraState, the camera state referenced by camstatep is corrected so that the parameters are valid and consistent. Other function arguments are not used.

If cmnd=PXCam_MapCameraStateToVideoState, the camera state referenced by camstatep is used to modify the video state referenced by vidstatep so as to be consistent. This does not, by itself, implement the modified video state. Other function arguments are not used.

If cmnd=PXCam_MapVideoStateToCameraState, the video state referenced by vidstatep is used to modify the camera state referenced by camstatep so as to be consistent. This does not, by itself, implement the modified camera state. Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateViaHandle, the camera state referenced by camstatep is uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateDeltaViaHandle those portions of the camera state referenced by camstatep which is different than the corresponding portions of the camera state referenced camstate2p are uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_InitCameraStateViaHandle, the camera is (re)initialized with standard defaults. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_SetMinimumValuesInCameraState or cmnd=PXCam_SetMaximumValuesInCameraState the camera state referenced by camstate2p is filled with minimal or maximal allowed values, respectively, relative to the current camera state referenced by camstatep. Only the gain, aoiWidth, and aoiHeight members of the camera state referenced by camstate2p are currently set. Other function arguments are not used.

If cmnd=PXCam_MapVideoStateSerialToCameraState the SPI commands within the video state referenced by vidstatep is used to modify the camera state referenced by camstatep so as to be consistent. Other function arguments are not used.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Camera Control: SILICON VIDEO® WGA --- PXCam_SILICONVIDEO032



Summary
int PXCam_SILICONVIDEO032(cmnd, rsvd, unitmap, porttype, port, camstatep, camstate2p, vidstatep);
int                 cmnd;           // A PXCam_ command verb
int                 rsvd;           // Reserved, should be 0
int                 unitmap;        // Unit selection bit map (1 for single unit)
int                 porttype;       // A PXCam_ port selection verb
void                *port;          // Point to port instance, dependent on porttype
PXCam_SV032State_s  *camstatep;     // Pointer to SILICON VIDEO parameters
PXCam_SV032State_s  *camstate2p;    // Pointer to SILICON VIDEO parameters
struct pxvidstate   *vidstatep;     // Pointer to video state

struct PXCam_SV032State { struct pxddch ddch;
int id; // chip ID as reported int aoiLeft; // capture AOI int aoiTop; // .. int aoiWidth; // .. int aoiHeight; // .. int scanDirection; // CC('R', 'T'): L-R/T-B // CC('R', 'B'): L-R/B-T // CC('L', 'T'): R-L/T-B // CC('L', 'B'): R-L/B-T int subsample; // encoded as 0xHHVV // 0x0101: none // 0x0102: 1x2 // 0x0104: 1x4 int videoMode; // 'c': free-run // 's': controlled int hBlank; // lengthen H blanking int vBlank; // lengthen V blanking int adcMode; // 10: linear, 12: companded int adcModeColor; // 0: neutral, 1: warmer int testPattern; // 0: off, 1-3: various int agc; // 0: off, 1: auto gain on int aec; // 0: off, 1: auto exposure on int strobeMode; // 0: disabled, 'e': enabled, // 'i': inverted int readoutMode; // 'i': overlaps exposure // 'e': follows exposure (not fully // supported) int exposureMode; // 'l': linear // 'x': high dynamic range (HDR) int macroExposure; // 1: allow long exposure // 0: don't int aecMaxmax; int agcUpdates; // 1-16: agc update period int aecUpdates; // 1-16: aec update period int aegcTarget; // 16-1008: agc/aec image target value int aecLpf; // 0-2: aec low pass filtering int agcLpf; // 0-2: agc low pass filtering int aegcCount; // 0-65535: pixels analyzed for aec/agc int hdrMode; // 'a': auto HDR, 'm': manual HDR int hdrKnee; // 1-2: # of HDR knees int ecl; // 0: off, 1: anti-eclipse on ...
double gain; // in dB. double exposure; // in milliseconds double framePeriod; // frame period, msec double agcMax; // max gain set by AGC, in dB. double aecMax; // max exposure set by AEC, in msec. double digitalGain; // in dB. double vref; // ADC Ref., V. double v1; // ADC V1, V. double v2; // ADC V2, V. double v3; // ADC V3, V. double v4; // ADC V4, V. double hdrT2; // HDR T2 & T3 ratio .. double hdrT3; // .. pow(.5, 15) - pow(.5, 0) double hdrExp1; // HDR T1 exposure, msec. double hdrExp2; // HDR T1 exposure, msec. double eclRef; // anti-eclipse reference, V. ...
struct { int isColor; // 0: sensor is mono, 1: is color // Info only which must be supplied double pixelClkFreq; // in MHz. Info only which must // be supplied } adi;
struct { // controlled mode: int mode; // 's', 'c' int trigger; // 'n', '+', '-', 'b'
int bits; // 8, 10 int bitpack; // 0: off, 1: on w. bits!=8 // only w. PIXCI(R) SI1,SI2,SI4 int strobePolarity; // not used ...
double frameRate; // rate in 'c' mode, Hz. // min. retrigger period // in 's' mode (1/Hz). double exposure; // msec. not used double maxFrameRate; // internal use double resetDelay; // internal use ... } adj; }; typedef struct PXCam_SV032State PXCam_SV032State_s;



Description

The PXCam_SILICONVIDEO032 allows controlling the various options of the SILICON VIDEO® WGA-M and SILICON VIDEO® WGA-C cameras, by downloading and uploading camera parameters. It also allows mapping video state parameters into the camera parameters, or vice versa, so that the PIXCI® state can be consistent with that of the camera.

If cmnd=PXCam_DownloadCameraIDStateViaHandle, the ID portions of the camera state referenced by camstatep are downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_SetDefaultValuesInCameraState, the camera state referenced by camstatep is initialized with camera default parameters. Other function arguments are not used.

If cmnd=PXCam_SetCorrectValuesInCameraState, the camera state referenced by camstatep is corrected so that the parameters are valid and consistent. Other function arguments are not used.

If cmnd=PXCam_MapCameraStateToVideoState, the camera state referenced by camstatep is used to modify the video state referenced by vidstatep so as to be consistent. This does not, by itself, implement the modified video state. Other function arguments are not used.

If cmnd=PXCam_MapVideoStateToCameraState, the video state referenced by vidstatep is used to modify the camera state referenced by camstatep so as to be consistent. This does not, by itself, implement the modified camera state. Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateViaHandle, the camera state referenced by camstatep is uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateDeltaViaHandle those portions of the camera state referenced by camstatep which is different than the corresponding portions of the camera state referenced camstate2p are uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_DownloadCameraStateViaHandle, the camera state referenced by camstatep is downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_InitCameraStateViaHandle, the camera is (re)initialized with standard defaults. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_SetMinimumValuesInCameraState or cmnd=PXCam_SetMaximumValuesInCameraState the camera state referenced by camstate2p is filled with minimal or maximal allowed values, respectively, relative to the current camera state referenced by camstatep. Only the gainrgb[], aoiWidth, and aoiHeight members of the camera state referenced by camstate2p are currently set. Other function arguments are not used.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

Camera Control: SILICON VIDEO® HAS21 --- PXCam_SILICONVIDEOHAS2



Summary
int PXCam_SILICONVIDEOHAS2(cmnd, rsvd, unitmap, porttype, port, camstatep, camstate2p, vidstatep);
int                 cmnd;           // A PXCam_ command verb
int                 rsvd;           // Reserved, should be 0
int                 unitmap;        // Unit selection bit map (1 for single unit)
int                 porttype;       // A PXCam_ port selection verb
void                *port;          // Point to port instance, dependent on porttype
PXCam_SVHAS2State_s *camstatep;     // Pointer to SILICON VIDEO parameters
PXCam_SVHAS2State_s *camstate2p;    // Pointer to SILICON VIDEO parameters
struct pxvidstate   *vidstatep;     // Pointer to video state

struct PXCam_SVHAS2State { struct pxddch ddch;
int id; // sensor ID as reported int aoiLeft; // capture AOI int aoiTop; // .. int aoiWidth; // .. int aoiHeight; // ..
int videoMode; // 'c': Free-run Max Rate // 'C': Free-run Pgm Rate // 's': Ext. Triggered int black; // not used int readout; // 'n': CDS/NDR Non-Destructive Readout // 'd': DS/DR Destructive Readout int aps; // 1: Active, 0: Standby ... double pgaOffset; // PGA Offset, 0.3 to 1.3 V. double pgaGain; // PGA Gain, 0.0 to 18.1 dB. double framePeriod; // frame period, msec double exposure; // in milliseconds double ndrBlack; // NDR mode black level, 0.4 to 2.9 V. double ndrOffset; // NDR mode even/odd offset, -17.5 to 17.5 mV. ....
struct { double pixelClkFreq; // in MHz. Info only which must // be supplied } adi;
struct { // controlled mode: int mode; // 's', 'c' int trigger; // 'n', '+', '-', 'b'
int bits; // 8, 12 int bitpack; // 0: off, 1: on w. bits!=8 // only w. PIXCI(R) SI1,SI2,SI4 int strobePolarity; // not used ...
double frameRate; // rate in 'c' mode, Hz. // min. retrigger period // in 's' mode (1/Hz). double exposure; // msec. not used double maxFrameRate; // internal use double resetDelay; // internal use ... } adj; }; typedef struct PXCam_SVHAS2State PXCam_SVHAS2State_s;



Description

The PXCam_SILICONVIDEOHAS2 allows controlling the various options of the SILICON VIDEO® HAS21 camera, by downloading and uploading camera parameters. It also allows mapping video state parameters into the camera parameters, or vice versa, so that the PIXCI® state can be consistent with that of the camera.

If cmnd=PXCam_DownloadCameraIDStateViaHandle, the ID portions of the camera state referenced by camstatep are downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_SetDefaultValuesInCameraState, the camera state referenced by camstatep is initialized with camera default parameters. Other function arguments are not used.

If cmnd=PXCam_SetCorrectValuesInCameraState, the camera state referenced by camstatep is corrected so that the parameters are valid and consistent. Other function arguments are not used.

If cmnd=PXCam_MapCameraStateToVideoState, the camera state referenced by camstatep is used to modify the video state referenced by vidstatep so as to be consistent. This does not, by itself, implement the modified video state. Other function arguments are not used.

If cmnd=PXCam_MapVideoStateToCameraState, the video state referenced by vidstatep is used to modify the camera state referenced by camstatep so as to be consistent. This does not, by itself, implement the modified camera state. Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateViaHandle, the camera state referenced by camstatep is uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_UploadCameraStateDeltaViaHandle those portions of the camera state referenced by camstatep which is different than the corresponding portions of the camera state referenced camstate2p are uploaded to the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_DownloadCameraStateViaHandle, the camera state referenced by camstatep is downloaded from the camera. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_InitCameraStateViaHandle, the camera is (re)initialized with standard defaults. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.

If cmnd=PXCam_SetMinimumValuesInCameraState or cmnd=PXCam_SetMaximumValuesInCameraState the camera state referenced by camstate2p is filled with minimal or maximal allowed values, respectively, relative to the current camera state referenced by camstatep. Only the exposure, framePeriod, aoiWidth, and aoiHeight members of the camera state referenced by camstate2p are currently set. Other function arguments are not used.


Returns


0
Operation complete.

PXERROR
Invalid parameters.

PXER...
Other error codes as appropriate.

 

 

 

12. Device Independent Image Access Interface

The pximage and pximage3 interfaces support a variety of device independent services to access image buffers. They are device independent in that, in conjunction with the PXIPL Image Processing Library, a pximage or pximage3 can be constructed to provide access to images in program memory buffers, disk files, or other media; using any pixel format, resolution, and bit depth unconstrained by PIXCI® support. All such images described by a pximage or pximage3 can be accessed in the same manner, or processed by PXIPL functions.[36] .' .ds Nm XCLIB


PXIMAGE: Image and Pixel Specifications --- Struct pximage



Summary
typedef int pxcoord_t;      // a coordinate

struct pxy {                // a pair of coordinates
    pxcoord_t   x;
    pxcoord_t   y;
};
typedef struct pxy pxy_s;
typedef struct pxy pxypoint_s;

struct pxywindow {          // a pair of 2-d points
    struct  pxy nw;         // north west corner inclusive
    struct  pxy se;         // south east corner, usually exclusive
};
typedef struct pxywindow pxywindow_s;

struct pxyz {               // a triplet of coordinates
    pxcoord_t   x;
    pxcoord_t   y;
    pxcoord_t   z;
};
typedef struct pxyz pxyz_s;
typedef struct pxyz pxyzpoint_s;

struct pxyzwindow {         // a pair of 3-d points
    struct  pxyz nw;        // north west inner corner inclusive
    struct  pxyz se;        // south east outer corner, usually exclusive
};
typedef struct pxyzwindow pxyzwindow_s;

struct pximagedata {        // pixel and pixie data descriptor
    int     pixietype;      // pixel type: PXDATUCHAR, PXDATUSHORT, PXDATULONG, PXDATFLOAT, etc.
    int     pixies;         // samples/colors/components per pixel: 1, 2, 3, ...
    int     pixelhint;      // hints on pixel interpretation

union { struct { //for (unsigned) integer pixels int bitsused; // significant bits per pixie: 8,12,... int bitsxsb; // PXDATMSB | PXDATLSB: significant bits @ lsb|msb // both: all bits used uint16 dirtyread; // PXDATDIRTY: unused read bits may not be zero // 0: unused read bits are zero uint16 dirtyrite; // PXDATDIRTY: unused written bits needn't be zero? // 0: unused written bits must be zero? uint16 endian; // PXDATENDIAN: has wrong byte endian for current // 0: has correct byte endian for host } i; //for (unsigned) integer pixels
struct { //for real (float) pixels float minvalue; // bottom of range float maxvalue; // top of range } r; //for real (float) pixels } u; }; typedef struct pximagedata pximagedata_s;

struct pximagefacts {       // derived facts and other image status
                            // derived from pixies, pixietype
    int     pixiesize;      // bytes per component value
    int     pixelsize;      // bytes per pixel

// derived from pixies, pixietype: uint pixieuint: 1; // - pixel components are positive ints uint pixiereal: 1; // - pixel components are real
... }; typedef struct pximagefacts pximagefacts_s;

struct pximagehints {
    float   pixelwidth;     // X axis width of 1 pixel. 0 if unknown
    float   pixelheight;    // Y axis height of 1 pixel. 0 if unknown
    float   pixeldepth;     // Z axis depth of 1 pixel. 0 if unknown
    uchar   widthunits;     // PXUNIT* real world units
    uchar   heightunits;    // PXUNIT* real world units
    uchar   depthunits;     // PXUNIT* real world units

... }; typedef struct pximagehints pximagehints_s;

struct pximage {
    struct pxywindow wind;      // size: subwindow within imdim
    pxcoord_t        pad2[2];
    struct pxywindow imdim;     // size: nw.x = nw.y = 0, se.x & se.y is dimension of image
    pxcoord_t        pad1[2];

struct pximagedata d; // type: pixel descriptor struct pximagefacts f; // type: derived & other facts struct pximagehints h; // interpretation hints
... member functions (methods) ... ... private state ... };

struct pximage3 {
    struct pxyzwindow wind;     // size: subwindow within imdim
    struct pxyzwindow imdim;    // size: nw.x = nw.y = 0, se.x & se.y is dimension of image

struct pximagedata d; // type: pixel descriptor struct pximagefacts f; // type: derived & other facts struct pximagehints h; // interpretation hints
... member functions (methods) ... ... private state ... };



Description

A pximage structure, after successful construction by ::pxlib.initPximage, pxd_defineImage, pximage_file, pximage_memory[37], or similar functions, provides several members (fields) with values of interest to the application program(er). The public fields of interest, excepting the member functions (methods), are shown above.

If using a prewritten image processing function on the pximage, only the imdim and wind are typically needed — to set an area of interest to the full dimensions of the image, or a subset thereof.

If writing custom image processing functions, additional members which specify the type, precision, and dimensionality of pixels are typically used.

Except where explicitly differentiated, this discussion applies to both two-dimensional pximage as well as three-dimensional pximage3 structures; the pximage3 differing with three-dimensional spatial coordinates.

Except for the wind member, and (rarely) the pixelhint and h members, discussed below, the various members of the pximage must never be directly modified by the application program.

The imdim specifies the image's dimensions; the imdim.se.x, imdim.se.y, and imdim.se.z (for pximage3) are the ''x'' (horizontal), ''y'' (vertical), and ''z'' (depth for pximage3) dimensions. The imdim.nw.x, imdim.nw.y, and imdim.nw.z (for pximage3) are always 0, and allow convenient use of the imdim as a pxywindow (or pxyzwindow) which specifies a full image window.

The wind specifies an area of interest, equal to or smaller than the full image resolution. The imdim.nw.x, imdim.nw.y, and imdim.nw.z (for pximage3) are the ''x'' (horizontal), ''y'' (vertical), and ''z'' (depth for pximage3) coordinates of the area of interest's upper left corner, inclusive; the imdim.se.x, imdim.se.y, and imdim.se.z (for pximage3) are coordinates of the area of interest's lower left corner, exclusive. The choice of inclusive/exclusive coordinates allows a full image area of interest to be specified by the same values as within imdim. For historical reasons, the wind members may be directly altered by the application program; although such direct modification is not suggested for new applications (use the ::xwind service instead). When modified directly, it is the application program's responsibility to maintain legitimate values in wind — i.e. window dimensions larger than 0 and smaller than or equal to the image dimensions.

The d.pixies is the number of numeric components (i.e. ``pixies''), or the dimensionality, of each pixel. The d.pixies would be 1 for monochrome imagery, 2 for complex values (either real and imaginary or magnitude and phase), and 3 or 4 for RGB, YIQ, CMYK, HSI, or other color spaces.

The d.pixietype is the fundamental, optimal, data type to be used for each pixie.

C Type pixietype

unsigned char PXDATUCHAR
unsigned short PXDATUSHORT
unsigned int PXDATUINT
unsigned long PXDATULONG
float PXDATFLOAT
double PXDATDOUBLE
8 bit unsigned integer PXDATUINT8
16 bit unsigned integer PXDATUINT16
32 bit unsigned integer PXDATUINT32
(see NULL image, below) 0
Some of the above constants are synonymous, as per the current programming environment. For example, in typical 32 bit environments PXDATUINT8 is identical both in meaning and value to PXDATUCHAR, PXDATUINT16 is identical to PXDATUSHORT, and PXDATUINT32 is identical to PXDATUINT. The PXDATULONG is not available in programming environments where a ''long'' is 64 bits. Use of PXDATUINT8, PXDATUINT16, and PXDATUINT32 instead of PXDATUCHAR, PXDATUSHORT, PXDATUINT, and PXDATULONG is recommended for easier portability between 16, 32, and 64 bit programming environments.

Some pximage device drivers may allow pixies to be read or written into types other than d.pixietype, but reading or writing into a data type matching d.pixietype would be more efficient.

For d.pixietype's that are unsigned integer, the f.pixieuint will be one, and the u.i members provide additional interpretation of the pixie's values. The u.i.bitsused is the number of bits of each d.pixietype actually used. When fewer u.i.bitsused are used than actually available in each d.pixietype, the u.i.bitsxsb is PXDATLSB to indicate the bits used are right justified within the data type, or PXDATMSB to indicate the bits used are left justified within the data type. When all bits of the d.pixietype, are used, the u.i.bitsxsb is PXDATMSB|PXDATLSB.

For example, on hosts where an ''unsigned short'' is 16 bits, if u.i.bitsused=12 and u.i.bitsxsb=PXDATLSB, the range of pixel values is from 0 to 212-1 (4095) in steps of 1. If u.i.bitsused=10 and u.i.bitsxsb=PXDATMSB, the range of pixel values is from 0 to 216-1 (65535) in steps of 26 (64).[38]

When fewer u.i.bitsused are used than actually available in each d.pixietype, the u.i.dirtyread indicates whether the unused bits will be read as zero or may contain random values. Likewise, the u.i.dirtyrite indicates whether the unused bits must be written as zero, or may contain random values.

For d.pixietype's utilizing more than 1 byte, the u.i.endian indicates whether the byte order, little endian or big endian, matches the host's natural default.

For d.pixietype's that are floating point, the f.pixiereal will be one and the u.r members provide additional interpretation of the pixie's values. The u.r.minvalue and u.r.maxvalue specify the pixie's minimum and maximum values, respectively.

The d.pixelhint is a hint to how the pixel, particularly multiple component pixels (i.e. color), is to be interpreted.

pixelhint Number of Interpretation
Components

PXHINTNONE (=0) unknown Unknown
PXHINTGREY 1 Grey scale monochrome
PXHINTINDEX 1 Index into (unspecified) palette
PXHINTBAYER 1 Bayer pattern RGB
PXHINTBAYER0 1 Bayer pattern RGB starting w. red
PXHINTBAYER1 1 Bayer pattern RGB starting w. grn-red
PXHINTBAYER2 1 Bayer pattern RGB starting w. grn-blu
PXHINTBAYER3 1 Bayer pattern RGB starting w. blu
PXHINTCOMPLEX 2 Complex, probably of monochrome data
PXHINTCBYCRY 2 Cb,Y,Cr,Y,Cb,Y,Cr,Y,... (YCrCb,UYVY)
PXHINTYCBYCR 2 Y,Cb,Y,Cr,Y,Cb,Y,Cr,... (YCrCb,YUY2)
PXHINTCRYCBY 2 Cr,Y,Cb,Y,Cr,Y,Cb,Y,... (YCrCb,VYUY)
PXHINTYCRYCB 2 Y,Cr,Y,Cb,Y,Cr,Y,Cb,... (YCrCb,YVYU)
PXHINTBGR 3 Blue,Green,Red,... (RGB)
PXHINTYCRCB 3 Y,Cr,Cb,Y,Cr,Cb,... (YCrCb)
PXHINTBSH 3 Brightness,Saturation,Hue,... (HSB)
PXHINTRGB 3 Red,Green,Blue,... (RGB)
PXHINTYIQ 3 YIQ
PXHINTCMY 3 Cyan,Magent,Yellow (CMY)
PXHINTBGRX 4 Blue,Green,Red,Pad,... (RGB)
PXHINTYCRCBX 4 Y,Cr,Cb,Pad,Y,Cr,Cb,Pad,... (YCrCb)
PXHINTRGBX 4 Red,Green,Blue,Pad,... (RGB)
PXHINTBAYERX4 4 Bayer pattern w. R Gr Gb B values each pixel
PXHINTCMYK 4 Cyan,Magent,Yellow,Black (CMYK)

PXHINTUSER unknown User-defined types: from PXHINTUSER
thru PXHINTUSER+PXHINTUSERN
For example, PXHINTBGRX hints that the first pixie is the Blue value, followed by values of Green, Red, and a fourth, unused, pixie value.[39]

The h.pixelwidth, h.pixelheight and h.pixeldepth provide a hint on the real-world width, height, and depth of a pixel; any may be 0 if no information is available. The h.widthunits, h.heightunits, and h.depthunits specify the units of the h.pixelwidth, h.pixelheight, and h.pixeldepth values, respectively.

widthunits
heightunits
depthunits Interpretation

PXUNITUNKNOWN (=0) Unknown
PXUNITRATIO Unitless, relative ratio
PXUNITINCH Inches
PXUNITFOOT Feet
PXUNITMETER Meters
PXUNITMILLIMETER Millimeters
PXUNITCENTIMETER Centimeters
PXUNITSECOND Seconds

A pximage which has been unsuccessfully constructed will be a so-called NULL image. All members shown above will be 0; thus the image dimensions will be 0, as will the d.pixietype. The member functions (methods) can be safely invoked; they refer to no-op functions which do nothing.


PXIMAGE: Set & Get Area of Interest Window --- pximage::xwind



Summary
struct pxywindow * (ip->xwind)(ip, wp, mode);
struct pximage      *ip;            // Pointer to pximage instance
struct pxywindow    *wp;            // Pointer to area of interest, or NULL
int                 mode;           // 'i': Get full image dimensions
                                    // 'w': Det area of interest dimensions
                                    // 's': Set area of interest dimensions

struct pxyzwindow * (ip3->xwind)(ip3, wp3, mode); struct pximage3 *ip3; // Pointer to pximage3 instance struct pxyzwindow *wp3; // Pointer to area of interest, or NULL int mode; // As above



Description

The area of interest window associated with the pximage instance referenced by ip, or the pximage3 instance referenced by ip3, is retrieved or modified.

If mode='i', the ip's (ip3's) full image dimensions, expressed as a pxywindow (pxyzwindow) structure are retrieved. A pointer to the pxywindow (pxyzwindow) dimensions is returned, and if wp≠NULL (wp3≠NULL), the pxywindow (pxyzwindow) is also copied to *wp (*wp3).

If mode='w', the ip's (ip3's) current area of interest dimensions, expressed as a pxywindow (pxyzwindow) structure are retrieved. A pointer to the pxywindow (pxyzwindow) dimensions is returned, and if wp≠NULL (wp3≠NULL), the pxywindow (pxyzwindow) is also copied to *wp (*wp3).

If mode='s', the ip's (ip3's) area of interest is set to *wp (*wp3); if wp=NULL (wp3=NULL), the area of interest is set to the full image dimensions. A pointer to the new area of interest dimensions is returned.

If the area of interest specified by *wp (*wp3) is invalid, all members of the area of interest window are set to 0 and the pximage's (pximage3's) ::ioset, ::bxts, and ::imapset services will not succeed until a valid area of interest window is set.


Returns

As described above.


PXIMAGE: Get Advice, Errors, Info & Options --- pximage::aeiou



Summary
pximaeiou_t (ip->aeiou) (ip,  service, parm1, parm2, parm3);
pximaeiou_t (ip3->aeiou)(ip3, service, parm1, parm2, parm3);
struct pximage      *ip;            // Pointer to pximage instance
struct pximage3     *ip3;           // Pointer to pximage3 instance
int                 service;        // As described below
int                 parm1;          // Option
int                 parm2;          // Option
void                *parm3;         // Rsvd. should be NULL

typedef ulong       pximaeiou_t;    // in 16 & 32 bit environments
typedef uint        pximaeiou_t;    // in 64 bit environments



Description

Advice, errors, and/or information associated with activity on the pximage instance referenced by ip, or the pximage3 instance referenced by ip3, is obtained.

Service Return Value Meaning Parm1 Parm2
Cast Into

'I' (uint) Suggested access cnt, ioread()/iorite() 0 0
'B' (uint) Suggested access cnt, bxta() 0 0

'i' Image access dope, ioread()/iorite() 0 0
'b' Image access dope, bxta() 0 0
'm' Image access dope, imap() 0 0

'e' (int) Previous error, or 0 clear recurse

If service='I', the suggested, or optimal, access count for use with ::ioread or ::iorite is returned. The returned value is never larger than UINT_MAX. The parm1 and parm2 are ignored.

If service='B', the suggested, or optimal, access count for use with ::bxta is returned. The returned value is never larger than:

UINT_MAX / sizeof(struct pximadrs)
The parm1 and parm2 are ignored.

If service='i', information about image access time and overhead for pixels read or written via ::ioread or ::iorite is returned. If service='b', information about image access time and overhead for pixels read, written, or modified via ::bxta is returned. If service='m', information about image access time and overhead for pixels read or written via a pointer provided by ::imap is returned.[40] The parm1 and parm2 are ignored. The returned information is described further in pximage.h.

If service='e', the last error code, if any, associated with activity on the pximage instance referenced by ip, or the pximage3 instance referenced by ip3, is retrieved. If parm1≠0, the error code is also cleared, so that a subsequent query doesn't return the same code.

If parm2≠0, and the ip (ip3) is a filter used in front of another pximage (pximage3), the first error code found in the chain of pximage's (pximage3's), is retrieved. Further, if parm1≠0, the one error code, on the specific pximage (pximage3) where it was found, is cleared.

Error codes typically report an error that occurred while reading or writing pixels. The values of error codes, cast to an ''int'' are interpreted as described in pxerrnomesg. Some pximage (pximage3) devices, such as those accessed via pximage_memory, never have error conditions. Others, such as those accessed via pximage_file record errors if/when an I/O error occurs reading or writing the underlying image file.


Returns

As described above.


PXIMAGE: Set to Access Sequential Pixels --- pximage::ioset
PXIMAGE: Read Sequential Pixels --- pximage::ioread
PXIMAGE: Write Sequential Pixels --- pximage::iorite
PXIMAGE: Wait for Sequential Access Completion --- pximage::iowait
PXIMAGE: Obtain Sequential Access Pixel Count --- pximage::iolen



Summary
int       (ip->ioset) (ip, mode, data, colormap);
pximcnt_t (ip->ioread)(ip, mode, bufp, cnt, x, y);
pximcnt_t (ip->iorite)(ip, mode, bufp, cnt, x, y);
int       (ip->iowait)(ip, wait, bufp);
pximcnt_t (ip->iolen) (ip, cnt, x, y);

int (ip3->ioset) (ip3, mode, data, colormap); pximcnt_t (ip3->ioread)(ip3, mode, bufp, cnt, x, y, z); pximcnt_t (ip3->iorite)(ip3, mode, bufp, cnt, x, y, z); int (ip3->iowait)(ip3, wait, bufp); pximcnt_t (ip3->iolen) (ip3, cnt, x, y, z);
struct pximage *ip; // Pointer to pximage instance struct pximage3 *ip3; // Pointer to pximage3 instance int mode; // As described below int data; // PXDATUCHAR, PXDATUSHORT, etc. // or'ed with PXDATLSB or PXDATMSB uint colormap; // Pixie selection bit map void _far *bufp; // Host memory [16 bit environments] void *bufp; // Host memory [32 bit environments] pximcnt_t cnt; // Number of pixels to access pxcoord_t x; // Access x (horizontal) coordinate pxcoord_t y; // Access y (vertical) coordinate pxcoord_t z; // Access z (depth) coordinate int wait; // PXAWAIT,PXASYNC,PXABORT

typedef uint        pximcnt_t;



Description

The ::ioset, ::ioread, ::iorite, ::iowait, and ::iolen provide access to sequences of pixels in the pximage instance referenced by ip, or the pximage3 instance referenced by ip3. The ::ioset must be used before other functions in this group; ::ioset establishes various modes which affect how the other functions operate. The ip's (or ip3's) area of interest window must not be changed between setting an access mode with ::ioset and using the other functions in this group.


::ioset. The ::ioset establishes the sequence orientation (horizontal, vertical, depth), and the data type for later ::ioread and ::iorite.

If mode=PXRXSCAN, sequential access is in order of increasing ''x'', then increasing ''y'' (and then increasing ''z''). If mode=PXRYSCAN, sequential access is in order of increasing ''y'', then increasing ''x'' (and then increasing ''z''). (If mode=PXRZSCAN, sequential access is in order of increasing ''z'', then increasing ''x'', and then increasing ''y'').

If the mode is OR'ed with PXIWRAP, a single sequential access may ''wrap'' around at the end of the specified line (PXRXSCAN), column (PXRYSCAN), or depth vector (PXRZSCAN), allowing several lines, columns, or depth vectors to be transferred at the same time. Otherwise, a single ::ioread or ::iorite access will stop at the end of the specified line (PXRXSCAN), column (PXRYSCAN) (or depth vector (PXRZSCAN)). If the mode is OR'ed with PXIXYVALID, the ''x'', ''y'', (or ''z'') coordinates specified by ::ioread or ::iorite are assumed to be valid, requiring less overhead for checking.

The data specifies the data type that ::ioread or ::iorite will provide for pixel data.

C Type data

(array of) unsigned char PXDATUCHAR
(array of) unsigned short PXDATUSHORT
(array of) unsigned int PXDATUINT
(array of) unsigned long PXDATULONG
(array of) float PXDATFLOAT
(array of) double PXDATDOUBLE
(array of) 8 bit unsigned integer PXDATUINT8
(array of) 16 bit unsigned integer PXDATUINT16
(array of) 32 bit unsigned integer PXDATUINT32
For the unsigned integer types, the data may be OR'ed with PXDATLSB or PXDATMSB. If the specified data type has the same number of bits as ip->u.i.bitsused (ip3->u.i.bitsused), use of PXDATLSB or PXDATMSB has no effect. Otherwise, PXDATLSB specifies that the significant bits are to be read/written to/from the specified data type right justified, PXDATMSB specifies that the significant bits are to be read/written to/from the specified data type left justified. If the data type has fewer bits than ip->u.i.bitsused, the most significant pixel bits are kept. If neither PXDATLSB or PXDATMSB is used, the pixel data is not shifted; the right most bits of the pixel are read/written to/from the specified data type, and the least significant bits are kept.

For the unsigned integer types, the data may also be OR'ed with PXDATDIRTY. If the specified data type has the same number of bits as ip->u.i.bitsused (ip3->u.i.bitsused), use of PXDATDIRTY has no effect. Otherwise, for ::iorite PXDATDIRTY indicates that the values being written have random values in the unused bits, rather than zeros. For ::ioread PXDATDIRTY indicates that the values being read are allowed to have random values in the unused bits, rather than zeros.

The colormap specifies which pixie components are to be accessed; bit 0x01 of colormap represent the first pixie component, bit 0x02 the second pixie component, etc. Multiple components may be accessed; colormap=0x07 specifies access to three components. Not all pximage (pximage3) devices support access to arbitrary subsets of pixies. For example, a pximage (pximage3) device providing 4 pixies must support colormap=0x1F, and may, or may not, support (in decreasing order of likelihood): (a) A colormap with a single bit set providing access to any one pixie, (b) A colormap with a contiguous block of bits set (e.g. 0x18, 0x07, or 0x06) providing access to a contiguous group of pixies, or (c) A colormap with an arbitrary pattern of bits set (e.g. 0x09) providing access to a arbitrary group of pixies.

The ::ioset returns a value greater than 0 if successful, or less than 0 if the image can't be accessed in the manner requested.


::ioread & ::iorite. The ::ioread and ::iorite respectively read pixel data from the image to a host buffer and write pixel data from a host buffer to the image. The cnt is the maximum number of pixels (not pixies!) to be accessed, starting at coordinates x, y, (and z) relative to the current area of interest; and proceeding in the PXRXSCAN, PXRYSCAN, (or PXRZSCAN) order, as specified previously via ::ioset. Fewer than cnt pixels may actually be accessed; access stops when the end of the image area of interest is reached, or, if PXIWRAP was not previously specified via ::ioset, when the end of the current row, column, (or depth vector) is reached.

The return value of ::ioread or ::iorite indicates the number of pixels (not pixies!) transferred.

The bufp must reference an array of the data type specified previously via ::ioset, with size no smaller than cnt times the number of pixies encoded in the colormap specified via ::ioset. The elements of bufp are filled in pixel by pixel, for each pixel the lowest numbered pixie first, followed by higher numbered pixies.

If mode=PXIASYNC, the pixel access is done asynchronously, if possible. If the return value of ::ioread or ::iorite is non-zero, asynchronous operation isn't available and the operation is complete. A return value of zero indicates that the operation is pending and may not be complete; the ::iowait must be used to wait or test for completion. For each instance of a pximage or pximage3, only one asynchronous operation may be pending at any one time.

The mode may also be OR'ed with PXIMAYMOD. The PXIMAYMOD has no effect for ::ioread. For ::iorite, PXIMAYMOD indicates that the (contents of) bufp array is disposable, and may be modified at the whim of the pximage device driver.


::iowait. The ::iowait need be used only when PXIASYNC is used with ::ioread or ::iorite. The bufp must be the same value as used with ::ioread or ::iorite. The wait must be either: (a) PXAWAIT, for which return is delayed until the previous operation is complete, returning the value PXODONE; (b) PXASYNC, for which return is immediate and the return value is PXODONE to indicate the operation is complete or PXOPRUN to indicate the operation is not yet complete; or (c) PXABORT, to prematurely terminate (if possible) the pending operation, returning value PXODONE.


::iolen. The ::iolen returns the number of pixels that ::ioread or ::iorite would access, if given the same cnt, x, y, and z parameters.


Returns

As described above.


Example

/*
 * Read one and return one pixel value component.
 * The x & y parameters are assumed relative to the window AOI, if any.
 *
 * Note: Reading or writing one pixel or one pixel component
 * at a time is not efficient; this is provided as an educational
 * example, not as a recommendation for use. Reading or writing lines,
 * columns or the entire image at one time is supported and highly recommended.
 *
 * Return is a signed long to accommodate errors.
 */
long imagepixie(struct pximage *ip, pxcoord_t x, pxcoord_t y, int pixie)
{
    union {
        uchar   c;
        ushort  s;
    } v;

if (!ip) return(-1); // missing pximage* // // Following tests aren't really necessary; // the ioset/ioread ends up doing the same. // They help illustrate use of the pximage fields. // if (x < 0 || x >= ip->imdim.se.x || y < 0 || y >= ip->imdim.se.y) return(-1); // x or y out of image bounds if (pixie < 0 || pixie >= ip->d.pixies) return(-1); // pixie out of bounds if (x >= ip->wind.se.x-ip->wind.nw.x || y >= ip->wind.se.y-ip->wind.nw.y) return(-1); // x or y out of AOI bounds
// // Setup for read. // if ((*ip->ioset)(ip, PXRXSCAN, ip->d.pixietype, 1<<pixie) < 0) return(-1); // // Read // #if 1 // // On some architectures, depending on little vs big endian // and on how loose one wants to be with C, one can do // the following for both PXDATUCHAR and PXDATUSHORT. // if (ip->d.pixietype == PXDATUCHAR || ip->d.pixietype == PXDATUSHORT) { v.s = 0; if ((*ip->ioread)(ip, 0, &v, 1, x, y) < 0) return(-1); return(v.s); } #else // // The alternative is safe but verbose. // switch (ip->d.pixietype) { case PXDATUCHAR: if ((*ip->ioread)(ip, 0, &v.c, 1, x, y) < 0) return(-1) return(v.c); case PXDATUSHORT: if ((*ip->ioread)(ip, 0, &v.s, 1, x, y) < 0) return(-1) return(v.s); } #endif return(-1); // data type unsupported by this example }

/*
 * Read all one or three components of one pixel.
 * See comments above regarding efficiency.
 * Assumes that all components can be shifted and fit into a long.
 */
long imagepixel(struct pximage *ip, pxcoord_t x, pxcoord_t y)
{
    union {
        uchar   c[3];
        ushort  s[3];
        ulong   l;
    } v;
    int     i;
    long    l;

if (!ip) return(-1); // missing pximage* // // Following tests aren't really necessary; // the ioset/ioread ends up doing the same. // They help illustrate use of the pximage fields. // if (x < 0 || x >= ip->imdim.se.x || y < 0 || y >= ip->imdim.se.y) return(-1); // x or y out of image bounds if (x >= ip->wind.se.x-ip->wind.nw.x || y >= ip->wind.se.y-ip->wind.nw.y) return(-1); // x or y out of AOI bounds
// // Setup for read. // The last paramater to ::ioset is a bit map selecting // all pixel components, with a maximum of 3. // if ((*ip->ioset)(ip, PXRXSCAN, ip->d.pixietype, max(7, (1<<ip->d.pixies)-1)) < 0) return(-1); // // Read // #if 1 // // On some architectures, depending on little vs big endian // and on how loose one wants to be with C, one can do // the following for PXDATUCHAR. // if (ip->d.pixietype == PXDATUCHAR) { if ((*ip->ioread)(ip, 0, &v.c[0], 1, x, y) < 0) return(-1); return(v.l); } #endif // // The alternative is safe but verbose. // switch (ip->d.pixietype) { case PXDATUCHAR: if ((*ip->ioread)(ip, 0, &v.c, 1, x, y) < 0) return(-1); for (l = i = 0; i < min(3, ip->d.pixies); i++) l = (l<<ip->d.u.i.bitsused) | v.c[i]; return(l);
case PXDATUSHORT: if ((*ip->ioread)(ip, 0, &v.s, 1, x, y) < 0) return(-1); for (l = i = 0; i < min(3, ip->d.pixies); i++) l = (l<<ip->d.u.i.bitsused) | v.s[i]; return(l); } return(-1); // data type unsupported by this example }

PXIMAGE: Set to Access Non-Sequential Pixels --- pximage::bxts
PXIMAGE: Prepare for Non-Sequential Pixel Access --- pximage::bxtp
PXIMAGE: Access Non-Sequential Pixels --- pximage::bxta
PXIMAGE: Wait for Non-Sequential Access Completion --- pximage::bxtw



Summary
int       (ip->bxts)(ip, mode, data, colormap);
int       (ip->bxtp)(ip, mode, bufp, adrsp, cnt, op);
pximcnt_t (ip->bxta)(ip, mode, bufp, adrsp, cnt, op);
int       (ip->bxtw)(ip, wait, bufp, adrsp);

int (ip3->bxts)(ip3, mode, data, colormap); int (ip3->bxtp)(ip3, mode, bufp, adrsp, cnt, op); pximcnt_t (ip3->bxta)(ip3, mode, bufp, adrsp, cnt, op); int (ip3->bxtw)(ip3, wait, bufp, adrsp);
struct pximage *ip; // Pointer to pximage instance struct pximage3 *ip3; // Pointer to pximage3 instance int mode; // As described below int data; // PXDATUCHAR, PXDATUSHORT, etc. // or'ed with PXDATLSB or PXDATMSB uint colormap; // Pixie selection bit map void _far *bufp; // Host memory [16 bit environments] void *bufp; // Host memory [32 bit environments] struct pximadrs _far *adrsp; // List of pixel locations [16 bit environments] struct pximadrs *adrsp; // List of pixel locations [32 bit environments] pximcnt_t cnt; // Number of pixels to access int op; // Operation: PXPIXBLT, PXPIXBATN, PXPIXBUTN, // PXPIXBRT, PXPIXBWT, PXPIXBXT, int wait; // PXAWAIT,PXASYNC,PXABORT

struct pximadrs {                   // list of pixel locations
    union {
        struct  pxy  xy;            // x, y coordinates
        struct  pxyz xyz;           // x, y, z coordinates

ulong devadrs; // internal usage ... uint devstate[3]; // .. device specific void *devptr0; // .. coordinates ... } adrs; }; typedef struct pximadrs pximadrs_s;



Description

The ::bxts, ::bxtp, ::bxta, and ::bxtw provide access to a list of pixels in arbitrary locations in the pximage instance referenced by ip, or the pximage3 instance referenced by ip3. The ::bxts must be used before other functions in this group; ::bxts establishes various modes which affect how the other functions operate. The ip's (or ip3's) area of interest window must not be changed between setting an access mode with ::bxts and using the other functions in this group.


Overview. Application programs prepare an array of pximadrs structures, one pximadrs for each pixel to be accessed. The adrs.xy (or adrs.xyz) of each pximadrs is initialized with a pixel's coordinates relative to the current area of interest. For each pixel in the list, a pixel read, write, or modify operation is performed; reading pixel values into the bufp, writing pixel values from the bufp, or modifying pixel values with values from the bufp.


::bxts. The ::bxts establishes the data type for later ::bxta. The mode is reserved, and should be PXIXYVALID. The data and colormap of ::bxts specifies the data type the bufp is expected to reference, and which pixel components are to be accessed, as described above for ::ioset.

The ::bxts returns a value greater than 0 if successful, or less than 0 if the image can't be accessed in the manner requested. Some pximage (or pximage3 device drivers may not support the ::bxt* services.


::bxtp. If mode&PXIBXTC, the ::bxtp translates the adrs.xy (or adrs.xyz) of the adrsp list containing cnt elements of pximadrs structures into an internal, device dependent, form. The adrs.xy (or adrs.xyz) coordinates are assumed valid! The op is the operation to be performed, as described below for ::bxta. (The op is currently ignored and may be 0).

The address translation can be done when pixels are accessed with ::bxta, explicit translation and modification allows reusing the same list with lower overhead.

The ::bxtp return value is the mode with the PXIBXTC bit set if the adrs.xy (or adrs.xyz) were modified or overwritten, otherwise the PXIBXTC bit is reset (if the device driver chooses to work with the original ''x'', ''y'', and ''z'' coordinates).


::bxta. The ::bxta reads, writes, or modifies the cnt pixels whose coordinates are specified by the adrsp list of cnt elements of pximadrs structures. The bufp must reference an array of the data type specified previously via ::bxts, with size no smaller than cnt times the number of pixies encoded in the colormap specified via ::bxts; successive pixies from bufp are associated with successive pixel addresses from adrsp. The op specifies the desired operation:

op value operation

PXPIXBLT exchange value in bufp[] with pixel
PXPIXBATN add value in bufp[] to pixel
PXPIXBUTN subtract value in bufp[] from pixel
PXPIXBUTN subtract value in bufp[] from pixel
PXPIXBRT read pixel value into bufp[]
PXPIXBWT write value in bufp[] to pixel
PXPIXBXT XOR value in bufp[] with pixel (unsigned integer pixels only)
For PXPIXBLT, PXPIXBATN, PXPIXBUTN, PXPIXBWT, and PXPIXBXT, the pixels in the buffer referenced by bufp should be initialized with a value before using ::bxta. For PXPIXBLT and PXPIXBRT, the pixels in the buffer referenced by bufp will be modified.

The mode should be 0, OR'ed with the following options. If mode is OR'ed with PXIBXTC ::bxta also performs the effect of ::bxtp, avoiding having to explicitly invoke ::bxtp.

The return value of ::bxta indicates the number of pixels accessed.

The mode may be OR'ed with PXIASYNC; the pixel access is done asynchronously, if possible. If the return value of ::bxta is non-zero, asynchronous operation isn't available and the operation is complete. A return value of zero indicates that the operation is pending and may not be complete; the ::bxtw must be used to wait or test for completion. For each instance of a pximage or pximage3, only one asynchronous operation may be pending at any one time.


::bxtw. The ::bxtw need be used only when PXIASYNC is used with ::bxta. The bufp and adrsp must be the same values as used with ::bxta. The wait must be either: (a) PXAWAIT, for which return is delayed until the previous operation is complete, returning the value PXODONE; (b) PXASYNC, for which return is immediate and the return value is PXODONE to indicate the operation is complete or PXOPRUN to indicate the operation is not yet complete; or (c) PXABORT, to prematurely terminate (if possible) the pending operation, returning value PXODONE.


Returns

As described above.


PXIMAGE: Set to Obtain Pointer to Pixels --- pximage::imapset
PXIMAGE: Obtain Pointer to Pixels --- pximage::imap
PXIMAGE: Release Pointer to Pixels --- pximage::imapr



Summary
int  (ip->imapset)(ip, mode, data, colormap);
int  (ip->imap)(ip, mp, x, y);
void (ip->imapr)(ip, mp);

int (ip3->imapset)(ip3, mode, data, colormap); int (ip3->imap)(ip3, mp, x, y, z); void (ip3->imapr)(ip3, pixp);
struct pximage *ip; // Pointer to pximage instance struct pximage3 *ip3; // Pointer to pximage3 instance int mode; // As described below int data; // PXDATUCHAR, PXDATUSHORT, etc. // or'ed with PXDATLSB or PXDATMSB uint colormap; // Pixie selection bit map struct pximap *mp; // Pixel reference 'handle'
pxcoord_t x; // Access x (horizontal) coordinate pxcoord_t y; // Access y (vertical) coordinate pxcoord_t z; // Access z (depth) coordinate

struct pximap
{
    int         valid;  // imap()'s return value, clr'ed by imapr()
    void _far   *p;     // pointer to image memory [segmented (i86) environments]
    void        *p;     // pointer to image memory [non-segmented environments]

size_t inc; // increment to next pixie, always in .. // .. sizeof(char), regardless of pixie type size_t len; // number of following pixels that can be accessed .. // .. at increasing x,y,z by using the inc
// if imap() mode 2 (PXIMAP2): (future) size_t xinc; // increment to next pixel (X) in row size_t yinc; // increment to next row (Y) in image size_t zinc; // increment to next image (Z) in sequence (3-D) // all in sizeof(char), regardless of pixie type size_t xdim; // # of accessible pixels at increasing X size_t ydim; // # of accessible pixels at increasing Y size_t zdim; // # of accessible pixels at increasing Z }; typedef struct pximap pximap_s;



Description

The ::imapset, ::imap, and ::imapr provides direct pointer access to pixels in the pximage instance referenced by ip, or the pximage3 instance referenced by ip3. Some pximage (or pximage3) device drivers do not support the ::imap service, or may provide the service under limited conditions.[41]

The ::imapset must be used before other functions in this group; ::imapset establishes various modes which affect how the other functions operate. The ip's (or ip3's) area of interest window must not be changed between setting an access mode with ::imapset and using the other functions in this group.


Overview. The ::imap requests access to the pixel at coordinates x, y, (and z), relative to the image area of interest, and as many of the following pixels as possible; the mode of ::imapset specifies the sense of ''following pixels''; in order of increasing x, y, (or z). The data and colormap of ::imapset specifies the data type the pointer is expected to reference, and which pixel components are to be accessed. If direct access is possible, ::imap returns a suitable pointer, which, after being cast to the correct data type, can read or write pixel values. Also returned are the number of following pixels that can be accessed, and the increment to be added to the pointer to access the following pixels. When done, the direct access is released with ::imapr.


::imapset. The ::imapset establishes the sequence orientation (horizontal, vertical, depth), and the data type for later use of ::imap.

The mode should be PXRXSCAN, PXRYSCAN, (or PXRZSCAN). If mode=PXRXSCAN, the sense of ''following pixels'' is in order of increasing ''x'', then increasing ''y'' (and then increasing ''z''). If mode=PXRYSCAN, the sense is in order of increasing ''y'', then increasing ''x'' (and then increasing ''z''). (If mode=PXRZSCAN, the sense is in order of increasing ''z'', then increasing ''x'', and then increasing ''y'').

If mode is OR'ed with PXIWRAP, the sense of ''following pixels'' ''wraps'' around at the end of the specified line (PXRXSCAN), column (PXRYSCAN), or depth vector (PXRZSCAN), allowing several lines, columns, or depth vectors to be available at the same time. Otherwise, the sense of ''following pixels'' stops at the end of the specified line (PXRXSCAN), column (PXRYSCAN) (or depth vector (PXRZSCAN)).

If mode is not OR'ed with PXIMAPINC, the returned mp->inc (assuming direct access service is available at all) is always the size of the data type specified by data; in other words, the assumptions expressed by:

    struct  pximap  imap;
    uint16  _far    *lp;    // _far only in segmented environments

if ((ip->imapset)(ip, PXRXSCAN, PXDATUINT16, 0x01) > 0) { if ((ip->imap)(ip, &imap, 0, 0)) { lp = imap.p; while (imap.len--) *lp++ = 0; (ip->imapr)(ip, &imap); } }
are valid. If mode is OR'ed with PXIMAPINC, the mp->inc, may not be the data size, but more pixels may thereby be accessible. The above extract must be modified to:
    struct  pximap  imap;

if ((ip->imapset)(ip, PXRXSCAN|PXIMAPINC, PXDATUINT16, 0x01) > 0) if ((ip->imap)(ip, &imap, 0, 0)) { while (imap.len--) { *((uint16 _far*)imap.p) = 0; // _far only in segmented environments (uchar _far*) imap.p += imap.inc; } (ip->imapr)(ip, &imap); }

Note: The mp->inc is always in units of ''uchars''!!!

If mode is OR'ed with PXIMAPNOTFAR, the ::imapset will succeed only if the pointer returned by ::imap can have the ''_far'' adjective cast off; the assumptions expressed by:

    struct  pximap imap;
    uint16  *lp;    // a default pointer!! All environments!!

if ((ip->imapset)(ip, PXRXSCAN|PXIMAPNOTFAR, PXDATUINT16, 0x01) > 0) if ((ip->imap)(ip, &imap, 0, 0)) { lp = imap.p; // ignore compiler warning lp = (uint16*)(imap.p); // or explicitly cast it while (imap.len--) *lp++ = 0; (ip->imapr)(ip, &imap); }
are valid. In nonsegmented environments which do not require the ''_far'' adjective, on in environments such as Microsoft 32 Bit C which doesn't support ''_far'' pointers, the PXIMAPNOTFAR is ignored.

If mode is OR'ed with PXIXYVALID, the ''x'', ''y'', (and ''z'') coordinates given to ::imap are assumed valid, requiring less overhead for checking.

The data specifies the intended data type of the returned pointer.

pointer type data

uchar PXDATUCHAR
ushort PXDATUSHORT
uint PXDATUINT
ulong PXDATULONG
float PXDATFLOAT
double PXDATDOUBLE
8 bit unsigned integer PXDATUINT8
16 bit unsigned integer PXDATUINT16
32 bit unsigned integer PXDATUINT32
For the unsigned integer types, the data may also be OR'ed with PXDATMSB, PXDATLSB, and/or PXDATDIRTY. These specifications are interpreted in a similar manner as the data parameter described for ::ioset. If PXDATMSB is used, ::imapset will succeed only if the unused bits, if any, are right justified. If PXDATLSB is used, ::imapset will succeed only if the unused bits, if any, are left justified. The PXDATMSB and PXDATLSB should not be used together. If PXDATDIRTY is not used, ::imapset will succeed only if the unused bits, if any, are 0.

The colormap specifies which pixie components are to be accessed, in the same manner as the colormap parameter described for ::ioset.

The ::imapset returns a value greater than 0 if successful; or less than 0 if the service is not available, or the requested/expected data and colormap is not consistent with the actual pixel data.


::imap. The ::imap requests a direct access pointer to the pixel at ''x'', ''y'', (and ''z'') relative to the image area of interest, and to following pixels; where the orientation of ''following pixels'', and the expected data type of the pointer are as specified by the mode, data, and colormap or ::imapset.

The ::imap returns 1 if access is granted, and fills in the pximap structure referenced by mp. The mp->p is the direct access pointer, the mp->len is the number of pixels that can be accessed with mp->p by incrementing by mp->inc ''uchars''. The mp->valid is set to 1.

The ::imap returns 0 if the access is denied, and sets mp->valid to 0. The ::imap may fail even if ::imapset succeeds.[42]

Multiple, simultaneous, direct access pointers may be requested from the same pximage (or pximage3), although hardware limitations may restrict ability of some device drivers to fulfill the second or later requests.

Under environments other than real-mode DOS: For pximage's (or pximage3's), which access buffers on imaging boards (such as on the SILICON VIDEO® MUX or the 4MEG VIDEO imaging boards), the direct access pointer provided by ::imap may be used by the requesting application, but can not be passed to other applications or to system services such as file I/O.


::imapr. The ::imapr releases a direct access pointer provided by ::imap and sets mp->valid to 0. For convenience, the ::imapr may be called even if ::imap failed (using the same mp) without ill effect. Also, for convenience, the mp->p, mp->len, and mp->cnt, (but not mp->valid) may be altered between invocations of ::imap and ::imapr.


Returns

As described above.


 

 

 

13. Deprecated Functions

Use of camera specific functions pxd_SV2112_setExposureAndGain, pxd_SV2112_getExposure, pxd_SV2112_getGain, pxd_SV2112_setResolutionAndTiming, pxd_SV2112_getDecimation, pxd_SV2112_getAoiTop, pxd_SV2112_getAoiLeft, pxd_SV2112_getPixelClock, pxd_SV2112_getScanDirection, pxd_SV2112_setVideoAndTriggerMode, pxd_SV2112_setCtrlExposureAndRate, pxd_SV2112_getVideoMode, pxd_SV2112_getCtrlVideoMode, pxd_SV2112_getCtrlTriggerMode, pxd_SV2112_getCtrlFrameRate, pxd_SV2112_getCtrlExposure, pxd_SV2112_getMinMaxExposure, and pxd_SV2112_getMinMaxCtrlExposure is deprecated; new applications should use pxd_SILICONVIDEO_setExposureGainOffset, pxd_SILICONVIDEO_setExposureColorGainOffsets, pxd_SILICONVIDEO_setResolutionAndTiming, pxd_SILICONVIDEO_setVideoAndTriggerMode, pxd_SILICONVIDEO_setCtrlRates, pxd_SILICONVIDEO_getMinMaxExposure, pxd_SILICONVIDEO_getMinMaxCtrlExposure and related functions.

Use of camera specific functions pxd_SV1281_setExposureGainOffset, pxd_SV1281_getExposure, pxd_SV1281_getGain, pxd_SV1281_getOffset, pxd_SV1281_setResolutionAndTiming, pxd_SV1281_getAoiTop, pxd_SV1281_getAoiLeft, pxd_SV1281_getPixelClock, pxd_SV1281_setVideoAndTriggerMode, pxd_SV1281_setCtrlRate, pxd_SV1281_getVideoMode, pxd_SV1281_getCtrlVideoMode, pxd_SV1281_getCtrlTriggerMode, pxd_SV1281_getCtrlFrameRate, and pxd_SV1281_getMinMaxExposure is deprecated; new applications should use pxd_SILICONVIDEO_setExposureGainOffset, pxd_SILICONVIDEO_setExposureColorGainOffsets, pxd_SILICONVIDEO_setResolutionAndTiming, pxd_SILICONVIDEO_setVideoAndTriggerMode, pxd_SILICONVIDEO_setCtrlRates, pxd_SILICONVIDEO_getMinMaxExposure and related functions.

Use of camera specific functions pxd_SV1310_setExposureGainOffset, pxd_SV1310_getExposure, pxd_SV1310_getGain, pxd_SV1310_getOffset, pxd_SV1310_setColorGain, pxd_SV1310_getColorGain, pxd_SV1310_setResolutionAndTiming, pxd_SV1310_getSubsample, pxd_SV1310_getAoiTop, pxd_SV1310_getAoiLeft, pxd_SV1310_getPixelClock, pxd_SV1310_getReadoutDirection, pxd_SV1310_getFramePeriod, pxd_SV1310_setVideoAndTriggerMode, pxd_SV1310_setCtrlRate, pxd_SV1310_getVideoMode, pxd_SV1310_getCtrlVideoMode, pxd_SV1310_getCtrlTriggerMode, pxd_SV1310_getCtrlFrameRate, and pxd_SV1310_getMinMaxExposure is deprecated; new applications should use pxd_SILICONVIDEO_setExposureGainOffset, pxd_SILICONVIDEO_setExposureColorGainOffsets, pxd_SILICONVIDEO_setExposureGainOffset, pxd_SILICONVIDEO_setExposureColorGainOffsets, pxd_SILICONVIDEO_setResolutionAndTiming, pxd_SILICONVIDEO_setVideoAndTriggerMode, pxd_SILICONVIDEO_setCtrlRates, pxd_SILICONVIDEO_getMinMaxExposure and related functions.

Use of camera specific functions pxd_SV642_setExposureAndGain, pxd_SV642_getExposure, pxd_SV642_getGain, pxd_SV642_getGainRange, pxd_SV642_setResolutionAndTiming, pxd_SV642_getAoiTop, pxd_SV642_getAoiLeft, pxd_SV642_getPixelClock, pxd_SV642_setVideoAndTriggerMode, pxd_SV642_setCtrlRate, pxd_SV642_getVideoMode, pxd_SV642_getCtrlVideoMode, pxd_SV642_getCtrlTriggerMode, pxd_SV642_getCtrlFrameRate, and pxd_SV642_getMinMaxExposure is deprecated; new applications should use pxd_SILICONVIDEO_setExposureGainOffset, pxd_SILICONVIDEO_setExposureColorGainOffsets, pxd_SILICONVIDEO_setResolutionAndTiming, pxd_SILICONVIDEO_setVideoAndTriggerMode, pxd_SILICONVIDEO_setCtrlRates, pxd_SILICONVIDEO_getMinMaxExposure, pxd_SILICONVIDEO_getMinMaxCtrlExposure and related functions.

Use of camera specific functions pxd_SV643_setExposureAndGain, pxd_SV643_setExposureAndGainOffset, pxd_SV643_getExposure, pxd_SV643_getGain, pxd_SV643_getOffset, pxd_SV643_setResolutionAndTiming, pxd_SV643_getAoiTop, pxd_SV643_getAoiLeft, pxd_SV643_getPixelClock, pxd_SV643_setVideoAndTriggerMode, pxd_SV643_setCtrlExposureAndRate, pxd_SV643_getVideoMode, pxd_SV643_getCtrlVideoMode, pxd_SV643_getCtrlTriggerMode, pxd_SV643_getCtrlFrameRate, pxd_SV643_getCtrlExposure, pxd_SV643_getMinMaxExposure, and pxd_SV643_getMinMaxCtrlExposure is deprecated; new applications should use pxd_SILICONVIDEO_setExposureGainOffset, pxd_SILICONVIDEO_setExposureColorGainOffsets, pxd_SILICONVIDEO_setResolutionAndTiming, pxd_SILICONVIDEO_setVideoAndTriggerMode, pxd_SILICONVIDEO_setCtrlRates, pxd_SILICONVIDEO_getMinMaxExposure, pxd_SILICONVIDEO_getMinMaxCtrlExposure and related functions.

Use of camera specific functions pxd_SV9M001_setExposureAndGain, pxd_SV9M001_setExposureAndDigitalGain, pxd_SV9M001_getExposure, pxd_SV9M001_getGain, pxd_SV9M001_getDigitalGain, pxd_SV9M001_setResolutionAndTiming, pxd_SV9M001_getAoiTop, pxd_SV9M001_getAoiLeft, pxd_SV9M001_getScanDirection, pxd_SV9M001_getSubsample, pxd_SV9M001_getPixelClock, pxd_SV9M001_setVideoAndTriggerMode, pxd_SV9M001_setCtrlRate, pxd_SV9M001_getVideoMode, pxd_SV9M001_getCtrlVideoMode, pxd_SV9M001_getCtrlTriggerMode, pxd_SV9M001_getCtrlFrameRate, and pxd_SV9M001_getMinMaxExposure is deprecated; new applications should use pxd_SILICONVIDEO_setExposureGainOffset, pxd_SILICONVIDEO_setExposureColorGainOffsets, pxd_SILICONVIDEO_setResolutionAndTiming, pxd_SILICONVIDEO_setVideoAndTriggerMode, pxd_SILICONVIDEO_setCtrlRates, pxd_SILICONVIDEO_getMinMaxExposure and related functions.


 

 

 

14. Application Notes

 

14.1. Conversion of Application Programs from XCOBJ

The following notes describe commonly used functions in the XCOBJ Library, and their SCF replacements in the XCLIB Library.

Several macros are provided to help automate the conversion. These macros can be found in xclibsc.h. They must be explicitly enabled by using:

    #define XCOBJ_TO_XCLIB_MACROS  1
before
    #include "xcliball.h"
in the application program.

The pxd_xcopen is replaced by pxd_PIXCIopen. The first parameter of pxd_xcopen, which could be either a reserved format name or a path name, is replaced by individual parameters for each of these usages.

The pxd_close is replaced by pxd_PIXCIclose.

The pxd_id and pxd_idstr are replaced by pxd_infoDriverId, pxd_infoLibraryId, and pxd_infoIncludeId.

The pxd_xcmodel, pxd_xcmodelcamera, pxd_udim, pxd_imsize, pxd_xdim, pxd_ydim, pxd_ylace, pxd_cdim, pxd_bdim, and pxd_imbufs, are replaced by pxd_infoModel, pxd_infoSubmodel, pxd_infoUnits, pxd_infoMemsize (note that the size in bytes is returned) , pxd_imageXdim, pxd_imageYdim (note that the number of pixels in a column including all fields of the frame buffer is returned), pxd_imageIdim (note that the number of fields is returned), pxd_imageCdim, pxd_imageBdim (note that the number of bits in a single color component is returned), and pxd_imageZdim.

The pxd_udim is replaced by pxd_infoUnits. The pxd_unit and pxd_units, which selected one or more units for use by all following functions until specified otherwise, are replaced by a unitmap parameter added to the actual functions that provide the desired service. For example, instead of using:

    pxd_unit(0x2);      // select unit
    pxd_snap(...);      // operate with selection
the
    pxd_doSnap(0x2, ...);
allows direct selection.

The pxd_iopen, pxd_iopencolor, pxd_ioc, and pxd_ios, are replaced by pxd_readuchar, pxd_writeuchar, pxd_readushort, and pxd_writeushort. An explicit pxd_iopen or pxd_iopencolor followed by a transfer request is not necessary; each of pxd_readuchar, pxd_writeuchar, pxd_readushort, and pxd_writeushort transfers pixels without requiring a preceding open.

The pxd_pixread, pxd_pixwrite, pxd_pixreadRGB, and pxd_pixwriteRGB were always documented to be an inefficient convenience, To dissuade programmers against reading or writing single pixels, they have not been replaced. Of course, the pxd_readuchar, pxd_writeuchar, pxd_readushort, and pxd_writeushort can still used upon single pixels.

The pxd_defimage and pxd_defimagecolor are replaced by pxd_defineImage. The pxd_defimage3 and pxd_defimage3color are replaced by pxd_defineImage3. The XCOBJ suggested against saving the pxd_defimage result, such as:

    struct pximage image;

image = *pxd_defimage();
This practice is still prohibited.

The pxd_vidgenlock, pxd_vidparm, pxd_vidsize, and pxd_vidfield do not have direct replacements within the SCF style functions. Instead, a Video Configuration Format, with suitable options set, can be loaded by pxd_PIXCIopen.

The pxd_chkfault and pxerrnomesg are replaced by pxd_mesgFault and pxd_mesgErrorCode. The pxd_chkstack is obsolete and not replaced.

The pxd_bmpsave, pxd_bmpload, pxd_tgasave, pxd_pcxsave, pxd_pcxload, pxd_tiffsave, and pxd_tiffload are replaced by pxd_saveBmp, pxd_loadBmp, pxd_saveTga, pxd_savePcx, pxd_saveTiff, and pxd_loadTiff.

The pxd_StretchDIBits, pxd_DIBCreate, and pxd_DIBFree are replaced by pxd_renderStretchDIBits, pxd_renderDIBCreate, and pxd_renderDIBFree.

The pxd_DirectVideoInit and pxd_DirectVideoDone are replaced by pxd_renderDirectVideoInit and pxd_renderDirectVideoDone. The pxd_DirectVideo are replaced by pxd_renderDirectVideoUnLive and pxd_renderDirectVideoLive.

The pxd_extin, pxd_extinreset, and pxd_extout are replaced by pxd_getGPIn, pxd_setGPIn, and pxd_setGPOut.

The pxd_vidmux, pxd_contrastbrightness, and pxd_huesaturation used with the PIXCI® SV2, SV3, and SV4 are replaced by pxd_setVidMux, pxd_setContrastBrightness, and pxd_setHueSaturation. The new functions have effect immediately, rather than waiting for the end of a frame, stopping video capture, and restarting.

The pxd_setDalsa01, pxd_setKodak01, pxd_setHitachi01, and pxd_setBasler01 used with the PIXCI® D, D24, D32, and A are replaced by pxd_setExsyncPrin. The new function has effect immediately, rather than waiting for the end of a frame, stopping video capture, and restarting. The new function provides for changing the ''exsync'' and ''prin'' values, typically integration time or line period, but does not provide for changing camera modes; instead, a Video Configuration Format, with suitable options set, can be loaded by pxd_PIXCIopen. Although the pxd_setDalsa01, pxd_setKodak01, pxd_setHitachi01, and pxd_setBasler01 allowed setting bits corresponding to camera modes, they were often misunderstood and misused; as corresponding parameters in the video format also must be changed.

The pxd_snap is replaced by pxd_doSnap. The pxd_vidtime is replaced by pxd_videoFieldCount.

The pxvid_snapbufa and pxvid_gobufa are replaced by pxd_goSnap, pxd_goLive, and pxd_goUnLive. The pxvid_snapbufw and pxvid_gobufw are replaced by using pxd_capturedBuffer, pxd_capturedSysTicks, and/or pxd_capturedFieldCount. However, the pxvid_snapbufw and pxvid_gobufw functions were intended to be used to wait until, or test whether, the previous pxvid_snapbufa and pxvid_gobufa had effect, with the intention that the application could then ''orchestrate'' ''ping-pong'' or sequence capture. In contrast pxd_capturedBuffer, pxd_capturedSysTicks, and/or pxd_capturedFieldCount reports whether and when a new field or frame has been captured; with the intention to track the progress of pxd_goLivePair or pxd_goLiveSeq which initiate a ''ping-pong'' capture, or a sequence capture, respectively, and proceeds without further ''orchestratation'' by the application.

The pxd_video is replaced by pxd_goLive and pxd_goUnLive; although the latter functions always return immediately.

 

14.2. Using a Serial (RS-232) Configurable Camera with the PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4

When used with a PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4 imaging board, the XCLIB library identifies the camera for which the specific model of the PIXCI® imaging board is intended and sets a default Video Format Configuration compatible with that camera's default operating mode. Typically, the camera's default operating mode is for continuous, periodic (i.e free-running) video at maximum resolution. The default Video Format Configuration does not re-configure the camera through the computer's serial RS-232 port or through the Camera Link serial port of the PIXCI® CL1, CL2, CL3SD, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, or EL1DB.[43]

The SILICON VIDEO® cameras used in conjunction with a PIXCI® D2X, ELS2, SI, SI1, SI2, or SI4 imaging board use serial I2C or SPI for camera configuration instead of RS-232 or Camera Link serial, but are handled similarly by software configuration. The SILICON VIDEO® 1281M, 1281C, 1310, 1310C, 2112, 2112C, 5C10, 5M10, 642M, 642C, 643M, 643C, 9C10, 9M001, 9M001C, 9T001C, 10C6, 10M6, WGA-C, and WGA-M are all initialized by the XCLIB library to the manufacturer's suggested default mode.

14.2.1. Initialization of RS-232 or Camera Link Serial Configured Cameras

To use the camera and PIXCI® imaging board in other modes — such as triggered capture with asynchronous reset, binning, or integration — requires that both the camera and the PIXCI® imaging board be reconfigured. The camera's operating mode must be reconfigured through the serial (RS-232 or Camera Link) port; the PIXCI® imaging board must be reconfigured through the XCLIB library.

For some cameras whose features are controlled by Camera Link serial commands, XCAP's Capture - Adjustments provides only basic, generic controls for configuring the PIXCI® imaging board as per the camera's configuration, and does not automatically send serial commands to the camera. For these cameras, the programmer must follow Using a Video Format Configuration Exported by XCAP to configure the PIXCI® imaging board, and must manually format and send serial commands through the RS-232 or Camera Link serial port as per the camera manufacturer's documentation.

For selected cameras whose features are controlled by RS-232, Camera Link serial, I2C serial, or SPI serial commands, XCAP's Capture - Adjustments provides convenient, integrated controls for the camera's programmable features; automatically generating and sending appropriate serial commands as the GUI controls are adjusted. The remainder of this application note discusses how to utilize XCAP's built-in integrated controls to simplify the reconfiguration of the camera when using the XCLIB library.

The XCAP application is used only during program development; it is not needed when the program being developed is run.

First, launch a compatible version of XCAP[44] and use its GUI to configure the camera's operating mode and the PIXCI® imaging board to the desired configuration. After verifying the proper configuration (such as correct triggering with externally provided signals, or sufficient light sensitivity relative to binning and integration options):

  1. Export the PIXCI® imaging board Video Format Configuration parameters to a file with:
        PIXCI®
        PIXCI® Export Video Setup
    

  2. Export the camera's current operating mode's serial (RS-232 or Camera Link) commands to a file using the:
        Export Commands
    
    button in the camera's ''Capture & Adjust'' dialog box. Each camera's ''Capture & Adjust'' dialog differs, but typically: a) The dialog has a left half devoted to the PIXCI® imaging board and a right half devoted to the camera's serial (RS-232 or Camera Link) controlled parameters, b) The ''Export Commands'' button is typically found under the ''Opt'' or ''Port'' tab of the right half of the dialog.
XCAP can now be closed.

Second, in the application program being developed, open the XCLIB library, specifying the previously saved Video Format Configuration file as the third parameter of pxd_PIXCIopen. This configures the PIXCI® imaging board appropriately.

Third, in the application program being developed, send the contents of the exported serial (RS-232) command file through the appropriate serial (RS-232) port. This configures the camera's operating mode appropriately and consistently with the PIXCI® imaging board configuration. An example method follows for cameras connected via an RS-232 port under Windows:[45]:

    #include <windows.h>
    #include <stdio.h>

FILE *fp; HANDLE fd; DCB dcb; char *name = "COM1"; // or "COM2", "COM3", etc. int i, n, l; // // Open access to COM port. // fd = CreateFile(name, GENERIC_READ|GENERIC_WRITE, OF_SHARE_COMPAT, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); if (fd == INVALID_HANDLE_VALUE) exit(1); // can't open COM port - produce suitable error message memset(&dcb, 0, sizeof(dcb)); if (!GetCommState(fd, &dcb)) { CloseHandle(fd); exit(1); // can't get COM port state - produce suitable error message } dcb.fBinary = TRUE; dcb.fDtrControl = DTR_CONTROL_ENABLE; dcb.fDsrSensitivity = FALSE; dcb.fNull = FALSE; dcb.fRtsControl = RTS_CONTROL_ENABLE; dcb.BaudRate = 9600; // replace with camera's baud rate dcb.ByteSize = 8; // assume camera with 8 bits per word dcb.Parity = 0; // assume no parity used dcb.StopBits = 2; // camera may spec fewer stop bits, more doesn't hurt! dcb.fOutX = dcb.fInX = 0; // assume camera w/out RS-232 flow control dcb.fOutxCtsFlow = dcb.fOutxDsrFlow = FALSE; SetCommState(fd, &dcb); SetupComm(fd, 4096, 4096); // // Open exported file with camera's RS-232 data stream. // fp = fopen("camera.dat", "rb"); if (!fp) { CloseHandle(fd); exit(1); // can't find file - produce suitable error message } // // Send each command from file through COM port. // For most cameras, we should wait until the camera // has finished processing one command before sending // the next. A sophisticated method would be to wait for // the camera's response to each command - and even // to check whether the response indicates an error. // For simplicity, and because this code is used only // during initialization - so overall elapsed time should // not be critical - we simply pause after each command. // for (n = 0; (i = fgetc(fp)) != EOF; ) { DWORD w = 0; uchar buf[1];
// // Send byte of command. // buf[0] = i; WriteFile(fd, buf, 1, &w, NULL);
// // Is the last byte sent the end of a command? // The test is camera specific! // #if 1 // for DVC, older Basler, Hamamatsu, Uniq if (i == '\r') // Dalsa Sleep(1000); #elif 0 if (i == '\n') // Imperx Lynx Sleep(1000); #elif 0 // for Pulnix if (i == '\x03') Sleep(1000); #elif 0 // for newer Basler, which ends w. 0x03 if (n++ == 2) // but may also have embedded 0x03, l = (i&0x7F)+5; // utilize the command's length count if (n > 2 && n == l) { // to determine the end of each command Sleep(1000); n = 0; } #elif 0 // for Hitachi using fixed length size commands if ((++n % 18) == 0) Sleep(1000); #elif 0 // for Kodak/Roper MASD if (i == '\n') // Some ES 4.0 commands may Sleep(1000); // require delay of several seconds! #endif } // // All done. Clean up. // fclose(fp); CloseHandle(fd);

Alternately, for cameras connected via Camera Link, send the contents of the exported serial command file through the PIXCI® CL1, CL2, CL3SD, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, or EL1DB Camera Link serial port:

    FILE    *fp;
    int     i, n, l;
    //
    // Configure serial port for the Camera Link standard
    // of 9600 baud, 8 bits, 1 stop bit, no parity.
    // More recent versions of the Camera Link spec
    // allow for alternate baud rates; set the rate to match the camera!
    pxd_serialConfigure(0x01, 0, 9600, 8, 0, 1, 0, 0, 0);
    //
    // Open exported file with camera's RS-232 data stream.
    //
    fp = fopen("camera.dat", "rb");
    if (!fp)
        exit(1);    // can't find file - produce suitable error message
    //
    // Send each command from file through serial port.
    //
    for (n = 0; (i = fgetc(fp)) != EOF; ) {
        char buf[1];
        buf[0] = i;
        pxd_serialWrite(0x01, 0, buf, 1);

// // Is the last byte sent the end of a command? // The test is camera specific! // #if 1 // for DVC, older Basler, Hamamatsu, Uniq if (i == '\r') // Dalsa Sleep(1000); #elif 0 if (i == '\n') // Imperx Lynx Sleep(1000); #elif 0 // for Pulnix if (i == '\x03') Sleep(1000); #elif 0 // for newer Basler, which ends w. 0x03 if (n++ == 2) // but may also have embedded 0x03, l = (i&0x7F)+5; // utilize the command's length count if (n > 2 && n == l) { // to determine the end of each command Sleep(1000); n = 0; } #elif 0 // for Hitachi using fixed length size commands if ((++n % 18) == 0) Sleep(1000); #endif } // // All done. Clean up. // fclose(fp);

14.2.2. Initialization of Camera Link Serial, I2C, or SPI Configured Cameras

For selected Camera Link cameras and for all SILICON VIDEO® cameras, the Video Format Configuration files saved by XCAP include the serial commands needed to restore the camera's operating mode. The XCLIB library automatically loads the serial commands contained in the Video Format Configuration file.

First, launch a compatible version of XCAP[46] and use its GUI to configure the camera's operating mode and the PIXCI® imaging board to the desired configuration. After verifying the proper configuration (such as correct triggering with externally provided signals, or sufficient light sensitivity relative to binning and integration options), export the PIXCI® imaging board Video Format Configuration parameters to a file with:

    PIXCI®
    PIXCI® Export Video Setup
XCAP can now be closed.

Second, in the application program being developed, open the XCLIB library, specifying the previously saved Video Format Configuration file as the third parameter of pxd_PIXCIopen. This configures the PIXCI® imaging board appropriately.

This improved support is currently provided for selected Adimec, Allied Vision Technologies (AVT), Atmel, Basler, Baumer, CIS, Cohu, Dalsa, DVC, EG&G Reticon, E2v, Hitachi, Illunis, Imperx, Jai, PerkinElmer, Point Grey, Princeton Instruments, Pulnix, Raptor Photonics, Rice Camera Technologies, Redlake, Salvador Imaging, Sentech, Sensors Unlimited, Silicon Imaging, Sony, SVS Vistek, Teli, VDS-Vosskuhler, Vieworks, and Uniq Camera Link cameras, and may be added (or have been added) for other Camera Link cameras post-publication of this application note.[47]

This improved support is not provided for Camera Link cameras whose manufacturer only provides a library and API but does not document the underlying serial commands.

To determine whether this integrated support is available for a specific Camera Link camera, in XCAP:

    PIXCI® (in Main Window)
    PIXCI® Open/Close
    Close (if open)
    Camera & Format
    Open w. Default Video Setup
    OK
    Open
    PIXCI® (in Main Window)
    PIXCI® Export Video Setup
If the
    Include Camera Link Serial Commands
checkbox is active (i.e. selectable), then this integrated support of serial commands by the XCLIB library is available for the current camera.

For SILICON VIDEO® cameras, the

    Include Camera Link Serial Commands
or
    Include I2C Commands
or
    Include SPI Commands
will be active, indicating integrated support of Camera Link serial, I2C serial, or SPI serial, commands by the XCLIB library.

14.2.3. Adjustments to RS-232 or Camera Link Serial Configured Cameras

In addition to the initialization described above, the application program may wish to adjust the camera - such as the gain, exposure, black level - via serial commands during program execution. These types of adjustments do not affect the PIXCI® imaging board configuration. In contrast, adjusting the camera's trigger mode, binning, bit-depth, or area of interest features do reflect upon the PIXCI® imaging board's configuration, and a new set of Video Format Configuration parameters should be saved via XCAP.

Adjusting the camera's gain, exposure, black level, and similar parameters could be done by using XCAP's ''Export Commands'' feature for each unique combination of gain, exposure, etc., if the application only needs a relatively small number of adjustment combinations.

Alternately, adjusting the camera's gain, exposure, black level, and similar parameters requires familiarity with the camera's unique serial commands, as described in the camera's manufacturer's documentation. XCAP can assist in learning about a specific camera's serial commands. By activating the RS-232 Log (or Serial Log), typically found under the ''Port'' tab, XCAP will log and display each serial command sent as a result of the modifying the camera's GUI controls. The programmer can read these as examples of the necessary commands to be sent via the computer's COM port for RS-232 or via pxd_serialWrite for Camera Link, supplementing the camera manufacturer's documentation and examples.

14.2.4. Adjustments to I2C or SPI Configured Cameras

The XCLIB library includes SILICON VIDEO® camera specific functions for adjustment of gain, black level, exposure, etc.; the programmer need not be concerned with I2C or SPI commands. Some of the more obscure settings can only be accessed via Structured Style Interface; users of the SCF Style Interface can utilize use of a Video Format Configuration file exported from XCAP, as described above, to initialize all of the camera's parameters.

 

14.3. Using a Video Format Configuration Exported by XCAP

The Video Format Configuration is a collection of dozens of parameters that defines the video format (i.e. whether NTSC, RS-170, PAL, CCIR, or other video standard for applicable imaging boards, or camera manufacturer and model for other imaging boards), the resolution (i.e. capturing more or fewer pixels per line or column), and other settings related to the imaging board's hardware.

The XCLIB library provides a suitable default Video Format Configuration for each PIXCI® imaging board, model, and submodel.

The easiest and suggested method of creating an alternate Video Format Configuration is to use XCAP. XCAP uses an identical and compatible[48] Video Format Configuration, although XCAP uses the term ''Video Setup''. In XCAP, use:

    PIXCI®
    PIXCI® Open/Close
    Close
    Camera & Format
    .. select alternate camera or format
    OK
    Open
to select an alternate camera or format from XCAP's predefined selections. Or, use:
    Capture (in PIXCI® Image Viewer)
    Adjustments
to open the Capture & Adjust dialog (if not already open), and select camera and format options within the Capture & Adjust dialog. Or, upon advice of EPIX® Technical Support, use:
    PIXCI® Video Setup
    .. adjust video configuration ..
    OK
Regardless of method, export the video setup with:
    PIXCI®
    PIXCI® Export Video Setup
After running XCAP, simply specify the path name of the saved video setup file as the third parameter to pxd_PIXCIopen (with the second parameter set to NULL) or as the fifth parameter to xclib_open (with the fourth parameter set to NULL) to configure the XCLIB library to the same Video Format Configuration.

However, for application programs which are to be distributed, the saved video setup file must be distributed as well. This can be advantageous - substituting a different video setup file may allow the application to work with other cameras or in other camera modes without recompilation - or disadvantageous when the video setup file is lost or accidentally modified.

Alternatively, the Video Format Configuration can be integrated into the application, preventing loss of, or accidental changes to, a file required at run time, as well as providing slightly quicker switching between different Video Format Configurations. The saved video setup file is readable text with the syntax of several ''C'' structure initializers; it can be directly compiled by simply including it within the application's C/C++ program.

If using the SCF Style Interface, the pxd_videoFormatAsIncluded macro can be used as:

    {
        #include "format.fmt"               // a saved video setup file
        pxd_videoFormatAsIncludedInit(0);
        pxd_videoFormatAsIncluded(0);     // configure as per the above
    }
to configure the XCLIB library as per the included video setup file. Of course, the contents of the ''format.fmt'' file could instead be copied and pasted into the application instead of being included; both methods result in the Video Format Configuration being integrated into the application.[49]

The Video Format Configuration files are portable among the various 32 bit operating systems, and among the various 64 bit operating systems. As of 27-Apr-2011, the Video Format Configuration files are also portable between 32 and 64 bit operating systems.

 

14.4. Capture Directly into Memory Space of Other Devices

The architecture of the PIXCI® A, A310, CL1, CL2, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI4, SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, and SV7 imaging boards allows capturing image data via PCI Bus Mastering. Typically, image data is transferred into the reserved image frame buffer memory — a pre-allocated pool of host memory. However, the image data can instead be transferred to any block of consecutive addresses in PCI address space.

The pxvidphys structure completely specifies the capture target address space (see pxlibvs.h).

When capturing into image frame buffer memory, the XCLIB library provides a simplified means of specifying the capture target address space — the image frame buffer number. Based on the memory size required for each image buffer and on the total size of image frame buffer memory, the XCLIB library partitions the image frame buffer memory into one or more image frame buffers. A function such as ::setSnapBuf specifies the capture target as a single, simple, image frame buffer number; the XCLIB library then translates the specified frame buffer number to a memory specification and fills in the pxvidphys appropriately.

By explicitly filling the pxvidphys rather than using an image frame buffer number, and by using the ::setLivePhys instead of the ::setLiveBuf service, images can be captured to targets in PCI address space other than the image frame buffer memory.

If pxvidphys.upatita=0 the addresses are interpreted as being relative to frame buffer memory. Alternately, addresses may also be interpreted as being in user space, or as being bus physical; the pxvidphys.upatita for these interpretations must be set by using ::signStateCopy to ''sign'' the pxvidphys instance after all other fields have been set.[50]

When using an image frame buffer number, the pxvidphys.buffer, pxvidphys.stateid, and pxvidphys.tracker, are automatically set to the buffer number, the video state id, and an arbitrary tracker number provided by ::setLiveBuf. When using ::setLivePhys these are arbitrary values; the values provided are later reported by ::getLiveStatus.

The use and constraints of the pxvidphys.startadrs, pxvidphys.endadrs, pxvidphys.linelength, pxvidphys.linestride, are dependent on the specific imaging board; see examples below.

If multiple image boards are in use, the

    xcdev.setLiveBuf(0x03, ..., 1);
which commands imaging boards one and two to both begin capturing into frame buffer number 1, does not cause conflict or overwriting of image data; each board is assigned its own, unique, buffer number 1. When using ::setLivePhys, each selected imaging board is provided with its own pxvidphys. Thus, ::setLivePhys allows for an array of pxvidphys specifications, one per selected imaging board.

14.4.1. PIXCI® SV4, SV5, SV5A, SV5B, SV5L, SV7 and DirectDraw

The following example is an extract of pxd_renderDirectVideoLive, and assumes familiarity with DirectDraw. For the sake of brevity, the example assumes that the PXMODE_DIGI video state has already been defined with a pixel format compatible to the graphics display (S/VGA) secondary surface[51] (such as UYVY rather than RGB), that the capture resolution has been set to match the display window's size, and that the capture bit depth has been set to 8 bits per color component

    DDSURFACEDESC       surface2;   // a DirectDraw struct
    pxvidphys_s         vidphys;
    xclib_DeclareVidStateStructs(vidstate);
    //
    // Create different state, copy of PXMODE_DIGI
    //
    xclib_InitVidStateStructs(vidstate);
    xclib.pxlib.getState(&xclib.pxlib, 0, PXMODE_DIGI, &vidstate);
    //
    // Setup to send video to overlay plane.
    // We assume the 'surface2' has already been specified and
    // acquired from DirectDraw.
    //
    memset(&vidphys, 0, siz(vidphys));
    vidphys.ddch.mos     = PXMOS_VIDPHYS;
    vidphys.ddch.len     = siz(pxvidphys_s);
    vidphys.bufxdim      = vidstate.vidres->x.datsamples;
    vidphys.bufydim      = vidstate.vidres->y.datsamples;
    vidphys.bufidim      = vidstate.vidres->datfields;
    vidphys.bufadrs      = (uint32)surface2.lpSurface;
    vidphys.startadrs[0][0]  = (uint32)surface2.lpSurface;
    vidphys.startadrs[1][0]  = (uint32)surface2.lpSurface;
    vidphys.linelength[0][0] = vidstate.vidres->x.datsamples*2;   // assumes YUV!
    vidphys.linelength[1][0] = vidstate.vidres->x.datsamples*2;   // assumes YUV!
    vidphys.linestride[0][0] = surface2.lPitch-vidphys.linelength[0][0];
    vidphys.linestride[1][0] = surface2.lPitch-vidphys.linelength[1][0];
    if (vidstate.vidres->datfields == 2) {
        vidphys.startadrs[0][0]  += surface2.lPitch;
        vidphys.linestride[0][0] += surface2.lPitch;
        vidphys.linestride[1][0] += surface2.lPitch;
    }
    vidphys.buffer    = 0;  // optional, so capture of this is never confused with a real buffer
    //
    // Sign the vidphys. Addresses provided by
    // DirectDraw are in user space, not physical!
    //
    vidstate.vidphys = &vidphys;
    if (xclib.xclib.signStateCopy(&xclib.xclib, 0, 0, &vidstate, 'u', 's') < 0)
        return; // error!
    //
    // If the new state changed the resolution or the pixel format, we must ..
    //
    if (xclib.xcdev.setVideoConfig(&xclib.xcdev, unitmap, 0, 0, &vidstate, NULL))
        return; // error!
    //
    // Start live video
    //
    if (xclib.xcdev.setLivePhys(&xclib.xcdev, unitmap, 0, 0, &vidstate, NULL, &vidphys))
        return; // error!
This example is not intended to show how to specify and acquire a DirectDraw surface, how to overlay the DirectDraw secondary surface onto the primary surface, and how to optionally activate chroma keying; these topics are described in the DirectDraw documentation.

14.4.2. PIXCI® and StreamStor

The following example is an extract of the XCAP ''Video to StreamStor'' feature; it assumes familiarity with the StreamStor XLR API.

    HANDLE      hXLR;
    xclib_DeclareVidStateStructs(vidstate);
    //
    // Get video state in use.
    //
    xclib_InitVidStateStructs(vidstate);
    xclib.pxlib.getState(&xclib.pxlib, 0, PXMODE_DIGI, &vidstate);
    //
    // Build the pxvidphys.
    //
    memset(&vidphys, 0, siz(vidphys));
    vidphys.ddch.mos = PXMOS_VIDPHYS;
    vidphys.ddch.len = siz(pxvidphys_s);
    vidphys.startadrs[0][0] = XLRGetBaseAddr(hXLR);
    vidphys.startadrs[1][0] = XLRGetBaseAddr(hXLR);
    //
    // Sign the vidphys. Addresses provided
    // by XLR are physical, not user space!
    //
    vidstate.vidphys = &vidphys;
    if (xclib.xclib.signStateCopy(&xclib.xclib, 0, 0, &vidstate, 'p', 's') < 0)
        return; // error!
    //
    // Start XLR recording then start live video.
    //
    XLRRecord(hXLR, FALSE, 1);
    if (xclib.xcdev.setLivePhys(&xclib.xcdev, unitmap, 0, 0, &vidstate, NULL, &vidphys))
        return; // error!

 

14.5. Adjusting White Balance of a Bayer Output Camera with the PIXCI® Imaging Board

When a Bayer output camera is used with a PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4 imaging board, the XCLIB library performs Bayer to RGB conversion and white balancing in software. As for all color cameras, white balancing is subject to the current illuminate's color spectrum, and should be adjusted for different illumination. A simple method of white balancing follows.

  1. Capture an image of a white or grey target:
        pxd_doSnap(1, 1, 0);
    

  2. Obtain true average red, green, and blue values of the captured grey target image. Thus, we turn off software white balancing before obtaining average values:
        unsigned int reference[3] = {0,0,0};
        unsigned int target[3]    = {0,0,0};
        pxd_setImageBrightBalance(1, reference, target, 0.00);
    

  3. Obtain average pixel values. This is slightly simpler if the PXIPL Image Processing Library is available:
        double  masses[] = {0, 0, 0};
        double  xcenter, ycenter;
    
    pxip8_masscenter(NULL,pxd_defineImage(1, 1, 0, 0, -1, -1, "RofRGB"), &masses[0], &xcenter, &ycenter); pxip8_masscenter(NULL,pxd_defineImage(1, 1, 0, 0, -1, -1, "GofRGB"), &masses[1], &xcenter, &ycenter); pxip8_masscenter(NULL,pxd_defineImage(1, 1, 0, 0, -1, -1, "BofRGB"), &masses[2], &xcenter, &ycenter); reference[0] = masses[0]/(double)pxd_imageXdim()*pxd_imageYdim(); reference[1] = masses[1]/(double)pxd_imageXdim()*pxd_imageYdim(); reference[2] = masses[2]/(double)pxd_imageXdim()*pxd_imageYdim();
    Or can be done by directly reading pixel values:
        double  masses[] = {0, 0, 0};
        ushort  pixels[9*9];
        int     midx, midy, i;
    
    midx = pxd_imageXdim()/2; midy = pxd_imageYdim()/2; pxd_readushort(1,1,midx-9/2,midy-9/2,midx+1+9/2,midy+1+9/2,pixels,9*9,"RofRGB"); for (i = 0; i < 9*9; i++) masses[0] += pixels[i]; pxd_readushort(1,1,midx-9/2,midy-9/2,midx+1+9/2,midy+1+9/2,pixels,9*9,"GofRGB"); for (i = 0; i < 9*9; i++) masses[1] += pixels[i]; pxd_readushort(1,1,midx-9/2,midy-9/2,midx+1+9/2,midy+1+9/2,pixels,9*9,"BofRGB"); for (i = 0; i < 9*9; i++) masses[2] += pixels[i]; reference[0] = masses[0]/(9*9); reference[1] = masses[1]/(9*9); reference[2] = masses[2]/(9*9);
    Whether it is best to obtain the average values from the whole image or an AOI is debatable; the former example does the entire image, the later does a small 9×9 AOI; either method can be changed to any size AOI.

  4. Determine suitable target pixel values. This is often the lowest, highest, or mean of the reference values - but should typically be the same for all three colors:
        target[0] = target[1]
                  = target[2]
                  = max(max(reference[0], reference[1]), reference[2]);
    
    And invoke:
        pxd_setImageBrightBalance(1, reference, target, 0.60);
    
    using the preferred gamma correction coefficient to apply the new coefficients to images accessed via pxd_defineImage.

 

14.6. Processing Images from a Bayer Output Camera with the PIXCI® CL, D, E, or SI Series

When a Bayer output camera is used with a PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, E1, E1DB, E4, E4DB, E8, E8DB, EB1, EB1-PoCL, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4 imaging board, the XCLIB library performs Bayer to RGB conversion and white balancing in software. The RGB conversion and white balancing is done automatically, and only on demand. Thus, capture may be done with any of the standard pxd_doSnap, pxd_goSnap, pxd_goLive or similar functions, and corrected RGB (or BGR) pixel values may be read via any of the standard pxd_readuchar, pxd_readushort, pxd_defineImage, or similar functions. Conversion to RGB is automatic and, for most applications, completely transparent.

For the sake of overall efficiency, the image frame buffer's contents are not converted en masse and saved internally as RGB values. Rather, the frame buffer remains in Bayer format and the Bayer values are converted only if, and when, they are requested. A side effect is that re-reading the same pixels from the same buffer requires repeating the Bayer conversion.

Also, any pixel values written into the frame buffer, such as by pxd_writeuchar, pxd_writeushort, pxd_defineImage or similar functions, requires converting and compressing the RGB (or BGR) values into Bayer format; a process which, when inverted, may not yield the exact, original, pixel values. The effect is particularly noticeable when the processing algorithm reads, processes, and writes line N before doing the same for line N+1; the modified values written to line N will affect the values read from line N+1 (especially the green component values).

Applications which need to re-read the same pixel values repeatedly can benefit from copying the RGB values from the Bayer frame buffer into a (true) RGB buffer once, and re-reading values from the copy. Applications which need to perform image modifications will also benefit from copy RGB values from the Bayer frame buffer into a (true) RGB buffer once, and thereafter processing the copy.

A true RGB buffer that can be accessed by PXIPL functions, can be created using pximage_memmalloc or pximage_memmalloc2. Or, an existent array or malloc'ed memory can be accessed by PXIPL functions by creating a pximage descriptor with pximage_memory. These are similar, the former allocates space for the pixels and creates the pximage descriptor, the latter assumes use of previously allocated memory and creates the pximage descriptor.

For example:

    //
    // Create the RGB image buffer and pximage descriptor
    //
    void    *imagemem = NULL;
    struct  pximage image;
    struct  pxy dim;
    int     r;

dim.x = pxd_imageXdim(); dim.y = pxd_imageYdim(); r = pximage_memmalloc(&image, &imagemem, &dim, pxd_imageBdim()<=8?PXDATUCHAR:PXDATUSHORT, pxd_imageBdim(), 3, PXHINTRGB); if (r < 0) ; // announce error
// // Copy image from image frame buffer 1, converting to RGB // and saving in the 'true' RGB image buffer. // r = pxip8_copy(NULL, pxd_defineImage(0x1,1,0,0,-1,-1,"RGB"), &image); // // We can now perform operations upon true RGB values, // writing RGB results. // r = pxip8_pixneg(NULL, &image, &image); ... ... // // When done, the memory allocated for the RGB image buffer // must be freed. // pximage_memfree(&image, &imagemem);
or the slightly simpler and easier to use from non-C/C++ environments:
    //
    // Create the RGB image buffer and pximage descriptor
    //
    struct  pximage *ip;
    int     r;

ip = pximage_memmalloc2(NULL, pxd_imageBdim()<=8?PXDATUCHAR:PXDATUSHORT, pxd_imageBdim(), 3, PXHINTRGB, pxd_imageXdim(), pxd_imageYdim(), 0, 0, 0); if (ip == NULL) ; // announce error
// // Copy image from frame buffer 1, converting to RGB // and saving in the 'true' RGB image buffer. // r = pxip8_copy(NULL, pxd_defineImage(0x1,1,0,0,-1,-1,"RGB"), ip); // // We can now perform operations upon true RGB values, // writing RGB results. // r = pxip8_pixneg(NULL, ip, ip); ... ... // // When done, the memory allocated for the RGB image buffer // must be freed. // pximage_memfree2(ip, NULL);

 

 

 

15. Release Notes



RELEASE NOTES: XCLIB — Version 3.0, V3.7

  1. Version 3.0 released. Adds support for Windows Vista, Windows XP(x64), and Linux 64 Bit.
    Under Linux, direct mapping of frame buffer memory into the application memory space is now supported under 2.6 kernels.
    Applications using SCF style functions need not recompile.
    Applications using non-SCF functions or PXIPL functions should recompile. Applications using ::bufferSaveStream or ::bufferLoadStream must add two parameters of 0. A new ::iosparse service is added. (28-Feb-2007)

  2. Modified Feature: The '''video''time' return value of pxd_videoFieldCount has been changed from ulong to pxvbtime_t for consistent sizing under various 64 bit compilers. This should not affect existing 16 or 32 bit programs, and the old and new types are the same size integers, albeit with a different type name. (28-Feb-2007).

  3. Fixed Feature: When using more than one PIXCI®, some errors such as PCI FIFO overflow, on units other than the first may not be reported via pxd_mesgFault, pxd_mesgFaultText, ::faultMessageBox, etc. (16-Mar-2007).

  4. Fixed Feature: Under Vista, the pxd_eventFieldCreate, pxd_eventCapturedFieldCreate, and pxd_eventGPTriggerCreate, may fail. (??-???-2007)

  5. Fixed Feature: XCAP for Linux 64 bit shows a ''Usage error or fault'' when trying to open the PIXCI® imaging board. In XCLIB for Linux 64 bit, the ::getDevParms suffers a similar fate, but the SCF functions are not affected as they don't use ::getDevParms. (30-Mar-2007)

  6. Added Feature: Functions pxd_SV9M001_setExposureAndGain, pxd_SV9M001_setResolutionAndTiming and other related functions now provide camera specific controls for the SILICON VIDEO® 5C10 and 5M10 camera. (18-Apr-2007).

  7. Fixed Feature: Per-pixel offset (only) corrections/normalizations did not work correctly under Linux, and under 64 bit Windows. Per-pixel gain corrections did not work correctly in configurations which did map map frame buffer memory into application space. (27-May-2007)

  8. Fixed Feature: For the SILICON VIDEO® 5C10 and 5M10 cameras, changing the exposure twice within one field may cause the video to stop until the camera head is reset. (31-May-2007).

  9. Fixed Feature: Under 64 bit Windows, with frame buffer memory mapped ''on-demand'', when using a PIXCI® SV4, SV5 or any Camera Link compatible board, and when using more than one imaging board (or more than one functional unit), all but the first imaging board may fail to open and no description of the error is provided via pxd_mesgFault(). (18-Jun-2007).

  10. Fixed Feature: Under Windows Vista, the pxd_eventFieldCreate, pxd_eventCapturedFieldCreate, and pxd_eventGPTriggerCreate may fail, returning NULL. (20-Jun-2007).

  11. Fixed Feature: The PIXCI® driver released approximately 11 July 2007 did not operate properly with the SV9M001, SV9M001C, SV9M001. (24-Jul-2007)

  12. Fixed Feature: Depending on multi-processor configuration and speed, the second functional half of the PIXCI® EL1DB, E1DB, E4DB may drop, garble, or duplicate serial characters. (02-Aug-2007)

  13. Fixed Feature: The PIXCI® CL3SD may intermittently report ''DMA Transfer Error'' on newer, faster computers, or where the PCI bus is inherently slow or heavily loaded. (04-Aug-2007)

  14. Improved Feature: XCLIB now supports the PIXCI® SI4 PCI Express imaging boards (Beta). (21-Dec-2007)

  15. Modified Feature: The ''Share Unit'' driver configuration parameter now defaults to ''share'' under Windows NT, 2000, XP, XP(x64), Server 2003, and Vista, to allow easier use of the clserEPX.DLL along with XCAP's Generic Camera Link controls. (26-Dec-2007)

  16. Improved Feature: The PIXCI® SV5B is now supported distinct from PIXCI® SV5; the default SV5B video setup is NTSC, not the SV5's NTSC/YC. (20-Feb-2008).

  17. Fixed Feature: The compilation instructions in XCLIBEXC.CPP has typo's referring to XCLIBEX2.CPP and XCLIBEX2.RC instead of XCLIBEXC.CPP and XCLIBEXC.RC, respectively. (04-Mar-2008)

  18. Fixed Feature: For SILICON VIDEO® 9T001, 5C10, and 5M10 cameras, if XCAP is configured for ''Long Exposure'' and a format file exported to XCLIB, the XCLIB's configuration will not be set for ''Long Exposure''. (04-Mar-2008)

  19. Added Feature: Adds support for Windows Vista(x64) with Service Pack 1 or later; use with Vista(x64) prior to SP1 is not recommended. (13-Apr-2008)

  20. New Feature: The pxd_buffersSysTicks2 returns the 64 bit system time of a buffer's capture, extending the existing pxd_buffersSysTicks which only returns the lower 32 bits. (11-Jul-2007)

  21. Fixed Feature: For some PIXCI® SI cards, after PC power up, the card must be opened twice: the first open fails, the second (and following) opens succeed. (17-Jul-2007)

  22. Modified Feature: Controlled mode for the SILICON VIDEO® 5C10/5M10 has been modified and improved to use the chip's ''GRR Snapshot'' mode; providing common start-of-exposure for all lines instead of rolling start-of-exposure. (The sensor still uses a rolling shutter, thus exposure time of lines differs. Use of a strobe light is expected).

    The SILICON VIDEO® 5C10/5M10 does not support horizontal subsampling by a factor of 8; software has been changed to disallow such a choice. (29-Aug-2007)

  23. Modified Feature: The default frame buffer size under Windows NT, 2000, XP, Server 2003, and Vista has been increased to 32 MByte. (01-Sep-2007)

  24. Modified Feature: Controlled mode for the SILICON VIDEO® 9T001 has been modified and improved to use the chip's ''Global'' mode; providing common start-of-exposure for all lines instead of rolling start-of-exposure. (The sensor still uses a rolling shutter, thus exposure time of lines differs. Use of a strobe light is expected). (07-Nov-2007)

  25. Improved Feature: For PIXCI® E1DB, EL1DB, E4DB, and PIXCI® SI4 imaging boards, under Windows 2000, XP, XP(x64), Server 2003, Vista, Linux 32 Bit and Linux 64 Bit, it is no longer required that the first functional unit be opened before (or together with) latter functional units of the same physical board. (14-Jan-2008)

  26. Modified Feature: For Windows 95, 98, ME, 2000, XP, Server 2003, XP(x64), and Vista the driver installation .inf file no longer sets default driver configuration parameters into the registry (except for the PIXCI® CL3SD) instead allowing the driver to set defaults internally. This avoids resetting the user's altered driver configuration parameters should a second PIXCI® card be installed later, or the original card moved from slot to slot. (24-Jan-2008)

  27. Fixed Feature: For the SILICON VIDEO® 5C10 and 5M10: after switching from controlled mode to free-run, the frame rate may stay at 0 until the pixel clock frequency is changed. When switching to controlled mode and single shot, the first trigger may not generate an exposure and image readout. (11-Mar-2008)

  28. Fixed Feature: Under Windows 2000, XP, and Vista, on some (newer?) motherboards, when using Map Frame Buffer on demand in Sys and not using Map Frame Buffer Direct into App after the PIXCI imaging board has been successfully opened and used and closed several times, an ''Unable to map image memory! (DDK MmMapIoSpace)'' may be reported; the error is cleared by rebooting Windows. (27-Mar-2008)

  29. Fixed Feature: For the SILICON VIDEO® 5C10 and 5M10: On some camera heads with the gain set to the default of 0 dB, the image is noisy and does not saturate. (25-Apr-2008)

  30. Improved Feature: The SCF functions now support use of multiple imaging boards with different resolution and/or camera configuration (previously, multiple imaging boards with identical configuration was supported). The feature is activated by importing a video setup file created by XCAP in ''Use Individual Formats & Controls'' mode. The SCF functions are still limited to use of identical imaging boards; in some cases multiple boards of the model but different revision level may also be allowed. (01-Jun-2008)

  31. Improved Feature: The new XCLIBEXC.TXT provides a SILICON VIDEO® specific example for use with VB.NET. (13-Jun-2008)

  32. Improved Feature: For the SILICON VIDEO® 5C10 and 5M10: Previously, the camera exposure was set in multiples of line periods; the error (difference between exposure requested and exposure implemented) could be up to one half a line period. Exposure control is now improved, and for small AOI's (less than half maximum width) the exposure error is typically a few pixel clock periods, but up to (approximately) one quarter of a line period for larger AOI's. (23-Jun-2008)

  33. New Feature: Now has partial and beta-level support for new SILICON VIDEO® 9C10 camera. (01-Jul-2008)

  34. Improved Feature: For 64 bit Windows and 64 bit Linux: new driver configuration options allow specifying that frame buffer memory should be allocated under the 4 GB address. This allows using 32 bit PCI cards even on systems with more than 4 GB of memory. (09-Jul-2008)

  35. Fixed Feature: The pxd_saveTiff and ::imageSaveTiff may fail when used with RGB+Pad or BGR+Pad format cameras with forceful frame buffer allocation, or with non-forceful allocation that isn't mapped into the application's space. (11-Jul-2008)

  36. New Feature: For PIXCI® CL2, E1 and newer imaging boards supporting Camera Link, but not for the older PIXCI® CL1 and CL3SD, new functions pxd_setCameraLinkCCOut and pxd_getCameraLinkCCOut allows setting the value of the Camera Link CC output lines, for those CC lines which are not otherwise in use for video control. (16-Jul-2008)

  37. New Feature: XCLIB now supports the PIXCI® ECB1 ExpressCard/54 imaging board. (18-Aug-2008)

  38. Improved Feature: XCLIB now supports bit packed pixels in conjunction with per pixel normalization. (22-Sep-2008)

  39. New Feature: XCLIB now supports the PIXCI® SI4 Rev. 2 imaging board. Use of an older XCLIB and/or driver with a PIXCI® SI4 Rev. 2 card will only work if a pixel clock frequency of 48 MHz is chosen. (07-Oct-2008)

  40. Fixed Feature: On PIXCI® CL1 imaging boards, a PCI FIFO Overflow error causes serial communication to halt until video capture is restarted, or the serial port disabled & renabled. (27-Oct-2008)

  41. New Feature: XCLIB now supports the PIXCI® EB1 imaging board. (18-Nov-2008)

  42. New Feature: Now supports the SILICON VIDEO® 9C10 camera in free-run and controlled global modes. (03-Dec-2008)

  43. Fixed Feature: On some SILICON VIDEO® 5M10 or 5C10 cameras heads, when the pixel clock frequency is changed and the gain is set to 0, pixel values will be noisy and limited to less than 255/4095 until the gain is changed at least once. (09-Jan-2009)

  44. New Feature: XCLIB now supports the PIXCI® EB1-PoCL imaging board. (11-Feb-2009)

  45. Fixed Feature: The pxd_doSnap would occasionally return 0 (success) when capture had, in fact, been terminated due to, for example, PCI FIFO Overflow. The pxd_mesgFault or pxd_mesgFaultText were not affected, and were reliable means to detect PCI FIFO Overflow. (13-Feb-2009)

  46. New Feature: Added functions pxd_eventFaultCreate and pxd_eventFaultClose allow notification of faults - via events, signals, or callbacks depending on O.S. - instead of polling via pxd_mesgFault. (04-Mar-2009)

  47. New Feature: For Windows, NT, 2000, XP, and Vista, added functions pxd_eventFieldCreate2, pxd_eventCapturedFieldCreate2, pxd_eventGPTriggerCreate2, and pxd_eventFaultCreate2 are variations of pxd_eventFieldCreate, pxd_eventCapturedFieldCreate, pxd_eventGPTriggerCreate, and pxd_eventFaultCreate that allow selection of a notification style event instead of a synchronization style event. (05-Mar-2009)

  48. Fixed Feature: With a PIXCI® D2X, CL1, or SI, with versions of the V3.0 driver with added support for PCI Express, invoking ::getDevInfo while video capture is pending or in progress may cause the video capture to be aborted. (10-Mar-2009)

  49. Fixed & Improved Feature: Under Linux, attempting to re-open an already open PIXCI® imaging board caused errors and crashes even if -XU disallowed sharing. Sharing is now supported. (27-Mar-2009)

  50. Improved Feature: XCLIB now has preliminary support for the PIXCI® SI1. (01-Apr-2009)

  51. Improved Feature: For Linux, two versions of each library is now provided, one compiled with -fPIC and one compiled without. Previously, the libraries were compiled without -fPIC. 14-Apr-2009

  52. Improved Feature: For Linux 2.6 and later kernels and Camera Link PIXCI® cards, the driver now offers /dev/tty style access to the serial port. Node names are /dev/ttyPIXCI0 for unit 0, /dev/ttyPIXCI1 for unit 1, etc. Note that this mapping holds even if unit 0, for example, is not a Camera Link card and thus doesn't have a serial port - in which case, opening /devttyPIXCI0 will fail. Only the Camera Link standard baud rates are supported. (21-Apr-2009)

  53. New Feature: XCLIB now supports the PIXCI® ECB1-34 ExpressCard/34 imaging board. (14-May-2009)

  54. Improved Feature: Under 64 bit operating systems, XCLIB now supports up to 16 PIXCI® imaging boards. (01-Jun-2009)

  55. New Feature: XCLIB now supports the PIXCI® ECB2 ExpressCard/54 imaging board. (03-Jun-2009)

  56. Fixed Feature: When using a SILICON VIDEO® camera, and using pxd_SV2112, pxd_SV1310, pxd_SV1281, or pxd_SV9M001 functions, using pxd_videoFormatAsIncluded with a format file which has I2C (i.e. camera head) configuration commands will cause unexpected results as the camera head state which is cached by pxd_SV2112, pxd_SV1310, pxd_SV1281, or pxd_SV9M001 is not updated with the camera state set by the format file. (04-Jun-2009)

  57. Clarified Feature: The 'properties' of the PIXCI® driver for XP(x64) & Vista(x64) describe it as supporting only XP(x64). This does not affect the driver's operation under Vista(x64). (01-Jul-2009)

  58. Fixed Feature: When using a PIXCI® SI4, depending on the order in which the 4 units are opened and the cameras initialized, an ''Eeprom contents invalid (0xffff:0xffff)'' error may occur. This can be resolved either with a FPGA update, or with a updated PIXCI® driver. (24-Jul-2009)

  59. Fixed Feature: When using multiple PIXCI® imaging boards, the ''struct pxdevfault'' and/or pxd_mesgFault messages may indicate the affected units as their physical sequential number, or as a sequential number relative to the units actually opened. Usage is now, consistently, the physical sequential number. (03-Aug-2009)

  60. New Feature: Now has partial (can configure camera via .fmt file, but does not yet have camera specific API) and beta-level support for new SILICON VIDEO® 643 camera. (24-Aug-2009)

  61. Modified Feature: The default pixel clock frequency for the SILICON VIDEO® 9C10 has been changed from 70 MHz (7.2 fps) to 48 MHz (4.8 fps). (18-Sep-2009)

  62. Version 3.7 released. Adds support for Windows 7 and 7(x64). (07-Nov-2009)

  63. New Feature: For SILICON VIDEO® cameras, new functions pxd_SV2112_getMinMaxExposure, pxd_SV2112_getMinMaxCtrlExposure, pxd_SV1310_getMinMaxExposure, pxd_SV1281_getMinMaxExposure, pxd_SV9M001_getMinMaxExposure, pxd_SV642_getMinMaxExposure, pxd_SV643_getMinMaxExposure, and pxd_SV643_getMinMaxCtrlExposure allow obtaining the minimum and maximum allowable exposures, which vary depending on other camera parameters such as pixel clock frequency, area of interest, subsampling, etc. These functions avoid having to actually set the exposure to a low or high value and query the result, or use non-SCF functions, to obtain the same information. (18-Dec-2009)

  64. Improved Feature: Fault messages now show multiple units as a 0-based list of units numbers, such as ''0,3,6'' instead of a hexadecimal number whose bits represent units, such as ''0x45''. (06-Jan-2010)

  65. Fixed Feature: With multiple boards, with multiple memory partitions, depending on the relative number of boards and partitions, some of the memory may not have been assigned to any board. (13-Jan-2010)

  66. Modified Feature: The xclib_open now applied the formatname before the formatfile, if both are specified. This provides a better result in the common case of accidently using pxd_PIXCIopen with both formatname and formatfile. (While pxd_PIXCIopen declares such as case invalid, no error is given). (27-Jan-2010)

  67. Improved Feature: XCLIB now supports the PIXCI® SI2 imaging board.

  68. Improved Feature: XCLIB now supports the PIXCI® SV7 imaging board. (03-Apr-2010)

  69. Improved Feature: New function pxd_SV643_setExposureAndGainOffset extends pxd_SV643_setExposureAndGain, allowing easy adjustment of the offset (black level). (03-May-2010)

  70. Fixed Feature: Under Windows, the optional high resolution kernel timer selectable via Driver Configuration Parameters isn't actually enabled. (19-May-2010)

  71. Improved Feature: Function names in the XCLIB 32 bit DLL's now have simple aliases, so that Visual Basic, .NET, LabView, etc. can call, for example, pxd_PIXCIopen instead of the full, decorated name _pxd_PIXCIopen@12. (28-May-2010)

  72. Improved Feature: XCLIB now supports the PIXCI® ELS2 PCI Express imaging boards (Beta). (21-Jun-2010)

  73. Improved Feature: New SCF+ functions, prefixed as pxe_, now allow operating multiple, non-identical PIXCI® imaging boards without having to use the structured functions. The pxe_ functions share the simplicity of the pxd_ functions. (17-Aug-2010)

  74. Fixed Feature: For SILICON VIDEO® 9C10 cameras, the pxd_SV9M001_setVideoAndTriggerMode function did not allow setting controlled mode. (14-Sep-2010)

  75. Fixed Feature: For PIXCI® SI2 imaging boards under a 64 bit O.S. where the PC has more than 4 GB of memory, image data may be black depending on whether allocated buffers were above or below the 4 GB address. (22-Sep-2010)

  76. New Feature: XCLIB now supports 32 bit applications under 64 bit Windows (previously only 64 bit applications were supported) using the XCLIBWNT.DLL (32 bit DLL) and the EPIXXCW6.SYS (64 bit driver). The 32 bit applications have the same limits as under 32 bit Windows - frame buffer memory is limited to less than 4 GByte. Also, the frame buffer memory must be in the lower 4 MByte of PC memory. (11-Oct-2010)

  77. New Feature: New pxd_SILICONVIDEO_ functions operate with all SILICON VIDEO® cameras. Use of the camera specific pxd_SV2112_, pxd_SV1310_, pxd_SV1281_, pxd_SV642_, pxd_SV643_, and pxd_SV9M001_ functions is deprecated. (Oct-2010)

  78. Fixed Feature: The XCLIBWNT_VBNET.TXT declarations for use with .NET have been fixed; declarations which involve ''passing'' of arrays were missing the ''ByRef'' adjective. (20-Oct-2010)

  79. Fixed Feature: Under some conditions, following addition of the new feature described in the 01-Jun-2008 entry, the pxd_goLiveSeq may initiate sequence capture twice which may cause problems in some trigger modes. (25-Oct-2010).

  80. Improved Feature: For PIXCI® imaging boards with multiple functional units (e.g. EL1DB, E4DB, SI2, SI4, ...) and under a Windows Plug & Play O.S. (i.e. Windows 2000 and later) the default -DM selection of which (functional) units are to be opened is changed from the first functional unit (i.e. -DM 0x01) to all functional units of the first physical board (i.e. -DM 0x03 for boards with two functional units or -DM 0x0F for boards with four functional units). (15-Nov-2010)

  81. New Feature: Now supports the SILICON VIDEO® WGA-C and WGA-M cameras. (14-Dec-2010)

  82. New Feature: Now supports the PIXCI® SV5L imaging board. (06-Jan-2011)

  83. Fixed Feature: With PIXCI® imaging boards with multiple functional units (EL1DB, E4DB, SI2, SI4, ECB2), when used with multiple processors or multi-core processors, a BSoD may occur when the imaging board is closed. (01-Jan-2011)

  84. New Feature: Functions pxd_eventSerialCreate and pxd_eventSerialClose allow signalling the application upon activity on the serial port. (17-Jan-2011).

  85. Fixed Feature: On some(?) 64 bit machines, sequence capture may cause PCI FIFO Adrs errors, even when live capture, or live alternate pair capture, does not. Reducing the number of memory partitions used appears to eliminate the problem. The underlying cause and alternate solutions are being investigated. (07-Feb-2011)

  86. Fixed Feature: For PIXCI® imaging boards with multiple functional units (ECB2, EL1DB, E4DB, SI2, SI4, etc.) the default submodel (i.e. camera type) of all but the first functional unit may rarely, randomly, be incorrect. (09-Feb-2011)

  87. Fixed Feature: The pxd_serialWrite, if used with an invalid unitmap, may not return. (18-Mar-2011)

  88. Fixed Feature: Using the 32 bit version of XCLIB under 64 bit Windows did not allow more than one instance of XCLIB to be opened from a single application, and thus would not allow multiple, different PIXCI® imaging boards to be opened. (20-Mar-2011)

  89. Improved Feature: With PIXCI® CL2 and E* imaging boards, the maximum number of pixels per line, single tap, monochrome has been increased from 65536 to 16777216. There are corresponding increases for multi-tap and color formats, but the numeric details of each are omitted. (25-Mar-2011)

  90. Improved Feature: The new -TI driver configuration parameter provides more selections for various operating system timer services used for time stamping video events. (28-Mar-2011)

  91. Improved Feature: Under 32 bit Windows & Linux, video setup files saved under 64 bit Windows & Linux can now be imported, and vice versa. (Under 32 bit DOS, only video setup files saved under 32 bit systems can be imported). (27-Apr-2011)

  92. Improved Feature: The video setup file (.fmt) now supports an extended ''struct pxcamcntl'' supporting a longer list of serial commands. A video setup file exported by XCAP in which the serial commands do not exceed 512 bytes (the previous limit) can be imported in the older XCLIB & XCAP. A video setup file exported by XCAP in which the serial commands exceed 512 bytes can't be imported in the older XCLIB & XCAP (unless XCAP's option to not include serial commands in the video setup file was used).

    The extended ''struct pxcamcntl'' is variable length; specified by its ''ddch.len'', and thus limited to 65535 bytes for the entire structure, or 65535-(800-512) bytes for serial commands. New ''pxlibservice'' services ::getAllocState, ::importAllocStateCopy, and ::initAllocStateCopy are needed to handle the variable length structures; using the older ::getState, ::importStateCopy, and ::initStateCopy will limit and truncate the serial commands to 512 bytes. (19-May-2011)

  93. Fixed Feature: Using pxd_SILICONVIDEO_setResolutionAndTiming to change the pixel clock frequency in conjunction with a SILICON VIDEO® 9C10, 10C6, 10M6 results in loss of video. (05-Jul-2011)

  94. New Feature: Now supports the SILICON VIDEO® 10M6, 10C6, 10C-CL, and 10M-CL cameras in free-run and controlled global modes. (12-Jul-2011)

  95. New Feature: Now supports the PIXCI® E8 imaging board. (19-Jul-2011)

  96. Fixed Feature: On some motherboards using the nVidia NF200 PCI Express Bus controller, configuration for a specific camera as per the EEPROM may not be reliable. (18-Aug-2011)

  97. New Feature: Now supports the PIXCI® E8DB imaging board. (30-Aug-2011)

  98. New Feature: Now supports the PIXCI® A310 imaging board.

    For users of the Structured Style Interface: The pxvidstate has been modified to accommodate additional substructures. The change (from a struct* to a union*) is backward compatible for object code, but source will require simple textual changes. (11-Sep-2011)

  99. Improved Feature: The pxe_ function names in the XCLIB 32 bit DLL's now, too, have simple aliases. (See 28-May-2010 entry). (04-Oct-2011)

  100. Fixed Feature: The pxd_setExsyncPrin and related functions return an error when used with a PIXCI® E8DB imaging board (but not for a PIXCI® E8 imaging board). (26-Nov-2011)

  101. Fixed Feature: Under newer Windows, a notify style event created with pxd_eventFieldCreate2, pxd_eventCapturedFieldCreate2, pxd_eventGPTriggerCreate2, pxd_eventFaultCreate2, or pxd_eventSerialCreate may not allow the event to be set or cleared by the application, due to ACL. (19-Dec-2011)

  102. Added Feature: New function pxd_infoSysTicksUnits provides the units for the raw capture times reported by pxd_capturedSysTicks, pxd_buffersSysTicks, and similar functions. Originally, the ''Ticks'' units were only dependent on the operating system chosen and could easily be hardcoded, however recently added driver configuration options allow selecting one of several timers each with different units. The pxd_infoSysTicks was also added. (17-Jan-2012)

  103. Improved Feature: The driver configuration options now allow specifying use of dynamically allocated kernel memory for serial data buffers, rather than stealing part of the frame buffer memory. This simplifies calculations of how much frame buffer memory is needed, and may simplify configuration issues when using forceful frame buffer allocation. (26-Jan-2012)

  104. Fixed Feature: For the PIXCI® SV7, a colorspace of ''CbYCrY'' was not accepted by pxd_readuchar and similar functions. (06-Mar-2012)

  105. Fixed Feature: For the PIXCI® SV7 with CCIR or PAL format video, the default video setup ''flipped'' the two fields causing interlace actifacts. (28-Mar-2012)

  106. Improved Feature: The pxd_videoFormatAsIncluded macro has been changed so as not to use ''static'' variables; use now requires enclosing braces and a pxd_videoFormatAsIncludedInit macro. For backward compatibility, the old pxd_videoFormatAsIncluded is available by editing xclibsc.h. The pxe_videoFormatAsIncluded and pxe_videoFormatAsIncludedInit macros have been added, analogous to the aforementioned macros. (08-May-2012)

  107. Improved Feature: For the PIXCI® A310, ''SVGA 800x600 60Hz RGB'' and ''VGA 640x480 60Hz RGB'' have been added as predefined formats selectable via pxd_PIXCIopen. (27-Jul-2012)


RELEASE NOTES: XCLIB — Version 2.2

  1. This release adds support for Windows XP. (03-Dec-2001).

  2. Added Feature: Function pxd_SV2112_setExposureAndGain allows setting the current exposure and gain for the SILICON VIDEO® 2112 and 2112C cameras. Function pxd_SV2112_setResolutionAndTiming allows setting the current decimation, AOI, scan direction, and pixel clock frequency for the SILICON VIDEO® 2112 and 2112C cameras. Functions pxd_SV2112_getExposure, pxd_SV2112_getGain, pxd_SV2112_getDecimation, pxd_SV2112_getAoiTop, pxd_SV2112_getAoiLeft, pxd_SV2112_getPixelClock, and pxd_SV2112_getScanDirection allow obtaining the eponymous setting for the SILICON VIDEO® 2112 and 2112C cameras. (03-Dec-2001).

  3. Added Feature: A SILICON VIDEO® 2112 and 2112C specific example program, XCLIBEXC.CPP, demonstrates capture, display, adjustment of the camera's settings. (03-Dec-2001).

  4. Fixed Feature: The new ::goingBufStatus service may cause system termination when used with multiple boards, and when used on any but the first board. (13-Dec-2001).

  5. Added Feature: For SILICON IMAGING 3170 cameras, video setup files saved by XCAP now contain the necessary serial commands to (re)configure the camera. Upon open, XCLIB now reconfigures the camera with these serial commands. (18-Jan-2002).

  6. Added Feature: New functions pxd_getGPTrigger, pxd_eventGPTriggerCreate, and pxd_eventGPTriggerClose provide SCF level access to the software detectable trigger provided on PIXCI® D, D24, D32, D2X, and D3X image boards. These functions are not needed when using a camera which itself is in trigger mode. Rather, they can be used to detect a trigger with cameras in continuous mode where the PIXCI® trigger input has no direct effect on camera or PIXCI® imaging board. (01-Feb-2002).

  7. Fixed Feature: The pxd_defineImage3 with some combinations of imaging boards and cameras would produce a program fault. (08-Feb-2002).

  8. Fixed Feature: On PIXCI® and cameras which produce more than one pixel per clock, the ''vidres.x.vidoffset'' was interpreted in units of pixel clocks, instead of pixels. (13-Feb-2002).

  9. Fixed Feature: The PIXCI® Windows VXD and SYS files, the XCLIB DLL files, and the PXIPL DLL files did not have correct, or did not have any, version information shown with the files' properties (such as via the Windows Explorer). (20-Feb-2002).

  10. Fixed/Added Feature: The pxd_getFieldCount function mentioned in the Conversion of Application Programs from XCOBJ was not documented. It has been renamed to pxd_videoFieldCount (a function under the old name persists for compatibility) and documented. The pxd_getFieldsPerFrame, never mentioned or documented, has been renamed to pxd_videoFieldsPerFrame and documented. (27-Feb-2002).

  11. Improved/Fixed Feature: The maximum number of bits per pixel value component was limited to 14, and has been changed to 16. (09-Apr-2002).

  12. Fixed Feature: When switching the SV2112 camera from controlled back to continuous video mode, the pxd_SV2112_setVideoAndTriggerMode had to be called twice (with the same parameters). (02-May-2002).

  13. Improved Feature: The XCLIBEXC.CPP example program for use with SV2112 and SV2112C cameras now also demonstrates the implementation of automatic gain control (AGC). (05-Jul-2002)

  14. Fixed Feature: Using Forceful Memory allocation under Windows NT/2000/XP, and selecting the wrong boot.ini selection when prompted during Windows' boot, may prevent Windows from starting. (09-Aug-2002).

  15. Fixed Feature: Using multiple PIXCI® D2X, D3X, CL1 under Windows 2000/XP, where the cameras are tightly synchronized may cause the PC to lockup until rebooted or the cameras powered down. (12-Aug-2002).

  16. Added Feature: XCLIB now supports additional features of newer PIXCI® D2X, D3X imaging boards for line scan cameras, increasing the maximum number of lines per image from 65535 to 16777216. (15-Aug-2002).

  17. Fixed Feature: When using multiple PIXCI® CL1 imaging boards with certain cameras, the pxd_videoFieldCount pxd_getFieldCount pxd_getGPTrigger functions always returned the status of unit 1, not the selected unitmap, and the events created by pxd_eventFieldCreate pxd_eventCapturedFieldCreate pxd_eventGPTriggerCreate were signalled by activity on either unit. (22-Aug-2002).

  18. Fixed Feature: On newer machines under Windows XP, the pxd_eventFieldCreate pxd_eventCapturedFieldCreate pxd_eventGPTriggerCreate may cause system death (i.e. ''blue-screen''). (23-Aug-2002).

  19. New Feature: XCLIB and XCLIB-IPL for Windows now includes static link libraries, as an alternative to using the dynamic link library (DLL). For OEM application programs that are to be redistributed, using the static link libraries minimizes the number of files that must be redistributed. (09-Sep-2002).

  20. Improved Feature: The ::setLiveTrigBuf and pxd_goLiveTrig now allow selecting rising, falling, or either edge of the general purpose input, when used with PIXCI® SV4, SV5, D2X, D3X, and CL1 imaging boards. Previously, those features always used either edge. (09-Sep-2002).

  21. Improved Feature: For PIXCI® D2X, D3X, or CL1 and line scan cameras running in ''vertical mastered'' mode (i.e. no external VDRIVE signal), XCLIB now allows snapping an image starting at the next line, in contrast to snapping when the internal line counters ''roll over''. (25-Sep-2002).

  22. Fixed Feature: In the current release of XCLIB, the ''controlled'' mode parameters of pxd_SV2112_setVideoAndTriggerMode and pxd_SV2112_setCtrlExposureAndRate may not work as intended. (04-Oct-2002).

  23. Added Feature: A new example, XCLIBEX4.CPP, demonstrates sequence capture and display with any PIXCI® imaging board. (11-Oct-2002)

  24. Fixed Feature: The pxd_readuchar, pxd_writeuchar, pxd_readushort, and pxd_writeushort as well as the similar ::imageWriteUShort, ::imageReadUShort, ::imageWriteUChar, and ::imageReadUChar functions would return 0 and read/write nothing if the specified AOI were invalid, such as larger than the frame buffer. (15-Oct-2002).

  25. Fixed Feature: The ::bufferSaveStream and ::bufferLoadStream functions may cause program death when the alignsector parameter is non-zero in conjunction with certain combinations of cameras, imaging boards, and operating systems. (16-Oct-2002).

  26. Improved Feature: The pxd_defineImage, pxd_defineImage3, pxd_readuchar, pxd_writeuchar, pxd_readushort, and pxd_writeushort now accept a colorspace of ''CbYCrY'' to access pixel data in UYVY format, supported only with a PIXCI® SV2, SV3, SV4, or SV5 which has been set to capture in that format. (28-Oct-2002).

  27. New Feature: A beta version of XCLIB for the Linux 2.4.8 kernel is released. (01-Nov-2002)

  28. Modified Feature: The default frame buffer memory size under Windows NT, 2000, and XP has been increased from 4 MByte to 16 MByte. (05-Nov-2002).

  29. Fixed Feature: For some combinations of PIXCI® imaging boards and cameras, use of pxd_defineImage3 selecting fewer than all frame buffers, combined with pxio8_binreadseq, pxio8_binwriteseq, pxio8_bin1writeseq, and pxio8_bin1readseq would result saving or loading more frame buffers than specified. (13-Nov-2002).

  30. Improved Feature: Under Windows NT, 2000, or XP the ''-WT'' driver configuration parameter now allows selecting a high resolution kernel timer for time stamping events. (28-Nov-2002)

  31. Fixed Feature: On some machines and cameras under Windows 2000 and XP, the pxd_eventFieldCreate pxd_eventCapturedFieldCreate pxd_eventGPTriggerCreate may cause system death. (16-Dec-2002).

  32. Added Feature: The Camera Link serial API has been added to XCLIB, with functions clSerialInit, clSerialClose, clSerialRead, and clSerialWrite. These allow access to a PIXCI® imaging board which was already opened by XCLIB. A separate DLL, clSerPIXCI.dll which has only the Camera Link Serial API, and can be distributed w/out XCLIB's licensing restrictions, can be used to access the serial port PIXCI® imaging boards w/out XCLIB. (24-Dec-2002)

  33. Fixed Feature: When using 3 or more PIXCI® imaging boards that are combinations of at least 2 different models (such as D vs SV4 vs D2X), certain combinations of selected boards (via -DM) when installed in certain order on the PCI bus may cause errors upon open. (13-Jan-2003)

  34. Fixed Feature: The pxd_setExsyncPrin, pxd_setExsyncPrincMode and related functions were not enabled for use with the PIXCI® CL3SD. (31-Jan-2003)

  35. Fixed Feature: For the SILICON VIDEO® 2112(C) when used in Controlled mode, the maximum frame rate allowed such as via pxd_SV2112_setCtrlExposureAndRate has been corrected (increased). (04-Feb-2003).

  36. Fixed Feature: Driver installation under Windows XP has been improved, eliminating the problem under some PC configurations whereby the initial Plug&Play installation run's ''forever'', requiring a reboot and a second installation. (20-Feb-2003).

  37. Added Feature: Functions pxd_SV1310_setExposureGainOffset, pxd_SV1310_setResolutionAndTiming and other related functions provide camera specific controls for the SILICON VIDEO® 1310 and 1310C cameras. (28-Feb-2003)

  38. Improved Feature: The pxd_SV2112 functions, and especially the pxd_SV2112_get functions, have been improved and are now faster by virtue of caching the camera's state rather than having to re-read the information from the camera. (05-Mar-2003).

  39. Fixed Feature: When the PIXCI® D2X, D3X, or CL1 is used in (video) triggered mode combined with pxd_goLive, the first triggered image is now captured, rather than capture starting with the second triggered image. (05-Apr-2003).

  40. Fixed Feature: The subsample parameter to the new pxd_SV1310_setResolutionAndTiming function had the horizontal and vertical subsampling components exchanged. Thus subsample=0x0402 would have implemented horizontal subsampling by a factor of two and vertical subsampling by a factor of four, rather than the documented horizontal subsampling by a factor of four and vertical subsampling by a factor of two. (11-Apr-2003).

  41. Improved Feature: For the SILICON VIDEO® 1310 camera, the frame rate can now be increased by using subsampling and/or using a smaller AOI. Previously, only a smaller AOI would increase the frame rate. (11-Apr-2003)

  42. Fixed Feature: Using a ''struct pximage3'' with operations that read or write across image boundaries with a single read or write, the result may be incorrect. The only known library function that this affected is pxio8_binreadseq. (11-Jun-2003)

  43. Added Feature: A new example program, xclibex5.cpp, demonstrates use of non pxd_ functions to operate two imaging boards at different resolutions. (06-Jun-2003)

  44. Fixed Feature: For the PIXCI® CL3SD, under Windows 2000, XP, the improved driver installation file, epixxcw2.inf, set
        PIXCI= ... -WT -0x20
    
    to activate high resolution timestamps. The superfluous ''-'' causes software to believe the board has 4 GBytes of memory, regardless of the amount of memory actually installed. (27-Jun-2003).

  45. Fixed Feature: The pximage's optional PXUNIT* constants (which describe the image's real-world dimensional units) have been corrected; the old values did not fit within the uchar fields provided, namely widthunits, heightunits, and depthunits. (13-Jul-2003)

  46. Added Feature: The pxd_goSnapPair has been added as an SCF version of ::setSnapPairBuf; both intended for use with cameras that output two images with a single trigger. (29-Jul-2003)

  47. Added Feature: The pxd_goLiveSeqTrig allows initiating or terminating sequence capture in response to a general purpose input or trigger, with less latency than possible with previously available techniques. (03-Aug-2003)

  48. Fixed Feature: For PIXCI® D, D24, D32, D2X, and D3X imaging boards, the pxd_goLiveTrig and ::setLiveTrigBuf optional parameters delay60 and delay70 would implement the stated delay plus 1, rather than the stated delay. These functions are rarely used with those imaging boards, as they are only used with cameras that don't implement triggering within the camera. (07-Aug-2003).

  49. Modified Feature: Due to lack of apparent interest, the static link libraries for Windows are no longer distributed with XCLIB and XCLIB-IPL. (19-Aug-2003).

  50. Improved Feature: XCLIB now performs a power-up initialization for SILICON VIDEO® 2112 and 1310 cameras upon calling pxd_PIXCIopen. Previously, the cameras were initialized only by PC power-up. (12-Sep-2003)

  51. Fixed Feature: Under Windows NT, 2000, and XP, when using multiple instances of XCLIB (via multiple calls to xclib_open), the pxd_eventFieldCreate, pxd_eventFieldClose, and pxd_eventCapturedFieldCreate could not be used in more than one instance. (13-Sep-2003).

  52. Added Feature: Functions pxd_SV1281_setExposureGainOffset, pxd_SV1281_setResolutionAndTiming and other related functions provide camera specific controls for the SILICON VIDEO® 1281 and 1281C cameras. (16-Sep-2003).

  53. Fixed Feature: On some PC's, the SILICON VIDEO® 1310(C) would not initialize properly after power up, outputting a grey image, unless either (a) XCAP was run, or (b) The XCLIB application was run twice. (29-Sep-2003).

  54. Improved Feature: The PIXCI® SV5A is now supported distinct from PIXCI® SV5; the default SV5A video setup is NTSC, not the SV5's NTSC/YC. (30-Sep-2003).

  55. Improved Feature: For all currently supported Uniq, Basler, Hitachi, and Cohu CameraLink cameras and the Jai CV-M4+CL/CV-M7+CL CameraLink cameras video setup files saved by XCAP now include the serial commands needed to restore the camera to the operating mode as set in XCAP. XCLIB now loads those serial commands during pxd_PIXCIopen, eliminating having to follow the instructions in the Using a Serial (RS-232) Configurable Camera with the PIXCI(R) D, D24, D32, D2X, D3X, CL1, or CL3SD application note. The same improvement has always been provided for Silicon Imaging and Redlake ES-1020 cameras, but not explicitly noted. (27-Oct-2003).

  56. Improved Feature: Under Linux, the ''Use Polling Rather than Interrupts (-QU)'' option is now available. (12-Nov-2003).

  57. Fixed Feature: Under Linux, closing the library may cause the wrong (library internal) file ''handle'' to the driver to be closed, adversely affecting any file or device opened after XCLIB. Under Linux, the pxd_loadBmp does not work properly. (09-Dec-2003).

  58. Added Feature: Functions pxd_definePximage and pxd_definePximage3 and similar to the existing pxd_defineImage and pxd_defineImage3, but more convenient in multi-threaded and a few other, rare, applications. (06-Jan-2004)

  59. Fixed Feature: Under Linux, on some motherboards, interrupts, and thus notification about end-of-capture, may not work properly. (14-Jan-2004)

  60. Added Feature: A new example program, XCLIBEX6.TXT, illustrates use of XCLIB with VB.NET. (16-Jan-2004).

  61. Added Feature: New functions pxd_saveRawBuffers and pxd_loadRawBuffers have been added as an SCF version of ::bufferLoadStream and ::bufferSaveStream. (02-Feb-2004)

  62. Fixed Feature: When using XCLIBEXC.CPPandaSILICONVIDEO®1310(C)with a video setup file saved by XCAP which sets a small capture AOI, the captured image is garbled as the camera is set to one resolution while the SILICON VIDEO® 1310(C) specific functions invoked by XCLIBEXC.CPP set the PIXCI® imaging board to a different resolution. (The same video setup file works correctly in XCLIBEX2.CPP which does not make use of SILICON VIDEO® 1310(C) specific functions). (31-Mar-2004).

  63. Improved Feature: New function pxd_mesgFaultText allows obtaining the text describing a fault from a SCF style function, avoiding pxd_mesgFault's implied creation of a message box. (12-Apr-2004).

  64. Fixed Feature: For Camera Link cameras where a previously saved video setup file contains serial commands with which to initialize the camera, XCLIB's pxd_PIXCIopen may fail with a ''timeout'' error. The problem is most likely to occur under Linux, but might occur under other operating systems. (30-Apr-2004).

  65. Improved Feature: The XCLIB release now includes the full XCLIB C/C++ Reference Manual in HTML format. (07-May-2004).

  66. Fixed Feature: For rare combinations of frame buffer sizes versus frame buffer memory allocation parameters, the per-buffer capture information reported by pxd_buffersFieldCount, pxd_buffersSysTicks, and pxd_buffersGPIn may be destroyed by capturing into the last, or last few, frame buffers. (11-May-2004).

  67. Fixed Feature: For the SILICON VIDEO® 1281 and 1281C cameras, in some combinations of AOI, pixel clock and other parameters, too large a value of exposure is allowed, causing the captured image to be extremely dark or extremely bright. Also, under Visual Basic or Delphi a divide by zero error may occur when the camera was not previously used by a ''C'' application or XCAP. (27-May-2004).

  68. Fixed Feature: For SILICON VIDEO® 1281 and 1281C cameras, the maximum exposure as a function of other parameters, and some internal ''tweaks'' governing timing was not consistent with XCAP. (17-Jun-2004).

  69. Improved Feature: For all currently supported DVC CameraLink cameras video setup files saved by XCAP now include the serial commands needed to restore the camera to the operating mode as set in XCAP. See entry for 27-Oct-2003 for additional information. (11-Aug-2004).

  70. Added Feature: Supports the SILICON VIDEO® 9M001 and 9M001C cameras, including utilizing video setup files saved by XCAP to restore the camera state. But does not yet have camera specific API functions. (19-Sep-2004).

  71. Added Feature: Access to color pixel values now supports CMY (cyan, magenta, yellow) color space. (21-Sep-2004).

  72. Corrected. Documentation for pxd_loadBmp and pxd_loadTiff has been corrected to describe the existing 0x100 option to loadmode. (25-Oct-2004).

  73. Added Feature: Functions pxd_SV9M001_setExposureAndGain, pxd_SV9M001_setResolutionAndTiming and other related functions provide camera specific controls for the SILICON VIDEO® 9M001 and 9M001C cameras. (25-Oct-2004).

  74. Improved Feature: XCLIB now recognizes and supports Windows Server 2003, a variant of XP. (29-Nov-2004)

  75. Fixed Feature: For the SILICON VIDEO® 1281 and 1281C cameras and when using a video setup file in non-free run mode. The call to the first pxd_SV1281_*() function may change the video setup. Previous workaround was to call pxd_videoFormatAsIncluded after the pxd_SV1281_*() function. (09-Dec-2004)

  76. Fixed Feature: For SILICON VIDEO® and other cameras configured for per-pixel offset and gain corrections, when a) Using forceful memory allocation, b) Driver configuration parameter -MB non-zero, and c) Frame buffer memory mapped into application space, the per-pixel corrections may not be applied correctly. (22-Dec-2004)

  77. Improved Documentation: For the pxd_SV2112_, pxd_SV1310_, pxd_SV1281_, and pxd_SV9M001_ functions, documentation now notes that pxd_PIXCIopen performs partial, quick initialization of XCLIB; initialization for these camera functions is delayed until the first such function is called. Time sensitive applications should call any of these camera functions once before entering the application's time critical phase. (23-Dec-2004)

  78. Fixed Feature: Use of clserPIXCI.DLL (the stand-alone Camera Link API) failed under Windows 95, 98 if the PIXCI® was not previously opened by XCLIB or XCAP. (06-Jan-2005)

  79. Added Feature: Functions pxd_SV9M001_setExposureAndGain, pxd_SV9M001_setResolutionAndTiming and other related functions provide camera specific controls for the SILICON VIDEO® 9T001C camera. (27-Feb-2005).

  80. Improved Feature: The clserPIXCI.DLL (the stand-alone Camera Link API) has been renamed to clserEPX.dll, and is now compliant with the Camera Link V1.1 specification. (12-May-2005).

  81. Improved Feature: The pxd_xclibEscape now returns NULL if the library is not open. (12-May-2005)

  82. Fixed Feature: The Linux version of the PIXCI® driver did not work with the (very) old PIXCI® SV2 and SV3 imaging boards. (25-Jun-2005)

  83. Fixed Feature: In beta releases of XCLIB w. support for the PIXCI® CL2, the pxd_serialConfigure would ONLY work with the CL2, not the older CL1, CL3SD, etc. (27-Jun-2005).

  84. Improved Feature: The data rate of the I2C or two wire serial bus used to control SILICON VIDEO® camera heads can now be increased via the ''-I2C'' Device Configuration Parameters so as to allow faster control of gain and other camera head features when used with shorter cables. This feature is particularly useful with 9T001C cameras, whose camera head's control involves more I2C or two wire serial bus activity than other SILICON VIDEO® camera heads. (04-Aug-2005).

  85. Added Feature: Now supports Linux 2.6.x kernels. (03-Oct-2005).

  86. Added Feature: Supports the SILICON VIDEO® 642M and 642C cameras, including utilizing video setup files saved by XCAP to restore the camera state. Functions pxd_SV640_setExposureAndGain, pxd_SV640_setResolutionAndTiming and other related functions provide camera specific controls for the SILICON VIDEO® 642M and 642C cameras. (23-Nov-2005).

  87. Fixed Feature: The pxd_readuchar and pxd_readushort functions, when used to read an AOI of the image with one function call, under some memory configurations may return incorrect pixel data. (22-Dec-2005).

  88. API Tweak: The ''cnt'' parameter of ::imageReadUChar, ::imageWriteUChar, ::imageReadUShort, ::imageWriteUShort, ::imageReadUInt, and ::imageWriteUInt has been tweaked from ''int'' to ''size_t''. This has no effect on (current) 32 bit applications. (18-Jan-2006).

  89. Modified Feature: The file name of 32 bit Linux drivers has been changed from pixcii86.o or pixcii86.ko to pixci_i386.o or pixci_i386.ko. This will avoid confusion with new 64 bit Linux drivers, to be named pixci_x86_64.ko. Similarly, the file names of 32 bit Linux drivers has changed from xclibi86.a and pxipli86.a to xclib_i386.a and pxipl_i386.a (The i386 or x86_64 file name components are consistent with ''uname -i''). (30-Jan-2006).

  90. Improved Feature: XCLIB now supports the PIXCI® CL1 Rev. 3. An older XCLIB used with a PIXCI® CL1 Rev. 3 is not able to correctly program the Camera Link serial baud rate. (07-Feb-2006)

  91. Improved Feature: XCLIB now supports the PIXCI® E1, PCI Express imaging board. Note that Microsoft does not support PCI Express under Windows 95, 98, ME, or NT; neither does XCLIB. (20-Feb-2006)

  92. Modified Feature: High resolution time stamping for Windows NT, 2000, XP is now the default for all PIXCI® imaging boards. Previously it was the default only for the PIXCI® CL3SD. (07-Apr-2006)

  93. API Tweak: The type of the offset parameter of ::getVidStatusValue has been changed from uint to size_t to better accommodate 64 bit environments. Ditto the cnt parameters of ::io, ::ioctl, pxd_readuchar, pxd_writeuchar, pxd_readushort, and pxd_writeushort have been changed from uint or int to size_t. This change does not affect 32 bit environments, under which the two types are the same size. (12-May-2006)

  94. Improved Feature: XCLIB now supports the PIXCI® E4, E1DB, and EL1, PCI Express imaging boards. (20-Feb-2006)

  95. Improved Feature: XCLIB now supports the PIXCI® E4DB, PCI Express imaging board. (30-Jun-2006)

  96. Modified Feature: The ctobas.exe utility, to generate VB and VB.NET declarations, is no longer distributed. The XCLIB distribution not includes VB and VB.NET declarations in XCLIB_VB.TXT and XCLIB_VBNET.TXT. (02-Sep-2006)

  97. Improved Feature: For Linux, the the ''-LX'' Driver Configuration Parameter allows requesting a higher resolution timer for time stamping video events. (06-Nov-2006)

  98. Fixed Feature: For SILICON VIDEO® 9M001 and 9M001C cameras, the actual frame period was one line longer than the program's requested frame period. (07-Dec-2006)

  99. Improved Feature: XCLIB now has preliminary support for the PIXCI® EC1, Express Card imaging boards; the number of general purpose inputs, outputs, and triggers is not yet finalized. (18-Dec-2006)

  100. Fixed Feature: On some computers with hyperthreading or multiple processors, under Windows NT, 2000, or XP, infrequent errors in Camera Link serial transmit or receive data may occur. (26-Dec-2006)

  101. Fixed Feature: Using XCLIB-Lite, the various file load/save functions returned PXERMALLOC. (09-Jan-2007)

  102. Improved Feature: Drivers for Windows 2000 and XP, as well all Windows DLL's and executables, are now digitally signed. (17-Jan-2007)

  103. Improved Feature: XCLIB now has support for the PIXCI® EL1DB, Express Card imaging boards. (18-Dec-2006)

  104. Fixed Feature: Under Linux, the pxd_doSnap() does not work as documented. It sometimes takes longer than necessary to complete, and in case of a timeout returns PXERDEVFAULT instead of PXERTIMEOUT. (30-Jan-2007)

  105. Fixed Feature: When using a PIXCI® SI, versions of XCLIB on or after Oct. 2006 may incorrectly report ''Camera head disconnected'', depending on cable length. (31-Jan-2007)

  106. Improved Feature: For SILICON VIDEO® 9T001 cameras, the (analog) gain and digital gains have been combined into a single, integrated gain. The integrated gain is easier to use, and prevents use of less than optimal settings (such as applying digital gain before the analog gain is maximized). (09-Feb-2007)


RELEASE NOTES: XCLIB — Version 2.1

  1. This release supports the PIXCI® SV2, SV3, SV4, D, D24, D32, and A models, in Watcom+Tenberry extended 32 bit DOS, and Windows 95/98/NT/2000 environments. Though not documented, the 95/98 driver and library also works in Windows ME. (28-Aug-2000).

  2. Added feature: An additional forceful memory allocation method added for Windows ME using the -IA driver configuration parameter in similar manner as for Windows NT. (01-Sep-2000).

  3. Fixed feature: The default format (pixels per clock) for the Pulnix TMC-9700 is incorrect. (04-Sep-2000)

  4. Fixed feature: Using pxd_getGPOut or its non-SCF counterpart with a PIXCI® D, D24, D32, or A and certain Kodak 10 bit cameras may cause loss of the 2 least significant bits. (7-Sep-2000).

  5. Fixed documentation: Documentation for pxd_renderDirectVideoInit, pxd_renderDirectVideoDone, pxd_renderDirectVideoLive, and pxd_renderDirectVideoUnLive showed these functions as being named pxd_DirectVideoInit, pxd_DirectVideoDone, pxd_DirectVideoLive, and pxd_DirectVideoUnLive. The library and .h files are not affected. (15-Sep-2000).

  6. Fixed feature: The default format for the Dalsa CA-D4 was incorrectly set as if for a line scan camera. (19-Sep-2000).

  7. Fixed documentation: The documentation for pxd_goLiveSeq also referred to a ''pxd_goSnapSeq'' function; the ''pxd_goSnapSeq'' was a typographical error and should have been pxd_goLiveSeq. (28-Sep-2000).

  8. Added feature: Support for using interlace cameras with the PIXCI® D, D24, D32 added with support for snap, live, and sequence capture. The ::setLiveTrigBuf does not yet support interlace modes. (29-Sep-2000)

  9. Fixed release: Versions of XCLIB for Windows NT w/out PXIPL did not included the EPIXXCWT.SYS driver and related files. These files can be obtained from the XCAP release. (03-Nov-2000)

  10. Added feature: XCLIB now supports the PIXCI® D2X series of imaging boards. (06-Nov-2000)

  11. Fixed documentation: The documentation for the reserved period parameter of ::setLivePairBuf specified that its value should be 0. The value should be 1. (09-Nov-2000).

  12. Added feature: The pxd_defineImage, pxd_defineImage3, pxd_readuchar, pxd_readushort, pxd_writeuchar, and pxd_writeushort now accept ''GRAY'' and ''Gray'' as a synonyms for ''Grey'', and now accept ''Bayer'' for use in conjunction with cameras that actually output raw Bayer pattern values, and where the library would otherwise be responsible for converting the values to RGB(x) or BGR(x). (22-Dec-2000).

  13. Modified feature: For Bayer output cameras, the ''Default'' pixel format is now BGR rather than RGB, for better display performance when ''Default'' is requested. (Does not affect code that explicitly requested BGR format). (01-Jan-2001).

  14. Fixed feature: A Driver Configuration Parameter of ''-XM''=0 (a non-default value) did not work properly with multiple boards installed.
    With multiple boards, one of which having a configuration error while others are selected for actual use, may result in a spurious ''Can't allocate frame buffer memory'' error. (02-Jan-2001).

  15. Fixed Feature: The pxd_defineImage3 did not accept a colorspace of ''Default'' (the pxd_defineImage was not affected). (13-Jan-2001).

  16. Fixed Feature: The pxd_defineImage and pxd_defineImage3 area of interest selection may or may not have the correct effect, depending upon the function with which the pxd_defineImage or pxd_defineImage3 result is used (a new bug only in previous release). (13-Jan-2001).

  17. Added Feature: The pxd_defineImage and pxd_defineImage3 now accept a colorspace of ''Display'', which provides the most efficient color space for display of the frame buffer through pxio8_GDIDisplay or similar functions. (13-Jan-2001).

  18. Fixed Feature: Using forceful memory allocation under Windows NT, Windows 2000, or DOS with a PIXCI® SV4 would result in unpredictable behavior the second time (since booting) that the board is opened. (16-Jan-2001).

  19. Fixed Feature: Calling pxd_goLiveSeq or ::setLiveSeqBuf while a previous pxd_goLiveSeq or ::setLiveSeqBuf was in operation did not alter the numbuf setting . (17-Jan-2001)

  20. Added Feature: XCLIB now supports the two G.P In and two G.P Out bits for the PIXCI® D2X series of imaging boards. (24-Jan-2001).

  21. Fixed Feature: For PIXCI® SV4 imaging boards in ::setLiveSeqBuf mode, a ::getLiveStatus using PXVIST_RUNNING always returned 0. (31-Jan-2001).

  22. Added Feature: The pxd_eventFieldCreate and pxd_eventCapturedFieldCreate allow the application to be signalled via a Windows event at the start of each field, and/or at the end of each captured field. Under Tenberry+DOS, pxd_eventFieldCreate and pxd_eventCapturedFieldCreate allow specifying a ''callback'' function to be invoked at the start of each field, and/or at the end of each captured field. (06-Feb-2001).

  23. Improved Feature: A new EPIXXCW2.SYS driver for Windows 2000 provides better compatibility with newer motherboards. In particular, it resolves a problem with motherboards using early 800 series chipsets, which would not provide interrupts. The older EPIXXCWT.SYS driver for Windows NT may still be used under Windows 2000 on all previously supported motherboards. (20-Feb-2001).

  24. Fixed feature: The default format for the SMD 4M15 was incorrect. (27-Mar-2001).

  25. Added Feature: New function pxd_setExsyncPrincMode, pxd_getExsyncMode, and pxd_getPrincMode allow setting camera configuration bits, but not suggested for use in favor of loading a new video configuration format.
    New service pxd_videoFormatAsIncluded allows configuring XCLIB as per a video configuration format that has been compiled into the application, and without re-opening XCLIB. (01-Apr-2001).

  26. Fixed Feature: The ::setLiveTrigBuf used with a PIXCI® SV4 imaging board did not always set the ''gpout60value'' or ''gpout80value'' correctly. (08-May-2001)

  27. Added Feature: The ::setLiveTrigBuf is now supported for the PIXCI® D2X imaging boards. (09-May-2001).

  28. Added feature: XCLIB now supports the PIXCI® CL1 series of imaging boards for Camera Link cameras. New functions pxd_serialConfigure, pxd_serialRead, and pxd_serialWrite support reading and writing data through the PIXCI® CL1. (15-May-2001).

  29. Fixed feature: Under Windows NT and 2000, the event created by pxd_eventFieldCreate and pxd_eventCapturedFieldCreate is initially signalled; thus the first WaitForSingleObject would always return immediately. For PIXCI® D2X imaging boards, the event created by pxd_eventCapturedFieldCreate behaved the same as an event created by pxd_eventFieldCreate. (18-May-2001).

  30. Added Feature: The XCLIB now supports the PIXCI® SV5 imaging board. (29-May-2001).

  31. Fixed Feature: Under Windows 2000, the PIXCI® SV5 would appear as two devices, (1) The SV5, and (2) A ''can't identify imaging board model''. (18-Jun-2001).

  32. Added Feature: The XCLIB now support opening multiple, simultaneous, instances of the library; allowing use of multiple, non-identical, PIXCI® imaging boards. The multiple instances must be opened from the same process, with multi-thread synchronization provided by the application program. (01-Jul-2001).

  33. Fixed Feature: The new pxd_serialWrite did not function correctly. (03-Jul-2001).

  34. Modified feature: For PIXCI® SV2, SV3, SV4, and SV5, for PAL and CCIR, the default video setup has been changed to avoid capturing black lines at the top of the image. (06-Jul-2001).

  35. Fixed Feature: When using Forceful Memory allocation under Windows NT or 2000, the frame buffer memory would not be cleared when Windows booted. Rather, the memory, or a portion of the memory, would be cleared each time the library/driver was opened. (18-Jul-2001).

  36. Fixed Feature: The ::setLiveTrigBuf did not work with the PIXCI® D2X, causing program or PC hang-ups. (20-Jul-2001).

  37. Modified feature: The size of the serial data buffers for pxd_serialRead and pxd_serialWrite have been increased from 32 bytes to 1024 bytes. (28-Jul-2001).

  38. Fixed Feature: For PIXCI® D, D24, D32, D2X, or CL1, specifying video resolution ''setmaxdatsamples'' or ''setmaxvidsamples'' with insufficient frame buffer memory to achieve maximum resolution would (correctly) cause the ''setmax...samples'' to be overridden and a less than maximum resolution to be used. However, the X & Y resolution used, trading X resolution for Y resolution, would not be consistent. (05-Aug-2001).

  39. Fixed Feature: Trying to open a imaging board while already in use by an earlier application correctly produced an error, but incorrectly closed the imaging board and deprived the earlier application of its use. (13-Aug-2001).

  40. Fixed Feature: Support for opening multiple, non-identical, PIXCI® imaging boards was not fully included in Windows NT/2000 versions. (17-Aug-2001).

  41. Added Feature: New functions pxd_buffersFieldCount pxd_buffersGPIn pxd_buffersSysTicks provide the time and value of the general purpose inputs for each captured buffer. (16-Sep-2001).

  42. Added Feature: New function pxd_goLiveTrig allows using ::setLiveTrigBuf within the SCF functions. (25-Sep-2001).

  43. Fixed Feature: The ::setLiveTrigBuf did not work with the PIXCI® D2X, causing the ''wait for g.p. input'' to never be satisfied. (05-Oct-2001).

  44. Fixed Feature: The colorspace parameter of pxd_readuchar, pxd_writeuchar and similar functions is documented as allowing a selection of ''YCrCb'', ''YofYCrCb'', ''RofYCrCb'', and ''BofYCrCb'', but the library instead required ''YCRCB'', ''YofYCRCB'', ''RofYCRCB'', and ''BofYCRCB''. Either ''YCRCB'' or ''YCrCb'', and their variants, are now allowed. (05-Oct-2001)

  45. Fixed Feature: The ::importStateCopy and ::exportStateCopy, and the third parameter of pxd_PIXCIopen did not always work properly under Watcom+Tenberry. (24-Oct-2001).

  46. Modified Feature: A twelfth parameter, trackers has been added to ::setLiveSeqBuf; existing code should simply add a final parameter of 0. (28-Oct-2001).

  47. Added feature: XCLIB now supports the PIXCI® D3X series of imaging boards. (Oct-2001)

  48. Added Feature: XCLIB now supports the G.P. In and G.P. Out bits that have been added to newer released of PIXCI® CL1 boards. (12-Nov-2001).


RELEASE NOTES: XCLIB — Version 0.0 Beta

  1. Fixed Feature. The pxd_readuchar, pxd_writeuchar, pxd_readushort, pxd_writeushort, as well as their ::imageReadUChar, ::imageWriteUChar ::imageReadUShort, ::imageWriteUShort equivalents do not work properly on an image AOI. (27-Jun-2000).

 

 

 

16. Distribution Contents

DISTRIBUTION KIT:

C/C++ Library for the PIXCI® Imaging Boards XCLIB & XCLIB-Lite - Version 3.7
The XCLIB or XCLIB-Lite distribution contains one or more of:
1a) EPIXXCW5.VXD Windows 95/98/ME 32 bit driver. EPIXXCW5.INF Windows 95/98/ME 32 bit driver installer. EPIXXC.SYS Large image memory reservoir driver for Windows 95/98.
1b) EPIXXCWT.SYS Windows NT 32 bit driver (formerly also for Windows 2000). EPIXXCWT.INF Windows NT 32 bit driver installer.
1c) EPIXXCW2.SYS Windows 2000/XP/Vista/7 32 bit driver. EPIXXCW2.INF Windows 2000/XP/Vista/7 32 bit driver installer. EPIXXCW2.CAT Windows 2000/XP/Vista/7 32 bit driver catalog.
1d) pixci_i386.o Loadable device driver for Linux w. 2.4 32 bit kernel and Intel i386 and newer processors.
1e) pixci_i386.ko Loadable device driver for Linux w. 2.6 32 bit kernel and Intel i386 and newer processors.
1f) EPIXXCW6.SYS Windows XP(x64)/Vista(x64)/7(x64) 64 bit driver. EPIXXCW6.INF Windows XP(x64)/Vista(x64)/7(x64) 64 bit driver installer. EPIXXCW6.CAT Windows XP(x64)/Vista(x64)/7(x64) 64 bit driver catalog.
1g) pixci_x86_64.ko Loadable device driver for Linux w. 2.6 64 bit kernel and Intel 86_x64 and newer processors.

2a) XCLIBW95.DLL XCLIB DLL and Import library for Windows 95/98/ME. XCLIBW95.LIB (Compiler independent). XCLIBW95.EXP
2b) XCLIBWNT.DLL XCLIB DLL and Import library for Windows NT V4.0, XCLIBWNT.LIB 2000, XP, Vista, and 7 (Compiler independent). XCLIBWNT.EXP
2c) XCLIBW64.DLL XCLIB DLL and Import library for Windows XP(x64), XCLIBW64.LIB Vista(x64), and 7(x64) (Compiler independent). XCLIBW64.EXP
2d) XCLYBW95.DLL XCLIB-Lite DLL and Import library for Windows 95/98/ME. XCLYBW95.LIB (Compiler independent). XCLYBW95.EXP
2e) XCLYBWNT.DLL XCLIB-Lite DLL and Import library for Windows NT V4.0, XCLYBWNT.LIB 2000, XP, Vista, and 7 (Compiler independent). XCLYBWNT.EXP

2f) XCLBW1DF.LIB XCLIB Library, F model, for Tenberry+DOS, Watcom 32 Bit C/C++ V11.0.
2g) xclib_i386.a XCLIB Library, static link, for Linux, Intel i386, and GNU 'C'.
2h) xclib_x86_64.a XCLIB Library, static link, for Linux, Intel x86_64, and GNU 'C'.
3a) xcliball.h Master C include file for programs using XCLIB.
3b) pxlibsv.h cext.h Various C include files for XCLIB. pxlibvs.h cext_hp1.h Included by inclusion of XCLIBALL.H xclibsc.h cext_hp2.h xclibsv.h cext_hp4.h xclibvs.h cext_hps.h xclibver.h cext_hpe.h pximage.h pxerrno.h pxlibcam.h
4a) XCLIBEX1.C Source of example program demonstrating capture and video display on S/VGA and other features under Tenberry+DOS and Windows command line.
4b) XCLIBEX2.CPP Source of example programs demonstrating capture XCLIBEX2.RC and video display on S/VGA and other features XCLIBEX2.H under Windows. XCLIBEX4.CPP See comments in file(s) for compilation instructions. XCLIBEX4.RC XCLIBEX5.CPP XCLIBEXP.CPP
4c) XCLIBEXD.CPP Source of example program demonstrating XCLIBEXD.RC capture, video display, and control of the SILICON VIDEO® 1281, 1281C, 1310, 1310C, 2112, 2112C, 5C10, 5M10, 642M, 642C, 643M, 643C, 9M001, 9M001C, 9T001C, 9C10 cameras under Windows.
4d) XCLIBEX3.TXT Source of example program for Visual Basic, VB.NET, XCLIBEX6.TXT and C#.NET, respectively. XCLIBEX7.TXT Comments in file provide usage instructions. XCLIBEXD.TXT
4e) xclibel1.c Source of example programs demonstrating capture, xclibel3.c access to pixel data and other features under Linux. See comments in file(s) for compilation instructions.
5) XCLIBW95_VB.TXT Declarations for Visual Basic, VB.NET, Matlab, & LabView XCLIBW95_VBNET.TXT for Windows 95/98/ME. XCLIBW95_IMPORT.H XCLIBWNT_VB.TXT Declarations for Visual Basic, VB.NET, Matlab & LabView XCLIBWNT_VBNET.TXT for Windows NT/2000/XP/Vista/7. XCLIBWNT_IMPORT.H XCLIBW64_VBNET64.TXT Declarations for VB.NET, Matlab & LabView for Windows XP, Vista, 7 (x64). XCLIBW64_IMPORT.H
6) *.txt One or more ASCII text files containing distribution information, release notes, manual updates, etc.
7) xclib.htm Complete XCLIB C/C++ Library Reference Manual, in HTML format.
A) XCLIB C/C++ Library Reference Manual. Not included with XCLIB-Lite.
Items 1 through 7 distributed on diskettes or CD. Item A distributed on paper.

17. Footnotes

[1]
The XCLIB-Lite library supports only a single imaging board with a single functional unit.
[2]
Under Watcom V10.0, there is a well known bug in the ``C'' library's realloc; the pxrealloc is defined differently, and avoids calling realloc.
[3]
The include file(s) attempt to automatically identify C++ environments and thereby eliminate the need of using ''extern'', but the automatic detection may not work with all compilers or all compiler options. Inclusion of the explicit ''extern'' is recommended.
[4]
The XCLIB-Lite library does not provide a pointer into the actual image frame buffer. A pointer into the actual image frame buffer may not be available in all operating systems and/or frame buffer memory configurations.
[5]
While the XCLIB-Lite library allows opening only a single imaging board, or one half of a PIXCI® E1DB, E4DB, E8DB, ECB2, EL1DB, ELS2, SI2, or SV7 imaging board, or one quarter of a PIXCI® SI4, XCLIB-Lite does allow selecting which of several imaging boards, or functional half or quarter of an imaging board, is to be opened.
[6]
Compatibility requires that the XCAP and XCLIB be using the same version libraries.
[7]
The XCLIB-Lite library does not support the Structured Style Interface.
[8]
The XCLIB-Lite library does not support the pxd_videoFormatAsIncluded.
[9]
Aficionados of C++ will recognize this description as a ''virtual class'', and may think of it as such. However, for compatibility with ''C'' programs, the pximage is implemented as a structure from which member functions are called via function pointers. Unlike typical class objects, the pximage may be freely copied and destroyed; there are no class destructors.
[10]
E.g. must be ''constructed'', for C++ aficionados.
[11]
See the ''Intel Chipset 4 GB System Memory Support'' white paper by Intel Corp.
[12]
Also referred to as a video setup file.
[13]
The XCLIB-Lite library supports only a single imaging board with a single functional unit. The SCF+ functions also support multiple, non-identical, imaging boards and are similar to the SCF functions.
[14]
The XCLIB-Lite library does not provide pxd_xclibEscape and pxd_xclibEscaped.
[15]
The time provided by the operating system is recorded by software after the frame is captured, and provided on request. No claim is made regarding the operating system clock's accuracy, repeatability, or resolution, nor the latency between the end of frame capture and software's recording of the time.
[16]
The time provided by the operating system is recorded by software after the frame is captured, and provided on request. No claim is made regarding the operating system clock's accuracy, repeatability, or resolution, nor the latency between the end of frame capture and software's recording of the time.
[17]
Unlike the similar pxd_bdim() function of the XCOBJ library, the number of bits in a single color component is returned.
[18]
Unlike the similar pxd_ylace() function of the XCOBJ library, the number of fields is returned, not a boolean as to whether the image frame buffer provides storage for both fields.
[19]
Unlike the similar pxd_ydim() function of the XCOBJ library, the number of pixels in a column including all fields of the frame buffer is returned.
[20]
A reminder regarding file names under DOS and Windows: C/C++ interprets any backslash (''\'') in a character string as a special escape character (see The C Programming Language by Kernighan & Ritchie or The C++ Programming Language by Stroustrup). Either use two backslashes which C/C++ translates to a single backslash, or use a forward slash (''/''), which DOS and Windows accept in liu of a backslash.
[21]
A reminder regarding file names under DOS and Windows: C/C++ interprets any backslash (''\'') in a character string as a special escape character (see The C Programming Language by Kernighan & Ritchie or The C++ Programming Language by Stroustrup). Either use two backslashes which C/C++ translates to a single backslash, or use a forward slash (''/''), which DOS and Windows accept in liu of a backslash.
[22]
A reminder regarding file names under DOS and Windows: C/C++ interprets any backslash (''\'') in a character string as a special escape character (see The C Programming Language by Kernighan & Ritchie or The C++ Programming Language by Stroustrup). Either use two backslashes which C/C++ translates to a single backslash, or use a forward slash (''/''), which DOS and Windows accept in liu of a backslash.
[23]
The pxd_renderDirectVideoInit and related functions currently support only a single imaging board.
[24]
The pxd_renderDirectVideoLive and related functions currently supports only a single imaging board.
[25]
The stated use of lrx-ulx and lry-uly is not complete and precise, as it doesn't take into account the lrx=-1 or lry=-1 option.
[26]
For monochrome images and S/VGA adapters providing 8 bits per pixel and a palette, the rendering could be improved by using the Windows CreatePalette, SelectPalette, and RealizePalette functions to define more grey levels, at the expense of colors used elsewhere on the desktop.
[27]
See the Camera Link V1.1 specification for a detailed description of these functions' parameters.
[28]
Obviously these functions take some non-zero amount of time to execute. The term ''immediately'' is used relative to video timing and events; these functions return without waiting for video events.
[29]
For all imaging boards, triggered sequence capture can also be implemented by the application: Record current value of the General Purpose Input or Trigger, wait for the value to change, and invoke pxd_goLiveSeq. Or, record current value of the General Purpose Input or Trigger, invoke pxd_goLiveSeq, wait for the value to change and invoke pxd_goUnLive.

The integrated pxd_goLiveSeqTrig function is particularly beneficial when used with very high speed cameras so as to eliminate the application's latency in responding to the General Purpose Input or Trigger.

[30]
The XCLIB-Lite library does not support the SCF+ Style Interface.
[31]
The XCLIB-Lite library does not support the Structured Style Interface.
[32]
A reminder regarding file names under DOS and Windows: C/C++ interprets any backslash (''\'') in a character string as a special escape character (see The C Programming Language by Kernighan & Ritchie or The C++ Programming Language by Stroustrup). Either use two backslashes which C/C++ translates to a single backslash, or use a forward slash (''/''), which DOS and Windows accept in liu of a backslash.
[33]
A reminder regarding file names under DOS and Windows: C/C++ interprets any backslash (''\'') in a character string as a special escape character (see The C Programming Language by Kernighan & Ritchie or The C++ Programming Language by Stroustrup). Either use two backslashes which C/C++ translates to a single backslash, or use a forward slash (''/''), which DOS and Windows accept in liu of a backslash.
[34]
The ''CCCC'' is a common Windows macro. For other environments use:
#define CCCC(a,b,c,d)   (((uint32)(a)<<24) | ((uint32)(b)<<16) | ((c)<<8) | (d))
[35]
A reminder regarding file names under DOS and Windows: C/C++ interprets any backslash (''\'') in a character string as a special escape character (see The C Programming Language by Kernighan & Ritchie or The C++ Programming Language by Stroustrup). Either use two backslashes which C/C++ translates to a single backslash, or use a forward slash (''/''), which DOS and Windows accept in liu of a backslash.
[36]
The XCLIB-Lite library does not support the PXIPL Image Processing Library or the pximage and pximage3 interfaces.
[37]
The pximage_file, and pximage_memory are provided with the PXIPL Image Processing Library.
[38]
These allowed variations do not complicate the typical application program. When reading and writing pixie values, it typically isn't necessary to worry about left or right justification, or the following topic of dirty and clean bits; for most pximage device drivers, pixel reads/writes can produce/accept data in the form that the application program requests/generates. These detailed specifications allow an application program to optionally improve efficiency by using the data in its natural format, rather than having the data converted.
[39]
This particular d.pixelhint begs for an explanation. When used with ''uchar'' pixie types, and multiple pixels read into a ''uchar'' buffer, on Intel machines with little-endian architecture (least significant byte of multi-byte word has lowest address), with the buffer typecast to the Windows ''COLORREF'' type, the resulting pixels are compatible with Windows' RGB() data type, as well as many SVGA cards operating in RGB 32 bit per pixel mode.
[40]
For ::imap, the information provided is not about the execution time of ::imap itself, but rather information regarding use of the pointer returned by ::imap.
[41]
For example, a pximage (or pximage3) which references image buffers on a SILICON VIDEO® or a 4MEG VIDEO imaging board might provide access only when the board is not capturing or displaying video.
[42]
For example, on a pximage (or pximage3) which references image buffers on a SILICON VIDEO® or a 4MEG VIDEO imaging board, where video was off during ::imapset and then activated before ::imap. The direct access pointer provided by ::imap could even be invalidated after receipt from ::imap, such as by activating video. The pximage (or pximage3) provides no method of handling invalidation; during use of the ::imap direct access pointer, the user must avoid using services beyond the pximage's (or pximage3's) domain which adversely affect the state of the underlying device.
[43]
With the exception of the Silicon Imaging 3170 and 3171 cameras, and the SILICON VIDEO® 10C-CL and 10M-CL cameras, which are initialized to the manufacturer's suggested default mode via the Camera Link serial port.
[44]
Compatibility requires that the XCAP and XCLIB are using the same version libraries.
[45]
This example of programming a non-EPIX® imaging product is provided without warranties of any kind.
[46]
Compatibility requires that the XCAP and XCLIB are using the same version libraries.
[47]
A newer release of the XCLIB library and XCAP may be required.
[48]
Compatibility requires that the XCAP and XCLIB be using the same version libraries.
[49]
The XCLIB-Lite library does not support the pxd_videoFormatAsIncluded.
[50]
The requirement for a signature is intended to prevent an imported Video Format Configuration, which contains a pxvidphys, from accidentally being re-used to specify a user space or bus physical target. Closing and re-opening the XCLIB library, even within the same application or process requires new signatures!
[51]
A ''secondary surface'' is a DirectDraw term.

Index

  • ::aeiou
  • ::bxta
  • ::bxtp
  • ::bxts
  • ::bxtw
  • ::imap
  • ::imapr
  • ::imapset
  • ::iolen
  • ::ioread
  • ::iorite
  • ::ioset
  • ::iowait
  • ::pxaux.bufferLoadStream
  • ::pxaux.bufferSaveStream
  • ::pxaux.errorCodeString
  • ::pxaux.faultMessageBox
  • ::pxaux.faultPrintf
  • ::pxaux.freeDIB
  • ::pxaux.imageLoadBmp
  • ::pxaux.imageLoadTiff
  • ::pxaux.imageReadUChar
  • ::pxaux.imageReadUInt
  • ::pxaux.imageReadUShort
  • ::pxaux.imageSaveBmp
  • ::pxaux.imageSavePcx
  • ::pxaux.imageSaveTga
  • ::pxaux.imageSaveTiff
  • ::pxaux.imageWriteUChar
  • ::pxaux.imageWriteUInt
  • ::pxaux.imageWriteUShort
  • ::pxaux.makeDIB
  • ::pxaux.StretchDIBits
  • ::pxdev.freeImap
  • ::pxdev.getDevInfo
  • ::pxdev.getFault
  • ::pxdev.getImap
  • ::pxdev.getVidStatus
  • ::pxdev.getVidStatusValue
  • ::pxdev.io
  • ::pxdev.ioctl
  • ::pxdev.iosparse
  • ::pxlib.allocStateCopy
  • ::pxlib.compareStateCopy
  • ::pxlib.defineState
  • ::pxlib.deleteState
  • ::pxlib.exportStateCopy
  • ::pxlib.freeStateCopy
  • ::pxlib.getAllocState
  • ::pxlib.getState
  • ::pxlib.goingBufStatus
  • ::pxlib.importAllocStateCopy
  • ::pxlib.importStateCopy
  • ::pxlib.initAllocStateCopy
  • ::pxlib.initFilteredPximage
  • ::pxlib.initFilteredPximage3
  • ::pxlib.initPximage
  • ::pxlib.initPximage3
  • ::pxlib.initStateCopy
  • ::setLivePhys
  • ::setLiveSeqBuf
  • ::setLiveTrigBuf
  • ::xcdev.getDevInfo
  • ::xcdev.getDevParms
  • ::xcdev.getGpin
  • ::xcdev.getGpout
  • ::xcdev.getLiveStatus
  • ::xcdev.getVidStatus
  • ::xcdev.setAbortLive
  • ::xcdev.setCameraConfig
  • ::xcdev.setDevParms
  • ::xcdev.setGpin
  • ::xcdev.setGpout
  • ::xcdev.setLiveBuf
  • ::xcdev.setLivePairBuf
  • ::xcdev.setSnapBuf
  • ::xcdev.setSnapPairBuf
  • ::xcdev.setUnLive
  • ::xcdev.setVideoAdjust
  • ::xcdev.setVideoConfig
  • ::xclib.fillStateCopy
  • ::xclib.fixxStateCopy
  • ::xclib.signStateCopy
  • ::xwind
  • _cfunacc
  • _cfunfcc
  • _cfunvcc
  • _farimap
  • Abort Live/Snap into Frame Buffer
  • Adjust Video Configuration
  • AEC
  • AGC
  • Allocate Copy of Video State
  • BMP Format
  • BMP Format
  • Buffer's Capture Field Count
  • Buffer's Capture Field Count
  • Buffer's Capture General Purpose Input
  • Buffer's Capture General Purpose Input
  • Buffer's Capture System Time
  • Buffer's Capture System Time
  • Buffer's Capture System Time
  • Buffer's Capture System Time
  • Camera Control: SILICON VIDEO® 10C-CL/10M-CL
  • Camera Control: SILICON VIDEO® 10C6/10M6
  • Camera Control: SILICON VIDEO® 1281
  • Camera Control: SILICON VIDEO® 1310
  • Camera Control: SILICON VIDEO® 2112
  • Camera Control: SILICON VIDEO® 5M10/5C10
  • Camera Control: SILICON VIDEO® 642
  • Camera Control: SILICON VIDEO® 643
  • Camera Control: SILICON VIDEO® 9C10
  • Camera Control: SILICON VIDEO® 9M001
  • Camera Control: SILICON VIDEO® 9T001
  • Camera Control: SILICON VIDEO® HAS21
  • Camera Control: SILICON VIDEO® WGA
  • Camera Link CC Output Signal: Get
  • Camera Link CC Output Signal: Get
  • Camera Link CC Output Signal: Set
  • Camera Link CC Output Signal: Set
  • Camera Link Serial: Close
  • Camera Link Serial: Error Text
  • Camera Link Serial: Get Baud Rates
  • Camera Link Serial: Initialize
  • Camera Link Serial: Manufacturer ID
  • Camera Link Serial: Ports ID
  • Camera Link Serial: Ports
  • Camera Link Serial: Read Available
  • Camera Link Serial: Read Flush
  • Camera Link Serial: Read
  • Camera Link Serial: Set Baud Rate
  • Camera Link Serial: Write
  • clFlushPort
  • clGetErrorText
  • clGetManufacturerInfo
  • clGetNumBytesAvail
  • clGetNumSerialPorts
  • clGetSerialPortIdentifier
  • clGetSupportedBaudRates
  • clSerialClose
  • clSerialInit
  • clSerialRead
  • clSerialWrite
  • clSetBaudRate
  • Compare Pair of Video State Copies
  • Compilation
  • ddch.len
  • ddch.mos
  • Declare Instance of Video Format Configuration Structures
  • Declare Instance of Video Format Configuration Structures
  • Define Video State
  • Delete Video State
  • Device Control
  • DOS
  • DOS: Register Callback upon Captured Video Field
  • DOS: Register Callback upon Captured Video Field
  • DOS: Register Callback upon Fault
  • DOS: Register Callback upon Fault
  • DOS: Register Callback upon General Purpose Trigger
  • DOS: Register Callback upon General Purpose Trigger
  • DOS: Register Callback upon Serial
  • DOS: Register Callback upon Serial
  • DOS: Register Callback upon Video Field
  • DOS: Register Callback upon Video Field
  • DOS: Unregister Callback upon Captured Video Field
  • DOS: Unregister Callback upon Captured Video Field
  • DOS: Unregister Callback upon Fault
  • DOS: Unregister Callback upon Fault
  • DOS: Unregister Callback upon General Purpose Trigger
  • DOS: Unregister Callback upon General Purpose Trigger
  • DOS: Unregister Callback upon Serial
  • DOS: Unregister Callback upon Serial
  • DOS: Unregister Callback upon Video Field
  • DOS: Unregister Callback upon Video Field
  • Driver Configuration Parameters
  • EMM386
  • Errors: Check & Report Faults
  • Errors: Check & Report Faults
  • Errors: Check & Report Faults
  • Errors: Check & Report Faults
  • Errors: Check & Report Faults
  • Errors: Check & Report Faults
  • Errors: Translate Error Code to String
  • Errors: Translate Error Code to String
  • Escape to Access Structured Interface Services
  • Escape to Access Structured Interface Services
  • Escaped to Access Structured Interface Services
  • Escaped to Access Structured Interface Services
  • Export Copy of Video State
  • Fill Video State
  • Fixup Video State
  • Free Copy of Video State
  • Free Pointer into Imaging Board Memory
  • Functional Units
  • General Purpose Input Signal: Reset
  • General Purpose Input Signal: Reset
  • General Purpose Input Signal: Reset
  • General Purpose Input Signal: Sense
  • General Purpose Input Signal: Sense
  • General Purpose Input Signal: Sense
  • General Purpose Output Signal: Get
  • General Purpose Output Signal: Get
  • General Purpose Output Signal: Get
  • General Purpose Output Signal: Set
  • General Purpose Output Signal: Set
  • General Purpose Output Signal: Set
  • General Purpose Trigger Input Count: Sense
  • General Purpose Trigger Input Count: Sense
  • Get & Allocate Video State
  • Get A/D Color Gains A
  • Get A/D Color Gains A
  • Get A/D Color Gains A
  • Get A/D Color Gains A
  • Get A/D Color Gains B
  • Get A/D Color Gains B
  • Get A/D Color Gains B
  • Get A/D Color Gains B
  • Get A/D Color Offsets A
  • Get A/D Color Offsets A
  • Get A/D Color Offsets B
  • Get A/D Color Offsets B
  • Get A/D Gain A
  • Get A/D Gain A
  • Get A/D Gain B
  • Get A/D Gain B
  • Get Current Buffer Status
  • Get Current Video Status
  • Get Current Video Status Value
  • Get Driver Parameters
  • Get EXSYNC Counter Value
  • Get EXSYNC Counter Value
  • Get EXSYNC Mode Bits
  • Get EXSYNC Mode Bits
  • Get Extended Imaging Board and Driver Information
  • Get Extended Video Status
  • Get Frame Buffer Image Aspect Ratio
  • Get Frame Buffer Image Aspect Ratio
  • Get Frame Buffer Image Aspect Ratio
  • Get Frame Buffer Image Aspect Ratio
  • Get Frame Buffer Image Bit Depth
  • Get Frame Buffer Image Bit Depth
  • Get Frame Buffer Image Bit Depth
  • Get Frame Buffer Image Bit Depth
  • Get Frame Buffer Image Color Components
  • Get Frame Buffer Image Color Components
  • Get Frame Buffer Image Color Components
  • Get Frame Buffer Image Color Components
  • Get Frame Buffer Image Count
  • Get Frame Buffer Image Count
  • Get Frame Buffer Image Count
  • Get Frame Buffer Image Count
  • Get Frame Buffer Image Field Dimension
  • Get Frame Buffer Image Field Dimension
  • Get Frame Buffer Image Field Dimension
  • Get Frame Buffer Image Field Dimension
  • Get Frame Buffer Image Horizontal Dimension
  • Get Frame Buffer Image Horizontal Dimension
  • Get Frame Buffer Image Horizontal Dimension
  • Get Frame Buffer Image Horizontal Dimension
  • Get Frame Buffer Image Vertical Dimension
  • Get Frame Buffer Image Vertical Dimension
  • Get Frame Buffer Image Vertical Dimension
  • Get Frame Buffer Image Vertical Dimension
  • Get Imaging Board's Frame Buffer Size
  • Get Imaging Board's Frame Buffer Size
  • Get Imaging Board's Model
  • Get Imaging Board's Model
  • Get Imaging Board's Submodel
  • Get Imaging Board's Submodel
  • Get Imaging Board and Driver Information
  • Get Imaging Board Driver's System Time
  • Get Imaging Board Driver's System Time
  • Get Imaging Board Driver's System Time Units
  • Get Imaging Board Driver's System Time Units
  • Get Imaging Board Driver ID
  • Get Imaging Board Driver ID
  • Get Imaging Board Include Files ID
  • Get Imaging Board Include Files ID
  • Get Imaging Board Library ID
  • Get Imaging Board Library ID
  • Get Imaging Board Library ID
  • Get Imaging Board Unit Count
  • Get Imaging Board Unit Count
  • Get Live/Snap Status
  • Get PRIN Counter Value
  • Get PRIN Counter Value
  • Get PRINC Mode Bits
  • Get PRINC Mode Bits
  • Get PXIMAGE: Access Imaging Board Frame Buffer
  • Get PXIMAGE: Access Imaging Board Frame Buffer
  • Get PXIMAGE: Access Imaging Board Frame Buffer
  • Get PXIMAGE: Access Imaging Board Frame Buffer
  • Get PXIMAGE: Release Access to Imaging Board Frame Buffers
  • Get PXIMAGE: Release Access to Imaging Board Frame Buffers
  • Get PXIMAGE3: Access Imaging Board Frame Buffers
  • Get PXIMAGE3: Access Imaging Board Frame Buffers
  • Get PXIMAGE3: Access Imaging Board Frame Buffers
  • Get PXIMAGE3: Access Imaging Board Frame Buffers
  • Get PXIMAGE3: Release Access to Imaging Board Frame Buffers
  • Get PXIMAGE3: Release Access to Imaging Board Frame Buffers
  • Get SILICON VIDEO AEC Exposure
  • Get SILICON VIDEO AEC Exposure
  • Get SILICON VIDEO AGC A Gain
  • Get SILICON VIDEO AGC A Gain
  • Get SILICON VIDEO AGC B Gain
  • Get SILICON VIDEO AGC B Gain
  • Get SILICON VIDEO Aoi Height
  • Get SILICON VIDEO Aoi Height
  • Get SILICON VIDEO Aoi Left Edge
  • Get SILICON VIDEO Aoi Left Edge
  • Get SILICON VIDEO Aoi Top Edge
  • Get SILICON VIDEO Aoi Top Edge
  • Get SILICON VIDEO Aoi Width
  • Get SILICON VIDEO Aoi Width
  • Get SILICON VIDEO Color Gains A
  • Get SILICON VIDEO Color Gains A
  • Get SILICON VIDEO Color Gains B
  • Get SILICON VIDEO Color Gains B
  • Get SILICON VIDEO Color Offset A
  • Get SILICON VIDEO Color Offset A
  • Get SILICON VIDEO Color Offset B
  • Get SILICON VIDEO Color Offset B
  • Get SILICON VIDEO Color Offsets A
  • Get SILICON VIDEO Color Offsets A
  • Get SILICON VIDEO Color Offsets B
  • Get SILICON VIDEO Color Offsets B
  • Get SILICON VIDEO Controlled Frame Rate
  • Get SILICON VIDEO Controlled Frame Rate
  • Get SILICON VIDEO Controlled Trigger Mode
  • Get SILICON VIDEO Controlled Trigger Mode
  • Get SILICON VIDEO Controlled Video Mode
  • Get SILICON VIDEO Controlled Video Mode
  • Get SILICON VIDEO Exposure
  • Get SILICON VIDEO Exposure
  • Get SILICON VIDEO Frame Period
  • Get SILICON VIDEO Frame Period
  • Get SILICON VIDEO Gain A
  • Get SILICON VIDEO Gain A
  • Get SILICON VIDEO Gain B
  • Get SILICON VIDEO Gain B
  • Get SILICON VIDEO Min/Max AEC Exposure
  • Get SILICON VIDEO Min/Max AEC Exposure
  • Get SILICON VIDEO Min/Max AGC A Gain
  • Get SILICON VIDEO Min/Max AGC A Gain
  • Get SILICON VIDEO Min/Max AGC B Gain
  • Get SILICON VIDEO Min/Max AGC B Gain
  • Get SILICON VIDEO Min/Max AOI Height
  • Get SILICON VIDEO Min/Max AOI Height
  • Get SILICON VIDEO Min/Max AOI Width
  • Get SILICON VIDEO Min/Max AOI Width
  • Get SILICON VIDEO Min/Max Controlled Frame Rate
  • Get SILICON VIDEO Min/Max Controlled Frame Rate
  • Get SILICON VIDEO Min/Max Exposure
  • Get SILICON VIDEO Min/Max Exposure
  • Get SILICON VIDEO Min/Max Frame Period
  • Get SILICON VIDEO Min/Max Frame Period
  • Get SILICON VIDEO Min/Max Gain A
  • Get SILICON VIDEO Min/Max Gain A
  • Get SILICON VIDEO Min/Max Gain B
  • Get SILICON VIDEO Min/Max Gain B
  • Get SILICON VIDEO Min/Max Offset A
  • Get SILICON VIDEO Min/Max Offset A
  • Get SILICON VIDEO Min/Max Offset B
  • Get SILICON VIDEO Min/Max Offset B
  • Get SILICON VIDEO Min/Max Pixel Clock Frequency
  • Get SILICON VIDEO Min/Max Pixel Clock Frequency
  • Get SILICON VIDEO Pixel Clock Frequency
  • Get SILICON VIDEO Pixel Clock Frequency
  • Get SILICON VIDEO Scan Direction
  • Get SILICON VIDEO Scan Direction
  • Get SILICON VIDEO Subsample
  • Get SILICON VIDEO Subsample
  • Get SILICON VIDEO Video Mode
  • Get SILICON VIDEO Video Mode
  • Get Video Brightness
  • Get Video Brightness
  • Get Video Contrast
  • Get Video Contrast
  • Get Video Field Characteristic
  • Get Video Field Characteristic
  • Get Video Field Characteristic
  • Get Video Field Characteristic
  • Get Video Field Count
  • Get Video Field Count
  • Get Video Hue
  • Get Video Hue
  • Get Video Input Multiplexer
  • Get Video Input Multiplexer
  • Get Video State
  • Get Video U Saturation
  • Get Video U Saturation
  • Get Video V Saturation
  • Get Video V Saturation
  • Graphics Display System
  • Import & Allocate Copy of Video State
  • Import Copy of Video State
  • Inclusions
  • Initialize Instance of Video Format Configuration Structures
  • Initialize Instance of Video Format Configuration Structures
  • Initiate Continuous Alternate Capture into Frame Buffers
  • Initiate Continuous Capture into Frame Buffer
  • Initiate Continuous Capture into Memory Space
  • Initiate Sequence Capture into Frame Buffers
  • Initiate Snap into Frame Buffer
  • Initiate Snap Pair into Frame Buffers
  • Initiate Triggered Capture into Frame Buffer
  • Last Captured Buffer: Buffer Number
  • Last Captured Buffer: Buffer Number
  • Last Captured Buffer: Field Count
  • Last Captured Buffer: Field Count
  • Last Captured Buffer: System Time
  • Last Captured Buffer: System Time
  • Libraries
  • Linux
  • Linux: Register Signal upon Captured Video Field
  • Linux: Register Signal upon Captured Video Field
  • Linux: Register Signal upon Fault
  • Linux: Register Signal upon Fault
  • Linux: Register Signal upon General Purpose Trigger
  • Linux: Register Signal upon General Purpose Trigger
  • Linux: Register Signal upon Serial
  • Linux: Register Signal upon Serial
  • Linux: Register Signal upon Video Field
  • Linux: Register Signal upon Video Field
  • Linux: Unregister Signal upon Captured Video Field
  • Linux: Unregister Signal upon Captured Video Field
  • Linux: Unregister Signal upon Fault
  • Linux: Unregister Signal upon Fault
  • Linux: Unregister Signal upon General Purpose Trigger
  • Linux: Unregister Signal upon General Purpose Trigger
  • Linux: Unregister Signal upon Serial
  • Linux: Unregister Signal upon Serial
  • Linux: Unregister Signal upon Video Field
  • Linux: Unregister Signal upon Video Field
  • Load Frame Buffers as Stream
  • Load Frame Buffers
  • Load Frame Buffers
  • Load Image: BMP Format
  • Load Image: BMP Format
  • Load Image: BMP Format
  • Load Image: TIFF Format
  • Load Image: TIFF Format
  • Load Image: TIFF Format
  • Obtain Filtered pximage Access into Imaging Board Memory
  • Obtain Filtered pximage3 Access into Imaging Board Memory
  • Obtain Last Logged Fault
  • Obtain Pointer into Imaging Board Memory
  • Obtain pximage Access into Imaging Board Memory
  • Obtain pximage3 Access into Imaging Board Memory
  • PCX Format
  • PCX Format
  • PIXCI® Imaging Board Library: Create Instance
  • PIXCI® Imaging Board Library: Uncreate Instance
  • PIXCI® Imaging Board: Close
  • PIXCI® Imaging Board: Close
  • PIXCI® Imaging Board: Open and Set Video Format Configuration
  • PIXCI® Imaging Board: Open and Set Video Format Configuration
  • PIXCI® Imaging Board: Structured Close
  • PIXCI® Imaging Board: Structured Open
  • Printing
  • pxabortfunc_t
  • pxauxservice, struct
  • pxauxservice_s
  • pxbuffer_t
  • pxbufstatus, struct
  • pxbufstatus_s
  • pxbufstatusfile, struct
  • pxbufstatusfile_s
  • PXCam_SILICONVIDEO032
  • PXCam_SILICONVIDEO1281
  • PXCam_SILICONVIDEO1310
  • PXCam_SILICONVIDEO2112
  • PXCam_SILICONVIDEO642
  • PXCam_SILICONVIDEO643
  • PXCam_SILICONVIDEO9M001
  • PXCam_SILICONVIDEO9M001
  • PXCam_SILICONVIDEO9M001
  • PXCam_SILICONVIDEO9M001
  • PXCam_SILICONVIDEO9M001
  • PXCam_SILICONVIDEO9M001
  • PXCam_SILICONVIDEOHAS2
  • PXCam_SV032State, struct
  • PXCam_SV032State_s
  • PXCam_SV1281State, struct
  • PXCam_SV1281State_s
  • PXCam_SV1310State, struct
  • PXCam_SV1310State_s
  • PXCam_SV2112State, struct
  • PXCam_SV2112State_s
  • PXCam_SV642State, struct
  • PXCam_SV642State_s
  • PXCam_SV643State, struct
  • PXCam_SV643State_s
  • PXCam_SV9M001State, struct
  • PXCam_SV9M001State_s
  • PXCam_SVHAS2State, struct
  • PXCam_SVHAS2State_s
  • pxcamcntl, struct
  • pxcamcntl_s
  • pxcoord_t
  • pxcoord_t
  • pxd_buffersFieldCount
  • pxd_buffersGPIn
  • pxd_buffersSysTicks
  • pxd_buffersSysTicks2
  • pxd_capturedBuffer
  • pxd_capturedFieldCount
  • pxd_capturedSysTicks
  • pxd_defineImage
  • pxd_defineImage3
  • pxd_definePximage
  • pxd_definePximage3
  • pxd_definePximage3Free
  • pxd_definePximageFree
  • pxd_doSnap
  • pxd_eventCapturedFieldClose
  • pxd_eventCapturedFieldClose
  • pxd_eventCapturedFieldClose
  • pxd_eventCapturedFieldCreate
  • pxd_eventCapturedFieldCreate
  • pxd_eventCapturedFieldCreate
  • pxd_eventCapturedFieldCreate2
  • pxd_eventFaultClose
  • pxd_eventFaultClose
  • pxd_eventFaultClose
  • pxd_eventFaultCreate
  • pxd_eventFaultCreate
  • pxd_eventFaultCreate
  • pxd_eventFaultCreate2
  • pxd_eventFieldClose
  • pxd_eventFieldClose
  • pxd_eventFieldClose
  • pxd_eventFieldCreate
  • pxd_eventFieldCreate
  • pxd_eventFieldCreate
  • pxd_eventFieldCreate2
  • pxd_eventGPTriggerClose
  • pxd_eventGPTriggerClose
  • pxd_eventGPTriggerClose
  • pxd_eventGPTriggerCreate
  • pxd_eventGPTriggerCreate
  • pxd_eventGPTriggerCreate
  • pxd_eventGPTriggerCreate2
  • pxd_eventSerialClose
  • pxd_eventSerialClose
  • pxd_eventSerialClose
  • pxd_eventSerialCreate
  • pxd_eventSerialCreate
  • pxd_eventSerialCreate
  • pxd_getAdcGainA
  • pxd_getAdcGainB
  • pxd_getAdcGainsA
  • pxd_getAdcGainsB
  • pxd_getAdcOffsetA
  • pxd_getAdcOffsetB
  • pxd_getAdcOffsetsA
  • pxd_getAdcOffsetsB
  • pxd_getBrightness
  • pxd_getCameraLinkCCOut
  • pxd_getContrast
  • pxd_getExsync
  • pxd_getExsyncMode
  • pxd_getGPIn
  • pxd_getGPOut
  • pxd_getGPTrigger
  • pxd_getHue
  • pxd_getPrin
  • pxd_getPrincMode
  • pxd_getUGain
  • pxd_getVGain
  • pxd_getVidMux
  • pxd_goAbortLive
  • pxd_goLive
  • pxd_goLivePair
  • pxd_goLiveSeq
  • pxd_goLiveSeqTrig
  • pxd_goLiveTrig
  • pxd_goneLive
  • pxd_goSnap
  • pxd_goSnapPair
  • pxd_goUnLive
  • pxd_imageAspectRatio
  • pxd_imageAspectRatios
  • pxd_imageBdim
  • pxd_imageBdims
  • pxd_imageCdim
  • pxd_imageCdims
  • pxd_imageIdim
  • pxd_imageIdims
  • pxd_imageXdim
  • pxd_imageXdims
  • pxd_imageYdim
  • pxd_imageYdims
  • pxd_imageZdim
  • pxd_imageZdims
  • pxd_infoDriverId
  • pxd_infoIncludeId
  • pxd_infoLibraryId
  • pxd_infoMemsize
  • pxd_infoModel
  • pxd_infoSubmodel
  • pxd_infoSysTicks
  • pxd_infoSysTicksUnits
  • pxd_infoUnits
  • pxd_loadBmp
  • pxd_loadRawBuffers
  • pxd_loadTiff
  • pxd_mesgErrorCode
  • pxd_mesgFault
  • pxd_mesgFaultText
  • pxd_PIXCIclose
  • pxd_PIXCIopen
  • pxd_readuchar
  • pxd_readushort
  • pxd_renderDIBCreate
  • pxd_renderDIBFree
  • pxd_renderDirectVideoDone
  • pxd_renderDirectVideoInit
  • pxd_renderDirectVideoLive
  • pxd_renderDirectVideoUnLive
  • pxd_renderStretchDIBits
  • pxd_saveBmp
  • pxd_savePcx
  • pxd_saveRawBuffers
  • pxd_saveTga
  • pxd_saveTiff
  • pxd_serialConfigure
  • pxd_serialRead
  • pxd_serialWrite
  • pxd_setAdcColorGainOffsets
  • pxd_setAdcGainOffset
  • pxd_setCameraLinkCCOut
  • pxd_setContrastBrightness
  • pxd_setExsyncPrin
  • pxd_setExsyncPrincMode
  • pxd_setGPIn
  • pxd_setGPOut
  • pxd_setHueSaturation
  • pxd_setImageBrightBalance
  • pxd_setImageDarkBalance
  • pxd_setVidMux
  • pxd_SILICONVIDEO_getAec
  • pxd_SILICONVIDEO_getAgcA
  • pxd_SILICONVIDEO_getAgcB
  • pxd_SILICONVIDEO_getAoiHeight
  • pxd_SILICONVIDEO_getAoiLeft
  • pxd_SILICONVIDEO_getAoiTop
  • pxd_SILICONVIDEO_getAoiWidth
  • pxd_SILICONVIDEO_getCtrlFrameRate
  • pxd_SILICONVIDEO_getCtrlTriggerMode
  • pxd_SILICONVIDEO_getCtrlVideoMode
  • pxd_SILICONVIDEO_getExposure
  • pxd_SILICONVIDEO_getFramePeriod
  • pxd_SILICONVIDEO_getGainA
  • pxd_SILICONVIDEO_getGainB
  • pxd_SILICONVIDEO_getGainsA
  • pxd_SILICONVIDEO_getGainsB
  • pxd_SILICONVIDEO_getMinMaxAec
  • pxd_SILICONVIDEO_getMinMaxAgcA
  • pxd_SILICONVIDEO_getMinMaxAgcB
  • pxd_SILICONVIDEO_getMinMaxAoiHeight
  • pxd_SILICONVIDEO_getMinMaxAoiWidth
  • pxd_SILICONVIDEO_getMinMaxCtrlFrameRate
  • pxd_SILICONVIDEO_getMinMaxExposure
  • pxd_SILICONVIDEO_getMinMaxFramePeriod
  • pxd_SILICONVIDEO_getMinMaxGainA
  • pxd_SILICONVIDEO_getMinMaxGainB
  • pxd_SILICONVIDEO_getMinMaxOffsetA
  • pxd_SILICONVIDEO_getMinMaxOffsetB
  • pxd_SILICONVIDEO_getMinMaxPixelClock
  • pxd_SILICONVIDEO_getOffsetA
  • pxd_SILICONVIDEO_getOffsetB
  • pxd_SILICONVIDEO_getOffsetsA
  • pxd_SILICONVIDEO_getOffsetsB
  • pxd_SILICONVIDEO_getPixelClock
  • pxd_SILICONVIDEO_getScanDirection
  • pxd_SILICONVIDEO_getSubsample
  • pxd_SILICONVIDEO_getVideoMode
  • pxd_SILICONVIDEO_setAxC
  • pxd_SILICONVIDEO_setCtrlRates
  • pxd_SILICONVIDEO_setExposure
  • pxd_SILICONVIDEO_setExposureColorGainOffsets
  • pxd_SILICONVIDEO_setExposureGainOffset
  • pxd_SILICONVIDEO_setResolutionAndTiming
  • pxd_SILICONVIDEO_setVideoAndTriggerMode
  • pxd_SV1281_getAoiLeft
  • pxd_SV1281_getAoiTop
  • pxd_SV1281_getCtrlFrameRate
  • pxd_SV1281_getCtrlTriggerMode
  • pxd_SV1281_getCtrlVideoMode
  • pxd_SV1281_getExposure
  • pxd_SV1281_getGain
  • pxd_SV1281_getMinMaxExposure
  • pxd_SV1281_getOffset
  • pxd_SV1281_getPixelClock
  • pxd_SV1281_getVideoMode
  • pxd_SV1281_setCtrlRate
  • pxd_SV1281_setExposureGainOffset
  • pxd_SV1281_setResolutionAndTiming
  • pxd_SV1281_setVideoAndTriggerMode
  • pxd_SV1310_getAoiLeft
  • pxd_SV1310_getAoiTop
  • pxd_SV1310_getColorGain
  • pxd_SV1310_getCtrlFrameRate
  • pxd_SV1310_getCtrlTriggerMode
  • pxd_SV1310_getCtrlVideoMode
  • pxd_SV1310_getExposure
  • pxd_SV1310_getFramePeriod
  • pxd_SV1310_getGain
  • pxd_SV1310_getMinMaxExposure
  • pxd_SV1310_getOffset
  • pxd_SV1310_getPixelClock
  • pxd_SV1310_getReadoutDirection
  • pxd_SV1310_getSubsample
  • pxd_SV1310_getVideoMode
  • pxd_SV1310_setColorGain
  • pxd_SV1310_setCtrlRate
  • pxd_SV1310_setExposureGainOffset
  • pxd_SV1310_setResolutionAndTiming
  • pxd_SV1310_setVideoAndTriggerMode
  • pxd_SV2112_getAoiLeft
  • pxd_SV2112_getAoiTop
  • pxd_SV2112_getCtrlExposure
  • pxd_SV2112_getCtrlFrameRate
  • pxd_SV2112_getCtrlTriggerMode
  • pxd_SV2112_getCtrlVideoMode
  • pxd_SV2112_getDecimation
  • pxd_SV2112_getExposure
  • pxd_SV2112_getGain
  • pxd_SV2112_getMinMaxCtrlExposure
  • pxd_SV2112_getMinMaxExposure
  • pxd_SV2112_getPixelClock
  • pxd_SV2112_getScanDirection
  • pxd_SV2112_getVideoMode
  • pxd_SV2112_setCtrlExposureAndRate
  • pxd_SV2112_setExposureAndGain
  • pxd_SV2112_setResolutionAndTiming
  • pxd_SV2112_setVideoAndTriggerMode
  • pxd_SV642_getAoiLeft
  • pxd_SV642_getAoiTop
  • pxd_SV642_getCtrlFrameRate
  • pxd_SV642_getCtrlTriggerMode
  • pxd_SV642_getCtrlVideoMode
  • pxd_SV642_getExposure
  • pxd_SV642_getGain
  • pxd_SV642_getGainRange
  • pxd_SV642_getMinMaxExposure
  • pxd_SV642_getPixelClock
  • pxd_SV642_getVideoMode
  • pxd_SV642_setCtrlRate
  • pxd_SV642_setExposureAndGain
  • pxd_SV642_setResolutionAndTiming
  • pxd_SV642_setVideoAndTriggerMode
  • pxd_SV643_getAoiLeft
  • pxd_SV643_getAoiTop
  • pxd_SV643_getCtrlExposure
  • pxd_SV643_getCtrlFrameRate
  • pxd_SV643_getCtrlTriggerMode
  • pxd_SV643_getCtrlVideoMode
  • pxd_SV643_getExposure
  • pxd_SV643_getGain
  • pxd_SV643_getMinMaxCtrlExposure
  • pxd_SV643_getMinMaxExposure
  • pxd_SV643_getOffset
  • pxd_SV643_getPixelClock
  • pxd_SV643_getVideoMode
  • pxd_SV643_setCtrlExposureAndRate
  • pxd_SV643_setExposureAndGain
  • pxd_SV643_setExposureAndGainOffset
  • pxd_SV643_setResolutionAndTiming
  • pxd_SV643_setVideoAndTriggerMode
  • pxd_SV9M001_getAoiLeft
  • pxd_SV9M001_getAoiTop
  • pxd_SV9M001_getCtrlFrameRate
  • pxd_SV9M001_getCtrlTriggerMode
  • pxd_SV9M001_getCtrlVideoMode
  • pxd_SV9M001_getDigitalGain
  • pxd_SV9M001_getExposure
  • pxd_SV9M001_getGain
  • pxd_SV9M001_getMinMaxExposure
  • pxd_SV9M001_getPixelClock
  • pxd_SV9M001_getScanDirection
  • pxd_SV9M001_getSubsample
  • pxd_SV9M001_getVideoMode
  • pxd_SV9M001_setCtrlRate
  • pxd_SV9M001_setExposureAndDigitalGain
  • pxd_SV9M001_setExposureAndGain
  • pxd_SV9M001_setResolutionAndTiming
  • pxd_SV9M001_setVideoAndTriggerMode
  • pxd_videoFieldCount
  • pxd_videoFieldsPerFrame
  • pxd_videoFieldsPerFrames
  • pxd_videoFormatAsIncluded
  • pxd_videoFormatAsIncludedInit
  • pxd_writeuchar
  • pxd_writeushort
  • pxd_xclibEscape
  • pxd_xclibEscaped
  • pxddch, struct
  • pxddch_s
  • pxdevfault, struct
  • pxdevfault_s
  • pxdevinfo, struct
  • pxdevinfo_s
  • pxdevservice, struct
  • pxdevservice_s
  • pxe_buffersFieldCount
  • pxe_buffersGPIn
  • pxe_buffersSysTicks
  • pxe_buffersSysTicks2
  • pxe_capturedBuffer
  • pxe_capturedFieldCount
  • pxe_capturedSysTicks
  • pxe_defineImage
  • pxe_defineImage3
  • pxe_definePximage
  • pxe_definePximage3
  • pxe_definePximage3Free
  • pxe_definePximageFree
  • pxe_doSnap
  • pxe_eventCapturedFieldClose
  • pxe_eventCapturedFieldClose
  • pxe_eventCapturedFieldClose
  • pxe_eventCapturedFieldCreate
  • pxe_eventCapturedFieldCreate
  • pxe_eventCapturedFieldCreate
  • pxe_eventCapturedFieldCreate2
  • pxe_eventFaultClose
  • pxe_eventFaultClose
  • pxe_eventFaultClose
  • pxe_eventFaultCreate
  • pxe_eventFaultCreate
  • pxe_eventFaultCreate
  • pxe_eventFaultCreate2
  • pxe_eventFieldClose
  • pxe_eventFieldClose
  • pxe_eventFieldClose
  • pxe_eventFieldCreate
  • pxe_eventFieldCreate
  • pxe_eventFieldCreate
  • pxe_eventFieldCreate2
  • pxe_eventGPTriggerClose
  • pxe_eventGPTriggerClose
  • pxe_eventGPTriggerClose
  • pxe_eventGPTriggerCreate
  • pxe_eventGPTriggerCreate
  • pxe_eventGPTriggerCreate
  • pxe_eventGPTriggerCreate2
  • pxe_eventSerialClose
  • pxe_eventSerialClose
  • pxe_eventSerialClose
  • pxe_eventSerialCreate
  • pxe_eventSerialCreate
  • pxe_eventSerialCreate
  • pxe_getAdcGainA
  • pxe_getAdcGainB
  • pxe_getAdcGainsA
  • pxe_getAdcGainsB
  • pxe_getAdcOffsetA
  • pxe_getAdcOffsetB
  • pxe_getAdcOffsetsA
  • pxe_getAdcOffsetsB
  • pxe_getBrightness
  • pxe_getCameraLinkCCOut
  • pxe_getContrast
  • pxe_getExsync
  • pxe_getExsyncMode
  • pxe_getGPIn
  • pxe_getGPOut
  • pxe_getGPTrigger
  • pxe_getHue
  • pxe_getPrin
  • pxe_getPrincMode
  • pxe_getUGain
  • pxe_getVGain
  • pxe_getVidMux
  • pxe_goAbortLive
  • pxe_goLive
  • pxe_goLivePair
  • pxe_goLiveSeq
  • pxe_goLiveSeqTrig
  • pxe_goLiveTrig
  • pxe_goneLive
  • pxe_goSnap
  • pxe_goSnapPair
  • pxe_goUnLive
  • pxe_imageAspectRatio
  • pxe_imageAspectRatios
  • pxe_imageBdim
  • pxe_imageBdims
  • pxe_imageCdim
  • pxe_imageCdims
  • pxe_imageIdim
  • pxe_imageIdims
  • pxe_imageXdim
  • pxe_imageXdims
  • pxe_imageYdim
  • pxe_imageYdims
  • pxe_imageZdim
  • pxe_imageZdims
  • pxe_infoDriverId
  • pxe_infoLibraryId
  • pxe_infoMemsize
  • pxe_infoModel
  • pxe_infoSubmodel
  • pxe_infoSysTicks
  • pxe_infoSysTicksUnits
  • pxe_infoUnits
  • pxe_loadBmp
  • pxe_loadRawBuffers
  • pxe_loadTiff
  • pxe_mesgFault
  • pxe_mesgFaultText
  • pxe_PIXCIclose
  • pxe_PIXCIopen
  • pxe_readuchar
  • pxe_readushort
  • pxe_renderDIBCreate
  • pxe_renderDIBFree
  • pxe_renderDirectVideoDone
  • pxe_renderDirectVideoInit
  • pxe_renderDirectVideoLive
  • pxe_renderDirectVideoUnLive
  • pxe_renderStretchDIBits
  • pxe_saveBmp
  • pxe_savePcx
  • pxe_saveRawBuffers
  • pxe_saveTga
  • pxe_saveTiff
  • pxe_serialConfigure
  • pxe_serialRead
  • pxe_serialWrite
  • pxe_setAdcColorGainOffsets
  • pxe_setAdcGainOffset
  • pxe_setCameraLinkCCOut
  • pxe_setContrastBrightness
  • pxe_setExsyncPrin
  • pxe_setExsyncPrincMode
  • pxe_setGPIn
  • pxe_setGPOut
  • pxe_setHueSaturation
  • pxe_setImageBrightBalance
  • pxe_setImageDarkBalance
  • pxe_setVidMux
  • pxe_SILICONVIDEO_getAec
  • pxe_SILICONVIDEO_getAgcA
  • pxe_SILICONVIDEO_getAgcB
  • pxe_SILICONVIDEO_getAoiHeight
  • pxe_SILICONVIDEO_getAoiLeft
  • pxe_SILICONVIDEO_getAoiTop
  • pxe_SILICONVIDEO_getAoiWidth
  • pxe_SILICONVIDEO_getCtrlFrameRate"
  • pxe_SILICONVIDEO_getCtrlTriggerMode
  • pxe_SILICONVIDEO_getCtrlVideoMode
  • pxe_SILICONVIDEO_getExposure
  • pxe_SILICONVIDEO_getFramePeriod
  • pxe_SILICONVIDEO_getGainA
  • pxe_SILICONVIDEO_getGainB
  • pxe_SILICONVIDEO_getGainsA
  • pxe_SILICONVIDEO_getGainsB
  • pxe_SILICONVIDEO_getMinMaxAec
  • pxe_SILICONVIDEO_getMinMaxAgcA
  • pxe_SILICONVIDEO_getMinMaxAgcB
  • pxe_SILICONVIDEO_getMinMaxAoiHeight
  • pxe_SILICONVIDEO_getMinMaxAoiWidth
  • pxe_SILICONVIDEO_getMinMaxCtrlFrameRate
  • pxe_SILICONVIDEO_getMinMaxExposure
  • pxe_SILICONVIDEO_getMinMaxFramePeriod
  • pxe_SILICONVIDEO_getMinMaxGainA
  • pxe_SILICONVIDEO_getMinMaxGainB
  • pxe_SILICONVIDEO_getMinMaxOffsetA
  • pxe_SILICONVIDEO_getMinMaxOffsetB
  • pxe_SILICONVIDEO_getMinMaxPixelClock
  • pxe_SILICONVIDEO_getOffsetA
  • pxe_SILICONVIDEO_getOffsetB
  • pxe_SILICONVIDEO_getOffsetsA
  • pxe_SILICONVIDEO_getOffsetsB
  • pxe_SILICONVIDEO_getPixelClock
  • pxe_SILICONVIDEO_getScanDirection
  • pxe_SILICONVIDEO_getSubsample
  • pxe_SILICONVIDEO_getVideoMode
  • pxe_SILICONVIDEO_setAxC
  • pxe_SILICONVIDEO_setCtrlRates
  • pxe_SILICONVIDEO_setExposure
  • pxe_SILICONVIDEO_setExposureColorGainOffsets
  • pxe_SILICONVIDEO_setExposureGainOffset
  • pxe_SILICONVIDEO_setResolutionAndTiming
  • pxe_SILICONVIDEO_setVideoAndTriggerMode
  • pxe_videoFieldCount
  • pxe_videoFieldsPerFrame
  • pxe_videoFieldsPerFrames
  • pxe_videoFormatAsIncluded
  • pxe_videoFormatAsIncludedInit
  • pxe_writeuchar
  • pxe_writeushort
  • pxe_xclibEscape
  • pxe_xclibEscaped
  • pxe_XCLIBinstantiate
  • pxe_XCLIBuninstantiate
  • pxim1size_t
  • pxim2size_t
  • pxim3size_t
  • pximadrs, struct
  • pximadrs_s
  • pximaeiou_t
  • pximage, struct
  • PXIMAGE: Access Non-Sequential Pixels
  • PXIMAGE: Get Advice, Errors, Info & Options
  • PXIMAGE: Image and Pixel Specifications
  • PXIMAGE: Obtain Pointer to Pixels
  • PXIMAGE: Obtain Sequential Access Pixel Count
  • PXIMAGE: Prepare for Non-Sequential Pixel Access
  • PXIMAGE: Read Sequential Pixels
  • PXIMAGE: Release Pointer to Pixels
  • PXIMAGE: Set & Get Area of Interest Window
  • PXIMAGE: Set to Access Non-Sequential Pixels
  • PXIMAGE: Set to Access Sequential Pixels
  • PXIMAGE: Set to Obtain Pointer to Pixels
  • PXIMAGE: Wait for Non-Sequential Access Completion
  • PXIMAGE: Wait for Sequential Access Completion
  • PXIMAGE: Write Sequential Pixels
  • pximage::aeiou
  • pximage::bxta
  • pximage::bxtp
  • pximage::bxts
  • pximage::bxtw
  • pximage::imap
  • pximage::imapr
  • pximage::imapset
  • pximage::iolen
  • pximage::ioread
  • pximage::iorite
  • pximage::ioset
  • pximage::iowait
  • pximage::xwind
  • pximage_s
  • pximage3, struct
  • pximage3_s
  • pximage3buf, struct
  • pximage3buf_s
  • pximagebuf, struct
  • pximagebuf_s
  • pximap, struct
  • pximcnt_t
  • pximcnt_t
  • pxtimestamp, struct
  • pxtimestamp_s
  • pxtrigspec, struct
  • pxtrigspec_s
  • pxvbtime_t
  • pxviddim, struct
  • pxviddim_s
  • pxvidformat, struct
  • pxvidformat_s
  • pxvidimage, struct
  • pxvidimage_s
  • pxvidmem, struct
  • pxvidmem_s
  • pxvidmode, struct
  • pxvidmode_s
  • pxvidopt, struct
  • pxvidopt_s
  • pxvidphys, struct
  • pxvidphys_s
  • pxvidres, struct
  • pxvidres_s
  • pxvidstate, struct
  • pxvidstate_s
  • pxvidstatus, struct
  • pxvidstatus_s
  • pxy, struct
  • pxy, struct
  • pxy_s
  • pxy_s
  • pxypoint_s
  • pxypoint_s
  • pxypointz_s
  • pxywindow, struct
  • pxywindow, struct
  • pxywindow_s
  • pxywindow_s
  • pxyz, struct
  • pxyz, struct
  • pxyz_s
  • pxyz_s
  • pxyzpoint_s
  • pxyzwindow, struct
  • pxyzwindow, struct
  • pxyzwindow_s
  • pxyzwindow_s
  • Read Pixel Values as Unsigned Char
  • Read Pixel Values as Unsigned Char
  • Read Pixel Values as Unsigned Char
  • Read Pixel Values as Unsigned Int
  • Read Pixel Values as Unsigned Short
  • Read Pixel Values as Unsigned Short
  • Read Pixel Values as Unsigned Short
  • Read/Write Imaging Board Memory
  • Read/Write Imaging Board Memory, Sparsely
  • S/VGA Adapter
  • Save Frame Buffers as Stream
  • Save Frame Buffers
  • Save Frame Buffers
  • Save Image: BMP Format
  • Save Image: BMP Format
  • Save Image: BMP Format
  • Save Image: PCX Format
  • Save Image: PCX Format
  • Save Image: PCX Format
  • Save Image: TARGA Format
  • Save Image: TARGA Format
  • Save Image: TARGA Format
  • Save Image: TIFF Format
  • Save Image: TIFF Format
  • Save Image: TIFF Format
  • schar
  • Serial Port: Read
  • Serial Port: Read
  • Serial Port: Set Configuration
  • Serial Port: Set Configuration
  • Serial Port: Write
  • Serial Port: Write
  • Set A/D Gain and Offset
  • Set A/D Gain and Offset
  • Set A/D Gains and Offsets
  • Set A/D Gains and Offsets
  • Set Bright White Balance
  • Set Bright White Balance
  • Set Camera Configuration
  • Set Dark White Balance
  • Set Dark White Balance
  • Set Default Configuration & Allocate Copy of Video State
  • Set Default Configuration Copy of Video State
  • Set Driver Parameters
  • Set EXSYNC and PRIN Counter Values
  • Set EXSYNC and PRIN Counter Values
  • Set EXSYNC and PRINC Mode Bits
  • Set EXSYNC and PRINC Mode Bits
  • Set SILICON VIDEO AGC and AEC
  • Set SILICON VIDEO AGC and AEC
  • Set SILICON VIDEO Controlled Rates
  • Set SILICON VIDEO Controlled Rates
  • Set SILICON VIDEO Exposure
  • Set SILICON VIDEO Exposure
  • Set SILICON VIDEO Exposure, Gain, and Offset
  • Set SILICON VIDEO Exposure, Gain, and Offset
  • Set SILICON VIDEO Exposure, Gains, and Offsets
  • Set SILICON VIDEO Exposure, Gains, and Offsets
  • Set SILICON VIDEO Resolution and Timing
  • Set SILICON VIDEO Resolution and Timing
  • Set SILICON VIDEO Video And Trigger Modes
  • Set SILICON VIDEO Video And Trigger Modes
  • Set Video Configuration as per Compiled Include
  • Set Video Configuration as per Compiled Include
  • Set Video Configuration as per Compiled Init
  • Set Video Configuration as per Compiled Init
  • Set Video Configuration
  • Set Video Contrast and Brightness
  • Set Video Contrast and Brightness
  • Set Video Hue and Saturation
  • Set Video Hue and Saturation
  • Set Video Input Multiplexer
  • Set Video Input Multiplexer
  • Sign Video State
  • SILICON VIDEO 10C-CL
  • SILICON VIDEO 10C6
  • SILICON VIDEO 10M-CL
  • SILICON VIDEO 10M6
  • SILICON VIDEO 1281C
  • SILICON VIDEO 1281M
  • SILICON VIDEO 1310
  • SILICON VIDEO 1310C
  • SILICON VIDEO 2112
  • SILICON VIDEO 2112C
  • SILICON VIDEO 5C10
  • SILICON VIDEO 5M10
  • SILICON VIDEO 642C
  • SILICON VIDEO 642M
  • SILICON VIDEO 643C
  • SILICON VIDEO 643M
  • SILICON VIDEO 9C10
  • SILICON VIDEO 9M001
  • SILICON VIDEO 9M001C
  • SILICON VIDEO 9T001C
  • SILICON VIDEO HAS21
  • SILICON VIDEO WGA-C
  • SILICON VIDEO WGA-M
  • SILICON VIDEO®
  • SILICON VIDEO®
  • SILICON VIDEO®
  • sint
  • size_t
  • slong
  • sshort
  • Stack Overflow
  • Struct pxauxservice
  • Struct pxbufstatus
  • Struct pxbufstatusfile
  • Struct PXCam_SV032State
  • Struct PXCam_SV1281State
  • Struct PXCam_SV1310State
  • Struct PXCam_SV2112State
  • Struct PXCam_SV642State
  • Struct PXCam_SV643State
  • Struct PXCam_SV9M001State
  • Struct PXCam_SVHAS2State
  • Struct pxcamcntl
  • Struct pxddch
  • Struct pxdevfault
  • Struct pxdevinfo
  • Struct pxdevservice
  • Struct pximadrs
  • Struct pximage
  • Struct pximage
  • Struct pximage3
  • Struct pximage3buf
  • Struct pximagebuf
  • Struct pximap
  • Struct pxtimestamp
  • Struct pxtrigspec
  • Struct pxviddim
  • Struct pxvidformat
  • Struct pxvidimage
  • Struct pxvidmem
  • Struct pxvidmode
  • Struct pxvidopt
  • Struct pxvidphys
  • Struct pxvidres
  • Struct pxvidstate
  • Struct pxvidstatus
  • Struct pxy
  • Struct pxy
  • Struct pxywindow
  • Struct pxywindow
  • Struct pxyz
  • Struct pxyz
  • Struct pxyzwindow
  • Struct pxyzwindow
  • Struct xca310format
  • Struct xca310mode
  • Struct xcdevinfo
  • Struct xcdevparms
  • Struct xcdevservice
  • Struct xcdxxformat
  • Struct xclibs
  • Struct xclibservice
  • Struct xcsv2format
  • Struct xcsv2mode
  • Struct xcsv7format
  • Struct xcvidstatus
  • TARGA Format
  • TARGA Format
  • Terminate Live/Snap into Frame Buffer
  • TIFF Format
  • TIFF Format
  • Type _cfunacc
  • Type _cfunfcc
  • Type _cfunvcc
  • Type _farimap
  • Type pxabortfunc_t
  • Type pxapiadrs_t
  • Type pxbuffer_t
  • Type pxcoord_t
  • Type pxcoord_t
  • Type pxim1size_t
  • Type pxim2size_t
  • Type pxim3size_t
  • Type pximaeiou_t
  • Type pximaplen_t
  • Type pximcnt_t
  • Type pximcnt_t
  • Type pxvbtime_t
  • Type schar
  • Type sint
  • Type size_t
  • Type slong
  • Type sshort
  • Type uchar
  • Type uint
  • Type ulong
  • Type ushort
  • uchar
  • uint
  • ulong
  • ushort
  • Video Abort
  • Video Abort
  • Video Format Configuration
  • Video Format Configuration
  • Video Initiated Status Check
  • Video Initiated Status Check
  • Video Live
  • Video Live
  • Video Live Pair Alternate
  • Video Live Pair Alternate
  • Video Live Sequence
  • Video Live Sequence
  • Video Live Sequence Trigger
  • Video Live Sequence Trigger
  • Video Live Trigger
  • Video Live Trigger
  • Video Snap and Wait
  • Video Snap and Wait
  • Video Snap
  • Video Snap
  • Video Snap Pair
  • Video Snap Pair
  • Video State ID
  • Video Time Stamps
  • Video Time Stamps
  • Video Time Stamps
  • Video Time Stamps
  • Video Time Stamps
  • Video UnLive
  • Video UnLive
  • Windows
  • Windows
  • Windows
  • Windows
  • Windows
  • Windows: Create Device Independent Bitmap (DIB)
  • Windows: Create Device Independent Bitmap (DIB)
  • Windows: Direct Video Display, Done
  • Windows: Direct Video Display, Done
  • Windows: Direct Video Display, Init
  • Windows: Direct Video Display, Init
  • Windows: Direct Video Display, Start
  • Windows: Direct Video Display, Start
  • Windows: Direct Video Display, Stop
  • Windows: Direct Video Display, Stop
  • Windows: Display Image Frame Buffer On Device Context
  • Windows: Display Image Frame Buffer On Device Context
  • Windows: Display Image Frame Buffer On Device Context
  • Windows: Free Device Independent Bitmap
  • Windows: Make Device Independent Bitmap
  • Windows: Register Event upon Captured Video Field
  • Windows: Register Event upon Captured Video Field
  • Windows: Register Event upon Captured Video Field
  • Windows: Register Event upon Captured Video Field
  • Windows: Register Event upon Fault
  • Windows: Register Event upon Fault
  • Windows: Register Event upon Fault
  • Windows: Register Event upon Fault
  • Windows: Register Event upon General Purpose Trigger
  • Windows: Register Event upon General Purpose Trigger
  • Windows: Register Event upon General Purpose Trigger
  • Windows: Register Event upon General Purpose Trigger
  • Windows: Register Event upon Serial
  • Windows: Register Event upon Serial
  • Windows: Register Event upon Video Field
  • Windows: Register Event upon Video Field
  • Windows: Register Event upon Video Field
  • Windows: Register Event upon Video Field
  • Windows: Release Device Independent Bitmap (DIB)
  • Windows: Release Device Independent Bitmap (DIB)
  • Windows: Unregister Event upon Captured Video Field
  • Windows: Unregister Event upon Captured Video Field
  • Windows: Unregister Event upon Fault
  • Windows: Unregister Event upon Fault
  • Windows: Unregister Event upon General Purpose Trigger
  • Windows: Unregister Event upon General Purpose Trigger
  • Windows: Unregister Event upon Serial
  • Windows: Unregister Event upon Serial
  • Windows: Unregister Event upon Video Field
  • Windows: Unregister Event upon Video Field
  • Write Pixel Values as Unsigned Char
  • Write Pixel Values as Unsigned Char
  • Write Pixel Values as Unsigned Char
  • Write Pixel Values as Unsigned Int
  • Write Pixel Values as Unsigned Short
  • Write Pixel Values as Unsigned Short
  • Write Pixel Values as Unsigned Short
  • xca310format, struct
  • xca310format_s
  • xca310mode, struct
  • xca310mode_s
  • xcdevinfo, struct
  • xcdevinfo_s
  • xcdevparms, struct
  • xcdevparms_s
  • xcdevservice, struct
  • xcdevservice_s
  • xcdxxformat, struct
  • xcdxxformat_s
  • xclib_close
  • xclib_DeclareVidStateStructs
  • xclib_DeclareVidStateStructs2
  • xclib_InitVidStateStructs
  • xclib_InitVidStateStructs2
  • xclib_libincid
  • xclib_liblibid
  • xclib_open
  • xclibs, struct
  • xclibs_s
  • xclibservice, struct
  • xclibservice_s
  • xcsv2format, struct
  • xcsv2format_s
  • xcsv2mode, struct
  • xcsv2mode_s
  • xcsv7format, struct
  • xcsv7format_s
  • xcvidstatus, struct
  • xcvidstatus_s