Vlákno názorů k článku
GIMP chystá nový formát na bázi XML, náhradu za XCF od radekm - To bude zase pomalé. Nechápu, proč si nevyberou...

To bude zase pomalé. Nechápu, proč si nevyberou binární formát, který jde efektivně parsovat, ideálně pomocí SIMD instrukcí. Nebo formát, co se nemusí parsovat vůbec a jeho načtení odpovídá přímo strukturám v paměti.

Nechápu, proč si nevyberou binární formát, který jde efektivně parsovat, ideálně pomocí SIMD instrukcí.
Protože parsováním se stráví zlomek času a u formátu jsou podstatně důležitější věci, než rychlost parsování.

Nebo formát, co se nemusí parsovat vůbec a jeho načtení odpovídá přímo strukturám v paměti.
Tím už si všichni prošli před desítkami let a zjistili, že je to peklo.

> u formátu jsou podstatně důležitější věci, než rychlost parsování.

A co třeba?

Třeba možnosti zpětně kompatibilního rozšíření formátu (nové funkce se ignorují, ale zbytek je zpracovatelný).

Ale to přeci jde i v binárním formátu, co se rychle parsuje. Důkazem jsou již existující formáty obrázků.

A jde to třeba i u C struktur, které můžu rozšiřovat a starý kód, který očekával struktury s méně fieldy stále funguje - jen prostě nečte ty další fieldy.

Struktury v paměti narazí hned při přechodu mezi little- vs. big-endian, jiným ABI pro padding nebo při jiné délce intu mezi platformami. Navíc se typicky nedají zpracovat jako stream a musí se načíst celé.

Binární strukturovaný formát by byl fajn. Ale na XML existuje spousta nástrojů a jestli GIMP už XML používá, tak jde o "malou" změnu oproti ostatním možnostem.

A kolik platforem je dnes big-endian? Číselné typy pak můžete zvolit s konkrétní velikostí a padding i alignment ovlivnit.

Nechápu, proč si nevyberou binární formát,
Jen to ne, pak bude chtít uživatel něco upravit mimo gimp a bude muset mít specializované nástroje místo "hloupého" nahrazení textu. Nehledě na dopřednou kompatibilitu (v textu je jednodušší ignorovat neznámé fieldy než ve špatně navržené binární struktuře). Navíc je třeba o dost větší pravděpodobnost že takové LLM bude daný formát chápat z dokumentace aniž by se musel dělat nějaký specializovaný MCP server který ji to bude překládát. Za mě binární formáty jsou hezké, ale tam kde je třeba opravdu optimalizovat. Ale v době kdy téměř všichni uživatelé doma mají kompy jejichž výkon ztěží dokážou využít mě to přijde jako optimalizace jen aby se mohlo říct že to je super-optimální bez nějakých extrémních přínosů pro koncáky (ještě navíc při načítání a ukládání souboru -- kolikrát to uživatel dělá?).

19. 8. 2026, 13:11 editováno autorem komentáře

A kolikrát to uživatel edituje mimo GIMP? Očekávám, že méně často než ukládá a načítá v GIMPu.

Uzivatel malo, ale softwaru co nyni umi nacist XCF je celkem dost. V pripadne binarnich dat se takovy format hur siri, protoze se hur implementuje do jineho softwaru (narozdil od XML parseru).

Hodně záleží jaký binární formát zvolíte. On to nemusí zrovna být ručně psaný a s ničím nepodobný bordel. Máme i moderní strukturované binární formáty.

Já jsem takhle opravoval bakalářskou práci, kde se OpenOffice rozhodl, že vše od stránky 12 dál bude v poznámce pod čarou. Naštěstí to bylo právě XML v ZIPu, takže jsem přesunul konec jednoho tagu na správné místo. Kdyby to byl binární formát, třeba DOC, nezbylo by mi nic jiného, než vyexportovat text jako čistý text a naformátovat to celé znovu, včetně vkládání obrázků, grafů, tabulek, citací, poznámek pod čarou apod. Protože v programu s tím nešlo hnout, když jsem kus vyjmul do schránky a chtěl sem ho vložit zpátky do hlavního toku dokumentu, jenom z toho vyrobil další poznámku pod čarou.

Je to extrémní příklad, ale prostě jsou situace, kdy jste rád, že na ten soubor můžete sahat běžnými a spolehlivými programy, protože nativní aplikace něco neumí, nebo něco pokazila.

Grafici načítají a ukládají velké soubory s mnoha a mnoha vrstvami poměrně dost často.

A datový formát GIMPu bude stejně binární. Bude to pravděpodobně archiv komprimovaných XML metadat a vektorů + binárních bitmap.