farbfeld, nový bezeztrátový grafický formát od suckless

Projekt suckless, tj. "software, který štve méně", se rozrostl o nový bezeztrátový grafický formát farbfeld (cgit, README). Dle autorů by grafický formát měl být co nejjednodušší, snadno parsovatelný, jeho zpracování by mělo být možné pomocí rour a filtrů a komprese by neměla být jeho součástí. Ta by měla být řešena externími kompresními nástroji.

17.1.2016 20:20 | Ladislav Hagara | Zajímavý software

Komentáře

[Josef Kufner]

A k čemu to je dobré? Má to vůbec nějaký přínos oproti PNG?

[pavlix]

Vždyť se to píše přímo ve zprávičce.

[Josef Kufner]

Přijde mi to jako naprostý nesmysl. Pokud jde o ukládání obrázku, tak PNG je jednoduché a flexibilní. Pokud o zpracování unixovými nástroji, tak je to o nástroji a ne o formátu. Pro texotvý formát už máme NetPBM a pro binární tvar je tak jako tak potřeba něco specializovaného, bez ohledu na jednoduchost formátu. Takže to klidně může používat PNG a neztrácet po cestě metadata.

Chápal bych vytvoření sady nástrojů a knihovny, která by pořešila API, aby bylo snadné pořešit parametry a předávání obrázku, a tedy i vytváření rourovatelných nástrojů.

[kralyk z abclinuxu]

+1, PNG není nijak složitý.

[pavlix]

Neřekl bych, že je PNG v kontextu klasických pixmap jednoduchým formátem.

[Josef Kufner]

PNG toho umí celkem hodně a může to na první pohled vypadat děsivě, ale ten formát je opravdu elegantní, jednoduchý a univerzální. Udělejme malé srovnání:

Farbfeld obrázek:

"farbfeld" [šířka] [výška] [data obrázku - RGBA pixely]

PNG obrázek:

"\x89PNG\x0D\x0A\x1A\x0A"
[délka IHDR chunku] "IHDR" [šířka] [výška] [bit hloubka] [typ barvy] [komprese] [filtr] [prokládání] [CRC IHDR chunku]
[délka IDAT chunku] "IDAT" [pixely obrázku komprimované pomocí defalte (zlib)] [CRC IDAT chunku]
[délka IEND chunku (0)] "IEND" [CRC IEND chunku]

Když v PNG vynecháme technické drobnosti okolo jednotlivých chunků, tedy délku a kontrolní součet, dostaneme:

"PNG"
"IHDR" [šířka] [výška] [bit hloubka] [typ barvy] [komprese] [filtr] [prokládání]
"IDAT" [pixely obrázku komprimované pomocí deflate (zlib)]
"IEND"

Jo, je tam navíc ta komprese, filtrování před kompresí a možné prokládání. Filtrování lze vypnout, prokládání také a zbývá už jen prosté volání zlib. A na to lze dodefinovat vlastní noop kompresi. (To mi přijde jako chyba v návrhu PNG, že komprese "0" je LZ77 a nic dalšího tam není. Čekal bych "0" jako žádnou kompresi a "1" jako LZ77 – filtry a prokládání tak udělané jsou.)

PNG má ale obrovskou výhodu v tom, že do něj lze dostat další data a lze ho rozšiřovat. A pokud program nějakému chunku nerozumí, prostě ho zkopíruje do výsledku, nebo zahodí.

[pavlix]

Ani teď mi není jasné, co na tom nechápeš a proč si nepřečteš ve zprávičce odkazované zdroje. Chtěli triviální formát, mají triviální formát. Už podle návrhu toho formátu je zřejmé, že nic jako PNG cílem nebylo. Podobné formáty samozřejmě už existovali a oni se k nim částečně vyjadřují. Že ti to nepřijde užitečné? To asi není u „suckless“ projektu nic překvapivého a u „suckless“ formátu už vůbec ne. Máš nějaké lepší řešení než to prostě nepoužívat?

[Josef Kufner]

To je jen má naivní snaha zabránit jim v plýtvání časem.

[pavlix]

Ten formát je triviální, takže plýtvání časem je v tomto případě ekvivalentem řešení běžné školní úlohy. Navíc tě nejspíš nikdo z nich nečte. Myslím, že tu plýtváme časem daleko horším způsobem než ti, kterým jsi chtěl údajně od plýtvání časem pomoct.

[Jendа]

"farbfeld" [šířka] [výška] [data obrázku - RGBA pixely]

Jak se to liší od PBM v binárním tvaru?

[Josef Kufner]

Všechny tyhle jednoduché formáty jsou jen o hlavičce následované seznamem pixelů. Vždy tam je šířka a výška obrázku, většinou ještě počet barev, případně paleta.

[Bedňa]

Fakt v tom nemám moc prehlad, ale čo som pochopil, tak to zapadá do filozofie *nixu, jeden program robí jednu vec a robí ju dobre. Grafický formát len uchováva dáta, ktoré napríklad pošleš cez rúru do 7z a tie sa pri zobrazení cez 7z rozbalia. Proste formát sám nerieši zobrazenia aj kompresiu.

[ffghgff]

sucklessaci nepochopili, ze existuji roury. mohli udelat konvertor z cehokoliv (jpg, png) do plain rgb formatu a ten nasledne zpracovavat trubkama.

[onovy]

takze je to prakticky BMP akorat s mensi hlavickou, omg.

[xkucf03]

grafický formát měl být co nejjednodušší, snadno parsovatelný, jeho zpracování by mělo být možné pomocí rour a filtrů

Proto má PNG i textovou reprezentaci zvanou SNG (Scriptable Network Graphics), o které se píše např. v knize Umění programování v Unixu: Case Study: SNG a která je už dlouho v distribucích (např. aptitude install sng).

farbfeld (2016):

Current image formats have integrated compression, making it complicated to read the image data. One is forced to use complex libraries like libpng, libjpeg, libjpeg-turbo, giflib and others, read the documentation and write a lot of boilerplate in order to get started.

SNG (1999):

Rather than writing special-purpose code to grovel through the PNG binary format, the user can simply flip an image into an all-text representation, edit that, and massage it back. Another potential application is in making images amenable to version control; under most version-control systems, text files are much easier to manage than binary blobs, and diff operations on SNG representations actually have some possibility of yielding useful information.

[juras]

Poslední dobou mi připadá, že celé slavné suckless hnutí tvoří samé produkty které really sucks. Opravdu si nemyslím, že v dnešní době, kdy je zpracování png otázkou použití jedné knihovny je vytváření formátu, jehož parsování každý nějak zbastlí na koleně rozumné. Chápu, že integrovaná komprese může rozbíjet unixový princip, nicméně pokud kompresní algoritmus "rozumí" komprimovaným datům bude vždy efektivnější, než univerzální nástroj (viz. hromady filtrů v png sloužící pro optimalizace). Problém s png může být u nástrojů pro verzování. V případě tak standardizovaných formátů jako je png však vidím jako rozumné řešení plugin pro daný verzovací systém, aby uměl zpracovávat vnitřní strukturu daného formátu a ukládat k němu diff data.

[pavlix]

V případě tak standardizovaných formátů jako je png však vidím jako rozumné řešení plugin pro daný verzovací systém, aby uměl zpracovávat vnitřní strukturu daného formátu a ukládat k němu diff data.

Nebo používat verzovací systém ve stylu Gitu, kde mají rozdíly pouze uživatelskou a optimalizační funkci.

[Sid]

este stastie, ze tento suckless program nezahrnuje aj procesory. na doske by bolo v ramci slavnej UNIX filozofie 45 koprocesorov, vsetko by to bolo pomale ako svina ale ideologicky ciste.

[:::]

... nicméně pokud kompresní algoritmus "rozumí" komprimovaným datům bude vždy efektivnější, než univerzální nástroj ...

tohle bych logicky taky ocekaval, nicmene v tom odkazovanym clanku pisou:

This effectively leads to filesizes you’d normally only reach with paletted images, and in some cases bz2 even beats png’s compression, for instance when you’re dealing with grayscale data, line drawings, decals and even photographs.

Ale mozna to byly nejaky specialne vybrany priklady...

[kralyk z abclinuxu]

To si myslim, že není žádný překvapení, PNG má velmi jednoduchý predikční filtry a pak akorát deflatuje, takže to se celkem dá očekávat, že bz2 to stlačí víc.

[little.owl]

Rada embeded veci pouziva HW dekoder, ktery je zoptimalizovany na JPEG a par dalsich formatu a pokud se pouzije neco jako bz2, treba na telefonu, tak se uzivatel naceka a jeste mu to vymlati baterii.

[Jendа]

nicméně pokud kompresní algoritmus "rozumí" komprimovaným datům bude vždy efektivnější

Já mám nahrávky řeči z FM rádia a bzip2 to komprimuje líp než flac.

[Ovocníček]

Chápu to tak, že někdo navrhl, aby se obrázky uchovávaly v úplně novém, nezaběhaném a nijak na ukládání obrázků optimalizovaném formátu jenom proto, aby se s nimi líp (nebo unixovějc...) laborovalo v skriptech?

To mi přijde jako trochu flusnutí do tváře všem těm chudákům, kteří navrhovali novej, lepší obrazovej formát tak, že měl lepší a pokročilejší funkce, kvalitu nebo kompresi, než ty starší, a stejně s ním neuspěli.

[pavlix]

Chápu to tak, že někdo navrhl, aby se obrázky uchovávaly v úplně novém, nezaběhaném a nijak na ukládání obrázků optimalizovaném formátu jenom proto, aby se s nimi líp (nebo unixovějc...) laborovalo v skriptech?

Já to tak nechápu. Podle mě si někdo jen vytvořil minimalistický grafický formát pro sadu minimalistických nástrojů.

To mi přijde jako trochu flusnutí do tváře všem těm chudákům, kteří navrhovali novej, lepší obrazovej formát tak, že měl lepší a pokročilejší funkce, kvalitu nebo kompresi, než ty starší, a stejně s ním neuspěli.

Oni jsou na flusání do tváře zvyklí a to od mnohem prominentnějších projektů než je suckless.

[mirec]

Mňa na tom najviac pobavilo vyhodenie podpory MNG kvôli veľkosti. V pohode vtrepeme do browsera podporu OpenGL ES, ale malý MNG dekóder sa tam nevojde.

[pavlix]

Tak to bych tipoval na jednu velkou lež. Jediný důvod, proč se bránit začlenění MNG může být strach, že by se ujalo a časem by mohl přijít tlak na odstranění aPNG z důvodu porušování standardu PNG. Klasický případ, kdy si dva subjekty, které by mohly s výhodou spolupracovat, akorát vzájemně hází klacky pod nohy.

[Ovocníček]

aPNG nic neporušuje, ne? Extra snímky normální implementace v souladu se specifikací zahodí a první dekomprimuje jako validní PNG, ne?

[pavlix]

Tak koukám, že druhá edice PNG už se k tomu snad ani nevyjadřuje. Původně bylo součástí specifikace, že PNG reprezentuje pouze jeden obrázek a ne sekvence. Ale je možné, že to jenom nemůžu najít.

[Josef Kufner]

Ano, chápeš to naprosto správně. Však to už máš v názvu projektu. Namísto dělání lepších věcí dělají jen méně špatné.

[Marek]

s/suck/use/g

[HonzaRez]

Kua, já to četl bezdrátový...

[Heron]

V popisu mě překvapilo tvrzení, že bzip2 si umí poradit s obrázky. Čekal bych, že na obrázky jsou v těch formátech speciální algoritmy (stačí se jen podívat kolik metod umí vyzkoušet pngcrush) a že soubory budou menší.

Vyzkoušel jsem to na 1000 screenshotech z jedné hry (Tekkit ).

Původní velikost: 1787MB (nejsem si zcela jist, ale asi je to prohrané přes pngcrush, takže minimální velikost obrázků.)

Dekomprimace do FF (png2ff): nějakých 17GB (některé obrázky mají 18MB, některé mají menší rozlišení a jsou cca 13MB per obrázek).

Komprimace těchto FF na FF.BZ2: 1361MB. Takže lepší výsledek, než optimalizované originály. To je celkem překvapující.

Jenže, těch 1000 obrázků se komprimovalo 3136s (tedy 3.1s per obrázek). To je neakceptovatelné. Sice je to menší (nějakých 76% originálu), ale za cenu značného nárůstu času.

No, potom jsem vyzkoušel ty FF převést zpět na PNG (ff2png), a velikost: 2368MB. (Doba 830s, tedy 0.8s na obrázek). Evidentně z toho lezou silně neoptimální pngčka. Takové originály ani ten MC negeneruje. To se to potom porovnává účinnost.

Takže, sice bz2 komprimuje obrazová data překvapivě dobře (o 24% lépe než optimalizované png), ale za cenu mnohem pomalejšího běhu. Nehledě na to, že to nemá metadata, nepodporuje to jiné barevné prostory, apod. (formát je pevně dán). Takže jako hračka možná dobrý a docela dobře to ukazuje, proč jsou skutečné formáty obrázků přece jen komplikovanější.

---

Samozřejmě, lze to na mnoha místech optimalizovat, místo bzip2 použít pbzip2 (takhle jsem to ostatně dělal, čekat hodinu na 1000img fakt nebudu) apod, tím bychom se dostali na quadcore na nějakých 0.775s per image, jenže stejně tak můžeme pustit konverzi těch png paralelně a dostat se na 0.2s per image. Podle mě to ale za ušetřených 24% nestojí.

[Ovocníček]

Těch 25% by měl na většině dat ušetřit proti PNG i lossless WebP (ale ten je taky o dsot pomalejší), pokud tedy nebude zdrojem nejaký screenshot textu nebo podobný obsah ideální pro PNG (a tedy asi i bzip2).

[mirec]

Ten bzip2 komprimoval každý obrázok samostatne, alebo celý adresár (tar.bz2)?

[Heron]

Samostatně. Viz: http://tools.suckless.org/farbfeld/

[----]

png používá deflate, takže stejný algoritmus, jako zip.

[Heron]

To jo, ale png má před deflate různé filtry a to ještě na různé chunky jiné. Čekal bych, že toto bude optimalizované tak, že výsledek bude menší, než nějaký obecný komprimátor puštěný na bitmapu, která je orientována jen po řádcích a žádné přehazování a odečítání se nekoná.

[Bystroushaak]

On bz2 komprimuje překvapivě dobře i text a XML. Nedávno jsem dělal test, kde jsem komprimoval 1.1MB soubor, lzma / rar a i zopfli se nedostali pod 366kB, bz2 dosáhl 307kB. Stejně dobré výsledky má i u souborů velkých řádově gigabajty, ale čísla už nemám.

[----]

meh, ta externí komprese je spíš velká nevýhoda, protože je nutné dekomprimovat, než se dá přečíst header (takže pokud potřebuju jen přečíst z obrázků nějaká metadata, v tomto případě asi jen velikost, tak musím rozbalit)

kromě toho bz2 komprese je pomalá (oproti deflate) a to, že není daný pevný kompresní algoritmus znamená, že prohlížeče apod. budou muset podporovat všechno.

[pavlix]

meh, ta externí komprese je spíš velká nevýhoda, protože je nutné dekomprimovat, než se dá přečíst header (takže pokud potřebuju jen přečíst z obrázků nějaká metadata, v tomto případě asi jen velikost, tak musím rozbalit)

A nemůžeš prostě dekomprimovat jen tu hlavičku (a případný zbytek bloku)?

[Bedňa]

Toto je len o spôsobe použitia. Inak asi pred rokom som videl testy a až ma pamäť neklame bolo na tomto serveri a vyhrala kompresia 7z. Potom bolo porovnanie txt a iných dát, takže porovnávať technológiu a konkrétny formát je out.

[Roman Došek]

Já ten suckless projekt fakt žeru, podle nich by bylo nejlepší, kdyby všude byl plaintext a všechno bylo strašně jendoduché, ale že je to pro většinu lidí nepoužitelné už je netrápí.

Naprosto mě fascinuje, jak na stránce "software that sucks" odsuzují třeba Firefox protože zle nastavuje TRANSIENT_FOR hint v download dialogu. A jako alternativu nabízejí textové prohlížeče, wow. Jako nemám nic proti textovým prohlížečům, občas používám links když není na výběr, ale doporučovat to někomu? (Firefox nepoužívám, ale tohle už je fakt slušná zabedněnost.)

Pak tam odsazují GCC a Clang (U GCC fair point, ale použitelná alternativa není, a věřím tomu že tihle tajtrlíci ji nenapíšou )

CMake a SCons je pochopitelně taky špatně, nejlepší je přece starý dobrý GNU Make (Aby ne, pro programy složené ze 3 zdrojáků..)

[Bystroushaak]

Pak tam odsazují GCC a Clang (U GCC fair point, ale použitelná alternativa není, a věřím tomu že tihle tajtrlíci ji nenapíšou )

Nemohla by být do jisté míry jako alternativa TCC? Ten by imho jejich ideologickým záměrům vyhovoval.

[Roman Došek]

Jim by možná vyhovoval, ale alternativa (pro reálný svět) to není.

[Jardík]

A zkoušel jsi ten CMake někdy zkompilovat? Stavěl jsem před nějakou dobou cross kompilátor a chroot s musl libc + clang (bez gcc) a říkal si, jak si polepším, že budu mít méně závislostí, než když se pokusím o musl libc + GCC ... a se samotným cmake jsem strávil hromady utrpení, kompiluje se to déle, než kernel. Do té doby jsem si neuvědomoval, co je cmake za nabobtnaný šmejd, který už dávno nenazývám build systémem. Víte třeba, že cmake vyžaduje (nevolitelně) curl a dokáže stahovat a nahrávat data na internet? Já do té doby netušil ... Kompilace GNU Make ... ta je nádherná ... nevyžaduje to snad nic (kompilátor, libc a shell (busyboxí ash funguje). GNU Make podporuje i různé podmíněné bloky apod, takže není potřeba nějakých krávovin. Oproti cmake, zlatý configure skripty z autotools ... a to věřte, že jsem dříve cmake opravdu fandil a autotools jsem pomlouval, jak to šlo. No a potom zkompilovat llvm a clang, to je další porod s tunou dalších závislostí. Mím cílem bylo nemít žádný skriptovací jazyk kromě shellu ... pro self-hosting systém s GCC je ale vyžadován perl (kvůli flexu a bisonu, co potřebujou binutils) a s clang pak navíc potřebujete python. A s tím spojená další halda závislotí.

[Roman Došek]

Jo, CMake je monstrum. Také nikde netvrdím že není. Sám jsem si s ním užil celkem dost legrace, když jsem pracoval s embedded linuxem a potřeboval jsem sestavit některé programy které ho měly jako závislost (např. OpenCV).

A může to být ještě o level horší, třeba takové OpenEmbedded/Yocto/Angstrom s build skriptama v Pythonu.

Jenže reálně ty nástroje v defaultní konfiguraci prostě (většinou) fungují. To že jsou tak nabobtnalé je proto, že toho dělají hodně a že to co dělají není jednoduché. Kdyby bylo tak easy napsat C++ compiler který byl krásně čistý a hebký, tak by jich bylo víc. A není..

A syntaxi makefilů snad vymýšlel někdo na drogách, jinak si to nedovedu ani vysvětlit. Obecně buildsystémy, které používají jako prostředníka makefily mi moc sympatické nejsou. V tomhle ohledu se mi líbí třeba Qbs, ale uznávám že kvůli závislostem to univerzálně použitelné není - a ani to není cíl toho projektu. Ale kdyby bylo něco podobného self-hosted, tak po tom skočím hned.

[little.owl]

A může to být ještě o level horší, třeba takové OpenEmbedded/Yocto/Angstrom s build skriptama v Pythonu.

Mam zkusenost se vsemi tremi a ve skutecnosti mi prijdou lepsi. Python je totiz plnohodnotny jazyk a da se rozumne debugovat. Debugovat nejaky komplexni cross-compile CMake build system je obcas na kulku do hlavy.

A syntaxi makefilů snad vymýšlel někdo na drogách, jinak si to nedovedu ani vysvětlit.

Jsou tam absurdity, portovatelnost nic moc, ale treba Buildroot ci FreeBSD/OpenBSD bsd.port.mk jsou fajn.

[kralyk z abclinuxu]

Python je totiz plnohodnotny jazyk a da se rozumne debugovat.

To je pravda, nicméně ten build nástroj nesmí být úplně zmršený (jako třeba gyp).

CMake má tu výhodu, že se chytil a je pro něj k dispozici spousta modulů na všechno možný. Python bych jako jazyk taky bral víc než ty CMake scripty, ale ono ten frontend jazyk je ve výsledku spíše ta jednodušší část build systému. Některé projekty mají svoje custom python build scripty, které jsou ve výsledku akorát kolekcí pofidérních hacků - to už je pak lepší ten CMake...