VCLinux Library Documentation  3.11.2



Compiler setup and camera access is covered by a separate handbook.
Image processing functions are documented at their own library documentation.

A quick summary of the basic environment is given by the following modules:

  1. Main Data Types
  2. briefcodeforimagerecording
  3. Service Applications

Version changes are listed at the Changelog.

This documentation can also be found at the debian package named libvclinux-doc: the version of that package defines the documented library version installed at /usr/share/doc/libvclinux-doc/.

Common Design Principles

Hardware Access

  • The connection between the hardware pins/sockets and GPIO numbers can be found at the camera hardware documentation.
  • Configuration of the purpose of persistent hardware pin/socket assignment is done based on their GPIO by the program vcio.
  • This libvclinux library provides access to the camera hardware (e.g. for image acquisition).

API Nomenclature and Shape

  • The only purpose of a VC⋯Init structure is to initialize the related VC⋯Cfg structure.
  • A VC⋯Cfg structure is used to carry modifyable settings and only in rare cases acquired data.
  • Contained at a VC⋯Cfg structure may be a VC⋯Desc structure, which provides useful information, but its contents must not be modified.
  • Opposed to the mainly constant information at the VC⋯Desc structures, volatile information, like the capture id of a recorded image, can be found as a VC⋯Volatile substructure.
  • Additional settings and results for special cameras, like the VC Nano3d Z, are accessible by a VC⋯Custom and VC⋯CustomInit structure.
  • Due to the hybrid nature of the capture image's structure containing configuration but also result data, the capture image is directly accessed and configured at the VCSenCfg structure.
  • Other processing results are usually provided by a VC⋯Result structure, e.g. at such type of structure the custom VC Nano3d Z structure provides laser positions.
  • Data or functions named external used for further processing of result data, like the transformation of pixel to world coordinates of a VC Nano3d Z laser line.
  • For each enum a string can be formed by prepending a str_ in front of the enum name. Enum values should begin with the enum name without the VC prefix in upper case.
  • Each structure should have a nullifier named by prepending a NULL_ in front of the structure name.
  • Some structures provide default values named by postpending a _Default after the structure name, whilst some functions allow to pass a NULL instead of an initialisation structure pointer, and it is most likely, that the default values are applied for the NULLed initialisation structures.

API Process Flow

  • Common is the partition in four parts:
    1. Setup phase: Declared variables (including structures) have random values at the programming language C. So it is important to initialize the declarations with defined values, especially at VC⋯Init structures. To do so, we provide defaulter (postpend a _Default after the structure name) for VC⋯Init structures and nullifier (prepending a NULL_ in front of the structure name) for other kind. The default values at a VC⋯Init structure may be changed and fit to your needs then during this phase.
    2. Initialisation phase: By calling the appropriate ⋯_init() function, settings of the VC⋯Init structure will be used to make the provided VC⋯Cfg structure ready for use. The VC⋯Init structure should only be needed for initialisation.
    3. Processing phase: Settings at the VC⋯Cfg structure can be altered and configure function behaviour, for example, the image acquisition. This phase is where the program stays most of its time.
    4. Deinitialisation phase: When the initialised structures are not needed anymore, the appropriate ⋯_deinit() function will free memory and deinitialize properly.
Process Flow Principle