Počítačová grafika: Konvoluční algoritmus

Bod B[4,4] je aritmetickým priemerom bodov A[3,3], A[3,4], A[3,5], A[4,3], A[4,4], A[4,5], A[5,3], A[5,4], A[5,5], pri matici 3x3. Pri matici, napr., 5x5 by to boli body A[2-6,2-6]. Veď je to jednoduché, len sa toho netreba báť. Na podobnom princípe pracuje aj digitálny zoom.

zoom?? to snad nie.

Hovorím podobnom, nie rovnakom. Veď digitálny zoom je len prepočítavanie farieb a žiadne zvyšovanie kvality detailov. Alebo chceš povedať, že áno.

Co na tom treba vysvetlovat? Treba skusit najprv porozmyslat, niekedy to pomaha.
Ta matica "a1" ti hovori ze ako to budes ratat (co robit so susednymi pixelmi). Vynasobis prislusnym clenom matice a1 kazdy (susedny) pixel (pixel na ktorom momentalne si je akokeby v strede matice a1 a prislusne dalsie cleny matice a1 reprezentuju susedne pixely) a vo vysledku sa to pre kazdy pixel spocita dohromady.
Momentalne mas v matici a1 kazdy clen = 1/9 takze hodnotu vsetkych 9 pixelov (pixel na ktorom si a vsetky susedne) vynasobis 1/9.

P.S. irituju ta asi tie krajne pixely (pri ktorych maska "vycnieva" mimo obraz. To si pozri v tych skriptach ze ako to robili pre krajne pixely, vseobecne hodnoty krajnych pixelov u teba v matici b) sa mi zdaju divne.

Momentalne mas v matici a1 kazdy clen = 1/9 takze hodnotu vsetkych 9 pixelov (pixel na ktorom si a vsetky susedne) vynasobis 1/9.

To asi ne, podívej se na obrázek a. Na ten samotný pixel a co pak z něho vzniklo...(0 * 1/9 není 1). Podle mě je to tak jak píše msx, že se z těch devíti pixelů vypočítá průměr a ten se pak přidělí každému pixelu v rámci matice.

Krajní pixely se můžou řešit třeba fiktivním zvětšením obrázku o jeden pixel z každé strany... Zkusím to na programovat s tím průměrem a uvidím, jak to bude vypadat.

0*1/9 nie je síce 1, ale MM písal niečo iné. Výsledná hodnota pixla je súčet násobkov hodnôt z konvolučnej matice s príslušnými hodnotami tých 9 pixlov v okolí (vrátane samotného pixla). Takže (0 + 0 + 0 + 0 + 0 + 0 + 0 + 0 + 9) * 1/9 = 1.

To, že je to priemer, vyplýva z tej konvolučnej matice (1/9 zo súčtu hodnôt 9 pixlov). Pri inej matici to bude inak (edit: bude to síce stále priemer, ale vážený).

Aha. Tedy pokud to nechci programovat pro obecnou matici, ale pro tu, kde jsou 1/9 vystačím si s průměrem, že?

Áno.

Ved ti pisem ze pre kazdy pixel aplikujes tu maticu na samotny pixel a susedne pixely a spocitas to. Kazdy clen matice a1 reprezentuje jeden susedny pixel (a stred matice reprezentruje pixel ktory prave ratas).
Nemusi to byt priemer, kedze ta matica a1 nemusi mat vsetky cleny = 1/9. V tvojom pripade ma vsetky cleny 1/9 takze to je specialny pripad a tym postupom (scitat pixel*clen matice) ziskas vlastne priemer susednych pixelov (spocitas 9 pixelov a nasobis 1/9 to je priemer). Ale nemusi to byt priemer, algoritmus je vseobecny a zavisi od matice a1.

P.S. samozrejme ze pri ratani krajnych pixelov sa akoze rozsiri obraz (malo by byt o pixely s hodnotou 0), ale v tom pripade je ten vysledok v skriptach chybny na niektorych krajnych pixeloch. Ved si predsa v tych skriptach pozri ako presne je to tam popisane, citat a chapat snad nie je problem (ak ano, tak to mas tazke).
Preto pisem pozri si v skriptach ako sa rataju krajne pixely (ake hodnoty sa pouziju pre tie "akoze novovytvorene precnievajuce" pixely)

Zrovna tato kapitola je v těch skriptech popsána dost divně. Samá matematika... Chtěl jsem jenom slyšet jasný popis algoritmu, prostě něco jako: "Vem pixel na pozici x,y a udělej s ním to a to..." Kdybych já psal taková skripta snažil bych se to vysvětlit co nejpolopatičtěji... Programování těchto algoritmů mě s největší pravděpodobností živit nebude, navíc vím, že už jsou dávno implementované v API Javy, takže pozastavovat se nad tím, je pro mě zbytečné a ztrátou času, bohužel pro dokončení školy, je třeba se v tomhle orientovat...

Chapat matematicke zapisy je nutne nielen v grafike (pravdepodobne tam mas uvedenu nejaku sumu a v nej nejaky sucin dvoch clenov, nie je to nic zlozite len ten zapis treba vediet precitat, co by ta mali naucit na matematike).
Cim sa budes zivit o tom radsej dopredu presvedceny nebud. Orientovat sa vyhradne na programovanie nejakeho GUI v Jave sice je pekne ale nie moc dobry napad, nakreslit GUI v jave zvladne aj stredoskolak. Ked budes robit nieco zlozitejsie (ci uz ekonomicke alebo technicke veci) tak tam budes mat urcite aj matematicke zapisy a bude treba navrhovat zlozitejsie algoritmy.
... a je dobre vediet ako algoritmy funguju, aj keby boli v Jave, aby ich clovek vedel spravne pouzit. A robit napr. graficky editor alebo realtimove spracovanie obrazu v Jave by bolo IMHO dost blby napad.

A robit napr. graficky editor alebo realtimove spracovanie obrazu v Jave by bolo IMHO dost blby napad.

Proč? Myslíš kvůli rychlosti? Metody pro práci s obrázky, které jsou v API Javy jsou vesměs implementované prostřednictvím nativního kódu...

Kvoli tomu ze si obmedzeny tymi vecami ktore tam su, a ostatne veci budu urobene odveci (skrabanie pravou rukou za lavym uchom). Realtime spracovanie obrazu sa nerovna zavolaniu jednej Java funkcie.
P.S. tato diskusia je nepodstatna, cim viac pochopis pocas studia tym lepsie pre teba. Keby som prisiel za sefom s takou otazkou aku si tu zadal tak by na mna hodne divne pozeral. Nejde o ten algoritmus (ja ho tiez v hlave nenosim) ale o pochopenie toho co mas pred sebou a co je na prvy pohlad ocividne. To budes potrebovat kazdy den (hlavne ked zdedis nejaky kod po nejakom debilovi) tak si to trenuj

Tak jsem to nakódil, výsledek je celkem pěkný... Nahoře je původní obrázek, dole po aplikaci konvolučního algoritmu s maticí se samýma 1/9...

Po prečítaní tejto dikusie mám zasa väčší rešpekt k Photoshopu. Veď už ani tento defacto jednoduchý blur som nepochopil :)