zune-image
libjpeg-turbo
zune-image | libjpeg-turbo | |
---|---|---|
8 | 15 | |
262 | 3,598 | |
- | 1.1% | |
9.7 | 8.2 | |
15 days ago | 1 day ago | |
Rust | 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.
zune-image
-
serde-numpy now supporting image formats!
Thanks to the zune-image library, serde-numpy is now supporting PNG and JPEG. Enabling faster io for neural net training loops and other image processing in python
-
Introducing zune-png: extremely fast PNG decoding in Rust
It has been extensively tested on 600,000 real world images, as well as fuzzed in various ways, and is now ready for production use!
-
Safety and Soundness in Rust
I might have misunderstood what you've written, but is there a reason you can't use https://github.com/etemesi254/zune-image as a JPEG decoder? It has minimal use of unsafe and is performant.
-
Announcing zune-jpeg: Rust's fastest JPEG decoder
It uses SIMD for colorspace conversion and IDCT, the code can be found here and here.
-
Introducing zune-inflate: The fastest Rust implementation of gzip/Zlib/DEFLATE
You can see a Github Action that zune-inflate uses here, it's mostly self-explanatory.
-
[Gitoxide in November]: high-speed diffing and pure-rust binary builds
I've just added a roundtrip fuzzer to the Rust translation of it so that we can start weeding out the bugs: https://github.com/etemesi254/zune-image/pull/13 Right now it finds some decoding failures in a few seconds.
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?
zune-jpeg - A jpeg decoder with wings
ImageMagick - 🧙♂️ ImageMagick 7
image-png - PNG decoding and encoding library in pure Rust
libwebp - Mirror only. Please do not send pull requests. See https://chromium.googlesource.com/webm/libwebp/+/HEAD/CONTRIBUTING.md.
unsafe-code-guidelines - Forum for discussion about what unsafe code can and can't do
orion - Usable, easy and safe pure-Rust crypto
miri - An interpreter for Rust's mid-level intermediate representation
bloom - The simplest way to de-Google your life and business: Inbox, Calendar, Files, Contacts & much more
image - Encoding and decoding images in Rust
virtualgl - Main VirtualGL repository
Symphonia - Pure Rust multimedia format demuxing, tag reading, and audio decoding library
Rustup - The Rust toolchain installer