Camera API Technical Report:
Introduction

Introduction

This is a discussion of a number of issues I am thinking about with respect to a camera library. I don't have a definite solution in mind and want to provoke some discussion. The aim is to produce a camera (programming) interface library that will suit all users, which we can adopt in the hope that we get some commonality of usage and thereby reduce the work entailed by new cameras/ driver software and application programs that may need converting. Comments requested on all of the below, especially on the general idea as well as specific points.

I want to convert my xgrab program to xmgrab in order to make it conform to Motif style of interface and to rewrite it so as to remove all the bugs (ha ha) and to make the source more coherent . I want it to use the new cameras and the old in a common way, and so we need a camera library to take away the specific device dependencies. The existing camera library does not really suit my requirements one of which is the the code which sets up the user interface should be able to request information to be able to set up sliders, choice menus . Furthermore there should be a mechanism for querying and testing parameter values that have constraints. What I really want is a model of what comprises a camera to which I can build the interface, with provision of course for extensions. The camera library should be regarded as ``lower'' than woolz and independent of both the woolz library and structure definitions. Anything that requires woolz objects should be in the woolz library or extensions to it. New cameras should be installed in the library in object-oriented fashion there should be no need to modify existing code except perhaps for a single ``camera-list'' which registers the new camera. The camera library is mostly a set of routines to dereference the appropriate functions. The library is then recompiled. An alternative is to go down the Xt route in which application code needs to include a .h file for each camera type but then access is via generic routines related to the camera model. With this option the camera-library does not need recompilation for a new camera type but the application code does.

To avoid the ad hoc type development of the camera library and to achieve the above depends on being able to define a camera ``model''. This is clearly impossible in principle but with care we may be able to define a model that can be extended as required and covers everything we can think of now. By having a camera model we can also provide a ``software'' camera that can be used for testing code. It is clearly impossible to provide for every quirk and detail of possible cameras and device drivers, especially boards that may include some image processing, however we can approach this problem in the same fashion as other libraries (Xt). That is to use the library for the usage we can envisage that covers the camera model we want and make sure that it is possible to go directly to the device driver for other facilities. Examples from the HGU board are the use of blocking and the shutter-closed signal. It should always be possible to circumvent the library therefore attributes available to the user should include the file-descriptor and/or the memory mapped pointer to a framebuffer.