QOI – The Quite OK Image Format

• libjxl

  84 2,178 9.8 C++

  JPEG XL image format reference implementation

  

> lossless JXL can be faster and compress better than QOI

It should be noted that it "can be", not it always is. The implementation in question [1] is currently experimental and not what you get from cjxl. In any case it is worth noting that QOI inspired both FPNG and FJXL.

[1] https://github.com/libjxl/libjxl/tree/main/experimental/fast...

• fpnge

  4 79 4.2 C++

  Demo of a fast PNG encoder.

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• qoi

  25 6,725 6.4 C

  The “Quite OK Image Format” for fast, lossless image compression

I don't know about CUDA, however I've made an AVX2 based encoder a few months ago : https://github.com/phoboslab/qoi/pull/143

I intend to create an AVX2 based decoder but I had absolutely no time to work on side projects in the past three months.

You might also want to take a look at this streaming encoder if you want to encode large files with a tiny memory footprint : https://github.com/MKCG/php-qoi/blob/main/src/FFI/lib/qoi.c

• php-qoi

  1 8 4.1 PHP

  QOI image encoder and decoder written in pure PHP

I don't know about CUDA, however I've made an AVX2 based encoder a few months ago : https://github.com/phoboslab/qoi/pull/143

I intend to create an AVX2 based decoder but I had absolutely no time to work on side projects in the past three months.

You might also want to take a look at this streaming encoder if you want to encode large files with a tiny memory footprint : https://github.com/MKCG/php-qoi/blob/main/src/FFI/lib/qoi.c

• fpng

  10 824 4.1 C

  Super fast C++ .PNG writer/reader

In the other direction, you can target a subset of PNG to get less optimized images but with QOI-like encode and decode speed: https://github.com/richgel999/fpng

• stb

  164 25,008 6.7 C

  stb single-file public domain libraries for C/C++

> Is this common practice? I’ve been assuming header files are used for unimplemented type definitions similar to TypeScript .d.ts files. Is this wildly wrong to assume?

Normally, you’d be almost correct, yes.

Unlike many other languages (including TypeScript AFAIK), C and C++ compilers are defined to process a self-contained stream of tokens (the “compilation unit”), which must declare the type of everything they use from the outside; those are then linked together into an executable with external references bound by name, with the types blindly assumed to be correct. (The linker works at the assembly level, not the C level, the types are already gone.) The usual workaround is to have the preprocessor, which assembles the token stream, pull in the declarations from a common source, the “headers”, just plain insert the declaration text into the source file. Thus the headers play a similar role to .d.ts files, but the toolchain does not impose any convention on how things are arranged in files, unlike in TypeScript, Go, or Java.

There are two downsides for this: first, the declarations go through the compiler once for every source file that uses them, yielding slower compiles; second, if you want to consume a library in source form you’ll have to marry the build system for the library with the build system for your consumer. (The “build system” is the conceptual thing that knows how to set up the header search paths, which files to compile, and how to link or otherwise package the results into the build artifacts.)

An alternative approach to this traditional one is the “header-only library”; it mostly eliminates the second downside at the cost of substantially exacerbating the first.

- In the C++ world, the dumb linker model I described aabove is something of a lie: a lot of C++ things (vtables, inline functions, template instances, etc.) do not actually have a well-defined compilation unit they belong to, so in the simplest apprpach the compiler generates a definition for every compilation unit and the linker has to (know enough to be able to) throw away all of these except one. (You see where the notoriously long C++ compile times come from.) A header-only library then just bites the bullet, defines everything inline, and has the linker sort them out. These have become fairly common over the last decade.

- In the C or C-ish-C++ gamedev world, there’s a practical need to get prototypes or good-enough implementations out the door quickly, so the library that is easiest to integrate across as much build systems as possible has an advantage. A different variety of header-only libraries has gained traction there. These have the header contain both declarations and implementation, but the implementation is guarded by a preprocessor macro; the user of the library defines that macro in a single compilation unit that they designate as owning that implementation. (This has worse “tree-shaking” characteristics than a well-organized static library, but if the library isn’t large that’s probably not a big deal, and in any case many common libraries, such as libjpeg and libtiff, are not well organized in this sense.)

The QOI library comes from the second tradition and is probably influenced by the similar stb libraries[1].

[1] https://github.com/nothings/stb

• zpaqlpy

  2 19 10.0 Rust

  Compiles a zpaqlpy source file (a Python-subset) to a ZPAQ configuration file for usage with zpaqd

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

Suggest a related project