Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Low FPS in rgb8 mode #21

Closed
geometrikal opened this issue Feb 5, 2020 · 8 comments
Closed

Low FPS in rgb8 mode #21

geometrikal opened this issue Feb 5, 2020 · 8 comments

Comments

@geometrikal
Copy link

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
Copy link

claudiofantacci commented Mar 4, 2020

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
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link

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
Copy link

m-binev commented Apr 16, 2020

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
Copy link

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants