mozjpeg
libjpeg-turbo
Our great sponsors
mozjpeg | libjpeg-turbo | |
---|---|---|
19 | 15 | |
5,353 | 3,582 | |
0.8% | 1.3% | |
6.2 | 8.4 | |
4 months ago | 15 days ago | |
C | C | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
mozjpeg
-
WebP is so great except it's not
[2] https://github.com/mozilla/mozjpeg
-
It's the future – you can stop using JPEGs
It would be nice if the author would add mozjpeg[1] to the comparison. At certain sizes, it can produce smaller sizes than WebP, and because it is still a jpeg, it has a much better compatibility story, which the author alluded to.
[1]https://github.com/mozilla/mozjpeg
-
Random Code Inspiration Volume 2
image-shrinker is a simple, easy to use open source tool for shrinking images. Under the hood it uses pngquant, mozjpg, SVGO, and gifsicle. You can also install these tools individually if you need to compress some images. I often use pngquantafter exporting PNGs for web projects from Figma or similar tools. I literally run it like this:
-
JPEG XL: How It Started, How It’s Going
> MozJPEG is a patch for libjpeg-turbo. Please send pull requests to libjpeg-turbo if the changes aren't specific to newly-added MozJPEG-only compression code.
https://github.com/mozilla/mozjpeg#mozilla-jpeg-encoder-proj...
-
Why there may never be a libjpeg-turbo 3.1
FWIW, Mozilla has been maintaining their own fork for quite a while now[1]
AFAIK most Linux Distros have been using libjpeg-turbo as a drop-in replacement for libjpeg, after some drama in ~2010 where libjpeg came under new management, decided to break ABI/API several times over and add incompatible, non-standard format extensions[2].
[1] https://github.com/mozilla/mozjpeg
[2] https://en.wikipedia.org/wiki/Libjpeg#History
-
Are all JPEG compression implementations the same?
No.
See https://github.com/mozilla/mozjpeg
Also, there is a fairly big problem with JPG that the ‘quality’ setting is not calibrated. That is you might look at one image and think it looks fine (which is subjective, depends on what you want to use the image for…) with a quality of 60%, but then you compress a million images at that rate, delete the originals, then you find that many of them look really awful. Not only that but there are images you could have compressed more and still been happy with the output.
If you are publishing images for the web consider using WebP which is consistently better, well supported now, and has a calibrated quality knob.
-
reduce the size of a bunch of jpg
https://github.com/mozilla/mozjpeg's cjpeg tool is the command line version of the mozjpeg library, itself a fork of libjpeg-turbo. Mozjpeg performs lossless JPEG optimization. There are plenty of others out there.
-
Lossy Image Compression with Dithering
Use the Mozilla JPEG Encoder, which implements several tricks for smaller file size / better visual quality. The result is still JPEG standard compatible that other software can decode.
-
Fighting JPEG Color Banding
Guetzli was already mentioned and roughly does what you are talking about.
MozJPEG [1] includes several quantization tables that are optimized for different contexts (see the quant-table flag and source code for specific tables[2]), and the default quantization table has been optimized to outperform the recommended quantization tables in the original JPEG spec (Annex K).
It's also worth noting that MozJPEG uses Trellis quantization [3] to help improve quality without a per-image brute force quantization table search. Basically rather than determining an optimal quantization table for the image, it minimizes rate distortion on a per-block level by tuning the quantized coefficients.
[1] https://github.com/mozilla/mozjpeg
[2] https://github.com/mozilla/mozjpeg/blob/5c6a0f0971edf1ed3cf3...
[3] https://en.wikipedia.org/wiki/Trellis_quantization
-
FFmpeg now supports JPEG XL
They're still being used. A newer, optimized JPEG encoder, mozJPEG[0], seems to use progressive encoding by default. I suspect with faster internet speeds, most images download and decode so fast that the cool 'enhance' animation doesn't happen anymore.
[0] https://github.com/mozilla/mozjpeg
libjpeg-turbo
-
Jpegli: A New JPEG Coding Library
> all decoders will render the same pixels
Not true. Even just within libjpeg, there are three different IDCT implementations (jidctflt.c, jidctfst.c, jidctint.c) and they produce different pixels (it's a classic speed vs quality trade-off). It's spec-compliant to choose any of those.
A few years ago, in libjpeg-turbo, they changed the smoothing kernel used for decoding (incomplete) progressive JPEGs, from a 3x3 window to 5x5. This meant the decoder produced different pixels, but again, that's still valid:
https://github.com/libjpeg-turbo/libjpeg-turbo/commit/6d91e9...
-
My personal C coding style as of late 2023
Last vestiges of this fact AFAIK were libjpeg, which had a macro NEED_SHORT_EXTERNAL_NAMES that shortens all public identifiers to have unique 6-letter-long prefixes. Libjpeg-turbo nowadays has removed them though [1].
[1] https://github.com/libjpeg-turbo/libjpeg-turbo/commit/52ded8...
- Libjpeg-Turbo 3.0.0
-
Why there may never be a libjpeg-turbo 3.1
While I think the move to safer code through Rust and other alternatives is a nice breath of fresh air, I doubt you can get these kinds of optimization without using unsafe code in Rust. These optimized implementations often require some kind of safety-bypassing memory modifications to work as efficiently ad they do.
There's a reason https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim... is filled with assembly files with conditional loading.
-
Learn x86-64 assembly by writing a GUI from scratch
Sure. You'll see it very often in codec implementations. From rav1e, a fast AV1 encoder mostly written in Rust: https://github.com/xiph/rav1e/tree/master/src/x86
Large portions of the algorithm have been translated into assembly for ARM and x86. Shaving even a couple percent off something like motion compensation search will add up to meaningful gains.
Or the current reference implementation of JPEG: https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim...
-
Announcing zune-jpeg: Rust's fastest JPEG decoder
zune-jpeg is 1.5x to 2x faster than jpeg-decoder and is on par with libjpeg-turbo.
-
JDK 21 - Image Performance Improvements
This is interesting from the standpoint of how new JVM features can be used to improve performance (what I presume the article's main purpose to have been), but the image processing improvement itself isn't head-turning. Also, we've found that libjpeg-turbo (https://libjpeg-turbo.org/) is ~5x (IIRC, can re-run my JMH benchmark if anyone wants me to) as fast for decoding JPEGs as ImageIO, so we wouldn't even benefit from this change in 21 much.
-
Convenient CPU feature detection and dispatch in the Magnum Engine
libjpeg-turbo: https://github.com/libjpeg-turbo/libjpeg-turbo/blob/main/simd/x86_64/jsimdcpu.asm
-
Implementing SVE2 for Open Source Project
libjpeg-turbo
-
How to go about implementing file encoding [Question]
For all but the simplest formats (basically BMP), the difficulty of implementing encoding/decoding from scratch is significant - well beyond a beginner's ability, and challenging/time-consuming even for senior developers. So, libraries are used in practice - e.g. libpng and libjpeg-turbo.
What are some alternatives?
squoosh - Make images smaller using best-in-class codecs, right in the browser.
ImageMagick - 🧙♂️ ImageMagick 7
guetzli - Perceptual JPEG encoder
libwebp - Mirror only. Please do not send pull requests. See https://chromium.googlesource.com/webm/libwebp/+/HEAD/CONTRIBUTING.md.
wazero - wazero: the zero dependency WebAssembly runtime for Go developers
orion - Usable, easy and safe pure-Rust crypto
image-actions - A Github Action that automatically compresses JPEGs, PNGs and WebPs in Pull Requests.
bloom - The simplest way to de-Google your life and business: Inbox, Calendar, Files, Contacts & much more
bimg - Go package for fast high-level image processing powered by libvips C library
virtualgl - Main VirtualGL repository
jpegoptim - jpegoptim - utility to optimize/compress JPEG files
Rustup - The Rust toolchain installer