Jak sloučit výsledky ze Soble Edge Detection filteru? – Matematika – Fórum – Programujte.com

Ahoj mám dotaz. Tady bylo vysvětleno jak funguje filtr Soble Edge Detection. Píše se tam, že výsledné černobílé obrázky se musí k sobě přidat (add). Není mi ale jasné jak. Myslí tím běžný matematický součet (edit: asi jsem už na to přišel, viz poznámka dole)? Když máme dva výsledky z matice X a matice Y a k tomu souřadnice bodu např. Xx, Xy a Yx, Yy, a jejich intenzity jsou 200 a 200 v tomto pořadí, pak výsledek bude 400 a po opravě 255? Nebo mysleli projet ty dvě matice ve smyčce a porovnat dvě intenzity a zvolit tu, která má vyšší hodnotu. To by mi totiž dávalo více smysl. Dole pod článkem pak jsou odkazy, kde jsem ale odpověď nenašel. Zde je to vysvětleno vzorcem:

Matematické vysvětlení

Jako G = Gx + Gy. Přičemž chápu G jako výsledek po provedení filtru. Gx jako výsledek po aplikování matice X ve směru x a Gy jako výsledek po aplikování matice Y ve směru y.

Dále mám dotaz na ten vzorec pro výpočet úhlu

"The angle of orientation of the edge (relative to the pixel grid) giving rise to the spatial gradient is given by: " (nechápu tu větu)

a vzorec je théta = arctan (Gy/Gx)

A ještě tam je vzorec pythagorovy věty. Zajímá mě co z toho lze vyvodit prakticky. Byl bych schopen a jak to provést - jak změřit tu orientaci? Dejme tomu, že vím, že na obrázku který zachycuje na černém pozadí narysované parcely jsou čísla parcel ... typicky je tam lomítko. Jsem schopen díky tomuto vzorci provést detekci, abych našel to lomítko a potom následně kde začíná a kde končí číslo parcely? Chtěl bych totiž algoritmus, který (během detekce hranic polygonu - totiž parcely) odstraní to číslo. Takže bych chtěl vědět jak bych mohl toho vzorce využít pro případnou detekci toho lomítka a rámečku, který to lomítko ohraničuje.

Poznámka:

Našel jsem další zdroj, kde se to dělá v matlabu a vypadá to, že v tom hlavním odkazu bylo přidáním myšlen zápočet či výpočet podle pythagorovi věty. Tak to tedy řekli hodně špatně tedy nesrozumitelně. Podle matlabu:

 % Calculate magnitude of vector
filtered_image(i+1, j+1) = sqrt(Gx.^2 + Gy.^2);

To konečně dává smysl!

Předchází tomu ale jiný kód kterému nerozumím. Chápu jen že Mx a My jsou matice.

% Gradient approximations
Gx = sum(sum(Mx.*input_image(i:i+2, j:j+2)));
Gy = sum(sum(My.*input_image(i:i+2, j:j+2)));

Takže se tam nějak zázračně provádí to násobení podle (či: "aplikování té") matice.

Ještě by mě tedy zajimalo to praktické využití vzorce pro výpočet úhlu théta. Jako využití v detekci.

Vezmeš pixel a jeho "sousedy", takže máš 3x3 pixely a matici 3x3 definující jejich "váhy". Jednotlivé pixely vynásobíš jejich váhami a ty násobky pak sečteš. A to uděláš pro všechny pixely.

Když se na ty matice/kernely podíváš, tak vidíš, že se stejné (nebo podobné) hodnoty nulují a rozdíly vynikají. Výrazné rozdíly jsou hrany. To je celé.

A když teda máš vertikální a horizontální hrany a chceš je sloučit, tak pro spoustu účelů je stačí normálně sečíst. Ale když je to teda vlastně vektor, tak se nabízí výpočet velikosti toho vektoru. A když máš vektor, tak máš i úhel. Jakoby kterým směrem je ten rozdíl "nejstrmější".  V rámci těch 9 pixelů.

Na tom není nic k přemýšlení. A Matlab umí násobit a sčítat prvky matic, zázrak.

Co se týče toho odstraňování čísel, tak ty nejspíš budou všechny stejným fontem. Takže hrubě vytipovat oblasti, kde by mohly být a pak zkusit jestli tam opravdu jsou číslice.

Původně jsem četl mini studii, která se snaží najít řešení pro lokální změnu kontrastu (a tím pádem změnu levels). Z popisu tam vyplývá, že autor nepoužil převod rozsahu intenzit barev na double, ale použil raději jednoduché omezení rozsahu na 0 až 255, respektive to rozdělil na menší rozsahy hodnot. Já si bohužel ze ZŠ pamatuji už jenom pythagorovu větu. Ale díky Bohu za ní.

Ten úhel théta se tedy taky vypočítává tím, že vezmu poměr jedné intenzity bodu x,y z jednoho výsledku (matice GY) a z druhého výsledku (matice GX) a pak to předám funkci arctan... To mi ale přijde dost neuvěřitelný, že bych mohl spočítat úhel z jednoho bodu x,y - asi jsem to tedy nepochopil. Možná mi uniká teorie kolem toho jak autor Sobelovy detekce okrajů přišel na to, že obraz musí projet dvěma směry. Možná právě výsledž poměr Matic GY a GX je právě tím vodítkem k výpočtu úhlu. Je to vlastně součet vektorů, ne?  Tedy dvou směrů. Něco podobného jako když vítr fouká z jihu a zároveň z východu, výsledný vektor bude jihovýchodní vítr o jiné síle. Snad jdu správným směrem...

No a po přečtení té studie, na kterou odkazuji v tomto příspěvku, taky nechápu jestli autor dělal ten smoothing filter neboli mean filter == averaging filter na ty dvě výsledné matice GX a GY. Nebo jestli to dělal až na ten obraz. Ale spíš to první, jinak by se mu obraz rozmazal.

Tady jsem našel, že opravdu se používá ta pythagorova věta na výpočet těch intenzit:

I'm using this function to compute edge intensities after having done the sobel kernel convolution.

Gxy = sqrt( pow(Gx, 2) + pow(Gy,2) )

Gx is sum of the convolution for the sobel kernel in the X direction and Gy is sum of the convolution for the sobel kernel in the Y direction. (note the sobel kernel in the X and Y direction are different kernels)

Takže opravdu Gx a Gy je něco jiného než jsem myslel, je to ten součet po vynásobení hodnot podle kernelu. Pak mi to myslím začíná dávat smysl, protože ty kernely jsou k sobě kolmo orientované (sloupec nebo řada s hodnotami 0 jsou na sebe kolmo). Takže tím pádem jsou ty dvě matice zároveň vyjádřením úhlu. No zajímalo by mě ještě, kdybych ty matice pozměnil o 45° jestli by byla přesnější detekce šikmých hran. Protože se uvádí, že detekce Sobelových hran je nepřesná na detekci šikmých hran. Když bych například posunul čísla kolem středu o 1 pole proti směru pohybu hodinových ručiček, pak bych dostal pro

kernel Y:

2	1	0
1	0	-1
0	-1	-2

a pro kernel X

0	1	2
-1	0	1
-2	-1	0

V principu jo, když ten kernel otočíš na diagonálu, tak bude detekovat diagonální hrany.

Akorát takhle kolem té diagonály "vzorkuješ trojúhelníky". To nedovedu intuitivně odhadnout, jak se to bude chovat a jestli by nebylo lepší ten kernel zvětšit. Jako takhle:

-1| 0| 1
-2| 0| 2
-1| 0| 1

A pootočit takhle:
  |  |-1|  |
  |-2|  | 0|
-1|  | 0|  | 1
  | 0|  | 2|
  |  | 1|  |

Ale fakt nevím.

Tak se mi ta "hustší" verze zdá lepší.