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

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.

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

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.