Portál AbcLinuxu, 2. května 2025 09:21
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.
Tiskni
Sdílej:
"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í.
"farbfeld" [šířka] [výška] [data obrázku - RGBA pixely]Jak se to liší od PBM v binárním tvaru?
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.
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.
... 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...
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.
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.
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.
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 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. 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í.
Ten bzip2 komprimoval každý obrázok samostatne, alebo celý adresár (tar.bz2)?
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)?
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íšouNemohla by být do jisté míry jako alternativa TCC? Ten by imho jejich ideologickým záměrům vyhovoval.)
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.
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...
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.