Drop in the frame rate of the GigE Blackfly S using BGR image format

[iag0g0mes]

We are experiencing a significant drop in frame rate when changing the image format of our GigE Blackfly S cameras. Specifically:

Problem:

• The cameras are connected to a network switch and are publishing images at 35Hz using the BayerRG format.
• When changing the configuration to publish images in BGR format, the frame rate drops to less than 10Hz, even with only one camera connected.

Parameters:

We identified two parameters that might be influencing the network performance:

• device_link_throughput_limit: 380000000
• gev_scps_packet_size: 9000

However, we encountered the following errors and issues:

• The driver indicates that the device_link_throughput_limit should be less than 125000000.
• The driver does not work with gev_scps_packet_size set to 9000. It only works when gev_scps_packet_size is set to 1400.
• In SpinView, the gev_scps_packet_size is displayed as 1400.

Hardware Setup:

• A computer with four network interfaces.
• Several GigE Blackfly S cameras connected through a network switch.
• All network interface of the computer connected to the switch. Each belong to a different VLAN.
• One network interface belong to the same VLAN of the cameras.

Environment:

• OS: Ubuntu 22.04
• ROS: ROS 2 Humble
• Driver: spinnaker_camera_driver (Humble branch)

Question:

How should we properly configure the device_link_throughput_limit and gev_scps_packet_size parameters? Are these parameters related to the drop in the frame rate of the cameras?

We are looking for guidance on how to optimize these settings to maintain a high frame rate when using the BGR image format.

Thank you for your assistance.

[berndpfrommer]

OK, so first about the device_link_throughput_limit: I don't really understand either how to set that. I played around with it a bit but couldn't make sense of what I was getting. It didn't seem to matter too much, unless you are hard at the limit of available bandwidth. About the drop in frame rate, I have the following theory: the Bayer image is 1/3 the size of the BGR image. This is due to the fact that the de-bayering bloats the image to 3 times its original size (the Bayer image really is a monochrome image). So when the camera does the de-bayer, you are wasting bandwidth. Your frame rate should drop to about 1/3 (if you are maxxed out on bandwidth). I believe you should debayer on the host. I think the ROS image viewers do that for you transparently. Alternatively, write a composable node and debayer using opencv.

[berndpfrommer]

Oh, and I definitely had the driver working with packet size 9000. Using jumbo frames is an absolute must. Check your network card settings. You need to bump the MTU to 9000.

[iag0g0mes]

Hello,

We agree with your point about the BayerRG format. It seems better to continue using it and perform the debayering on the host.

Regarding the gev_scps_packet_size, we adjusted the network interface configuration on the computer and the switch to 9000 MTU. Are there any other configurations needed? When we run the driver with this setting, it gets blocked and doesn't publish images. Similarly, when we set SpinView to 9000, the camera stops sending images.

We will continue investigating this parameter.

Thank you very much for your help.

[iag0g0mes]

Hello,

We got it working by changing the maximum size of jumbo frames on the switch from 9000 to 9216 (the maximum allowed), and it worked.

It also seems to have resolved the issue with the BGR image format. The cameras are not publishing at 35Hz yet, but they are close (approximately 25Hz). We will assess this further and may decide to keep using the BayerRG format.

Thank you for your assistance.

[berndpfrommer]

You are welcome. Glad you got it sorted. Side note: If you plan on storing the images in a rosbag, bayer is also more efficient. You can do the math to check if you are running optimally. Image width height 8 bits * fps should be close to 1 Gigabit for Bayer image.