image compression

3 Articles

Jpegli: Google’s Better JPEG And Possible Death Knell For WebP

April 7, 2024 by 56 Comments

Along with the rise of the modern World Wide Web came the introduction of the JPEG image compression standard in 1992, allowing for high-quality images to be shared without requiring the download of a many-MB bitmap file. Since then a number of JPEG replacements have come and gone – including JPEG 2000 – but now Google reckons that it can improve JPEG with Jpegli, a new encoder and decoder library that promises to be highly compatible with JPEG.

To be fair, it’s only the most recent improvement to JPEG, with JPEG XT being introduced in 2015 and JPEG XL in 2021 to mostly deafening silence, right along that other, better new image format people already forgot about: AVIF. As Google mentions in their blog post, Jpegli uses heuristics developed for JPEG XL, making it more of a JPEG XL successor (or improvement). Compared to JPEG it offers a higher compression ratio, 10+-bit support which should reduce issues like banding. Jpegli images are said to be compatible with existing JPEG decoders, much like JPEG XT and XL images.

Based on the benchmarks from 2012 by [Blobfolio] between JPEG XL, AVIF and WebP, it would seem that if Jpegli incorporates advancements from AVIF while maintaining compatibility with JPEG decoders out there, it might be a worthy replacement of AVIF and WebP, while giving JPEG a shot in the arm for the next thirty-odd years of dominating the WWW and beyond.

Squeezing GIFs Into Even Tighter Spaces

December 21, 2022 by 6 Comments

Showing images on a TFT or OLED display with a small AVR microcontroller can be a challenge as it requires significant storage space. One solution is to compress the images, but then you need more RAM to decompress it, and that’s a whole other problem. [David Johnson-Davies] of Technoblogy couldn’t find a GIF decoder that fit his needs, so he started writing his own.

We had previously seen a minimal GIF decoder aimed at a Cortex-M0+ that required 24 K of RAM, but this technique is running on an AVR with just 12 K of RAM. Along the way, [David] uses little tricks to shave down the requirements. Since the TFT he targets is a 5-6-5 color space, those 3-byte colors become 2 bytes. The LZW lookup table is encoded as 12-bit pointers to earlier entries plus an additional pixel. However, these savings come at a cost. Animated, local color tables, transparency, interlacing, or GIF87a formatted images aren’t supported. But he ports it over to the PyBadge, which is ATSAMD51 based.

[David] provides some sample code to display a GIF from program memory and an SD card. All the code is on GitHub under a CC By 4.0 license.

A Super Speedy Lightweight Lossless Compression Algorithm

November 30, 2021 by 38 Comments

[Dominic Szablewski] was tinkering around with compressing RGB images, when he stumbled upon idea of how to make a simple lossless compression algorithm, resulting in the Quite OK Image Format, which seems to offer comparable file sizes to the PNG format but is so simple it runs up to 50 times faster for compression and up to four times faster for decompression. Implementation can be achieved with a miniscule 300 lines of C. Need a bit more detail on the real-world performance? Well [Dominic] has that covered too, with a complete set of benchmarks for your perusal.

Image formats are one of those things these days that are designed by consortium, with so much complexity wedged in making it hard to implement with limited resources, so we find it very refreshing to see someone going back to basics and producing something super lightweight, and plenty good enough in practical terms.

Other uses for the algorithm could be for super simple video compression, for applications where resource is tight and some low-effort bandwidth reduction would be beneficial. Implementation in a small FPGA would also be quite straightforward, since the memory requirement is quite low also.

The project is very new and already there are some tweaks happening to the format, so the GitHub project code may change without warning to reflect any corrections [Dominic] feels necessary.

Thanks [David] for the tip!