libqoi seems (to me) faster than https://github.com/wx257osn2/qoixx

[awesomebytes]

Hello,

As I played with your project to integrate QOI into ROS (the robotics framework I use almost everyday) I compared it with qoixx and saw that your implementation, on my machine (i7-10875H CPU @ 2.30GHz × 16), on a 640x480 30fps webcam stream, had better performance.

About 20% faster to encode and about 30% faster to decode.

I've proposed a couple of PRs adding your implementation to ROS (ros-perception/image_transport_plugins#103 ros-perception/image_transport_plugins#104). I've credited you as much as I could.

Thanks for sharing your project :)

[ShadowMitia]

Hi!

Glad this project is helping you! And thank you for the mentions!
I hadn't really worked on making it fast, but if it works out better for you, great!

If you have any comments or feedback about the code, feel free to mention it, I can even try and push one or two things before you close your PRs if needed.

And thank you for your message, you've made my day 😀

[wx257osn2]

@awesomebytes That sounds interesting. Do you still have code of ros-perception/image_transport_plugins using qoixx ? I think that there are still some chance to improve performance.

[awesomebytes]

@wx257osn2 The pull requests are linked in my post, so yes, the code is still there. No one has shown interest yet, but I'd happily welcome performance improvements.

[wx257osn2]

@awesomebytes The codes on PR uses libqoi , not qoixx . You said

I compared it with qoixx

above, so you had implemented image_transport_plugins with qoixx at least once. If you still have the code, I want to see that. Do you have that?

[awesomebytes]

No, I don't have it anymore. Sorry, I did not understand what you meant in the previous comment.

In order to test yourself qoixx performance I think you'd need to change just:

https://github.com/awesomebytes/image_transport_plugins/blob/noetic-devel_add_qoi_compression_support/compressed_image_transport/src/compressed_publisher.cpp#L260-L263

and

https://github.com/awesomebytes/image_transport_plugins/blob/noetic-devel_add_qoi_compression_support/compressed_image_transport/src/compressed_subscriber.cpp#L107

Which, if you don't use ROS I do feel it's a rather long task.

[wx257osn2]

@awesomebytes

No, I don't have it anymore.

OK.

if you don't use ROS I do feel it's a rather long task.

I'm not ROS developer, so it seems that it is not so easy to test, but I will try it.

I need to ask a question for you, what do you use the compiler to build it?

[wx257osn2]

@awesomebytes I implemented qoixx version here.
I confirmed that the branch can be built with C++17-compatible compiler, but I have no environment for execution ROS.
Would you check the performance of this branch?

[wx257osn2]

@awesomebytes Would you check that? I want to know the performance on your environment and usecase, but I have neither the application using image_transport_plugins nor the environment as same as yours.

[awesomebytes]

@wx257osn2 I'll find a moment in the following days to re-create the environment and test (and share this environment with you).

Thanks for your efforts and interest!

[awesomebytes]

Hey @wx257osn2 I finally found some time to dedicate to this. Good news: your qoixx is faster.

I made an environment ready for testing here: https://github.com/awesomebytes/image_transport_qoi_playground
with a README with my results:

Compression Algorithm	Compression CPU %	Decompression CPU %	BW	HZ
JPEG Quality 80	21	29-31	690KB/s	30
PNG Level 1	59-61	24	5.6MB/s	30
PNG Level 2	59-62	24	5.4MB/s	30
QOI qoixx	27-30	32-35	6.1MB/s	30
QOI	40-50	40-50	6.1MB/s	30

[awesomebytes]

I need to update my Pull Requests with your implementation. That said, my previous results were probably wrong because I did not compile in Release mode (not enough optimizations enabled!).

[wx257osn2]

@awesomebytes Thanks for your measurement result.
Actually that is not surprising to me; since I have claimed qoixx is one of the fastest.
Anyway, it is good that it was incorrect argue that my implementation is slower.

I have three requests for you:

• When you will talk about the performance of several libraries hereafter, please keep the code used to measure due to ensure reproducibility.
• Please consider whether your own code has any problems on performance before mentioning the performance of the libraries written by someone else -- especially, when the library claims to be fast.
• At this point, it doesn't seem appropriate to continue the discussion here IMHO. It should be done at new issue on your repository.

@ShadowMitia Sorry for sending you many notifications.

[awesomebytes]

@wx257osn2 I'm sorry if you got offended, I did my best to perform my experiment at the time, which is a hobby project done in my spare time. Thanks for helping on using your version of the library, it is very appreciated!

I'll update my pull request soon, when I find some free time again.