libjpeg-turbo
ImageMagick
Our great sponsors
libjpeg-turbo | ImageMagick | |
---|---|---|
15 | 169 | |
3,575 | 11,028 | |
1.1% | 2.7% | |
8.4 | 9.4 | |
5 days ago | 4 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.
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...
-
Why there may never be a libjpeg-turbo 3.1
> These projects deserve funding, if at least from giants like facebook & co.
Absolutely.
Looking at:
https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/...
one wonders what possible harm could come from leaving image decompression buffer faults from maliciously crafted jpegs in popular browsers and software unattended.
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
-
Looking for an open-source project to join part-time
There is no specific 'reference' that's required to match. However, you might be interested in libjpeg-turbo, which implements them in hand-written asm, as a comparison/bench target. My own opinion of this approach is that it should be unnecessary and for well-written code llvm beats 'hand-optimized' assembly. If some use of unsafe, unchecked indexing is necessary then so be it.
-
How do I create an image?
Different image formats are implemented by their own libraries, usually. libpng for PNG files, libjpeg-turbo is one of the ones for JPEG files, and so on.
-
The Future of Libjpeg-Turbo
https://news.ycombinator.com/item?id=25712301
This is based on https://github.com/mozilla/mozjpeg, which is a patched version of https://github.com/libjpeg-turbo/libjpeg-turbo
ImageMagick
-
Open source at Fastly is getting opener
To tie all this together, we made an org profile for our GitHub organization page. There are some great examples of these, like Microsoft and PayPal. For Fastly's, we wanted something friendly and human so we used Imagemagick to create a montage of all the avatars of the Fastly team members who have contributed to the open source projects in our org:
-
Video Generation with Python
Python has become a popular programming language for different applications, including data science, artificial intelligence, and web development. But, did you know creating and rendering fully customized videos with Python is also possible? At Stack Builders, we have successfully used Python libraries such as MoviePy, SciPy, and ImageMagick to generate videos with animations, text, and images. In this article, we will look closer at how Python can be used for video generation and explore some of the powerful libraries and tools that make it possible.
-
How Can I Streamline My Image Prep
ImageMagick is the main tool and can do most conversions and image operations. For example to resize a whole folder of photos and convert to WebP you can do this:
- HackTheBox — Writeup Pilgrimage [Retired]
- HTB - Pilgrimage Writeup
-
The Windows installer of ImageMagick will no longer be signed
From what I understand ImageMagick's vulnerability management involves updating to newer versions, so this is specifically about distributions that don't. Ubuntu chooses to distribute older versions with their own patches, but require Pro for you to get them.
With that said, the mentioned vulnerability is an odd one. A CVE published in 2023 with a CVE number for 2022 for a bug that was found and fixed in 2020. The bug in question is a memory leak when passing -help.[1]
Lack of open governance explains the fork in 2002. [0] The github commit history shows it's still a largely one-person-band. [1] The problems with this include a lack of succession planning, a lack of ability to scale bandwidth, and a narrower pool of ideas. The documentation website is really out-of-date as it mentions using a Borland compiler.
Alternatives to IM:
- http://www.graphicsmagick.org (IM fork)
0. https://marc.info/?l=imagemagick-developer&m=104777007831767...
- Website pentested. Help me fix the vulnerabilities found.
- Gibts ein (CLI) tool, das Kontrast und Helligkeit von gescannten Textdokumenten dynamisch anpasst?
What are some alternatives?
pillow - Python Imaging Library (Fork)
Intervention Image - PHP Image Processing
stb - stb single-file public domain libraries for C/C++
squoosh - Make images smaller using best-in-class codecs, right in the browser.
godot-stex-to-png - converts godot .stex files to standard .png files
av1-avif - AV1 Image File Format Specification - ISO-BMFF/HEIF derivative
ImageGlass - 🏞 A lightweight, versatile image viewer
punks.blocks - DIY (Do-It-Yourself) - Yes, You Can! Design Your Own Punk (Pixel) Characters / Heads using the Punk (Building) Blocks in the 24Ă—24px Format And Much More [UnavailableForLegalReasons - Repository access blocked]
FFmpeg - Mirror of https://git.ffmpeg.org/ffmpeg.git
godot-unpacker - godot .pck unpacker
lepton - Lepton is a tool and file format for losslessly compressing JPEGs by an average of 22%.
nixpkgs - Nix Packages collection & NixOS