Jenom pet a kupodivu ten nejslozitejsi (Paethuv) nedava vzdycky nejlepsi vysledky, spis to jsou primitivni Up a Sub :-) Do hlavy tvurcum PNG nevidim (i kdyz by slo dohledat tu e-mailovou konferenci), ale duvody jsou myslim dva:
1. hodne s navrhem spechali, to je videt i na ne zrovna stastne volbe CRC polynomu. Takze vyber slozitejsich filtru, ktere by byly statisticky lepsi, se nekonal. Urcite ne v takovem rozsahu, jak to udelala CCITT pri navrhu faxovych protokolu, kde jsou zvoleny vylozene statisticke "filtry" (spis sekvence bitu) ziskane z mnoha tisicu dokumentu ruznych typu.
2. chteli co nejdrive funkcni implementace, potom zabihat do slozitych filtru s ruznymi okrajovymi podminkami by znamenalo, ze by spousta aplikaci nezvladala vsechny obrazky. Ze to neni utopie a i takovy SW existuje, je jasne pri pohledu na jeden dosti rozsireny webovy prohlizec :-)
su - \mathfrak{M}ĦĒNJMARCHON (neregistrovaný)
Ked to chapem spravne, tak by nemal byt problem pridat nove filtre (do nejakej buducej specifikacie), aspon par cisel by malo byt este volnych (neviem kolkymi bitmi sa koduju), pripadne nove chunky.
Problem to neni, volnych je 256-5=251 kodu pro filtry. Pokud to budou radkove filtry s dobrym vysledkem (lepsi komprimace), pravdepodobne by se daly prosadit. Radkovymi filtry myslim filtry zavisle tak na poslednich trech-ctyrech radcich, precejen existuji "proudova" zarizeni, ktere maji male buffery a treba sloupcovy nebo dokonce celoobrazovkovy filtr (FFT?, DCT?) by neutahly.
Ja bych zkusil pridat nejake filtry s vystupem ktery nema stejnou sirku jako vstup, pokud to jde ... treba neco, co skutecne "na základě hodnot tří sousedních pixelů vybere ten, jehož barva je nejbližší pixelu zpracovávanému" - protoze Paeth tak nefunguje (taky by v tom pripade musel poznamenat, ktery pixel to je). Podle uvedeneho kodu Paeth predikuje hodnotu pixelu na zaklade tech trech okolo a pote ulozi rozdil mezi skutecnou hodnotou pixelu a hodnotou pixelu, ktery je nejbliz te predikovane hodnote.
Aha, tu vetu jsem nedokoncil, myslel jsem, ze je to jasne ze zdrojaku. Mozna by se neco na zpusob vyberu pixelu mohlo vytvorit, dokonce by se nemuselo hledat pouze na trech sousedech, ale do vetsiho okoli - tim by se (teoreticky) mohla komprimace zvysit, protoze napriklad ctyti pixely vedle sebe, ktere by mely mit stejnou barvu, se mohou vlivem zasumeni trosku zmenit a potom je opravdu vyhodnejsi zaznamenat rozdil (nebo primo pozici - mas zajimavy napad!) trosku vzdalenejsiho pixelu.
Nehlede na obrazky, ktere nekdo predtim ulozil do GIFu a aplikoval na ne dithering, to pouzite filtry ani deflate opravdu moc nerozchodi.