Kinek kell az APNG?

Na, kicsit nyomoztam, ez az APNG tökre felejtős, mert a referencia imlementáció libpng nem tudja és faszkalapok miatt valszeg soha nem is fogja tudni rendesen.

A vicc az, hogy valaki már megcsinálta a libpng-be, másvalaki beküldte issuera (sok-sok évvel ezelőtt), de a png fejlesztők sértett kis primadonna picsákként reagáltak rá.

Aztán, a mostani W3C frissítéssel egyidőben megint megcsinálta valaki, de a png fejlesztők újfent össze-vissza picsogtak és két hete konkrétan használhatatlanságig szétbaszták a már működő kódot (kitörölték az összes szükséges API-t, unknown chunk-ba rakták az APNG chunkokat, azaz teljesen kiherélték és használhatatlan innentől, mert a png_read_image() nem kezeli).

A legviccessebb az, hogy közben önellentmondásos baromságokkal írták tele a saját forráskódjukat, pl mint ez: these chunk names violate the chunk name recommendations because the chunk definitions have no signature. Namármost akárki elolvashatja a specet, és látni fogja, hogy a chunkok nagyon is megfelelnek neki, másrészről nem tudom, mire gondoltak "signature" alatt, de tekintettel arra, hogy az fdAT chunk bitre ugyanaz, mint az IDAT, csak épp van benne egy sequence number is, tutira dettó faszság az egész érvelés, az biztos...

JÓSLAT: gyanítom, W3C nyomására csak bele fog kerülni végül, de biztos jó szar lesz és ott gáncsolják majd a png fejlesztők, ahol csak tudják (különösen ez a jbowler tűnik egy igazi sértődött kis fruskának). Eredmény: marad a GIF meg a WEBP.

ps: kipróbáltam a legfrissebb libpng-t, mást is elkúrtak benne, nem lehet pl. már a text kommentet kiolvasni, mert nem include-olhatod a pnginfo.h-t direktben (amiben a text struct-ja van), csak a png.h-t behúzva meg " invalid use of incomplete typedef ‘png_info’ {aka ‘struct png_info_def’}" hibát dob. Ha ezt kapjuk egy állítólag fullosan támogatott chunk esetén, mégis mire számítsunk egy olyannál, amire még fújnak is...?

Fussunk neki mégegyszer.

akinek kell használja

Hogy? A referencia libpng-be most sem működik, mert szándékosan szabotálják (két hete még ment!).

a többi hasonló az mind veszteséges

Nem igaz, ott a WEBP kétféle codec-kel:
- JPEG-ből lopott kód, YUV, csak állókép, veszteséges CDT alapú
- PNG-ből és GIF-ból lopott kód, RGB(A), veszteségmentes, ez lehet állókép és animáció is.
Hogy lopott kódról van szó, az nem vitás, ugyanis a kétfajta codec esetén eltérően tárolódik a kép mérete pl. (veszteségesnél pont úgy, mint JPEG-nél, prefixált adat, veszteségmentes esetén meg mint a PNG esetén, fix offszeten). Ha saját kód lenne, akkor kizárt, hogy kétféleképp tárolnák a méretet, és hogy csak az egyik codec esetén tárolnának több frame-t. De mindegy, a lényeg, hogy csak veszteségmentes tömörítés esetén tudja az animációt.

sose szabad egy formátum vagy szoftver hasznosságát vitatni

Pedig vitatható, újfent megkérdezem, hogyan kellene egyáltalán használni, ha a referencia libpng-ben szándékosan szabotálják?

Milyen hasznossága van egy olyan formátumnak, amit nem tudsz menteni a programodból, csak lejátszani? (Ha nem lenne világos, a parancssoros tool nem képes képet ténylegesen menteni, az csak PNG chunkokat lapátol dekódolás és enkódolás nélkül, úgy állít elő APNG-t meglévő PNG-kből. Hasznos tool, hasznos, de nem beágyazható ez a megoldás egy olyan programba, ahol direktben kellene APNG-t menteni.)

a saját felhasználási körödet kivetíteni, ha neked haszontalan, akkor azt feltételezni, hogy mindenkinek az lesz

Nem ártana megtanulnod olvasni és leszokni arról, hogy másokról feltételezed, mit gondolnak. Ugyanis TÉVEDSZ, mint mindig.

Veled ellentétben én SOSEM vetítettem ki, sem korábban, sem most ennél. És nem is feltételeztem. Nem is tudom, honnan szoptad ezt. Sőt, itt most épp használni akarnám, csak hát nem lehet, mert nyista támogatás. A sourceforge-os libpng-apng nem hivatalos és le van maradva a patchekkel jócskán, a mozilla-apng meg csak lejátszó könyvtár, menteni nem tud. A Pillow az python és nem natív, az stb_image_write nem tud APNG-t, stb. stb. stb. Jelenleg nincs natív kódra forduló lib (a libpng-nek kellene annak lennie, ugye).

A kérdésem az (nem feltételeztem, kérdezek!!!), ha az embereknek nem köll ez, akkor szarok bele, és nem szenvedek azzal, hogy én magam megpaktoljam a libpng-t, míg ha köll, akkor workaroundolom valahogy. Csak hogy egy nyelvet beszéljünk, miről is szól ez a topik.

ez a baj, mikor nem új szabványokat hoznak, hanem meglévőket foltozgatják tovább toldatokkal. Nevezetesen az, hogy egyes implementációk nem mindent fognak belőle támogatni.

Csakhát itt most egyáltalán nem erről van szó. Itt az van, hogy egy 30 éves specifikációt emeltek be az alap specifikációba. Ugyanakkor az implementációját nem akarja pár faszcsimbók berakni a referencia libpngbe (pedig létezik az is, 30 éve, és teljes támogatású). Tudtommal a többi saját implementáció meg mindent tud (pl. Pillow), nincs velük kompatíbilitási probléma.