Adding QOI compression support for ROS1 #103
Conversation
The Quite OK Image format (https://qoiformat.org/) is a good substitute of PNG for lossless compression. This commit adds it as a compressed image transport thanks to Dimitri's Belopopsky (@ShadowMitia) MIT Licensed library (https://github.com/ShadowMitia/libqoi) implementing Dominic Szablewski's QOI algorithm (which is CC0 licensed, public domain).
|
This would probably have better impact as a standalone package that you'd release yourself. Getting anything in this library is most probably a year(s)-long run... In a standalone package, you could first prove practical usability of this compression, get feedback from users, and after that, its way to this "master" package could be easier. Feel free to post a link to the standalone package to this issue and mention it on discourse.ros.org. |
|
This looks like an amazing addition. Would you help me set up? I was trying to use your version using qoi but I am having some issues regarding high resolution images. I have 8k images which are bayered and i would like to compress them as is. But qoi only allows 3 to 4 channels. Is this a qoi limitation? |
The Quite OK Image format (https://qoiformat.org/) is a good substitute of PNG for lossless compression.
As per QOI's website:
This commit adds it as a compressed image transport thanks to Dimitri Belopopsky's (@ShadowMitia) MIT Licensed
library (https://github.com/ShadowMitia/libqoi) implementing Dominic Szablewski's QOI algorithm (which is
CC0 licensed, public domain).
To give context, I implemented this to practice C++ and to provide an alternative to PNG compression for when we'd like lossless compression or to have an alpha channel without framerate drop. Currently using PNG drops a 640x480 webcam stream 30fps to 3fps. With QOI it stays at 30fps.
Taking as baseline raw image publishing with video_stream_opencv, and subscribing with rqt_image_view, on my i7-10875H CPU @ 2.30GHz × 16, QOI compression adds 28% CPU usage and QOI decompression adds 13% CPU usage. Feels reasonable to me, specially compared to PNG going over 100% CPU usage and dropping most of the frames.
I would gladly appreciate help on how to eliminate the (what I think is) unnecessary copy of the image in the publisher and the subscriber.