Capturing and Processing Images#

This topic explains how to capture and process images with a Smart blaze camera.

Image acquisition and processing on the Smart blaze camera works the same way as on any x86 Linux host computer. A virtual network connection between the VM and the camera makes this possible, so there is no difference in control or image acquisition whether the software runs on the host or in a VM on the Smart blaze.

For software running inside a VM on the Smart blaze, C++ and Python with pypylon are currently supported. C# bindings for pylon have not yet been tested on the Smart blaze camera.

This consistent behavior is achieved by establishing a virtual network connection between the VM and the camera, so there is no difference in control or image acquisition whether the software runs on the host or in a VM on the Smart blaze.

Documentation and Samples#

Refer to the blaze Programmer's Guide for instructions on configuring blaze cameras and setting up a grab loop. After installing Basler pylon and the pylon Supplementary Package for blaze on your development computer, you can find sample code in the installation directories:

• /opt/pylon/share/pylon/Samples/blaze/cpp/
• /opt/pylon/share/pylon/Samples/blaze/Python/pypylon/

You can download Basler pylon and the Supplementary Package for blaze from the Basler website.

Managing CPU Resources#

The CPU resources available on the Smart blaze camera (4x Cortex-A53 at 1.5 GHz) are shared between the native camera firmware and the customer VM. To ensure stable image acquisition and depth processing, the camera firmware runs with real-time priority while the customer VM runs with normal task priorities.

This design allows software in the VM to fully utilize all four virtual CPU cores without impacting image acquisition or depth calculation. The virtual CPU cores are allocated only the share of physical cores that aren't currently needed for image acquisition and depth processing.

While image acquisition is in progress, the camera firmware uses three physical cores. When the firmware finishes acquiring and processing a frame, there is a window of time during which the VM can utilize the CPU cores almost exclusively. The window ends when the next frame acquisition is triggered. Currently, about 20 ms of this window is spent transferring image data over the virtual network between the firmware and the VM, occupying a significant portion of one core. Future optimizations are expected to make this transfer faster and less resource-intensive.

X11 forwarding introduces additional latency, which can slow down your grab loop and cause missed frames.

When your application can't keep up with processing and starts missing frames, consider reducing the frame rate.

Controlling the Frame Rate#

You can control the frame rate either manually using the 3D Viewer on a host computer (note that settings are not persistent across camera power cycles) or by configuring the relevant camera parameters in your application.

There are several ways to trigger frame acquisition on the camera:

• Hardware trigger: The camera acquires a frame only when it receives a hardware trigger signal.
• Software trigger: The camera acquires a frame only when it receives a software trigger signal from the application.
• Free run: The camera continuously acquires frames using an internal, periodic trigger. Free run is the default trigger mode.

To enable or disable frame rate control, use the AcquisitionFrameRateEnable parameter. When enabled, you can set the AcquisitionFrameRate parameter to specify the desired frame rate in frames per second (fps). In free run mode, the camera automatically adjusts its internal timing to achieve the requested frame rate.

In triggered modes, the frame rate setting defines the maximum frequency allowed for trigger signals. If trigger signals arrive too quickly, those that occur before the minimum interval are ignored.

When using software triggers, you can check the AcquisitionStatus parameter to determine whether the camera is ready to accept the next trigger.

A robust approach is to use software triggers so that acquisition is started only when the application is ready to process the next frame. This allows the application in the VM to use all available CPU resources for processing before requesting the next frame.

How Temperature Affects Accuracy#

The accuracy of depth data depends on maintaining a constant operating temperature. Variations in trigger frequency can cause temperature fluctuations, affecting depth accuracy.

To prevent this, the TriggerThermalDriftStabilization parameter is enabled by default. When it is enabled in software or hardware trigger modes, the camera firmware continuously acquires and processes images in the background at a constant frame rate and delivers the current or next available image upon receiving a trigger.

Since background processing consumes CPU resources, in software trigger mode you should either reduce the AcquisitionFrameRate value or disable the TriggerThermalDriftStabilization parameter.

Using Multiple blaze Cameras in the Same Network#

When working with multiple blaze cameras (Smart blaze or blaze) in the same network, camera enumeration may find not only the Smart blaze camera the application is running on but also other reachable blaze cameras. The Smart blaze camera the application is running on is referred to as the "host camera."

If multiple cameras are present in the network, the host camera can be identified by its serial number. The serial number is passed to the VM via the kernel command line. You can check this by running the following command:

cat /proc/cmdline

出力例：

$ cat /proc/cmdline
root=/dev/vda1 rw console=ttyAMA0 earlycon rootwait ip=192.168.1.127:::255.255.255.0:::off:: blazeSerial=40560199 blazeFirmwareVersion=fw-6.0.0-20260428134100;fw-6.0.0+gf1b86064cda6

C++ Example: Opening the Host Camera by Its Serial Number#

#include <regex>
#include <fstream>
#include <iostream>
#include <sstream>
#include <string>
#include <pylon/PylonIncludes.h>
#include <pylon/BlazeInstantCamera.h>

using namespace Pylon;
int main() {
    std::string serial_number = "40560199";
    std::string cmdline = (std::stringstream() << std::ifstream("/proc/cmdline").rdbuf()).str();
    std::smatch match;
    if (std::regex_search(cmdline, match, std::regex("blazeSerial=(\\d+)")))
        serial_number = match[1];
    PylonInitialize();
    CBlazeInstantCamera camera(CTlFactory::GetInstance().CreateFirstDevice(
        CDeviceInfo().SetDeviceClass(BaslerGenTlBlazeDeviceClass).SetSerialNumber(serial_number.c_str())));
    camera.RegisterConfiguration(new CBlazeDefaultConfiguration, RegistrationMode_ReplaceAll, Cleanup_Delete);
    camera.Open();
    std::cout << "Connected to camera " << camera.GetDeviceInfo().GetFriendlyName() << std::endl;
    std::cout << "Serial Number: " << camera.GetDeviceInfo().GetSerialNumber() << std::endl;
}

Python Example: Opening the Host Camera by Its Serial Number#

rom pypylon import pylon
import re

serial_number = "40560199" # default
with open("/proc/cmdline") as f:
    match = re.search(r'blazeSerial=(\d+)', f.read())
    if match:
        serial_number = match.group(1)
factory = pylon.TlFactory.GetInstance()
device_info = pylon.DeviceInfo()
device_info.SetSerialNumber(serial_number)
camera = pylon.InstantCamera(factory.CreateDevice(device_info))
camera.Open()
print(f"Connected to camera {camera.GetDeviceInfo().GetFriendlyName()}")
print(f"Serial Number: {camera.GetDeviceInfo().GetSerialNumber()}")

Managing the Smart blaze Firmware#

Some use cases may require the Smart blaze camera firmware to be updated from within the VM. This is possible by accessing the software update web/REST interface on port <cameraip>:8080 from within the VM and uploading a suitable *.swu file supplied by Basler.

To verify that a firmware update was successful, compare the current firmware version obtained from the GenICam register DeviceFirmwareVersion with the expected firmware version. For simplicity, the current firmware version is also passed into the VM via the kernel command line with the blazeFirmwareVersion argument:

cat /proc/cmdline

出力例：

$ cat /proc/cmdline
root=/dev/vda1 rw console=ttyAMA0 earlycon rootwait ip=192.168.1.127:::255.255.255.0:::off:: blazeSerial=40560199 blazeFirmwareVersion=fw-6.0.0-20260428134100;fw-6.0.0+gf1b86064cda6