Hello, K.N,
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(orRectifyImages). - 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.
See, for example, discussion here Calculations for the first point cloud takes long time.
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.
Best wishes,
Gisha