Low FPS in rgb8 mode

[geometrikal]

Am connecting an ac2440-35uc (2448 x 2048 colour, 35 fps) to a Jetson Nano.

I can get 35 fps in pylon viewer with colour images, 26 fps when subscribed to image_raw topic with greyscale images (mono8) but only 2.5 fps with RGB (rgb8).

Why would this be? Something to do with the software triggering?

[claudiofantacci]

May be related to #28 and/or #29.

This may be also be related to magazino/pylon_camera#25 even though they may refer to a different implementation of the ROS driver.

[fhwedel-hoe]

I saw a number of discussions here and in the ROS boards. In need of a solution available on short term, I threw together a ROS node for grabbing from Basler's USB cameras based on their "Instant USB Camera" sample code: https://github.com/fhwedel-hoe/pylon_usb-instant-camera Maybe someone finds this useful until the official node is enhanced in this regard.

[pablo-quilez]

Hello all

the FPS issue is something we want to address in the following weeks. We consider that is one of the most important topics to solve. I am considering to merge somehow all those related issues into one if it is ok for you.

Thanks!

[pablo-quilez]

Some additional information, when driver uses software triggering, only 50% of the maximal framerate can be reached because the camera is operated in non-overlap mode.

To increase the framerate, instead of using rgb8 you may use bayer8 pixel format because this will reduce the bandwidth.

[claudiofantacci]

the FPS issue is something we want to address in the following weeks. We consider that is one of the most important topics to solve. I am considering to merge somehow all those related issues into one if it is ok for you.

This is great news! Looking forward to it and let us know!

Some additional information, when driver uses software triggering, only 50% of the maximal framerate can be reached because the camera is operated in non-overlap mode.

Can you please provide a bit more details about this?

[m-binev]

Hi,

let me give you some hints on the possible frame rate limitation factors:

Some additional information, when driver uses software triggering, only 50% of the maximal framerate can be reached because the camera is operated in non-overlap mode.

First, you can generally read more about that here:
https://docs.baslerweb.com/resulting-frame-rate.html#factors-limiting-the-frame-rate

Otherwise, you should consider the following main things:

1. the frame rate may be limitted by the bandwidth first. In case of USB3.0, it is at maximum 380MB/s. This depends strongly on your xHCI USB 3.0 host controller though. Some xHCI may support 300MB only or even less. Unfortunately, you first get to know that when you test.
2. ROI and Pixel Format: in case of RGB8 you transfer 3Bytes per pixel, i.e. you need 3 times more bandwidth to transfer the image.
   In case of Bayer8: 1Byte per pixel.
   For your camera this means that for 380MB bandwidth (best case), you reach 35fps with Bayer, and 25fps with RGB8.
3. Exposure Time: the longer the exposure time, the lower the FPS
4. Triggering: in theory you usually reach the maximum frame rate either in the so-called "Free run" mode (no trigger), or in External trigger mode. In both cases the goal is to trigger the new image acquisition while the camera is reading out the sensor data from the previous acquisition. We speak about "overlapping exposure or triggering".
   In case you do single shots (software trigger is also considered here), you cannot reach overlapping exposure, because you have a kind of sequential acquisition, e.g. send a software trigger - expose the sensor - readout the sensor - transfer image - receive image - and then trigger the next one.
   This is simply too slow and prevents from reaching the maximum frame rate.

According to some "private" measurements, you can reach about 50% of the mixumum FPS while using software triggering.

Hope that helps.

[claudiofantacci]

Thanks for the long explanation and for sharing the link.
I was mainly curious about the trigger mode as I felt was not as straightforward to understand why you may have a 50% decrease in FPS, even under optimal settings. So again, thanks for explaining that, especially for the stressing on the overlapping exposure/triggering.

[pablo-quilez]

Hello,

we have added in devel (#56) the possibility to change the grabbing strategy as well as the grabbing timeout. I will close the issue as there are other related.

Cheers