SaaSHub helps you find the best software and product alternatives Learn more →
Libjpeg-turbo Alternatives
Similar projects and alternatives to libjpeg-turbo
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
-
-
-
-
-
-
-
-
-
Bullet
Bullet Physics SDK: real-time collision detection and multi-physics simulation for VR, games, visual effects, robotics, machine learning etc.
-
-
-
-
-
-
-
libwebp
Mirror only. Please do not send pull requests. See https://chromium.googlesource.com/webm/libwebp/+/HEAD/CONTRIBUTING.md.
-
NOTE:
The number of mentions on this list indicates mentions on common posts plus user suggested alternatives.
Hence, a higher number means a better libjpeg-turbo alternative or higher similarity.
libjpeg-turbo discussion
libjpeg-turbo reviews and mentions
Posts with mentions or reviews of libjpeg-turbo.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2024-04-03.
-
Neo Geo Dev: Fixed Point Numbers
Professional tools even for audio use floating point engines (Ableton has done this for well over a decade [1]). While fixed point may be ok for input/output formats, it is certainly not suitable for complex audio processing needs, where errors accumulate far too fast for any fixed point system at equivalent bit depth.
And fixed point is an order of magnitude slower.
> Decoding a JPEG for example is a bunch of fixed point math
It can be done that way, but modern decoders use float for accuracy and speed when available. Search libjpeg-turbo [2] codebase for float and surprise yourself. Even the ancient libjpeg [3] uses float when possible.
Why not simply used fixed-point? Because it's worse in nearly every way, and an artifact of computing from the 1970s-1980 when JPEG pieces were designed (DCT, lots of work culminating in the final JPEG spec in 1992). The world of computing has changed a bit since then.
[1] https://cdn-resources.ableton.com/80bA26cPQ1hEJDFjpUKntxfqdm...
[2] https://github.com/libjpeg-turbo/libjpeg-turbo
[3] https://www.ijg.org/files/
-
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
-
A note from our sponsor - SaaSHub
www.saashub.com | 8 Oct 2024
Stats
Basic libjpeg-turbo repo stats
16
3,737
9.2
14 days ago
libjpeg-turbo/libjpeg-turbo is an open source project licensed under GNU General Public License v3.0 or later which is an OSI approved license.
The primary programming language of libjpeg-turbo is C.
Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com