There are a lot of better-than-JPEG and better-than-PNG solutions out there.
Speed: If the benchmarks are correct, then this is exceptional, especially considering that the file size is only slightly larger than PNG.
I can think of a couple of ways they could reduce the file size by probably around 10%-20% without sacrificing speed, but this is good enough to get attention.
The biggest speed loss for PNG comes from zlib.
PNG without zlib is very fast -- probably comparable to QOI.
If QOI use bz2 or even zlib on top of the current encoding scheme, then it would be slower, but I bet it would also be smaller than PNG.
The biggest issue isn't making a better/faster picture format.
Rather, the biggest issues are adoption, metadata, and variable color support.
Until web browsers and smartphones natively support the format, it's only good for a proof-of-concept or for niche applications. (Don't get me wrong -- online games could benefit from something like this.)
Wide-spread consumer adoption will also need support for metadata. EXIF, IPTC, XMP, ICC Profiles, etc.
This is easy enough to add. I hope the author choose something simple, like a tag-length-data. The tag just identifies it as a meta block. The data should begin with a text string and "\n" that defines the type of data, followed by the binary data. The "length" includes the size of the data + string + 1 for "\n". Also, be aware that some metadata is larger than 65535 bytes, so the length should support large data blocks.
The algorithm as currently defined only supports 8-bits per channel and 3 or 4 channels (RGB or RGBA).
For widespread adoption, it should support:
- 8-bit Grayscale (1 byte per pixel)
- 16-bit Grayscale (2 bytes per pixel)
- 8-bit Grayscale + Alpha (2 byte per pixel)
- 16-bit Grayscale + Alpha (4 bytes per pixel)
- 8-bit and 16-bit RGB (24 and 48 bytes per pixel)
- 8-bit and 16-bit RGBA (32 and 64 bytes per pixel)
- 8-bit and 16-bit CMYK (for the printing industry)
- 8-bit YUV (for cameras; most also support 16-bit YUV, but it's rarely ever seen)
I don't think the algorithm will change for these, but the file format will need a header that defines the color space and color depth.
The source code is also problematic. For example, the .h (header) file contains functions. Not function definitions, but actual functions. E.g.: https://github.com/phoboslab/qoi/blob/master/qoi.h
All functions (qoi_encode, qoi_decode, etc.) are completely included in this header file. It should be in a .c file (not .h) and compiled into a library (libqoi). Although C does permit you to put functions in header files, it is REALLY REALLY REALLY bad form and strongly discouraged. (This is a really bad programming practice. When I was in school, doing this sort of thing would be an immediate homework failure even if the code works.)
I came all the back from my Thanksgiving slumber just to say; really?
I love this library, and have made a C++ friendly version of the same.
What you get for a few hundred lines of code far outweighs any of the shortcomings it might have. It's a great starting point. If someone wants to make a full on format, they'll probably be better off just using the new JPEG XL, rather than trying to shape this thing.
It's a good exploration of what can be done with run-length encoding.
Speed: If the benchmarks are correct, then this is exceptional, especially considering that the file size is only slightly larger than PNG.
I can think of a couple of ways they could reduce the file size by probably around 10%-20% without sacrificing speed, but this is good enough to get attention.
The biggest speed loss for PNG comes from zlib. PNG without zlib is very fast -- probably comparable to QOI. If QOI use bz2 or even zlib on top of the current encoding scheme, then it would be slower, but I bet it would also be smaller than PNG.
The biggest issue isn't making a better/faster picture format. Rather, the biggest issues are adoption, metadata, and variable color support.
Until web browsers and smartphones natively support the format, it's only good for a proof-of-concept or for niche applications. (Don't get me wrong -- online games could benefit from something like this.)
Wide-spread consumer adoption will also need support for metadata. EXIF, IPTC, XMP, ICC Profiles, etc. This is easy enough to add. I hope the author choose something simple, like a tag-length-data. The tag just identifies it as a meta block. The data should begin with a text string and "\n" that defines the type of data, followed by the binary data. The "length" includes the size of the data + string + 1 for "\n". Also, be aware that some metadata is larger than 65535 bytes, so the length should support large data blocks.
The algorithm as currently defined only supports 8-bits per channel and 3 or 4 channels (RGB or RGBA). For widespread adoption, it should support: - 8-bit Grayscale (1 byte per pixel) - 16-bit Grayscale (2 bytes per pixel) - 8-bit Grayscale + Alpha (2 byte per pixel) - 16-bit Grayscale + Alpha (4 bytes per pixel) - 8-bit and 16-bit RGB (24 and 48 bytes per pixel) - 8-bit and 16-bit RGBA (32 and 64 bytes per pixel) - 8-bit and 16-bit CMYK (for the printing industry) - 8-bit YUV (for cameras; most also support 16-bit YUV, but it's rarely ever seen) I don't think the algorithm will change for these, but the file format will need a header that defines the color space and color depth.
The source code is also problematic. For example, the .h (header) file contains functions. Not function definitions, but actual functions. E.g.: https://github.com/phoboslab/qoi/blob/master/qoi.h All functions (qoi_encode, qoi_decode, etc.) are completely included in this header file. It should be in a .c file (not .h) and compiled into a library (libqoi). Although C does permit you to put functions in header files, it is REALLY REALLY REALLY bad form and strongly discouraged. (This is a really bad programming practice. When I was in school, doing this sort of thing would be an immediate homework failure even if the code works.)