Sajnos ezt most elkapkodtad.
Súlyos tévedésben leledzel, nem ártana elolvasni a README-t vagy a forráskód legtetején a kommenteket, ugye...
Már indításból nincs Makefile
Soha, egyetlen stb single header library-hoz sincs, mert nem is lehet. Nincs mit lefordítani, egy fejlécfájl csupán, amit csak "#include"-olni kell.
Az sem igaz, hogy függőség nélküli, mert igényli a png.h-t (libpng).
Lófasz kell neki, nem a libpng. Az csak a konvertálóknak kell, azok ugyanis PNG-ből vagy PNG-be konvertálnak, ugye és hát ahhoz biza köll a libpng... A QOI / QOI 2.0 függvénykönyvtárakhoz NEM kell. De ha írsz egy konvertálót, ami PPM-et használ, vagy mondjuk az stb_image.h fejlécfájlt, akkor ahhoz sem fog kelleni a libpng.
A konvertálók fordítása meg egyébként (ott van leírva a kommentben, mindjárt a fájl legtetején) a legprimitívebb egysoros, gcc qoi2enc.c -o qoi2enc -lpng, ehhez felesleges a Makefile.
De direkt a kedvedért csináltam egyet.
Továbbmenve teszteltem mindenféle háttérképpel, és a legtöbbet sokkal nagyobbra tömörítette össze, mint az eredeti .png fájl volt.
Ejnye, de nem erősséged az olvasás. Sosem állítottam ezt. Igen, a PNG jobban tömörít, cserébe SOKKAL lassabb és sokkal több erőforrást (memóriát és CPU-t) zabál. Le van írva feketén fehéren:
- a repó README legelején: It is extremely small (~200 SLoC), super-duper fast to decode, yet it provides just slightly worse compression ratios than PNG (slightly worse != jobb lenne)
- samples/README-ben: In general PNG still compresses better, but requires considerably more (I mean, by magnitudes more) CPU time to decode
- eggyel korábbi hozzászólásomban is leírtam: közel PNG szinten van a törmörítési rátája, ugyanakkor milliószor gyorsabb kicsomagolni annál (közel != hogy mindig jobb)
Itt a hangsúly azon van, hogy baromi gyors, csak egy kis statikus memóriát eszik, ehhez képest mégse rossz a tömörítési rátája. Mindig is erről szólt a QOI, és ez nincs másként a QOI 2.0-ában sem.
Egyedül csak akkor tömörített jobban, mint egy png, ha a képen sok azonos színű pixel volt egymás mellett, ahogy a kolléga írta felettem, a rajzolt, mesterséges képek, UI screenshotok fekszenek neki.
Mármint most az eredeti QOI-ról beszélsz, ugye? Igen, az ilyen, az egyáltalán nem képes anti-aliasolt transzparens képeket tömöríteni, mint a QOI 2.0. Pont emiatt csináltam.
Tipikus példa erre a samples/pnglogo: ez PNG-ben 311K (nyilván ez a legjobban törmörített), ez az eredeti QOI-ban 406K, az én QOI 2.0-mmal meg 377K. Az még mindig több, mint a PNG, ugyanakkor SOKKAL jobb, mint az eredeti QOI, 10%-ot ráver. A többi példaképnél is hasonló az eredmény, a legrosszabb a Lena, amin egyáltalán nincs egyetlen transzparens pixel se, az csak ~400 bájttal kissebb. De ezt is írtam már, hogy ilyen esetben azonos a rátája az eredeti QOI-val.