mozjpeg
wazero
Our great sponsors
mozjpeg | wazero | |
---|---|---|
19 | 52 | |
5,330 | 4,465 | |
0.6% | 3.3% | |
6.2 | 9.8 | |
3 months ago | 13 days ago | |
C | Go | |
GNU General Public License v3.0 or later | Apache License 2.0 |
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
-
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.
-
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].
-
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.
-
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...
It was not badly picked for regular use cases. Just, before the retina displays appeared no one was interested in extreme low bitrate and no one knew that different artifacts had different impact with high density.
At least this problem was highlighted by Kornel, one of the mozjpeg author here: https://github.com/mozilla/mozjpeg/issues/76
> the employed solution only modifies first element from [16,17] to [10,16].
Correction: 16 and 17 are values from the base tables, which means this table is used with q=50. With q=25 it will be [32, 22, 24, 28, 24, 20, 32, 28…] (in zigzag order). The employed solution is to always limit the first value by 10 regardless of q: [10, 22, 24, 28, 24, 20, 32, 28…]
mozjpeg chosen the different approach: it still scales all values based on q, but has significantly changed the default base table. It helps, but doesn't eliminate color banding completely (you can still see it on the example from issues/76).
-
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.
- Mishaal Rahman on Twitter: "Samsung, MediaTek, and Google have enabled AV1 decode support in their chipsets, making Qualcomm the biggest holdout. I'm hoping that the next Snapdragon 8 series chipset brings AV1 decode support. Wishful thinking? Maybe."
-
WASM instead of C Dependencies?
Testsetup: Encode a 6048x2048px big image using mozjpeg (mozjpeg-sys to be more specific), resize it down to 1008x665px using PistonDevelopers/resize, and decode it again using mozjpeg.
wazero
-
Wazero: The zero dependency WebAssembly runtime
https://github.com/tetratelabs/wazero/releases/tag/v1.7.0
This includes the final release of the new optimizing compiler, which is a big improvement over the previous one.
The new version also adds experimental support for threads and snapshot/restore (setjmp/longjmp).
This is already being used by go-pgquery, all will mean that sqlc won't need to ship to almost copies of wazero (these features had been implemented on a friendly fork, and have now been up-streamed).
- Show HN: My Go SQLite driver did poorly on a benchmark, so I fixed it
-
Making Games in Go for Absolute Beginners
> Go actually has one of the best WASM runtimes https://github.com/tetratelabs/wazero
> I am the developer of Astral Divide, which is entirely written in Go: https://store.steampowered.com/app/2597060/Astral_Divide/
Your game looks great, congrats on your progress! I especially enjoyed how the zoom works when you're leaving/arrive planets, and the unique propulsion system (also, the anchor made me giggle!).
> lack of data structure packages
I tend to not need many, so I'd be curious if you can recall any structure in particular which you couldn't find? No biggie if not.
> package structure not suited for games
I'm not a game dev, but I've seen some larger games such as https://github.com/divVerent/aaaaxy/tree/main/internal (if you haven't played it before—do it!) which seem to be able to place everything into separate packages without issue, so perhaps there's something to gleam from their design?
> maps are random when iterated
Hash map iteration shouldn't be sorted in _any_ language (here's Rust, for example https://play.rust-lang.org/?version=stable&mode=debug&editio... (Python makes it _appear_ as if dicts are sorted hash maps, but that's only because it doesn't only use a hash table, but a vector as well (same as you'd have to do in Go))), otherwise it would cause both portability and security (https://github.com/golang/go/issues/2630) issues. You can use a b-tree (which was probably the data structure you wanted there) if you aren't willing to sort it yourself.
> modding options
If you don't care about unloading https://github.com/pkujhd/goloader
Go actually has one of the best WASM runtimes https://github.com/tetratelabs/wazero
It also has a bunch of libraries for embedding scripting languages https://awesome-go.com/embeddable-scripting-languages, with Tengo _probably_ being quickest https://github.com/d5/tengo
I'd _highly_ recommend Ebitengine in the future, as not only have there been multiple brilliant games using it, but it also has Switch/Android/iOS support, and you can find help with any issue whatsoever in their Discord. People have built 3D games with it, and Hajime is an absolute beast of a developer.
-
WASM by Example
That depends entirely on the runtime, and its WASI implementation.
wazero [1], which I'm most familiar with, allows you to decide in a relatively fine-grained way what capabilities your WASI module will have: command line arguments, environment variables, stdin/out/err, monotonic/wall clock, sleeping, even yielding CPU… Maybe more importantly, filesystem access can be fully emulated, or sandboxed to a specific folder, or have some directories mounted read-only, etc; it's very much up to you.
I've used it to wrap command line utilities, and package them as Go libraries.
For one example, dcraw [2]. WASM makes this memory safe, and I can sandbox it to access only the single file I want it to process (which can be a memory buffer, or something in blob storage, if I want it to).
Wazero looks super cool. I saw somewhere that programs can be run with a timeout, which sounds great for sandboxing. The program input is just a slice of bytes [1], so an interesting use case would be to use something like Nats [2] to distribute programs to different servers. Super simple distributed computing!
--
1: https://github.com/tetratelabs/wazero/blob/main/examples/bas...
-
Show HN: Sqinn-Go is a Golang library for accessing SQLite databases in pure Go
It is slower.
The WASM runtime wazero [1] uses a compiler on amd64 and arm64 (on Linux, macOS, Windows, and FreeBSD), but the current compiler is very fast (at compiling), but very naive (generates less than optimal code).
An optimizing compiler is currently being developed, and should be released in the coming months. I'm optimistic that this compiler will cover the performance gap between WASM and modernc.
[1]: https://wazero.io
-
Jacobin: Minimal JVM written in Go and capable of running Java 17 classes
I am a fan of the Jacobin project! For your uses, you may also want to consider wazero [1], a pure-go WebAssembly runtime. Full disclosure: I am on the team :)
[1]: https://wazero.io/
-
Val, a high-level systems programming language
No longer does Wasm/WASI need JS host! There are many spec-compliant runtimes built for environments from tiny embedded systems up to beefy arm/x86 racks:
- https://github.com/bytecodealliance/wasm-micro-runtime
- https://github.com/bytecodealliance/wasmtime
- https://github.com/wasmerio/wasmer
- https://github.com/tetratelabs/wazero
- https://github.com/extism/extism (disclaimer, my company's project - makes wasm easily embeddable into 16+ programming languages!)
What are some alternatives?
wasmer - 🚀 The leading Wasm Runtime supporting WASIX, WASI and Emscripten
wasmtime - A fast and secure runtime for WebAssembly
wasmer-go - 🐹🕸️ WebAssembly runtime for Go
squoosh - Make images smaller using best-in-class codecs, right in the browser.
guetzli - Perceptual JPEG encoder
grule-rule-engine - Rule engine implementation in Golang
yaegi - Yaegi is Another Elegant Go Interpreter
wasmtime-go - Go WebAssembly runtime powered by Wasmtime
gc - Branch of the spec repo scoped to discussion of GC integration in WebAssembly
image-actions - A Github Action that automatically compresses JPEGs, PNGs and WebPs in Pull Requests.
sc - Common libraries and data structures for C.
goja - ECMAScript/JavaScript engine in pure Go