v2.1.0 - 2026.07.17

Added:

  • A simpler way to trigger a camera. Every camera operation (capture, save, load, remove, list-images) can now be started with a single command under <camera id>/control/<operation>/execute. The command runs the operation and only returns once it has finished, so there is no need to watch for a "ready" signal and then send a "request". The results appear exactly where they did before, and the outcome is reported on status/code and status/text. The familiar ready/request handshake keeps working, so existing programs do not have to change.

    Connect, disconnect and reset are deliberately not offered this way. They can take several seconds, and a waiting command would usually give up before the camera reports success. Please continue to use the ready/request handshake for those three.
    If the camera is already busy with another operation, the command is rejected with DL_TOO_MANY_OPERATIONS instead of queuing up.

  • A viewable preview image. Switch <camera id>/input/preview/enable on and every successful capture or load also publishes a ready-to-view PNG picture on <camera id>/output/preview/encoded-data. This is useful for checking what the camera actually sees, because the normal image output is raw sensor data that most viewers cannot display. The format is named on <camera id>/output/preview/encoded-format and is currently always PNG.

    The preview can be made smaller with <camera id>/input/preview/scale (a value between 0.0 and 1.0, 1.0 means full size). A smaller preview costs less time per cycle, at the price of less detail. Values outside the allowed range are treated as full size.

    The preview is switched off by default, and while it is off it costs no time at all. Creating a preview also never causes a capture to fail: if it cannot be produced, a warning is written to the log and the previous preview stays in place. You can tell whether a preview belongs to the latest picture by comparing output/package-identifier.

Changed:

  • Reset now proves that the camera really works. Previously, reset only disconnected the camera. Disconnecting always succeeds — even for a camera that has been physically unplugged — so reset could report success for a camera that was in fact dead, and operators reasonably concluded it was ready to use. Reset now disconnects, connects again to prove the camera is reachable, then disconnects once more and hands back a disconnected camera. As before, please call control/connect-camera yourself afterwards. If the camera cannot be reached, reset reports failedToConnectToCamera and names the camera in status/text, and keeps reporting the problem until a reset actually succeeds. Because reset now performs a full connection test, it takes correspondingly longer than before.

Bugfix:

  • A camera that was unplugged and plugged back in can now be recovered without restarting the application. Previously, the driver kept using the old connection to a camera that had left the network, and every attempt to reconnect failed until the application was restarted. Reset now searches for the camera again and retries once, which brings a re-plugged camera back. The search only happens after a connection attempt has already failed, so resetting a healthy camera does not disturb the other cameras.

  • Wrong image size for 12-bit images. For the 12-bit formats (mono12, bayer_rg12, rgb12, bgr12), output/image/data claimed twice as many bytes as the picture really contains, and the extra bytes were unrelated memory contents. 8-bit formats were not affected.

  • Crash on connect in simulation mode.

  • Simulated images from different cameras could be mixed up. Saving the current image and loading a simulation image now use a sub-folder named after the camera, so each camera keeps its own images.