We are using custom software with an external trigger to image workpieces arriving at 8-second intervals.
Basically, imaging works without problems,
but the first imaging process after connecting the camera takes nearly 3 seconds.
Subsequent imaging processes take about 1.7 seconds.
The above times represent the time taken for the following processes:
Capture
Pointmap acquisition
Feature point extraction
Saving result data
Saving parameters
Processes 1, 2, and 5 are performed via nxlib.
We have collected logs.
Could you please check if there is a difference in processing time via nxlib
between the first image and subsequent images?
We have attached two logs collected under the following conditions:
Log for the first and second images
(tmp_NxTreeEdit20260615(first,second).enslog)
Log for the nth and (n+1)th images in subsequent imaging cycles
(tmp_NxTreeEdit20260615(n,n+1).enslog)
Thank you for your detailed post, but unfortunately the logs you attached contain no actual data.
Firstly, the first long imaging cycle (~3s) is a known and expected behavior. The delay occurs because several internal resources are initialized lazily upon the first execution of the capture and processing commands:
Rectification Lookup Table: The SDK calculates an internal lookup table to speed up image rectification. This is computed on the very first execution of ComputeDisparityMap (or RectifyImages).
Algorithm Memory Buffers: The stereo matching algorithm (PatchMatch) allocates significant memory buffers for descriptors and intermediate calculations. For a high-resolution camera like the C57, this can involve hundreds of megabytes of RAM or VRAM.
CUDA/OpenGL Context Initialization: If GPU acceleration is enabled, the first call triggers the creation of the CUDA context and the compilation/caching of necessary kernels. Similarly, if you are rendering the pointmap, the OpenGL context is initialized on the first run.
A common practice in external-triggered industrial workflows is to perform a “warm-up” capture immediately after connecting to the camera and initializing the SDK. You can trigger and compute the first frame, discard the result, and only then begin your actual 8-second production cycle. This ensures all heavy allocations happen before your first real workpiece arrives.
Secondly, a steady-state processing time of 1.7s for a C57 is somewhat a bit longer than expected. You can look through our guide Optimize Settings for Performance/Quality, but I would also happy to see real profiling data to make some recommendations. It would also helpful if you would share your PC/GPU specifications and your ComputeDisparityMap parameters, and we can look into performance tuning options.
Q1. When using an external trigger, is there a way to activate a warm-up trigger without physically turning on the sensor?
Since the sensor is installed in a high location, it is difficult to physically trigger it by activating the sensor before the workpiece arrives .
Also, I do not want to resort to simply sacrificing the first workpiece.)
Q2.When starting my custom software, I set the trigger mode to software mode and perform a “warm-up capture.”
Then, I change the trigger mode to the external trigger “FallingEdge.”
Is this method effective?
(Would this method allow for imaging from the first workpiece with a short processing time?)
Regarding the phrase “after connecting to the camera and initializing the SDK” mentioned above, could you please explain the conditions under which a “warm-up capture” is required?
For example, is a “warm-up capture” necessary if the camera is disconnected and then reconnected?
Or, once the camera is powered on and connected, is a “warm-up capture” unnecessary for subsequent operations?
I apologize for the additional request, but could you please let me know?
Regarding the specific processing for the warm-up capture,
I am considering the following procedure:. 1. Open the color camera after opening the 3D camera.. 2. Configure the JSON files for the 3D camera and color camera.. (using the same ones used during actual operation). 3. Change the trigger mode to software trigger (3D camera only?).
4. Issue a capture command to the 3D camera.
5. Issue a capture command to the color camera.
However,
after acquiring the data in steps 4 and 5,
what is the minimum set of commands required
to satisfy the requirements for the warm-up capture?
For reference, the following commands are used during normal operation. “Open”
“GetModelInfo”
“Close”
“Trigger”
“Retrieve”
“ComputeDisparityMap”
“SaveImage”
“ComputePointMap”
“RenderPointMap”
“RectifyImages”
I am planning to handle the specific Warm-Up capture processing from Step 3 onwards as follows.
Would this be acceptable?
//3. Change the trigger mode to software trigger.
NxLibItem camera = getAvailableCamera({valStereo, valStructuredLight});
NxLibItem triggerNode = camera.cameraNode()[itmParameters][itmCapture][itmTriggerMode];
setNxLibItemValue(camera[itmParameters][itmCapture][itmTriggerMode], valSoftware);
//4. Issue a capture command to all camera.
NxLibCommand(cmdCapture).execute(); // Without parameters, most commands just operate on all open cameras
//5.Executing a command that requires a warm-up.
NxLibCommand(cmdComputeDisparityMap).execute();
if (camera[itmType] != valStructuredLight) {
NxLibCommand(cmdComputePointMap).execute();
// Compute map: uses per default all open cameras
NxLibCommand compRenderPointMap(cmdRenderPointMap).execute();
}
//6. Return the trigger mode to its original state.
setNxLibItemValue(camera[itmParameters][itmCapture][itmTriggerMode], triggerNode);
your code looks good, but there is a thing missing.
After step 6, execute a Trigger command, so the camera is armed and waiting for the first hardware trigger edge. Otherwise, the first real trigger can be missed.