Compressed Depth Image Error

[dave992]

I have been using the Zivid camera in my project but ran into the following error when I use rosbag record -a to record all topic messages:

[/project_node] [ INFO] [1591269835.914690961]: Zivid capture service called
[/zivid_camera/zivid_camera] [ INFO] [1591269835.915845060]: Capturing with 5 frames
[/zivid_camera/zivid_camera] [ERROR] [1591269839.085602044]: Compressed Depth Image Transport - Compression requires single-channel 32bit-floating point or 16bit raw depth images (input format is: rgb8).
[/zivid_camera/zivid_camera] [ERROR] [1591269843.992570263]: Compressed Image Transport - JPEG compression requires 8/16-bit color format (input format is: 32FC1)
[/zivid_camera/zivid_camera] [ERROR] [1591269843.996938457]: cv_bridge exception: '[32FC1] is not a color format. but [bgr8] is. The conversion does not make sense'

The error follows after calling the capture service of the Zivid camera node. The error is not present when I do not run rosbag (and therefore am not subscribed to all available Zivid topics).

When I am not recording, my project only subscribes to the /zivid_camera/points and /zivid_camera/depth/image_raw topics.

[apartridge]

@dave992 I assume you are setting up the compressed_depth_image_transport node, since this is not something that the Zivid driver sets up. It complains about "input format is: rgb8", which is the format of the color image published as a part of 3d capture. The messages from the Zivid driver are only generated when there are active subscribers to them, which explain that they are published when rosbag record -a is running.

I am not familiar with "Compressed Depth Image Transport" but it looks that it tried to compress the color image from the Zivid driver, which does not work because of wrong format. Additionally "Compressed Image Transport" complains about wrong format as well ("input format is: 32FC1", which is actually the depth image format). Maybe color and depth images have been mixed up?

Edit: It could be that this happens via image_transport::CameraPublisher which we do use. Will need to look more into it.

[apartridge]

Hi @dave992 Can you explain a bit more about setup and usage of image_transport compression? Are you sure that the in/out topics are correctly connected? From the error above it looks like depth and color images topics have been swapped somewhere.

[dave992]

I am not creating a compressed_dept_image_transport node myself. If this is created, then it is by use of the rosbag record -a command. If my understanding of rosbag is correct, it looks up all available topics, subscribes to them, and when receiving a message from a topic it writes them 'as is' to a file. It may actually be a rosbag issue causing the error, but it made sense to first post an issue here to figure out what is going wrong exactly.

For my use case, I am not really interested in the compressed dept images which is why I do not subscribe to it in my application. In this case, I used rosbag to save all ROS messages (including the unused ones), allowing me to simulate the hardware setup. This allows me to also inspect currently unused messages at a later time if required.

The resulting bag file was still useable, although I did not inspect the compressed_dept_image messages as these were not needed up until now.

To reproduce this error:

1. Launch zivid_camera_node
2. Enable at least one frame, i.e. by calling the suggested settings service
3. Run rosbag using rosbag record -a
4. Trigger a capture, i.e. run rosservice call /zivid_camera/capture

Note: This is from memory, I will have to check it later today when I am at work.

Edit: @apartridge I've checked the reproduction steps, these indeed result in the error shown in my original post. You might need to enable at least one frame before you are able to trigger a capture.

[apartridge]

Thanks @dave992. Myself and an colleague have tested your steps now and we don't see the error here. We are testing on ros-noetic currently, so it could be a difference in distribution. Are you using kinetic or melodic?

We found this similar issue IntelRealSense/realsense-ros#315. According to this comment it may have been fixed in melodic, so it could be worth checking that. If you are using melodic, can you send us the output from dpkg -l | grep "ros-" so that we can try to reproduce with the same setup?

[runenordmo]

An option is also exlude the topics related to compressed_depth_image_transport when recording using
rosbag record -a -x "(.*)/compressedDepth | (.*)/theora | (.*)/theora/(.*)". It should also be possible to disable the plugins compressed-depth-image-transport plugins from a launch file.

[apartridge]

@dave992, can you confiirm with version of ROS you are using? See #21 (comment), which indicates this issue might be fixed in Melodic.