"Kaže kako se ovog posla primio jer su drugi formati (.png, .jpeg, ali i video formati kao što su .mpeg, .mov i .mp4) iznimno kompleksni, jer ih je "dizajnirao konzoricij"."
Zavjera ljudi reptila. 
Išao vidjeti png specifikaciju da vidim o čemu lik govori.
Očekujući da ću naći specifikaciju kompresije.
Kad ono kompresija se spominje samo kao naznaka da png koristi deflate kompresiju. A druge kompresije nisu definirane standardom.
Spala knjiga na tri slova.
Išao vidjeti png specifikaciju da vidim o čemu lik govori.
Očekujući da ću naći specifikaciju kompresije.
Kad ono kompresija se spominje samo kao naznaka da png koristi deflate kompresiju. A druge kompresije nisu definirane standardom.
Spala knjiga na tri slova.
Ima kod na githubu, ovdje je primjer u C#
https://github.com/NUlliiON/QoiSharp
Go: https://github.com/xfmoulet/qoi
Pascal: https://github.com/DosWorld/pasqoi
Python: https://github.com/kodonnell/qoi
Lijepi pozdrav
Članak je možda mrvicu misleading, barem sam ga ja tako shvatio. Sad sam skinuo testne datoteke, radi se o *enkodiranju* slike a ne o kompresiji. Slike su daleko veće od losless PNG-a, ali valjda je enkodiranje u format brže.
Ovo bi možda moglo imati primjenu kod video streaminga, ali tamo se koristi lossy format koji sasvim uredno odrađuje posao. Tako da meh ...
Al kolka mu je u prosjeku velicina slike, jer ako saljes npr podatke preko interneta, bitnije ti je da ih brze posaljes jer su manji (sto se mjeri u sekundama) nego sto si ustedio par 10-aka ms na encodiranje.
U tom slucaju je usporedba s .png-om ili jpg-om malo blesava, jer oni imaju specificnu zadacu koju obavljaju.
Al kolka mu je u prosjeku velicina slike, jer ako saljes npr podatke preko interneta, bitnije ti je da ih brze posaljes jer su manji (sto se mjeri u sekundama) nego sto si ustedio par 10-aka ms na encodiranje.
U tom slucaju je usporedba s .png-om ili jpg-om malo blesava, jer oni imaju specificnu zadacu koju obavljaju.
Ako usporediš s PNG, u prosjeku slika ispadne 30-50% veća, ali troši manje procesora... Iskreno, nisam siguran zašto je ovo postalo viralno i čemu toliki hype oko svega...
Al kolka mu je u prosjeku velicina slike, jer ako saljes npr podatke preko interneta, bitnije ti je da ih brze posaljes jer su manji (sto se mjeri u sekundama) nego sto si ustedio par 10-aka ms na encodiranje.
U tom slucaju je usporedba s .png-om ili jpg-om malo blesava, jer oni imaju specificnu zadacu koju obavljaju.
Ako usporediš s PNG, u prosjeku slika ispadne 30-50% veća, ali troši manje procesora... Iskreno, nisam siguran zašto je ovo postalo viralno i čemu toliki hype oko svega...
Zato što je lik otkrio toplu vodu, a to je da je većina današnjeg softwera teški legacy bloat. A to je cute kao slike mladih mačaka.
CPU je nebitan za slike, bitan je stupanj sažimanja bez gubitka. Tako da fokusirao na krivu stvar i u tom području je lošiji od svega.
ALI, u području videa jest bitan CPU. Da se ubaci u video vode, tamo bi mogao požnjeti ozbiljan uspjeh sa smanjenjem potrošnje CPU, pod pretpostavkom da je sve zbilja kako kaže tj. da je lossless i da veličina nije 10x veća od prvog sljedećeg encodera.
zgodno. hvala na ideji - malo razbibrige za praznicne dane kad vani stisne studen, a od ponude filmova ti dodje slabo.
pogledao sam primjere i prema benchmarcima omjer brzine i kompresije je sjajan - dakako naglasak je na brzini.
ono sto meni nedostaje jest upravo poredjenje sa drugim generalnim kompresorima poput ZLiba koji ne mare za vrstu inputa; bas zbog brzine i mislim da bi shio ovaj njegovu implemetaciju - bas cu isprobati da vidim konkretno.
naravno da je komentar o konzorciju i kompleksnosti bedast. inace postoje sjajni algoritmi kompresije koje nisu zazivjeli SAMO zbog minskog polja zvanog IP.
a ovim zucnim momcima na forumu - cemu popljuvavati mladica koji je sebi rijesio problem?
decko je trazio nesto brzo, napisao RLE s preponama i - super!
naravno njegove slike su - buduci da dolazi iz game making worlda nekako fokusirane na teksture i pixel format je ovdje samo 32-bitni: RGB + alpha channel.
hvala na linku!
inace, bacih pogled na jednu groznu implementacije ali ove linije su mi izmamile nostalnigcni osmijeh:
GRAPH_MODE = $13;
...
PROCEDURESetMode(mode: INTEGER); ASSEMBLER;
ASM
MOV AX, mode
INT $10
END;
CPU je nebitan za slike, bitan je stupanj sažimanja bez gubitka. Tako da fokusirao na krivu stvar i u tom području je lošiji od svega.
ALI, u području videa jest bitan CPU. Da se ubaci u video vode, tamo bi mogao požnjeti ozbiljan uspjeh sa smanjenjem potrošnje CPU, pod pretpostavkom da je sve zbilja kako kaže tj. da je lossless i da veličina nije 10x veća od prvog sljedećeg encodera.
slatko se nasmijah - nemas ljutnje sinatra.
pa vec postoje lossless codeci za video, da si ikada renderao video u losless formatu, znao bi da je "omanji" nedostatak - DZINOVSKA potrosnja prostora na disku, jer dakako nijedan lossles codec ne moze prici bilo kojem lossy algoritmu po pitanju velicine kompresiranog materijala.
k tome sam CPU danas kod kodiranja vise ne igra nikakvu ulogu jer ta cemu sluze hardware compressori koji rade upravo to? h.264, h.265, AV1... hint - film se odvija na GPU. ;-)
Nebi se bavio cijeli "konzorcij" s tim da je to tako jednostavno. Nisam gledao kod ali nebi se čudio da je samo nabacio zip ili neku drugu kompresiju i eto ga manja slika! Ono genijalno, kak se nisu toga prije sjetili, kad ono svaki lossless format napravljen na isti način..
Unatoč očvrsju kojeg se ne bi posramio ni bolji bug-ovac, super-brzi diskovi, vrlo jaki CPU i ok grafulja, renderiranje 4K videa ne prolazi baš brzo. Sporije od sekunde videa za sekundu vremena. Usko grlo je CPU i grafulja, ne zna se koji jače "dere" pri renderu. A 8K da ne pričam. Tako da bi neki codec koji manje cpu troši dobro došao. Još ako je lossless a da bitno smanjuje gigabajtažu - to bi bilo čudo, ako je uopće moguće. Slažem se da teško da će za video napraviti lossless a da smanji fajle na upotrebljivu veličinu, to mi zvuči teško moguće, ali ne i nemoguće.
