Huge image input delay when working with low frame rates

[MrFresh1]

Setting frame_rate: 1.0 I get a huge delay of about 36 seconds from when the actual image is taken and received on ros. Comparing the timestamp of the image message and ros time of the moment the image message is published I get a difference of about 1 second which I can work with. The delay of 36 seconds I acquired by comparing the image content and the image message timestamp so the total delay is at about 37 seconds.
Using the same camera settings with PylonViewerApp does not result is a huge delay. So the fault must be with the ros driver.

[FranekStark]

Do you receive the Image on the machine, wehre it ha sbeen captured?
Otherwise it's importand to know that ROS doesn't compress images by default

[MrFresh1]

I do receive the image on the same machine I capture them with.
Using rosrun image_view I always look at image_raw, how does compression come into this?

[MrFresh1]

Edit: Nope it's still there.
Update:
I was able to come up with a workaround. Using the following two lines

cam_->AcquisitionFrameRateEnable.SetValue(true);
cam_->AcquisitionFrameRate.SetValue(1.0); 

in function applyCamSpecificStartupSettings which can be found at the following line:
https://github.com/basler/pylon-ros-camera/blob/master/pylon_camera/include/pylon_camera/internal/impl/pylon_camera_usb.hpp#L86
No sign of any huge delays anymore. Previously the camera would run in free running mode with the highest frame rate possible in my case 40 fps. This way it will still run in free running mode but at 1 fps.

Though I don't quite understand as to where the images were being saved. The 36 seconds old images I received must have been buffered somewhere?

[FranekStark]

Hm, I used this node myself and do not observe such strong delays.
What kind of hardware are you using?
For compressed images, have a look. We are using this node with a Basler-Dart on a Raspi4. Using the compressed images, helped us to transfer the pictures via network and write them to a bag file.

However, I can confirm that this Node is unfortunately very buggy.

[MrFresh1]

Today I started working on that issue again and I found the troublemaker. When I start my camera node with a launch file I also execute a bash script which runs a few services like:

set_trigger_mode false

The latter was originally placed to make sure the camera is running in free running mode. According to Basler documentation the trigger mode is off by default for all trigger types. Not executing that line results in the huge delay I was seeing before to be gone.

Further tests:

1. Specifying a trigger type before setting the trigger mode to off like I should have done according to Basler documentation also results in the delay
2. Turning the trigger mode on after I turned it off also results in the delay (before both I didn't specify a trigger type)
3. Never turning the trigger mode off but instead turning it on has no effect. There is no delay before and after calling the service

Conclusion:
I will not turn the trigger mode off as I don't really need it and its already off after powering the camera. Thanks for the feedback.