Comments: Comparing Performance: stb_image vs libjpeg(-turbo), libpng and lodepng

[DanielGibson]

Comments for https://blog.gibson.sh/2015/03/23/comparing-performance-stb_image-vs-libjpeg-turbo-libpng-and-lodepng/

[Theldus]

Hello Daniel, first I would like to say that I really liked the comparison present on the site since I am deciding which library to
use, it was quite interesting to read.

However, my results were different from yours with respect to JPEG (more specifically libjpeg-turbo vs stb_image).

I did tests in 2 scenarios, both with consecutive readings of 17 images of 4608x2592 with stb_image latest version (v2.26)
and -O3:

1. i7 2600, libjpeg-turbo v1.5.0, GCC v5.3, Slackware 14.2
   libjpeg-turbo: 1525ms
   stb-image: 2279ms, or 33% slower

2. i5 7300HQ, libjpeg-turbo v2.0.5, GCC v9.3.0, Slackware 14.2-current
   libjpeg-turbo: 1317ms
   stb-image: 2130ms, or 38% slower

Interesting isn't it? I don't know exactly what has changed but it seems that the difference between libjpeg-turbo and stb_image has become bigger, which may not be as interesting for those who need the best possible performance.

[DanielGibson]

Hi Theldus,

yes, it seems like the gap has become wider - I guess that libjpeg-turbo has gotten additional optimization in the last years - keep in mind that my test was 6 years ago, and the libjpeg-turbo release I was using (1.3.0) is already 8 years old.
So it's likely that they improved performance in general and probably added support for newer SSE versions etc.
I think stb_image didn't get many performance optimizations in the meantime, and still "only" has optimized code for SSE2, not any newer SSE versions (or AVX).

Another factor in my tests was the image size - for the big (4000x3000px) image stb_image took 23% longer than libjpeg-turbo, for the small (512x512px) image it was much closer (3.7%-16%).
Maybe the image itself also makes a difference (apart from its size).

It's true that stb_image is not (and never was) the best solution if you need the best possible performance, but often it's good enough. I personally avoid libjpeg if possible at all, because its API is less friendly and its different incompatible versions are such a pain in the ass: Most Linux distros ship libjpeg-turbo with a (slightly enhanced) jpeg6.2 API as their default libjpeg, but Ubuntu ships it in the (incompatible!) jpeg8 API, so

1. you gotta make sure your source supports both versions
2. if you want to provide binaries for your users, you gotta bundle libjpeg, otherwise it only works on Ubuntu or on (most) other distros..

If you want the best possible performance in loading images (or textures) in a 3D-accelerated context, I'd suggest looking at Basis Universal.
If you need to decode the images in the CPU, it's probably best to use an uncompressed format (like TGA, BMP or uncompressed PNG), and maybe compress the images with zstd or lz4.

[Theldus]

Hi,
Yes, I also noticed stb_image got 'stuck' on SSE2 while libjpeg-turbo certainly uses newer versions, but it is pretty impressive anyway that a single-header library can still come close to something industry-standard being developed for over a decade.! Besides, stb_image also reads 8 file formats (in addition to JPEG), amazing.

I didn't know about the differences between API in libjpeg, perhaps the best approach is to support both libraries and let the user decide, maybe using stb_image as a default.

Anyway, thanks for the suggestions, I was just playing around with the libraries and seeing what I got from them, but for something more serious I will consider them =).