Názory k článku
Řádkové filtry v PNG

Filtry vypadaji zajimave, vcelku se mi zalibilo, ze se to provadi po jednotlivych pixelech. Jaky je ale vykon?

Nevim jak je to v Xorg vyresene, ale pokud se pixely primo zapisuji do videoram po jednom, tak bude techto zapisu potreba vykonat mnoho a tedy i vykon bude velmi nizky, protoze by se musela pro efektivni vykreslovani pouzit metoda blokoveho zapisu (napriklad po celych radcich). Ted nevim, zda je to skutecne pouzitelne, jak zapsat najednou cely radek?

No, operace typu putpixel() a getpixel() mohou byt obecne dost pomale, viz treba WinAPI funkce SetPixel() a GetPixel() - pomerne inteligentni, ale neskutecne pomale funkce. Vy vsak nemusite pracovat primo z obrazovou pameti, postaci si do bufferu ulozit maximalne dva obrazove radky a na nich tuto filtraci provadet. Pokud by byl v bufferu ulozen cely dekomprimovany obrazek, je naprogramovani putpixel() i getpixel() pro grayscale pixmapy pomerne jednoduche:

//-----------------------------------------------------------------------------
// Zmena barvy pixelu na zadanych souradnicich
//-----------------------------------------------------------------------------
void putpixel(pixmap *p,
              const unsigned int x,             // pozice pixelu v pixmape
              const unsigned int y,
              const unsigned char w)            // barva pixelu
{
    int pos;
    // zde se vyuziva zkraceneho vyhodnoceni vyrazu - pokud plati !p, nic se dale netestuje
    if (!p || !p->pixels || x>=p->width || y>=p->height) return;
    pos=(x+y*p->width);
    p->pixels[pos]=w;
}



//-----------------------------------------------------------------------------
// Precteni barvy pixelu na zadanych souradnicich
//-----------------------------------------------------------------------------
unsigned char getpixel(pixmap *p,
                       const unsigned int x,
                       const unsigned int y)
{
    int pos;
    // zde se vyuziva zkraceneho vyhodnoceni vyrazu - pokud plati !p, nic se dale netestuje
    if (!p || !p->pixels || x>=p->width || y>=p->height) return 0;
    pos=(x+y*p->width);
    return p->pixels[pos];
}

prekladac by nemel mit problemy s "inliningem" techto funkci, pokud ano, staci prepsat do maker.

Dulezite je, ze se jedna POUZE o radkove (resp. "dvouradkove") filtry a to jeste o filtry realizovatelne "zleva-doprava", tj. presne ve smyslu nejrychlejsiho adresovani operacni pameti. Jine usporadani by melo dost podstatny vliv na vykonnost.

dekuji pekne =)

"pro znalce: jedná se o známý obrázek Leny, použitý v mnoha testech algoritmů pro zpracování obrazu, jehož originál můžete vidět například zde."
Jelikož se odkaz nedostavil, přikládám jej zde - na plnou verzi fotky: http://www.lenna.org

Sorry, ten odkaz mi pri prevodu do RedSysu vypadl, diky za doplneni.

Jenom pět filtrů ? Čekal jsem, že jich bude víc a budou i složitější ...

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 :-)

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.

Ten problem s vyberom CRC polynomu sa predpokladam tyka tohoto: http://en.wikipedia.org/wiki/Cyclic_redundancy_check#Error_detection_strength_.28Bitfilters.29

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.

Dobrý den, jestli to dobře chápu, je na každý řádek pixlů obrázku možno použít jiný filtr? Dost bych potřeboval nějáký program, který by vypsal čísla použitých filtrů. Nebo aspoň jak se to zjistí, na kterém je to bytu, nebo tak něco. takže když někdo použije na první řádku filtr 0, na druhou 2 a na třetí zase 0, tak aby mi to vypsalo 0,2,0.
Moc dík.