Electronics > Microcontrollers

More compression codecs

(1/3) > >>

T3sl4co1l:
This looks quite promising:
https://phoboslab.org/log/2021/11/qoi-fast-lossless-image-compression

I may port it into my compression test demo thingy and see how it fares on embedded-relevant things I've been playing with.

The small buffer, and streamed architecture, suggests it should perform very well indeed on highly constrained embedded platforms.  Even in compression, given the excellent performance in both directions.

An indexed version could be made, I suppose, by simply packing the palette alongside a grayscale image.  Hmm, I wonder how the palette can be arranged to minimize large differences in the resulting grayscale...

Which, I also wonder if a dither extension would be worthwhile; specific to very color-constrained cases of course, and probably wouldn't perform all that well in general (having to encode the period and duty cycle of the pattern, in addition to the two alternating colors; and such runs only working along relatively rare flat-dithered rows, whereas real artwork contains gradients and curves?).  Meh, pixel art enthusiasts either have their own stuff anyway (I recall reading LucasArts had some storage method for them (though not necessarily compression?) back in the day... which means it should be part of ScummVM?), I digress.

Or changing the window to be 2D-aware, when that should prove valuable.  (Not so much on embedded, where you might not even have a frame buffer, but when one is available, sure.)  Wouldn't cover much area for the same number of pixels (like 32 x 2 or 16 x 4), unless the window can be grown (and profitably so), while still packing everything into a byte-wise encoding.


http://www.gfwx.org/
Not so simple (though still under 1kLOC, comments included), and not clear what the memory requirements are, but very much open and available, and excellent performance!

Tim

SiliconWizard:
Gave QOI a shot. Tried it on a few images. Here are my first remarks:

- It works. At least could not make it fail so far. Both encoding and decoding.
- In terms of compression, it doesn't look as good as the author's benchmark makes it appear. Compared to libpng on the images I used, the resulting files are about 2 times as large as PNG.
- It's fast. That's for sure.
- I got a number of warnings while compiling it - thought that might be worth fixing. The QOI_READ_16 macro is an example of what should not be done. Can you guess what the problem is?

--- Code: ---#define QOI_READ_16(B, P) ((B[P++] & 0xff) << 8 | (B[P++] & 0xff))
--- End code ---

Siwastaja:
Argh, that piece of code alone makes me not quite trust any of the code.

(| makes no sequence point, so the order in which P++ statements are evaluated, is undefined. Such code is unlikely to work except by luck. Why the author does not compile with warnings enabled, or overlooks the warnings, is beyond me!)

This being said, I quite like the idea of writing quick, simple, maybe even "unscientific" image compressor algorithms. I did something similar nearly 2 decades ago, my idea was to make a video player on TI-83 calculator but the TI-83 part never finished, or even started... But I did the encoder/decoder parts on PC and was able to squeeze some very small video files. I had similar concept of pattern headers/tags. These simple strategies greatly benefit from reducing the number of colors, i.e., quantization. I used 8-level (3-bit) grayscale in my tests back then. In such special cases (low resolution, low number of colors), these algorithms can even perform better (look better given the same file size) than general purpose advanced algorithms (like MPEG-1 at the time, which I compared against).

SiliconWizard:

--- Quote from: Siwastaja on November 27, 2021, 07:44:18 am ---Argh, that piece of code alone makes me not quite trust any of the code.
(| makes no sequence point, so the order in which P++ statements are evaluated, is undefined. Such code is unlikely to work except by luck. Why the author does not compile with warnings enabled, or overlooks the warnings, is beyond me!)
--- End quote ---

I took a look at the code (other than the point above.) It's not extremely good, it's not bad. Apart from a couple points that would be an easy fix.
It's unfortunate that people would still not bother looking at warnings these days, and keep using constructs that are undefined behavior.

I ran Cppcheck on the code, and it did find the issue with QOI_READ_16 (and QOI_READ_32 which uses QOI_READ_16):

--- Quote ---error: Expression '(bytes[p++]&0xff)<<8|(bytes[p++]&0xff)' depends on order of evaluation of side effects
--- End quote ---

It also found another issue: a resource leak at line 500 (in qoi_read): if memory allocation fails, the open file will never get closed.

So I would suggest rewriting the QOI_READ_* and QOI_WRITE_* macros and fixing the above. Both are simple fixes.

A last point is that both encoding and decoding use dynamic memory allocation. If you're going to use this in embedded projects, that's something to keep in mind, depending on your requirements. Modifying the code to support static allocation (and possibly using smaller buffer size) may not be all trivial.


--- Quote from: Siwastaja on November 27, 2021, 07:44:18 am ---This being said, I quite like the idea of writing quick, simple, maybe even "unscientific" image compressor algorithms.

--- End quote ---

Although I guess I know what you mean, I wouldn't put it this way. There's nothing "unscientific" about designing simple algorithms, as long as they are correct. Just because they don't use any fancy maths doesn't mean they are not "scientific".

Also implemented some kind of 2D-RLE (but only partial in the second direction) a few years ago, for a project that required real-time compression and decompression of video using a small FPGA. It wasn't close to PNG in terms of compression, but was good enough using the specific kind of images I had to deal with, and could run at about 200 MHz with relatively few resources on a Spartan-6 LX9.

The interesting point with QOI is that it looks reasonably general-purpose. Although not as good as PNG, it does a pretty decent job on various types of images.

I wanted a rude username:


Edit: Restored image from mirror.

Navigation

[0] Message Index

[#] Next page