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: 28-Apr-2023
EPIX, Inc.
381 Lexington Drive
Buffalo Grove IL 60089
847.465.1818
847.465.1919 (fax)
epix@epixinc.com
www.epixinc.com
This manual describes the XCLIB and XCLIB-Lite ``C'' Library for use with the EPIX® PIXCI® A, A110, A310, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, SI, SI1, SI2, SI4, SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, SV7, and SV8 frame grabbers. The library supports all current and previous versions of the PIXCI® frame grabbers, allowing convenient control and access to the features of single frame grabbers, of multiple frame grabbers, or of one or more frame grabbers with multiple functional units.[1]
This common manual discusses all PIXCI® frame grabbers, clearly identifying the common features and the distinguishing features as seen through the XCLIB and XCLIB-Lite ``C'' Library. An frame grabber specific introduction to using XCLIB and XCLIB-Lite can be found in the ''Getting Started with XCLIB'' chapter of the frame grabber'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, 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.
An example Visual Basic program named
xclibex3.vb
,
an example VB.NET program named
xclibex6.vb
,
and an example C#.NET program named
xclibex7.cs
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.
An example Windows program named
xclibex5.cpp
is included with the library,
and demonstrates simultaneous operation of two frame grabbers
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,
1514CL,
1820CL,
2KS-C, 2KS-M,
5C10, 5M10,
642M, 642C, 643M, 643C,
9C10,
9M001, 9M001C, 9T001C,
10C6, 10M6,
10C-CL, 10M-CL,
20C-CL, 20M-CL,
15C5,
WGA-C, and WGA-M cameras,
and demonstrates camera specific controls as well as
capturing and displaying video
on the graphics display.
An example VB.NET program named
xclibexd.vb
provides a similar example.
An example Windows program named
xclibexg.c
is included with the library,
and demonstrates streaming of image sequences
at video rate using a frame generator.
An example Linux
''terminal''
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, using the Gnome Desktop.
An example Linux
''terminal''
program named
xclibel5.c
is included with the library,
and demonstrates simultaneous operation of two frame grabbers
at different resolutions.
An example Linux
program named
xclibel8.c
is included with the library,
and demonstrates display of live video
via the Linux Direct Rendering Manager (DRM-KMS)
and/or the Linux FBDEV API.
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.
While XCLIB is easy to install, like most manufacturers of software we recommend as a precaution that a hard disk backup be performed before installing XCLIB.
To install XCLIB on a computer system with hard disk:
> Z:SETUP (replace Z with drive letter for your CD)
as appropriate. Click ''OK''.XCLIB-Lite 'C' Library for Win 95/98/ME XCLIB-Lite 'C' Library for Win NT/2000/XP/Vista/7/8/10 32-Bit XCLIB-Lite 'C' Library for Win XP/Vista/7/8/10/11 64-Bit XCLIB 'C' Library for Win 95/98/ME XCLIB 'C' Library for Win NT/2000/XP/Vista/7/8/10 32-Bit XCLIB 'C' Library for Win XP/Vista/7/8/10/11 64-Bit 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/8 32-Bit XCLIB+PXIPL `C' Library for Win XP/Vista/7/8/10/11 64-Bit XCLIB+PXIPL `C' Library for DOS+Watcom+Tenberry
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.
.EXE
or
.bin
file from the EPIX, Inc. web or ftp site.
or via the desktop explorer.> THE.EXE
.EXE
or
.bin
file from your computer system's hard drive.
*.TXT
etc. contain distribution listings, corrections, or additions
to this manual, or other up-to-date information.
The example
xclibex1.c
,
xclibex2.cpp
,
xclibex3.vb
,
xclibex4.cpp
,
xclibex5.cpp
,
xclibex6.vb
,
xclibex7.cs
,
xclibexd.cpp
,
xclibexd.vb
,
xclibel1.c
,
xclibel3.c
,
xclibel5.c
,
or
xclibel8.c
program, or your application program,
can now be compiled and run.
The library is compatible with the following compilers, versions, memory models, and environments:
|
Compiled | Execution | Run Time | ||
Compiler |
|
Library Name | w. Options | Environment | Modules |
Any 32 bit |
XCLIBW95.LIB
|
-GB -MT -LD
|
Windows 95 |
XCLIBW95.DLL
|
|
Microsoft | or | Windows 98 |
EPIXXCW5.VXD
|
||
Compatible |
XCLYBW95.LIB
|
Windows ME |
EPIXXCW5.INF
|
||
Compiler | Intel x86 |
EPIXXC.SYS (opt.)
|
|||
Any 32 bit |
XCLIBWNT.LIB
|
-GB -MT -LD
|
Windows NT |
XCLIBWNT.DLL
|
|
Microsoft | or | Intel x86 |
EPIXXCWT.SYS
|
||
Compatible |
XCLYBWNT.LIB
|
EPIXXCWT.INF
|
|||
Compiler |
EPIXXCWT.INF
|
||||
Any 32 bit |
XCLIBWNT.LIB
|
-GB -MT -LD
|
Windows 2000 |
XCLIBWNT.DLL
|
|
Microsoft | or | Windows XP |
EPIXXCW2.SYS
|
||
Compatible |
XCLYBWNT.LIB
|
Windows Vista |
EPIXXCW2.INF
|
||
Compiler | Windows 7,8,10 |
EPIXXCW2.CAT
|
|||
Intel x86 | |||||
Any 32 bit |
XCLIBWNT.LIB
|
-GB -MT -LD
|
Windows XP 64-Bit |
XCLIBWNT.DLL
|
|
Microsoft | or | Windows Vista 64-Bit |
EPIXXCW6.SYS
|
||
Compatible |
XCLYBWNT.LIB
|
Windows 7,8,10,11 64-Bit |
EPIXXCW6.INF
|
||
Compiler | Intel x86-64 |
EPIXXCW6.CAT
|
|||
Any 64 bit |
XCLIBW64.LIB
|
-GB -MT -LD
|
Windows XP 64-Bit |
XCLIBW64.DLL
|
|
Microsoft | or | Windows Vista 64-Bit |
EPIXXCW6.SYS
|
||
Compatible |
XCLYBW64.LIB
|
Windows 7,8,10,11 64-Bit |
EPIXXCW6.INF
|
||
Compiler | Intel x86-64 |
EPIXXCW6.CAT
|
|||
LSB-GNU V4.7 |
xclib_i386.a
|
Linux 2.4 kernels |
pixci_i386.o
|
||
32 bit | or | Intel x86 |
pixci.sh
|
||
xclyb_i386.a
|
pixci.rc
|
||||
LSB-GNU V4.7 |
xclib_i386_pic.a
|
-fPIC
|
Linux 2.4 kernels |
pixci_i386.o
|
|
32 bit |
or xclib_i386.so
|
Intel x86 |
pixci.sh
|
||
or xclyb_i386_pic.a
|
pixci.rc
|
||||
or xclyb_i386.so
|
|||||
LSB-GNU V4.7 |
xclib_i386.a
|
Linux 2.6.x,3.x, |
pixci_i386.ko
|
||
32 bit | or | 4.x,5.x kernels |
pixci.sh
|
||
xclyb_i386.a
|
Intel x86 |
pixci.rc
|
|||
LSB-GNU V4.7 |
xclib_i386_pic.a
|
-fPIC
|
Linux 2.6.x,3.x, |
pixci_i386.ko
|
|
32 bit |
xclib_i386.so
|
4.x,5.x kernels |
pixci.sh
|
||
xclyb_i386_pic.a
|
Intel x86 |
pixci.rc
|
|||
xclyb_i386.so
|
|||||
LSB-GNU V4.7 |
xclib_x86_64.a
|
Linux 3.x,4.x, |
pixci_x86_64.ko
|
||
64 bit | or | 5.x kernels |
pixci.sh
|
||
xclyb_x86_64.a
|
Intel x86-64 |
pixci.rc
|
|||
LSB-GNU V4.7 |
xclib_x86_64_pic.a
|
-fPIC
|
Linux 3.x,4.x, |
pixci_x86_64.ko
|
|
64 bit |
or xclib_x86_64.so
|
5.x kernels |
pixci.sh
|
||
or xclyb_x86_64_pic.a
|
Intel x86-64 |
pixci.rc
|
|||
or xclyb_x86_64.so
|
|||||
GNU V4.8 |
xclib_armv7l.a
|
Linux 3.x4.x, |
pixci_armv7l.ko
|
||
32 bit | or | 5.x kernels |
pixci.sh
|
||
xclyb_armv7l.a
|
nVidia TK1 (ARM A15) |
pixci.rc
|
|||
GNU V4.8 |
xclib_armv7l_pic.a
|
-fPIC
|
Linux 3.x,4.x, |
pixci_armv7l.ko
|
|
32 bit |
or xclib_armv7l.so
|
5.x kernels |
pixci.sh
|
||
or xclyb_armv7l_pic.a
|
nVidia TK1 (ARM A15) |
pixci.rc
|
|||
or xclyb_armv7l.so
|
|||||
GNU V4.8 |
xclib_armv7l.a
|
Linux 4.x kernels |
pixci_armv7l.ko
|
||
32 bit | or | Boundary Devices/ARM |
pixci.sh
|
||
xclyb_armv7l.a
|
NITROGEN6/imx6 |
pixci.rc
|
|||
GNU V4.8 |
xclib_armv7l_pic.a
|
-fPIC
|
Linux 4.x kernels |
pixci_armv7l.ko
|
|
32 bit |
or xclib_armv7l.so
|
Boundary Devices/ARM |
pixci.sh
|
||
or xclyb_armv7l_pic.a
|
NITROGEN6/imx6 |
pixci.rc
|
|||
or xclyb_armv7l.so
|
|||||
GNU V9.4 |
xclib_aarch64.a
|
Linux 3.x,4.x,5.x kernels |
pixci_aarch64.ko
|
||
64 bit | or | nVidia Nano,Orin,TX1,TX2, |
pixci.sh
|
||
xclyb_aarch64.a
|
Xavier,XavierNX (ARM A57) |
pixci.rc
|
|||
GNU V9.4 |
xclib_aarch64_pic.a
|
-fPIC
|
Linux 3.x,4.x,5.x kernels |
pixci_aarch64.ko
|
|
64 bit |
or xclib_aarch64.so
|
nVidia Nano,TX1,TX2, |
pixci.sh
|
||
or xclyb_aarch64_pic.a
|
Xavier,XavierNX (ARM A57) |
pixci.rc
|
|||
or xclyb_aarch64.so
|
|||||
Watcom C/C++ |
XCLBW1DF.LIB
|
-4r -mf -w3 -ox
|
DOS4GW | none | |
V11.0 | Professional | ||||
f model,32 bit | Intel x86 |
Windows drivers (*.VXD, *.SYS, *.CAT, *.INF) and Linux drivers (*.o, *.ko, pixci.sh, pixci.rc) are provided with the XCAP application.
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.
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.
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 MiByte) 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, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, SI, SI1, SI2, or SI4 frame grabber, 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.
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]
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./* 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
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:
at the start of each source file of the application program that uses XCLIB functions.#include "xcliball.h"
If using
xcliball.h
within a C++ program, then:
should be used.[3]extern "C" { #include "xcliball.h" }
If using
xcliball.h
in a Windows environment, a
must (not necessarily immediately) precede#include <windows.h>
#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
.
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.
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, length |
pxapiadrs_t | uint64 (64 bit library) | frame buffer memory address, length |
_farimap | _far or blank | farness of an 'imap' pointer |
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 |
xcliball.h
;
the programmer need not
''define''
or
''typedef''
these symbols:
Symbol | Use |
pxabortfunc_t | premature termination callback predicate function |
xcliball.h
as:
If abortp≠NULL, the service will periodically invoke:typedef int (_cfunfcc pxabortfunc_t)(void*,int,int);
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.(*abortp)(abortp, ipos, npos);
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.
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,
pxd_mesgErrorCode,
and/or
pxd_mesgErrorCode2
can be used if the open failed,
to obtain additional information on the cause of failure.
For PIXCI® A, A110, A310, CL1, CL2, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, SI, SI1, SI4, SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, SV7, or SV8 frame grabbers which do not have on-board frame buffer memory, the XCLIB library architecture uses a portion of host computer DMA memory as frame buffer memory. Under Windows 95, 98, ME, NT, 2000, XP, XP(x64), Vista 32/64-Bit, 7 32/64-Bit, 8/10 32/64-Bit, and 11 64-Bit, 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® frame grabbers, the frame buffer memory is partitioned into image frame buffers, based upon the number of PIXCI® frame grabbers in use and the video format configuration and resolution for each frame grabber. The frame buffer memory is re-partitioned whenever the number of PIXCI® frame grabbers in use changes, or the video format configuration changes.
An XCLIB function such as:
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_goLive(..., 1);
snaps two fields or frames into image frame buffer 1, with the latter overlaying the former.pxd_doSnap(..., 1, ...); pxd_doSnap(..., 1, ...);
The image frame buffers for each frame grabber are numbered consecutively starting with 1. Thus when using multiple frame grabbers, the XCLIB library function
which commands both the first and second frame grabbers 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 frame grabber number (i.e. ''unit'').pxd_goLive(0x03, 1);
Video capture is, generally, into one or more of these image frame buffers, and not to a malloc'ed buffer provided by the application program.[4] 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.[5]
As the total number of image frame buffers cannot be increased arbitrarily (for a given number of frame grabbers and a fixed video format resolution), a live sequence capture with:
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 cycles through all other frame buffers and re-uses that buffer.pxd_goLiveSeq(...)
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® frame grabber to capture the next field or frame into a frame buffer. This is in contrast to having the frame grabber consume resources continuously capturing every field or frame, and having a hypothetical snap function retrieve the last field or frame captured. This behavior could be obtained in XCLIB using pxd_goLivePair or similar functions, but it isn't the behavior of the snap functions.
XCLIB provides several paradigms for effecting continuous live capture and retrieval of image data.
One paradigm initializes the PIXCI® frame grabber and driver's video capture engine to continuously capture into one frame buffer, an alternating pair of frame buffers, or a (circular) sequence of N frame buffers. One initialized, capture proceeds without further action by the application (and is interrupt driven, rather than as a background thread). The application monitors the capture progress and retrieves image data as appropriate. See pxd_goLive, pxd_goLivePair, pxd_goLiveSeq.
Another paradigm allows the application to queue each frame buffer into which an image should be captured; images are captured into the same order as they were queued. The application monitors the capture progress, retrieves image data as appropriate, and then (typically) re-queues the frame buffer for further capture. If desired, the same frame buffer can be queued multiple times; an image is captured into the frame buffer for each queued instance. See pxd_quLive.
Both paradigms can provide the same video capture rate. Their behavior differs when the application fails to attend to the capture process; the former results in overwrite/overrun of data, the latter results in under-run/starvation of data.
A third paradigm uses repeated
pxd_goSnap
or
pxd_doSnap;
each snapping one image
without queuing of requests.
This may be sufficient for triggered cameras
and/or slow frame rate applications,
but, in general, is not suitable for video rate capture.
(By the time the application is aware of one video frame
having been captured by
pxd_goSnap
or
pxd_doSnap,
it is too late for the application
to initiate and
''arm''
capture for the following video frame).
The pxd_readuchar, pxd_writeuchar, and similar functions read or write the PIXCI® frame grabber's frame buffers. Depending on the PIXCI® frame grabber, the frame buffers might be on-board dedicated memory, or might be reserved DMA buffers within the computer's memory. In either case, access is shared between the PIXCI® frame grabber, capturing (i.e. storing) pixel data as it arrives from the camera, and the application's read or write of data from the frame buffers.
The pxd_readuchar, pxd_writeuchar, and similar functions are not ''interlocked'' with pxd_doSnap, pxd_goSnap, pxd_goLive and similar capture functions. The application can read or write a frame buffer, or an AOI of the frame buffer, before any image was captured, multiple times after an image was captured, or ignore the captured image data — none of which affects capturing (i.e. storing) pixel data to the frame buffers. The application can read a frame buffer while new image data is being captured and stored into the same frame buffer; this can be used to get a ''head-start'' on processing the top portion of an image while the camera is still sending the bottom portion.
Optional unpacking of bitpacked data,
optional
''multi-tap''
correction of pixel order,
optional color space conversions,
and optional access as one byte versus two byte values,
are not done when image data is captured and stored
but later, if and when the application reads image data so that it
can be saved, displayed, etc.
Each call of pxd_readuchar and similar functions can read one pixel, one line, one column, the entire image, or any AOI of the image. Single pixel reads, looping over columns and rows, is inefficient and should be avoided. Reading columns, looping over columns, might be inefficient, depending on camera, frame grabber, pixel format, and driver configuration parameters. Reading rows, looping over rows or, better, reading the entire AOI with each call, is recommended.
The pxd_readuchar and related functions read a 2-D AOI of an image into a 1-D array, consistent with the C/C++ implementation of a 2-D monochrome array[M][N] as a 1-D array[M×N]; the pixel at column=n and row=m is found at array[n+m×N] (where 0<=n<N and 0<=m<M). Or of a 2-D color array[M][N][C] as a 1-D array[C×M×N]; the pixel at column=n, row=m, and color component=c is found at array[c+n×C+m×N×C] (where 0<=n<N, 0<=m<M, and 0<=c<C).
The
pxd_readuchar
and related functions
do not support
implementation of a 2-D array[m][n] as
a 1-D list[m] of 1-D array[n]'s.
The pxd_eventFieldCreate, pxd_eventCapturedFieldCreate, and similar functions allow registering an Event (Windows) or Signal (Linux) through which the application can be notified of a variety of conditions. Upon detecting an occurrence of the condition, the PIXCI® frame grabber driver asks Windows to set the state of an Event or asks Linux to send a Signal; the application may then be notified by Windows via the Event mechanism or by Linux via the Signal mechanism. XCLIB is not involved in the notification process.
The PIXCI® frame grabber driver does not know whether the application is configured to accept or to ignore the Events or Signals, whether the application is actively executing versus paused for I/O or paused in favor of a different application, or, in short, whether each notification has, or will be, detected by the application. The driver does not queue notifications.
Particularly on busy
systems, applications should
arrange for a high-priority thread
to accept notifications.
Or, not assume they will receive one notification per
captured field (as an example); instead, treat
each notification as a
''wake-up''
to be followed by using
pxd_videoFieldCount,
pxd_capturedBuffer,
pxd_buffersFieldCount,
or similar functions (following same example)
to determine how many fields have been captured since the
last determination.
The PIXCI® E1DB, ECB2, EL1DB, E4DB, E4G2-2F, E4TX2-2F, E8DB, and e104x4-2f frame grabbers contain multiple, independent functional units within a single physical board and provides features similar to two PIXCI® EB1, ECB1, EB1, EB1, EB1, or E4 frame grabbers, respectively. The PIXCI® E4G2-4B, E4TX2-4B and e104x4-4b frame grabbers contains multiple, independent functional units within a single physical board and provides features similar to four PIXCI® EB1 frame grabbers, respectively. The PIXCI® E4G2-F2B, E4TX2-F2B, and e104x4-f2b frame grabbers contain multiple, independent functional units within a single physical board and provides features similar to one PIXCI® E4 and two PIXCI® EB1 frame grabbers, respectively. The PIXCI® ELS2 frame grabber contains multiple, independent functional units within a single physical board and provides features similar to two PIXCI® SI frame grabbers. The PIXCI® E8CAM, SI2, and SI4 frame grabbers contain multiple, independent functional units within a single physical board and provides features similar to two, two, or four PIXCI® SI1 frame grabbers, respectively. The PIXCI® SV7 frame grabber contains multiple, independent functional units within a single physical board and provides features similar to two PIXCI® SV5B frame grabbers.[6]
The XCLIB Library presents the two halves, three thirds, or four quarters of the
PIXCI® E1DB, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B,
E4TX2-2F, E4TX2-4B, E4TX2-F2B,
E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, ECB2, EL1DB, ELS2, miniH2B,
SI2, SI4, SV7 frame grabber
as two, three, or four
PIXCI® EB1, EB1, E4, E4, E4&EB1, SI1,
E4, E4, E4&EB1,
EB1, E4, E4, E4&EB1, ECB1, EB1, EB1G2,
SI, SI1, SI1, SV5B frame grabbers,
respectively.
If opened together, the halves, thirds, or quarters are
accessed and controlled via a
unitmap
parameter as described below.
Each half, third, or quarter of the PIXCI® E1DB, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B,
E4TX2-2F, E4TX2-4B, E4TX2-F2B,
E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b,
ECB2, EL1DB, ELS2, miniH2B, SI2, SI4, SV7 frame grabber 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,
''frame grabber''
is synonymous with
''functional units''
unless explicitly stated otherwise.
Each open instance of the library allows operation of one or more identical frame grabbers; the frame grabbers may have independent video format and resolution. Relevant XCLIB functions allow simultaneous control of multiple boards via the unitmap parameter.[7]
Multiple instances of the library may be opened for mutually exclusive subsets of frame grabbers. 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 frame grabbers 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.
A single open instance of XCLIB supports the operation of multiple, identical PIXCI® frame grabbers, 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 frame grabber.
Some functions allow operation on multiple frame grabbers 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 frame grabber
with a single invocation;
they describe
unitmap
with the phrasing
''the single frame grabber selected by ...''.
Should the
unitmap
have more than one bit set to 1, the frame grabber corresponding
to the rightmost 1 bit is selected for use.
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 Windows XP and later, virtual COM port access to the serial port is available. All Camera Link standard baud rates are supported. The ''COM'' driver is separate from the PIXCI® imaging card's driver, and must be explicitly installed. The ''COM'' 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.
Under Linux with 2.6 and later kernels, the
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'' driver is separate from the PIXCI® imaging card's driver, and must be explicitly installed. 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./dev/ttySPIXCI0 /dev/ttySPIXCI1 ..
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/ttySPIXCI0
,
/dev/ttySPIXCI1
,
etc. nodes.
Also, under
Windows 95, 98, and ME,
XCLIB cannot share access to the
PIXCI® frame grabber(s) with
clserEPX.dll
requiring use of the integrated functions.
Under Linux with 2.4 kernels, which doesn't support
/dev/ttySPIXCI0
,
etc. nodes,
use of the integrated functions is similarly necessary.
The Video Format Configuration is a group of dozens of parameters that defines the video format (i.e. whether NTSC, RS-170, PAL, CCIR, or similar video standard for applicable frame grabbers, or specific camera manufacturer and model for other frame grabbers), the resolution (i.e. capturing more or fewer pixels per line and per column), the bit depth (i.e. capturing more or fewer bits per pixel), the color space (i.e. capturing monochrome, RGB color, Bayer color, YUYV color or other options), and other settings related to the frame grabber's hardware.
The XCLIB library provides a default Video Format Configuration for each PIXCI® frame grabber, model, and submodel. The library of defaults is compiled into XCLIB and cannot be changed in the field. For PIXCI® frame grabbers intended for one specific camera, the default matches the intended camera. For others, the default may or may not match the intended camera, or may match only the default operating mode of the intended camera (such as for digital cameras with adjustable resolution, bit depth, color space, triggering, etc). For some PIXCI® frame grabbers, the default Video Format Configuration is specified in an EEPROM which can be changed using the XCAP application.
For PIXCI® frame grabbers supporting multiple standard formats such as NTSC, RS-170, PAL, CCIR, or similar video standards, 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[8] Video Format Configuration, although XCAP uses the term ''Video Setup''. In XCAP, use:
to select an alternate camera or format from XCAP's predefined selections. Or, use:PIXCI® PIXCI® Open/Close Close Camera & Format .. select alternate camera or format OK Open
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:Capture (in PIXCI® Image Viewer) Adjustments
Regardless of method, export the video setup with:PIXCI® Video Setup .. adjust video configuration followed by OK ..
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.PIXCI® PIXCI® Export Video Setup
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,[9]
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[10] pxd_videoFormatAsIncluded. To use SCF style or SCF+ style functions with multiple frame grabbers at different formats and resolutions, a saved video setup file, created with XCAP configured with
must be specified as the third parameter to pxd_PIXCIopen or pxe_PIXCIopen.PIXCI® PIXCI® Open/Close Multiple Devices Use Individual Formats & Controls OK
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 may create its own convention,
such as using the C/C++ library's
RegQueryValueEx(),
GetPrivateProfileString(),
or
getenv(),
for run time selection of a video format name or a video setup file
which the application then passes to the XCLIB library.
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''.
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
or
pxd_mesgErrorCode2
functions.
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,
initializes the pxdevfault structure.struct pxdevfault fault_structure;
memset(&fault_structure, 0, sizeof(fault_structure)); fault_structure.ddch.len = sizeof(fault_structure); fault_structure.ddch.mos = PXMOS_DEVFAULT;
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:
may be used.struct pxy a_pair_of_xy_coordinates; pxy_s another_pair_of_xy_coordinates;
The pxy struct provides a pair of x, y coordinates defining a point in two dimensions:
The pxyz struct provides a triplet of x, y, z coordinates defining a point in three dimensions:struct pxy { pxcoord_t x; pxcoord_t y; }; typedef struct pxy pxy_s; typedef struct pxy pxypoint_s;
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:
The pxyzwindow struct provides a pair of x, y, z coordinates defining a rectangle in three dimensions:struct pxywindow { struct pxy nw; // north west corner inclusive struct pxy se; // south east corner, usually exclusive }; typedef struct pxywindow pxywindow_s;
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[11] 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[12] 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.
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.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;
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;
The structures used for access to and control of the frame grabber(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 |
pxbufstatus2 | 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 |
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.
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.
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, E4G2-2F, E4TX2-2F, E8CAM, E8DB, e104x4-2f, ECB2, EL1DB, ELS2, SI2, and SV7 frame grabbers which contain two independent functional units within a single physical board, for the PIXCI® E4G2-F2B, E4TX2-F2B, and e104x4-f2b frame grabbers which contains three independent functional units within a single physical board: and for the PIXCI® E4G2-4B, E4TX2-4B, e104x4-4b, and SI4 frame grabbers which contain four independent functional units within a single physical board: Under Windows 2000, XP, XP(x64), Vista 32/64-Bit, 7 32/64-Bit, 8/10 32/64-Bit, 11 64-Bit, Linux 32 Bit and Linux 64 Bit, each functional unit is handled as an independent frame grabber 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, E4G2-2F, E4TX2-2F, E8CAM, E8DB, e104x4-2f, ECB2, EL1DB, ELS2, miniH2B, SI2, or SV7 frame grabber and both halves of the second physical PIXCI® E1DB, E4DB, E4G2-2F, E8CAM, E8DB, e104x4-2f, ECB2, EL1DB, ELS2, miniH2B, SI2, or SV7; 0b11111001 selects the first and fourth quarter of the first physical PIXCI® E4G2-4B, E4TX2-4B, e104x4-4b, or SI4 frame grabber and all quarters of the second physical PIXCI® E4G2-4B, E4TX2-4B, e104x4-4b, or 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® frame grabbers, 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) frame grabber(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.
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 MiByte). 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.
Particularly useful for use with SILICON VIDEO® 1281M, 1281C, 1310, 1310C, 2112, 2112C, 1514CL, 1820CL, 2KS-C, 2KS-M, 5C10, 5M10, 642M, 642C, 643M, 643C, 9C10, 9M001, 9M001C, 9T001C, 10C6, 10M6, 15C5, 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 frame grabbers.
Default: 0.
If bit 0x80 is set with non forceful memory allocation, frame buffer memory below 4 GiByte is requested; on 64 bit systems with more than 4 GiByte 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).
Only used under Linux. Other bits to be described. Default: 0.
If bit 0x04 is not set, the frame buffer memory is not cleared (i.e. set to zero) after allocation, minimizing delay, particularly when using several GiBytes 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® frame grabber(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.
If bit 0x40 is set, the frame buffer memory and memory used for recording per frame buffer's capture status is cleared (i.e. set to zero) whenever the capture format resolution, bit depth, bit packing, or color space options are changed. This is intended so that display of the contents of the frame buffer(s), under the new format but before a new image is captured, will show a black image (or green for YUYV formats) rather than ''garbled'' pixel data. This option is ignored when using forceful image frame buffer allocation, or for frame grabbers with on-board frame buffer memory.
Default: 0x01 under Windows 95, 98, ME. 0x28 under Linux 32 Bit and Linux 64 Bit prior to kernel 4.x; 0x29 for kernel 4.x and later. 0x29 under Windows NT, 2000, XP, XP(x64), Vista 32/64-Bit, 7 32/64-Bit, 8/10 32/64-Bit, 11 64-Bit.
Default: 0.
Under Linux: If n=1, the jiffies and HZ are used for time stamping video events. If n=2, the high resolution kernel timer (i.e. do_gettimeofday for earlier kernels, or getnstimeofday or ktime_get_real_ts64 for kernel 5.x and later) is used for time stamping video events. If n=4, the raw monotonic kernel timer (i.e. getrawmonotonic or ktime_get_raw_ts64) is used for time stamping video events; if unavailable, reverting to do_gettimeofday, getnstimeofday, or ktime_get_real_ts64. If n=3, the get_jiffies_64 is used for time stamping video events.
Under Windows 95, 98, and ME: If n=1, the Get_Last_Updated_System_Time is used for time stamping video events.
Under Windows NT: If n=1, the KeQuerySystemTime is used for time stamping video events.
Under Windows 2000, XP, XP(x64), Vista 32/64-Bit, 7 32/64-Bit: If n=1, the KeQuerySystemTime is used for time stamping video events. If n=2, the KeQueryPerformanceCounter is used for time stamping video events. If n=3, the KeQueryInterruptTime is used for time stamping video events. If n=4, the KeQueryTickCount is used for time stamping video events.
Under Windows 8/10 32/64-Bit and 11 64-Bit: If n=1, the KeQuerySystemTime is used for time stamping video events. If n=2, the KeQueryPerformanceCounter is used for time stamping video events. If n=3, the KeQueryInterruptTime is used for time stamping video events. If n=4, the KeQueryTickCount is used for time stamping video events. If n=5, the KeQuerySystemTimePrecise 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 compatibility, time stamping as per -WT or -LX is used.
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 32/64-Bit, 7 32/64-Bit, 8/10 32/64-Bit, and 11 64-Bit. The new -TI option supersedes this option.
If bit 0x80 is set, frame buffer memory below 4 GiByte is requested; on 64 bit systems with more than 4 GiByte of memory, this allows allows use of 32 bit PCI cards, and/or allows allows use of 32 bit applications. Only used with Window XP, XP(x64), Vista 64-Bit, 7 64-Bit, and 8/10/11 64-Bit.
if bit 0x100 is set, the driver applies a patch so that the frame grabber can be opened after Windows awakes from sleep or hibernation modes. Only used with Vista 32/64-Bit, 7 32/64-Bit, 8/10 32/64-Bit, and 11 64-Bit.
If bit 0x200 is set, the driver does not use IOCTL ''DIRECT'' mode.
If bit 0x1000 is set, the driver implements a work-around so that Windows sleep or hybernation does not adversely affect the operation of older PIXCI® frame grabbers
Only used under Windows. Other bits to be described. Default: 0x20.
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:
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.PIXCI PIXCI Open/Close Advanced
Driver Configuration Parameters
may be specified in the Windows'
SYSTEM.INI
file:
Windows must be rebooted for the new specification to take effect.[EPIX_XC] PIXCI=<DriverConfigurationParameters>
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. Optionally, the frame buffer memory is cleared upon change of the video format resolution, bit depth, bit packing, or color space; this option would also clear the memory when the driver is opened.
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.
The EPIXXCWT.SYS driver for Windows NT, or the EPIXXCW2.SYS driver for Windows 2000, XP, Vista, 7, and 8/10 32-Bit or the EPIXXCW6.SYS driver for Windows XP, Vista, 7, and 8/10/11 64-Bit, 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, 8/10 32/64-Bit, and 11 64-Bit. 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, Vista, 7, and 8/10/11 64-Bit.
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:
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.PIXCI PIXCI Open/Close Advanced
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, 7, 8/10 32-Bit registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EPIXXCW2 PIXCI = <DriverConfigurationParameters>or the Windows XP, Vista, 7, 8/10/11 64-Bit 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. Optionally, the frame buffer memory is cleared upon change of the video format resolution, bit depth, bit packing, or color space; this option would also clear the memory when the driver is opened.
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.
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.
The ''pixci_i386.o'' (for 2.4 kernels) or ''pixci_i386.ko'' (for 2.6, 3.x, 4.x, and 5.x 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 several system timers, as selected by the Driver Configuration Parameters. If jiffies (or jiffies_64) and HZ are selected, the system time units are dependent on the Linux version and host computer; for typical kernels, the system time is in 1, 4, or 10 millisecond units with the same resolution. If the high resolution do_gettimeofday for earlier kernels, or getnstimeofday or ktime_get_real_ts64 for kernel 5.x and later, is selected, the units are 1 microsecond or 1 nanosecond, respectively, with resolution dependent on the host computer. If the raw monotonic getrawmonotonic or ktime_get_raw_ts64 is selected, the units are 1 nanosecond with resolution dependent on the host computer.
Optionally, files
''pixci.sh''
and
''pixci.rc''
can be used to install the
''pixci_i386.o''
or
''pixci_i386.ko''
driver so that the driver is automatically loaded as Linux boots.
When using
''pixci.rc'',
the Driver Configuration Parameters
are taken from
/etc/default/pixci
which is expected to have the line:
driver.pixci.parm=<driver_config_parameters>
As Linux requires the driver to be compiled on the specific system (i.e. exact match to ''uname -r'') in which the driver is to be used, precompiled drivers aren't included with XCLIB; The XCAP application's driver recompilation kit should be be used compile a driver on the target system. The ''pixci.sh'' and ''pixci.rc'' files are also supplied with the driver recompilation kit.
The ''pixci_x86_64.ko'' (for 2.6, 3.x, 4.x, and 5.x 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 several system timers, as selected by the Driver Configuration Parameters. If jiffies (or jiffies_64) and HZ are selected, the system time units are dependent on the Linux version and host computer; for typical kernels, the system time is in 1, 4, or 10 millisecond units with the same resolution. If the high resolution do_gettimeofday for earlier kernels, or getnstimeofday or ktime_get_real_ts64 for kernel 5.x and later, is selected, the units are 1 microsecond or 1 nanosecond, respectively, with resolution dependent on the host computer. If the raw monotonic getrawmonotonic or ktime_get_raw_ts64 is selected, the units are 1 nanosecond with resolution dependent on the host computer.
Optionally, files
''pixci.sh''
and
''pixci.rc''
can be used to install the
''pixci_i386.o''
or
''pixci_i386.ko''
driver so that the driver is automatically loaded as Linux boots.
When using
''pixci.rc'',
the Driver Configuration Parameters
are taken from
/etc/default/pixci
which is expected to have the line:
driver.pixci.parm=<driver_config_parameters>
As Linux requires the driver to be compiled on the specific system (i.e. exact match to ''uname -r'') in which the driver is to be used, precompiled drivers aren't included with XCLIB; The XCAP application's driver recompilation kit should be be used compile a driver on the target system. The ''pixci.sh'' and ''pixci.rc'' files are also supplied with the driver recompilation kit.
The ''pixci_armv7l.ko'' (for 3.x, 4.x, and 5.x 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_armv7l.ko [ PIXCIPARM=<driver_config_parameters> ]Some versions of insmod 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_armv7l.ko'' is loaded; the contents of frame buffer memory is lost when ''pixci_armv7l.ko'' is unloaded.
Video events are time stamped using one of several system timers, as selected by the Driver Configuration Parameters. If jiffies (or jiffies_64) and HZ are selected, the system time units are dependent on the Linux kernel's compile or configuration options selecting the ''HZ'' constant. If the high resolution do_gettimeofday for earlier kernels, or getnstimeofday or ktime_get_real_ts64 for kernel 5.x and later, is selected, the units are 1 microsecond or 1 nanosecond, respectively, with resolution dependent on the host computer. If the raw monotonic getrawmonotonic or ktime_get_raw_ts64 is selected, the units are 1 nanosecond with resolution dependent on the host computer.
Optionally, files
''pixci.sh''
and
''pixci.rc''
can be used to install the
''pixci_armv7l.o''
or
''pixci_armv7l.ko''
driver so that the driver is automatically loaded as Linux boots.
When using
''pixci.rc'',
the Driver Configuration Parameters
are taken from
/etc/default/pixci
which is expected to have the line:
driver.pixci.parm=<driver_config_parameters>
As Linux requires the driver to be compiled on the specific system (i.e. exact match to ''uname -r'') in which the driver is to be used, precompiled drivers aren't included with XCLIB; The XCAP application's driver recompilation kit should be be used compile a driver on the target system. The ''pixci.sh'' and ''pixci.rc'' files are also supplied with the driver recompilation kit.
The ''pixci_armv7l.ko'' (for 3.x, 4.x, and 5.x 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_armv7l.ko [ PIXCIPARM=<driver_config_parameters> ]Some versions of insmod 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_armv7l.ko'' is loaded; the contents of frame buffer memory is lost when ''pixci_armv7l.ko'' is unloaded.
Video events are time stamped using one of several system timers, as selected by the Driver Configuration Parameters. If jiffies (or jiffies_64) and HZ are selected, the system time units are dependent on the Linux kernel's compile or configuration options selecting the ''HZ'' constant. If the high resolution do_gettimeofday for earlier kernels, or getnstimeofday or ktime_get_real_ts64 for kernel 5.x and later, is selected, the units are 1 microsecond or 1 nanosecond, respectively, with resolution dependent on the host computer. If the raw monotonic getrawmonotonic or ktime_get_raw_ts64 is selected, the units are 1 nanosecond with resolution dependent on the host computer.
Optionally, files
''pixci.sh''
and
''pixci.rc''
can be used to install the
''pixci_armv7l.o''
or
''pixci_armv7l.ko''
driver so that the driver is automatically loaded as Linux boots.
When using
''pixci.rc'',
the Driver Configuration Parameters
are taken from
/etc/default/pixci
which is expected to have the line:
driver.pixci.parm=<driver_config_parameters>
As Linux requires the driver to be compiled on the specific system (i.e. exact match to ''uname -r'') in which the driver is to be used, precompiled drivers aren't included with XCLIB; The XCAP application's driver recompilation kit should be be used compile a driver on the target system. The ''pixci.sh'' and ''pixci.rc'' files are also supplied with the driver recompilation kit.
The ''pixci_aarch64.ko'' (for 3.x, 4.x, and 5.x 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_aarch64.ko [ PIXCIPARM=<driver_config_parameters> ]Some versions of insmod 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_aarch64.ko'' is loaded; the contents of frame buffer memory is lost when ''pixci_aarch64.ko'' is unloaded.
Video events are time stamped using one of several system timers, as selected by the Driver Configuration Parameters. If jiffies (or jiffies_64) and HZ are selected, the system time units are dependent on the Linux kernel's compile or configuration options selecting the ''HZ'' constant. If the high resolution do_gettimeofday for earlier kernels, or getnstimeofday or ktime_get_real_ts64 for kernel 5.x and later, is selected, the units are 1 microsecond or 1 nanosecond, respectively, with resolution dependent on the host computer. If the raw monotonic getrawmonotonic or ktime_get_raw_ts64 is selected, the units are 1 nanosecond with resolution dependent on the host computer.
Optionally, files
''pixci.sh''
and
''pixci.rc''
can be used to install the
''pixci_aarch64.o''
or
''pixci_aarch64.ko''
driver so that the driver is automatically loaded as Linux boots.
When using
''pixci.rc'',
the Driver Configuration Parameters
are taken from
/etc/default/pixci
which is expected to have the line:
driver.pixci.parm=<driver_config_parameters>
As Linux requires the driver to be compiled on the specific system (i.e. exact match to ''uname -r'') in which the driver is to be used, precompiled drivers aren't included with XCLIB; The XCAP application's driver recompilation kit should be be used compile a driver on the target system. The ''pixci.sh'' and ''pixci.rc'' files are also supplied with the driver recompilation kit.
To assist debugging of cameras and applications, XCLIB allows for logging of serial and I2C camera commands and responses as well as tracing use of pxd_ and pxe_ functions.
Under Windows NT and later, logging is enabled by specifying a path name of the log file via registry string value:
HKEY_CURRENT_USER\SOFTWARE\EPIX\PIXCI\XCLIBLOGor when using a 32 bit DLL on 64 bit Windows:
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\EPIX\PIXCI\XCLIBLOGUnder Linux and under Windows 95, 98, ME, logging is enabled by specifying a path name of the log file via environment variable:
XCLIBLOGThe specified file name is created if it does not exist; any directories specified must exist, they are not created. The log file is not cleared with each open and use of XCLIB, but will continue to increase in size. The log file is simple text and can be viewed with suitable text editor.
Use of the logging feature adds file I/O overhead to XCLIB functions, and can therefore affect the behavior of application programs.
Any faults upon open of XCLIB,
such as would be reported by calling
pxd_mesgFault()
or
::getFault
after use of
pxd_PIXCIopen
or
xclib_open,
are automatically
logged to the Windows Event Log, or to the Linux
syslog
,
even if
pxd_mesgFault()
or
::getFault
is not explicitly invoked.
This feature is always enabled and simplifies diagnosing of configuration problems on remote systems where the application using XCLIB has chosen not to obtain and report faults via pxd_mesgFault() or ::getFault.
The so-called Simple ``C'' Function Style Interface provides sufficient services for most common applications using a single frame grabber, or using multiple, identical, frame grabbers, or using one or more identical frame grabbers 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,[14] 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 frame grabbers, or frame grabbers with multiple functional units, the boards or units must be identical. In contrast, the Structured functions support multiple identical frame grabbers 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, frame grabbers.[15]
Fourth, the SCF functions share common names with libraries for other families of EPIX, Inc. frame grabbers. 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. frame grabbers, 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.[16]
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.
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
The pxd_setAdcGainOffset and pxd_setAdcColorGainOffsets sets gain and offsets (black level) of the analog to digital converter of selected PIXCI® frame grabbers.
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® frame grabbers 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 frame grabber 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.
For
PIXCI® A110:
The frame grabber provides
analog A-gain
in the range of 0.0 to 6.02 dB,
analog A-offset
in the range of -124/1024 to 124/1024,
digital B-gain
in the range of 0.0 to 6.00 dB,
and
digital B-offset
in the range of -512/1024 to 511/1024.
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 frame grabber is in use.
The remaining functions return:
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
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 frame grabber) 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 frame grabber dependent format as for pxd_getGPIn. For the PIXCI® SV2 and SV3 frame grabbers, 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,[17] 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,[17] 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:
See pxd_capturedFieldCount, pxd_capturedSysTicks, pxd_capturedSysTicksHi, and pxd_getGPIn which provide similar information if invoked in a timely manner, and are supported for all PIXCI® frame grabbers and Driver Configuration Parameters. See pxd_infoSysTicksUnits for the units and scaling of the pxd_buffersSysTicks and pxd_buffersSysTicks2.
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
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, synchronized to the camera's pixel clock; 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 frame grabbers,
nor for PIXCI® frame grabbers which do not support Camera Link.
For most, if not all, PIXCI® frame grabbers, 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:
The pxd_setCameraLinkCCOut returns:
pxbuffer_t pxd_capturingBuffer(unitmap); pxbuffer_t pxd_capturedBuffer(unitmap); pxvbtime_t pxd_capturedFieldCount(unitmap); uint32 pxd_capturedSysTicks(unitmap); uint32 pxd_capturedSysTicksHi(unitmap);
int unitmap; // Unit selection bit map (1 for single unit)
Information about the current frame buffer into which video is being capture, or the last captured frame buffer, is returned.
The pxd_capturingBuffer returns the buffer number into which video is being captured, or into which capture is imminent upon arrival of the next video frame, on the single unit specified by unitmap.
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 counts all video fields, whether captured or not.
The
pxd_capturedSysTicks
and
pxd_capturedSysTicksHi
returns the low 32 bits or upper 32 bits,
respectively, of the system time
when the last frame was captured,[18]
on the single unit specified by
unitmap.
Returns
As described above. The pxd_capturingBuffer returns 0 if the library is not open for use or capture is neither in progress nor imminent. The pxd_capturedBuffer, pxd_capturedFieldCount, pxd_capturedSysTicks, or pxd_capturedSysTicksHi, return 0 if the library is not open for use or no frame has been captured since the library was opened.
Note:
Invoking
pxd_goLive,
pxd_goLivePair,
pxd_goLivePairSeq
or a similar function does
not
cause the return values
of
pxd_capturedBuffer,
pxd_capturedFieldCount,
pxd_capturedSysTicks,
or
pxd_capturedSysTicksHi,
(such as due to a previous use of
pxd_goLive,
etc.),
be reset to 0 pending capture
of the next frame.
(But see
pxd_goAbortLive2
to explicitly
reset those values).
See Also
See pxd_buffersFieldCount, pxd_buffersSysTicks, and pxd_buffersSysTicks2 which provide similar information as pxd_capturedFieldCount, pxd_capturedSysTicks, or pxd_capturedSysTicksHi, but 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 and pxd_capturedSysTicksHi.
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
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 Color Representation Components "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 frame grabbers 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.
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. Nor should pxd_defineImage or pxd_defineImage3 be used from a multi-threaded environment, unless the call to pxd_defineImage or pxd_defineImage3 and the use of the resulting ''struct pximage *'' or ''struct pximage3 *'' are both protected against other threads invoking pxd_defineImage or pxd_defineImage3.
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:
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 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
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:
to save the entire AOI of all image frame buffers.pxio8_tifwriteseq(NULL, pxd_defineImage3(1, 1, pxd_imageZdim(), 0, 0, -1, -1, "Default"), NULL, "test.tif", 8, 0, 0, NULL);
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_eventCapturedFrameCreate2(unitmap, type); void pxd_eventCapturedFrameClose(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
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® SV8: The event is signaled at (approximately) the end of vertical drive. For PIXCI® A, A110, A310, CL1, CL2, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, e104x4-2f, e104x4-4b, e104x4-f2b, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, 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_eventCapturedFrameCreate2 return a HANDLE to a Windows event which is signaled once per captured video frame, on the single unit specified by unitmap. The event is signaled at (approximately) after the last pixel captured within the frame. For non-interlaced video, the pxd_eventCapturedFrameCreate2 and pxd_eventCapturedFieldCreate2 provide the same functionality.
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, e104x4-2f, e104x4-4b, e104x4-f2b, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB frame grabbers. 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, 7, and 8/10/11 the pxd_eventFieldCreate, pxd_eventCapturedFieldCreate, pxd_eventGPTriggerCreate, and pxd_eventFaultCreate create Synchronization style events. The pxd_eventFieldCreate2, pxd_eventCapturedFieldCreate2, pxd_eventCapturedFrameCreate2, 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.
Windows documentation may also refer to Synchronization Events as Auto Reset Events, and to Notification Events as Manual Reset Events.
The Windows HANDLE returned by pxd_eventFieldCreate, pxd_eventFieldCreate2, pxd_eventCapturedFieldCreate, pxd_eventCapturedFieldCreate2, pxd_eventCapturedFrameCreate2, 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:
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.HANDLE hEvent = pxd_eventFieldCreate(0x1); for (;;) { WaitForSingleObject(hEvent, INFINITE); // do something upon signal }
The
pxd_eventFieldClose,
pxd_eventCapturedFieldClose,
pxd_eventCapturedFrameClose,
pxd_eventGPTriggerClose,
pxd_eventFaultClose,
or
pxd_eventSerialClose
terminates the event previously created with
pxd_eventFieldCreate,
pxd_eventFieldCreate2,
pxd_eventCapturedFieldCreate,
pxd_eventCapturedFieldCreate2,
pxd_eventCapturedFrameCreate2,
pxd_eventGPTriggerCreate,
pxd_eventGPTriggerCreate2,
pxd_eventFaultCreate,
pxd_eventFaultCreate2,
or
pxd_eventSerialCreate
respectively.
Returns
The
pxd_eventFieldCreate,
pxd_eventFieldCreate2,
pxd_eventCapturedFieldCreate,
pxd_eventCapturedFieldCreate2,
pxd_eventCapturedFrameCreate2,
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 (Auto Reset) versus Notification (Manual Reset) Events and the advantages of each.
int pxd_eventFieldCreate(unitmap, irqfunc, statep); int pxd_eventFieldClose(unitmap, irqfunc); int pxd_eventCapturedFieldCreate(unitmap, irqfunc, statep); int pxd_eventCapturedFieldClose(unitmap, irqfunc); int pxd_eventCapturedFrameCreate(unitmap, irqfunc, statep); int pxd_eventCapturedFrameClose(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
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® SV8: The function is invoked at (approximately) the end of vertical drive. For PIXCI® A, A110, A310, CL1, CL2, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, 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_eventCapturedFrameCreate registers a callback function to be invoked once per captured video frame, on the single unit specified by unitmap. The function is invoked at (approximately) after the last pixel captured within the frame For non-interlaced video, the pxd_eventCapturedFrameCreate and pxd_eventCapturedFieldCreate provide the same functionality.
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, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB frame grabbers. 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_eventCapturedFrameCreate, 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_eventCapturedFrameClose,
pxd_eventGPTriggerClose,
pxd_eventFaultClose,
or
pxd_eventSerialClose
unregisters the callback function previously registered with
pxd_eventFieldCreate,
pxd_eventCapturedFieldCreate,
pxd_eventCapturedFrameCreate,
pxd_eventGPTriggerCreate,
pxd_eventFaultCreate,
or
pxd_eventSerialCreate,
respectively.
Returns
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).
int pxd_eventFieldCreate(unitmap, signum, rsvd2); int pxd_eventFieldClose(unitmap, signum); int pxd_eventCapturedFieldCreate(unitmap, signum, rsvd2); int pxd_eventCapturedFieldClose(unitmap, signum); int pxd_eventCapturedFrameCreate(unitmap, signum, rsvd2); int pxd_eventCapturedFrameClose(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
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® SV8: The signal is issued at (approximately) the end of vertical drive. For PIXCI® A, A110, A310, CL1, CL2, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, 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_eventCapturedFrameCreate registers a signal number to be signaled once per captured video frame, on the single unit specified by unitmap. The function is invoked at (approximately) after the last pixel captured within the frame. For non-interlaced video, the pxd_eventCapturedFrameCreate and pxd_eventCapturedFieldCreate provide the same functionality.
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_eventSerialCreate 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, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB frame grabbers. 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_eventCapturedFrameClose,
pxd_eventGPTriggerClose,
pxd_eventFaultClose,
or
pxd_eventSerialClose
unregisters the signaling previously registered with
pxd_eventFieldCreate,
pxd_eventCapturedFieldCreate,
pxd_eventCapturedFrameCreate,
pxd_eventGPTriggerCreate,
pxd_eventFaultCreate,
or
pxd_eventSerialCreate,
respectively.
Returns
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).
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
The EXSYNC and PRIN counter values for PIXCI® A, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 frame grabbers, 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, E8CAM, ELS2, SI, SI1, SI2, and SI4 frame grabbers 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 frame grabber is in use.
The pxd_setExsyncPrin returns:
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
The EXSYNC and PRIN mode bits for PIXCI® A, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 frame grabbers, 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, E8CAM, ELS2, SI, SI1, SI2, and SI4 frame grabbers 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 frame grabber is in use.
The pxd_setExsyncPrincMode returns:
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
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 frame grabbers 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 frame grabbers: 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 frame grabbers: The board does not provide general purpose input or output signals.
For the PIXCI® SV5L frame grabber: 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 frame grabbers: 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, D3XE, E1, E4, E8, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, EL1, SI, SI1, and SV8 frame grabbers for each functional unit of the PIXCI® E1DB, E4DB, E4G2-2F, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8CAM, E8DB, e104x4-2f, EL1DB, ELS2, SI2, SI4, and SV7 frame grabbers, and for the ''full'' functional unit of the PIXCI® E4G2-F2B and e104x4-f2b frame grabbers: 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® A110 frame grabber: The six general purpose output signals are set to bits 0x01 through 0x20 of setoutdata. The six general purpose input signals are sensed in bits 0x01 through 0x20 of the returned value of pxd_getGPIn. The general purpose inputs are level sensitive, the pxd_setGPIn has no effect.
For the PIXCI® ECB1 frame grabber, for each functional unit of the PIXCI® E4G2-4B, e104x4-4b, and ECB2 frame grabbers, and for each ''base'' functional unit of the PIXCI® E4G2-F2B and e104x4-f2b frame grabbers: 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 frame grabber: The board does not provide general purpose input or output signals.
For the PIXCI® CL1 frame grabber: 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 frame grabbers
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, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B,
E4TX2-2F, E4TX2-4B, E4TX2-F2B,
E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b,
EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280,
EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4
frame grabber.
Returns
The pxd_getGPIn and pxd_getGPOut return values as described above, and may also return:
The pxd_setGPIn and pxd_setGPOut return:
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
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 frame grabbers: There are no general purpose trigger inputs.
For the PIXCI® A110, A310, CL1, CL2, CL3SD, D, D24, D32, D2X, D32, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, SI4, SV7, and SV8 frame grabbers: 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 frame grabbers
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, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B,
E4TX2-2F, E4TX2-4B, E4TX2-F2B,
E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b,
EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280,
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:
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)
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 frame grabbers, 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.[19]
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 frame grabber. For example, three is returned, representing the common RGB interpretation, for each of: a) An frame grabber which stores YUYV or YCrCb 4:2:2 as two components per pixel, b) An frame grabber which stores Bayer pattern color as one component per pixel, c) An frame grabber 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.[20]
The pxd_imageXdim returns the number of pixels in a horizontal line.
The pxd_imageYdim returns the number of pixels in a vertical column.[21]
The pxd_imageZdim returns the number of image frame buffers. If multiple frame grabbers are in use, the pxd_imageZdim returns the number of image frame buffers assigned to each frame grabber.
If multiple frame grabbers 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.
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
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, A110, A310, SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, SV7, and SV8 frame grabbers: The pxd_setImageDarkBalance and pxd_setImageBrightBalance are not used.
For PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B,
E4TX2-2F, E4TX2-4B, E4TX2-F2B,
E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b,
EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280,
EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 frame grabbers:
The
pxd_setImageDarkBalance
and
pxd_setImageBrightBalance
are intended for use only
with Bayer output color cameras.
Returns
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
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 Color Representation Components "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 frame grabbers 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
The center pixel in each image frame buffer of each frame grabber 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]); } }
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)
Identification or other characteristics of the library, driver, and frame grabber(s) are returned.
The pxd_infoDriverId returns the identification string of the current PIXCI® frame grabber 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:
orprintf("%s", pxd_infoIncludeId());
if (strcmp(pxd_infoIncludeId(), pxd_infoLibraryId)) printf("Probable DLL mismatch\n");
The pxd_infoLibraryId returns the identification string of the current frame grabber 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:
where these are constants defined by inclusion ofPIXCI_A // the PIXCI® A Frame Grabber PIXCI_A110 // the PIXCI® A110 Frame Grabber PIXCI_A310 // the PIXCI® A310 Frame Grabber PIXCI_CL1 // the PIXCI® CL1 Frame Grabber PIXCI_CL2 // the PIXCI® CL2 Frame Grabber PIXCI_CL3SD // the PIXCI® CL3SD Frame Grabber PIXCI_D // the PIXCI® D, D24, D32 Frame Grabber PIXCI_D24 // the PIXCI® D24 Frame Grabber PIXCI_D32 // the PIXCI® D32 Frame Grabber PIXCI_D2X // the PIXCI® D2X Frame Grabber PIXCI_D3X // the PIXCI® D3X Frame Grabber PIXCI_D3XE // the PIXCI® D3XE Frame Grabber PIXCI_E1 // the PIXCI® E1 Frame Grabber PIXCI_E1DB // the PIXCI® E1DB Frame Grabber PIXCI_E4 // the PIXCI® E4 Frame Grabber PIXCI_E4DB // the PIXCI® E4DB Frame Grabber PIXCI_E4G22F // the PIXCI® E4G2-2F Frame Grabber PIXCI_E4G24B // the PIXCI® E4G2-4B Frame Grabber PIXCI_E4G2F2B // the PIXCI® E4G2-F2B Frame Grabber - Full unit PIXCI_E4G22BF // the PIXCI® E4G2-F2B Frame Grabber - Base unit(s) PIXCI_E4TX22F // the PIXCI® E4TX2-2F Frame Grabber PIXCI_E4TX24B // the PIXCI® E4TX2-4B Frame Grabber PIXCI_E4TX2F2B // the PIXCI® E4TX2-F2B Frame Grabber - Full unit PIXCI_E4TX22BF // the PIXCI® E4TX2-F2B Frame Grabber - Base unit(s) PIXCI_E8 // the PIXCI® E8 Frame Grabber PIXCI_E8CAM // the PIXCI® E8CAM Frame Grabber PIXCI_E8DB // the PIXCI® E8DB Frame Grabber PIXCI_E104X42F // the PIXCI® e104x4-2f Frame Grabber PIXCI_E104X44B // the PIXCI® e104x4-4b Frame Grabber PIXCI_E104X4F2B // the PIXCI® e104x4-f2b Frame Grabber - Full unit PIXCI_E104X42BF // the PIXCI® e104x4-f2b Frame Grabber - Base units PIXCI_EB1 // the PIXCI® EB1 Frame Grabber PIXCI_EB1G2 // the PIXCI® EB1G2 Frame Grabber PIXCI_EB1POCL // the PIXCI® EB1-PoCL Frame Grabber PIXCI_EB1G2POCL // the PIXCI® EB1G2-PoCL Frame Grabber PIXCI_EB1MINI // the PIXCI® EB1mini Frame Grabber PIXCI_MINIH2DB // the PIXCI® miniH2B Frame Grabber PIXCI_MINIH2F // the PIXCI® miniH2F Frame Grabber PIXCI_MINIH2X4F // the PIXCI® miniH2x4F Frame Grabber PIXCI_MF2280 // the PIXCI® mf2280 Frame Grabber PIXCI_EC1 // the PIXCI® EC1 Frame Grabber PIXCI_ECB1 // the PIXCI® ECB1 Frame Grabber PIXCI_ECB134 // the PIXCI® ECB1-34 Frame Grabber PIXCI_ECB2 // the PIXCI® ECB2 Frame Grabber PIXCI_EL1 // the PIXCI® EL1 Frame Grabber PIXCI_EL1DB // the PIXCI® EL1DB Frame Grabber PIXCI_ELS2 // the PIXCI® ELS2 Frame Grabber PIXCI_SI // the PIXCI® SI Frame Grabber PIXCI_SI2 // the PIXCI® SI2 Frame Grabber PIXCI_SI4 // the PIXCI® SI4/SI4a Frame Grabber PIXCI_SI4B // the PIXCI® SI4b Frame Grabber PIXCI_SI1 // the PIXCI® SI1 Frame Grabber PIXCI_SV2 // the PIXCI® SV2 Frame Grabber PIXCI_SV3 // the PIXCI® SV3 Frame Grabber PIXCI_SV4 // the PIXCI® SV4 Frame Grabber PIXCI_SV5 // the PIXCI® SV5, SV5A, SV5B, SV5L Frame Grabber PIXCI_SV7 // the PIXCI® SV7 Frame Grabber PIXCI_SV8 // the PIXCI® SV8 Frame Grabber
xcliball.h
.
Note that PIXCI® D24, and D32 frame grabbers
may be identified as a PIXCI® D frame grabber.
The pxd_infoSubmodel returns the submodel designation associated with the single selected unitmap. For PIXCI® SV2, SV3, SV4, SV5, SV7, and SV8 frame grabbers the value is 0. For PIXCI® SV5A frame grabbers the value is the predefined constant PIXCI_SV5_SV5A. For PIXCI® SV5B frame grabbers the value is the predefined constant PIXCI_SV5_SV5B. For PIXCI® SV5L frame grabbers the value is the predefined constant PIXCI_SV5_SV5L. For PIXCI® A, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 frame grabbers the value is a code indicating the specific camera for which the frame grabber is intended, as coded into the PIXCI®'s EEPROM.
The
pxd_infoUnits
returns the number of frame grabbers
(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.
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
The units, in microseconds, of the system time ticks provided by pxd_capturedSysTicks, pxd_capturedSysTicksHi, 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
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));
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) const 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; // pxd_saveTiff: see below // Other: Reserved, should be 0 int options; // Reserved, should be 0
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,[22] 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[0:7]='b', the image is resized by bilinear interpolation, which is suitable for continuous tone images. If loadmode[0:7]='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[8]!=0 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. If savemode=0, the same number of bits per pixel as the image frame buffer is saved. Otherwise, savemode[0:5] bits per pixel are saved; if savemode[7]=0 using most significant bit alignment, if savemode[7]!=0 using least significant bit alignment. Typically, savemode=16 is used with frame buffers of 10, 12, or 14 bits per pixel, forcing pixel values to be saved as 16 bits by padding each on the right with 6, 4, or 2 bits of zero, respectively.
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
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); }
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) const 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
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.[23] 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[0], 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 frame grabber'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 frame grabbers, with different video formats
using a common frame grabber, 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
frame grabber set to the same video format.
Returns
Images could follow one another in the file w/out padding, but it is often more efficient to have each image aligned with a multiple of the disk's block and sector size or the operating system's virtual page size. This example doesn't try to query the operating system for page, block and sector sizes - simply assume ...
#define ALIGNMENT 8192
Re-open's the file with each call to pxd_saveRawBuffers.
// save current contents of buffer 1 // as 1st image in file pxd_saveRawBuffers(0x01,"file1.vif", 1, 1, NULL, 0, ALIGNMENT, 0); // // save current contents of buffer 2 // as 2nd image in file pxd_saveRawBuffers(0x01,"file1.vif", 2, 2, NULL, 1, ALIGNMENT, 0); // // save current contents of buffer 3 // as 2nd image of file (replacing previous image) pxd_saveRawBuffers(0x01,"file1.vif", 3, 3, NULL, 1, ALIGNMENT, 0); // // save current contents of buffer 2 & 3 // as 3rd & 4th image of file pxd_saveRawBuffers(0x01,"file1.vif", 2, 3, NULL, 2, ALIGNMENT, 0);
For Windows: pre-opens the file, keeping it open until after last call to pxd_saveRawBuffers. This is more efficient, and it allows customizing the Windows' FILE_FLAG options, if needed.
HANDLE hFile = CreateFile("file2.vif", GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, 0, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL|FILE_FLAG_WRITE_THROUGH |FILE_FLAG_NO_BUFFERING, 0);
if (hFile != INVALID_HANDLE_VALUE) { // // save current contents of buffer 1 // as 1st image in file pxd_saveRawBuffers(0x01, NULL, 1, 1, hFile, 0, ALIGNMENT, 0); // // save current contents of buffer 2 // as 2nd image in file pxd_saveRawBuffers(0x01, NULL, 2, 2, hFile, 1, ALIGNMENT, 0); // CloseHandle(hFile); }
char* pxd_mesgErrorCode(errorcode); int pxd_mesgErrorCode2(errorcode, buf, bufsize); int errorcode; // Error return code char *buf; // Returned text size_t bufsize; // Size of *buf
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.
The pxd_mesgErrorCode returns a pointer to a error message string; a NULL value is returned if errorcode is not a recognized ''PXER...'' code.
The pxd_mesgErrorCode2 copies the error message string, or an empty string if errorcode is not a recognized ''PXER...'' code, into buf of maximum length bufsize. The copied string is truncated if buf is too small (but the copied string is always NULL terminated, unless bufsize=0).
The pxd_mesgErrorCode2 can be used with buf=NULL, returning the length of the error message string.
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 non-error conditions.
Thus, if an arbitrary
''library_function''
is described to return
''PXER...''
codes, the assumptions utilized in:
or in:int i; if ((i = library_function(...)) < 0) { printf("error %s\n", pxd_mesgErrorCode(i)); return; }
are valid.char *cp; if ((cp = pxd_mesgErrorCode(library_function(...)))) { printf("error %s\n", cp); return; }
The pxd_mesgErrorCode and pxd_mesgErrorCode2 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
The pxd_mesgErrorCode returns a char * to an error message, or NULL.
The pxd_mesgErrorCode2 returns the length of the (non-truncated) error message, excluding terminating NULL. The return type ''int'' doesn't match the ''size_t'' type of ''bufsize''; a possible annoyance that won't be changed in favor of historical compatibility. The maximum size of any error message is far smaller than the maximum value of either ''int'' or ''size_t''; no information is lost.
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
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:
The pxd_mesgFaultText's return code does not indicate whether the buf was too small; if after calling pxd_mesgFaultText"Configuration Error or Fault" ... ... "Check Configuration!" "See `Installation' and `In Case of Trouble' in ..."
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.strlen(buf) == bufsize-1
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
int pxd_PIXCIopen(driverparms, formatname, formatfile); int pxd_PIXCIclose();
const char *driverparms; // Driver configuration parms, or NULL or empty string const char *formatname; // Video format configuration name, or NULL or const char *formatfile; // Video format configuration file name, or NULL or empty string
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.[24] 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. Under Windows and Linux, the PIXCI® library and driver are automatically closed when the program exists, but an explicit pxd_PIXCIclose is still suggested.
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. Depending on host environment, some driver configuration parameters may only be effective when the driver is first installed (typically when the system is booted) and ignored when used from pxd_PIXCIopen.
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 (i.e. "" in C/C++). The formatname is not case sensitive.
For PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, and SV5L frame grabbers: The following predefined formatname's allow setting for standard video format configurations:
"RS-170"
"NTSC"
"NTSC/YC"
"CCIR"
"PAL"
"PAL/YC"
"PAL(M)"
"PAL(M)/YC"
"PAL(N)"
"PAL(N)/YC"
"SECAM"
"SECAM/YC"
"DEFAULT"
"NTSC/YC"
.
For PIXCI® SV5A and SV5B: Same as "NTSC"
.
For PIXCI® SV7 frame grabbers: The following predefined formatname's allow setting for standard video format configurations:
"RS-170"
"NTSC"
"NTSC(J)"
"NTSC(4.43)"
"CCIR"
"PAL"
"PAL(M)"
"PAL(N)"
"PAL(60)"
"DEFAULT"
"NTSC"
.
For PIXCI® SV8 frame grabbers: The following predefined formatname's allow setting for standard video format configurations:
"RS-170"
"NTSC"
"NTSC/YC"
"CCIR"
"PAL"
"PAL/YC"
"RS-170(SQR)"
"NTSC(SQR)"
"NTSC/YC(SQR)"
"CCIR(SQR)"
"PAL(SQR)"
"PAL/YC(SQR)"
"Video 720x480i 60Hz"
"RS-170"
.
"Video 720x480i 60Hz Color"
"NTSC"
.
"Video 720x480i 60Hz Y/Color"
"NTSC/YC"
.
"Video 720x576i 50Hz"
"CCIR"
.
"Video 720x576i 50Hz Color"
"PAL"
.
"Video 720x576i 50Hz Y/Color"
"PAL/YC"
.
"DEFAULT"
For PIXCI® A, CL1, CL3SD, D, D24, D32, D2X, D3X, D3XE, ELS2, E8CAM, SI, SI1, SI2, and SI4 frame grabbers: The following predefined formatname's are allowed:
"DEFAULT"
For PIXCI® CL2, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB frame grabbers: The following predefined formatname's are allowed:
"DEFAULT"
For PIXCI® A310 frame grabbers: The following predefined formatname's allow setting for standard video format configurations:
"RS-170"
"CCIR"
"Video 720x480i 60Hz"
"RS-170"
.
"Video 720x480i 60Hz RGB"
"Video 640x480i 60Hz"
"Video 640x480i 60Hz RGB"
"Video 720x576i 50Hz"
"CCIR"
.
"Video 720x576i 50Hz RGB"
"Video 768x576i 50Hz"
"Video 768x576i 50Hz RGB"
"Video 1920x1080i 60Hz"
"Video 1920x1080i 60Hz RGB"
"Video 1920x1080i 50Hz"
"Video 1920x1080i 50Hz RGB"
"Video 1920x1080p 60Hz"
"Video 1920x1080p 60Hz RGB"
"Video 1920x1080p 50Hz"
"Video 1920x1080p 50Hz RGB"
"Video 1280x720p 60Hz"
"Video 1280x720p 60Hz RGB"
"Video 1280x720p 50Hz"
"Video 1280x720p 50Hz RGB"
"XGA 1024x768 60Hz"
"XGA 1024x768 60Hz RGB"
"VGA 640x480 60Hz"
"VGA 640x480 60Hz RGB"
"SVGA 800x600 60Hz"
"SVGA 800x600 60Hz RGB"
"SXGA 1280x1024 60Hz"
"SXGA 1280x1024 60Hz RGB"
"RS343 875i 60Hz"
"RS343 875i 60Hz RGB"
"RS330 720x480i 60Hz"
"DEFAULT"
For PIXCI® A110 frame grabbers: The following predefined formatname's allow setting for standard video format configurations:
"RS-170"
"CCIR"
"Video 720x480i 60Hz"
"RS-170"
.
"Video 640x480i 60Hz"
"Video 720x576i 50Hz"
"CCIR"
.
"Video 768x576i 50Hz"
"Video 1920x1080i 60Hz"
"Video 1920x1080i 50Hz"
"Video 1280x720p 60Hz"
"Video 1280x720p 50Hz"
"XGA 1024x768 60Hz"
"VGA 640x480 60Hz"
"SVGA 800x600 60Hz"
"SXGA 1280x1024 60Hz"
"RS343 875i 60Hz"
"RS330 720x480i 60Hz"
"DEFAULT"
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 frame grabber 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
syslog
,
respectively, even if neither
pxd_mesgFault
nor
pxd_mesgFaultText
is explicitly invoked.
See the
PIXCI® USER'S MANUAL
for discussion of configuration options and settings.
Example
A PIXCI® A110, A310, SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, SV7, or SV8 frame grabber 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® frame grabber 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");
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
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.
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
A connection to the DirectX/DirectDraw feature of Windows is created in preparation for displaying live video on the graphics display. The hWnd specifies the window to which DirectX/DirectDraw access is requested on the single unit specified by unitmap.[25]
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
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
The pxd_renderDirectVideoLive initiates displaying of live video directly to the graphics display, using the Windows DirectX/DirectDraw feature. The pxd_renderDirectVideoUnLive terminates displaying of live video directly to the graphics display. 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.[26] 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.
The PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, and SV5L frame grabbers support resizing & reducing of captured video to fit the display area. The PIXCI® SV7 and SV8 frame grabbers do not support resizing of captured video to fit the display area.
If ClrKey1≠CLR_INVALID, the color key (chroma key) feature of the graphics display is enabled, so as to allow presenting live video only where the graphics display 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 system cards, and their drivers, differ widely in their support of live video. The minimal requirements are:
Each graphics display system 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 current mode and resolution, it does not change the graphics display system's current mode or resolution.
For PIXCI® A, A110, A310, CL1, CL2, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, and SI4: No known graphics display system supports the data formats produced by these frame grabbers.
For PIXCI® CL3SD and SI2: The frame grabber can't directly display live video to the graphics display.
If using a 32 bit version of XCLIB on Windows 64 bit, or if using a 32 bit PIXCI® frame grabber (i.e. PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, or SV5L) on Windows 64 bit, the pxd_renderDirectVideoLive will fail if the address range assigned by Windows to the graphics display overlay surface is above the 4 GiByte address.
The
pxd_renderDirectVideoLive
and
pxd_renderDirectVideoUnLive
do not support
use of multiple frame grabbers at different
video formats and resolutions.
Returns
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
and frame grabber provides support
pxd_renderDirectVideoLive.
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
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:
orStretchDIBits(hDC,nX,nY,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.[27]StretchDIBits(hDC,nX,nY+nHeight-1,nWidth,-nHeight,0,0,lrx-ulx,lry-uly,*,*,DIB_RGB_COLORS,SRCCOPY);
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 drivers, the quality of the rendered image can be significantly improved by using:
before pxd_renderStretchDIBits.SetStretchBltMode(hDC, STRETCH_DELETESCANS);
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 and its driver. For example, in 16 color (4 bit per pixel) graphics display adapter mode, monochrome images might be rendered using only 3 grey levels, with significant ''banding''. Good results will be obtained with graphics display adapters providing at least 16 bits per pixel for monochrome images, or at least 24 bits per pixel for color images.[28]
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 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 graphics display adapter 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
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 pxd_serialFlush(unitmap, rsvd0, flushread, flushwrite);
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 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[] int flushread; // 1: flush read queue int flushwrite; // 1: flush write queue
The pxd_serialConfigure, pxd_serialRead, and pxd_serialWrite allow use of the serial port on PIXCI® CL1, CL2, CL3SD, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB frame grabbers.
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, 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, EB1mini, 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, EB1G2, EB1G2-PoCL, miniH2B, miniH2F, miniH2x4F, mf2280, ECB2, EL1DB, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8DB, e104x4-2f, e104x4-4b, and e104x4-f2b, 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 default size of the transmit and received buffers are 1024 bytes; the size can be changed via the Driver Configuration Parameters.
The pxd_serialFlush flushes any data received, but not yet read, from the serial receive queue; and/or flushes any data written, but not yet sent, from the serial write queue.
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
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.
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: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.0, 8, 0, 1, 0, 0, 0); if (r < 0) return; // error // // For many cameras, it is helpful to flush the receive queue // before sending a command and checking the response. // Flushing the transmit queue isn't as helpful, but doesn't hurt. // pxd_serialFlush(0x1, 0, 1, 1); // // 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, // the camera may not be 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
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; ... }
int clSerialInit(...); int clSerialClose(...); int clSerialRead(...); int clSerialWrite(...); int clGetNumBytesAvail(...); int clFlushPort(...); int clGetErrorText(...); int clGetNumSerialPorts(...); int clGetSerialPortIdentifier(...); int clGetManufacturerInfo(...); int clGetSupportedBaudRates(...); int clSetBaudRate(...);
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® frame grabbers. These functions' API obeys the Camera Link V1.1 Serial API,[29] 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.
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
The multiplexer selection, contrast, brightness, and other A/D characteristics of PIXCI® SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, SV7, and SV8 frame grabbers, 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.
For the PIXCI® SV8, 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 High Density BNC connector closest to the S-Video connector, continuing with inmux=3, inmux=4, and inmux=5 selecting High Density BNC connectors progressively further away from the S-Video connector.
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.
For the PIXCI® SV8, The contrast, between 0.00 and 200.00, is the percent of the default contrast (gain). The brightness, between -100.0 and +100.0 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. Normally, the Ugain and Vgain are changed by the amount, but are not identical values. If Ugain=-243.0, the Vgain can be used alone to change saturation, between 0.0 to 242.78 percent of the default saturation.
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.
For the PIXCI® SV8: The hue, between -90.0 and 90.0, is the color phase shift, in degrees. The Ugain and Vgain, between 0.7943 and 199.5262, is the percent of the default Cb and Cr saturation, respectively.
The
pxd_getHue,
pxd_getUgain,
and
pxd_getVgain
return the current hue, U gain, and V gain
(or Cb and Cr saturation)
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 frame grabber is in use.
The pxd_setVidMux, pxd_setContrastBrightness, and pxd_setHueSaturation return:
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
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 frame grabbers 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 frame grabbers. The default timeout is likely to be inappropriate for cameras which have been programmed for an extended exposure and frame period, or for line scan cameras whose ''frame'' period depends on the number of lines captured.
For the PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, D3XE,
E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B,
E4TX2-2F, E4TX2-4B, E4TX2-F2B,
E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280,
EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 frame grabber
configured for triggered
capture, the
pxd_doSnap
''arms''
the frame grabber to capture the next externally triggered
frame, or both
''arms''
and initiates a software triggered frame,
according to the Video Format Configuration.
With externally triggered cameras,
the
timeout
must allow for the delay between
function call and subsequent trigger as well as the expected
exposure and readout period.
Returns
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 pxd_goAbortLive2(unitmap, abortoptions);
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 int abortoptions; // bit 0x2: clear 'captured' status // other bits reserved and should be 0
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 of 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 or pxd_goAbortLive2 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. If abortoptions&2, the ''last captured status'' returned by pxd_capturedBuffer, pxd_capturedFieldCount, pxd_capturedSysTicks, or pxd_capturedSysTicksHi, are reset to 0 (Reset of last captured status added to PIXCI® driver mid V3.8; earlier drivers ignore the option).
Except for pxd_goAbortLive and pxd_goAbortLive2, these functions return ''immediately'' without waiting for the beginning or conclusion of their stated effect.[30] The pxd_goAbortLive and pxd_goAbortLive2 both has effect and returns ''immediately''.
For PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 configured for triggered capture, the pxd_goSnap ''arms'' the frame grabber to capture the next externally triggered frame, or both ''arms'' and initiates a software triggered frame, according to the Video Format Configuration.
Note: The pxd_goLiveSeq implements continuous capture of videoperiod fields or frames (i.e. effectively a pxd_goLive) into a frame buffer, which at the appropriate time is terminated (i.e. effectively a pxd_goLive to the next buffer or a pxd_goUnLive after the last buffer) leaving the last captured field or frame. (For videoperiod>1, this is contrast to pausing for videoperiod-1 frames or fields, capturing for one frame or field, and then proceeding to the next frame buffer). Especially useful for large values of videoperiod, this supports display of live video during sequence capture. For videoperiod>1, use of pxd_capturingBuffer, to monitor capture progress, allows detecting final capture into each frame buffer one field or frame period sooner than logic based on use of pxd_capturedBuffer.
Note:
The
pxd_goLive
can be invoked while a previous
pxd_goLive
is in progress, causing capture to be shifted
to a different frame buffer.
This allows capture of a sequence of images
into designated frame buffers at irregular intervals.
Similarly,
pxd_goLivePair
can be invoked while a previous
pxd_goLivePair
is in progress,
and
pxd_goLiveSeq
can be invoked while a previous
pxd_goLiveSeq
is in progress so as to adjust the frame buffer selection(s),
capture period, etc.
Returns
See pxd_capturedBuffer, pxd_capturedSysTicks, pxd_capturedSysTicksHi, and pxd_capturedFieldCount to determine when an image frame buffer has been captured, and thereby whether the above functions have completed their 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); }
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
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, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 frame grabbers 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 frame grabber'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
frame grabbers.
For PIXCI® D, D24, and D32 frame grabbers,
the actual non-zero value of
gpin30wait
is immaterial; the frame grabber's hardware determines
the edge sensitivity of the General Purpose Input.
See
pxd_getGPIn
and
pxd_getGPOut
for discussion of the number of General Purpose Inputs and Outputs
are available on various frame grabbers.
Returns
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 (w. g.p input) // 5: wait for falling edge as sampled at VB (w. g.p input) 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 (w. g.p input) // 5: wait for falling edge as sampled at VB (w. g.p input) pxvbtime_t trig40delay; // Delay effect by .. fields.
int rsvd1; // Reserved, should be 0. ... int rsvd15; // Reserved, should be 0.
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, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 frame grabbers 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 frame grabber'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, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B,
E4TX2-2F, E4TX2-4B, E4TX2-F2B,
E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b,
EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280,
EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4
frame grabbers for use with non-interlaced cameras.[31]
See
pxd_getGPIn
and
pxd_getGPTrigger
for discussion of the number of General Purpose Inputs and
General Purpose Triggers
are available on various frame grabbers.
Returns
int pxd_quSnap(unitmap, buffer); int pxd_quLive(unitmap, buffer, rsvd);
int unitmap; // Unit selection bit map (1 for single unit) pxbuffer_t buffer; // Image frame buffer int rsvd; // Reserved, should be 0
The pxd_quSnap adds the buffer to the queue of requested single image captures, on each of the multiple units specified by unitmap. After capture, the buffer is removed from the queue.
The pxd_quLive adds the buffer to the queue of requested single image captures, on each of the multiple units specified by unitmap. After capture, the buffer is removed from the queue.
The pxd_goUnLive terminates a previously initiated pxd_quSnap or pxd_quLive after the current field or frame, and empties the queue, on each of the multiple units specified by unitmap.
The pxd_goAbortLive or pxd_goAbortLive2 terminates a previously initiated pxd_quSnap or pxd_quLive immediately, even if in the middle of a field, line, or pixel, and empties the queue, on each of the multiple units specified by unitmap.
Except for pxd_goAbortLive and pxd_goAbortLive2, these functions return ''immediately''; i.e. without waiting for the beginning or conclusion of their stated effect.
For each image captured, the pxd_quSnap has the same behavior as pxd_goSnap; for frame grabbers configured for triggered capture, the pxd_quSnap ''arms'' the frame grabber to capture the next externally triggered frame, or both ''arms'' and initiates a software triggered frame, according to the Video Format Configuration.
Initiation of image capture with pxd_quLive has the same behavior as pxd_goLive; although they differ in that pxd_goLive initiates continuous capture, while pxd_quLive is repeatedly invoked for continuous capture.
The total number of queued buffers is limited by the number of queue elements which have been reserved (via the Driver Configuration Parameters). As the pxd_quSnap and pxd_quLive were added in XCLIB mid Version 3.8, and to maintain backward compatibility, the default number of queue elements in V3.8 is zero. The default for later versions of XCLIB is TBD.
Each frame buffer can be queued more than once; limited by the number of queue elements. For example, queuing a single buffer multiple times, and requeuing each time the buffer is captured, has the same effect as using pxd_goLive; video is continuously captured into the same buffer.
The pxd_quSnap and pxd_quLive are not currently available for older, out-of-production, frame grabbers, specifically PIXCI® SV2, SV3, D, D24, and D32.
When used with early versions of PIXCI® A110, A310, SV7, SV8,
or with early versions of PIXCI® CL2,
E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B,
E4TX2-2F, E4TX2-4B, E4TX2-F2B,
E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b,
EB1, EB1-PoCL, EB1mini, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4
frame grabbers configured for non-triggered capture,
the
pxd_quSnap
does not allow queuing of buffers to be captured,
and behaves in a similar manner as
pxd_goSnap.
Returns
This example illustrates a typical video rate processing, with the ability to queue and capture several video frames while accommodating intermittent processing delays.
pxbuffer_t lastProcessedBuffer = pxd_capturedBuffer(0x1); pxbuffer_t n;
// Queue all buffers for capture for (n = 1; i <= pxd_imageZdim(1); n++) pxd_quLive(1, n);
// Monitor capture activity for (;;) { pxbuffer_t lastCapturedBuffer = pxd_capturedBuffer(0x1); if (lastCapturedBuffer == lastProcessedBuffer) { Sleep(5); // be nice to other processes continue; } // Process EACH buffer that has been captured but // not yet saved; as each buffer is processed, requeue to // capture another video frame. do { if (++lastProcessedBuffer > pxd_imageZdim(1)) lastProcessedBuffer = 1; .. process buffer 'lastProcessedBuffer' ... pxd_quLive(0x1, lastProcessedBuffer); } while (lastProcessedBuffer != lastCapturedBuffer) ; }
int pxd_goneLive(unitmap, rsvd); int unitmap; // Unit selection bit map (1 for single unit) int rsvd; // Reserved, should be 0
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.
pxvbtime_t pxd_videoFieldCount(unitmap); int unitmap; // Unit selection bit map (1 for single unit)
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, pxd_goLive, pxd_goLivePair, or pxd_goLiveSeq. 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, SV7, and SV8 frame grabbers: The count increments even when no video source is connected to the frame grabber. When no video source is connected, these frame grabbers substitute a synthetic ''video'' source, generating a synthetic image that can be captured with pxd_doSnap, pxd_goSnap, pxd_goLive, etc. For the PIXCI® SV8, the synthetic video field rate may not be the same as the expected video field rate.
For PIXCI® A, A110, A310, CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B,
E4TX2-2F, E4TX2-4B, E4TX2-F2B,
E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b,
EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280,
EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 frame grabbers:
The count increments only when a video source is connected to the frame grabber.
Returns
As described above.
int pxd_videoFieldsPerFrame(); int pxd_videoFieldsPerFrames(unitmap);
int unitmap; // Unit selection bit map (1 for single unit)
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 frame grabbers 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.
pxd_videoFormatAsIncludedInit(rsvd); int pxd_videoFormatAsIncluded(rsvd);
int rsvd; // Reserved, should be 0
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:
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.{ int r; #include "format.fmt" pxd_videoFormatAsIncludedInit(0); r = pxd_videoFormatAsIncluded(0); }
A ''format.fmt'' exported from a 64 bit Linux application can't be used by pxd_videoFormatAsIncluded in a 32 bit Linux, a 32/64 bit Windows, or a 32 bit DOS 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 frame grabbers at different formats and resolutions, the pxd_videoFormatAsIncluded only configures the first frame grabber; simple variants of the pxd_videoFormatAsIncludedInit macro can be defined to configure each of the other frame grabbers.
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
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); } ... }
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
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:
int pxd_SILICONVIDEO_getCameraType(unitmap);
int unitmap; // Unit selection bit map (1 for single unit)
A value indicating the type of the 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 frame grabbers, of SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 15C5, SILICON VIDEO® 1C45, SILICON VIDEO® 1M45, SILICON VIDEO® 5C10, SILICON VIDEO® 5M10, SILICON VIDEO® 642M, SILICON VIDEO® 642C, SILICON VIDEO® 643M, SILICON VIDEO® 643C, SILICON VIDEO® 9C10, 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 frame grabbers, of SILICON VIDEO® 10C-CL and SILICON VIDEO® 10M-CL cameras connected to PIXCI® E4 and E4DB (versions with PoCL), E8, E8DB, and EB1-PoCL frame grabbers, of SILICON VIDEO® 20C-CL, SILICON VIDEO® 20M-CL, SILICON VIDEO® 1514CL, and SILICON VIDEO® 1820CL cameras connected to PIXCI® E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB frame grabbers, and of SILICON VIDEO® 2KS-C and SILICON VIDEO® 2KS-M cameras connected to PIXCI® E8CAM frame grabbers is returned.
Current values are:
SILICONVIDEO_10CM6 // the SILICON VIDEO® 10C6 // and SILICON VIDEO® 10M6 SILICONVIDEO_10CL // the SILICON VIDEO® 10M-CL // and SILICON VIDEO® 10C-CL SILICONVIDEO_20CL // the SILICON VIDEO® 20M-CL // and SILICON VIDEO® 20C-CL SILICONVIDEO_1281 // the SILICON VIDEO® 1281M // and SILICON VIDEO® 1281C SILICONVIDEO_1310 // the SILICON VIDEO® 1310 // and SILICON VIDEO® 1310C SILICONVIDEO_1514CL // the SILICON VIDEO® 1514CL SILICONVIDEO_1820CL // the SILICON VIDEO® 1820CL SILICONVIDEO_1CM45 // the SILICON VIDEO® 1C45 // and SILICON VIDEO® 1M45 SILICONVIDEO_15C5 // the SILICON VIDEO® 15C5 SILICONVIDEO_2112 // the SILICON VIDEO® 2112 // and SILICON VIDEO® 2112C SILICONVIDEO_2KS // the SILICON VIDEO® 2KS-M // and SILICON VIDEO® 2KS-C SILICONVIDEO_5CM10 // the SILICON VIDEO® 5C10 // and SILICON VIDEO® 5M10 SILICONVIDEO_642 // the SILICON VIDEO® 642M // and SILICON VIDEO® 642C SILICONVIDEO_643 // the SILICON VIDEO® 643M // and SILICON VIDEO® 643C SILICONVIDEO_9C10 // the SILICON VIDEO® 9C10 SILICONVIDEO_9M001 // the SILICON VIDEO® 9M001 // and SILICON VIDEO® 9M001C SILICONVIDEO_9T001 // the SILICON VIDEO® 9M001C // and SILICON VIDEO® 9T001C SILICONVIDEO_HAS21 // the SILICON VIDEO® HAS21 SILICONVIDEO_WGA // the SILICON VIDEO® WGA-M // and SILICON VIDEO® WGA-C
Return values as described above, or 0 if the library is not open for use, or the wrong frame grabber is in use.
int pxd_SILICONVIDEO_setExposureGainOffset(unitmap,rsvd,exposure,gainA,offsetA, gainB,offsetB); int pxd_SILICONVIDEO_setExposureColorGainOffsets(unitmap,rsvd,exposure, gainsA,gainsB,offsetsA,offsetsB); int pxd_SILICONVIDEO_setExposure(unitmap,rsvd,exposure); 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
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 frame grabbers, of SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 15C5, SILICON VIDEO® 1C45, SILICON VIDEO® 1M45, SILICON VIDEO® 5C10, SILICON VIDEO® 5M10, SILICON VIDEO® 642M, SILICON VIDEO® 642C, SILICON VIDEO® 643M, SILICON VIDEO® 643C, SILICON VIDEO® 9C10, 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 frame grabbers, of SILICON VIDEO® 10C-CL and SILICON VIDEO® 10M-CL cameras connected to PIXCI® E4 and E4DB (versions with PoCL), E8, E8DB, and EB1-PoCL frame grabbers, of SILICON VIDEO® 20C-CL , SILICON VIDEO® 20M-CL, SILICON VIDEO® 1514CL, and SILICON VIDEO® 1820CL cameras connected to PIXCI® E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB frame grabbers, and of SILICON VIDEO® 2KS-C and SILICON VIDEO® 2KS-M cameras connected to PIXCI® E8CAM frame grabbers.
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 correspondence 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.
is a convenient method of changing only the camera's exposure.pxd_SILICONVIDEO_setExposureColorGainOffsets(..., 0, exposure, NULL, NULL, NULL, NULL);
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® 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® 20C-CL, and SILICON VIDEO® 20M-CL: The camera provides a single A-gain in the range of -1.9 to 2.9 dB. The camera provides a single B-gain in the range of -5.2 to 15.3 dB. The camera provides a single A-offset in the range of -0.19 to .84.
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® 15C5: The camera provides green-next-to-blue, blue, red, and green-next-to-red analog A-gain in the range of 3.5 to 24.0 dB. The camera provides a single digital B-gain in the range of 0 to 23.5 dB.
For SILICON VIDEO® 1C45 and SILICON VIDEO® 1M45: The camera provides a single A-gain in the range of 20log(1) to 20log(8) dB and green-next-to-blue, blue, red, and green-next-to-red B-gain in the range of 1.0 to 7.96875 dB. The camera provides a single A-offset in the range of 0.0 to +0.499. Different per-color gains can be set for the SILICON VIDEO® 1M45 (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® 2KS-C and SILICON VIDEO® 2KS-M: The camera provides a single A-gain of 0.0, 1.6, 2.9, or 4.1 dB. The camera provides a single A-offset in the range of -1.0 to 0.068.
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® 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.
For SILICON VIDEO® 1514CL: The camera provides green-next-to-blue, blue, red, and green-next-to-red analog A-gain in the range of 3.5 to 24.0 dB. The camera provides a single digital B-gain in the range of 0 to 23.5 dB.
For
SILICON VIDEO® 1820CL:
The camera provides
a single analog A-gain in the range of -6.0 to 17.5 dB.
The camera provides
green-next-to-blue, blue, red, and green-next-to-red
digital B-gain in the range of 0 to 12.0 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 frame grabber is in use.
The remaining functions return:
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 milliseconds
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 frame grabbers, of SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 15C5, SILICON VIDEO® 1C45, SILICON VIDEO® 1M45, SILICON VIDEO® 5C10, SILICON VIDEO® 5M10, SILICON VIDEO® 642M, SILICON VIDEO® 642C, SILICON VIDEO® 643M, SILICON VIDEO® 643C, SILICON VIDEO® 9C10, 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 frame grabbers, of SILICON VIDEO® 10C-CL and SILICON VIDEO® 10M-CL cameras connected to PIXCI® E4 and E4DB (versions with PoCL), E8, E8DB, and EB1-PoCL frame grabbers, of SILICON VIDEO® 20C-CL, SILICON VIDEO® 20M-CL, SILICON VIDEO® 1514CL, and SILICON VIDEO® 1820CL cameras connected to PIXCI® E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB frame grabbers, and of SILICON VIDEO® 2KS-C and SILICON VIDEO® 2KS-M cameras connected to PIXCI® E8CAM frame grabbers.
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® 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® 20C-CL, and SILICON VIDEO® 20M-CL: The camera supports subsampling ×1, ×2, ×4, and ×16 vertically. The camera supports ('L'<<8)|'T' and ('L'<<8)|'B' scan directions. The camera supports 8, 10, and 12 bit depths in combination with various numbers of taps; this function only supports changing the number of bits, not the number of taps. The camera supports multiple, non-overlapping vertical AOI; this function only supports a single AOI. The camera does not support a horizontal AOI. The frame period is not adjustable, except by increasing exposure so as to be larger than the nominal frame period. The pixel clock frequency is not adjustable.
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® 15C5: 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® 1C45 and SILICON VIDEO® 1M45: The camera supports subsampling ×1 horizontally and subsampling ×1, ×2, ×4, ×8, ×16, ×32, and ×64 vertically, in all combinations. If the camera has been configured so that ''subsample'' is actually binning, the camera supports ''subsampling'' ×1 and ×2 horizontally and ''subsampling'' ×1 and ×2 vertically, in all combinations. The camera does not support selectable 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® 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® 2KS-C and SILICON VIDEO® 2KS-M: The camera supports subsampling ×2, ×4, ×8, and ×16 vertically. The camera supports all four scan directions. The camera only supports 10 bit depth. The camera does not support AOI width selection. 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® 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.
For SILICON VIDEO® 15C5: 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, 10, and 12 bit depths in two tap configuration and supports 8 and 10 bit depths in eight tap configuration; this function only supports changing the number of bits, not the number of taps. The allowable frame period depends on the subsampling, AOI height, and AOI width. The pixel clock frequency is not adjustable.
For
SILICON VIDEO® 1820CL:
The camera supports subsampling ×1, ×2, and ×4
horizontally and ×1, ×2, ×4, and ×8
vertically, in all combinations.
The camera supports all four scan directions.
The camera supports 8, 10, and 12 bit depths
in two tap configuration and supports
8 and 10 bit depths in eight tap configuration;
this function only supports changing the
number of bits, not the number of taps.
The allowable frame period depends on
the subsampling, AOI height, and AOI width.
The pixel clock frequency is not adjustable.
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 frame grabber is in use.
The remaining functions return:
int pxd_SILICONVIDEO_setVideoAndTriggerMode(unitmap,rsvd,videomode,controlledmode, controlledtrigger,rsvd1,rsvd2,rsvd3,rsvd4); int pxd_SILICONVIDEO_setCtrlRates(unitmap,rsvd,exposure,framerate,rsvd12,rsvd13,rsvd14); int pxd_SILICONVIDEO_getVideoMode(unitmap); int pxd_SILICONVIDEO_getCtrlVideoMode(unitmap); double pxd_SILICONVIDEO_getCtrlFrameRate(unitmap); double pxd_SILICONVIDEO_getCtrlExposure(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 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': single-shot int triggermode; // Controlled trigger: 'n': none, 'b': snap function // '+': rising, '-': falling, ' double exposure; // Controlled exposure, milliseconds. double framerate; // Controlled frame rate, Hz. // Or inverse is single-shot min. retrigger period, sec.
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 frame grabbers, of SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 15C5, SILICON VIDEO® 1C45, SILICON VIDEO® 1M45, SILICON VIDEO® 5C10, SILICON VIDEO® 5M10, SILICON VIDEO® 642M, SILICON VIDEO® 642C, SILICON VIDEO® 643M, SILICON VIDEO® 643C, SILICON VIDEO® 9C10, 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 frame grabbers, of SILICON VIDEO® 10C-CL and SILICON VIDEO® 10M-CL cameras connected to PIXCI® E4 and E4DB (versions with PoCL), E8, E8DB, and EB1-PoCL frame grabbers, of SILICON VIDEO® 20C-CL, SILICON VIDEO® 20M-CL, SILICON VIDEO® 1514CL, and SILICON VIDEO® 1820CL cameras connected to PIXCI® E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, and EL1DB frame grabbers, and of SILICON VIDEO® 2KS-C and SILICON VIDEO® 2KS-M cameras connected to PIXCI® E8CAM frame grabbers.
Within controlled/trigger mode(s), the pxd_SILICONVIDEO_setCtrlRates sets the controlled frame rate, and, for selected cameras, the controlled exposure.
If videomode='f', the camera is free-running; the controlledmode, triggermode, and framerate parameters have no effect.[32]
If videomode='c', or videomode='c'|('g'<<8), initiation of each video field is controlled via the PIXCI® frame grabber. 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 frame grabber. 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_getCtrlExposure returns the controlled exposure, in milliseconds.
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® 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® 20C-CL, and SILICON VIDEO® 20M-CL: The camera supports free-run mode with videomode='f' and controlled mode with videomode='c'.
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® 15C5: 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® 1C45 and SILICON VIDEO® 1M45: The camera supports free-run mode with videomode='f', and controlled mode with videomode='c' selecting global shutter.
For SILICON VIDEO® 2112 and SILICON VIDEO® 2112C: The camera supports free-run mode with videomode='f' and controlled mode with videomode='c'. In controlled mode, the camera's exposure is determined by the pulse width of the trigger signal, and thus via pxd_SILICONVIDEO_setCtrlRates, rather than programmed via pxd_SILICONVIDEO_setExposure and similar functions.
For SILICON VIDEO® 2KS-C and SILICON VIDEO® 2KS-M: The camera does not support free-run mode. The camera supports 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'. In controlled mode, the camera's exposure is determined by the pulse width of the trigger signal, and thus via pxd_SILICONVIDEO_setCtrlRates, rather than programmed via pxd_SILICONVIDEO_setExposure and similar functions.
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® 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'.
For
SILICON VIDEO® 1280CL:
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.
Returns
The pxd_SILICONVIDEO_getVideoMode, pxd_SILICONVIDEO_getCtrlVideoMode, pxd_SILICONVIDEO_getCtrlTriggerMode, pxd_SILICONVIDEO_getCtrlFrameRate, and pxd_SILICONVIDEO_getCtrlExposure, returns values as described above, or 0 if the library is not open for use, or the wrong frame grabber is in use.
The pxd_SILICONVIDEO_setVideoAndTriggerMode and pxd_SILICONVIDEO_setCtrlRates returns:
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
The pxd_SILICONVIDEO_setAxC sets the automatic gain control (AGC) and automatic exposure control (AEC) hardware features of SILICON VIDEO® 1C45, SILICON VIDEO® 1M45, SILICON VIDEO® WGA-C, and SILICON VIDEO® WGA-M cameras connected to PIXCI® SI, SI1, SI2, and SI4 frame grabbers.
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 and the rate at which the AGC provides corrections. 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® 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® 20C-CL, and SILICON VIDEO® 20M-CL: The camera does not provide hardware AGC or AEC features.
For SILICON VIDEO® 1514CL: The camera does not provide hardware AGC or AEC features.
For SILICON VIDEO® 1820CL: The camera does not provide hardware AGC or AEC features.
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® 15C5: The camera does not provide hardware AGC or AEC features.
For SILICON VIDEO® 1C45 and SILICON VIDEO® 1M45: The camera provides AGC control of the A-gain, AGC control of the B-gain, and AEC control of the exposure (shutter). In addition to value 0, values for the agcA, agcB, and aec rate may range from 10 (slowest) to 200 (fastest); values greater than 100 may cause overshoot as automatic changes to gain or exposure may overcompensate. All enabled features share the same rate.
For SILICON VIDEO® 2112 and SILICON VIDEO® 2112C: The camera does not provide hardware AGC or AEC features.
For SILICON VIDEO® 2KS-C and SILICON VIDEO® 2KS-M: 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® 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 frame grabber is in use.
The remaining functions return:
double pxd_SILICONVIDEO_getMinMaxExposure(unitmap, exposure); double pxd_SILICONVIDEO_getMinMaxFramePeriod(unitmap, framePeriod); double pxd_SILICONVIDEO_getMinMaxCtrlFrameRate(unitmap, frameRate); double pxd_SILICONVIDEO_getMinMaxCtrlExposure(unitmap, exposure); 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 pxd_SILICONVIDEO_getMinMaxResolution(unitmap, subsamplep,aoileftp,aoitopp,aoiwidthp,aoiheightp, scandirectionp,bitdepthp,rsvd3p,rsvd4p);
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 int subsamplep[1]; // Subsample/decimation // High byte X, Low byte Y, 0x0101 for none int aoileftp[1]; // Left edge of partial scan AOI int aoitopp[1]; // Top edge of partial scan AOI int aoiwidthp[1]; // Width of partial scan AOI int aoiheightp[1]; // Height of partial scan AOI // aoi* are in reference to sensor // and independent of subsampling int scandirectionp[1]; // ('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 bitdepthp[1]; // bits per pixel value component int rsvd3p[]; // reserved, use NULL int rsvd4p[]; // reserved, use NULL
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_getMinMaxCtrlExposure corrects the prospective controlled, continuous mode exposure 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 pxd_SILICONVIDEO_getMinMaxResolution" corrects the prospective subsamplep[0], aoileftp[0], aoitopp[0], aoiwidthp[0], aoiheightp[0], scandirectionp[0], and bitdepthp[0] to the nearest valid value. Each is specified as the value of a one element array, each is 'returned' as the modified element of the same array. The interpretation of subsamplep[0], aoileftp[0], aoitopp[0], aoiwidthp[0], aoiheightp[0], scandirectionp[0], and bitdepthp[0] is identical to the similarly named parameter of pxd_SILICONVIDEO_setResolutionAndTiming.
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 frame grabber is in use.
int pxd_SILICONVIDEO_exportSettings(unitmap, rsvd, pathname); int pxd_SILICONVIDEO_importSettings(unitmap, rsvd, pathname);
int unitmap; // Unit selection bit map (1 for single unit) int rsvd; // Reserved, should be 0 const char *pathname; // File path name to export to, or import from
The pxd_SILICONVIDEO_exportSettings exports the current camera settings to pathname. The pxd_SILICONVIDEO_importSettings imports the current camera settings to pathname.
The
pxd_SILICONVIDEO_exportSettings
and
pxd_SILICONVIDEO_importSettings
are, currently, only available
for use with
SILICON VIDEO® WGA-C,
SILICON VIDEO® WGA-M,
SILICON VIDEO® 1C45,
SILICON VIDEO® 1M45,
SILICON VIDEO® 643M,
SILICON VIDEO® 643C,
SILICON VIDEO® 5C10,
SILICON VIDEO® 5M10,
SILICON VIDEO® 10C6,
SILICON VIDEO® 10M6,
SILICON VIDEO® 15C5,
SILICON VIDEO® 9M001,
SILICON VIDEO® 9M001C,
SILICON VIDEO® 9T001C,
SILICON VIDEO® 20C-CL,
SILICON VIDEO® 20M-CL,
SILICON VIDEO® 1514CL,
and
SILICON VIDEO® 1820CL
cameras.
Returns
The so-called Simple ``C'' Function Plus Style Interface is similar to the SCF Style Interface functions, but allows access to multiple, non-identical, frame grabbers.[33]
pxdstate_s * pxe_XCLIBinstantiate(); void pxe_XCLIBuninstantiate(instance);
pxdstate_s * instance; // Library instance
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 frame grabbers of different types.
In contrast, the slightly simpler
pxd_
functions use an implicit instance of the PIXCI® XCLIB Library,
but can only operate multiple frame grabbers of the same type.
Returns
The
pxe_XCLIBinstantiate
returns a pointer to a new instance,
or NULL for
malloc
error.
Example
Assume three PIXCI® frame grabbers. 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 frame grabber 1 into its buffer #5 pxe_doSnap(xclib1, 2, 5, 0); // snap frame grabber 2 into its buffer #5 pxe_doSnap(xclib1, 3, 5, 0); // snap frame grabber 1&2 into their respective buffer #5 pxe_doSnap(xclib2, 1, 5, 0); // snap frame grabber 3 into its buffer #5 ... pxe_PIXCIclose(xclib1) pxe_PIXCIclose(xclib2) pxe_XCLIBuninstantiate(xclib1); pxe_XCLIBuninstantiate(xclib2); exit(0);
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); uint32 pxe_capturedSysTicksHi(instance,unitmap); pxbuffer_t pxe_capturingBuffer(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_eventCapturedFrameCreate2(instance,unitmap,type); void pxe_eventCapturedFrameClose(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_eventCapturedFrameCreate(instance,unitmap,irqfunc,statep); int pxe_eventCapturedFrameClose(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_eventCapturedFrameCreate(instance,unitmap,signum,rsvd2); int pxe_eventCapturedFrameClose(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_serialFlush(instance,unitmap,rsvd0,read,write); 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_quSnap(unitmap, buffer); int pxe_quLive(unitmap, buffer, rsvd); 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
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 frame grabbers of different types.
In contrast, the slightly simpler
pxd_
functions use an implicit instance of the PIXCI® XCLIB Library,
but can only operate multiple frame grabbers of the same type.
Returns
See the corresponding
pxd_
functions.
Example
See pxe_XCLIBinstantiate.
int pxe_SILICONVIDEO_getCameraType(instance,unitmap); 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,exposure,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); double pxe_SILICONVIDEO_getCtrlExposure(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_getMinMaxCtrlExposure(instance,unitmap,exposure); 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); int pxe_SILICONVIDEO_getMinMaxResolution(instance,unitmap,subsamplep,aaoileftp,aoitopp, aoiwidthp,aoiheightp,scandirectionp,bitdepthp,rsvd3p,rsvd4p);
pxdstate_s * instance; // Library instance
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 frame grabbers of different types.
In contrast, the slightly simpler
pxd_
functions use an implicit instance of the PIXCI® XCLIB Library,
but can only operate multiple frame grabbers of the same type.
Returns
See the correspond
pxd_
functions.
Example
See pxe_XCLIBinstantiate.
The Open, Close, Information, and Fault services open the library for use, close the library after use, identify the types of frame grabber(s) and/or functional units present as well as the versions of library and driver, and provide descriptions of operational faults.[34]
int xclib_liblibid(info); #define xclib_libincid(info)
struct pxdevinfo *info; // Only 'libraryid' field used
The xclib_liblibid fills the libraryid field of the info instance of the pxdevinfo structure with an identification string of the current frame grabber 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
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 ""
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 frame grabbers(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 frame grabber 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. Depending on host environment, some driver configuration parameters may only be effective when the driver is first installed (typically when the system is booted) and ignored when used from xclib_open.
The formatfile may be the file name of a Video Configuration Format previously saved with ::exportStateCopy or with the XCAP application.[35] 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 frame grabber 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.
Under Windows 2000 and later, or under Linux, the additional
information provided by
::getFault
is automatically logged to the Windows Event Log, or to the Linux
syslog
,
respectively,
even if
::getFault
is not explicitly invoked.
Returns
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
Information about the driver and about the single selected unitmap frame grabber 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 frame grabber model,
frame grabber submodel (if applicable),
frame grabber revision level (if applicable),
the number of frame grabbers open for use,
the total amount of image frame buffer memory per frame grabber,
a driver identification string,
and a library identification string.
Returns
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
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
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
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 frame grabber 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
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 frame grabber'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 frame grabber in use, with effect upon the library's state.
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
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
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
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
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
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
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
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.[36] 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
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
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 frame grabber.
The ::fillStateCopy fills the pxvidphys structure of the Video Configuration Parameters to refer to image frame buffer number buffer, buffer≥1, within the frame grabber'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
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 frame grabber char *formatname; // A predefined name of video format int vidmode; // A PXMODE_ value
The ::initStateCopy initializes the statep instance of the pxvidstate structure to the default Video Configuration Parameters appropriate to the frame grabber 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 frame grabber 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 frame grabber 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.
#define xclib_DeclareVidStateStructs(Name) // deprecated #define xclib_InitVidStateStructs(Name) // deprecated #define xclib_DeclareVidStateStructs2(Name, Model) #define xclib_InitVidStateStructs2(Name, Model)
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 frame grabber'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, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB134, ECB2, EL1, EL1DB, ELS2, SI, SI2, SI4, SI1, SV2, SV3, SV4, SV5, and SV7 frame grabbers but not with the PIXCI® A110, A310, or SV8 frame grabbers. The xclib_DeclareVidStateStructs2 and xclib_InitVidStateStructs2 will work with all PIXCI® frame grabbers.
The Memory Access services provide several methods of accessing image data or other memory associated with the frame grabber.
The ::initPximage, ::initPximage3, ::initFilteredPximage, and ::initFilteredPximage3, are the suggested services for accessing frame grabber memory. Use of the low level ::io, ::getImap, and ::freeImap services should be minimized.
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 frame grabber memory uint altspace; // 0: image frame buffer memory uchar _farimap **accessptr; // Returned pointer to frame grabber 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]
The ::getImap obtains and returns a pointer into memory associated with the frame grabber, 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 frame grabber 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 frame grabber memory from adrs through adrs+accesslen-1 can be accessed by using *accessptr through *accessptr+accesslen-1.
The availability of a direct pointer into frame grabber memory varies with the type of frame grabber, the state of the frame grabber, the current operating system, and the current Driver Configuration Parameters.
Under Windows 95, 98, ME, NT, 2000, XP, XP(x64), Vista 32/64-Bit, 7 32/64-Bit, 8/10 32/64-Bit, and 11 64-Bit:
The access pointer
provided by
::getImap
can be used by the application to access frame grabber memory,
but cannot be passed to other applications or to system
services such as file I/O.
Returns
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
A pximage or pximage3 is initialized so as to provide access to the frame grabber's frame buffers, or to other memory associated with the frame grabber. 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, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B,
E4TX2-2F, E4TX2-4B, E4TX2-F2B,
E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b,
EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280,
EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 frame grabbers,
using
altspace=(('t'<<8)|'s')
provides access to the four byte video field counter
attached to each captured frame buffer.
Returns
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 frame grabber 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
The contents of frame grabber 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 frame grabber 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 frame grabber memory into the *buf; rw=PXRITE chooses write of the frame grabber 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
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
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 |
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 frame grabber's status qualifies for
PXVIST_RUNNING or for PXVIST_QUEUED
is frame grabber 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.
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
The ::pxdev.getVidStatus obtains the current video status of the single frame grabber 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 frame grabber 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 frame grabber 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:
where the Offset macro is defined in the C/C++ library.xclib.pxdev.getVidStatusValue(&xclibs.pxdev, 1, 0, PXSTAT_LASTIRQ, Offset(pxvidstatus2, time.vcnt));
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 (frame grabber 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:
The ::getVidStatusValue returns the requested value, or a PXER... code cast to a uint32.
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 struct pxbufstatus2 *status; // Buffer status
The ::pxlib.goingBufStatus obtains the status of image frame buffer of the single frame grabber selected by unitmap, ''returning'' the status in the status instance of a pxbufstatus or pxbufstatus2 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
int (xcdev.setSnapBuf) (&xcdev, unitmap, options, stateid, statep, time, buf1, tracker1); int (xcdev.setSnapPairBuf) (&xcdev, unitmap, rsvd1, stateid, statep, time, buf1, tracker1, buf2, tracker2); int (xcdev.setLiveBuf) (&xcdev, unitmap, options, 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 options; // Should be 0, except as described below 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
The ::setSnapBuf initiates a snap of a single video field or frame on the multiple units selected by unitmap into image frame buffer buf1. A snap or other video activity must not be in progress.
The ::setSnapBuf with options&1, adds the buf1 to the queue of requested single image captures, on the multiple units selected by unitmap; after capture, the buf1 is removed from the queue. Video activity other than a queued snap must not be in progress.
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. A snap or other video activity must not be in progress. The ::setSnapPairBuf 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. If continuous capture is already in progress, then the target image frame buffer is modified; other video activity must not be in progress.
The ::setLiveBuf with options&1, adds the buf1 to the queue of requested single image captures, on the multiple units selected by unitmap; after capture, the buf1 is removed from the queue. Video activity other than a queued live must not be in progress.
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 continuous pair capture is already in progress, then the target image frame buffers are modified; other video activity must not be in progress.
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 frame grabber 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. If continuous capture is already in progress, then the target memory spaces are modified; other video activity must not be in progress.
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.
The queued variations of ::setSnapBuf and ::setLiveBuf, are not currently available for older, out-of-production, frame grabbers, specifically PIXCI® SV2, SV3, D, D24, and D32.
When used with early versions of PIXCI® A110, A310, SV7, SV8,
or with early versions of PIXCI® CL2,
E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B,
E4TX2-2F, E4TX2-4B, E4TX2-F2B,
E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b,
EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280,
EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4
frame grabbers configured for non-triggered capture,
the
queued variations of
::setSnapBuf
does not allow queuing of buffers to be captured,
and behaves in a similar manner as
the unqueued
::setSnapBuf.
Returns
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
The ::setLiveSeqBuf initiates a snap of a sequence of video fields or frames on the multiple units selected by unitmap. If seqeunce capture is already in progress, then the target image frame buffers and other parameters are modified; other video activity must not be in progress.
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 frame grabber 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
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
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, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, and SI4 frame grabbers 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 frame grabber'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, the number of fields or frames to wait at each step, and when to conclude the capture.
The ::setLiveTrigBuf is not available for PIXCI® SV2 and SV3 frame grabbers. For PIXCI® D, D24, and D32 frame grabbers, the actual non-zero value of trigspec.gpin30wait is immaterial; the frame grabber'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 frame grabber 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
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
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.
For queued variations of ::setSnapBuf and ::setLiveBuf, the capture queue is emptied.
Both ::setUnLive and ::setAbortLive return ''immediately'' without waiting for completion.
For PIXCI® CL3SD, the
::setAbortLive
currently behaves the same as
::setUnLive.
Returns
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
The ::setCameraConfig configures the cameras connected to multiple frame grabbers selected by unitmap to the camera control component of a Video Format Configuration.
The camera control component of a Video Format Configuration currently supports:
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
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
The ::setVideoConfig configures the multiple frame grabbers 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 frame grabbers 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
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
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 frame grabbers 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 frame grabbers: 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 frame grabbers: The board does not provide general purpose input or output signals.
For the PIXCI® SV5L frame grabber: 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 frame grabber: The board does not provide general purpose input or output signals.
For the PIXCI® D, D24, and D32 frame grabbers: 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, D3XE, E1, E4, E8, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, EL1, SI, SI1, and SV8 frame grabbers, for each functional unit of the PIXCI® E1DB, EL1DB, E4DB, E4G2-2F, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8CAM, E8DB, e104x4-2f, ELS2, SI2, SI4, and SV7 frame grabbers, and for the ''full'' functional unit of the PIXCI® E4G2-F2B or e104x4-f2b: 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® A110 frame grabber: The six general purpose output signals are set to bits 0x01 through 0x20 of value. The six general purpose input signals are sensed in bits 0x01 through 0x20 of the returned value of ::getGpin. The general purpose inputs are level sensitive, the ::setGpin has no effect.
For the PIXCI® ECB1 frame grabber, for each functional unit of the PIXCI® E4G2-4B, e104x4-4b, and ECB2 frame grabbers, and for the ''base'' functional units of the PIXCI® E4G2-F2B or e104x4-f2b frame grabber: 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 frame grabbers: 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 frame grabbers
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, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B,
E4TX2-2F, E4TX2-4B, E4TX2-F2B,
E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b,
EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2x4F, mf2280,
EC1, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4.
Returns
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
Various frame grabber features are accessed and controlled.
For the PIXCI® CL1, CL2, CL3SD, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, 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.[37] 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:
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, E8, EB1, EB1-PoCL, EB1mini, EC1, ECB1, ECB1-34, and EL1 support any baud rate between 512.4 and 12,500,000.0 baud, other serial format characteristics are fixed in hardware. The PIXCI® E1DB, EB1G2, EB1G2-PoCL, miniH2B, miniH2F, miniH2x4F, mf2280, ECB2, EL1DB, E4DB, E4G2-2F, E4G2-4B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E4G2-F2B, E8DB, e104x4-2f, e104x4-4b, and e104x4-f2b, support 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.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
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('X','M','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
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 ::faultMessageBox combines ::getFault with MessageBox of the Windows API.
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
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.[38] 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 frame grabber'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 frame grabbers, or different video formats with a single frame grabber. 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 frame grabber 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
int (pxaux.errorCodeString) (&pxaux, errorcode);
struct pxauxservice pxaux; // A pxauxservice instance int errorcode; // Error return code
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.
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
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
See ::getFault for additional discussion regarding the cause and nature of faults.
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; // imageSaveTiff: See below // Other: Reserved, should be 0
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.
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
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 Color Representation Components 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 frame grabbers 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:
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.
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)
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
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.
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
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
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
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.
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;
... // see file pxlibcam.h }; typedef struct PXCam_SV2112State PXCam_SV2112State_s;
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_SetDefaultVideoValuesInCameraState or cmnd=PXCam_SetDefaultValuesInCameraState (deprecated), the camera state referenced by camstatep is initialized with default camera and video parameters. If cmnd=PXCam_SetDefaultAllValuesInCameraState, the camera state referenced by camstatep is initialized with default parameters (except for the ddch fields). 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 or cmnd=PXCam_DownloadCameraID2StateViaHandle, 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 fields of the camera state referenced by camstate2p are currently set. Other function arguments are not used.
If cmnd=PXCam_ExportCameraStateViaPathName, the camera state referenced by camstatep is exported. The porttype must be PXCam_PortIsPathName, the port must be a path name (null terminated char string). Other function arguments are not used.
If
cmnd=PXCam_ImportCameraStateViaPathName,
the camera state referenced by
camstatep
is imported
(except for
ddch
fields).
The
porttype
must be PXCam_PortIsPathName,
the
port
must be a path name (null terminated char string).
This does not, by itself, upload or implement the modified state.
Other function arguments are not used.
Returns
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.
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 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, sizeof(camstate)); camstate.ddch.len = sizeof(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); }
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, sizeof(camstate)); camstate.ddch.len = sizeof(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); }
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;
... // see file pxlibcam.h }; typedef struct PXCam_SV1310State PXCam_SV1310State_s;
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_SetDefaultVideoValuesInCameraState or cmnd=PXCam_SetDefaultValuesInCameraState (deprecated), the camera state referenced by camstatep is initialized with default camera and video parameters. If cmnd=PXCam_SetDefaultAllValuesInCameraState, the camera state referenced by camstatep is initialized with default parameters (except for the ddch fields). 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 or cmnd=PXCam_DownloadCameraID2StateViaHandle, 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 fields of the camera state referenced by camstate2p are currently set. Other function arguments are not used.
If cmnd=PXCam_ExportCameraStateViaPathName, the camera state referenced by camstatep is exported. The porttype must be PXCam_PortIsPathName, the port must be a path name (null terminated char string). Other function arguments are not used.
If
cmnd=PXCam_ImportCameraStateViaPathName,
the camera state referenced by
camstatep
is imported
(except for
ddch
fields).
The
porttype
must be PXCam_PortIsPathName,
the
port
must be a path name (null terminated char string).
This does not, by itself, upload or implement the modified state.
Other function arguments are not used.
Returns
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;
... // see file pxlibcam.h }; typedef struct PXCam_SV1281State PXCam_SV1281State_s;
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_SetDefaultVideoValuesInCameraState or cmnd=PXCam_SetDefaultValuesInCameraState (deprecated), the camera state referenced by camstatep is initialized with default camera and video parameters. If cmnd=PXCam_SetDefaultAllValuesInCameraState, the camera state referenced by camstatep is initialized with default parameters (except for the ddch fields). 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 or cmnd=PXCam_DownloadCameraID2StateViaHandle, 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 fields of the camera state referenced by camstate2p are currently set. Other function arguments are not used.
If cmnd=PXCam_ExportCameraStateViaPathName, the camera state referenced by camstatep is exported. The porttype must be PXCam_PortIsPathName, the port must be a path name (null terminated char string). Other function arguments are not used.
If
cmnd=PXCam_ImportCameraStateViaPathName,
the camera state referenced by
camstatep
is imported
(except for
ddch
fields).
The
porttype
must be PXCam_PortIsPathName,
the
port
must be a path name (null terminated char string).
This does not, by itself, upload or implement the modified state.
Other function arguments are not used.
Returns
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;
... // see file pxlibcam.h }; typedef struct PXCam_SV9M001State PXCam_SV9M001State_s;
The PXCam_SILICONVIDEO9M001 allows controlling the various options of the SILICON VIDEO® 10C6, SILICON VIDEO® 10M6, SILICON VIDEO® 10C-CL, SILICON VIDEO® 10M-CL, SILICON VIDEO® 15C5, SILICON VIDEO® 5C10, SILICON VIDEO® 5M10, SILICON VIDEO® 9C10, SILICON VIDEO® 9M001, SILICON VIDEO® 9M001C, and SILICON VIDEO® 9T001C, 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 or cmnd=PXCam_DownloadCameraID2StateViaHandle, 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 or cmnd=PXCam_DownloadCameraID2StateViaHandle must be used to obtain the camera ID so that other commands, below, can adapt properly.
If cmnd=PXCam_SetDefaultVideoValuesInCameraState or cmnd=PXCam_SetDefaultValuesInCameraState (deprecated), the camera state referenced by camstatep is initialized with default camera and video parameters. If cmnd=PXCam_SetDefaultAllValuesInCameraState, the camera state referenced by camstatep is initialized with default parameters (except for the ddch fields). 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 fields of the camera state referenced by camstate2p are currently set. Other function arguments are not used.
If cmnd=PXCam_ExportCameraStateViaPathName, the camera state referenced by camstatep is exported. The porttype must be PXCam_PortIsPathName, the port must be a path name (null terminated char string). Other function arguments are not used.
If cmnd=PXCam_ImportCameraStateViaPathName, the camera state referenced by camstatep is imported (except for ddch fields). The porttype must be PXCam_PortIsPathName, the port must be a path name (null terminated char string). This does not, by itself, upload or implement the modified state. Other function arguments are not used.
For
SILICON VIDEO® 9T001C cameras,
use of the
digitalgain
field
is deprecated; the former, separate digital
gain has been integrated into the
gainrgb[].
Returns
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;
... // see file pxlibcam.h }; typedef struct PXCam_SV642State PXCam_SV642State_s;
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, or cmnd=PXCam_DownloadCameraID2StateViaHandle, 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_SetDefaultVideoValuesInCameraState or cmnd=PXCam_SetDefaultValuesInCameraState (deprecated), the camera state referenced by camstatep is initialized with default camera and video parameters. If cmnd=PXCam_SetDefaultAllValuesInCameraState, the camera state referenced by camstatep is initialized with default parameters (except for the ddch fields). 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 fields of the camera state referenced by camstate2p are currently set. Other function arguments are not used.
If cmnd=PXCam_ExportCameraStateViaPathName, the camera state referenced by camstatep is exported. The porttype must be PXCam_PortIsPathName, the port must be a path name (null terminated char string). Other function arguments are not used.
If
cmnd=PXCam_ImportCameraStateViaPathName,
the camera state referenced by
camstatep
is imported
(except for
ddch
fields).
The
porttype
must be PXCam_PortIsPathName,
the
port
must be a path name (null terminated char string).
This does not, by itself, upload or implement the modified state.
Other function arguments are not used.
Returns
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;
... // see file pxlibcam.h }; typedef struct PXCam_SV643State PXCam_SV643State_s;
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_SetDefaultVideoValuesInCameraState or cmnd=PXCam_SetDefaultValuesInCameraState (deprecated), the camera state referenced by camstatep is initialized with default camera and video parameters. If cmnd=PXCam_SetDefaultAllValuesInCameraState, the camera state referenced by camstatep is initialized with default parameters (except for the ddch fields). 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 fields 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.
If cmnd=PXCam_ExportCameraStateViaPathName, the camera state referenced by camstatep is exported. The porttype must be PXCam_PortIsPathName, the port must be a path name (null terminated char string). Other function arguments are not used.
If
cmnd=PXCam_ImportCameraStateViaPathName,
the camera state referenced by
camstatep
is imported
(except for
ddch
fields).
The
porttype
must be PXCam_PortIsPathName,
the
port
must be a path name (null terminated char string).
This does not, by itself, upload or implement the modified state.
Other function arguments are not used.
Returns
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;
... // see file pxlibcam.h }; typedef struct PXCam_SV032State PXCam_SV032State_s;
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 or cmnd=PXCam_DownloadCameraID2StateViaHandle, 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_SetDefaultVideoValuesInCameraState or cmnd=PXCam_SetDefaultValuesInCameraState (deprecated), the camera state referenced by camstatep is initialized with default camera and video parameters. If cmnd=PXCam_SetDefaultAllValuesInCameraState, the camera state referenced by camstatep is initialized with default parameters (except for the ddch fields). 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 fields of the camera state referenced by camstate2p are currently set. Other function arguments are not used.
If cmnd=PXCam_ExportCameraStateViaPathName, the camera state referenced by camstatep is exported. The porttype must be PXCam_PortIsPathName, the port must be a path name (null terminated char string). Other function arguments are not used.
If
cmnd=PXCam_ImportCameraStateViaPathName,
the camera state referenced by
camstatep
is imported
(except for
ddch
fields).
The
porttype
must be PXCam_PortIsPathName,
the
port
must be a path name (null terminated char string).
This does not, by itself, upload or implement the modified state.
Other function arguments are not used.
Returns
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;
... // see file pxlibcam.h }; typedef struct PXCam_SVHAS2State PXCam_SVHAS2State_s;
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 or cmnd=PXCam_DownloadCameraID2StateViaHandle, 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_SetDefaultVideoValuesInCameraState or cmnd=PXCam_SetDefaultValuesInCameraState (deprecated), the camera state referenced by camstatep is initialized with default camera and video parameters. If cmnd=PXCam_SetDefaultAllValuesInCameraState, the camera state referenced by camstatep is initialized with default parameters (except for the ddch fields). 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 fields of the camera state referenced by camstate2p are currently set. Other function arguments are not used.
If cmnd=PXCam_ExportCameraStateViaPathName, the camera state referenced by camstatep is exported. The porttype must be PXCam_PortIsPathName, the port must be a path name (null terminated char string). Other function arguments are not used.
If
cmnd=PXCam_ImportCameraStateViaPathName,
the camera state referenced by
camstatep
is imported
(except for
ddch
fields).
The
porttype
must be PXCam_PortIsPathName,
the
port
must be a path name (null terminated char string).
This does not, by itself, upload or implement the modified state.
Other function arguments are not used.
Returns
int PXCam_SILICONVIDEO1CM45(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_SV1CM45State_s *camstatep; // Pointer to SILICON VIDEO parameters PXCam_SV1CM45State_s *camstate2p; // Pointer to SILICON VIDEO parameters struct pxvidstate *vidstatep; // Pointer to video state
struct PXCam_SVCM45State { struct pxddch ddch;
... // see file pxlibcam.h }; typedef struct PXCam_SV1CM45State PXCam_SV1CM45State_s;
The PXCam_SILICONVIDEO1CM45 allows controlling the various options of the SILICON VIDEO® 1C45 and 1M45 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 or cmnd=PXCam_DownloadCameraID2StateViaHandle, 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_SetDefaultVideoValuesInCameraState or cmnd=PXCam_SetDefaultValuesInCameraState (deprecated), the camera state referenced by camstatep is initialized with default camera and video parameters. If cmnd=PXCam_SetDefaultAllValuesInCameraState, the camera state referenced by camstatep is initialized with default parameters (except for the ddch fields). 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 status portion is not downloaded. 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_DownloadCameraStatusViaHandle, the status portion of 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_ExecuteCameraCommandViaHandle, the camera command(s) specified by calibrateColumnCorrection are executed. 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, aoiHeight, aegcWidth, aegcHeight, analogGain, and gainrgb fields of the camera state referenced by camstate2p are currently set. Other function arguments are not used.
If cmnd=PXCam_ExportCameraStateViaPathName, the camera state referenced by camstatep is exported. The porttype must be PXCam_PortIsPathName, the port must be a path name (null terminated char string). Other function arguments are not used.
If
cmnd=PXCam_ImportCameraStateViaPathName,
the camera state referenced by
camstatep
is imported
(except for
ddch
fields).
The
porttype
must be PXCam_PortIsPathName,
the
port
must be a path name (null terminated char string).
This does not, by itself, upload or implement the modified state.
Other function arguments are not used.
Returns
int PXCam_SILICONVIDEO20MCL(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_SV20MCLState_s *camstatep; // Pointer to SILICON VIDEO parameters PXCam_SV20MCLState_s *camstate2p; // Pointer to SILICON VIDEO parameters struct pxvidstate *vidstatep; // Pointer to video state
struct PXCam_SV20MCLState { struct pxddch ddch;
... // see file pxlibcam.h }; typedef struct PXCam_SV20MCLState PXCam_SV20MCLState_s;
The PXCam_SILICONVIDEO20MCL allows controlling the various options of the SILICON VIDEO® 20M-CL and 20C-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, calibration coefficients for reading sensor temperature, and factory lists of defects, 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. The cmnd=PXCam_DownloadCameraIDStateViaHandle causes a camera reset, thus video capture is interrupted, and the serial interface lines may float causing a serial ''framing'' error.
If cmnd=PXCam_SetDefaultVideoValuesInCameraState or cmnd=PXCam_SetDefaultValuesInCameraState (deprecated), the camera state referenced by camstatep is initialized with default camera and video parameters. If cmnd=PXCam_SetDefaultAllValuesInCameraState, the camera state referenced by camstatep is initialized with default parameters (except for the ddch fields). 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 status portion is not downloaded. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.
If cmnd=PXCam_DownloadCameraStatusViaHandle, the status portion of the camera state referenced by camstatep is downloaded from the camera, specifically the sensorTemp. 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 analogGain, adcGain, exposure, exposure2, exposure3, and exposure4 fields of the camera state referenced by camstate2p are currently set. Other function arguments are not used. Note that the minimum valid value of adcGain is provided, not the larger, minimum recommended value.
If
cmnd=PXCam_ImportCameraStateViaPathName,
the camera state referenced by
camstatep
is imported
(except for
ddch
fields).
The
porttype
must be PXCam_PortIsPathName,
the
port
must be a path name (null terminated char string).
This does not, by itself, upload or implement the modified state.
Other function arguments are not used.
Returns
int PXCam_SILICONVIDEO1820CL(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_SV1820CLState_s *camstatep; // Pointer to SILICON VIDEO parameters PXCam_SV1820CLState_s *camstate2p; // Pointer to SILICON VIDEO parameters struct pxvidstate *vidstatep; // Pointer to video state
struct PXCam_SV1820CLState { struct pxddch ddch;
... // see file pxlibcam.h }; typedef struct PXCam_SV1820CLState PXCam_SV1820CLState_s;
The PXCam_SILICONVIDEO1820CL allows controlling the various options of the SILICON VIDEO® 1820CL and 1514CL 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. The cmnd=PXCam_DownloadCameraIDStateViaHandle causes a camera reset, thus video capture is interrupted, and the serial interface lines may float causing a serial ''framing'' error.
If cmnd=PXCam_DownloadCameraID2StateViaHandle, a subset of 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. In comparison to PXCam_DownloadCameraIDStateViaHandle, only the information that can be accessed without causing a camera reset is downloaded.
If cmnd=PXCam_SetDefaultVideoValuesInCameraState, the camera state referenced by camstatep is initialized with default camera and video parameters, leaving other parameters unchanged. Other function arguments are not used. If cmnd=PXCam_SetDefaultAllValuesInCameraState, the camera state referenced by camstatep is initialized with default parameters (except for the ddch fields).
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 status portion is not downloaded. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used.
If cmnd=PXCam_DownloadCameraStatusViaHandle, the status portion of the camera state referenced by camstatep is downloaded from the camera, specifically the sensorTemp. The porttype must be PXCam_PortIspxdevservice, the port must be a (pxdevservice_s*). Other function arguments are not used. The cmnd=PXCam_DownloadCameraStatusViaHandle is only supported for the SILICON VIDEO® 1820CL.
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 anagainrgb, diggainrgb, framePeriod, and exposure fields of the camera state referenced by camstate2p are currently set. Other function arguments are not used.
If cmnd=PXCam_ExportCameraStateViaPathName, the camera state referenced by camstatep is exported. The porttype must be PXCam_PortIsPathName, the port must be a path name (null terminated char string). Other function arguments are not used.
If
cmnd=PXCam_ImportCameraStateViaPathName,
the camera state referenced by
camstatep
is imported
(except for
ddch
fields).
The
porttype
must be PXCam_PortIsPathName,
the
port
must be a path name (null terminated char string).
This does not, by itself, upload or implement the modified state.
Other function arguments are not used.
Returns
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.[39]
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 ... };
A pximage structure, after successful construction by ::pxlib.initPximage, pxd_defineImage, pximage_file, pximage_memory[40], 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 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).[41]
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 |
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.
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
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.
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
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:
The parm1 and parm2 are ignored.UINT_MAX / sizeof(struct pximadrs)
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.[43]
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.
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;
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 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 }
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;
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) |
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.
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;
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.[44]
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:
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; 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); } }
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); }
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:
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.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); }
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 |
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.[45]
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 frame grabbers (such as on the SILICON VIDEO® MUX or the 4MEG VIDEO frame grabbers), 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.
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. Deprecated functions are provided for backward compatibility with older applications; combined use of deprecated and newer functions is not recommended.
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. Deprecated functions are provided for backward compatibility with older applications; combined use of deprecated and newer functions is not recommended.
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. Deprecated functions are provided for backward compatibility with older applications; combined use of deprecated and newer functions is not recommended.
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. Deprecated functions are provided for backward compatibility with older applications; combined use of deprecated and newer functions is not recommended.
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. Deprecated functions are provided for backward compatibility with older applications; combined use of deprecated and newer functions is not recommended.
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. Deprecated functions are provided for backward compatibility with older applications; combined use of deprecated and newer functions is not recommended.
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:
before#define XCOBJ_TO_XCLIB_MACROS 1
in the application program.#include "xcliball.h"
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:
thepxd_unit(0x2); // select unit pxd_snap(...); // operate with selection
allows direct selection.pxd_doSnap(0x2, ...);
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:
This practice is still prohibited.struct pximage image;
image = *pxd_defimage();
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 ''orchestration'' by the application.
The pxd_video is replaced by pxd_goLive and pxd_goUnLive; although the latter functions always return immediately.
The PIXCI® EB1tg and EB1miniTg allow configuring the Camera Link resolution, bit depth, color space, and frame rate. They support both free-run and async-reset (also known as trigger or frame-on-demand) modes, and can output static test pattern images, time-varying test pattern images, or user-supplied images and image sequences.
This application note is intended to help the reader understand and utilize the PIXCI® frame generators, Familiarity with the Camera Link protocol and camera terminology such as free-run and async-reset is assumed. Familiarity with PIXCI® frame grabbers is helpful, as the frame generators can be most easily understood by their similarities and differences relative to, the more commonly used, frame grabbers.
The PIXCI® frame grabbers and generators are supported by XCAP (GUI) and XCLIB (SDK/API) software. To the extent possible, generator and grabber cards have identical, or at least analogous, architecture and controls. Much of the XCAP (GUI) software is identical, or at least symmetric, for grabbers and generators, except for exchange of terminology. The XCLIB (SDK/API) is also identical, except for re-interpreting ''capture'' and ''snap'' function names as ''stream'' and ''flash'', respectively.
Both frame grabbers and generators use a fixed set of frame buffers
in the host computer's memory for storage of image data,[46]
with the direction of pixel data flow
and of Camera Link control signals reversed.
Camera Link Video Signals
The PIXCI® frame grabber and generator card's
image resolution, bit depth, number of taps,
can be configured.
The grabber cards
''lock''
to the Camera Link clock provide by the camera and accept pixel data
at that rate;
the generator cards allow selecting the Camera Link clock frequency
and rate of pixel data.
The grabber cards expect FVAL, LVAL, DVAL (optional)
Camera Link signals from the camera,
the generator cards output FVAL, LVAL and DVAL (optional) signals.
In async-reset mode,
the grabber cards assert CC1 to trigger the camera
(driven by an external signal applied to the frame grabber,
or driven by a button click (GUI) or function call (SDK));
the generator cards accept a signal on CC1 to trigger output of
an image (in async-reset mode), or can be triggered via
button click (GUI) or function call (SDK).
Free-Run Mode Capture/Stream
In free-run mode, the grabber cards continuously monitor video timing and count FVAL's. If a frame capture is requested, the pixel data is stored in a designated frame buffer or a specified sequence of frame buffers; otherwise the pixel data is ignored.
In free-run mode, the generator cards maintain continuous, periodic, video timing (i.e. FVAL's and LVAL's) and count FVAL's; the contents of a specified frame buffer, or the contents of a specified sequence of frame buffers, are output as pixel data. If a frame buffer isn't specified, the generator cards output pixel data of a preselected test pattern; one such test ''pattern'' is all zeros, and thus black.[47]
A frame grabber ''snap'' captures one image into the designated frame buffer. In free-run mode, the frame grabber waits for the camera's next top of frame and captures the following frame. For the frame generator the corresponding activity is ''flash''; the frame generator waits for the next top of frame (as determined by the card's internal, periodic timing), and then outputs the contents of the designated frame buffer during the following frame period.
A frame grabber in ''live'' mode continuously captures incoming frames into one, or perhaps an alternating pair of, frame buffers. A frame generator in ''live'' mode continuously outputs images from one, or perhaps an alternating pair of, frame buffers.
A frame grabber, using the ''Video to Frame Buffers'' feature can ''record'' a sequence of incoming frames by capturing into a sequence of frame buffers; an option allows continuous recording by treating the frame buffers as a circular queue. A frame generator, using the ''Video from Frame Buffers'' feature can ''stream'' a sequence of output frames by outputting the contents of a sequence of frame buffers; an option allows continuous streaming by treating the frame buffers as a circular queue.
The XCAP (GUI) application was originally designed for frame grabbers; many of its features may not be useful for frame generator cards. The most important features for use of generator cards, the:
are analogous to the:Stream & Adjust dialog Video from Frame Buffers
features for frame grabbers, but ''re-tuned'' for use with frame generators. Features such as:Capture & Adjust Dialog Video to Frame Buffers
do not reference either capturing or streaming, as these features operate upon the contents of frame buffers independent of how frame buffer was, or will be, used. Other features of XCAP may not apply to frame generators, or may show the Snap, Capture, and Record terminology instead of Flash, Stream, and Stream, respectively.Save Image Load Image Save Image Sequence Load Image Sequence
The XCLIB (SDK/API) function names and documentation have not been changed for use with frame generators. The following examples illustrate use of XCLIB with frame grabbers, and the corresponding use with frame generators.
Capture one image and save:
versus load one image and flash:pxd_doSnap(...) pxd_saveTiff(...)
Continuous capture with eventual save:pxd_loadTiff(...) pxd_doSnap(...)
versus load image and continuous stream:pxd_goLive(...) ... until ? ... pxd_goUnLive(...) pxd_saveTiff(...)
Continuous capture into an alternating pair of buffers with eventual save of images:pxd_loadTiff pxd_goLive() ... until ? ... pxd_goUnLive(...)
versus load images and continuous stream from an alternating pair of buffers:pxd_goLivePair(..., 1, 2) ... until ? ... pxd_goUnLive(...) pxd_saveTiff(..., 1, ...) pxd_saveTiff(..., 2, ...)
Sequence capture and save:pxd_loadTiff(..., 1, ...) pxd_loadTiff(..., 2, ...) pxd_goLivePair(..., 1, 2) ... until ? ... pxd_goUnLive(...)
versus load sequence and stream:pxd_goLiveSeq(...) for (i = 0; i < pxd_imageZdim(); i++) pxd_saveTiff(..., i, ...)
for (i = 0; i < pxd_imageZdim(); i++) pxd_loadTiff(..., i, ...) pxd_goLiveSeq(...)
The example code above uses
pxd_loadTiff()
and
pxd_saveTiff().
The same code logic applies if they are replaced by
pxd_writeushort
and
pxd_readushort,
or
pxd_writeuchar
and
pxd_readuchar,
to modify the contents of a frame buffer
or to copy the contents of a frame buffer.
Video to/from Disk
The frame buffers are simply shared memory; shared between the video DMA engine and the application. The application can read the contents of a frame buffer while capture is in progress, or write the contents of a frame buffer while streaming is in progress. If using single buffer capture/stream (with pxd_goLive()), the application will likely read a partially updated image, or cause the streaming of a partially updated image (with exceptions for very slow video and/or very fast computers). Double buffering via pxd_goLivePair(), or N-buffering via pxd_goLiveSeq() in continuous/circular mode, supports applications such as continuous video to disk, or continuous video stream from disk, without the risk of ''partial'' artifacts.
Functions such as
pxd_capturedBuffer,
pxd_capturedFieldCount,
and
pxd_buffersFieldCount,
can be used to monitor the progress of
pxd_goLiveSeq().
For a frame grabber, they
report the last frame buffer that was (completely) captured,
the FVAL count at the time the last frame buffer was captured,
or the FVAL count when a specified frame buffer was captured
and help determine when the contents of one or more frame buffer
should be saved and thus
''emptied''.
For a frame generator, they report
the last frame buffer that was (completely) streamed,
the FVAL count at the time the last frame buffer was streamed,
or the FVAL count when a specified frame buffer was streamed
and help determine when the contents of one or more frame
buffers are
''empty''
and should be loaded.
Async-Reset Mode Capture/Stream
In async-reset mode, the grabber cards continuously monitor video timing and count FVAL's. If a frame capture is requested, the pixel data of a video frame is stored in a designated frame buffer; otherwise the pixel data is ignored. This is, in fact, identical to their behavior in free-run mode; the grabber card's participation in triggering the camera is independent of of the capture process.
In async-reset mode, the generator cards output one video frame (i.e. FVAL and LVAL's) per trigger, neither FVAL, LVAL, DVAL nor image data are output while awaiting a trigger. As for free-run mode, the cards output the contents of a specified frame buffer as pixel data, or outputs pixel data of a preselected test pattern if no frame buffer is specified.
For frame grabbers, a ''snap'' must be used to ''arm'' the frame grabber to capture the next frame from the camera. In a button-click trigger mode, the ''snap'' also triggers the camera via CC1 prior to arming the frame grabber.
For frame generators, a ''flash'' must be used to arm the frame generator so as to output desired pixel data upon sensing a trigger via CC1; if not armed, a preselected test pattern is output upon sensing a trigger. In a button-click trigger mode, the ''flash'' also triggers the frame generator to output an image.
Some cameras support triggering via a serial command. Such a feature has no impact on the video, image, or trigger operation of a frame grabber. For frame generators simulating such a camera, the application can implement this behavior by reading serial commands, and then invoking pxd_doSnap() in button-click trigger mode.
The same XCLIB code is used to
''snap''
or
''flash''
in async-reset mode as in free-run mode (above)
using
pxd_doSnap().
Serial Communication
Both frame grabbers and frame generator cards support serial communication via Camera Link. All Camera Link standard baud rates, 8 bit data, and full duplex communication, are supported.
While the frame generator cards are intended to simulate a camera, they do not, themselves, implement a suite of serial commands; nor do they send a serial ''hello'' message on start-up.[48] The XCAP (GUI) PIXCI® Serial Terminal allows the user to type and view serial data. The XCLIB (SDK/API) pxd_serial*() functions allow explicit reading and writing of serial data; implementation of a suite of serial commands is up to the application programmer.
As for the frame grabbers, the serial communication
of frame generators can be also accessed
via the Camera Link Serial API (i.e.
clserEPX.DLL
,
Windows),
a virtual COM port (Windows),
or a virtual tty (Linux).
General Purpose Inputs/Outputs
Both frame grabbers and frame generators support one or two General Purpose Input signals and one or two General Purpose Output signals. These level sensitive signals allow the XCAP (GUI) user or the XCLIB (SDK/API) application to sense or control a few external signals and devices without the need of using a separate ''Parallel I/O'' interface card. A few optional capture/stream features incorporate use of these signals (at the driver level), but, generally, these signals are independent of the triggering and capture/stream process.
In addition to the ''normal'' General Purpose Input signals, the frame generators report the state of CC1, CC2, CC3, and CC4 signals as additional general purpose, level sensitive, inputs. This is true regardless of whether a CC1, CC2, CC3, or CC4 signal is being used as a trigger input.
For a frame generator with two General Purpose Input signals:
bits 0 and 1 of the return value of
pxd_getGPIn()
are the current values of the General Purpose Input signals,
while bits 2 thru 5 are the current values of the
CC1 thru CC4 signals, respectively.
Trigger Inputs
Both frame grabbers and frame generators support a trigger input.
For frame grabbers, in async-reset modes, this trigger input may (depending on configuration) assert CC1 and trigger the camera. Otherwise, transitions (rising or falling, as configured) are counted and available to the XCAP (GUI) user or the XCLIB (SDK/API) application.
For frame generators, in async-reset modes, any one of the trigger input, CC1, CC2, CC3, or CC4 can be used to trigger the output of one image. (For the sake of brevity, these alternatives to CC1 triggers were not mentioned previously).
Independent of free-run vs async-reset modes,
any transitions on one of the trigger input, CC1, CC2, CC3, or CC4
can be counted
and available to the XCAP (GUI) user or the
XCLIB (SDK/API) application.
Miscellaneous Topics
For frame grabbers, the XCAP (GUI) image viewer window displays a selected frame buffer (or displays a sequence of the frame buffers, or a displays an array of tiles with all frame buffers, etc.); the image viewer window is updated when the a new image has been captured into a frame buffer. For frame generators, the image viewer window also displays a selected frame buffer (or variations thereof), but whether or not the contents of a frame buffer was streamed has no effect on the image display.
The contents of the current (or any) frame buffer is not changed by the frame generator's output of the preselected test pattern data. The image viewer window will not display the preselected test pattern data; nor will Histogram, Pixel Plot or similar features reflect the preselected test pattern data.
The pxd_doSnap function is mentioned above for capturing or generating one image, possibly with a side effect of triggering the camera or triggering the generator card. The pxd_doSnap waits until the operation is complete, a parameter specifies the allowable wait duration before timeout. For the sake of brevity, the alternate pxd_goSnap was not mentioned previously. The pxd_goSnap, initiates capture or generation of an image with optional triggering and returns (almost) immediately; the application can poll to detect completion or await an Event (Windows) or signal (Linux). The pxd_doSnap is essentially a convenience; a pxd_goSnap followed by a wait for completion.
Just as XCAP's
provides adjustments for PIXCI® frame grabbers, XCAP'sCapture & Adjust Dialog
provides PIXCI® frame generators a simple GUI for adjusting the resolution, bit depth, number of taps, and free-run versus async-reset modes. After setting and testing the configuration, export the video setup for use by XCLIB. See XCLIB's Using a Video Format Configuration Exported by XCAP application note.Stream & Adjust Dialog
For frame grabbers, the optional ''Multi-Tap Corrections'' allow reordering captured pixel data, so as to correct for cameras that don't output pixels in the typical left-to-right and top-to-bottom order. For frame generators, for user supplied pixel data, the ''Multi-Tap Corrections'' applies the inverse ordering correction - allowing simulation of a camera's atypical data ordering without pre-processing of the pixel data. The frame generator's preselected test pattern data is not affected by the ''Multi-Tap Corrections''.
After changing the video resolution, bit depth, color space, bit-packing, or multi-tap corrections parameters, any old user supplied data in the frame buffer(s), viewed under the new parameters, will typically appear garbled. Or the frame buffer(s) will be zero'ed, if the ''Clear Frame Buffers in Format Change'' option is set (i.e. via XCAP's Driver Assistant - Advanced Options or XCLIB's ''Driver Configuration Parameters''). For PIXCI® frame grabbers, new image(s) should be captured to replace old data. For PIXCI® frame generators, the frame buffer(s) should be reloaded or rewritten after changing the video parameters (this does not apply to preselected test pattern data, which is generated on-the-fly as per the current video parameters).
The Video for Linux (V4L2), Frame Server (DirectShow), TWAIN, and ImagePro drivers — providing alternate methods of accessing PIXCI® frame grabbers — do not support the PIXCI® EB1tg or EB1miniTg frame generator cards.
For PIXCI® frame grabbers, XCAP's Capture & Adjust dialog is typically constructed so that its right side has camera configuration controls (typically via serial commands), while the left side has PIXCI® configuration controls along with XCAP options and features. For PIXCI® frame generators, XCAP's Stream & Adjust dialog is organized with the right side providing controls of the ''phantom'' camera represented by the frame generator card, while the left side has controls for other features of the frame generator card (i.e. features not typically associated with a camera) along with XCAP options and features.
For generator cards configured in free-run mode, the reported video rate will be non-zero and the field count will continuously increase regardless of whether Flash or Live is selected. The field count and frame rate reflect continuous, periodic, video timing; which is maintained when outputting the preselected test pattern.
For frame grabbers, the ''PCI FIFO Overflow'' fault message indicates that data could not be pushed through the PCI or PCIe bus at video rates. For frame generators, the same fault message indicates that data could not be pulled through the PCIe bus at video rates; an underflow condition. In either case, resolution of the problem requires adjustments via the PC's BIOS; configuring video for lower resolution, smaller bit depth, fewer taps, or reduced clock rate; or selecting a different PC. See the PC Configuration Tips application note.
When used with a PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4 frame grabber, the XCLIB library identifies the camera for which the specific model of the PIXCI® frame grabber 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, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, or EL1DB.[49]
The SILICON VIDEO® cameras used in conjunction with a PIXCI® D2X, E8CAM, ELS2, SI, SI1, SI2, or SI4
frame grabber 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,
2KS-C, 2KS-M,
5C10, 5M10,
642M, 642C,
643M, 643C,
9C10,
9M001, 9M001C,
9T001C,
10C6, 10M6,
15C5,
WGA-C, and WGA-M
are all initialized by the XCLIB library to the manufacturer's suggested default mode.
To use the camera and PIXCI® frame grabber in other modes — such as triggered capture with asynchronous reset, binning, or integration — requires that both the camera and the PIXCI® frame grabber be reconfigured. The camera's operating mode must be reconfigured through the serial (RS-232 or Camera Link) port; the PIXCI® frame grabber 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® frame grabber 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® frame grabber, 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[50] and use its GUI to configure the camera's operating mode and the PIXCI® frame grabber 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):
PIXCI® PIXCI® Export Video Setup
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® frame grabber 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 ''Port'' or ''Chan'' tab of the right half of the dialog.Export Commands
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® frame grabber 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® frame grabber configuration. An example method follows for cameras connected via an RS-232 port under Windows[51]:
#include <windows.h> #include <stdio.h>
FILE *fp; HANDLE fd; DCB dcb; char *name = "COM1"; // or "COM2", "COM3", etc. int i, n, j; // // 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];
// // For cameras with readable commands with an obvious // end-of-command indicator, // or easy to parse binary style commands. // #if 1
// // Send byte of command. // buf[0] = i; WriteFile(fd, buf, 1, &w, NULL);
// // Is the previous 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 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
// // For cameras w. binary style, variable length, commands // which don't have an obvious 'end of command' indicator. // If given the raw binary, we would have to decode the // byte stream as per the camera's command codes and structure. // Instead, expect that the file contains the commands in hex, // with a new-line indicating end of command. // #else #define HexToInt(c) ((c)>='0'&&(c)<='9'? (c)-'0': (c)>='A'&&(c)<='F'? (c)-'A': (c)-'a')
if (i == '\n') Sleep(1000); else if (i == '\r') ; // only needed for Windows, because // file was opened w. "rb" mode else if ((j = fgetc(fp)) != EOF) { i = HexToInt(i); j = HexToInt(j); buf[0] = (i<<4) | j; WriteFile(fd, buf, 1, &w, NULL); } #endif } // // All done. Clean up. // fclose(fp); CloseHandle(fd);
An example method follows for cameras connected via an RS-232 port under Linux:
#include <termios.h> #include <unistd.h> #include <stdio.h> #include <fcntl.h> #include <poll.h>
FILE *fp; int fd; char *name = "/dev/ttyS0"; // or ttyS1, ttyS2, etc int i, n, j; struct termios tio; // // Open access to tty port. // fd = open(name, O_RDWR | O_NOCTTY | O_NONBLOCK); if (fd < 0) exit(1); // can't open tty port - produce suitable error message tcgetattr(fd, &tio); tio.c_cflag = CLOCAL | CREAD; tio.c_iflag = IGNBRK; tio.c_oflag = 0; tio.c_lflag = 0; tio.c_cc[VMIN] =1; tio.c_cc[VTIME]=0; tio.c_cflag |= B9600; // replace with camera's baud rate tio.c_cflag |= CS8; // assume camera with 8 bits per word tio.c_cflag |= 0; // assume no parity used tio.c_cflag |= CSTOPB; // camera may spec fewer stop bits, more doesn't hurt! tio.c_cflag |= 0; // assume no flow control used tcflush(fd, TCIFLUSH); tcsetattr(fd,TCSANOW,&tio); // // Open exported file with camera's RS-232 data stream. // fp = fopen("camera.dat", "r"); if (!fp) { close(fd); exit(1); // can't find file - produce suitable error message } // // Send each command from file through tty 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; ) { uchar buf[1];
// // For cameras with readable commands with an obvious // end-of-command indicator, // or easy to parse binary style commands. // #if 1
// // Send byte of command. // buf[0] = i; write(fd, buf, 1);
// // Is the previous 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 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
// // For cameras w. binary style, variable length, commands // which don't have an obvious 'end of command' indicator. // If given the raw binary, we would have to decode the // byte stream as per the camera's command codes and structure. // Instead, expect that the file contains the commands in hex, // with a new-line indicating end of command. // #else #define HexToInt(c) ((c)>='0'&&(c)<='9'? (c)-'0': (c)>='A'&&(c)<='F'? (c)-'A': (c)-'a')
if (i == '\n') Sleep(1000); else if ((j = fgetc(fp)) != EOF) { i = HexToInt(i); j = HexToInt(j); buf[0] = (i<<4) | j; write(fd, buf, 1); } #endif } // // All done. Clean up. // fclose(fp); close(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, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, or EL1DB Camera Link serial port:
FILE *fp; int i, n, j; // // 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 baud // rate to match the camera! pxd_serialConfigure(0x01, 0, 9600.0, 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];
// // For cameras with readable commands with an obvious // end-of-command indicator, // or easy to parse binary style commands. // #if 1
buf[0] = i; pxd_serialWrite(0x01, 0, buf, 1);
// // Is the previous 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 Hitachi using fixed length size commands if ((++n % 18) == 0) Sleep(1000); #endif
// // For cameras w. binary style, variable length, commands // which don't have an obvious 'end of command' indicator. // If given the raw binary, we would have to decode the // byte stream as per the camera's command codes and structure. // Instead, expect that the file contains the commands in hex, // with a new-line indicating end of command. // #else #define HexToInt(c) ((c)>='0'&&(c)<='9'? (c)-'0': (c)>='A'&&(c)<='F'? (c)-'A': (c)-'a')
if (i == '\n') Sleep(1000); else if (i == '\r') ; // only needed for Windows, and because file was opened w. "rb" mode else if ((j = fgetc(fp)) != EOF) { i = HexToInt(i); j = HexToInt(j); buf[0] = (i<<4) | j; pxd_serialWrite(0x01, 0, buf, 1); } #endif
// // To keep things simple, we are delaying after each command // rather than waiting, reading, and checking the camera's response. // At least flush the read buffer of the response sent by the camera, // so that the responses don't accumulate and cause pxd_mesgFault() // to report 'Serial Buffer Overflow' // while (pxd_serialRead(0x01, 0, buf, 1) == 1) ;
} // // All done. Clean up. // fclose(fp);
For selected Camera Link cameras and for all SILICON VIDEO® cameras, the Video Format Configuration files saved by XCAP includes 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[52] and use its GUI to configure the camera's operating mode and the PIXCI® frame grabber 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® frame grabber Video Format Configuration parameters to a file with:
XCAP can now be closed.PIXCI® PIXCI® Export Video Setup
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® frame grabber 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, ISVI, 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.[53]
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:
If thePIXCI® (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
checkbox is active (i.e. selectable), then this integrated support of serial commands by the XCLIB library is available for the current camera.Include Camera Link Serial Commands
For SILICON VIDEO® cameras, the
orInclude Camera Link Serial Commands
orInclude I2C Commands
will be active, indicating integrated support of Camera Link serial, I2C serial, or SPI serial, commands by the XCLIB library.Include SPI Commands
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® frame grabber configuration. In contrast, adjusting the camera's trigger mode, binning, bit-depth, or area of interest features do reflect upon the PIXCI® frame grabber'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.
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.
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 frame grabbers, or camera manufacturer and model for other frame grabbers), the resolution (i.e. capturing more or fewer pixels per line or column), and other settings related to the frame grabber's hardware.
The XCLIB library provides a suitable default Video Format Configuration for each PIXCI® frame grabber, 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[54] Video Format Configuration, although XCAP uses the term ''Video Setup''. In XCAP, use:
to select an alternate camera or format from XCAP's predefined selections. Or, use:PIXCI® PIXCI® Open/Close Close Camera & Format .. select alternate camera or format OK Open
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:Capture (in PIXCI® Image Viewer) Adjustments
Regardless of method, export the video setup with:PIXCI® Video Setup .. adjust video configuration .. OK
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.PIXCI® PIXCI® Export Video Setup
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:
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.[55]{ #include "format.fmt" // a saved video setup file pxd_videoFormatAsIncludedInit(0); pxd_videoFormatAsIncluded(0); // configure as per the above }
The Video Format Configuration files are portable among the Windows, Linux, and DOS 32 bit operating systems. As of 27-Apr-2011, the Video Format Configuration files are also portable between Windows 32 and 64 bit operating systems. The Video Format Configuration files are not portable between Linux 64 bit and other operating systems.
The architecture of the PIXCI® A, A110, A310, CL1, CL2, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI4, SV2, SV3, SV4, SV5, SV5A, SV5B, SV5L, SV7, and SV8 frame grabbers 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.[56]
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 frame grabber; see examples below.
If multiple frame grabbers are in use, the
which commands frame grabbers 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 frame grabber is provided with its own pxvidphys. Thus, ::setLivePhys allows for an array of pxvidphys specifications, one per selected frame grabber.xcdev.setLiveBuf(0x03, ..., 1);
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 adapter secondary surface[57] (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
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.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, sizeof(vidphys)); vidphys.ddch.mos = PXMOS_VIDPHYS; vidphys.ddch.len = sizeof(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!
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, sizeof(vidphys)); vidphys.ddch.mos = PXMOS_VIDPHYS; vidphys.ddch.len = sizeof(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!
When a Bayer output camera is used with a PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4 frame grabber, 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.
pxd_doSnap(1, 1, 0);
unsigned int reference[3] = {0,0,0}; unsigned int target[3] = {0,0,0}; pxd_setImageBrightBalance(1, reference, target, 0.00);
Or can be done by directly reading pixel values: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();
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.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);
And invoke:target[0] = target[1] = target[2] = max(max(reference[0], reference[1]), reference[2]);
using the preferred gamma correction coefficient to apply the new coefficients to images accessed via pxd_defineImage.pxd_setImageBrightBalance(1, reference, target, 0.60);
When a Bayer output camera is used with a PIXCI® CL1, CL2, CL3SD, D, D24, D32, D2X, D3X, D3XE, E1, E1DB, E4, E4DB, E4G2-2F, E4G2-4B, E4G2-F2B, E4TX2-2F, E4TX2-4B, E4TX2-F2B, E8, E8CAM, E8DB, e104x4-2f, e104x4-4b, e104x4-f2b, EB1, EB1G2, EB1-PoCL, EB1G2-PoCL, EB1mini, miniH2B, miniH2F, miniH2x4F, mf2280, EC1, ECB1, ECB1-34, ECB2, EL1, EL1DB, ELS2, SI, SI1, SI2, or SI4 frame grabber, 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:
or the slightly simpler and easier to use from non-C/C++ environments:// // 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);
// // 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);
On newer PIXCI® frame grabbers with the PoCL feature, power is applied to the camera only while the XCLIB is opened, such as via pxd_PIXCIopen; power to the camera is removed when XCLIB is closed. This allows for safe ''hot-plugging'' of the camera to the PIXCI® frame grabber by having XCLIB closed while connecting or disconnecting the Camera Link cables.
The Camera Link specification involves a four second delay during the PoCL ''handshaking'' protocol: the camera and frame grabber are negotiations as to whether the camera requires power and whether the frame grabber should apply power. Thus, after opening XCLIB there may be a four second delay before the camera outputs video and before the camera is able to respond to serial commands.
The pxd_PIXCIopen does not delay its return while power is being negotiated; it is the application's responsibility to wait. However, if pxd_PIXCIopen is used with a a video setup file that includes camera serial commands and if the camera acknowledges each serial command, it is often possible to force pxd_PIXCIopen to wait by setting the timeout pause and number of serial retries so as to effectively retry the serial commands for at least four seconds.
Note that some cameras require additional, significant, delay for initialization after power is applied. Some cameras may require 30 to 45 seconds for initialization after power is applied!
XCLIBEXC.CPP
has typo's referring to
XCLIBEX2.CPP
and
XCLIBEX2.RC
instead of
XCLIBEXC.CPP
and
XCLIBEXC.RC
,
respectively.
(04-Mar-2008)
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)
.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; both of which actions
would cause Windows to reset the registry as per the
.inf
file.
(24-Jan-2008)
XCLIBEXC.TXT
provides a SILICON VIDEO® specific example
for use with VB.NET.
(13-Jun-2008)
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 GiByte.
Also, the frame buffer memory must be in the lower 4 MiByte
of PC memory.
(11-Oct-2010)
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)
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)
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)
xclibsc.h
.
The
pxe_videoFormatAsIncluded
and
pxe_videoFormatAsIncludedInit
macros have been added, analogous
to the aforementioned macros.
(08-May-2012)
pixci.sh
and
pixci.rc
files are now provided, allowing the driver to
be installed via
/etc/rc
.
Previously, the driver was loaded when needed via
insmod
,
and (optionally) installing the driver via
/etc/rc
was up to the end-user.
(24-Jul-2014)
epixxcw5.exe
,
epixxcwt.exe
,
epixxcw2.exe
,
and
epixxcw6.exe
installers (which, for recent versions of Windows,
install the drivers via the Device Manager while
XCLIB only unpacked the driver's files).
(25-Aug-2014)
\
.so)
versions of the library, avoiding the need to build it
from the libraries provided.
(06-Jan-2015)
verifier.exe
tests; previous versions of the driver used
older kernel API functions that the verifier found objectionable.
The newer driver requires use of a newer XCLIB;
an older XCLIB will generate a
''... driver not installed ...''
error if used with the newer driver.
The newer XCLIB is backward compatible with
older drivers.
Newer driver is marked V3.8.1 or later, although
some beta versions are marked V3.8.0.
(13-May-2015)
syslog
,
even if
pxd_mesgFault
is not explicitly invoked.
This assists providing technical support
for third party applications, where the
application neglects to invoke
pxd_mesgFault.
(10-Jul-2015)
xclibex5.cpp
)
under Windows.
(14-Dec-2015)
epixxcw2.sys
and
epixxcw6.sys
,
can't be uninstalled.
Note that they can be updated: the updated driver can then be uninstalled.
Also note that if the PIXCI® frame grabber is not present
the driver is not loaded, making uninstall moot.
(28-Jan-2016)
.h
files for Matlab and LabView
have been added to XCLIB.
(10-Jul-2017)
insmod
reports
''No Device Found'').
This should be less confusing to end-users
and conserve system resources.
The XCLIB error message when the driver isn't found
has been simplified, and more appropriate
to end-users.
(06-Mar-2018)
modinfo
on the 64 bit driver(s) shows (in part)
''32 Bit Driver''
and differs from the
the correct string returned by
pxd_infoDriverId.
As Linux 64 bit won't allow installation
of a 32 bit driver, the incorrect
''32 Bit Driver''
declaration can be safely ignored.
(28-Aug-2018)
xclibel8.c
example demonstrates use of the PIXCI® frame grabber
with the Linux Direct Rendering Manager (DRM-KMS)
and/or the Linux FBDEV API.
(06-Mar-2019)
clserEPX.DLL
did not support serial communication for the relatively
new PIXCI® miniH2B and miniH2F frame grabbers.
(Did not affect serial communication via XCLIB, via virtual COM port,
or virtual TTY).
(24-Dec-2019)
xclib_x86_64.a
,
add a
''-no-pie''
option to the
''gcc''
command line to avoid linking errors.
Alterately, compile/link against, for example,
xclib_x86_64_pic.a
(25-Feb-2020)
pixcitty.c
allows creating old node names;
or, create link from desired old name to new name.)
Also,
nodes are now created only for each detected
PIXCI® frame grabber;
rather than creating a fixed number of /dev/ttyPIXCI* nodes.
(12-May-2020)
xclibrls.txt
and
xclibdst.txt
files are instead named
_xclibrls.txt
and
_xclibdst.txt
and won't be found by the desktop shortcuts.
(08-Feb-2021)
XCLIBEXC.CPP
,
demonstrates capture, display, adjustment of
the camera's settings.
(03-Dec-2001).
XCLIBEXC.CPP
example program for use with SV2112 and SV2112C
cameras now also demonstrates the implementation
of automatic gain control (AGC).
(05-Jul-2002)
XCLIBEX4.CPP
,
demonstrates
sequence capture and display with any PIXCI®
frame grabber.
(11-Oct-2002)
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® frame grabbers w/out XCLIB.
(24-Dec-2002)
xclibex5.cpp
,
demonstrates use of non pxd_
functions to operate two
frame grabbers at different resolutions.
(06-Jun-2003)
epixxcw2.inf
,
set
to activate high resolution time stamps. The superfluous ''-'' causes software to believe the board has 4 GiBytes of memory, regardless of the amount of memory actually installed. (27-Jun-2003).PIXCI= ... -WT -0x20
XCLIBEX6.TXT
,
illustrates use of XCLIB with VB.NET.
(16-Jan-2004).
XCLIBEXC.CPP
anda
SILICONVIDEO®
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® frame grabber 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).
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).
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)
DISTRIBUTION KIT:
C/C++ Library for the PIXCI® Frame Grabbers XCLIB & XCLIB-Lite - Version 3.8
The XCLIB or XCLIB-Lite distribution contains one or more of:
1a) XCLIBW95.DLL XCLIB DLL and Import library for Windows 95/98/ME. XCLIBW95.LIB (Compiler independent). XCLIBW95.EXP
1b) XCLIBWNT.DLL XCLIB DLL and Import library for Windows NT V4.0, XCLIBWNT.LIB 2000, XP, Vista, 7, 8, and 10 32-Bit (Compiler independent). XCLIBWNT.EXP
1c) XCLIBW64.DLL XCLIB DLL and Import library for Windows XP, XCLIBW64.LIB Vista, 7, 8, 10, and 11 64-Bit (Compiler independent). XCLIBW64.EXP
1d) XCLYBW95.DLL XCLIB-Lite DLL and Import library for Windows 95/98/ME. XCLYBW95.LIB (Compiler independent). XCLYBW95.EXP
1e) XCLYBWNT.DLL XCLIB-Lite DLL and Import library for Windows NT V4.0, XCLYBWNT.LIB 2000, XP, Vista, 7, 8, and 10 32-Bit (Compiler independent). XCLYBWNT.EXP
1f) XCLYBW64.DLL XCLIB-Lite DLL and Import library for Windows XP, XCLYBW64.LIB Vista, 7, 8, 10, and 11 64-Bit (Compiler independent). XCLYBW64.EXP
1g) XCLBW1DF.LIB XCLIB Library, F model, for Tenberry+DOS, Watcom 32 Bit C/C++ V11.0.
1h) xclib_i386.a XCLIB Library, static link, for Linux, xclib_i386_pic.a Intel i386, and GNU 'C'; compiled with and without PIC option. xclib_i386.so XCLIB Library, shared object, for Linux Intel i386.
1i) xclib_x86_64.a XCLIB Library, static link, for Linux, xclib_x86_64_pic.a Intel x86_64, and GNU 'C'; compiled with and without PIC option. xclib_x86_64.so XCLIB Library, shared object, for Linux Intel x86_64.
1j) xclib_aarch64.a XCLIB Library, static link, for Linux, xclib_aarch64.pic.a nVidia Nano/TX1/TX2/Xavier/XavierNX (ARM A57) 64 bit, and GNU 'C'; compiled with and without PIC option.
xclib_aarch64.so XCLIB Library, shared object, for Linux nVidia Nano/TX1/TX2/Xavier/XavierNX (ARM A57) 64 bit.
1k) xclib_armv7l.a XCLIB Library, static link, for Linux, xclib_armv7l.pic.a nVidia TK1 (ARM A15) 32 bit and Boundary Devices NITROGEN6 (ARM imx6), 32 bit and GNU 'C'; compiled with and without PIC option.
xclib_armv7l.so XCLIB Library, shared object, for Linux nVidia TK1 (ARM A15) and Boundary Devices NITROGEN6 (ARM imx6) 32 bit.
1l) xclyb_i386.a XCLIB-Lite Library, static link, for Linux, xclyb_i386_pic.a Intel i386, and GNU 'C'; compiled with and without PIC option.
xclyb_i386.so XCLIB Library, shared object, for Linux Intel i386.
1m) xclyb_x86_64.a XCLIB-Lite Library, static link, for Linux, xclyb_x86_64_pic.a Intel x86_64, and GNU 'C'; compiled with and without PIC option.
xclyb_x86_64.so XCLIB-Lite Library, shared object, for Linux Intel x86_64.
1n) xclyb_aarch64.a XCLIB-Lite Library, static link, for Linux, xclyb_aarch64.pic.a nVidia Nano/TX1/TX2/Xavier/XavierNX (ARM A57) 64 bit, and GNU 'C'; compiled with and without PIC option.
xclyb_aarch64.so XCLIB-Lite Library, shared object, for Linux nVidia Nano/TX1/TX2/Xavier/XavierNX (ARM A57) 64 bit.
1o) xclyb_armv7l.a XCLIB-Lite Library, static link, for Linux, xclyb_armv7l.pic.a nVidia TK1 (ARM A15) 32 bit and Boundary Devices NITROGEN6 (ARM imx6), 32 bit and GNU 'C'; compiled with and without PIC option.
xclyb_armv7l.so XCLIB-Lite Library, shared object, for Linux nVidia TK1 (ARM A15) and Boundary Devices NITROGEN6 (ARM imx6) 32 bit.
2a) xcliball.h Master C include file for programs using XCLIB.
2b) 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 pixcimod.h pxerrno.h pxlibcam.h
3a) XCLIBEX1.C Source of example program demonstrating capture and video display on S/VGA and other features under Tenberry+DOS and Windows command line.
3b) 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 XCLIBEX4.RC instructions. XCLIBEX5.CPP XCLIBEXP.CPP
3c) XCLIBEXD.CPP Source of example program demonstrating XCLIBEXD.RC capture, video display, and control of the SILICON VIDEO® 10C6, 10M6, 10C-CL, 10M-CL, 20M-CL, 20C-CL, 1281M, 1281C, 1310, 1310C, 1514CL, 1820CL, , 15C5, 1C45, 1M45, 2112, 2112C, 2KS-C, 2K2-M, 5C10, 5M10, 642M, 642C, 643M, 643C, 9C10, 9M001, 9M001C, 9T001C, HAS21, WGA-M, and WGA-C cameras under Windows.
3d) XCLIBEX3.VB Source of example program for Visual Basic, XCLIBEX6.VB VB.NET, and C#.NET. XCLIBEX7.CS Comments in file provide usage instructions. XCLIBEXD.VB
3e) xclibel1.c Source of example programs demonstrating capture, xclibel3.c access to pixel data and other features xclibel5.c under Linux. See comments in file(s) for xclibel8.c compilation instructions.
3f) XCLIBEXG.C Source of example programs demonstrating streaming from frame generator for Windows.
4) XCLIBW95_VB.TXT Declarations for Visual Basic, VB.NET, Matlab, XCLIBW95_VBNET.TXT and LabView for Windows 95/98/ME. XCLIBW95_IMPORT.H XCLIBW95_LABVIEW.H XCLIBWNT_VB.TXT Declarations for Visual Basic, VB.NET, Matlab, LabView, & C# XCLIBWNT_VBNET.TXT for Windows NT/2000/XP/Vista/7/8/10 32-Bit. XCLIBWNT_IMPORT.H XCLIBWNT_LABVIEW.H XCLIBWNT_CSHARP.TXT XCLIBW64_VBNET64.TXT Declarations for VB.NET, Matlab, LabView, & C# XCLIBW64_IMPORT64.H for Windows XP, Vista, 7, 8, 10, 11 64-Bit. XCLIBW64_LABVIEW64.H XCLIBW64_CSHARP64.TXT xclib_i386_import.h Declarations for Matlab & LabView for Linux xclib_i386_labview.h 32 & 64 bit. xclib_x86_64_import.h xclib_x86_64_labview.h
5) *.txt One or more ASCII text files containing distribution information, release notes, manual updates, etc.
6) xclib.htm Complete XCLIB C/C++ Library Reference Manual, in HTML format.
Items 1 through 6 distributed on CD/DVD.
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.
#define CCCC(a,b,c,d) (((uint32)(a)<<24) | ((uint32)(b)<<16) | ((c)<<8) | (d))