[Alg] meest bezochte coordinaat van plaatje vinden *

[Koffie]

OK, ik ga proberen dit zo duidelijk mogelijk uit te leggen, want ik weet dat ik nu eenmaal vage gedachtenkronkels hierover heb

Ik heb een plaatje, dat plaatje wordt uit een DB gehaald en allemaal bijgehouden enzo. Niets bijzonders dus.

Nu heb ik die image in een form gegoten en het plaatje gebombardeerd tot een INPUT IMAGE TYPE

Op deze manier krijg ik de X/Y coordinaten van klikken binnen.
Deze sla ik op in een DB.
Tot nu toe allemaal heel simpel.

Wat ik echter wil, is op de een of andere manier voor elkaar krijgen dat ik het meest aangeklikte gedeelte van het plaatje kan bereken.
Dit hoeft uiteraard niet tot op de pixel zijn, maar mag gewoon een 'area' binnen het plaatje wezen.

Probleem is dus, hoe bereken ik het meest aangeklikte gedeelte

De optie om vantevoren zelf al een soort areas te defineren is eigenlijk niet echt een oplossing voor mij.

Wie o wie weet in welke richting ik het moet zoeken ?

[Verwijderd]

Areas afgebakend met wat voor geometrie?
Vierkanten/rechthoeken is natuurlijk niet moeilijk, en uitvinden of-ie in welke circel ligt natuurlijk ook niet. Willekeurige polygonen is alweer ietsjes lastiger bijvoorbeeld. Splines nog lastiger.

Mijn oude 3D engine stikt van de in/out tests, dus daar zit vast wel wat bruikbaars tussen als ik 't platsla naar 2D.

[ Voor 26% gewijzigd door Verwijderd op 31-10-2003 14:49 ]

[Verwijderd]

je kunt toch simpel een grafiekje genereren met de coordinaten met de meeste hits?

[Koffie]

Verwijderd schreef op 31 oktober 2003 @ 14:48:
Areas afgebakend met wat voor geometrie?
Vierkanten/rechthoeken is natuurlijk niet moeilijk, en uitvinden of-ie in welke circel ligt natuurlijk ook niet. Willekeurige polygonen is alweer ietsjes lastiger bijvoorbeeld. Splines nog lastiger.

Mijn oude 3D engine stikt van de in/out tests, dus daar zit vast wel wat bruikbaars tussen als ik 't platsla naar 2D.

Wil je niet van die gekke termen gebruiken

Het gaat dus om een (laat zeggen) vierkant plaatje.
Binnen dat plaatje mag je klikken waar je wilt.

Deze info wordt opgeslagen, en vervolgens de waarden bijelkaar geraapt om te kijken waar de meeste kliks bij elkaar in de buurt liggen.

[Renegade]

Als je de X en de Y waardes opslaat tel je toch gewoon het unieke aantal waardes en kijk je welke het meest voorkomt?

[Koffie]

Dat zou zo kunnen zijn, waren het niet dat de kans nihil is dat een 2e persoon op exact dezelfde pixel zal klikken

[Renegade]

Dan moet je ranges gaan opstellen. Iets als:

code:

SELECT count(*) FROM aantallen WHERE x<=10 AND y<=10

En die resultaten sla je op.

Of is dat ook geen mogelijkheid?

[ Voor 4% gewijzigd door Renegade op 31-10-2003 15:03 ]

[dusty]

Het ligt eraan precies hoe fijn je het berekend wilt hebben. In principe ga je zoeken naar een vierkant waar de meeste kliks in zijn gevallen.

Uiteindelijk is de makkelijkste oplossing alle geklikte punten doorlopen en kijken hoeveel andere kliks eromheen zijn gedaan binnen een x-marge en y-marge. Of je kan natuurlijk ook een radius nemen om de punt te bepalen in een cirkel.

Het hangt hier gewoon teveel af van wat je EXACT wilt hebben. Je zou ook de zwaarte kunnen berekenen van elke punt, dat betekent dat je alle punten doorloopt en dan gaat kijken hoever alle andere punten liggen, punten dichtbij zorgen voor een hoge "zwaarte" verdere punten voegen minder punten toe, waardoor je uiteindelijk een punt krijgt met de hoogste waarde, dat zou je dan als de zwaarste punt van je plaatje kunnen beschouwen.

Je zult dus eerst exact moeten bepalen wat je echt wilt hebben

[Verwijderd]

mm, heb hier nog wel ergens een stukje code voor gemaakt, zal het eens opzoeken

[Koffie]

heel graag

[McVirusS]

Ik kan me topic herinneren van heeeeeeel lang geleden in W&G daar had iemand de klikcoordinaten opgeslagen van een banner waar een vrouw op stond. Die coordinaten had hij vervolgens uitgelezen in Flash geloof ik en het gedeelte waar het meest geklikt was werd rood...je raad nooit waar het meest geklikt werd .

<!-- tepels dus..geloof ik, is echt al lang geleden -->

[Verwijderd]

Stel, we hebben een plaatje van een mooie schaars geklede dame, en we willen uitzoeken hoeveel tweakers er tietenmannen zijn, en hoeveel er kontjeliefhebbers zijn. Dan moeten we die gebieden afbakenen om kliks erop te vinden. Een simpele 'tiet geklikt als x>10 && x<50 && y>10 && y<50' test werkt dan niet.

een of meerdere circels zijn dan eventueel makkelijk (Xc,Yc: middelpunt circel, Rc is radius circel):
bCircleHit = sqrt((xclick - Xc)*(xclick - Xc) + (yclick - Yc)*(xclick - Yc)) < Rc;

De sqrt (sloom) werk je uiteraard eruit door te vergelijken met Rc*Rc. Dit zou je direct in een SQL query kunnen doen.

Dan kunnen we nog vergelijken met een polygon (=veelhoek) gedefinieerd door een array van hoekpunten. Een driehoek? 3 hoekpunten. Een vijfhoek? 5 hoekpunten. Maar dit is ingewikkelder

[Janoz]

Maak een 2d array die net zo groot is als het orginele plaatje. Vul hier de voorkomens in (als er 5x op positie (10,21) is gedrukt komt daar dus 10 te staan). Schaal de uiteindelijke waarden op een range van 0 tot en met 255. Maak hier vervolgens een plaatje van. Als dit plaatje te spikkelig is doordat er te weinig op is gedrukt haal je een paar keer een gausian blur overheen tot je het gewenste effect hebt.

(Het schalen is trouwens ook te doen met een contrast stretch. Dat is hetzelfde, maar is ook makkelijk met photoshop te doen. Hierdoor hoef je alleen maar een simpel grijswaarden plaatje te genereren)

[ Voor 20% gewijzigd door Janoz op 31-10-2003 16:20 ]

[curry684]

Mag ik vragen waarom dit in CA staat en niet in P&W?

[Koffie]

Mag ik vragen om een move ?

[Verwijderd]

ik kom nooit in P&W.

Heer van het Zwarte Goud, wat zijt gij nou eigenlijk precies van plan?

[Renegade]

Move --> P&W

[Koffie]

OK, ik zal het nogmaals proberen uit te leggen.

Ik heb een random plaatje, welke dus elke keer anders is, zowel kwa afmetingen als inhoud.
Via genoemd formpje krijg ik de X en Y coordinaten binnen en worden opgeslagen in een DB.

Nu wil ik dus op een gegeven moment berekenen wat de 'hotspot' is , waar wordt er op het plaatje het meeste geklikt.

Dat hoeft echt niet tot op de pixel nauwkeurig, dat mag best een stuk zijn van ca. 60*60 of zelfs 120*120

Ik doe PHP pielen gewoon voor de hobby, dus oplossingen met 2D en 3D modellen zullen misschien wel werkbaar zijn maar daar snap ik simpelweg geen jota van

[DRaakje]

Waarom genereer je niet een plaatje waarbij je elke pixel die wordt geklikt een kleurtje geeft. En dan kan je als je wilt nog werken met kleurgradienten als er vaker op 1 plek wordt geklikt...

[Yoeri]

sla gewoon de exacte X en Y coördinaten op

vervolgens plot je die op een grafiek en zul je visueel een gebied zien met een grotere concentratie aan punten

met statistische formules kun je vervolgens wel een mediaan, gemiddelde, verwachtte waarde, standaardafwijking, ... berekenen

Het gebied dat jij zoekt is dan ruwweg gezegd een cirkel met middelpunt = verwachtte waarde en straal = standaardafwijking
?

[ Voor 19% gewijzigd door Yoeri op 31-10-2003 17:03 ]

[Verwijderd]

Als je het plaatje nu opdeelt in vakjes van bijv (zoals je zelf zegt) 60px.

Dan ga je tellen in wel stukje het meest geteld is, dan zal je groepen moet en maken per vakje.
Of te wel voor elk vakje gaan tellen ( query uitvoeren ) hoeveel keer daar geteld is.
Bijv voor vakje A1:

code:

SELECT COUNT(*) AS kliks 
FROM table 
WHERE ( x BETWEEN 0 AND 60 ) 
AND ( y BETWEEN 0 AND 60 )

En met dat lijstje kan je zien wat er het meest aangeklikt is.

_{Zover is kon zien was dit nog niet zo ge-opperd}

edit:
Wel dus

[Yoeri]

De optie om vantevoren zelf al een soort areas te defineren is eigenlijk niet echt een oplossing voor mij

Zover is kon zien was dit nog niet zo ge-opperd

[Renegade]

Als je nu eerst de grootte van het plaatje ophaalt met getimagesize. Daarmee los je het probleem op dat je niet weet hoe groot je plaatje is. Vervolgens baken je vlakken af van 25 bij 25 pixels bijvoorbeeld. Valt een click dan binnen 0,0 en 25,25 dan sla je voor dat gebied een click op. Hetzelfde geldt als een click valt tussen 25,25 en 50,50, of bijvoorbeeld 25,50 en 50,100.

code:

100_________________________
|      |        |       |
|      |         |      |
|      |         |      |
|      |         |      |
50------|---------|--------|
|     |      |      |
|      |         |      |
|      |         |      |
|      |         |      |
25----25,25-------|--------|
|      |         |      |
|      |         |      |
|      |         |      |
|      |         |      |
-------25--------50------100

Dat is trouwens niet de meest elegante oplossing. Een andere manier zijn om met cirkels te werken waarbij je uitgaat van het middelpunt van de cirkel, je opgeeft hoe groot de cirkel is, en kijkt naar het aantal clicks dat binnen dat gebied valt. Je probleem is dus meer van wiskundige aard dan iets anders, maar er zitten genoeg wiskundige functies in PHP om je verder te kunnen helpen. De truuk is nu alleen om de goede functies te vinden.

_{Layout is een bitch in code tags}

[ Voor 2% gewijzigd door Renegade op 31-10-2003 17:22 . Reden: Kleine verduidelijking ]

[Jurgle]

Mijn idee voor een oplossing:

Je weet de aangeklikte x en y coord. Je weet ook de maxX en maxY van het plaatje. Dan kan je x/maxX en y/maxY uitrekenen. Dan neem je het probleem weg van de verschillende afmetingen van plaatjes.

Daarna lees je al die delingen uit en genereer je met de GD een plaatje waarmee je bijvoorbeeld as basis blauw neemt en elke klik op een pixel wordt de betreffende pixel iets meer rood.

Je krijgt dan zoiets:


Je ziet dat er in het midden iets van een advertentie gestaan zal hebben en linksonder 'klik hier'...

[Erik Jan]

Mooiste oplossing IMO:

-Verdeel je bitmap naar eigen inzicht in vlakken. Hoe meer vlakken je hebt, hoe meer detail je zal hebben in je stats. Dit verhoogt echter je load wel drastisch. Ik ga gewoon uit van 1 pixel = 1 vlak in dit voorbeeld.
-Maak een table van (hoogte*breedte) records, met als kolommen X,Y en Aantal.
-Doe per klik op (X,Y) in je DB gewoon (Aantal += 1).
-De stats genereer je als volgt: maak bijvoorbeeld met GD een plaatje van grootte (X,Y). Neem Max(Aantal). Aan de hand daarvan ga je je plaatje "inkleuren":

code:

sql(select X,Y,Aantal from tabel)

foreach (result) {
  a = Aantal / Max(Aantal) * 255
  kleur = ImageColorAllocate(img, a, a, a)
  ImageSetPixel(img, X, Y, kleur)
}

Zo krijg je dus een duidelijke graphic die je, als je wilt, over je originele bitmap heen kan leggen (achtergrondkleur wit, schroef alpha van originele bitmap terug, kies afwijkende kleur voor "screen" en leg die eroverheen etc.) zodat je duidelijk kan weergeven wat de hotspots zijn.

//laat: hmm, ik moet geen schermen open laten staat zie ik wederom.

[ Voor 5% gewijzigd door Erik Jan op 31-10-2003 17:55 . Reden: laat... ]

[Yoeri]

Ehm... iedereen komt hier maar met voorgedefinieerde vlakken aandraven terwijl de TS al aangaf dat niet echt te willen

Bovendien zou je in dat geval met overlappende vlakken moeten werken om randgevallen te elimineren

0 -> 50, 25 -> 75, 50 -> 100, 75 -> 125
vervolgens een klik op 49 meetellen voor het interval 25 tot 75, maar een klik op 26 meetellen voor 0 tot 50... zo elimineer je de gevallen waar alle kliks zich rond de 50 situeren en je dus met twee areas zit die veel kliks hebben

Persoonlijk zou ik dit met statistiek oplossen... lijkt me het eenvoudigst, alleen wat wiskundiger

@jurgle, mijn excuses, had je oplossing verkeerd begrepen

[ Voor 7% gewijzigd door Yoeri op 31-10-2003 18:22 ]

[Jurgle]

De oplossing die ik gaf werkt toch niet met voorgedefinieerde vlakken?

Er wordt gewerkt met steeds verschillende afbeeldingen.

Randgevallen blijf je altijd houden en je kan deze wiskundig bij het 'ene vlak' tellen of bij het 'andere vlak' maar je kan ook zelf ongeveer een grens beslissen, zo ben je niet aan rechthoeken gebonden. Zie reactie #23

[ Voor 14% gewijzigd door Jurgle op 31-10-2003 18:21 ]

[Emmeau]

Heb hier een tijdje over na lopen denken, vind het een interessant iets in ieder geval.

Ik denk dat je 'vlekken' moet gaan uitrekenen, waarbij het begrip 'vlek' (of area) eerst gedefinieerd dient te worden natuurlijk.

De definitie kan een vlek iets zal zijn als:

a) Minimaal X pixels
b) Noem de afstand tussen een pixel en zijn dichtsbijzijnde buur A.
Door A een waarde te geven, kunnen de pixels opgedeeld gaan worden in vlekken.

Leuke is, als iemand per ongeluk 1 keer geklikt heeft waar niemand anders ook maar in de buurt geklikt heeft, kan door X is 3, dit soort 'foutjes' eruitgefilterd worden.

Denk dat je door het spelen met deze parameters wel wat kan bereiken.

uiteraard natuurlijk altijd 'relatieve' coordinaten gebruiken, zoals al eerder is besproken .

Hmm, dat kan best nog wel eens heftig rekenwerk worden.

Heb je ideeen over hoeveel kliks je verwacht?
Kun je uitspraken doen over de verdeling van klikken op plaatjes?

[ Voor 13% gewijzigd door Emmeau op 31-10-2003 18:29 ]

[Soultaker]

Ik vind de suggestie van Jurgle toch echt het meest geschikt (ik zat er eerlijk gezegd al op te wachten toen ik de thread doorlas). Het levert de meest veelzeggende plaatjes op, lijkt me. Het is wel een hoop rekenwerk: per pixel moet je de intensiteit berekenen (en die stel je dan bijvoorbeeld gelijk aan de gemiddelde afstand naar alle pixels). Vervolgens verzin je er een mooie gradient bij.

[.oisyn]

Ik zou het probleem opdelen in 2 deelgebieden. Allereerst ga je even alleen uit van de x-coordinaten van de punten. Daar sorteer je ze op, en vervolgens ga je zoeken naar groepjes. Dat zoeken naar groepjes kun je denk ik het best doen door steeds te kijken naar de afstand (in horizontale richting dus) tussen de punten. Dit geeft een soort afgeleide, met dalen die overeen komen met groepen. Als je steeds de minima opzoekt, dus daar waar de afstand tussen 2 punten het kleinst is, en dan aan beide kanten naar buiten beweegt tot de afstand boven een bepaalde grens komt, dan dun je dat gebied afbakenen als groepje. Dit doe je tot je alle groepen hebt gevonden.

Vervolgens ga je, voor elk groepje afzonderlijk, hetzelfde proces nog een keer doen, maar dan in de y-richting. Als je dit gedaan hebt dan heb je dus alle clusters van pixels gevonden. Om die clusters kun je dan nog evt. een bounding area berekenen. Dit kan simpelweg een rechthoek zijn (minimale en maximale x en y coordinaten opzoeken), of een zo klein mogelijke cirkel (vindt de 2 punten met de meeste afstand, deze punten liggen dan tegenover elkaar op je cirkel), of een polygoon (met een convex hull algoritme)

.edit: trouwens de titel maar even gewijzigd naar Alg ipv PHP

[ Voor 3% gewijzigd door .oisyn op 31-10-2003 18:38 ]

[SuperRembo]

Als je er een leuk plaatje van wil maken dan zou kunnen tekenen met een brush- in plaats van pencil-tool. Dan vlakt het een beetje uit. Als je eerst "tekent" in een matrix dan kan je het resultaat netjes normaliseren.

Gemaakt in met php met random input (100 klikken):
Pencil versie:

Brush versie:

[PanMan]

Ik kreeg inspiratie door je post
En ik heb ook een vraag: Wat wil je met de gegevens? Wil je het meest geklikte deel tonen oid? Ik heb iig een beetje zitten spelen met PHP en GD, met dit als resultaat:
http://panman.nl/temp/linetest.php

Het linker plaatje toont je laatste klik, het rechter houdt al je clicks bij in een sessie, en toont ze dus met rondjes. Heb je iig. een indicatie waar het meest geklikt wordt. Uiteraard kan je het oorspronkelijke plaatje daarachter zetten, om te vergelijken. Oid.
Dit werkt dus compleet zonder berekeningen op de data, het toont het alleen.
Als je een gebied wilt definieren, zal je het anders moeten doen.
(b.v. voor elk punt de afstand tot elk ander punt bepalen, dan kan je ze daarop sorten, oid).

[Cavorka]

Heel erg netjes PanMan.

Zit alleen een foutje in: op (0,0) van het middelste plaatje zegt hij dat ik geklikt heb, dat is niet zo!

@SuperRembo: Tekenen met een brush? In GD? Ik heb iets dergelijks geprobeerd te doen, maar dat is niet echt eenvoudig en werd bij een beetje brute forcen, wat mijn parse tijden niet ten goede kwamen (was voor een simulatie'tje).
Hoe heb jij dat precies gedaan?

[ Voor 17% gewijzigd door Cavorka op 01-11-2003 11:13 ]

[PanMan]

Jah, okee. De eerste keer dat je hem laad zijn X en Y nog niet gedefineerd, en dus zijn ze 0, dus denkt hij idd dat je de eerste keer daar hebt geklikt.
Maar dat kan er natuurlijk zo uit.

[SuperRembo]

Cavorka schreef op 01 november 2003 @ 11:07:
@SuperRembo: Tekenen met een brush? In GD? Ik heb iets dergelijks geprobeerd te doen, maar dat is niet echt eenvoudig en werd bij een beetje brute forcen, wat mijn parse tijden niet ten goede kwamen (was voor een simulatie'tje).
Hoe heb jij dat precies gedaan?

Ik wilde er voor zorgen dat de niet geklikte pixels zwart worden, en de meest geklikte pixel(s) wit (dus niet grijs afhankelijk van het aantal klikken). Daarom heb ik de berekening in een matrix (array van arrays) gedaan, wat erg beroerde parsetijden oplevert.
Voor elke pixel met 1 of meer klikken verhoog ik de waarde van de pixel evenredig met het aantal klikken. De omringende pixels worden minder verhoogd afhankelijk van de afstand tot de pixel.
Daarna bepaal je de maximale waarde in de matrix. Die heb je nodig om het kleurverloop goed te krijgen.
100 klikken, "brushgroote" 1/11/21/31

[MSalters]

Als je plaatje echte afzonderlijke gebieden heeft, dan zijn er algoritmen die die gebieden zelf vinden. Zo'n algoritme wijst elke klik dus aan een gebied toe. Vervolgens kun je simpelweg turven welk gebied de meeste punten heeft gekregen. Dat gaat dus ook goed als je een grote en een kleine button heeft, je loopt dan niet het risico dat een vooraf vastgestelde grens een button in tweeen knipt.

Het idee is als volg. Je begint met N punten. Die verdeel je over N gebieden. Vervolgens voeg je telkens de twee gebieden samen die de kleinste onderlinge afstand hebben. De eerste stap is dus een gebied maken met de twee dichts bij elkaar staande punten.
Er zijn een paar varianten, hoe je de afstand tussen twee gebieden meet en wanneer je stopt zijn de belangrijkste keuzes.

[Koffie]

Phoe, hoop replys in 1 weekend (heb tijdelijk geen inet thuis) ga het eens doorlezen allemaal.
Probleem is, er zitten idd best bruikbare oplossingen tussen echter ben ik bang dat dat veel te hoog gegrepen is voor mij.

Ik snap al het wiskundige gedeelte niet zo echt van alle voorbeelden
Daarom snap ik bijvoorbeeld ook niet echt wat in het voorbeeld van Jurgle het delen van de geklikte waarde door de maxwaarde voor nut heeft.

Wel bedacht ik me daardoor ineens dat ik wel idd een plaatje ervor heen kan leggen, en dan elke geklikte pixel brushen.
Als er dan (heel simpel gezegd) 4 pixel rond elkaar liggen zullen de 4 brushes elkaar overlappen en dus een grotere brush geven.

[ Voor 5% gewijzigd door Koffie op 03-11-2003 08:50 ]

[Janoz]

SuperRembo schreef op 01 november 2003 @ 12:32:
[...]
Ik wilde er voor zorgen dat de niet geklikte pixels zwart worden, en de meest geklikte pixel(s) wit (dus niet grijs afhankelijk van het aantal klikken). Daarom heb ik de berekening in een matrix (array van arrays) gedaan, wat erg beroerde parsetijden oplevert.
Voor elke pixel met 1 of meer klikken verhoog ik de waarde van de pixel evenredig met het aantal klikken. De omringende pixels worden minder verhoogd afhankelijk van de afstand tot de pixel.
Daarna bepaal je de maximale waarde in de matrix. Die heb je nodig om het kleurverloop goed te krijgen.
100 klikken, "brushgroote" 1/11/21/31
[afbeelding]

Dat verhogen van de omliggende pixels is een morphologische operatie. Tijdens mijn afstuderen heb ik gebruik gemaakt van een bewijs dat bewijst dat een convolutie met 1 zo'n 'bobbel' over het spikkelplaatje hetzelfde resultaat oplevert als voor elke klik een bobbel neerzetten. In dat geval maakt het qua snelheid niks meer uit waneer je de brushgrootte aanpast. Die werkwijze heb ik al veel eerder in het topic 'in photoshop acties' uitgelegd.

[Cavorka]

De methode die Superrembo toepastte heb ik ook gebruikt (zie: de brute force referentie), en dit werkt zeer goed maar als gezegd: het is echt een killer voor je parse tijden.

@Janoz: Ik begrijp je reply niet helemaal... Hetzelfde resultaat? Wat is precies hetzelfde resultaat, als wat? Het resultaat is niet hetzelfde voor elke brush.
En een convolutie van 1 'bobbel'? Ik ben nou niet echt een wiskunde leek, maar zou je het misschien anders kunnen uitleggen (ik wil het graag begrijpen (interessant namelijk)! ) Wat versta je precies onder de operatie 'convolutie over 1 bobbel over het spikkelplaatje'?

Bedoel je zoiets als: het integreren over een som kan hetzelfde zijn als een som over een integratie? Iets in die trend?

[ Voor 22% gewijzigd door Cavorka op 03-11-2003 12:14 ]

[chem]

Waarom plot je het niet in een 3D grafiek in excell, of jdgraph?
x: x
y: y
z: frequentie

[SuperRembo]

Cavorka schreef op 03 november 2003 @ 12:11:
De methode die Superrembo toepastte heb ik ook gebruikt (zie: de brute force referentie), en dit werkt zeer goed maar als gezegd: het is echt een killer voor je parse tijden.

Als je eenmaal een flinke hoeveelheid klikken hebt (zeg 100+), dan zijn de wijzigingen als gevolg van 1 extra klik miniem. Je kan het plaatje dus makkelijk cachen.

[Janoz]

Een convolutie is een operatie op een plaatje. Je neemt een footprint (klein plaatje) en 'vermenigvuldigd' deze met het orginele plaatje. Dit betekent dat op positie x,y de footprint wordt geplakt. De grijswaarden van de footprint worden eerst vermenigvuldigd met de grijswaarde op positie x,y. Het komt er op neer dat je elke pixel in je bron vervangt door een vlek in je doel.

Bij het voorbeeld van superrembo wordt bij elke klik de vlek geplaatst. Bij mijn voorbeeld worden eerst de pixels gezet en pas aan het eind de bobbels geplaatst. Mijn manier zorgt ervoor dat het zelfde plaatje als dat van superrembo te verkrijgen is, maar dan heel wat efficienter. Een (en nu draaf ik door) symetrische footprint kan namelijk weer worden opgesplitst in een horizontaal en een verticaal deel waardoor de bewerking vervolgens niet meer een kwadratiesche maar lineaire complexiteit heeft.

Hier [rml]Janoz in "[ Alg] meest bezochte coordinaat van plaa"[/rml] heb ik een 'dummy' uitleg hoe dit plaatje te genereren met bvphotoshop. De bewerking komt ongeveer op hetzelfde neer (een gausian blur is een convolutie met een 'bobbel'. Veel mensen kennen de gausische kromme wel van de normale verdeling.)

Voor meer informatie over morphologische operatoren zou je bij google kunnen zoeken. Ikzelf heb dit allemaal gehad bij beeldbewerking vakken op de universiteit, dus heel erg makkelijke stof is het niet .

[ Voor 14% gewijzigd door Janoz op 03-11-2003 13:56 ]