v2.3.0 - not yet released

Added:

  • Image stream (experimental). A camera can now stream its images instead of taking one image per capture request. <camera name>/control/publish/execute applies the inputs control/publish/input/enable and keep-latest-output. While the stream runs, the Cam Driver publishes every image the camera delivers on control/publish/output/stream/frame for a subscriber, together with its size, its pixel format and its lineage: the camera, the stream’s start and the image’s number in it. The Cam Driver does not trigger the camera by itself: an image comes on a hardware trigger, on control/trigger/execute, or continuously while the camera’s trigger mode is off. Triggered at a fixed rate, the camera we tested delivered every image at up to 66 images per second, against about 34 with capture/execute, with its TriggerOverlap set to PreviousFrame in a feature file. keep-latest-output also puts each image on output/image and counts it on output/package-identifier, at the cost of a copy per image. Counters under control/publish/output/stream/statistics show images and losses.

    Every image is delivered on either Data Layer. setting/settings-hash identifies the settings the images are taken with, and each frame carries it. Each frame also carries the module’s tag - the camera name, or the one control/publish/input/tag gives, which is saved in the module configuration file as stream.tag - and the applications that process the images keep it in their results' lineage. The hash says that the settings changed, not what changed; and that it follows a camera feature change has not yet been verified with a real camera.

    While the stream runs, capture is not available: capture/ready is false, capture/execute answers DL_INVALID_OPERATION_MODE, and a capture request ends with status -3 without latching a fault. Stopping the stream connects the camera again, so capture/ready returns after about two seconds on the camera we tested. See Streaming Images (Experimental).

  • Software trigger. <camera name>/control/trigger/execute sends the camera a software trigger while it is in software trigger mode - its trigger mode on and its trigger source software, read in the camera’s own spelling - and does nothing in any other mode. The command is the camera’s own, TriggerSoftware or SoftwareTrigger. A camera in that mode without either, or refusing it, reports the new status -10012 (softwareTriggerFailed). While the image stream runs, a camera without a software trigger mode - a simulated camera, or a plugin camera without TriggerSoftware - is fired by its own trigger instead, one image per call. See Software Trigger.

  • Feature mappings. A camera that names its software trigger command, its trigger mode or source, or their values differently gets its own names in the application settings file: an entry under featureMappings, named by the camera’s featureMappingId. The schema lists the keys. A mapped name the camera does not have is logged as a warning, and the built-in names are used. See Software Trigger.

  • An example of the settings, on a PC. -g, --generate-settings [folder] writes the application settings file, an example module file and their schemas into a folder (the current one by default), names the folder the Cam Driver reads its settings from, and ends. Existing files are never overwritten. See Creating New Camera Settings Files.

  • Settings on the Data Layer. hdvisionsystems/lumiscan-cam-driver/system/settings shows the settings the application was started with: the application’s settings file, each module file inlined in its modules list, passwords as ***. Writing it changes the files. The application checks the change as at start, saves it (the previous file as .bak), and then refuses all work until it is restarted: restart-required, status -5. hdvisionsystems/lumiscan-cam-driver/system/control/restart/execute restarts it. See Settings on the Data Layer.

Bugfix:

  • The Cam Driver started on a ctrlX CORE again. Since it moved to the new command line, it refused the -p 8080 its snap passes and ended at once. It accepts and ignores -p now, and the snap no longer passes it.

  • A program that keeps calling a refused execute no longer floods the log. Each refusal was written as its own line, so a program retrying capture/execute while the camera was busy wrote about 11 MB of log per minute. For each method and result, the first refusal is logged, then at most one line every ten seconds, which says how many were not logged one by one.