Detektering og klassificering af kimplanter ved brug af computer vision

Detektering og klassificering
af kimplanter ved brug af computer vision
Afgangsprojekt:
Kursus: 7. semester elektroteknologi, data (E-AFP1)
Periode: 01.09.2006 – 19.12.2006
Gruppe 7E1:
Anders Due Schwartz
Kasper Broegaard Simonsen
Mads Johannes Thorsted Nielsen
Vejleder:
John Immerkær
Projekt udarbejdet ved:
Syddansk Universitet
Teknisk Fakultet
Institut for Sensorer, Signaler og Elektroteknologi

1 Indledning 1.1 Indledning
Synopsis
Problemstillingerne detektering og klassificering af kimplanter er begge forsøgt løst i projektet. For
at detektere de enkelte kim er der udviklet algoritmer så de fritliggende kim identificeres, og deres
placering samt orientering i planet findes. Til klassificeringen er der identificeret fire
kvalitetsparametre samt forskellige udvælgelsesmodeller. Detekteringen af kim anses som løst,
hvorimod klassificeringen stadig har åbne problemstillinger.
Forord
Rapporten er skrevet som et afgangsprojekt på elektroingeniør data-retningen ved Det Tekniske
Fakultet på Syddansk Universitet (SDU). Projektet er påbegyndt d. 1. september 2006 og er afsluttet
d. 19. december 2006. Gruppen har haft John Immerkær som vejleder.
Projektet er en del af HiTec Elitetræer-projektet ved Robocluster, som er et kompetencenetværk i
den syddanske region for robotter, intelligente mekaniske systemer og automationsteknologiske løsninger.
Selve HiTec Elitetræer-projektet omhandler: udvikling af nye robot- og visualiseringsteknologier
til automatiseret planteproduktion.
Hensigten med rapporten er at videregive løsninger, samt belyse eventuelle problemstillinger for
styregruppen for HiTec Elitetræer-projektet og andre interesserede.
Under udarbejdelsen af rapporten har det været nødvendigt at konsultere flere eksperter, der også
selv er tilknyttet HiTec Elitetræer-projektet: Jens Iver Find, biolog ved Københavns Universitet;
Lars Sommer fra Vitroform A/S, samt projektleder for HiTec Elitetræer-projektet fra Robocluster
Niels Korsager. Ydermere har gruppen samarbejdet med resten af styregruppen for HiTec
Elitetræer-projektet.
Odense d. 19. december 2006,
Kasper B. Simonsen Mads T. Nielsen Anders D. Schwartz
Side 1 af 131

1 Indledning 1.1 Indledning
Læsevejledning
Hovedrapporten er overordnet opdelt i to dele:
Del I: Detektering af kimplanter og Del II: Klassificering af kimplanter. Opdelingen udspringer
direkte af overskriften for projektet. Overskrifterne dækker over hver deres opgave, som vil blive
forsøgt løst i de to dele. Udover de to hoveddele er der også en række kapitler, der er fælles for
begge dele. Der hvor der er funktionalitet, som er implementeret i C++, har kapitlerne fået samme
navn, som den tilhørende C++-klasse. På denne måde er der skabt en direkte sammenhæng mellem
rapport og det tilhørende produkt. Disse kapitler er bygget op som følgende:
1. Indledning
Kort introduktion til den opgave klassen skal løse
2. Teori
Her beskrives den teori, der skal til for at klassen kan løse opgaven
3. Test
Her beskrives, hvordan testen skal udføres samt testresultaterne
4. Sammenfatning
En kort konklusion der samler op på resultatet af testen, samt hvorvidt klassen løser
opgaven som ønsket
Kapitlerne uden for Del I og Del II afviger fra denne opbygning.
Alle litteraturhenvisninger er skrevet på følgende måde: Forfatter [XX:YY]. Tallet på XX-pladsen angiver
kildenummeret i litteraturlisten. YY angiver sidetallet i den respektive kilde.
I Appendiks 18.1 Klasseoversigt s. 84 findes en klasseoversigt, der viser indholdet af klasserne et samlet
sted. Ydermere er det muligt i Appendiks 18.9 Implementering s. 102 at læse, hvordan alle klasserne i
rapporten er implementeret i C++-kode.
DVD
I løbet af rapporten vil der blive henvist til den vedlagte DVD. På denne findes kildekoden til
programmet, samt testbilleder, resultater og MatLab-scripts m.m. Henvises der i et kapitel til
DVD’en, findes de relevante filer i det tilsvarende kapitel-bibliotek.
Det udviklede program, kan findes på DVD’en i biblioteket ”Program”. Det er muligt i
underbiblioteket ”Kildekode”, at finde kildekoden til programmet. Kildekoden ligger i en mappe,
der har navn efter følgende skabelon: ”Vision NNN III”, hvor NNN er det tre cifredekodeversionsnummer,
og III er initialerne på den person, der har lavet den version. Inde i mappen
er der yderligere to mapper:
• Debug
o Indeholder det eksekvérbare program
• Vision
o Indeholder selve C++-kildekoden
I mange af kapitel-bibliotekerne findes der mapper, der indeholder testresultater samt den kildekode,
der blev anvendt i testen.
Side 2 af 131

1 Indledning 1.1 Indledning
Indholdsfortegnelse
1 Indledning ............................................... 5
1.1 Indledning ............................................. 5
1.2 Målformulering....................................... 5
1.3 Kravspecifikation .................................... 6
1.3.1 Del I: Detektering af kimplanter 6
1.3.2 Del II: Klassificering af kimplanter 6
1.3.3 Afgrænsning 6
2 Opbygning og planlægning..................... 7
2.1 Opbygning ............................................ 7
2.1.1 Program 8
2.2 Planlægning......................................... 10
3 Beskrivelse af kim ................................. 11
3.1 Indledning ........................................... 11
3.2 Kim ..................................................... 11
3.3 Miljø ................................................... 11
3.4 Klassificering........................................ 12
3.4.1 Første klasse – veldannede 12
3.4.2 Anden klasse – lette misdannelser 12
3.4.3 Tredje klasse – misdannede 12
3.4.4 Fjerde klasse – abnorme 13
3.5 Værdi.................................................. 13
4 Kamera ................................................. 14
4.1 Indledning ........................................... 14
4.2 Tilgængelige kameraer.......................... 14
4.2.1 Opløsning 15
4.2.2 Afstand og linse 15
4.3 Fire-i API.............................................. 15
4.3.1 Fire-i ubCore 15
4.3.2 WDM 15
4.3.3 Implementering af Fire-i 15
4.4 Sammenfatning .................................... 16
Del I: Detektering af kimplanter 17
5 Color ..................................................... 18
5.1 Indledning ........................................... 18
5.2 Teori ................................................... 18
5.2.1 Koordinatsystem 18
5.2.2 BMP-filer 18
5.2.3 Billedtilgang 19
5.3 Test ..................................................... 19
5.3.1 Fremgangsmetode 19
5.3.2 Testresultater 20
5.4 Sammenfatning .................................... 20
6 GrayScale.............................................. 21
6.1 Indledning ........................................... 21
6.2 Forskelle fra Color-klassen ..................... 21
6.3 Konvertering fra farve- til gråtonebilleder. 21
6.4 Test..................................................... 21
6.4.1 Fremgangsmetode 21
6.4.2 Testresultater 22
6.5 Sammenfatning .................................... 22
7 Binary ................................................... 23
7.1 Indledning ........................................... 23
7.2 Teori ................................................... 23
7.2.1 Histogram 23
7.2.2 Iterativ thresholding-teknik 24
7.3 Test..................................................... 26
7.4 Sammenfatning .................................... 27
8 BlobDetection ........................................ 28
8.1 Indledning ........................................... 28
8.2 Teori ................................................... 28
8.2.1 Knytning af pixels til subblobs 28
8.2.2 Knytning af subblobs 29
8.2.3 Blob sammensætning 30
8.2.4 Boundingbox 30
8.2.5 Seed generering 30
8.3 Test..................................................... 30
8.3.1 Deltest 1 31
8.3.2 Deltest 2 32
8.4 Sammenfatning .................................... 33
9 EllipseApproximation ............................ 34
9.1 Indledning ........................................... 34
9.2 Teori ................................................... 34
9.2.1 Massemidtpunkt 35
9.2.2 Orientering i planet 35
9.2.3 Vigtige tilfælde 36
9.2.4 Bestemmelse af ellipseparametre 37
9.3 Test..................................................... 38
9.3.1 Beskrivelse 38
9.3.2 Testresultater 40
9.4 Sammenfatning .................................... 41
Del II: Klassificering af kimplanter 43
10 ExpandShrink 44
10.1 Indledning ......................................... 44
10.2 Teori ................................................. 44
10.2.1 Expand 44
10.2.2 Shrink 45
10.2.3 Expand og Shrink 46
10.3 Test................................................... 47
10.3.1 expand() 47
10.3.2 shrink() 47
Side 3 af 131

1 Indledning 1.1 Indledning
10.3.3 expand() og shrink() 47
10.4 Sammenfatning .................................. 48
11 TopDetection........................................ 49
11.1 Indledning ......................................... 49
11.2 Teori ................................................. 49
11.2.1 Arealforskel 49
11.3 Test ................................................... 51
11.3.1 Testresultater 51
11.4 Sammenfatning .................................. 53
12 Symmetry............................................ 54
12.1 Indledning ......................................... 54
12.2 Teori ................................................. 54
12.2.1 Rotation af pixels 56
12.2.2 Bestemmelse af løsningsmodel 56
12.3 Test ................................................... 57
12.4 Sammenfatning .................................. 59
13 Quality ................................................ 60
13.1 Indledning ......................................... 60
13.2 Teori ................................................. 60
13.2.1 Bestemmelse af Kvalitetsparametre 60
13.2.2 Manuel inspektion 61
13.2.3 Bestemmelse af grænser 62
13.2.4 Variable grænser 65
13.3 Test ................................................... 65
13.3.1 Første del 65
13.3.2 Anden del 66
13.4 Sammenfatning .................................. 68
14 Implementering ................................... 69
14.1 Indledning ......................................... 69
14.2 Valg af implementeringsmiljø ............... 69
14.3 Programstruktur .................................. 69
14.3.1 Vision.cpp 69
14.4 User interface..................................... 72
15 Sammenfatning ................................... 73
15.1 Samlet test ......................................... 73
15.1.1 Fremgangsmetode 73
15.1.2 Test 1 – detektering af kim 73
15.1.3 Test 2 – klassificering 73
15.1.4 Test 3 – User interface 75
15.2 Diskussion ......................................... 77
15.3 Konklusion......................................... 78
15.3.1 Del I: Detektering af kimplanter 78
15.3.2 Del II: Klassificering af kimplanter 78
15.4 Videreudvikling .................................. 79
15.4.1 Kamera 79
15.4.2 EllipseApproksimation 80
15.4.3 TopDetection 80
15.4.4 Quality 80
15.4.5 Implementering 81
16 Litteraturliste ....................................... 82
17 Ordliste ............................................... 83
18 Appendiks........................................... 84
18.1 Klasseoversigt .................................... 84
18.2 Projektoplæg...................................... 87
18.3 Procesbeskrivelse................................ 87
18.4 Tidsplan ............................................ 88
18.5 Orientering i planet ............................ 89
18.6 Bestemmelse af ellipseparametre .......... 91
18.7 Valg af TopDetection-algoritme ............ 93
18.7.1 Brainstorm 93
18.7.2 Rating af idéer 97
18.8 Kodestandard .................................... 99
18.8.1 Indledning 99
18.8.2 Navngivning 99
18.8.3 Udseende 100
18.8.4 Programmeringsregler 101
18.9 Implementering ................................ 102
18.9.1 Color 102
18.9.2 Binary 103
18.9.3 Seed 105
18.9.4 BlobDetection 106
18.9.5 EllipseApproximation 109
18.9.6 ExpandShrink 111
18.9.7 TopDetection 114
18.9.8 Symmetry 116
18.9.9 Quality 117
18.9.10 Draw 121
18.9.11 Utilities 122
18.10 Test af Binary................................. 124
18.11 Test af TopDetection........................ 127
18.11.1 Billede 1 127
18.11.2 Billede 2 128
18.11.3 Billede 3 130
Side 4 af 131

1 Indledning 1.1 Indledning
1 Indledning
1.1 Indledning
Dette afgangsprojekt skal indgå som en del af det større projekt HiTec Elitetræer, som har til formål
at klone juletræer (og andre træer på længere sigt). Ved at anvende kloning skabes en stabil
produktion af planter af høj, ensartet kvalitet, der samtidigt øger den gennemsnitlige salgspris pr.
produceret træ, da planterne vil have meget ens arvelige egenskaber. Det er altså muligt at begrænse
den tilfældighed der spiller ind, når juletræer plantes i naturen på traditionel vis. Det vurderes, at der
er store økonomiske gevinster ved at producere juletræer på denne måde.
Gruppen skal indgå i arbejdet på HiTec Elitetræer med det formål at udvikle computeralgoritmer,
der ved hjælp af computervision kan identificere og klassificere samt kvalitetsvurdere kimplanter.
Det er ikke endeligt afgjort, om klassificeringen skal anvendes, på det stadie gruppen skal
implementere sin løsning i processen, men gruppen skal under alle omstændigheder udvikle metoder
til at løse klassificeringen.
I den samlede beplantningsproces vil gruppens arbejde indgå relativt tidligt i forløbet. Indledende
skal kimplanterne klones i et næringsmedium. Herefter skal de tages ud af næringsmediet, og der
foretages yderligere modning af kimene. Det er efter denne modningsperiode, at gruppen skal
identificere og klassificere kimplanterne. Efter kimene er blevet lokaliseret skal de placeres i et nyt
vækstmedie, hvor de skal modnes yderligere. Herefter er de spiret kraftigt, og en ny
computervisionproces skal udvælge de kim, der skal anvendes i den egentlige og traditionelle
beplantningsproces. Dette sidste trin håndteres af firmaerne T&O Stelectric A/S og Bila A/S.
1.2 Målformulering
Formålet med projektet er at arbejde med og udvikle visionsystemer.
Det er gruppens opgave, at fremstille et system der ved hjælp af visualiseringsteknologi kan
lokalisere kimene i vækstmediet, således de kan indgå i en udplantningsprocess. Der skal anvendes et
kamera, der tager et billede af vækstmediet med kimene i. Dette billede skal derefter processeres i en
computer med algoritmer udviklet af gruppen. Det er målet med algoritmerne at danne en snitflade,
hvor en robot vil kunne tilkobles computersystemet. Robotten vil kunne modtage information om
kimenes placering og orientering i vækstmediet. Det er kun gruppens opgave at bestemme placering
og orientering, men ikke at håndtere en eventuel robot.
Generelt vil gruppen danne en forsøgsopstilling til fotografering af kimplanter, der vil have en sort
baggrund, med en uniform belysning af baggrunden. Derudover vil gruppen undersøge, udvikle og
programmere algoritmer der kan identificere kimenes placering og orientering i vækstmediet.
Gruppen får stillet kamera og computer til rådighed til opgaven.
Side 5 af 131

1 Indledning 1.3 Kravspecifikation
1.3 Kravspecifikation
1.3.1 Del I: Detektering af kimplanter
1. Indlæse billede fra disk
a. Kunne modtage billede i 3x8-bit RGB BMP-format
2. Kunne identificere kimplanter
a. Enkelte fritliggende
b. Deres placering og længdeaksers orientering i planet
c. Ikke fritliggende kimplanter accepteres dog og sorteres evt. fra i kvalitetsvurderingen
1.3.2 Del II: Klassificering af kimplanter
3. Kvalitetsvurdering
a. Det skal bestemmes hvilke parametre, der skal bruges til at udvælge godkendte og
ikke-godkendte kim med
b. Det skal være muligt kun at udvælge alle 1. klasses kimplanter vha. de parametre angivet
i punkt a.
c. Det skal være muligt med algoritmer at udvælge kim hvis parametre falder indenfor
brugerspecificerede grænser
d. Projektet skal som resultat outputte x,y koordinat i pixels (på kimplantens midtpunkt)
og θ (vinkel i forhold til det vandrette plan) på de kimplanter der ligge inden
for grænserne
4. User Interface
a. Konsol baseret
b. Bruger skal kunne sætte grænser for kvalitetsparametre
1.3.3 Afgrænsning
5. Afgrænsning
a. Kimplanter i grupper vil ikke blive forsøgt separeret i programmet
b. Systemet skal kun understøtte en mørk baggrund og lys forgrund
c. Der må ikke være nogen betydelig variation i billedets belysning
Side 6 af 131

2 Opbygning og planlægning 2.1 Opbygning
2 Opbygning og planlægning
2.1 Opbygning
Formålet med afsnittet er, at give et overblik over hvordan det samlede system skal bygges op.
Overordnet set skal der laves et system, der består af et kamera og en computer. Computeren skal
interfaces med kameraet, som skal tage billeder af kimene. Billederne overføres fra kameraet til
computeren, og på computeren afvikles et program, som har til formål at analysere billedet. I
projektet skal der laves en forsøgsopstilling, der ikke er optimeret, så den kan indgå i produktionssammenhæng.
Der skal laves et program, der har til formål at analysere kimene i billedet. Dette skal skrives i C++,
da det vurderes at være hurtigt i afviklingen af koden og er objekt-orienteret. Samtidigt har gruppen
erfaring med C++, og på den måde undgås det at bruge tid på den overhead, der ligger i at lære nye
sprog. MatLab vil bruges til at supplere i opbygning og debugging af algoritmer, hvor det findes
nødvendigt. Gruppen skal udvikle, undersøge og programmere alle algoritmer, der kan være relevante
i løsning af opgaven. Ydermere skal der også udvikles et user interface, hvor en bruger kan ændre
indstillinger og se resultater fra programmet. Interfacet skal være konsolbaseret og kun implementere
de mest simple funktionaliteter. Det er ikke gruppens fokus at udarbejde et avanceret GUI.
Kamera
Figur 2.1
Generel opbygning
FireWire
protokol
Computer:
Afvikling af
C++-program
Det er aftalt, sammen med vejleder, at anvende et
kamera, der benytter FireWire-protokollen. Samtidigt
anvendes der software af navnet ”Fire-i API”.
Denne software kan interface med kameraer, der
anvender FireWire-protokollen (figur 2.1). Fordelen
ved at anvende dette kamera, er at det er muligt at
tilgå kamerafunktioner, som f.eks. at tage et billede,
direkte via et API i skrevet i C++.
Gruppen tildeles indledende et 640x480 pixel S/Hkamera,
som kan anvendes til opsætnings- og
interfacing-test med Fire-i API. Gruppen vil dog
senere i projektforløbet blive tildelt et 1280x960 pixel farve-kamera, som forventes at være det
primære kamera.
Side 7 af 131

2 Opbygning og planlægning 2.1 Opbygning
2.1.1 Program
I projektets begyndelse er programmets vigtigste komponenter blevet bestemt i samarbejde med
vejleder. Årsagen til dette er, at gruppen har en meget begrænset viden inden for computer vision.
Senere i forløbet har gruppen tilføjet komponenter og processer, som har vist sig at være
nødvendige for programmet. Der er ikke lavet en metodisk gennemgang af alternative
sammensætninger af algoritmer og programkonstruktioner, da dette blev vurderet som værende for
stor en opgave, set i lyset af gruppens begrænsede tid i projektet. Programstrukturen er blevet
bestemt til at være følgende (figur 2.2):
1. I Del I skal programmet
kunne loade et farvebillede
ind fra harddisken. Dette er
nødvendigt, for at kunne
udvikle på programmet, uden
at der anvendes kamera.
Billedet skal kunne gøres
tilgængeligt for alle andre
dele af programmet, som
kan have brug for tilgang til
det. Det skal på samme
måde være muligt, at hente
billedet direkte fra kameraet.
Dette billede skal herefter
gøres tilgængeligt på samme
måde som med billeder
hentet ind fra harddisken.
Når et billede er hentet ind,
enten på den ene eller anden
måde, skal det være muligt at
gemme det på disken igen,
således det kan bruges som
dokumentation eller i forbindelse
med debugging. Det
skal være muligt på et hvert
tidspunkt i løbet af programmet
at kunne gemme billedet.
2. Når billedet er hentet ind og
gjort tilgængeligt, er det næste
skridt, at det skal konverteres
til et gråtonebillede.
3. Gråtonebilledet skal danne
grundlag for et binært billede,
hvor baggrunden er sort
og kimene i forgrunden er
hvide. Der skal altså sættes
Figur 2.2
Blokdiagram over programmets opbygning
en grænse, for hvilket gråtoneniveau der er baggrund og hvilket der er forgrund. Hertil
anvendes et histogram. Alt som enten ligger over eller under denne grænse bliver
Side 8 af 131

2 Opbygning og planlægning 2.1 Opbygning
henholdsvis hvidt eller sort. Det ønskes at fastlæggelsen af denne grænse sker dynamisk, da
lysforholdene i billedet kan variere. Grænsen bliver på denne måde ikke givet på forhånd.
4. I det binære billede skal alle de hvide forgrundspixels, som rører ved hinanden, sættes
sammen sådan, at man kan referere til en samlet pixelgruppe med et nummer. En sådan pixelgruppe
refereres som ”blob”. Udover at danne blobs skal det også fastlægges, hvor disse
ligger i det binære billede. Der skal altså opsættes en grænse, som omslutter hver enkel blob.
Dette gøres ved at ramme dem ind med en firkant, med koordinater til alle fire hjørner, en
såkaldt ”bounding box”. Alle informationer om hver enkel blob gemmes i et objekt ”seed” i
programmet.
5. Næste skridt er at udføre ellipseapproksimation på alle blobsne. Det udnyttes her, at det er
givet på forhånd, at kimplanterne vil være aflange af form. Det er ellipseapproksimationens
formål, at bestemme stor- og lilleaksernes længder, samt de vinkler de danner med det
horisontale plan. På denne måde afgrænses det til to ender, hvor top og bund på kimet kan
ligge. Enten i den ene eller anden ende af storaksen. Ellipseapproksimationen resulterer
yderligere i centerkoordinater for kimplanten, som kan bruges i den videre analyse. Alle disse
informationer gemmes, sammen med dem der allerede står der fra blobsne, i seed-strukturen.
6. I Del II af projektet skal kimene kvalitetssorteres. Som et led i det skal kimenes top og bund
først findes. Dette gøres for, at man kan placere kimene med korrekt orientering i deres
næringsmiljø.
7. En interessant parameter for kimene er, hvor symmetriske de er omkring deres længdeakse.
Det er tanken, at undersøge hvor symmetrisk hvert kim er omkring dets længdeakse. Et mål
for den symmetri skal herefter vægtes i forhold til kimets størrelse, og på den måde kan
kimene sammenlignes indbyrdes. Det er altså herefter muligt, at frasortere kim der er
asymmetriske.
8. Det næstsidste trin bliver at udføre selve sorteringen. Indtil videre er der i Del II kun blevet
samlet oplysninger ind. I trin 8 gennemgås hvert kim, og det skal vurderes om kimet falder
inden for de grænser der sættes af brugeren.
9. I trin 9 skal der udskrives data om alle kimene. Når programmet kører i ”Debug”-mode
udskrives al tilgængelig information omkring kimene. Når programmet kører i normal
funktionsmode, udskrives kun det absolut nødvendige. I ”Debug”-mode laves der billeder,
der grafisk viser hvilke kim, der er blevet fundet i billedet. Fra trin 5, Ellipseapproksimation,
tegnes alle ellipserne på det originale billede, der bliver anvendt som input til programmet.
På den måde vil det være nemt at sammenligne det originale billede, med hvad algoritmen
har fundet frem til. Ydermere tegnes alle blobs, og der laves også et billede, der viser alle
toppe og bunde på kimene, ud fra det originale billede. Derudover udskrives der 3 tekstfiler:
a. ”Histogram.m” er en m-fil til MatLab, der direkte kan plotte histogrammet, der
bliver udregnet undervejs
b. ”blobData.txt” viser næsten al tilgængelig data på kimene
c. ”robotData.txt” viser kun (x, y, θ) for alle godkendte kim. Det er tanken, at en robot
kan interface med denne tekstfil, og på den måde finde kimene i planet. Når
programmet ikke kører i ”Debug”-mode, og altså ved normal funktionsmode,
udskrives kun ”robotData.txt”
Side 9 af 131

2 Opbygning og planlægning 2.2 Planlægning
2.2 Planlægning
Projektet er af natur uforudsigeligt. Der er ikke nogen mulighed for at støtte sig til tidligere skrevne
rapporter eller manualer om emnet, så vidt gruppen kan se, og derfor er det heller ikke enkelt at
tidsestimere hvert enkelt emne beskrevet i opbygningen af programmet (2.1.1 Program s. 8). Gruppen
indgår i en større helhed, og derfor vil fremgangen i projektet til dels afhænge af de andre grupper.
F.eks. skal gruppen bruge kim i forsøg og udvikling af kode, men da andre skal levere disse vil der
være ventetider i forbindelse med bestillingen. Ydermere skal der anvendes kameraer, der skal
rekvireres, og i denne situation er mange parter involverede. Derfor skal gruppen arbejde fleksibelt
og være indstillet på at kunne flytte fokus, afhængigt af hvad der er tilgængeligt på tidspunktet.
Derfor besluttes det at anvende riskorn i stedet for kimplanter i forbindelse med udvikling af de
første algoritmer. Det vurderes at disse, med succes, vil kunne anvendes som erstatning for kim i
test af de 5 første algoritmer i Del I. På samme måde anvendes en substitut for et kamera, i form af
mobiltelefonkamera, der sagtens kan bruges i tidlige test.
For at planlægge projektet har gruppen baseret sig på 6-fasemodellen (AIPA [1:1-4]), som er den der
anvendes på elektroretningen:
1. Problemanalyse
2. Idefase
3. Planlægning
4. Problemløsning
5. Konklusion
6. Formidling
Det vurderes dog på forhånd, at det ikke er hensigtsmæssigt at have en adskilt problemløsnings- og
analysefase grundet projektets forskningsprægede natur. For at holde styr på tiden har gruppen
opstillet 3 milepæle. Disse skal være afsluttet inden for tidsrammerne, da det ellers vurderes at
projektet, vil komme ud af kurs. Disse er:
1. Problemløsnings- og analysefase
2. Dokumentationsfase
3. Aflevering af rapport
Selve problemløsningsfasen kan ikke planlægges mere detaljeret, ud over at alle punkterne i 2.1.1
Program s. 8 skal løses her inden for. Dokumentationsfasen skal påbegyndes på et bestemt tidspunkt,
og er planlagt ud fra en tidsplan (18.4 Tidsplan s. 88), der sikrer at det står klart undervejs hvor langt
gruppen er nået, da det kan være svært at overskue, mens den forløber. Samlet skal de 2 første
milepæle sikre, at den 3. og afgørende milepæl ”Aflevering af rapport” kan overholdes.
Side 10 af 131

3 Beskrivelse af kim 3.1 Indledning
3 Beskrivelse af kim
3.1 Indledning
Den danske eksport af juletræer er Europas største med omkring 10 mio. træer årligt til en værdi af
omkring 1 mia. kr. Denne er hovedsageligt baseret på nordmandsgran, hvilket betyder at det er det
træ i Danmark, der har størst økonomisk betydning. Derfor er det kim af denne type der arbejdes
med i projektet.
3.2 Kim
Et kim er, på stadiet hvor gruppen skal arbejde med det, ca. 1-5 mm langt og fra 0,5 -1 mm bredt.
Det er gulligt i farven. Denne skifter dog langsomt til grøn, efterhånden som kimet bliver udsat for
lys og luft. I toppen har kimet en begyndende kimbladsstruktur. I bunden kan roden af og til anes
som en knold eller andre gange som en lille hale (figur 3.3). Pga. den måde hvorpå kimene er klonet,
har de ikke alle præcis samme alder. Der kan derfor være stor variation i størrelse, og hvor langt
kimblade og rod har udviklet sig.
3.3 Miljø
Kimene ligger efter de er blevet klonet og modnet i en
næringsmasse. I denne masse ligger de klumpet sammen
og klistrer kraftigt til hinanden (figur 3.1).
Efter et givent stykke tid skal kimene ud af denne masse
og flyttes enkeltvis over i et nyt næringsmedie. For at
separere kimene fra hinanden omrøres de kraftigt i et
vandkar. Herefter trækkes der et net op af vandkaret,
hvorpå kimene vil ligge spredt ud. Et eksempel på et
sådan net er vist på figur 3.2. Det ligger ikke inden for
gruppens område at designe dette net. Det er dog med
dette net som baggrund, at kimene vil komme til at ligge i
en endelig produktion. Nettet vil være matteret sort, og
det antages at genskin fra vand vil være minimalt.
Der vil blive anvendt prøver med kim, som leveres fra
Jens Iver Find fra Københavns Universitet. Disse kim vil
indgå i test, og opbevares på SDU, Det Tekniske Fakultet,
i køleskab. Det skal dog gøres klart, at gruppen ikke har
mulighed for at arbejde under sterile forhold, og derfor vil
prøver, efter de er åbnede blive udsat for bakterier, og
dette vil markant begrænse deres holdbarhed. Dermed
bliver den periode hvor gruppen kan foretage test, efter
åbning, meget begrænset.
Figur 3.1
Kimene mens de ligger klumpet sammen
Figur 3.2
Et eksempel på et net, hvor billedet er taget på
nært hold
Side 11 af 131

3 Beskrivelse af kim 3.4 Klassificering
3.4 Klassificering
Som det ses på figur 3.3 er der stor forskel på kimenes udseende. Nogle
er meget krumme, andre har ingen kimblade, mens nogle er tykke, og
andre er tynde. Dette giver anledning til en opdeling og klassificering.
Det viser sig nemlig, at det ikke er alle kim, der bliver til et pænt juletræ.
Kimene inddeles i 4 klasser (Find [2]).
• 1. klasse – veldannede
• 2. klasse – lette misdannelser
• 3. klasse – misdannede
• 4. klasse - abnorme
De bedste kim falder inden for 1. klasse.
3.4.1 Første klasse – veldannede
I en skål med klonede kim vil 8 – 10 % være af 1. klasse (figur 3.4). Af disse bliver 100 % til
veldannede og gode planter. For at et kim kan blive betragtet som et 1. klasses kim, skal det opfylde
følgende krav:
• 4-7 kimblade
• 3-5 mm lange
• Have en hvid-gul farve
• Være lige
Figur 3.4
Skitse af 1.klasses veldannede kim
Hver gang der laves en ny kloning kan der forekomme variation. Når der senere i denne rapport
tales om godkendte kim, så er dette ensbetydende med, at kimene er af 1. klasse.
3.4.2 Anden klasse – lette misdannelser
I en skål med klonede kim vil 8 – 10 % være af 2. klasse
(figur 3.5). Af disse bliver 75 % til veldannede og gode
planter. For at et kim kan blive betragtet som et 2. klasses
kim, skal det opfylde et af følgende krav:
• Et kimblad længere end de øvrige
• Indsnævret stængel
• 2-3 kimblade
3.4.3 Tredje klasse – misdannede
I en skål med klonede kim vil 8 – 10 % være af 3. klasse
(figur 3.6). Af disse bliver 50 % til veldannede og gode planter. For at et kim kan blive betragtet som
et 3. klasses kim, skal det opfylde et af følgende krav:
• Et dominerende kimblad
Figur 3.3
Viser et udsnit af de forskellige
former et kim kan antage
Figur 3.5
Skitse af de forskellige krav der stilles til 2.
klasses planter
Side 12 af 131

3 Beskrivelse af kim 3.5 Værdi
• Stumpet
• Ekstra rodspids
• Tvilling
• Krum
• Opsvulmet stængel
Figur 3.6
Skitser af de forskellige misdannelser som kan forekomme og gør at kimene falder inden for 3. klasse
3.4.4 Fjerde klasse – abnorme
I en skål med klonede kim vil ca. 75 % være af 4. klasse (figur 3.7). Af disse bliver 0 % til veldannede
og gode planter. For at et kim kan blive betragtet som et 4. klasses kim, skal det opfylde et af
følgende krav:
• Klumper
• Ingen kimblade
3.5 Værdi
Figur 3.7
Skitse af 4. klasses kim
Kostprisen på et kim på dette stadie er endnu ukendt, og det er derfor ikke muligt med sikkerhed, at
sige om det kan betale sig at plante alle kimklasser, selvom man ved at de ikke alle bliver til gode
træer, eller om man skal frasortere alle dårlige og kun koncentrere sig om de gode, eller om der skal
findes en mellemvej. Dog tyder tidlige vurderinger fra Jens Iver Find og Lars Sommer på, at det er
mest økonomisk at fjerne dårlige kim tidligt i beplantningsprocessen.
Side 13 af 131

4 Kamera 4.1 Indledning
4 Kamera
4.1 Indledning
For at det er muligt at detektere kim, er det nødvendigt med et kamera, der kan tage et billede, som
programmet herefter kan analysere. Det er ønskeligt, at kameraet kan interfaces i et kodeprojekt, så
der kan kommunikeres direkte, uden at skulle anvende proprietær software.
I samarbejde med vejleder blev det besluttet at anvende et kamera, der benytter FireWireprotokollen.
I den forbindelse anbefalede vejleder, at gruppen anvendte produktet Fire-i fra firmaet
Unibrain. Denne softwarepakke indeholder mange løsninger til at kommunikere med et FireWirekompatibelt
kamera. Overordnet set er disse løsninger delt ind i 2 kategorier (figur 4.1):
1. Kompilér-bar C++-kode (Fire-i API)
2. Prekompileret software
Fire-i API indeholder klasser skrevet i C++,
som programmører kan anvende i deres egen
kode. På den måde kan man direkte interface
sit eget kodeprojekt med kameraet.
Den prekompilerede software er applikationer
skrevet af Unibrain, som kan eksekveres
og igennem dem, kan man anvende kameraet.
Selvsagt giver dette ikke mulighed for at
indarbejde dette i sit kodeprojekt, da der er
tale om beskyttet proprietær software.
Gruppen har fra starten bestemt sig for at
indarbejde kameraet direkte i koden, ved at
anvende Fire-i API.
4.2 Tilgængelige kameraer
Til projektet blev der stillet to forskellige FireWire-kameraer til rådighed:
1. SONY XCD-V50 640x480 Gråtonekamera
2. SONY DFW-SX910 1280x960 Farvekamera
Figur 4.1
Oversigt over muligheder med Fire-i
Det har fra starten været hensigten, at kamera nr. 2 (farvekamera) skulle være gruppens primære
kamera. Dette kamera var dog ikke indkøbt fra starten af projektet, og derfor blev gruppen tildelt
kamera nr. 1 (gråtonekameraet), så det var muligt at arbejde på implementering af FireWire-kameraet
i kodeprojektet.
Det kan oplyses, at begge kameraer opererer med en gamma-værdi på 1. Det betyder, at det ikke er
nødvendigt for gruppen at indarbejde metoder for gamma-korrektion.
Side 14 af 131

4 Kamera 4.3 Fire-i API
4.2.1 Opløsning
Detektering af toppen på de enkelte kim dikterer kravet til opløsningen, da algoritmerne bygger på,
at der er synlig bladstruktur på kimene. De enkelte kim skal være minimum 10 pixels brede i toppen,
for at der er en detektérbar bladstruktur på billedet. Da godkendte kim er minimum én millimeter
brede, giver det et krav om en opløsning på minimum 10 pixels/mm, hvilket giver et synsfelt på
64x48 mm eller 128x96 mm afhængigt af kameraopløsning.
4.2.2 Afstand og linse
Gruppen anvender en linse fra Pentax (6 mm F/1.2 H612A C60607TH). Denne linse giver ikke
mulighed for zoom, men ved at placere den med den rigtige afstand til kimene, har gruppen fundet
frem til en løsning, der giver 11 pixels/mm. Dog er denne afstand uden for linsens normale
fokusområde, men dette er løst ved at lægge en mellemring imellem kamera og linse, så linsen kan
fokusere på objekter tættere på.
4.3 Fire-i API
Fire-i kan anvendes på 2 måder:
4.3.1 Fire-i ubCore
Denne model bygger på ”Firei.dll” fra Unibrain. Igennem dette bibliotek kan Unibrain-driverne
(ubCore) tilgås direkte, hvilket minimerer belastningen af systemressourcer, samtidigt med at
systemet er bagudkompatibelt med Windows 98 og NT.
4.3.2 WDM
Denne model bygger på Windows Driver Model (WDM), hvor softwaren, igennem DirectShow
(multimedieframework der bruges til lyd og billeder i Windows), tilgår Unibrain-driverne. Denne
metode anbefales af Unibrain til alle nyere systemer, da den er mere fleksibel og fremtidssikker. Dog
er denne metode ikke bagudkompatibel med Windows 98 og NT, og kræver flere systemressourcer,
da alle kald skal igennem flere applikationslag.
4.3.3 Implementering af Fire-i
Gruppen har forsøgt at interface med kameraet direkte, via et af de medfølgende Visual C++kodeprojekter
fra Unibrain, både ved anvendelse af ubCore- og WDM-modellen. Kodeprojekterne
skulle kun anvendes til test, og til at danne forståelse for hvordan en implementering skulle foretages
i gruppens eget kodeprojekt.
Gruppen har forsøgt at kompilere begge typer af kodeprojekteter, uden succes. Både i forbindelse
med ubCore- og WDM-modellen, har gruppen haft uoverkommelige problemer med at kompilere
de medfølgende kodeprojekter. I WDM-modellen anvendes der Microsoft DirectShow.
Dokumentationen til Fire-i biblioteket beskriver, at Microsofts ”Platform SDK” skal installeres, for
at det er muligt at kompilere software, der benytter sig af DirectShow. Gruppen installerede derfor
Microsofts ”Platform SDK” version 2006, men dette løste ikke kompileringsproblemerne, da der
Side 15 af 131

4 Kamera 4.4 Sammenfatning
stadig var problemer pga. manglende header-filer (f.eks. streams.h), og at der blev anvendt forældede
(”deprecated”) funktionskald.
Det er senere i forløbet konstateret, at Microsoft har fjernet DirectShow i version 2006 af Platform
SDK. At DirectShow ikke længere er en del af Platform SDK’et, kan være den væsentlige faktor til,
at gruppen ikke har kunnet kompilere softwaren. Årsagen til at gruppen ikke var klar over denne fejl
er, at DirectShow er fjernet fra Platform SDK i løbet af 2006, mens dokumentationen til kameraet er
skrevet i 2005, hvor der ikke er angivet nogen version af hvilket Platform SDK der skulle anvendes.
Problemerne, med anvendelse af Fire-i API, har resulteret i, at gruppen har været nødsaget til at tage
billeder vha. den medfølgende prekompilerede software til kameraet: ”Fire-i Application v. 3.51.0.3”.
Denne software er proprietær, og kan altså ikke interfaces direkte med gruppens eget kodeprojekt.
Det vurderes dog ikke at være en væsentlig hindring, da gruppen kun skal demonstrere at projektet
fungerer på konceptform, og ikke til produktionsmæssigt brug. ”Fire-i Application v. 3.51.0.3” giver
mulighed for, at brugeren kan se hvad kameraet filmer, og lave ”screendumps” af dette. Disse
screendumps kan herefter gemmes i et valgfrit bibliotek på computeren.
4.4 Sammenfatning
Samlet set kan det konkluderes, at interfacingen med kameraerne har haft en begrænset succes.
De anvendte kameraer har i sig selv været udmærkede valg til opgaven, og har ikke medført direkte
problemer.
Det kan konstateres, at det ikke har været muligt at interface kameraet på den ønskede måde. Der
var meget store problemer med at kompilere de medfølgende kodeprojekter fra Unibrain. I tilfældet
med ubCore-modellen, er det uvist hvad problemet skyldes, hvorimod med WDM-modellen har
gruppen en idé om, at der kan være problemer med anvendelsen af den nyeste version af Microsofts
Platform SDK. Gruppen har som alternativ besluttet, at anvende den medfølgende prekompilerede
software, der dog ikke giver mulighed for direkte tilgang til kameraet fra gruppens eget kodeprojekt.
Dette har dog ikke væsentlige konsekvenser, da der i forvejen skal udvikles metoder til at indlæse
BMP-filer i gruppens kodeprojekt.
Side 16 af 131

4 Kamera 4.4 Sammenfatning
Del I: Detektering af kimplanter
Første del af rapporten omhandler detektering af kimplanter. I denne del vil der blive udviklet
algoritmer, der har til formål alene at finde alle kim i billedet uden hensyn til kvaliteten af disse. Først
behandles Color- og GrayScale-klasserne, der har til formål at indlæse henholdsvis farve-, og
gråtonebilleder, og gøre dem tilgængelige for andre klasser. Dernæst gennemgås Binary- og
BlobDetection-klasserne, der vil henholdsvis thresholde, og finde alle blobs i billedet. Til sidst vises
klassen EllipseApproximation, som har til formål at finde kimenes massemidtpunkt, og
approksimere en ellipse hertil.
Side 17 af 131

5 Color 5.1 Indledning
5 Color
5.1 Indledning
Formålet med denne klasse er at give programmet et interface til at styre al I/O-billedbehandling
igennem. Klassen skal kunne indlæse BMP-filer, samt kunne gemme dem igen. Samtidigt skal
klassen stille et interface til rådighed til de andre klasser, som kan tilgå, ændre og gemme BMP-filer
simpelt.
5.2 Teori
5.2.1 Koordinatsystem
Figur 5.1
Koordinatsystem hvor ykoordinaten
peger nedad
5.2.2 BMP-filer
Hver pixel i et billede har et koordinatsæt. I et billedebehandlingsprogram
angives disse i et koordinatsystem
hvor y-aksen peger nedad (figur 5.1).
I matematiske sammenhænge og i BMP-filer bruges et
koordinatsystem hvor y-aksen peger opad (figur 5.2).
Gruppen har valgt at benytte sig af dette koordinatsystem.
En BMP-fil består af en header, evt. en palette og selve
dataene i nævnte rækkefølge (figur 5.3).
5.2.2.1 Header
Headeren ligger i starten af BMP-filen. Der findes flere
versioner af denne header, men det er valgt kun at arbejde
med 54-bytes versionen, ligesom det er valgt ikke at
komprimere eller dekomprimere billeder.
Figur 5.3
BMP-filers opbygning
Figur 5.2
Koordinatsystem hvor ykoordinaten
peger opad
Headeren er delt i to dele: en fil-header og en infomations-header. Fil-headeren gemmer
informationer omkring filstørrelse og offset ned til selv billede-dataene. Offsettets størrelse er
afhængigt af om der er en palette, og hvor stor den evt. er. Informationsheaderen angiver
oplysninger som højde og bredde af billedet, farvedybde, kompressionsmetode m.m.
Side 18 af 131

5 Color 5.3 Test
5.2.2.2 Palette
Paletten bruges kun på billeder med en farvedybde på 8 bit og der under. Paletten ligger på den 54.
byte og frem efter i BMP-filen. For hver farve gemmes 4 bytes: De første 3 bytes er intensiteten for
henholdsvis den blå, grønne og røde farve. Den fjerde byte bruges ikke.
5.2.2.3 Data
I datadelen gemmes selve billedet linie for linie, hvor den nederste linie i billedet er den, der ligger
først i filen, derefter kommer den næste linie osv. Pixelene gemmes enkeltvis hvor den pixel, længst
til venstre, er den der ligger først i filen. Hvis billedets farvedybde er over 8 bit bruges paletten ikke,
og de enkelte pixels gemmes i 3 bytes. Den første byte er farveintensiteten af den blå farve, den
anden er den grønne farve, og den tredje er den røde farve. Hvis billedets farvedybde er 8 bit eller
der under, bruges der en enkelt byte til at henvise til paletten.
BMP-standarden kræver, at det antal bytes en linie består af, skal være multiplum af 4. Da det ikke
vil passe med alle bredder af billeder, tilføjes 0-3 tomme bytes efter hver linie, så antallet af bytes er
multiplum af 4.
5.2.3 Billedtilgang
Når billedet er blevet loadet ind i et Color-objekt, er der mulighed for at gemme det som en fil eller
ændre det. Der kan laves ændringer i billedet på de følgende to måder:
• Normal tilgang
• Hurtig tilgang
Med den normale tilgang er der en fejlkontrol, der sikrer, at der skrives/læses indenfor billedet. Med
den hurtige tilgang anvendes der ikke fejlkontrol, men til gengæld kan der skrives og læses hurtigere.
5.3 Test
Da det er svært at lave en fuldstændigt dækkende test af color-klassen, er der foretaget en simpel
stikprøvekontrol. Kontrollen tester med et enkelt billede, om klassen kan hente og gemme billeder,
samt hvordan interfacing med andre klasser virker.
5.3.1 Fremgangsmetode
For at teste klassen er denne blevet implementeret
i et særskilt Visual C++-kodeprojekt. Dette kodeprojekt
tester klassens metoder til at hente billeder
fra disken og gemme dem til disken igen. Samtidigt
tester kodeprojektet også klassens metoder til at
hente enkelte RGB-værdier i billedet, samt ændre
disse.
Testen udføres ved at billedet ”input.bmp” (figur
5.4), bliver loadet ind med execute()-funktionen.
Figur 5.4
input.bmp – inputfilen til testen af color-klassen. Billedets
opløsning er 14x6 pixel
Side 19 af 131

5 Color 5.4 Sammenfatning
Herefter udskriver programmet billedets størrelse til prompten.
For at teste den normale tilgang bliver farven i koordinatet (3,1) kopieret til variablerne red, green
og blue samt skrevet til skærmen. Efterfølgende bliver farven i variablerne red, green og blue
kopieret til koordinaterne (3,2), (3,3) og (3,4).
For teste den hurtige billedetilgang (uden kontrol af om der skrives/læses inden for billedet),
kopieres pointeren til det grønne farve array over i ppGreenArray, som bruges til at tegne en grøn
streg fra punktet (4,4) og ud til højre side af billedet.
Til sidst gemmes billedet som filen ”color.bmp” (figur 5.5), så gemmefunktionaliteten også testes:
Color color;
color.execute("input.bmp");
printf("Picture size: %dx%d\n", color.getWidth(), color.getHeight());
unsigned char red, green, blue;
color.getValue(3,1, red, green, blue);
printf("RGB(3,1): %d %d %d\n", red, green, blue);
color.setValue(3,2, red, green, blue);
color.setValue(3,3, red, green, blue);
color.setValue(3,4, red, green, blue);
unsigned char **ppGreenArray;
ppGreenArray = color.getGreenPointer();
for (int i = 4; i < color.getWidth(); i++)
{
ppGreenArray[4][i] = 255;
}
color.save("output.bmp");
5.3.2 Testresultater
Programmet skriver følgende til prompten:
Picture size: 14x6
RGB(3,1): 255 255 0
Billedet vist i figur 5.5 bliver gemt til disken.
Billedets størrelse (14x6 pixel) er læst fra filen.
Samtidigt er RGB-koden for farven i koordinatsæt 3,1
indlæst til at være 255, 255, 0, hvilket svarer til gul.
Som det ses på billedet er farven (gul), fra pixel (3,1),
kopieret til pixelene (3,2), (3,3) og (3,4). Ligeledes er
der tegnet en streg fra pixelen i (4,4).
5.4 Sammenfatning
Figur 5.5
Figuren viser color.bmp som er resultatet af testen af
color-klassen
Det kan konkluderes, at andre klasser i programmet med succes kan tilgå BMP-billedet med det
interface, der er stillet til rådighed igennem denne klasse. Testen viser, at klassen korrekt henter,
ændrer og gemmer billedet som ønsket.
Side 20 af 131

6 GrayScale 6.1 Indledning
6 GrayScale
6.1 Indledning
Der ønskes en simpel måde at interface med gråtonebilleder, hvor det er let at loade, ændre, oprette
og gemme gråtonebilleder.
Da koden i GrayScale-klassen bygger på koden i Color-klassen, minder de to klasser meget om
hinanden. I stedet for at dokumentere hele GrayScale-klassen på samme måde som Color-klassen,
har gruppen valgt kun at dokumentere de forskelle, der er på de to klasser i dette kapitel.
6.2 Forskelle fra Color-klassen
Da der arbejdes med et gråtonebillede er antallet af farvekanaler reduceret til én enkelt i GrayScaleklassen.
Da der kun er én farvekanal, simplificeres metoderne til at hente og ændre pixelintensiteten.
6.3 Konvertering fra farve- til gråtonebilleder
Ved konvertering af farvebilleder til gråtonebilleder skal farvekoden, for de enkelte pixels konverteres
til en gråtone lysintensitet. De tre farverkanaler i RGB-billedet bør vægtes forskelligt (tabel 6.1)
ved konverteringen til gråtoner.
Da den grønne farvekanal er den mest dominerende hvad angår
lysintensitet, og da kimene er gul-grønne, har gruppen valgt at konvertere
fra et farvebillede til et gråtonebillede, ved kun at bruge den grønne
farvekanal. Med denne metode bliver konverteringen simplere og hurtigere,
samtidigt med at grønne objekter bliver tydeligere i gråtonebilledet.
Dette gør selvfølgelig, at algoritmen ikke vil virke på rent røde og blå
objekter.
6.4 Test
6.4.1 Fremgangsmetode
Denne test kontrollerer konverteringen af et farvebillede til
gråtonebillede. Testen udføres ved at indlæse billedet
”color.bmp” fra testen af Color-klassen og konvertere det
til et gråtone billede og sammenligne de to billeder:
Color color;
GrayScale grayScale;
color.execute("color.bmp");
grayScale.execute(color);
grayScale.save("grayscale.bmp");
Figur 6.1
color.bmp
Farve Vægtning
Rød 0,299
Grøn 0,587
Blå 0,114
Tabel 6.1
Vægtning af de forskellige
farver ved konvertering til
gråtone
Side 21 af 131

6 GrayScale 6.5 Sammenfatning
6.4.2 Testresultater
På figur 6.1 ses det oprindelige billede, som er blevet loadet
ind i figuren. I figur 6.2 ses resultatet af konverteringen. Det
ses her, at det kun er den grønne farve, der bliver overført
til gråtonebilledet.
6.5 Sammenfatning
Figur 6.2
grayscale.bmp
Der er med succes lavet en klasse, som stiller et interface til rådighed. Dette interface gør det muligt
for andre klasser at loade, oprette, ændre og gemme gråtonebilleder på samme måde som med
Color-klassen. Konverteringen fra farvebillede til gråtonebillede foregår ved kun at bruge den
grønne farvekanal, da kimene er gul-grønne og da den grønne farvekanal, er den mest dominerende
af de 3 farvekanaler i forhold til lysintensitet.
Side 22 af 131

7 Binary 7.1 Indledning
7 Binary
7.1 Indledning
Det er formålet med Binary-klassen, at skabe en måde hvorpå det kan afgøres, hvad der er for- og
baggrund i billedet. Billedet, som skal behandles, kommer som et objekt fra GrayScale-klassen. Det
ønskes at opstille automatiserede metoder til, hvordan man får adskilt lyse kim i forgrunden fra den
mørke baggrund. I denne forbindelse opereres der med en term som thresholdværdi, som er den
pixelintensitetsværdi, der angiver skellet mellem for- og baggrund.
7.2 Teori
Det ønskes altså at have en automatiseret proces, der kan finde thresholdværdien automatisk. Til
dette bruges et histogram og Ridler og Calvards iterative thresholding-teknik (Ridler og Calvard [6:630-
632]). Metoden er delt i to processer:
1. Histogram dannes ved at billedet traverseres, hvor der løbende tælles op hvor mange pixels,
der er af hver pixelintensitet
2. Efter et antal iterationer bestemmes billedets thresholdingværdi. Denne værdi vil afgøre hvad
der er forgrund og baggrund i billedet
Histogrammet bruges til, at vurdere hvor de største fordelinger i pixelintensitet er placeret. Derefter
skal den iterative thresholding-teknik bruges til at bestemme selve thresholdværdien ud fra
histogrammet.
7.2.1 Histogram
Histogrammet er et plot af hyppigheden (frekvens) af alle pixelintensiteter (pixel intensitet) i et
gråtonebillede (figur 7.1). Det er givet på forhånd i programmet, at alle pixelintensiteter skal kunne
være i en byte, så derfor skal histogrammet gå fra 0-255 pixels. Figur 7.1 viser et realistisk eksempel
på et histogram af et billede med kim:
Figur 7.1
Billede med tilhørende histogram
Side 23 af 131

7 Binary 7.2 Teori
Som det ses af histogrammet, er der en meget stor peak ved de lavere pixelintensiteter, som kommer
af den dominerende mørke baggrund i billedet. Ydermere er der en mindre peak omkring 150 i
pixelintensitet, som kommer af de lyse kim i forgrunden. Det er tydeligt at se fra histogrammet, at
vælger man en pixelintensitet omkring 70, vil man skelne forgrunden fra baggrunden. Det er dog
ikke altid at en thresholdværdi på 70 vil være rigtigt, da ændringer i lysforhold og kimtyper kan gøre
at begge peaks vil ligge andetsteds i histogrammet. Derfor vil det være hensigtsmæssigt at anvende
en automatiseret proces der kan finde ”dalen” i histogrammet mellem de to peaks.
Histogrammets udseende afhænger af mange faktorer. På billedet, der er anvendt som eksempel, er
følgende tilstande gældende:
1. Ensartet belysning i hele billedet
2. Der er stor kontrastforskel mellem forgrund og baggrund
3. Der er meget lidt genskin fra lyskilder
4. Der er mere baggrund end forgrund i billedet
En ændring i hver af disse parametre (1-4) vil give hver sin type af ændring (a-d) i histogrammet:
a) Forestiller man sig f.eks. at et hjørne er mere belyst end de andre vil de lyse områder, der er
større end thresholdværdien, blive opfattet som forgrund. For at løse dette kunne man lave
et gradient-map. Dette map gør at det er muligt at have forskellige thresholdværdier
forskellige steder i billedet. På den måde er der ikke én fast thresholdværdi for hele billedet
men thresholdværdier for områder i stedet. Dette gør, at selvom dele af billedet er mere lyse
end andre, så vil disse områder ikke nødvendigvis blive betragtet som forgrund, da der
eksisterer en relativ thresholdværdi for det område, der sikrer at thresholdingen matcher
lysforholdene i det område.
b) Hvis der ikke eksisterer et stort kontrastforhold mellem kimene og baggrunden, vil den
mindre peak mod højre ligge længere til venstre. Ved særligt lave pixelintensiteter vil den lille
peak, som kommer fra tilstedeværelsen af kimene, være sammenfaldende med den store
peak og det vil være svært algoritmemæssigt at skelne forgrund fra baggrund ved brug af
histogrammet.
c) Ved genskin vil det give ”falske kim” i billedet. Genskinnet vil sandsynligvis ligge over
thresholdværdien og vil derfor blive betragtet som forgrund. Dermed vil den mindre peak
fra kimene være større på et falskt grundlag, og den store peak med baggrundspixels være
tilsvarende mindre.
d) Skulle det være tilfældet at der er mere forgrund end baggrund i billedet, vil histogrammet se
ud som det i eksemplet, bare spejlet omkring midten (127 pixelintensitet), dvs. den store
peak vil ligge mod højre.
Punkterne beskrevet i a-d er alle emner, der regnes for ikke at være gældende i de billeder, der skal
analyseres af algoritmen.
7.2.2 Iterativ thresholding-teknik
Ridler og Calvards iterative thresholding-teknik, har til formål at finde ”dalen” imellem de 2 store
peaks i histogrammet. Trussel [5:311] beskriver en matematisk løsning på Ridler og Calvards teknik
som:
Side 24 af 131

7 Binary 7.2 Teori
, hvor:
T
Tk
∑
bn() b
b=
0
b= Tk+
1
k + 1 = T +
k
N
∑
2 nb ( )
b=
0
N
∑
∑
b= Tk+
1
bn() b
2 nb ( )
T k Thresholdværdien ved k’te iteration
N Antal pixelintensiteter (i gråtonebillede er N = 255 )
b Pixelintensitet ( 0 ≤b ≤ N)
nb () Antal forekomster af b
H. J. Trussels formel og Ridler og Calvards iterative thresholding-tekniks virkemåde kan beskrives
som (figur 7.2):
1. Den indledende thresholdværdi ( T 0 ) sættes til 127
2. Det undersøges for hver pixelintensitet i histogrammet, om denne ligger over eller under den
aktuelle thresholdværdi:
a. Under er baggrundspixel, og indgår i summering af arealerne af baggrundspixelene
(tæller i venstre led i ligning (7.1)), og summering af antallet af forekomster for den på
gældende pixelintensitet (nævner i venstre led i ligningen)
b. Over er forgrundspixel, og samme retorik for forgrundspixels gælder som beskrevet i
punkt a.
3. Efter endt summering findes der en gennemsnitsværdi for både baggrunds- og
forgrundsarealet (optræder som divisionen med tæller- og nævnersummeringerne)
4. Herefter findes gennemsnitsværdi for baggrunds- og forgrundsgennemsnitsværdierne.
Denne værdi er den nye thresholdværdi T k (optræder som den halve der er ganget på begge
led i ligningen)
5. Processen gentages fra trin 2 til og med 4 indtil thresholdværdien ikke ændrer sig mere
(7.1)
Side 25 af 131

7 Binary 7.3 Test
7.3 Test
Figur 7.2
Implementering af H. J. Trussels formel
Det er formålet med testen, at undersøge hvorledes den udviklede kode, vil udregne
thresholdværdien for et billede. Der bruges i alt 11 billeder i testen (ligger på DVD’en i ”7.
Binary\Inputbilleder til test”). For hvert billede der testes registreres gennemsnitsværdierne for baggrunds-
og forgrundsarealet (punkt 3 i 7.2.2 Iterativ thresholding-teknik s. 24), og thresholdværdien for
hver iteration. Ydermere udprinter klassen automatisk histogrammet for billedet i MatLab-kode, så
der nemt kan tegnes en graf ud fra dataene (disse findes som ”histogram.m” i ”Data”-biblioteket).
Billedet herunder (figur 7.3) beskriver iterationsprocessen på histogrammet ud fra data fra test på det
første billede ”blandet1”. B K beskriver baggrundsarealets gennemsnitsværdi for k’te iteration, og på
samme måde med F for forgrundsarealet. T k beskriver thresholdværdien for k’te iteration.
Side 26 af 131

7 Binary 7.4 Sammenfatning
Det ses på figur 7.3, at som der
itereres placeres thresholdværdien
længere og længere mod venstre og
konvergerer til en threshold på 87 i
pixelintensitet.
Testresultater for alle 11 billeder
findes i Appendiks 18.10 Test af Binary
s. 124.
7.4 Sammenfatning
Det kan overordnet konkluderes, at
det har været muligt at skabe en
klasse, der med succes kan thresholde
et billede.
Klassen indeholder en funktion, der
kan skabe et histogram over et givent
billede, hefter en funktion der kan
anvende histogrammet og evaluere en
thresholdværdi, der passer til billedet.
Til sidst er der lavet en funktion, der
kan anvende thresholdværdien på det
oprindelige billede, og skabe et nyt
binært billede der er thresholdet med
thresholdværdien.
Figur 7.3
Demonstration af algoritme med billedet ”blandet1” som eksempel
Testen viser, at implementeringen af koden virker som den skal. Thresholdværdien lægger sig
imellem de to peaks i histogrammet som ønsket, og ved visuel inspektion af de thresholdede billeder,
er det klart at mindre mængder genskin og andet ”støj” bliver sorteret fra som ønsket.
Det vurderes, at det ikke har nogen væsentlig effekt, hvad det indledende gæt på thresholdværdien
T 0 er ud fra gruppens forsøg. Dvs. det betyder ikke noget, om det vælges at starte yderst fra højre
( 0 T = 255) eller om 0 T = 127. Det eneste sted hvor der kan findes en forskel, er når T 0 = 0. Denne
forskel er dog sjældent mere end 1 pixel i pixelintensitet. Derfor findes det mest logisk og effektivt at
vælge T 0 = 127, da dette er midten af skalaen, og samtidigt i nærheden af den resulterende thresholdværdi
i langt det fleste tilfælde, hvilket vil give en potentielt kortere iterationsproces.
Samlet kan det konkluderes, at klassen korrekt identificerer thresholdværdien, og anvender denne til
at skabe et thresholdet billede fra det oprindelige gråtonebillede.
Side 27 af 131

8 BlobDetection 8.1 Indledning
8 BlobDetection
8.1 Indledning
Formålet med denne klasse er, at kunne detektere de enkelte objekter i et binært billede, og kunne
videregive data om disse objekter til andre klasser. Objekter, der ligger i kanten af billedet, skal
sorteres fra, da det ikke er sikkert, at hele objektet ligger inden for billedet. Ligeledes skal objekter,
der er uden for givne arealgrænser, sorteres fra. I opbygning af algoritmen anvendes der principper
fra Davies [3:159-167], der er blevet modificeret til gruppens behov.
8.2 Teori
En blob er en gruppering af en eller flere hvide forgrundspixels, som har kontakt med hinanden. Til
de enkelte blobs knytter der sig oplysninger omkring størrelse og placering i billedet.
En subblob er forstadiet til en blob. Hvis to eller flere subblobs viser sig at have
kontakt med hinanden, vil disse blive knyttet sammen inden de bliver til en blob.
Billedet bliver behandlet pixel for pixel. Den pixel der behandles på et givent
tidspunkt kaldes A0. De omkringliggende pixels kaldes for A1-8 (figur 8.1). Hvis A0
er tændt tilhører den en blob. De af dens naboer (A1-8), der er tændt, tilhører den
samme blob.
8.2.1 Knytning af pixels til subblobs
Billedet bliver kontrolleret pixelvis, hvor alle tændte pixels bliver knyttet til en subblob efter
følgende princip:
• Hvis en eller flere af nabopixelene er knyttet til en subblob, knyttes A0 til den samme
subblob
• Hvis en eller flere af nabopixelene er knyttet til forskellige subblobs, forenes disse subblobs
og A0 knyttes til disse
• Hvis ingen af nabopixelene er knyttet til en subblob, oprettes der en ny subblob som A0
knyttes til
A5 A0
A4 A3 A2
Figur 8.2
Den aktuelle
pixel og de 4
interessante
naboer
A6 A7 A8
A5 A0 A1
A4 A3 A2
Figur 8.1
Den aktuelle
pixel og dens
otte naboer
Da billedet bliver kontrolleret pixelvis, vil kun de 4 af naboerne (A2-A5) til en given
pixel have været kontrolleret forinden. Dette gør, at det kun er muligt at knytte en
pixel til de subblobs, der ligger i A2-5. Dermed bliver kontrollen af A1 og A6-8 udsat,
til når algoritmen når til næste pixel og næste linie, hvor de pixels så vil blive knyttet
til deres naboer (A2-5). På dette grundlag undersøges kun A2-A5 (figur 8.2) og ikke
A1 og A6-A8.
Side 28 af 131

8 BlobDetection 8.2 Teori
8.2.1.1 Eksempel
Figur 8.3
Billede på 5x6 pixel med to
forgrundspixels
Et simpelt billede i størrelsen 6x5 pixel, hvor
alle pixels er slukket med undtagelse af de to
midterste (figur 8.3). Algoritmen kontrollerer
billedet nedefra og op, hvor den ikke vil finde
nogen tændte pixels i de to første rækker.
Først ved 3. pixel i 3. række (figur 8.4) finder
den en tændt pixel. Det bliver kontrolleret,
om dens 4 naboer (A2-5) er knyttet til en
subblob. Da ingen af dem er tændte, er de
heller ikke knyttet til en subblob. Derfor oprettes der en ny subblob, som
den aktuelle pixel knyttes til. Når dette er gjort, forsætter algoritmen til
næste pixel (figur 8.5). Denne pixel er også tændt, og derfor kontrolleres
også dennes 4 naboer. Af dens naboer er den ene tændt (A5), og dermed
knyttes A0 til samme subblob som A5. Resten af billedet løbes igennem,
men der findes ikke flere tændte pixels. Nu har algoritmen fundet en
subblob, som består af 2 pixels.
8.2.2 Knytning af subblobs
Under kontrollen af et billede, kan der forekomme situationer, hvor 2 eller flere subblobs har
kontakt med hinanden. Disse situationer fremkommer, hvis 2 eller flere af A0s fire naboer er
knyttet til forskellige subblobs.
Sammenknytningen laves vha. en træstruktur, hvori det noteres hvilke subblobs der hænger sammen.
Alle subblobs oprettes som deres egen rod i hvert deres rodsystem, uden at der er andre
elementer i systemet. Hvis to subblobs knyttes sammen, gøres det ved at gøre den med det højeste
subblobnummer til en gren i den andens rodsystem.
Træstrukturen realiseres i en liste, hvor der er en plads til hver subblob. Når en subblob oprettes,
skrives dens subblobnummer ind på dens plads. Hvis den senere knyttes til en anden subblob,
ændres værdien på pladsen, så subblobben nu peger på dens rod.
8.2.2.1 Eksempel
Figur 8.6
Billede med to blobs som bliver detekteret
som flere subblobs
Billedet (figur 8.6) viser et eksempel
med to blobs som i algoritmen først
vil blive detekteret som 4 subblobs,
men hvor de 3 knyttes sammen, så
der kun er 2 blobs.
Billedet kontrolleres nedefra, hvor
de enkelte pixels bliver knyttet til
forskellige subblobs. Som det er vist
på figur 8.7, bliver de enkelte pixels
knyttet til de samme subblobs som
deres naboer. Ved A- og B-pixelene
er der to forskellige naboer, så der
skal to subblob knyttes sammen.
A5 A0
A4 A3 A2
Figur 8.4
Naboerne til pixelen i (2,2)
bliver undersøgt
A5 A0
A4 A3 A2
Figur 8.5
Naboerne til pixelen i (3,2)
bliver undersøgt
B 3
0 2 A
0 2 1 1
0 1 1
Figur 8.7
Billede delt op i subblobsne 0, 1, 2 og
3, hvor pixelene i A og B sammenkæder
de forskellige subblobs
Side 29 af 131

8 BlobDetection 8.3 Test
Figur 8.8
De fire subblobs som ikke er
knyttet sammen
På figur 8.6 bliver der detekteret 4 subblobs,
som sættes op som hver deres rod
(figur 8.8).
Nå algoritmen analyserer A-pixelen i figur
8.7, opdages det at subblob 1 og 2 er den samme, og derefter knyttes
subblob 2 til subblob 1 (figur 8.9).
Senere, ved analysering af B-pixelen, opdages det, at subblob 2 og
subblob 0 også skal kædes sammen. Men da subblob 2 allerede er
knyttet til subblob 1, kan den ikke knyttes til subblob 0. I stedet
knyttes subblob 1 (subblob 2’ rod) til subblob 0 (figur 8.10). På denne
måde bliver alle de 3 subblobs knyttet sammen.
8.2.3 Blob sammensætning
Ud fra subblob-træstrukturen laves de endelige blobs. Der bliver lavet en liste med subblobs, som
bruges til at knytte de enkelte subblobs til de forskellige blobs.
8.2.4 Boundingbox
For hver blob på billedet, findes det mindste rektangel, som hele blobben kan være indenfor. Dette
rektangel kaldes for en boundingbox og består af 4 koordinater. Disse koordinater findes, ved at
kontrollere samtlige pixels i billedet. Hvis pixelen er knyttet til en blob, kontrolleres det om den
ligger inden i boundingboxen for den givne blob. Hvis den ikke ligger inden for boxen, udvides
denne, så den aktuelle pixel kommer indenfor.
8.2.5 Seed generering
Alle blobs, hvis arealer er for små eller for store, i forhold til de brugerspecificerede grænser, sorteres
fra. Dette gøres for at eliminere falske detekteringer fra f.eks. genskin og andet ”støj”. Blobs, som
har kontakt med kanten sorteres også fra, da det ikke er muligt at vide, om noget af det enkelte
objekt ligger uden for billedet. Der generes et binærtbillede af de enkelte blobs, så efterfølgende
programkode kan tilgå et billede af de enkelte objekter. Da objekterne skal sendes videre til de andre
dele af programmet, laves her en liste, hvor der gemmes oplysninger om de enkelte objekter.
8.3 Test
Testen har til formål at vise, at BlobDetection kan:
• lokalisere de enkelte objekter i billedet
• frasortere objekter der ligger i kanten eller hvis areal er under en minimums- eller over en
maksimumsgrænse
De to delformål vil blive testet separat.
0 1 3
2
Figur 8.9
Subblob 2 knyttet til subblob 1
0
1
2
Figur 8.10
Subblob 0, 1 og 2 er nu knyttet
sammen
3
Side 30 af 131

8 BlobDetection 8.3 Test
8.3.1 Deltest 1
Denne tests formål er, at
vise at BlobDetection kan
lokalisere de enkelte objekter
i et billede.
Billedet på figur 8.11 består
af 11 forskellige elementer
i forskellige former og
størrelser. Øverst ses de fire
forskellige måder, hvorpå
en pixel (A0) kan være
nabo til en anden pixel
(A2-5). Det forventes at
disse 4 objekter, hver bliver
detekteret som en
blob. I den midterste række
vises objekter med forskellige
størrelser samt
elementer med huller i.
Det forventes igen, at disse
objekter bliver detekteret
som hver deres blob. De
nederste 3 objekters ud-
seende gør, at de først vil blive detekteret som flere subblobs, men senere vil blive kædet sammen.
Denne detektering og sammenknytning forventes at resultere i, at de tre objekter bliver detekteret
som tre blobs.
8.3.1.1 Testresultater
Figur 8.11
Testbillede som udsætter BlobDetection for forskellige situationer
Algoritmen har, ud fra billedet i figur 8.11, fundet dataene i tabel 8.1:
Number BoundsXMin BoundsXMax BoundsYMin BoundsYMax Area
0 5 22 4 12 90
1 29 31 8 9 3
2 42 45 8 11 10
3 5 5 22 22 1
4 16 18 22 24 9
5 28 32 22 26 25
6 42 48 22 28 24
7 11 12 37 37 2
8 21 22 37 38 2
9 33 33 37 38 2
10 41 42 37 38 2
Tabel 8.1
Number er nummeret på den enkelte blob. Da billedet bliver analyseret fra bunden og op vil
de nederste objekter have de laveste numre. BoundsXMin, BoundsXMax, BoundsYMin og
BoundsYMax koordinaterne for de enkelte objekters boundingboxes. Area er arealet på de forskellige
objekter
Med klassen Draw (Appendiks 18.9.10 Draw s. 121) plottes de forskellige blobs i forskellige farver, og
ydermere bliver der plottet en omkringliggende ramme til de enkelte blobs (figur 8.12). Disse rammer
Side 31 af 131

8 BlobDetection 8.3 Test
svarer næsten til boundingboxene, men de er udvidet med en pixel i alle retninger, for at de ikke skal
dække for noget af de enkelte objekter.
8.3.2 Deltest 2
Figur 8.12
Resultat af første deltest
Formålet med testen er at
vise, at algoritmen kan
frasortere de objekter, der
ligger i kanten af billedet, og
de objekter, hvis areal er uden
for bruger specificerede
grænser.
Testen afvikles ved at teste et
billede (figur 8.13) af 16 forskellige
objekter. Disse objekter
er fordelt i billedet, så
nogle ligger i kanten og andre
ligger tilfældigt rundt i billedet.
Samtidigt har de
forskellige størrelser.
Fire af disse objekter ligger i
kanten af billedet. Algoritmen
afvikles med en minimumsarealgrænse
på 5 og en maksimumsarealgrænse
på 100.
Figur 8.13
Testbillede til anden del af testen
Side 32 af 131

8 BlobDetection 8.4 Sammenfatning
Blandt de forskellige objekter i billedet, er der nogle, der er mindre end minimumsgrænsen, og nogle
der er mellem de 2 grænser, mens der er andre der er større end maksimumsgrænsen.
På figur 8.14 vises resultatet fra deltest 2 genereret via Draw-klassen:
Figur 8.14
Resultat af anden deltest
8.4 Sammenfatning
I deltest 1 fremgår det, at algoritmen har adskilt de forskellige objekter i billedet fra hinanden. Det
ses også at de enkelte objekters boundingboxkoordinater og areal er blevet optalt korrekt. I figur 8.12
får de enkelte objekter hver deres farve, hvilket viser at algoritmen har adskilt dem. Ydermere ses
det, at alle objekter er blevet detekteret korrekt.
I resultaterne fra deltest 2 ses det, at antallet af objekter er blevet reduceret (figur 8.14). 4 af objekterne
er fjernet pga. de ligger i kanten af billedet. 3 objekter er fjernet, da de er mindre en minimumgrænsen
på 5, mens 2 objekter er fjernet, pga. de er større end maksimumsgrænsen på 100.
Ud fra resultatet af deltest 2 kan det ses, at algoritmen er i stand til at fjerne de objekter, der ligger i
kanten af billedet, og de objekter hvis areal er uden for brugerspecificerede grænser.
Det kan konkluderes, at algoritmen kan finde de enkelte objekter i billedet. Ydermere frasorterer
algoritmen de objekter, der ligger i kanten af billedet, og evt. de hvis arealer er over eller under
brugerspecificerede grænser. Samtidigt finder algoritmen objekternes areal samt deres boundingboxkoordinater.
Side 33 af 131

9 EllipseApproximation 9.1 Indledning
9 EllipseApproximation
9.1 Indledning
Det er formålet med EllipseApproximation-klassen, at skabe en måde hvorpå et objekts (kims)
midtpunkt og orientering i planet kan bestemmes (Horn [4:48-53]). En måde at gøre dette på er ved
at antage, at objektet har en aflang
form, der kan sammenlignes med en
ellipse. Dette gøres ved at undersøge
det binære billede af hver blob. Herfra
er det muligt at bestemme et midtpunkt
x,y ) i objektet (figur 9.1). Herefter
a
( 0 0
tilpasses en ellipse ud fra objektets udseende.
Den resulterende ellipses stor-
(a ) og lille-akse (b ) danner hver en
vinkel θmajorog θ min or med det vandrette
plan. Når disse 3 sæt af data er
kendt, er det muligt at angive kimets
placering og orientering i forhold til det
vandrette plan.
Ellipseapproksimationsalgoritmen skal
ikke kun begrænses til at tilpasse
ellipser til kim, men til enhver given
form.
9.2 Teori
Som fundament til ellipseapproksimationen bruges et binært
billede, som er resultatet af Binary-klassen. Det binære
billede er et 2-dimensionelt array, hvor der på hver plads
står enten 0 eller 255. På den måde er det entydigt afklaret,
hvad der er forgrund og baggrund (figur 9.2). Funktionen
bxy (, ) beskriver det binære array:
⎧⎪
255
bxy (, ) = ⎨
⎪⎩
0
(9.1)
Dermed kan arealet af objektet bestemmes som:
Figur 9.1
3 sæt af interessante ellipseparametre
θmin
or
θmajor
x,y 0 0
A = ∫∫ b(, x y) dx dy
(9.2)
y
b
Figur 9.2
bxy (, ) definerer objektet
b(x,y) = 255
b(x,y) = 0
x
Side 34 af 131

9 EllipseApproximation 9.2 Teori
9.2.1 Massemidtpunkt
I forbindelse med udregningen af objektets orientering, er det nødvendigt at finde midten af
objektet. Der findes en analogi imellem midtpunktet og fysikkens massemidtpunkt. Det kan antages
at et objekts arealmidtpunkt, svarer til et objekt af samme forms massemidtpunkt, der har en
konstant masse per arealenhed. I det 2-dimensionelle plan kan momenterne omkring x- og y-aksen
bestemmes som koordinatet multipliceret med pixelintensiteten:
I () x = xb(,) x y
x
I () y = yb(, x y)
y
Findes gennemsnittet af inertimomenterne i begge dimensioner, findes x- og y-koordinatet for
massemidtpunktet af objektet ( , )
xy :
∫∫ ∫∫
∫∫ ∫∫
x b(, x y) dx dy yb(, x y) dx dy
x = , y =
b(, x y) dx dy b(, x y) dx dy
Hermed er koordinaterne for massemidtpunktet i objektet fundet.
9.2.2 Orientering i planet
Formålet med dette afsnit er at udvikle en metode til at
bestemme orienteringen af objektet i planet i forhold til xaksen.
Det forudsættes at objektet er aflangt af form, og det
er denne retning det ønskes at finde. Dette kan gøres ved, at
bestemme den linie hvor inertimomentet i objektet er
mindst. Dvs. det afgøres ikke, hvad der er top og bund, blot
hvilken orientering objektet har i planet.
Det ønskes at finde den linie der angiver, hvor inertimoment
(I) er mindst. Dette ønskes altså at bestemme minimum af
flg. formel:
2
I = ∫∫ r b(, x y) dxdy (9.5)
, hvor r er den korteste afstand fra et punkt (x,y) i objektet,
til et punkt (x 0,y 0) på linien der ønskes fundet (figur 9.3).
En detaljeret gennemgang af den bagvedliggende matematik kan findes i Appendiks 18.5 Orientering i
planet s. 89. Dog kan der her fremhæves to vigtige resultater fra gennemgangen. Ligningen for
inertimomentet i objektet kan udtrykkes som:
(9.3)
(9.4)
1 1 1
I = ( A+ C) − ( A−C) cos2θ− Bsin
2θ
(9.6)
2 2 2
, hvor A, B og C er integraler der afhænger af objektets form.
y
(x,y)
r
(x0,y0)
b(x,y)
Figur 9.3
(, xy) er et tilfældigt punkt i objektet
bxy
(, )
x
Side 35 af 131

9 EllipseApproximation 9.2 Teori
Der findes en løsning til henholdsvis cos2θ og sin 2θ . Disse kan indsættes i ligning (9.6). Hver af
de to løsninger har hver en negativ og positiv løsning. Anvendes den negative løsning i både
cos2θ og sin 2θ , fås det mindste inertimoment I min, og tilsvarende giver de positive løsninger det
største inertimoment I max. Disse skal senere anvendes direkte til at bestemme længden på
henholdsvis lille- og storaksen i ellipsen.
Vinklen til storaksen i ellipsen kan bestemmes som:
θ =
major
1 arcsin
2
9.2.3 Vigtige tilfælde
( ) 2
⎛
B
⎞
⎜ ⎟
⎜ 2
B + A−C ⎟
⎝ ⎠
Det er nødvendigt at vurdere resultatet af udregningen af vinklen i forhold værdierne af integralerne
A og C i Appendiks 18.5 Orientering i planet s. 89. Problemet kan illustreres, ved at forestille sig to
ellipser der begge er roterede henholdsvis 22,5° og 67,5° (figur 9.4):
Figur 9.4
22,5° og 67,5° giver samme vinkelresultat
Forskellen imellem de to ellipser er umiddelbart deres drejning i planet, men udregnes vinklen de er
roterede med ligning (9.7) fås begge som resultat 22,5°. Dvs. en ellipse der er drejet 67,5° i planet
detekteres til at være drejet 22,5°. Faktum er, at størrelsesforholdet mellem integralerne A og C
afhænger af vinklingen i planet:
A < C for θ < 45°
major
A = C for θ = 45°
major
A > C for θ > 45°
major
Dette er i sig selv godt nok, men da (A-C) kvadreres i nævneren i ligning (9.7), vil vinkler over og
under 45° give det samme resultat. Derfor skal størrelsesforholdet mellem A og C undersøges, hvis
det vil vurderes, om den vinkel der er udregnet ligger over eller under 45°. Hvis vinklen ligger over
45°, skal den udregnes som 90° - 45°. Dette svarer til en spejling omkring 45°.
(9.7)
(9.8)
Side 36 af 131

9 EllipseApproximation 9.2 Teori
Den anden problemstilling ligger i, hvis ellipsen er den særlige cirkelform, hvor excentriciteten er 0. I
denne situation vil B=0 og A=C. Da ellipsen er helt cirkulær, giver det ikke mening at tale om en
akse i cirklens længderetning.
9.2.4 Bestemmelse af ellipseparametre
Inertimomenterne og vinklen udregnet i foregående afsnit skal bruges direkte til at bestemme de
resterende ellipseparametre. Det ønskes, som beskrevet i indledningen, at finde længderne på stor-
og lilleaksen samt excentriciteten.
Det gælder at:
2
Imin b
= (9.9)
2
I a
max
Længderne b og a kan herefter bestemmes ud fra 2 relationer:
e =
2
b
1 − 2
a
(9.10)
A = abπ
(9.11)
, hvor e er excentriciteten og A er arealet af ellipsen. Det beskrives nærmere i Appendiks 18.6
Bestemmelse af ellipseparametre s. 91, hvorledes længderne a og b, kan bestemmes som:
a
=
π
A
I
I
min
max
(9.12)
A
b = (9.13)
π a
Hermed er der udledt udtryk for bestemmelse af længderne af stor- (a ) og lille-akse (b ) samt excentriciteten
(e ).
Side 37 af 131

9 EllipseApproximation 9.3 Test
9.3 Test
9.3.1 Beskrivelse
Det ønskes, at teste hvorvidt ellipseapproksimationsalgoritmen virker efter hensigten. Det er
beskrevet i indledningen, at ellipseapproksimationsalgoritmens formål er at på enhver given form at
kunne approksimere en ellipse. Det kan være svært ved alene visuel inspektion, at afgøre hvorvidt
ellipsen er korrekt approksimeret, når der arbejdes med irregulære former. Derfor er det besluttet, at
første del af testen går på at anvende ellipser som input til algoritmen. Det må være således, at hvis
algoritmen kan analysere en ellipse i inputbilledet, uden at ”være klar over” det er en ellipse, og så
bestemme en ellipse, der med rimelighed passer på inputellipsen, så må algoritmen være
funktionsduelig. Succeskriteriet er altså opnået såfremt algoritmen bestemmer en ellipse, der passer
på inputellipsen. Det er ikke muligt, at afgøre hvor godt ellipsen skal tilpasses, da der ikke stilles krav
herom fra nogen steder.
Det vurderes, at det er interessant at teste algoritmens reaktion på forskellige varierende parametre:
• Excentricitet
• Størrelsen på figur
• Vinkel med x-akse
• Alle ovenstående kombineret
Anden del af testen går på, at teste hvorvidt algoritmen kan tilpasse en ellipse til et objekt, der ikke
er ellipseformet, heriblandt firkanter, trekanter og polygoner.
For at anskueliggøre resultaterne af testen på en simpel og overskuelig måde, er det besluttet at
anvende Draw- og Color-klassen til henholdsvis at tegne og udskrive de udregnede ellipser i et
BMP-billede. Det skal derfor bemærkes, at der i er mulighed for at testresultaterne påvirkes, da
andre algoritmer anvendes til at udskrive dem, men det vurderes af gruppen, at disse påvirkninger er
minimale.
Som input til algoritmen blev 2 billeder lavet (figur 9.5 og figur 9.6, vises her i nedskaleret form):
Side 38 af 131

9 EllipseApproximation 9.3 Test
Figur 9.5
1. testbillede der var input til algoritmen. Her testes algoritmens evne til at approksimere en ellipse til en ellipse
Figur 9.6
2. testbillede med trekanter, firkanter og andre polygoner
Side 39 af 131

9 EllipseApproximation 9.3 Test
9.3.2 Testresultater
Ved afvikling af algoritmen blev flg. billeder outputtet som resultat (figur 9.7 og figur 9.8). Det
anbefales at nærstudere billederne vedlagt på DVD’en under ”9. EllipseApproximation
\Testresultater”, da billedet er af høj opløsning og vises nedskaleret her:
Figur 9.7
Testresultater fra 1. billede
Side 40 af 131

9 EllipseApproximation 9.4 Sammenfatning
Figur 9.8
Testresultater fra 2. testbillede
9.4 Sammenfatning
Det kan overordnet konkluderes, at det har været muligt at fremstille en algoritme, der kan
approksimere en ellipse til en given form. Som beskrevet i indledningen til testen, afgøres det ikke
kvantitativt, hvor godt ellipserne passer til figurerne, men kun rent kvalitativt.
Det ses, at i den første del af testen, hvor inputtet til algoritmen er ellipseformer, tilpasses ellipserne
med stor nøjagtighed til inputellipserne. Først er der bestemt et massemidtpunkt i figuren. Herfra
har ellipsens to principale akser deres begyndelse. Det ses tydeligt, at de tilpassede ellipsers lille- og
storakser passer med inputellipsernes lille- og stor-akser. Ydermere ses det her, at ellipseapproksimationen
fungerer lige vel ved forskellige excentriciteter, størrelser og vinkler og kombinationer heraf.
Ved nærundersøgelse af billedet (ved mange gange zoom) ses det, at ved mange af ellipserne (f.eks.
20 til og med 30) er massemidtpunktet forskudt en smule. Dette ses i form af, at det sted, hvor de to
akser i ellipsen krydser, ikke er det udregnede massemidtpunkt, men at massemidtpunktet ligger lige
ved siden af. Dette skyldes afrunding i forbindelse med tegningen af akserne, og har ikke noget med
ellipseapproksimationsalgoritmen som så at gøre, men problemet opstår i forbindelse med selve
tegningen af akserne i Draw-klassen. Dette er et nødvendigt onde for at kunne præsentere
resultaterne på denne mere overskuelige måde.
I den anden del af testen ses det, at algoritmen tilpasser en ellipse med succes til forskellige andre
typer af inputformer end ellipser. Som det fremgår, opnås der også her gode resultater. Det ses, at
ellipsens areal stemmer overens med objekternes areal, da det areal der ligger uden for objektet
svarer til det areal af objektet, der ligger uden for ellipsens areal.
Ellipserne med nr. 20, 21, 22 er alle tegnet med samme excentricitet. Men som det fremgår af
testresultaterne, så har nr. 20 og 22 en vinkel fra storaksen til det vandrette plan på 90°. Dette skyldes,
at algoritmen har fundet en (meget lille) unøjagtighed i ellipsens form. Denne unøjagtighed gør,
at integralerne A og C ikke er lige store, selvom det dog er tæt på. Som omtalt tidligere, vil en ellipse
med excentricitet på 0 gøre at A=C og B=0. I tilfældet med nr. 20 og 22 er A dog meget tæt på at
være lig C, men ikke helt, og dette giver derfor en vinkel på 90° og ikke 0°.
På mange af ellipserne på det 2. testbillede (f.eks. nr. 37 og 39) ses et synsbedrag. Ellipsen der fittes
til firkanten er faktisk cirkulær, men når den ses approksimeret til en firkant, ligner den nærmest en
superellipse. Dette er dog ikke tilfældet i virkeligheden, og altså kun et synsbedrag. Det vurderes
Side 41 af 131

9 EllipseApproximation 9.4 Sammenfatning
også her, at ved approksimering til forskellige andre former end ellipser, virker algoritmen efter
hensigten.
Samlet kan det konkluderes, at EllipseApproximation-klassen korrekt approksimerer en ellipse til
inputobjektet.
Side 42 af 131

9 EllipseApproximation 9.4 Sammenfatning
Del II: Klassificering af kimplanter
Anden del af rapporten handler om klassificering af kimplanter. Overordnet set vil der i denne del
blive udviklet algoritmer, der kan udvælge godkendte kim i forhold til klassificeringsregler (3.4
Klassificering s. 12) givet af Jens Iver Find (KU). I TopDetection- og ExpandShrink-klasserne
gennemgås det, hvorledes toppen på et kim kan findes. Symmetry-klassen viser, hvordan det er
muligt at bestemme symmetrien i et kim. Sidste klasse i Del II er Quality. I denne klasse gennemgås
forskellige metoder, der kan anvendes til at adskille godkendte fra ikke-godkendte kim.
Side 43 af 131

10 ExpandShrink 10.1 Indledning
10 ExpandShrink
10.1 Indledning
Formålet med ExpandShrink-klassen er at skabe en måde hvorpå, det er muligt at udfylde indhak i
et objekt. Behovet for klassen bliver først beskrevet i det næste kapitel om TopDetection-klassen,
men gennemgås nu da klassens metoder skal anvendes i TopDetection.
ExpandShrink-klassen indeholder to algoritmer. Disse har til formål, i samarbejde, udfylde skarpe
indhak i et objekt. Dette kan gøres ved først at lægge et antal pixels til på objektet (”expande”) for
derefter at trække et tilsvarende antal fra igen (”shrinke”), (Davies [3:33-34]).
10.2 Teori
10.2.1 Expand
Expand-algoritmen lægger en pixel til rundt i kanten på et objekt. Algoritmen traverserer gennem
billedet og undersøger hver enkel pixel. Når en hvid pixel er fundet, gøres alle dens naboer også
hvide. På figur 10.1 ses et 10 x 10 pixel stort billede, hvor objektet består af en enkel hvid pixel.
Denne pixel ønskes expanded én gang. Resultatet af denne operation fremgår af figur 10.2. Figur 10.2
er expanded én gang, da der er blevet lagt én pixel til rundt i kanten. Hvis der i stedet var blevet
expanded to gange, ville der blive lagt én pixel mere til rundt i kanten, og firkanten var dermed
blevet én pixel bredere i alle fire retninger:
Figur 10.1
En figur repræsenteret
ved én pixel
Figur 10.2
Resultat med én gang
expand
Det er dog ikke nok bare at udvide den enkelte pixel. Hvis den hvide pixel ligger ude i kanten, er den
afskåret fra at udvide sig i mindst en retning. Tages der igen udgangspunkt i et 10 x 10 pixel billede
(figur 10.3), hvor objektet igen er en enkel pixel, men denne gang er pixelen placeret i øverste venstre
hjørne (pixelen er gjort rød for lettere at følge den rundt i de forskellige figurer). Der ønskes stadig
kun at expande én gang. For at kunne gøre alle dens naboer hvide, er det nødvendigt at udvide
billedet. Dette er gjort på figur 10.4:
Side 44 af 131

10 ExpandShrink 10.2 Teori
Billedet udvides med antallet af gange det ønskes at expande gange to, i både i længde- og bredderetningen.
Dette svarer til at udvide billedet det antal gange, der ønskes at expande i alle 4 retninger.
Dvs. at hvis det ønskes at expande én gang i et 10 x 10 pixel billede, bliver det nye billede et 12 x 12
pixel billede. (På figur 10.5 er figur 10.3 og figur 10.4 vist oveni i hinanden for at demonstrere
princippet). Ønskes det derimod at expande to gange, bliver det nye billede derimod 14 x 14:
10.2.2 Shrink
Figur 10.6
Resultatet af én shrink operation
Figur 10.3
En figur repræsenteret
ved én pixel der ligger i
hjørnet
Figur 10.4
Her er billedet blevet udvidet
samtidig med at figuren er
expanded én gang
Figur 10.5
Figur 10.3 og figur 10.4 vist
oveni hinanden
Shrink-algoritmen fjerner en pixel hele vejen rundt i kanten. Algoritmen
fungerer lige modsat af expand-algoritmen. Den traverserer igennem et
billede, og finder alle pixels der er sorte. Derefter tegnes alle naboer også
sorte. Udføres shrink-algoritmen på figur 10.5, hvor det ønskes at shrinke
én gang, bliver resultatet som vist på figur 10.6. Det ses, at alle de hvide
pixels, som havde en sort nabo, nu også er blevet sorte.
De to algoritmer expand og shrink vil i de fleste
tilfælde blive kørt lige efter hinanden. Det kan
derfor være ønskværdigt at formindske billedets
dimensioner til den originale størrelse. Dette er
gjort på figur 10.7.
Det originale billede er nu genskabt. Operationen har i dette tilfælde ikke
ført til nogen ændring. Det er det samme billede, som til at begynde med. I
det næste afsnit, bliver det beskrevet hvordan en kombination af de to
algoritmer kan anvendes til noget praktisk.
Figur 10.7
Resultatet af en trunkering
Side 45 af 131

10 ExpandShrink 10.2 Teori
10.2.3 Expand og Shrink
Figur 10.8
En figur med indhak
Figur 10.10
Samlet resultat af
expand og shrink
kombineret hvor det ses
at den ene pixel i
toppen er udfyldt
Det kan altså lade sig gøre at lægge x antal pixels
på i kanten af et objekt, og derefter fjerne et
tilsvarende antal igen. Dette vil blive udnyttet til
udfylde skarpe knæk eller indhak. Et eksempel på
et objekt ses på figur 10.8.
Afvikles expand-algoritmen én gang på dette
objekt, fås et nyt billede som det på figur 10.9.
Det blå i figuren, viser de pixels, som er blevet
tilføjet ved afvikling af expand-algoritmen.
Afvikles shrink-algoritmen nu én gang på objektet, kommer resultatet til at
se ud som på figur 10.10.
Det ses, at der er en pixel ekstra på dette nye objekt i forhold til det originale.
Hullet er altså blevet udfyldt. Denne ekstra pixel kaldes i resten af denne
rapport en expand-shrink-pixel.
Havde man i stedet for kun at expande og shrinke én gang gjort det to
gange, ville der blive udfyldt endnu mere. Figur 10.11 viser, hvordan at 10 x
10 pixel billedet er blevet udvidet til et 14 x 14 billede. De blå pixel viser igen
dem, som er blevet tilføjet.
Figur 10.11
Resultatet af to gange expand
Køres shrink-algoritmen nu to gange på figur 10.11, bliver resultatet, som det ses på figur 10.12.
Figur 10.12
Resultat efter to gange
expand og to gange
shrink
Figur 10.9
Resultat af én gang expand
Det ses, at der denne gang er blevet tilføjet 4 expand-shrink-pixels i forhold til tidligere. Det ville på
dette objekt ikke given nogen ændring at expande og shrinke mere end to gange, da der ikke er flere
indhak, der kan blive udfyldt.
Side 46 af 131

10 ExpandShrink 10.3 Test
10.3 Test
For at sikre, at de to algoritmer virker efter hensigten, er der udført tre test. De to af dem verificerer,
at henholdsvis expand- og shrink-algoritmerne virker efter hensigten. Den sidste tester
kombinationerne af de to. Alle test samt testresultater findes på DVD i mappen ”10.
ExpandShrink”.
10.3.1 expand()
For at teste expand-algoritmen er figur 10.3 blevet benyttet. Denne er vist sammen med resultatet på
figur 10.13:
Originalbilledet var 10 x 10 pixel, hvor pixelen i øverste venstre hjørne var hvid. Resultatbilledet blev
et 12 x 12 pixel billede, med alle nabopixelene omkring pixelen i hjørnet farvet hvide.
10.3.2 shrink()
Testen af shrink-algoritmen vises i figur 10.14, hvor både input- og outputbillede er vist sammen.
Billedet som algoritmen blev kørt på, var et 12 x 12 pixel billede. Resultatbilledet blev et 10 x 10
pixel billede magen til udgangsbilledet i figur 10.13.
10.3.3 expand() og shrink()
Figur 10.13
Her ses udgangsbilledet samt resultatet af 1 gang expand
Figur 10.14
Viser billedet, som shrink-algoritmen blev udført på, samt
resultatet
For at se, hvordan de to algoritmer virker sammen, er der lavet en test på billedet figur 10.8 fra afsnit
10.2.3 Expand og Shrink s. 46.
Side 47 af 131

10 ExpandShrink 10.4 Sammenfatning
Figur 10.15 viser først det originale billede, som er 10 x 10 pixel, inden algoritmen er kørt på det.
Derefter vises resultatet af expand-algoritmen, hvor billedet er blevet udvidet til 12 x 12 pixel, og der
er lagt en pixel på hele vejen rundt i kanten. Efter shrink-algoritmen er billedet igen blevet 10 x 10
pixel, og det ses at den sorte pixel i toppen af objektet er blevet hvid.
10.4 Sammenfatning
Figur 10.15
På figuren ses inputbilledet, derefter vises expand-resultatet,
og til sidst det endelige resultat efter shrink
Det kan overordnet konkluderes, at det er lykkedes, at lave en klasse hvor det kan lade sig gøre at
fjerne skarpe indhak eller knæk.
Testen af expand-algoritmen viser, at resultatet er præcis som forventet, og i overensstemmelse med
teorien. Alle naboer til hvide pixels bliver hvide, og billedet bliver udvidet to gange antallet af gange,
det ønskes at expande. Med dette opnås det, at det altid kan lade sig gøre, at tegne nabopixelene
hvide.
Shrink-algoritmen blev testet på det billede, som var resultatet af expand-algoritmen. Efter billedet
var blevet behandlet af shrink-algortimen, havde det den oprindelige størrelse, og med kun en hvid
pixel i øverste venstre hjørne, hvilket var hvad der ønskedes at opnå.
Kombinationen af expand og shrink blev testet på en figur, der havde et indhak i toppen. Efter
begge algoritmer var blevet kørt på billedet, blev resultatet et nyt billede hvor indhakket i toppen var
blevet udfyldt. Det kan hermed konkluderes, at det er lykkedes at lave en algoritme, der virker efter
hensigten.
Side 48 af 131

11 TopDetection 11.1 Indledning
11 TopDetection
11.1 Indledning
Formålet med TopDetection er, at kunne finde enten top eller
bund på kimene. Dette ønskes gjort, da en robot skal kunne gribe
kimene, og lægge dem op på række ved siden af hinanden, således
at toppene vender henholdsvis den ene eller den anden vej. På
denne måde bliver der plads til, at kimene kan vokse på et mindre
areal, og dermed udnyttes den skål, hvori de ligger, bedre.
Algoritmen skal optimeres til at virke på kim, som ikke bliver sorteret
fra pga. deres dårlige kvalitet (dette gennemgås nærmere i 13
Quality s. 60).
11.2 Teori
Der er lavet en brainstorm som findes i Appendiks 18.7 Valg af
TopDetection-algoritme s. 93. Heri beskrives det, hvilke algoritmer gruppen i
fællesskab, har fundet frem til i brainstormen. Ydermere gennemgås en
særlig rating, der blev foretaget, for at kunne udvælge algoritmen, gruppen
mente havde det største potentiale. Valget faldt på Arealforskel-algoritmen.
11.2.1 Arealforskel
Arealforskel-algoritmen bygger på at kimet har
indhak, der hvor der er kimbladsstruktur. Når det
forstørres og derefter mindskes igen med
ExpandShrink, bliver disse indhak udfyldt. Det
originale kim-objekt sammenlignes derefter med
dette modificerede kim-objekt. Dette giver en
arealforskel i toppen (figur 11.1).
Ved at subtrahere de to objekter fra hinanden, opstår
der små arealer, der hvor der er forskel mellem dem
(figur 11.2). Man kan være uheldig, at der opstår arealer
andre steder end i toppen, det kan derfor være
nødvendigt at udglatte eventuelle urenheder langs
kanten af objektet.
Når delarealerne er fundet, beregnes deres massemidtpunkt,
også kaldet top-massemidtpunkt. For at
undgå for megen vægtning af arealer, som ikke ligger
i toppen, kan man i stedet vælge det enkelte delareal,
der er størst. Dette skulle gerne ligge i toppen.
Ud fra den linie, der opstår mellem top-massemidt-
Massemidtpunkt fra
ellipseapproksimation
Figur 11.1
Arealforskel
Massemidtpunkt fra
ellipseapproksimation
Massemidtpunkt fundet
ved subtrahering
Figur 11.2
Viser de delarealer der
opstår
Massemidtpunkt fundet
ved subtrahering
Figur 11.3
Viser to forskellige scenarier hvor toppen detekteres i
hver deres ende
θ
θ
Side 49 af 131

11 TopDetection 11.2 Teori
punktet, og massemidtpunktet fundet i ellipseapproksimationen,
beregnes vinklen til det vandrette plan (figur 11.3).
Det er afgørende på hvilken side af ellipsens lilleakse, top-
massemidtpunktet ligger. Hvis vinklen til kimets top
( θ topmassemidtpunkt ), detekteres til at ligge i samme ende som vinklen
til storaksen ( θ major ), er følgende udsagn gældende (figur 11.4):
θ ellipselilleakse > θ top massemidtpunkt > θellipselilleakse − π (11.1)
Hvis udsagnet er opfyldt, ligger top-massemidtpunktet i det skraverede
område i figur 11.4, og det tilføjes i seed-objektet, at toppen
har samme vinkel som storaksen. Ligger toppen ikke i det skraverede
område, lægges der 180 º til storaksens vinkel, inden dette tilføjes
i seed-objektet. På denne måde er det muligt at fastlægge, i hvilken
ende af kimet toppen er fundet.
11.2.1.1 Beregning af vinkel
For at kunne beregne θ top massemidtpunkt , som den-
ne danner med det vandrette plan, tegnes en
retvinklet trekant (figur 11.5). Hertil anvendes, at
det gælder, at cosinus til en af de to ikke rette
vinkler er det samme, som forholdet mellem
hypotenuse og hosliggende katete. Hypotenusens
længde kan beregnes vha. Pythagoras, og
katetens længde beregnes ved at trække koordinaterne
fra hinanden.
b
cos( θ ) =
c
b
θ= arccos
⎛ ⎞
⎜ ⎟
⎝c⎠ (11.2)
11.2.1.2 Subtrahering af billeder
( ) ( )
2 2
M2 M1 M2 M1
c = x − x + y −y
( x , y )
M1 M1
Figur 11.5
Beregning af vinkel
top − massemidtpunkt
storakse
θtopmassemidtpunkt major θ
Figur 11.4
Figuren viser tilfældet hvor Ligning
(11.1) er sand. Top-massemidtpunktet
ligger i det skraverede område
Subtraheringen, som tidligere beskrevet i dette afsnit, bygger på, at billederne er lige store og er sorthvide.
Resultatet af metoden er et nyt billede, med forskellene tegnet ind.
Først oprettes der et nyt billede, med de samme dimensioner, som de to der ønskes sammenlignet.
Derefter sammenlignes hver enkel pixel i de to billeder, og resultatet af denne sammenligning skrives
i det nye billede. Hvis der ikke er nogen forskel, gøres den tilsvarende pixel, i det nye billede, sort.
Hvis der er en forskel, markeres denne med hvid. Resultatet af en sådan operation på figur 11.6 og
figur 11.7, kan ses på figur 11.8.
θ
b = x − x
M2 M1
( x , y )
M2 M2
A C
B
a = y − y
M2 M1
Side 50 af 131

11 TopDetection 11.3 Test
11.3 Test
Det er formålet med testen, at bestemme hvilken kombination af parametre, der bedst finder toppen
det rigtige sted. Algoritmen er anvendt på 3 billeder. På hvert billede er der 25-30 kim, som alle er
godkendte. Algoritmen er kørt 30 gange på hvert billede, hvor følgende parametre varierer:
• Den første ExpandShrink-operation, der fjerner urenheder
• Den anden ExpandShrink-operation, der bruges til at finde forskel
• Massemidtpunkt for det største eller summen af delarealerne der opstår ved subtrahering
Det er testens formål, at finde den bedste kombination af ovenstående parametre. På DVD’en
findes test samt testresulater i mappen ”11. TopDetection”.
11.3.1 Testresultater
Testresultaterne for et af billederne, fremgår af tabel 11.1. Resten af testresultaterne findes i
Appendiks 18.11 Test af TopDetection s. 127. Kolonnen ”Arealer” indeholder enten værdien ”alle
arealer”, eller ”største areal”. Dette skal indikere, om det er valgt at beregne top-massemidtpunktet
ud fra alle delarealer, der opstår ved subtrahering af de to billeder, eller om det er det største af de
enkelte delarealer, der skal bruges. Den næste kolonne er ”Antal udglatninger”. Denne værdi
indikerer hvor kraftigt kanten skal glattes ud, inden det bliver forsøgt at finde en forskel. ”Antal
ExpandShrink” er det antal gange, der skal expandes og shrinkes, inden der foretages en
sammenligning af de to billeder. ”Rigtigt fundne”-kolonnen indeholder antallet af kim, hvor toppen
blev fundet det rigtige sted. ”Forkert fundne”-kolonnen indeholder antallet af kim, hvor toppen er
fundet til at ligge i den forkerte ende af kimet.”Udefinerede”-kolonnen er hvor, der ikke har været
nogen forskel mellem de to billeder, der skulle sammenlignes. Den sidste kolonne angiver i procent,
hvor effektiv algoritmen har været til at finde toppen det rigtige sted.
Kombination
Figur 11.6
Det første billede i subtraheringen
Arealer Antal
Udglatning
Figur 11.7
Det andet billede i subtraheringen
Antal
Expand-
Shrink
Antal
rigtigt
fundne
Figur 11.8
Resultat af subtraheringen
Antal
forkert
fundne
Antal
udefinerede
1 Alle arealer 0 1 19 3 3 76,00
2 Alle arealer 0 2 23 1 1 92,00
3 Alle arealer 0 3 24 1 0 96,00
4 Alle arealer 0 4 24 1 0 96,00
5 Alle arealer 0 5 24 1 0 96,00
6 Alle arealer 1 1 16 2 7 64,00
7 Alle arealer 1 2 19 4 2 76,00
8 Alle arealer 1 3 19 5 1 76,00
9 Alle arealer 1 4 19 5 1 76,00
10 Alle arealer 1 5 19 5 1 76,00
11 Alle arealer 2 1 5 5 15 20,00
%
Side 51 af 131

11 TopDetection 11.3 Test
12 Alle arealer 2 2 8 6 11 32,00
13 Alle arealer 2 3 8 6 11 32,00
14 Alle arealer 2 4 8 6 11 32,00
15 Alle arealer 2 5 7 7 11 28,00
16 Største areal 0 1 14 6 5 56,00
17 Største areal 0 2 21 2 2 84,00
18 Største areal 0 3 22 2 1 88,00
19 Største areal 0 4 23 1 1 92,00
20 Største areal 0 5 23 1 1 92,00
21 Største areal 1 1 13 5 7 52,00
22 Største areal 1 2 17 6 2 68,00
23 Største areal 1 3 19 5 1 76,00
24 Største areal 1 4 19 5 1 76,00
25 Største areal 1 5 19 5 1 76,00
26 Største areal 2 1 5 5 15 20,00
27 Største areal 2 2 7 6 12 28,00
28 Største areal 2 3 8 5 12 32,00
29 Største areal 2 4 8 5 12 32,00
30 Største areal 2 5 7 6 12 28,00
Tabel 11.1
Testresultater
Ved at tage gennemsnittet af kolonnen ”%” for de billeder testen blev udført på, findes den
kombination, som giver det bedste resultat (tabel 11.2).
Kombination Billede 1 [%] Billede 2 [%] Billede 3 [%] Gennemsnit [%]
1 76,00 76,00 70,37 75,46
2 92,00 92,00 92,59 92,20
3 96,00 96,00 92,59 92,20
4 96,00 96,00 92,59 92,20
5 96,00 96,00 92,59 92,20
6 64,00 64,00 62,96 67,65
7 76,00 76,00 85,19 81,73
8 76,00 76,00 85,19 81,73
9 76,00 76,00 88,89 82,96
10 76,00 76,00 88,89 82,96
11 20,00 20,00 18,52 28,84
12 32,00 32,00 37,04 40,35
13 32,00 32,00 40,74 42,91
14 32,00 32,00 44,44 42,81
15 28,00 28,00 48,15 42,72
16 56,00 56,00 70,37 68,79
17 84,00 84,00 92,59 88,20
18 88,00 88,00 88,89 88,30
19 92,00 92,00 85,19 88,40
20 92,00 92,00 85,19 88,40
21 52,00 52,00 66,67 63,56
22 68,00 68,00 85,19 79,06
23 76,00 76,00 81,48 80,49
24 76,00 76,00 81,48 80,49
25 76,00 76,00 81,48 79,16
26 20,00 20,00 22,22 30,07
27 28,00 28,00 37,04 39,01
28 32,00 32,00 40,74 42,91
29 32,00 32,00 44,44 42,81
30 28,00 28,00 48,15 41,38
Tabel 11.2
Gennemsnit af testresulatater
Det ses at det er kombination 2, 3, 4 og 5, der giver det bedste resultat. De finder toppen det rigtige
sted på 92,2 % af kimene.
Side 52 af 131

11 TopDetection 11.4 Sammenfatning
11.4 Sammenfatning
Der fremkom en del idéer under brainstormingen, som er blevet vurderet, og undersøgt nærmere.
Valget faldt på metoden Arealforskel, som der blev arbejdet videre med.
Testen viser, at det ikke er nødvendigt at forsøge at udjævne kanten på kimene med den første
ExpandShrink-operation. Det kan også ud fra testen konkluderes, at det er mest fordelagtigt at
anvende alle delarealer til beregning af top-massemidtpunktet. Den viser også, at kombination 2, 3, 4
og 5 er lige gode. Valget af den kombination, der skulle implementeres, faldt på kombination 4, da
denne ligger imellem to, som giver det samme resultat.
Det lykkedes, at lave en algoritme, der med omkring 90 % sikkerhed placerer toppen det rigtige sted.
Da TopDetection mere er en ”nice to have feature” end et reelt krav, ser gruppen sig tilfreds med
resultatet. Hvis dette skulle forøges, skal det undersøges om algoritmen kan forbedres, eller om man
skal starte forfra med at finde på nye idéer.
Side 53 af 131

12 Symmetry 12.1 Indledning
12 Symmetry
12.1 Indledning
Det er formålet med Symmetry-klassen,
at skabe en
måde hvorpå det er muligt,
at vurdere i hvor høj grad
objektet er symmetrisk omkring
dets længdeakse (figur
12.1). Dette skal bruges i
forbindelse med kvalitetsvurderingen
af kimene. Bestemmelsen
af symmetrien
foregår lettest ved at traversere
objektet på begge
sider (a og b) af længdeaksen,
og undersøge om hvert
koordinat forefindes på den
modsatte side af længdeaksen.
På den måde er det
muligt at tælle op hvor mange
pixels, der ikke har en
symmetripartner (symmetripixel),
og vurdere hvor sym-
metrisk objektet er. Herefter skal antallet af symmetripixels vægtes med arealet af objektet, for at det
er muligt at vurdere kimenes symmetri med hinanden.
12.2 Teori
Figur 12.1
Objektet traverseres på begge siden af længdeaksen
Algoritmen skal kunne traversere igennem alle pixels i objektet, på begge sider af længdeaksen, og
undersøge om der findes en hvid pixel på den modsatte side af denne. Metoden for at bestemme
antallet af symmetripixels i et objekt er som følger (figur 12.2 - figur 12.6):
1. Algoritmen går alle pixels i objektet igennem. Hvis pixelen er en forgrundspixel fortsætter
algoritmen. Punktet A er den aktuelle pixel i figuren, hvor det skal undersøges, om den har
en symmetripartner på den modsatte side.
2. Punkt A omregnes til B, som ligger i et koordinatsystem hvor massemidtpunktet CM er
origo.
3. B roteres nu, så figurens længdeakse er sammenfaldende med b.x-aksen, B bliver nu C.
Herefter bestemmes symmetripartneren til C som D.
4. D roteres tilbage igen, og bliver til E.
5. E omregnes til F, således CM ikke længere er origo.
6. Det undersøges om F er en hvid pixel. Hvis dette er tilfældet har A en symmetripartner i F.
Figuren i illustrationerne er kun tegnet for at hjælpe på forståelsen, ved at illustrere hvordan A flytter
rundt i koordinatsystemet i forhold til figuren. Det er ikke hensigten, at alle punkter i figuren skal
indgå i udregningerne i hvert trin. Det er kun punkterne A-F, der skal udregnes i alt. Dette gør, at
algoritmen vil være mulig at afvikle relativt hurtigt.
y
y
x
x
Side 54 af 131

12 Symmetry 12.2 Teori
y
CM(x cm, y cm )
(0, 0)
A(x 1, y 1)
Figur 12.2
Trin 1: Det ønskes undersøgt om der findes et
punkt modsat A på den anden side af
længdeaksen
a.y
(0, 0)
B(a.x 1, a.y 1)
?
x
(0, 0)
(0, 0)
D(b.x 2, b.y 2)
Figur 12.4
Trin 3: Objektet roteres ned og D bestemmes
E(a.x 2, a.y 2)
a.x
Figur 12.5
Trin 4: Der roteres op igen så D bliver til E
B(a.x 1, a.y 1)
Figur 12.3
Trin 2: Koordinatsystem centreres omkring CM
C(b.x 1, b.y 1)
CM(x cm, y cm )
(0, 0)
A(x 1, y 1)
F(x 2, y 2)
Figur 12.6
Trin 5: E bliver til F ved at koordinasystemet
rykkes væk fra CM igen
Side 55 af 131

12 Symmetry 12.2 Teori
12.2.1 Rotation af pixels
I trin 3 og 4 skal en pixel i objektet roteres en given vinkel. Til denne operation anvendes flg. ligning,
der roterer et punkt imod omløbsretningen:
x = x cos( −θ ) + ysin(
−θ)
2
y = ycos( −θ) −x sin( −θ)
2
(12.1)
I ligningen indgår koordinatsættet ( xy , ) , der ønskes roteret med vinklen θ . Resultatet er det
x , y .
roterede koordinatsæt ( )
2 2
12.2.2 Bestemmelse af løsningsmodel
Algoritmens udformning er et resultat af mange andre mulige løsningsmodeller, der dog hver havde
en brist. Én løsningsmodel, der ligger lige for er, at udføre trinnene 1-3 fra løsningsmodellen
ovenover, hvor man dog roterer alle pixelene i hele objektet i samme omgang. På den måde er hele
objektet roteret, og ligger med længdeaksen sammenfaldende med x-aksen. Herefter ville det være
nærliggende at foretage sammenligningen på tværs af længdeaksen i dette objekt. Der er dog et
problem ved det, da rotationen er en trigonometrisk
funktion, der afhænger af vinklen der ønskes drejet (figur
12.7). Figur 12.7 viser, at når objektet i billedet roteres til
det vandrette plan, vil hver pixel i billedet få et nyt (x,y)koordinat.
For at kunne foretage sammenligningen på
tværs af den vandrette længdeakse, skal alle værdierne
afrundes til heltal (pixels). Det er denne afrunding af de
roterede koordinater, der er problemet, fordi afrundingen
gør at nogle koordinatpar vil være sammenfaldne. Derfor
vil der opstå huller i det roterede objekt. Figur 12.8 viser et
objekt (kim) inden den roteres, og figur 12.9 viser objektet
efter rotationen. Billedet er et direkte udprint fra
algoritmens array til en BMP-fil:
Figur 12.8
Objekt før rotation
Figur 12.9
Objekt efter rotation
På figur 12.9 ses problemstillingen med sammenfaldne pixels tydeligt.
For at undgå dette problem, skal afrundingen undgås, og det gøres
ved at efter man har fundet pixelen på den modsatte side af
længdeaksen, roteres denne pixel tilbage i det oprindelige (x,y)domæne.
Dvs. i stedet for at afrunde pixelen og undersøge med det
θ
Figur 12.7
Ved rotation anvendes en trigonometrisk funktion
der giver nye x, og y-værdier
Side 56 af 131

12 Symmetry 12.3 Test
samme om pixelen er hvid, så roteres denne altså tilbage i det oprindelige (x,y)-domæne, og først her
foretages undersøgelsen om de roterede koordinater peger på en hvid pixel. Dette er da også
fremgangsmetoden beskrevet i afsnit 12.2 Teori s. 54.
12.3 Test
Testen blev foretaget på billedet nedenunder (figur 12.10):
Testresultaterne er angivet i tabel 12.1. ”Symmetry”-kolonnen indeholder billeder, der er blevet
udskrevet direkte fra Symmetry-klassen. Disse har sort baggrund, mens de pixels der har en
symmetripartner på den modsatte side af længdeaksen er hvid. De pixels der ikke blev fundet en
symmetripartner til er farvet grå. Testen bestås såfremt de hvide grupperinger i billederne i
”Symmetry”-kolonnen er symmetriske omkring længdeaksen:
Blobid EllipseApproximation Symmetry Symmetri [%]
0
1
2
3
4
5
Figur 12.10
Testbillede anvendt
96
94
71
34
92
77
Side 57 af 131

12 Symmetry 12.3 Test
Blobid EllipseApproximation Symmetry Symmetri [%]
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
42
86
88
56
55
32
79
82
80
93
64
69
89
75
60
Side 58 af 131

12 Symmetry 12.4 Sammenfatning
Blobid EllipseApproximation Symmetry Symmetri [%]
21
22
23
Tabel 12.1
Testresultater, hvor det hvide i figurerne i ”Symmetry”-kolonnen, er symmetripixels
12.4 Sammenfatning
Det kan overordnet konkluderes, at det har været muligt at lave en klasse, der kan angive hvor
symmetrisk et objekt er omkring dets længdeakse, vægtet i forhold til dets areal.
Det ses i testen, at klassen kan opgøre hvor stor en procentdel af pixelene, der har en
symmetripartner på den modsatte side af længdeaksen. De hvide pixels i billederne i ”Symmetry”kolonnen
er alle symmetriske objekter, der ligger omkring længdeaksen. Dermed kan det
konkluderes, at Symmetry-klassen korrekt finder symmetripixels i objektet.
33
45
41
Side 59 af 131

13 Quality 13.1 Indledning
13 Quality
13.1 Indledning
Formålet med Quality-klassen er at skabe en måde, hvorpå det er muligt, at udvælge kim der er af 1.
klasses kvalitet i henhold til 3.4 Klassificering s. 12. I Del I blev det vist, hvorledes det ukritisk er muligt
at identificere alle kim. Del II omhandler som nævnt kvalitetsvurdering, og det er Quality-klassen,
der rent praktisk skal sortere kimene. Klasser i Del I og II har evalueret kimene, og tilføjet deres
resultater til seed-objektet, men det er altså først i her i Quality-klassen, at alle kimenes parametre
bliver evalueret samlet. Opgaven er altså to-delt:
1. Det skal undersøges, hvorledes det er muligt at udvælge 1. klasses kim
2. Der skal udvikles programkode, der kan implementere de fundne metoder i 1
13.2 Teori
13.2.1 Bestemmelse af Kvalitetsparametre
Som nævnt skal der foretages en kvalitetssortering af kimene. Indledningsvis er det undersøgt, hvad
det er, der udgør et godt kim; hvilke parametre kan det være interessant at arbejde med. Gruppen
har i samarbejde med biolog Jens Iver Find fra Københavns Universitet studeret kimene nærmere. I
fællesskab er der fundet frem til 4 parametre, som det håbes at kunne bruge til at frasortere de ikkegodkendte
kim:
Den første parameter er arealet. Arealet er interessant af flere grunde. Den første er, at det giver
mulighed, for at frasortere kim, der rører ved hinanden, da arealet af disse lagt sammen, vil være
meget større end for et enkelt. Den anden grund er, at det giver muligheden for at frasortere helt
små prikker eller mindre grupper af pixels i billedet, som ikke er kim.
Den næste parameter, excentricitet, er interessant ud fra den betragtning, at kimenes form er aflang.
Excentriciteten er et udtryk for bredde i forhold til længde. Excentriciteten blev tidligere omtalt i
9.2.4 Bestemmelse af ellipseparametre s. 37. Ved brug af denne parameter, kan det lade sig gøre at
frasortere former, som er mere cirkulære og derved ikke ønskelige.
Ved at studere kimene var det tydeligt, at det ville være hensigtsmæssigt med en parameter, der
kunne give et udtryk for kimbladsstruktur. Det viste sig svært, at finde en parameter der netop kun
gjorde dette. Til gengæld blev der fundet en anden parameter som indirekte giver det ønskede
resultat. Denne parameter er antallet af expand-shrink-pixels (10.2.3 Expand og Shrink s. 46).
Parameteren er ikke direkte udtryk for kimbladsstruktur, men angiver i stedet for hvor kraftige
indhak, der er i objektet. Hvis der ingen indhak er, kan det med stor sikkerhed vurderes, at der ikke
er nogen kimblade, og i dette tilfælde vil expand-shrink-pixels-parameteren give 0 eller små værdier.
Hvis den derimod er stor, kan det både være et udtryk for at objektet er krumt, eller at det har
kimblade.
Den sidste parameter er symmetri i kimet som, fundet i kapitel 12 Symmetry s. 54. Ved symmetri
forstås, at det er symmetrisk omkring længdeaksen. Et godt kim, har som regel også en høj grad af
symmetri.
Side 60 af 131

13 Quality 13.2 Teori
De 4 parametre er samlet:
• Areal
• Excentricitet
• Expand-shrink-pixels
• Symmetri
Ved at kombinere disse parametre, skal det være muligt at udvælge alle de gode kim.
13.2.2 Manuel inspektion
For at fastslå hvor godt det, ved hjælp af parametrene, kan lade sig gøre at separere og udvælge de
godkendte kim fra de ikke-godkendte, er der brug for en prøve af kim. Disse kim er blevet manuelt
inspiceret med henblik på at vide hvor mange og hvilke kim, der objektivt er godkendte og ikkegodkendte
i en tilfældig distribution. På den måde kan man sammenligne med programmets
godkendelse af kim. I alt er der inspiceret 11 billeder med et samlet antal kim på 313. Af de 313 var
de 205 af dem ikke-godkendte, mens de resterende 108 var godkendte (billederne kan findes på
DVD’en i ”13. Quality\Test\Manuelt godkendte”).
For at visualisere hvordan godkendte og ikke-godkendte kim ligger i forhold til hinanden, er de
blevet plottet i et 3-dimensionelt plot (figur 13.1). De 3 akser repræsenterer 3 af de 4 parametre. Det
er ved forsøg blevet fastslået, at de 3 parametre der giver den bedste separation, er areal, symmetri
og expand-shrink-pixels. Det anbefales, at afvikle det MatLab-script der ligger på DVD’en under
”13. Quality\MatLab”, da dette giver mulighed for at rotere plottet og se det i original størrelse.
Figur 13.1
3-dimensionelt plot som viser hvor de godkendte (blå firkanter) og ikke-godkendte kim (røde cirkler) placerer sig
Side 61 af 131

13 Quality 13.2 Teori
På figur 13.1 er de røde cirkler de ikke-godkendte kim, og de blå firkanter er de godkendte. Det ses at
de godkendte kim fortrinsvis samler sig i venstre hjørne af plottet. Opgaven er nu at indhegne alle de
blå firkanter uden at udvælge nogen af de røde cirkler.
13.2.3 Bestemmelse af grænser
Til at indhegne de blå firkanter, kan der vælges flere geometriske figurer. Den mest simple figur er
en 3-dimensionel rektangulær boks, hvor længderne på siderne afgøres af en minimums- og
maksimums-værdier for de respektive parametre.
Figur 13.2
3-dimensionelt plot der viser en rektangulær boks, hvor alle de godkendte kim ligger indenfor grænserne
På figur 13.2 er en boks blevet plottet med grænser, som lige netop gør, at alle de blå firkanter ligger
indenfor boksen. Ud over de grænser, som bestemmes af de 3 parametre der ses i plottet, er også
excentriciteten medtaget, denne er dog bare ikke visuelt synlig i 3d-plottet.
Resultatet bliver, at de 108 godkendte kim ligger indenfor boksen, men desværre bliver også 54 ikkegodkendte
udvalgt.
Da det ikke kan lade sig gøre kun at udvælge alle godkendte og ingen ikke-godkendte kim, kan det
være interessant at forsøge at omgrænse dem med en anden form end boksen. F.eks. en 3dimensionel
ellipse (ellipsoide). En ellipsoide har runde former og giver dermed en blødere overgang
Side 62 af 131

13 Quality 13.2 Teori
imellem grænserne (figur 13.3). Ellipsoiden er ikke så simpel som boksen, og derfor opstilles følgende
teori for at beskrive dens funktionalitet:
Figur 13.3
Ellipsoide i 3-dimensionelt enhedskoordinatsystem
3-dimensionelle koordinater ( xyz , , ) , der opfylder følgende ligning, vil alle ligge på ellipsoidens
overflade:
⎛x −x ⎞ ⎛y −y ⎞ ⎛z −z
⎞
⎜ ⎟ + ⎜ ⎟ + ⎜ ⎟ =
⎝ a ⎠ ⎝ b ⎠ ⎝ c ⎠
2 2 2
0 0 0 1
, hvor
x 0 er centerpunktet for ellipsoiden i x-planet
a er semiaksen i x-planet
y 0 er centerpunktet for ellipsoiden i y-planet
b er semiaksen i y-planet
z 0 er centerpunktet for ellipsoiden i z-planet
c er semiaksen i z-planet
Derfor gælder det, at de koordinater der opfylder
følgende ulighed:
⎛x −x ⎞ ⎛y −y ⎞ ⎛z −z
⎞
⎜ ⎟ ⎜ ⎟ ⎜ ⎟
⎝ a ⎠ ⎝ b ⎠ ⎝ c ⎠
2 2 2
0 + 0 + 0 ≤1
, ligger inden for ellipsoiden.
(13.1)
Figur 13.4
Semiakse og centerpunkt for ellipsoide i x, z-planet
(13.2)
På figur 13.4 ses ellipsoiden fra siden, og det ses hvilken
betydning a har for ellipsoidens form. Det samme er gjort
på figur 13.5, hvor ellipsoiden ses fra enden for at vise b og
c .
Figur 13.5
Semiakser og centerpunkter for ellipsoiden i z,
y-planet
Side 63 af 131

13 Quality 13.2 Teori
Figur 13.6
3-dimensionelt plot der viser en ellipsoide hvor alle de godkendte kim ligger inden for grænserne
Med ellipsoiden, hvor den lige præcis omgrænser alle de godkendte, opnås et lidt bedre resultat end
med boksen (figur 13.6). Udover alle de 108 godkendte kim er der nu kun udvalgt 46 ikke-godkendte.
Det er altså ikke lykkedes at finde en form eller figur, der kan separere alle de godkendte kim fra de
ikke-godkendte. Selvom kimene samler sig i venstre side af det 3-dimensionelle plot, er der dog
stadig nogle ikke-godkendte i denne gruppe. Her kan der enten være tale om, at der skal findes en
parameter mere, eller at der skal forsøges med andre geometriske former. Måske skulle der findes
andre metoder end dem, som her er valgt. Emnet er utroligt stort og kompliceret, og derfor har det
ikke været muligt, at videreudvikle yderligere på parametrene og lave flere og større test, grundet den
begrænsede tid i projektet.
Gruppen har i stedet for valgt en anden fremgangsmetode. I stedet for at forsøge at udvælge alle
godkendte og ingen ikke-godkendte kim, vil det derimod blive forsøgt at udvælge så mange
godkendte uden at udvælge ikke-godkendte kim, ud fra den tankegang at kimene er relativt billige på
det trin hvor dette projekt skal håndtere dem, og at det er vigtigere at undgå at få ikke-godkendte
kim med.
Anvendes denne fremgangsmetode først med boksen opnår man, med de bedst tilpassede grænser,
at udvælge 54 godkendte uden at udvælge ikke-godkendte kim. Med ellipsoiden opnås at udvælge 51
godkendte og 0 ikke-godkendte.
Side 64 af 131

13 Quality 13.3 Test
13.2.4 Variable grænser
I det forrige afsnit er de to ekstremer beskrevet. Enten blev alle godkendte og nogle ikke-godkendte
kim udvalgt, eller også udvælges ingen ikke-godkendte og nogle godkendte kim. Imidlertid kan man
godt forestille sig, at en bruger af programmet kunne være interesseret i, at kunne vælge grænser, der
ligger imellem disse to yderpunkter. Ydermere kunne det også ske, at kimenes størrelse ændrede sig.
Der er altså et behov for at have justerbare grænser. Det skal derfor i en implementering af
kvalitetsvurderingen, være muligt at hente grænserne ind fra en ini-fil. Dermed bliver programmet
mere fleksibelt, og giver mulighed for at opfylde flere behov.
Da de 2 geometriske figurer kun er blevet undersøgt i ekstrempunkterne, og deres resultater imellem
disse ikke kendes, er det valgt, at det i implementeringen skal være muligt, for en bruger at vælge
hvilken af de to udvælgelsesmodeller (boks eller ellipsoide) der ønskes anvendt.
13.3 Test
Testafsnittet er delt i to dele. Den første del har til formål, at afdække hvorvidt koden der er udviklet
til klassen, er implementeret korrekt. Den anden del har til formål, at vise hvor godt teorien, med at
anvende boks og ellipsoide, virker.
13.3.1 Første del
13.3.1.1 Fremgangsmetode første del
Algoritmen anvendes på alle billederne med de 313 kim (findes på DVD’en under ”13.
Quality\Test\Første del”), som er vist i det 3-dimensionelle plot. Ved at benytte de fundne grænser
for henholdsvis ellipsoiden og boksen, skulle der opnås de samme resultater som blev fundet med
MatLab-scriptet i afsnit 13.2.3 Bestemmelse af grænser s. 62:
13.3.1.2 Testresultater første del
Resultatet er vist i tabel 13.1:
Type Grænser Godkendte Ikke
godkendte
Ellipsoide
Boks
Tabel 13.1
Resultat af første test
Smalle 51 0
Brede 108 46
Smalle 54 0
Brede 108 54
Side 65 af 131

13 Quality 13.3 Test
13.3.2 Anden del
Denne test skal vise, at anvendelsen af
justerbare grænser og de 2 udvælgelsesmodeller
også virker i praksis. Der
testes på billedet vist i figur 13.7. På
dette billede er de kim, der er manuelt
godkendt markeret med hvide cirkler.
Algoritmen skal ideelt udvælge disse
kim. For bedre at kunne konkludere
noget ud fra resultaterne af testen,
burde der anvendes mere end ét billede
til testen, men det var desværre ikke
muligt at fremskaffe kimprøver sidst i
projektets forløb. Det er ikke muligt at
anvende billederne fra første del af
testen, da disse netop er dem der har
dannet grundlag for grænseværdierne,
der skal testes i anden del.
13.3.2.1 Fremgangsmetode
Testen af Quality-klassen foretages ved
at anvende udvælgelsesmodellerne på
figur 13.7, dog uden de hvide cirkelmarkeringer.
Overordnet vil der blive testet
med begge udvælgelsesmodeller, boks
og ellipsoide. I alt foretages fire test. To
for hver af udvælgelsesmodellerne. En
test med de smalle grænser, hvor der
kun udvælges godkendte kim og en med
brede grænser, hvor der også udvælges
ikke-godkendte kim.
13.3.2.2 Testresultater ellipsoide
Figur 13.8 viser resultatet ved brug af
ellipsoiden som udvælgelsesmodel og
med smalle grænser.
Det ses, at der i bunden af billedet, er
fundet et kim ud af de fire godkendte.
Resultatet af den samme test, men
denne gang med de brede grænser, kan
ses på figur 13.9. Med de brede grænser
udvælges alle fire godkendte, samt fem
ikke-godkendte. Ved nærmere inspektion
viser det sig, at det kun er en af de
fem, som slet ikke kan bruges til noget.
De andre ligger lige på grænsen, og er 2.
Figur 13.7
Billede der blev anvendt til testen: De hvide markeringer angiver de kim der
vurderes at være godkendte
Figur 13.8
Resultatet med ellipsoide brugt som udvælgelsesmodel og smalle grænser
Figur 13.9
Resultat med ellipsoide brugt som udvælgelsesmodel og brede grænser
Side 66 af 131

13 Quality 13.3 Test
klasses kim (3.4.2 Anden klasse – lette misdannelser s. 12).
13.3.2.3 Testresulater rektangulær boks
Med udvælgelsesmodellen, der baserer
sig på boksen og med smalle grænser,
fås det resultat, som ses på figur 13.10.
Denne gang udvælges der et godkendt
og et ikke godkendt kim. Det bemærkes
også, at der ikke blev udvalgt de
samme godkendte kim, som da
ellipsoiden blev anvendt.
Med brede grænser opnås resultat som
er vist på figur 13.11. Det ses her, at
resultatet næsten er det samme, som
da ellipsoiden med brede grænser blev
anvendt. Denne gang udvælges der
dog et mindre ikke godkendt kim.
Noget, som umiddelbart kan undre, er
at det ikke-godkendte kim, som blev
udvalgt med smalle grænser, ikke
udvælges når de brede grænser anvendes.
Men dette skyldes, at når de smalle
grænser anvendes, er der tilpasset
en boks, som kun omkranser godkendte
kim, og så er det gjort så stort,
at det lige netop ikke udvælger nogle
ikke-godkendte kim. Med brede grænser,
er der tilpasset en ny boks, som
omkranser alle godkendte, men som
er tilpasset, så der udvælges så få ikkegodkendte
som muligt. Det er med
andre ord ikke de smalle grænser, som
er blevet udvidet, men et helt andet
rektangel.
Samlet ses resultatet af testen i tabel
13.2:
Figur 13.10
Resultat med rektangulær boks som udvælgelsesmodel og smalle grænser
Figur 13.11
Resultat med rektangulær boks som udvælgelsesmodel og brede grænser
Type Grænser Godkendte Ikke
godkendte
Ellipsoide
Boks
Tabel 13.2
Samlet resultat af testen
Smalle 1 0
Brede 4 5
Smalle 1 1
Brede 4 4
Side 67 af 131

13 Quality 13.4 Sammenfatning
13.4 Sammenfatning
Overordnet kan det konkluderes, at det ikke har været muligt, at skabe en metode der kan udvælge
alle godkendte og ingen ikke-godkendte kim i et givent billede.
Ved gennemgangen i teoriafsnittet blev ellipsoiden foreslået, som et alternativ til boks-modellen som
udvælgelsesmodel. Det viste sig at ved anvendelse af begge modeller på 313 prøvekim, at det ikke
entydigt kunne afgøres hvilken af de to modeller der gav de bedste resultater.
I den første test i testafsnittet blev det undersøgt, hvorvidt den boksen og ellipsoiden blev
implementeret korrekt, så de udførte deres opgave korrekt. Testen viste, at dette var tilfældet da
C++ implementeringen gav det samme resultat, som fundet ved den manuelle inspektion
(visualiseret igennem MatLab-scriptet). Dermed kan det konkluderes, at koden virker korrekt.
I den anden test i testafsnittet blev det testet hvorvidt boksen, var bedre end ellipsoidemodellen.
Men ved test på et enkelt billede, viste det sig at være svært at afgøre, hvilken af modellerne der
klarede sig bedst. Det står klart, at der skal anvendes mere end 1 billede, hvis en tendens skal kunne
identificeres. Dette var dog ikke muligt, da der ikke kunne anskaffes flere prøver tidsnok fra
Københavns Universitet, men det er gruppens opfattelse, at de to udvælgelsesmodeller ikke
nødvendigvis er de bedste løsningsmodeller, og at situationen er mere kompliceret end først antaget.
Først og fremmest vil det være nødvendigt med større og mere omfattende undersøgelser, at
afdække hvilken udvælgelsesmodel der er bedst. Det vil være nødvendigt at undersøge, om der
findes bedre alternativer til boks- og ellipsoidemodellen, hvilket er meget muligt. Det er gruppens
holdning at undersøgelsen med de 313 kim, ikke er omfattende nok til, at man i første omgang kan
afgøre om boksmodellen er bedre eller dårligere end ellipsoidemodellen. Årsagen til at gruppen ikke
har foretaget sig yderligere test er, at det er en meget tidskrævende proces, og det er i hele taget
gruppens holdning at kvalitetsvurderingen af kimene er et afgangsprojekt i sig selv, og kræver
omfattende statistisk analysearbejde.
Et andet resultat af en mere omfattende analyse vil også være at identificere flere og/eller andre
parametre at arbejde med. Gruppen udarbejdede 4 parametre i samarbejde med Jens Iver Find (KU),
men det er igen gruppens holdning, at yderligere analysearbejde skal afdække flere parametre, da det
netop ikke er muligt, at opfylde hovedkravet om at kunne udvælge alene alle godkendte kim. Flere
parametre vil sandsynligvis gøre det muligt, at kunne få bedre resultater ved udvælgelsen.
Side 68 af 131

14 Implementering 14.1 Indledning
14 Implementering
14.1 Indledning
Når et projekt skal implementeres, er der flere ting der bør overvejes. Det gælder for det første om,
at vælge det miljø hvori det ønskes at arbejde, hvilke fordele og ulemper der kan være. Noget andet
er den struktur, der vælges for programmet, samt på hvilket stadie det færdige produkt skal være.
Skal det være en prototype eller et færdigt program? Derudover skal der også være et user interface,
således at en bruger vil være i stand til at benytte programmet.
14.2 Valg af implementeringsmiljø
Implementeringen af teorien i projektet sket i C++. Valget af C++, var en kombination af flere
faktorer. For det første var gruppen i forvejen kendt med sproget, hvilket ville nedsætte den
overhead, der altid er ved at lære et nyt programmeringssprog. Et andet aspekt var hastigheden i
afviklingen. Sammenlignet med sprog som MatLab og Java er hastigheden i C++ større. Til gengæld
har MatLab mange standardfunktioner til at behandle billeder indbygget. Et sidste argument for at
bruge C++ er at det er et objektorienteret programmeringssprog.
Gruppen valgte, at implementere projektet ved at bruge Visual C++ 2005 Express, en integreret
IDE og kompiler fra Microsoft. Express-udgaven er gratis at bruge, og dette var hovedgrunden til at
den blev valgt.
14.3 Programstruktur
Programmet er udviklet på konceptbasis. Dvs. at programmet skal sandsynliggøre, at det i praksis
kan lade sig gøre, at detektere og klassificere kim. Dette indebærer, at der ikke er gjort så meget ud af
user interfacet samt hastighedsoptimering. Det er også valgt, at man manuelt skal aktivere
programmet, hver gang det ønskes afviklet. Dette gør det nemt at arbejde med, så længe der udvikles
på det.
Selve programstrukturen er opbygget omkring en enkelt fil, ”vision.cpp”, der sekventielt afvikler
programmet svarende til blokdiagrammet i afsnit 2.1.1 Program s. 8. Undervejs i programafviklingen,
genereres der forskellige data, som alle gemmes i undermappen ”Data”.
14.3.1 Vision.cpp
I de foregående kapitler er de forskellige klasser, som programmet gør brug af, beskrevet. Alle disse
klasser instantieres fortrinsvis i filen ”vision.cpp”, som er programmets hovedfil. I den følgende
tekst vil en, for overskuelighedens skyld, lidt forenklet version af denne fil blive beskrevet.
Som det første oprettes der en instans af klassen Color. Denne instans bruges til at læse filen
”kim.bmp” ind fra harddisken. Filen ”kim.bmp” skal ligge i samme mappe som programmet:
Color color;
color.execute("kim.bmp");
Side 69 af 131

14 Implementering 14.3 Programstruktur
Herefter oprettes der en instans af klassen GrayScale, hvor det color-objekt, der indeholder filen
”kim.bmp”, der blev loadet fra disken, overføres til. Dette gøres for at konvertere farvebilledet til
gråtoner:
GrayScale grayScale;
grayScale.execute(color);
Klassen Binary bruges bl.a. til at bestemme hvilken thresholdværdi, der skal bruges for at skelne
forgrund fra baggrund. Til dette formål oprettes der en instans af denne. Binary-klassens execute()funktion
tager gråtonebilledet grayScale som input:
Binary binary;
binary.execute(grayScale);
Når thresholdværdien er udregnet, kan gråtonebilledet laves om til et binært billede, som kun består
af baggrundspixels, som er sorte, og forgrundspixels, der er hvide. Der oprettes derfor en ny instans
af klassen GrayScale kaldet binaryImage:
GrayScale binaryImage;
binary.makeBinary(binaryImage);
For at bestemme hvilke hvide pixels der repræsenterer et kim, er det nødvendigt at finde ud af hvilke
der rører ved hinanden. Til dette bruges klassen BlobDetection, som instantieres som
blobDetection. Denne instans tager det binære billede binayImage som argument. De to
efterfølgende funktioner setMaxArea() og setMinArea() sorterer grupperinger af forgrundspixels
fra, som ikke er relevante at arbejde med. Grupper over 100.000 pixel er for store og grupper under
250 pixel er for små:
BlobDetection blobDetection;
blobDetection.execute(binaryImage);
blobDetection.setMaxArea(100000);
blobDetection.setMinArea(250);
For at kunne gemme informationer om hvert enkelt kim, er der oprettet en struktur til dette formål i
klassen Seed. Der oprettes en pointer pSeed af klassen Seed. Herefter oprettes der en liste med alle
de kim, som blev fundet i BlobDetection, som denne pointer sættes til at pege på. Til sidst gemmes
antallet af kim i variablen numberOfSeeds:
Seed *pSeed;
int numberOfSeeds = blobDetection.makeSeeds(&pSeed);
Efter alle kimene er fundet, skal deres x,y-koordinater, samt deres orientering θ i planet findes. Dette
gøres ved at bruge klassen EllipseApproximation. Objektet ellipseApproximaion er en instans af
denne klasse. EllipseApproximations constructor skal have 2 parametre, den ene er pointeren til
listen med kim, pSeed, den anden er antallet af kim i listen, numberOfSeeds, for kunne beregne x, y
og θ på alle kimene:
EllipseApproximation ellipseApproximation(pSeed, numberOfSeeds);
ellipseApproximation.execute();
Fra dette punkt i programmet implementeres kvalitetssorteringen. Som det første findes toppen på
alle kimene. Til dette formål anvendes TopDetection. TopDetection-klassen implementerer
Arealforskel-algoritmen. Instansen af klassen kaldes topDetection. Igen tages de 2 parametre pSeed
og numberOfSeeds som input:
TopDetection topDetection(pSeed, numberOfSeeds);
topDetection.execute();
Side 70 af 131

14 Implementering 14.3 Programstruktur
Når alle kimene har været igennem TopDetection, tages Symmetry-klassen i brug. Klassen bruges til
at fastlægge kvalitetsparameteren, symmetri, for hvert af kimene. For at afvikle klassen sendes de to
parametre pSeed og numberOfSeeds til constructoren:
Symmetry symmetry(pSeed, numberOfSeeds);
symmetry.execute();
Nu er tiden inde til at beregne kvaliteten af kimene ud fra kvalitetsparametrene. Igen beregnes
kvaliteten for hvert enkelt kim. Det første der sker, er at der oprettes en instans af klassen Quality,
med de to parametre pSeed og numberOfSeeds som input. I Quality indlæses kvalitetsparametrenes
grænser fra ”settings.ini”-filen. Det er ud fra disse parametre, at det beregnes hvilke kim der bliver
godkendt.
Quality quality(pSeed, numberOfSeeds);
quality.execute();
Når de godkendte kim er fundet, udskrives deres x,y-koordinater samt θ til tekstfilen
”robotData.txt”.
quality.saveRobotData("Data/robotData.txt");
For at visualisere resultaterne af algoritmerne, genereres der en række billeder. Hertil anvendes
klassen Draw (Appendiks 18.9.10 Draw s. 121). Det første billede der oprettes, tager udgangspunkt i
originalbilledet ”kim.bmp”. Der tegnes på billedet med funktionen drawEllipse(). Dette billede
viser alle de fundne kim og deres approkismerede ellipser. Billedet gemmes i ”Data”-mappen som
”ellipse.bmp”.
Draw draw;
draw.load("kim.bmp");
draw.drawEllipse(pSeed, numberOfSeeds, true);
draw.save("Data/ellipse.bmp");
Herefter tegnes der et nyt billede, som også er baseret på det originale ”kim.bmp”. På dette billede er
kun de godkendte kim med, samt en markering for hvert enkelt kim hvor toppen er fundet.
Procesgangen er som følger: Først slettes alle tidligere data fra objektet draw med clear()
funktionen. Herefter loades det originale billede ind. Derefter tegnes de approksimerede ellipser på
de godkendte kim. Derefter indtegnes topmarkeringen med funktionen drawCenterTop(). Til sidst
gemmes billedet i filen med navnet ”topBottomApproved.bmp”:
draw.clear();
draw.load("kim.bmp");
draw.drawEllipse(pSeed, numberOfSeeds, false);
draw.drawCenterTop(pSeed,numberOfSeeds, false);
draw.save("Data/topBottomApproved.bmp");
Billedet ”topBottomApproved.bmp” viser resultatet af den samlede algoritme.
Side 71 af 131

14 Implementering 14.4 User interface
14.4 User interface
Som beskrevet i 2.1.1 Program s. 8 skal programmet
kun vise, om principperne virker efter hensigten.
Derfor er det valgt kun at implementere et simpelt
user interface. Der opbygges en konsolbaseret
applikation, med et lille menusystem, der giver
mulighed for at afvikle programmet, indstille
grænserne for kvalitetsparametrene og vise enkelte
resultater i form af billeder (figur 14.1).
Figur 14.1
Menusystem
Hovedmenu
Kør
Opsætning
Fundne kim
Godkendte kim
Afslut
Afvikler algoritme
Åbner settings.ini
I notepad
Åbner paint og
viser alle funde
kim
Åbner paint og
viser alle de
godkendte kim
Side 72 af 131

15 Sammenfatning 15.1 Samlet test
15 Sammenfatning
15.1 Samlet test
Det ønskes at teste det samlede program. I de enkelte kapitler testes funktionaliteten af de enkelte
klasser, men her er det meningen at vise at sammenspillet mellem disse også virker efter hensigten.
15.1.1 Fremgangsmetode
Testen er opdelt i tre dele. Den første del skal verificere at det er muligt at detektere kimene. Anden
del skal vise at klassifikationen er implementeret efter hensigten. Sidste del af testen skal vise at user
interfacet virker som forventet.
15.1.2 Test 1 – detektering af kim
I denne test skal det vises, om det er muligt at detektere alle kim. Derudover skal kimenes x, ykoordinater
og θ findes. Dette gøres ved at afvikle programmet på et billede. Efter algoritmen har
detekteret kimene gemmes et billede, hvor de 3 parametre er tydelige at se.
15.1.2.1 Testresultater
Testresultaterne kan ses på billedet i
figur 15.1.
Kimenes placering og længdeakses
orientering i planet skal findes. Ved at
kigge nærmere på et tilfældigt udvalgt
kim kan det ses, at der hvor ellipsens
lille- og storakse krydser findes kimets
midtpunkt. Dette punkt er kimets
placering i x, y-planet. Derudover kan
det også ses, at kimets længdeakse er
identisk med ellipsens storakse, hvilket
er kimets orientering. Ydermere ses
det, at kim der ligger i kanten af
billedet ikke bliver medtaget.
Grupper at kim, dvs. flere kim der
rører ved hinanden, bliver også
detekteret.
15.1.3 Test 2 – klassificering
Figur 15.1
Billedet viser resultatet af algoritmen hvor alle kim er fundet og har fået
tilpasset en ellipse.
Det skal verificeres, at teorien i 13 Quality s. 60 virker i samspil med de resterende klasser. Dette
gøres ved at afvikle programmet. Resultaterne gemmes herefter i en tekstfil samt et billede for at
Side 73 af 131

15 Sammenfatning 15.1 Samlet test
visualisere dem. Desuden ønskes det i denne test, at vise hvordan TopDetection-klassen virker i
samspil med de andre klasser. I testen anvendes det brede sæt grænser, for den rektangulære
udvælgelsesmodel (13.2.3 Bestemmelse af grænser s. 62).
15.1.3.1 Testresultater
Af figur 15.2 fremgår resultaterne.
Det ses for det første, at der denne
gang kun er blevet udvalgt nogle få
kim i forhold til tidligere. Hvilke kim
det er og hvorfor det netop er disse,
der er blevet udvalgt kan læses i 13
Quality s. 60.
For hvert af de kim, som ses i figur
15.2, er det forsøgt at finde hvor
toppen ligger. Dette er vist lidt
tydeligere i figur 15.3, hvor man kan se,
at der på kimet er en lille lyserød
markering. Denne indikerer, at toppen
er beregnet til at ligge i den ende. Ved
at gennemgå figur 15.2, ses det at
toppen findes rigtigt på de 7 af 8 kim.
På det ottende er det svært, at definere
hvad der er top, da det her drejer sig
om et meget deformt kim. Det ottende
kim er det, som ses forstørret i øverste
højre hjørne på figur 15.3.
Dataene på de kim som godkendes i
klassificeringen gemmes alle i en
tekstfil, ”robotData.txt”, som vises i
figur 15.4. Her kan x- og y-koordinater,
samt den vinkel, som kimets top
danner i forhold til det vandrette plan,
aflæses.
Figur 15.2
Resultat med rektangel som udvælgelsesmodel og brede grænser.
Figur 15.3
Placeringen af den lyserøde prik afgør hvor toppen på kimet er fundet.
Side 74 af 131

15 Sammenfatning 15.1 Samlet test
Resultaterne i denne tekstfil er blevet sammenholdt med figur 15.3, hvor det i et billedebehandlingsprogram
er verificeret, at de stemmer.
15.1.4 Test 3 – User interface
User interfacet er opbygget efter den struktur, der er vist i 14.4 User interface s. 72. Testen gennemgår
de enkelte dele i menustrukturen og viser hvordan de forskellige skærmbilleder ser ud.
15.1.4.1 Testresultater
Figur 15.5
Programmets hovedmenu
Figur 15.4
Tekstfil der viser dataene for de godkendte kim
Side 75 af 131

15 Sammenfatning 15.1 Samlet test
På figur 15.5 ses menupunkterne. Det første menupunkt er ”Kør”. Dette punkt afvikler algoritmerne,
og viser skærmbilledet figur 15.6. Her ses det, at programafviklingen tager 481 millisekunder for lige
præcis det billede, som er anvendt i denne test. Afviklingstiden afhænger af billedet og computeren.
Figur 15.6
Programmet udprinter de tider som det tager at afvikle de forskellige algoritmer
Det andet punkt i menuen er ”Opsætning”. Vælges dette punkt åbnes der en fil (figur 15.7), hvori
parametrene for kvalitetsvurderingen kan sættes.
Figur 15.7
Settings.ini filen hvor man kan indstille kvalitetsparametrene
Det tredje punkt ”Fundne kim” åbner et billede, hvor alle kimene er blevet fundet, og har fået
approksimeret en ellipse. Et eksempel på dette billede er figur 15.1
Det fjerde punkt ”Godkendte kim”, åbner et billede, hvor det kun er de kim der opfylder
kvalitetsparametrene, der er indtegnet. Her er der tale om et billede magen til det i figur 15.2
Side 76 af 131

15 Sammenfatning 15.2 Diskussion
Det sidste punkt afslutter programmet.
15.2 Diskussion
Arbejdet med biologisk materiale har vist sig at være udfordrende. Der arbejdes i en verden med
grænsetilfælde, hvor det kan være svært at afgøre hvad der er sandt og falskt, f.eks. hvornår er et kim
for krumt, for bredt osv. Miljøet hvori kimene har befundet sig, har også været en udfordring.
Kimene klistrer til hinanden og belysningsforholdene varierer, da en fast testopstilling endnu ikke
forefindes.
At tage et billede med kameraet har givet anledning til en del overvejelser. For det første har det
været vigtigt at fastlægge opløsningen på kimene. Hvor store skal de være på billedet, således at der
lige netop kommer detaljer nok med. Her skal man dog også passe på, at man ikke går i den anden
grøft og får flere detaljer med end nødvendigt, for på den måde begrænses pladsen i selve billedet,
og dermed udvælges færre kim. Valget af 10 pixels som et minimum i bredden på et kim virker
fornuftigt og resulterer i et synsfelt for kameraet på 128 mm x 96 mm. At implementeringen af Fire-i
biblioteket måtte udelades, var ikke hensigten fra starten, men set i lyset af de opståede problemer og
tiden i projektet, var dette en fornuftig beslutning.
De opnåede resultater med Color- og GrayScale-klasserne har været tilfredsstillende. I forbindelse
med GrayScale-klassen, foretages der ikke en egentlig gråtone-konvertering, da det blev vurderet, at
der ikke var behov for en sådan. Den grønne kanal er tilstrækkelig i dette tilfælde.
For at skille forgrund fra baggrund er Ridler og Calvards iterative thresholding-teknik blevet anvendt
med succes. Selv efter få iterationer findes dalen imellem de to toppe i histogrammet ligegyldigt hvor
udgangspunktet tages.
Identifikation af blobs gør, at man kan nøjes med kun at analysere små fragmenter af billedet, som
er interessante at arbejde med. På denne måde har man identificeret og adskilt grupperinger af pixels
fra hinanden. Dette er implementeret i BlobDetection-klassen, og resultaterne er helt som forventet.
EllipseApproximation-klassen giver kimenes orientering i planet i form af en vinkel med det
vandrette plan, samt længderne på akserne. Kombineret med beregningen af kimenes
massemidtpunkter, som angiver kimenes placering, opnås det ønskede resultat om detektering af
kim. Metoden må derfor anses for at virke som forventet.
Undersøgelsen og valg af TopDetection-algoritme resulterede i ”Arealforskel”. Metoden viste sig
ikke at være så robust som ønsket. Ifølge testen findes toppen rigtigt på ca. 92 % af alle godkendte
kim. Forestiller man sig, at der i en af udvælgelsesmodellerne anvendes brede grænser, udvælges der
også en del ikke-godkendte kim, hvilket vil resultere i, at toppen ikke findes rigtigt på flere af
kimene, og derfor vil resultatet på ca. 92 % ikke gælde i den situation. En anden betragtning, som er
opstået under arbejdet er, at en topdetektering senere i beplantningsprocessen ville være nemmere,
da kimene udvikler en kraftig farveforskel mellem top og bund, som de modnes. Den nuværende
udviklede TopDetection-algoritme vurderes ikke at være dækkende nok.
Kvalitetsparameteren symmetri blev implementeret i Symmetry-klassen. Klassen tester symmetrien i
kimene omkring deres længdeakse og giver et resultat mellem 0 – 100 %, som er forholdet imellem
antallet af pixel, der ikke er symmetriske og kimets areal. Det vurderes, at klassen virker som ønsket.
Kvalitetsvurderingen i Qualiy-klassen udfylder ikke dets formål. Det er ikke alene alle godkendte
kim, der bliver udvalgt. Der er ikke fundet kvalitetsparametre nok, eller også har det ikke været de
rigtige, der er blevet anvendt. Det kunne også være udvælgelsesmetoden, med netop at anvende
Side 77 af 131

15 Sammenfatning 15.3 Konklusion
kvalitetsparametre, der ikke er den optimale. Der kan også stilles spørgsmålstegn ved nogle af de
kim, som algoritmen godkender, men som ikke er blevet godkendt ved manuel inspektion eller
omvendt. De kim, som gruppen har godkendt, er forsøgt godkendt objektivt ud fra kravene for 1.
klasses kim givet af Jens Iver Find. Dette kan dog være yderst svært, da der kan være tale om
grænsetilfælde, hvor den objektive vurdering bliver mere subjektiv.
Generelt kan det siges, at alle gennemførte test har været simple. Resultaterne er som regel visuelt
vurderede og ikke kvantitativt analyserede. Dette er grundet, at algoritmerne er computerbaserede,
og derfor kan der regnes med de store datamængder i billederne. Et menneske kan ikke duplikere
denne regnekraft, og netop derfor er vurderingerne af testene baseret på en simpel visuel inspektion.
Skulle dataene analyseres korrekt, ville det være nødvendigt at aflæse dem i computerens
hukommelse. Dette ville dog have været et stort arbejde. Af den årsag blev det besluttet, at vurdere
testresultaterne ved at gemme dataene i en fil (som et billede) ved at bruge Draw-klassen. Det
vurderes, at Draw-klassen ikke påvirker resultaterne i en nævneværdig grad, og derfor kan det
retfærdiggøres, at anvende denne i verificering af testresultater.
15.3 Konklusion
Overordnet kan det konkluderes, at det har været muligt at fremstille et system, der med succes kan
identificere alle kim i et givent billede, men der kun med begrænset succes, kan kvalitetssortere disse.
Det følgende er gennemgang af de vigtige emner i rapportens to hoveddele. Konklusionen bygger på
kravspecifikationen (1.3 Kravspecifikation s. 6), og der henvises direkte til punkter i denne.
15.3.1 Del I: Detektering af kimplanter
I første del af rapporten, blev det vist, at Color-klassen kan indlæse en BMP-fil og gøre denne
tilgængelig for alle klasser, der har brug for den. På baggrund af testen i kapitlet omkring Colorklassen,
kan det konkluderes, at systemet lever op til kravspecifikationens punkt 1.
Det blev også vist, at det er muligt at identificere enkelte og fritliggende kim, samt finde deres
placering (koordinater) og længdeaksens orientering. Ved test kan det fastslås, at systemet godt kan
håndtere kimplante-grupperinger, men at disse bliver identificeret som ét stort kim. Dette vurderes
dog ikke som værende et problem, da kvalitetssorteringen vil sørge for, at den falske detektering vil
blive sorteret fra pga. størrelsen af arealet. Dermed konkluderes det, at systemet lever op til punkt 2.
15.3.2 Del II: Klassificering af kimplanter
I anden del af rapporten blev der udviklet forskellige metoder til udvælgelse af godkendte kim. I den
forbindelse blev der afdækket flere parametre, der kan anvendes i udvælgelsesprocessen. Ydermere
blev der udviklet 2 udvælgelsesmodeller, til at vurdere kimene med ud fra udvælgelsesmodellerne:
boks og ellipsoide. Det er gruppens vurdering, at den analyse der ligger til bunds for bestemmelsen
af parametrene og udvælgelsesmodellerne ikke er omfattende nok, og at der ved en mere omfattende
analyse kan findes flere parametre og udvælgelsesmodeller. Dette er nødvendigt, da systemet ikke
entydigt kan udvælge alene alle første klasses godkendte kim. Dermed kan det konkluderes, at
systemet ikke lever op til punkt 3.a og 3.b.
Side 78 af 131

15 Sammenfatning 15.4 Videreudvikling
Der blev dog med succes implementeret en metode til, at udvælge kim, hvis parametre falder inden
for brugerspecificerede grænser. Systemet kan yderligere udskrive x, y og θ på de udvalgte kim til en
fil, og dermed lever systemet op til punkt 3.c og 3.d.
I sammenfatningen er der lavet en samlet test af systemet. Denne test har til formål, at vise at hele
systemet virker, som det skal, når alle klasserne arbejder sammen. Det ses fra testen, at ved
anvendelse af billeder fra test af Quality-klassen, opnås samme resultat. Derved konkluderes det, at
klasserne arbejder sammen korrekt. Der er udviklet et konsolbaseret interface, og testen viser, at det
er muligt for brugeren, at angive hvilke grænser kvalitetssorteringen skal anvende. Ydermere ses det,
at det er muligt at se resultatet fra detekteringen af alle kim og resultatet af kvalitetssorteringen, ved
at interfacet automatisk kan hente disse billeder frem og vise dem. Dermed lever systemet op til
punkt 4.
Samlet vurderer gruppen at ”Del I: Detektering af kimplanter” fungerer som ønsket, og at der ikke
er yderligere at foretage sig i denne del. Dog vurderes det, at ”Del II: Klassificering af kimplanter”
har to vigtige udfordringer (punkt 3.a og 3.b), der skal løses før systemet er fuldt funktionelt.
15.4 Videreudvikling
Dette afsnit har til formål, at give gruppens bud på hvilke emner der kan være interessante at
videreudvikle. Generelt kan det siges, at der ikke er fundet mange alternativer til hver algoritme, der
er implementeret på nær i TopDetection. Dette skyldes delvist, at størstedelen af algoritmerne er
meget simple, og der derfor ikke er mange alternativer, men også at gruppen fra starten, i samarbejde
med vejleder, har fundet frem til algoritmer, der blev vurderet til at løse opgaven. Herefter var det
meningen, at en implementering skulle afgøre hvorvidt, der var problemer med den implementerede
algoritme, og hvis ikke, kunne det konkluderes, at algoritmen fungerede som ønsket, og der ville ikke
blive udviklet alternativer. En tilbundsgående analyse af alle alternative algoritmer, inden der blev
implementeret, blev vurderet til at være en for stor opgave for gruppen, set i lyset af projektets
begrænsede tid.
15.4.1 Kamera
Det er gruppens holdning, at ved videreudvikling på projektet, vil det være fordelagtigt at
implementere kameraet direkte i kodeprojektet, som det også var planen fra starten. Dvs. at den
kode der er udviklet fra gruppens side vil interface direkte med kode, der kommunikerer med
kameraet. På den måde er al funktionalitet samlet i ét program.
Det er tidligere beskrevet, at den optimale opløsning giver et synsfelt på ca. 128 mm x 96 mm.
Gruppen vurderer, at det er TopDetection, der er toneangivende i den henseende. Derfor vil det
være sandsynligt, at man vil kunne få et større synsfelt, hvis TopDetection udelades eller ændres.
Det skal herefter undersøges nærmere, hvad den mindste opløsning skal være, da det ikke vides med
sikkerhed. De fleste af algoritmerne kan arbejde med selv meget små objekter, men usikkerheden
bliver større, som objekterne bliver mindre. I tilfælde af at synsfeltet er mindre end bredden på det
transportbånd eller bord, der skal passere kimene forbi kameraet, må der laves en løsning således
båndet eller bordet kan rykkes under kameraet, eller kameraet kan rykkes over båndet/bordet, eller
evt. lave flere parallelle kameraopstillinger.
Side 79 af 131

15 Sammenfatning 15.4 Videreudvikling
15.4.2 EllipseApproksimation
I slutningen af projektet blev gruppen klar over at der fandtes et værktøj, der muligvis kan håndtere
mange af de problemstillinger der løses i projeket. Fourier-deskriptorer (Image processing [7]) kan
muligvis delvist erstatte EllipseApproksimation, ved at det, sammen med hjælpefunktioner, kan være
med til at bestemme længdeaksen, og vinklen objektet er roteret med. Det vurderes, at der stadig vil
være behov for massemidtpunktsbestemmelsen.
15.4.3 TopDetection
Det er gruppens holdning, at det bedste resultat opnås, hvis bestemmelsen af toppen gøres på et
senere tidspunkt i beplantningsprocessen. Dette skyldes, at kimene får en markant farveforskel
mellem top og bund, som de modnes. Denne forskel er nem at detektere og vil give en markant
større sikkerhed end at bestemme top på dette tidligere stadie i beplantningsprocessen, som er
tilfældet nu.
I tilfælde af der stadig ønskes at arbejde videre med at finde top og bund på dette trin i processen,
anbefaler gruppen, at der arbejdes videre med ”Afstand 2”-algoritmen fra TopDetection-kapitlet.
Denne algoritme virker lovende og vil muligvis kunne give et bedre resultat end den nuværende
implementerede algoritme.
Som et led i bestemmelsen af toppen bestemmes expand-shrink-pixel-parameteren. Denne
parameter vil stadig være interessant i klassificeringen af kimene, selvom toppen ikke skal findes.
Dvs. ExpandShrink-klassen med fordel kan forblive en del af programmet, selvom TopDetectionklassen
evt. fjernes.
Som alternativ til ”Afstand 2”-algoritmen, er det også blevet foreslået, at finde toppen af kimet, ved
at finde det sted hvor kimet er bredest, vinkelret på længdeaksen. Dette er en meget simpel
algoritme, men er en teori, der er opstået, efter gruppen har kigget mange billeder igennem, og lagt
mærke til at kimene generelt er bredest i toppen.
15.4.4 Quality
Gruppen vurderer, at Fourier-deskriptorer kan anvendes i stedet for de tidligere udviklede parametre
og udvælgelsesmodeller. Det er dog uvist, om Fourier-deskriptorer vil kunne løse opgaven bedre
end de nuværende parametre og udvælgelsesmodeller, men det er et emne der med fordel kan
undersøges nærmere. Nearest Neighbour er navnet på en anden udvælgelsesmodel. Denne model
anvender de tidligere fundne kvalitetsparametre, men er altså et alternativ til boksen og ellipsoiden.
Det kan også her anbefales at undersøge denne nærmere, med henblik på at vurdere om den kan
erstatte andre modeller. Samlet set er der mange andre modeller og systemer, der kan erstatte det,
der er udviklet i projektet, og nærmere analyser kan afdække, om der er flere interessante modeller at
anvende, som ikke er nævnt her. Gruppen afviser ikke, at der kan laves en holdbar løsning, ud fra
det der allerede er lavet, men vil samtidigt heller ikke afvise, at der findes bedre modeller og
systemer. Det vil et mere detaljeret analysearbejde afdække. Ydermere er det gruppens holdning, at
det skal undersøges, om der kan findes flere kvalitetsparametre, end dem der allerede er afdækket.
Hvis det ønskes at vurdere krumheden af et objekt, kan expand-shrink-pixels til dels anvendes.
Succesen af denne afhænger dog af hvor aflangt indhakket i objektet er. En mere pålidelig algoritme
kunne være en, hvor man først finder alle midterpunkterne i objektet. Dvs. i hele objektets længde
vurderes det for hver horisontale linie, hvor midten på objektet er i den linie. Herefter fittes en ret
Side 80 af 131

15 Sammenfatning 15.4 Videreudvikling
linie til punkterne. Til sidst gås der igennem for alle punkter, og afstanden fra midterpunktet til den
fittede linie er så et mål for, hvor krumt objektet er.
15.4.5 Implementering
Ved implementering i fremtiden vil det være interessant, at lave en form for ekstern trigning af
programmet. På den måde vil programmet blive eksekveret når kim passerer under det, og tage et
billede og analysere det. Ydermere skal programmet interfaces med en robot. På nuværende
tidspunkt bliver koordinaterne for godkendte kim gemt i ”robotData.txt”, men en optimal
implementering ville muligvis indebære en overførsel af data direkte til robotten ved anvendelse af
en protokol.
Der kan også udvikles et grafisk brugerinterface (GUI), der på en mere hensigtsmæssig måde giver
mulighed for at angive grænserne, og få vist hvilke kim der udvælges. GUI’et kan vise billederne som
programmet analyserer og resultatet, uden at der skal åbnes eksterne programmer op.
I forbindelse med en reel implementering skal det også vurderes, hvorvidt en ændring i overfladen af
transportbåndet har effekt for, hvorvidt programmet fortsat virker som ønsket. Gruppen vurderer,
at det vil være en hensigtsmæssig løsning at anvende et finmasket net hertil, men at det skal
undersøges nærmere, om det vil give anledninger til ændringer i programmet. I tilfælde af valg af
andre løsninger, skal det vurderes konsekvenserne heraf.
Side 81 af 131

16 Litteraturliste 15.4 Videreudvikling
16 Litteraturliste
[1] Ingeniørhøjskolen Odense Teknikum Elektroretningen December 2000 AIPA: E- og I-PRO 1
Kompendium, Revision 3, 990927/AIPA.
[2] Find, Jens Iver: Høj-tech træer præsentation-1.ppt.
[3] Davies, E.R: Machine Vision, 3rd edition 2005, Morgan Kaufmann. ISBN: 0-12-206093-8.
[4] Horn, Bertholde Klaus Paul: Robot Vision, 3rd printing 1987, MIT Press. ISBN: 0-07-030349-5.
[5] Trussell, H. J.: Comments on ”Picture Thresholding Using an Iterative Selection Method”, IEEE
Transactions on systems, man, and Cybernetics, Vol. Smc-9, no. 5. May 1979.
[6] Ridler, T. W. og Calvard, S.: Picture Thresholding Using an Iterative Selection Method, IEEE
Transactions on systems, man, and Cybernetics, Vol. Smc-8, no. 8. August 1978.
[7] Image processing, March issue 1999.
Side 82 af 131

17 Ordliste 15.4 Videreudvikling
17 Ordliste
Ord Beskrivelse
Array En gruppe af homogene elementer af en specifik datatype
Blob En del af et binært billede hvor alle pixels er sammenhængende
BMP-header Den første del af en BMP-fil, der består af to under-headers. Disse indeholder
yderligere information om BMP-filen
Boundingbox Det mindste rektangel der lige præcis omgrænser en blob
Fire-i API En softwarepakke fra firmaet Unibrain, der via FireWire kan kommunikere med
et kamera
FireWire Er en PC seriel bus interface-standard
MatLab Et numerisk beregningsmiljø og et programmeringssprog fra firmaet The
Math­Works
Pixel Sammensat af ”picture element” hvor picture er forkortet pix. En pixel er et
enkelt punkt i et grafisk billede
RGB-værdier Et tal mellem 0 og 255, som anvendes i de 3 farvekanaler, rød, grøn og blå
SDU Syddansk Universitet
Threshold Tærskelværdi der logisk adskiller to tilfælde. Anvendes i projektet som en værdi
der adskiller forgrund fra baggrund
WDM Windows Driver Model
Side 83 af 131

18 Appendiks 18.1 Klasseoversigt
18 Appendiks
18.1 Klasseoversigt
-int height
-int width
-unsigned char**ppRedArray
-unsigned char**ppGreenArray
-unsigned char**ppBlueArray
Color
+Color(void)
+Color(const Color &colorInput)
+~Color()
-void makeVirtualImage(void)
+void execute(int width, int height)
+int execute(char *path)
+void clearImage(void)
+int getWidth(void)
+int getHeight(void)
+int setValue(int x, int y, unsigned char redColor, unsigned char greenColor, unsigned char blueColor)
+int getValue(int x, int y, unsigned char &redColor, unsigned char &greenColor, unsigned char &blueColor)
+unsigned char **getRedPointer(void)
+unsigned char **getGreenPointer(void)
+unsigned char **getBluePointer(void)
+void save(char *filename)
GrayScale
-int width;
-int height;
-unsigned char **ppArray;
+GrayScale(void)
+GrayScale(const GrayScale& grayScaleInput)
+~GrayScale()
-void makeVirtualImage(void)
+void operator= (const GrayScale& grayScaleInput)
+void execute(int width, int height)
+void execute(Color& color)
+void execute(GrayScale *grayScaleInput)
+int execute(char *path)
+int setValue(int x, int y, unsigned char grayColor)
+int getValue(int x, int y, unsigned char &grayColor)
+void clearImage(void)
+int getWidth(void)
+int getHeight(void)
+unsigned char **getPointer(void)
+void save(char *filename)
Binary
-int height
-int width
-int histogram[HISTOGRAM_SIZE]
-int threshold
-GrayScale *pGrayScale
-unsigned char **ppGrayArray
+Binary(void)
-void makeHistogram(void)
-void evaluateThreshold(void)
+void execute(GrayScale &grayScaleInput)
+void makeBinary(GrayScale binaryImage)
+void drawHistogram(void)
Side 84 af 131

18 Appendiks 18.1 Klasseoversigt
Side 85 af 131

18 Appendiks 18.1 Klasseoversigt
-unsigned char **ppBlob
-Seed *pSeed
-int numberOfSeeds
-Color color
-unsigned char **ppRedMap
-unsigned char **ppGreenMap
-unsigned char **ppBlueMap
Symmetry
+Symmetry(Seed *pSeedInput, int blobCount)
+void execute(void)
+int getPixelDeviation(int seedCount)
+Coordinate rotateCoordinate(Coordinate coordinate, float angle)
Draw
Utilities
+Utilities()
+~Utilities()
-Coordinates calculateCM(unsigned char **ppBlob, int ySize, int xSize, int numberOfPixels)
+float average(int numberOfElements, float *arrayOfElements)
+Coordinates calculateCenterOfMass(GrayScale &grayScale, int noOfPixels)
+Coordinates calculateCenterOfMass(unsigned char **ppBlob, int ySize, int xSize, int numberOfPixels)
+Draw(void)
+Draw(int width, int height)
+~Draw()
+void clear(void)
+void load(char *path)
+void drawBlobs(Seed *pSeed, int numberOfSeeds, bool all)
+void drawBounds(Seed *pSeed, int numberOfSeeds, bool all)
+void drawEllipse(Seed *pSeed, int numberOfSeeds, bool all)
+void drawCenterTop(Seed *pSeed, int numberOfSeeds, bool all)
+void save(char *path)
-Seed *pSeed
-int numberOfSeeds
-int expandShrinkLow
-int expandShrinkHigh
-int symmetryLow
-int symmetryHigh
-int areaLow
-int areaHigh
-float eccentricityLow
-float eccentricityHigh
-int selection
Quality
+Quality(Seed *pSeedInput, int blobCount)
-void evaluateSeeds(void)
-void getParametersFromFile(void)
+void execute(void)
+void saveSeedData(char *path)
+void saveRobotData(char *path)
Side 86 af 131

18 Appendiks 18.2 Projektoplæg
18.2 Projektoplæg
Titel: Detektering og klassificering af kimplanter
Baggrund:
På danske forskningsinstitutioner er der udviklet meget effektive bioteknologiske metoder til at
klone planter, i første omgang kloning af nordmannsgran til dansk juletræsproduktion.
Kloning kan sikre en stabil produktion af planter af høj, ensartet kvalitet og øge den gennemsnitlige
salgspris pr. produceret træ. Men det er meget arbejdskrævende og dermed dyrt at håndtere klonede
planter manuelt inden de når producenterne. Med computer vision vil robotter kunne gøre en del af
arbejdet med at finde, isolere og udplante spirende kimplanter fra sterile vækstmedier til fx en potte.
Afgangsprojekt:
I projektet skal der udvikles 2D computer vision metoder til at finde og kvalitetsvurdere spirende
kimplanter der er spredt ud på en plan flade.
18.3 Procesbeskrivelse
Formålet med dette afsnit er at beskrive, hvordan projektet forløb overordnet set. Det står klart, at
forløbet stort set har været, som det blev planlagt i begyndelsen (2.2 Planlægning s.10). Milepælene har
med rimelighed været overholdt, kun med få dages difference. Derudover har der været 2
demonstrationsdage, hvor gruppen har fremlagt resultaterne for projektstyringsgruppen fra HiTec
Elitetræer, samt andre interesserede.
Det er gruppens opfattelse, at der har været et godt og dynamisk samarbejde, der har været præget af
intensiv fordybelse i emnerne. Ydermere har gruppemedlemmerne arbejdet sammen i større eller
mindre omfang om næsten alle emnerne. Dette samarbejde på kryds og tværs kan være hårdt og
tidskrævende, men på den måde har det været muligt at skabe et homogent produkt.
Det har vist sig at modellen med, at slå problemløsnings- og analysefasen sammen var en god måde
at strukturere arbejdet på, i det mere forskningsprægede projekt. Nogle tidligere semestres
projektarbejde har vist, at 6-fasemodellen er en god model at anvende i projektarbejde, men i dette
tilfælde blev det fra starten vurderet, at 6-fasemodellen ikke ville slå an. Sammenlægningen af de 2
første faser blev en succes, i det mange problemstillinger opstod undervejs i udviklingen af
algoritmerne. De fleste af disse problemer var meget svære at identificere på forhånd.
Samarbejde på tværs af professioner, med bl.a. biologer, har været en lærerig proces på flere planer.
For det første har det været interessant at lære omkring kloning af kim. For det andet har det være
lærerigt, at formidle sin viden indenfor sit område til andre udenforstående, som f.eks. biologer.
Denne kommunikation på tværs af professioner har været givende.
Side 87 af 131

18 Appendiks 18.4 Tidsplan
18.4 Tidsplan
Side 88 af 131

18 Appendiks 18.5 Orientering i planet
18.5 Orientering i planet
Det ønskes at finde den linie der angiver, hvor inertimoment
(I) er mindst. Hertil anvendes teori fra Horn [4:48-53]. Det
ønskes altså at bestemme minimum af flg. formel:
2
I = ∫∫ r b(, x y) dxdy (18.1)
, hvor r er den korteste afstand fra et punkt (x,y) i objektet,
til et punkt (x 0,y 0) på linien der ønskes fundet (figur 18.1).
Det ønskes at finde en løsning for I, der kan udtrykkes i
C++-kode. Først findes en ligning, for linien der ønskes
fundet. Denne indsættes i ligningen for I. I bliver til sidst
minimeret for at finde aksen med det mindste inertimoment.
En linie i planet kan angives ved flg. parameterfremstilling: (, )
x sin θ−ycos θ+ρ= 0
bxy
(, )
(18.2)
Her er θ vinklen, linien med mindst inertimoment danner med x-aksen, og ρ er den korteste afstand
fra linien til origo (figur 18.2):
( −ρsin θ, ρcos θ)
−ρ
sin θ
Figur 18.2
Vigtige punkter på figur
θ
y
ρ
ρ
cosθ
(x,y)
r
b(x,y)
(x0,y0)
Ved at anvende punkterne, hvor linien skærer x-
og y-aksen, fås flg. parameterligninger:
x0= −ρ sin θ + scos
θ
y = +ρcos θ + ssinθ
(18.3)
0
, hvor s er afstanden langs linien fra det tætteste
punkt til origo.
Afstanden r er den korteste og vinkelrette afstand
mellem et punkt (x,y) i objektet, til et
punkt (x 0,y 0) på linien. Med Pythagoras gælder
flg. relation:
( ) ( )
2
2 2
r x x0 y y0
= − + − (18.4)
Indsættes ligning (18.3) i ligning (18.4) fås:
( ) 2 ( sin cos ) 2 ( cos sin )
2 2 2 2 2
r = x + y +ρ + ρ x θ−y θ − s x θ+ y θ + s (18.5)
Differentieres ligning (18.5) og sættes lig 0 fås et udtryk for s:
x
s = x cos θ+ ysinθ
(18.6)
y
(x,y)
r
(x0,y0)
b(x,y)
Figur 18.1
xy er et tilfældigt punkt i objektet
x
Side 89 af 131

18 Appendiks 18.5 Orientering i planet
Dette udtryk indsættes i parameterligningerne (18.3), og der isoleres så forskellene findes:
0
( )
( )
x − x0= sin θ x sin θ−ycos θ+ ρ
y − y = −cos θ x sin θ−ycos θ+ρ (18.7)
Forskellene kan indsættes i udtrykket for ligning (18.4):
( sin ( sin cos ) ) cos ( sin cos )
( sin cos )
( )
2
2 2
r = θ x θ−y θ+ρ + − θ x θ−y θ+ρ
...
2
r x y
= θ− θ+ρ
2
(18.8)
Det ses, at ligningen for (18.8) er lig ligningen for linien, der angiver det mindste inertimoment (hvor
r = 0 ) (18.2). Ligning (18.8) indsættes nu i formlen for inertimomentet (18.1):
( ) 2
∫∫ sin cos ( , )
(18.9)
I = x θ−yθ+ ρ b x y dx dy
Vi ønsker at finde minimum af ovenstående funktion, så derfor differentieres der med hensyn til
ρ og ligningen sættes lig nul:
( )
Axsin θ−ycos θ+ρ = 0
(18.10)
, hvor ( xy , ) er massemidtpunktet i objektet, og A er arealet. Fra formlen ses det at aksen passerer
igennem massemidtpunktet. Derfor kan der med fordel indføres nye koordinater, der gør at
massemidtpunktet bliver centrum i koordinatsystemet:
x′ = x − x , y′ = y − y
Det betyder at følgende gælder:
(18.11)
x sin θ−ycos θ+ρ= x′ sin θ−y′ cos θ (18.12)
Ved indsættelse i (18.9) og udregning af integrale fås:
I A B C
2 2
= sin θ− sin θcosθ+ cos θ (18.13)
Hvor A, B og C er defineret som:
∫∫
∫∫
∫∫
2
( ) ( , )
A = x′ b x y dx′ dy′
2
( ) ( )
B = 2 x′′ y b x, y dx′ dy′
2
( ) ( , )
C = y′ b x y dx′ dy′
Ligningen for inertimomentet kan vha. substitutioner også udtrykkes som:
(18.14)
1 1 1
I = ( A+ C) − ( A−C) cos2θ− Bsin
2θ
(18.15)
2 2 2
Side 90 af 131

18 Appendiks 18.6 Bestemmelse af ellipseparametre
Hvis dette udtryk differentieres og sættes lig nul, fås den løsning der giver det mindste inertimoment:
B
tan 2θ=
A−C Ved anvendelse af
sin 2θ=±
cos2θ=±
2
tan 2
2
sin 2θ
θ= fås to løsninger for ligningen:
2
cos 2θ
B
( )
2
B + A−C A−C ( )
+ −
2
B A C
2
2
(18.16)
(18.17)
Herefter kan sin 2θ og cos2θ indsættes i formlen for I. Af de to løsninger, vil den negative hos
både sin 2θ og cos2θ give det mindste inertimoment I min, og den positive vil give det største inertimoment
I max.
Ønskes vinklen til den principale storakse, θ major , der angiver det mindste inertimoment, kan θ major
isoleres i den positive løsning for sin 2θ :
θ =
major
1 arcsin
2
( ) 2
⎛
B
⎞
⎜ ⎟
⎜ 2
B + A−C ⎟
⎝ ⎠
18.6 Bestemmelse af ellipseparametre
Det gælder at:
max
(18.18)
2
Imin b
= (18.19)
2
I a
Længderne b og a kan herefter bestemmes ud fra 2 relationer:
e =
2
b
1 − 2
a
(18.20)
A = abπ
(18.21)
, hvor e er excentriciteten og A er arealet af ellipsen. Først udregnes længden a og dernæst bruges a
til at udregne b. (18.20) kan omregnes til:
2
b
e = 1 − ⇒ 2
a
2
b 2 b 2 2
e e b a e
2
= + 1 ⇔ = + 1 ⇔ = + 1
a a
A isoleres ligning (18.21):
(18.22)
Side 91 af 131

18 Appendiks 18.6 Bestemmelse af ellipseparametre
A
a =
π b
Indsættes udtrykket for b fra ligning (18.22):
a
a
2
a
A
1
A
1
A
=
2
π a e +
=
2
π e +
=
2
π e +
Det gælder fra ligning (18.22) at
a
A
=
2
π +
=
=
e
A
2
b
π 2
a
A
I
π
I
min
max
1
1
b
a
2
2
2
= e + 1 :
Dernæst kan b ifølge ligning (18.21) findes som:
(18.23)
(18.24)
(18.25)
A
b = (18.26)
π a
Hermed er der udledt udtryk for bestemmelse af længderne af stor- (a ) og lille-akse (b ) samt excentriciteten
(e ).
Side 92 af 131

18 Appendiks 18.7 Valg af TopDetection-algoritme
18.7 Valg af TopDetection-algoritme
18.7.1 Brainstorm
For at finde metoder til at detektere top eller bund er der blevet brainstormet på emnet. Det skal
bemærkes, at gruppen på tidspunktet, da brainstormen blev gennemført, endnu ikke havde set et
rigtigt kim, og kun kendte deres udseende fra andenhåndsbeskrivelser. Brainstormen er lavet på
baggrund af disse forudsætninger, som antages opfyldt:
1. Kimenes centerkoordinater kendes, samt akseorienteringer, som er et resultat af ellipse
approksimationen
2. Kimene er i den ene ende runde og forholdsvis glatte. Det er herfra, at rodnettet senere
udvikler sig. I toppen derimod, kan der allerede på dette stadie, anes en svag begyndelse til
kimbladene, som gør at planten er lidt flosset og har nogle rundinger
og hak
Brainstormen resulterede i et antal metoder og teknikker, som kan anvendes
til formålet:
18.7.1.1 Cirkel
Metoden går ud på, at man fra den approksimerede ellipses storakse finder
frem til skæringspunkterne med kanten af objektet. Fra centrum og i 2/3 af
afstanden til skæringspunkterne, tegner man en cirkel. Herefter kontrolleres
det, om der er sorte baggrundspixels med i cirklerne. Hvis ikke øges radius,
og operationen foretages igen. Efterhånden som cirklerne udvides, vil der i
toppen, begynde at komme baggrundspixels med, mens cirklen i bunden
stadig kun får hvide pixels (figur 18.3). På denne måde kan det afgøres, hvad
der er top og bund. Det kræver dog, at centeraksen ligger præcist, som vist
på figur 18.3, altså at den går lige igennem top og bund. Det vil nok ikke
realistisk, at kimet vil være symmetrisk omkring centeraksen. Derfor vil
cirklerne muligvis ikke ligge indenfor kimet (figur 18.4).
Ulemper
• Figuren skal være symmetrisk omkring ellipsens længdeakse.
18.7.1.2 Afstand 1
Den første afstandsmetode går ud på, at man fra centrum måler afstande
ud til kanten i begge ender (figur 18.5). Der holdes så øje med hvordan
afstandene fordeler sig. Starter de med at være korte, for derefter at vokse
indtil de falder igen, kan man gå ud fra, at det er bunden man har fundet.
Sker der pludselig et fald i stedet for en stigning, må det være enden med
de karakteristiske ”bølgedale” eller hak som er fundet. Metoden er en
følsom overfor urenheder i kanten, som kan resultere i et fald hvor man
forventer en stigning. Der kan anvendes en threshold-teknik, som sorterer
disse ikke ønskværdige ændringer fra.
Figur 18.3
Cirkel-metoden
Figur 18.4
Illustrerer problemet med
en skæv centerakse
Figur 18.5
Afstand 1-metoden
Side 93 af 131

18 Appendiks 18.7 Valg af TopDetection-algoritme
Fordele
• Metoden indebærer kun beregning af afstande, og på denne måde er algoritmen meget simpel
Ulemper
• Metoden er ikke så robust, da det ikke er sikkert at kanterne er
”rene”. Dette kan dog omgås ved at bruge en thresholdværdi, der
afgør hvor kraftig en stigning skal være før den accepteres
18.7.1.3 Afstand 2
Den anden afstandsmetode er at plotte alle afstandene fra hver ende imod
den vinkel, som afstandsvektoren danner med centeraksen (figur 18.6).
Til dette plot tilpasses en parabel. Den parabel, som er stejlest,
repræsenterer den ende hvor den er mest rund, altså bunden, hvilket er illustreret på figur 18.7. I
stedet for at bruge centerpunktet til at beregne afstandene fra, kunne man i stedet bruge ellipsens to
brændpunkter. Ved at gøre dette opnås der større
variation mellem der hvor der er lang afstand, og hvor
der er kort. Dette vil give et tydeligere resultat.
Fordele
• Den tilpassede parabel bliver vægtet med vinklen,
hvilket giver større variation
Ulemper
• Hvis bunden, hvor der ingen flosser er, er meget
flad, så bliver krumningen på den tilnærmede
parabel også lille, og derfor kan det være svært at
skelne mellem top og bund
18.7.1.4 dy/dx 1
Differentialkvotienten findes rundt langs kanten, og der
hvor den er størst, er toppen (figur 18.8).
Fordele
• Metoden afhænger ikke af figurens centerkoordinater
Ulemper
• Det er langt fra sikkert det er i toppen at der er den største hældning
• Det er svært at differentiere, da kanterne på figuren aldrig er ”rene”,
hvilket kan medføre kraftig stigning/fald i differentialkvotienten
18.7.1.5 dy/dx 2
Her kigges også på differentialkvotienten, men her er det ikke størrelsen på
hældningen, men fortegnet der er interessant. I den ende hvor fortegnet skifter flest gange findes
toppen.
Afstans
Afstans
Vinkel θ
Vinkel θ
Figur 18.6
Afstand 2-metoden
Figur 18.7
Tilpasning af parabel i Afstand 2-metoden
Figur 18.8
Illustration af metoderne
dy/dx1 og 2
θ
Side 94 af 131

18 Appendiks 18.7 Valg af TopDetection-algoritme
Fordele
• Den er simpel fordi den ikke afhængig af figurens centerkoordinater eller akse orienteringer
Ulemper
• Det er svært at differentiere, da kanterne på figuren aldrig er ”rene”, hvilket kan medføre
lokale fortegnsændringer
18.7.1.6 Spejling
Objektet spejles omkring lilleaksen i ellipsen, og der foretages en
sammenligning af de to halvdele. Der hvor der er mest forskel, findes den
reelle top. Denne metode er dog ret svær at realisere, da den lille akse ikke
afstandsmæssigt ligger lige langt fra top og bund, men i stedet afhænger af
figurens massemidtpunkt (figur 18.9). Lilleaksen vil derfor flytte sig
afhængigt af kimets form. Dette gør det svært at opstille et kriterium, som
kan bruges som sammenligningsgrundlag, for at bestemme hvilken ende
der er top og bund.
Ulempe
• Det er svært at afgøre gyldigheden af kriteriet i metoden
18.7.1.7 Arealforskel
Først udvides objektet med et antal pixels, hvorefter det skrumpes
tilsvarende tilbage igen. Dette udjævner alle indhak, hvilket gør at
”bølgedalen” i toppen vil blive gjort mere flad (figur 18.10). Nu
foretages der en sammenligning af det oprindelige og det skrumpede
objekt. I toppen vil der nu være delarealer, hvor de to objekter afviger
fra hinanden, mens bunden stadig er intakt. Det er derfor nu muligt
at identificere toppen som værende der, hvor den største arealforskel
er. Der kan være et problem hvis indhakkene i ”bølgedalen” ikke er
skarpe nok. Dette medfører, at der ikke vil være nogen forskel
imellem de to objekter, og dermed bliver toppen ikke mulig at
detektere.
Fordele
• Denne metode er uafhængig af centerkoordinater og
aksernes orientering
Ulemper
• Det er ikke sikkert, at det bliver nogen nævneværdig forskel
at detektere, og det kan derfor blive svært at finde toppen
18.7.1.8 Color
Denne metode bygger på, at der ud fra farve, kan kendes forskel på
de to ender. Ved at tage et gennemsnit af farverne i hver ende, og
sammenligne resultaterne kan toppen findes (figur 18.11).
Fordele
Figur 18.9
Spejling omkring lilleaksen
Figur 18.10
Arealforskel-algoritmen
Figur 18.11
De 2 streger indikerer i hvilke
områder gennemsnittet skal beregnes
Side 95 af 131

18 Appendiks 18.7 Valg af TopDetection-algoritme
• Det er enkelt at foretage en farve sammenligning, og igen er metoden uafhængig af
centerkoordinater og aksernes orientering
Ulemper
• Det er ikke sikkert, at der er nogen farveforskel at detektere
18.7.1.9 Thinning
Thinning vil sige, at der fjernes lag af fra ydersiden. Når man er nået ind til den
sidste pixel inden figuren bliver delt, fjernes der ikke yderligere pixels. Dette
resulterer i en y-form, som den vist på figur 18.12. I den ende, hvor y’et opstår,
er toppen. Problemet her er, at der kan opstå grene, som dem i y’et, hvis
figuren har udposninger, eller er uren i kanten. Det er derfor først nødvendigt,
at rense kanten inden thinning-algoritmen kan tages i brug. Dette afhjælper
dog stadig ikke problemet med udposninger.
Fordele
• Algoritmen giver et tydeligt resultat
Ulemper
• Algoritmen er følsom overfor ”urenheder” langs kanten, dvs. at der kan opstå grene udover
de to som er i y’et
• Udposninger på figuren kan have stor indflydelse
18.7.1.10 Diameter
Denne metode bygger på, at man tager et tilfældigt punkt i objektet. Fra dette
punkt beregner man nu afstanden til det punkt, i objektet, der ligger længst væk.
Fra dette nye punkt beregner man så igen afstanden til det punkt der ligger
længst væk. På denne måde får man hurtigt beregnet den største diameter
figuren kan have. Ved at beregne afstandene fra diameteren til centeraksen i de
to ender, kan toppen findes. Toppen er der, hvor der er længst afstand ind til
storaksen (figur 18.13). Hvis kimet har en anden form, end den der er vist på
figuren, kan diameteren komme til at ligge et andet sted. Det er derfor ikke et
holdbart kriterium, at bruge afstanden mellem diameteren og længdeaksen,
som det ses på figur 18.14.
Fordele
• Algoritmen for afstandsberegning er nem at udføre
Ulemper
• Algoritmen er baseret på længdeaksen i ellipsen og hvis denne ligger
lidt skævt, er det ikke sikkert at kriteriet, om at det er afstanden mellem
længde aksen og diameteren, er brugbart
18.7.1.11 Linie til alle punkter
Figur 18.12
Thinning, som danner
et ”y” i toppen
Figur 18.13
Diameter
Figur 18.14
Problemet med parallelle
akser
Side 96 af 131

18 Appendiks 18.7 Valg af TopDetection-algoritme
Denne metode bygger på, at man fra hver eneste pixel i kanten af objektet
tegner en streg til hver enkel af alle andre pixels i kanten. På denne måde opstår
der et nyt objekt, som har fået udfyldt kimbladsstrukturen i toppen (figur 18.15).
Dette nye objekt og det oprindelige kan så sammenlignes. I den ende hvor der
er mindst lighed findes toppen. Det kan dog give problemer, hvis kimet er
krumt, hvilket kan ses på figur 18.16.
På denne måde kommer stregerne som tegnes mellem punkterne til at ligge
udenfor objektet.
Fordele
• Metoden er uafhængig af centerkoordinater og aksernes orientering
Ulemper
• Metoden er følsom overfor krumhed i kimet
18.7.1.12 Ellipse
Denne metode gør brug af, at der allerede er en approksimeret en ellipse.
Denne kan anvendes til sammenligning med objektet. I den ende hvor der er
mindst lighed mellem de to figurer, findes toppen (figur 18.17).
Fordele
• Der findes allerede teknikker til at approksimere en ellipse
Ulemper
• Metoden kræver at kimet er symmetrisk omkring længdeaksen i
ellipsen
18.7.2 Rating af idéer
For at fastslå hvilken af idéerne fra brainstormingen der skal anvendes, benyttes en metode (AIPA
[1:47-48]) hvor man sammenligner alle idéerne parvis. Metoden bygger på ét intuitivt valg af hvilken
af de to idéer, der vinder sammenligningen. I tabel 18.1 er sammenligningen foretaget.
Tabel 18.1
Ratingskema hvor ideerne er sammenlignet parvis
Figur 18.15
Linie til alle punkter
Figur 18.16
Viser problemet med en
buet figur
Figur 18.17
Ellipse
Side 97 af 131

18 Appendiks 18.7 Valg af TopDetection-algoritme
18.7.2.1 Valg af idé
Herefter tælles der sammen hvor mange gange en idé har vundet en sammenligning. Den eller de
som har vundet flest, går så videre til en nærmere undersøgelse. Det er valgt, at nr. 1, 2 og 3 er idéer,
som gruppen ønsker at arbejde videre med.
1. Diameter
2. Thinning
3. a) Arealforskel
b) Afstand 2
c) Linie til alle punkter
Disse idéer ønskes nærmere undersøgt og det er heriblandt, at den metode som der ønskes at
arbejde videre med skal findes.
18.7.2.2 Førsteplads
”Diameter”-metoden vandt ratingen, og det var derfor umiddelbart denne metode, der skulle bruges
til at finde top og bund. Som nævnt i Appendiks 18.7.1.10 Diameter s. 96, er dens svaghed at kriteriet,
om at bruge afstanden mellem diameteren og storaksen i ellipsen, til at bestemme top og bund, ikke
vil være holdbart i alle tilfælde. Ved nærmere undersøgelser viser det sig, det ikke nødvendigvis er i
toppen, der er den længste afstand mellem de to linier. Hvis kimet er en asymmetrisk, kan det lade
sig gøre at den største afstand opstår i bunden. Gruppen har vurderet at dette er for uholdbart, og
har derfor fravalgt metoden.
18.7.2.3 Andenplads
”Thinning” blev nr. 2 i ratingen efter Diameter-metoden. Metoden er, som beskrevet i Appendiks
18.7.1.9 Thinning s. 96, følsom overfor urenheder i kanten samt udposninger i figuren. Ved nærmere
undersøgelser viser det sig at det ikke sikkert, at y’et vil være lige. Det kan være krumt, afhængigt af
kanten på objektet. Der blev derfor ikke fundet noget kriterium, der kan opstilles til at bestemme
toppen. Derfor valgte gruppen også at fravælge denne idé.
18.7.2.4 Tredjeplads
”Arealforskel” blev rated som nr. 3, sammen med ”Afstand 2” og ”Linie til alle punkter”. Her blev
”Arealforskel” valgt, da det var den algoritme, som syntes at have flest fordele. Den blev vurderet
som værende robust, og kræver kun at kimet har kimbladsstruktur. Dette gør det muligt, at udviske
de skarpe kanter, og på denne måde få en nævneværdig forskel mellem det originale kim-objekt, og
det hvor algoritmen er blevet anvendt.
Side 98 af 131

18 Appendiks 18.8 Kodestandard
18.8 Kodestandard
18.8.1 Indledning
For at koden skal fremstå ensartet, er der fastlagt en kodestandard. Denne skal også hjælpe til med at
gøre koden mere læsevenlig.
18.8.2 Navngivning
Variabelnavne, klassenavne m.m. skrives altid på engelsk og skal værende sigende.
18.8.2.1 Klasser
Alle klasser navngives med det første bogstav stort. Indgår der flere ord i navnet, startes det nye ord
igen med stort. Derudover har .h filer og .cpp filer altid det samme navn.
Eksempel:
class EllipseApproximation
EllipseApproximation.cpp
EllipseApproximation.h
18.8.2.2 Variable
I variabelnavne skrives det første bogstav altid med småt. Kommer der et nyt ord i navnet skrives
dette med stort.
Eksempel:
int numberOfBlobs
18.8.2.3 Definements
Definements skrives altid med store bogstaver og indgår der flere ord, adskilles disse af en
underscore ”_”.
Eksempel:
#define HISTOGRAM_SIZE 256
18.8.2.4 Pointere
Pointere navngives med et ”p” foran navnet. ”p”’et er med småt og det efterfølgende ord er med
stort. Er det en dobblet pointer tilføjes der et ”p” mere.
Side 99 af 131

18 Appendiks 18.8 Kodestandard
Eksempel:
Seed *pSeed
int **ppSubBlob
18.8.3 Udseende
18.8.3.1 Pointere
Når pointeren oprettes benyttes ”*”-operatoren, som altid står sammen med navnet og ikke typen.
Eksempel:
int *pBlobList
18.8.3.2 Referencer
Oprettes der referencer med ”&”-operatoren, står denne altid sammen med navnet på referencen og
ikke typen
Eksempel:
void execute(GrayScale &binaryImage)
18.8.3.3 Funktioner
Der er ingen mellemrum mellem parentesen, og det første og sidste der står inde i den.
Eksempel:
void rootUnion(int a, int b)
18.8.3.4 Indrykning
Koden inddeles i niveauer. Et niveau er det der står mellem de to tegn ”{” og ”}” og der skal være
én tabulator indrykning.
Eksempel:
int BlobDetection::rootFind(int a)
{
if (pSubBlobList[a] == a)
{
return a;
}
else
{
return rootFind(pSubBlobList[a]);
}
}
Side 100 af 131

18 Appendiks 18.8 Kodestandard
18.8.4 Programmeringsregler
Hvis en klasse består af flere funktioner, der afvikles i rækkefølge, oprettes der en execute()funktion
hvorfra disse funktioner afvikles.
Eksempel:
void BlobDetection::execute(GrayScale &binaryImage)
{
pBinaryImage = &binaryImage;
height = pBinaryImage->getHeight();
width = pBinaryImage->getWidth();
}
findSubBlobs();
joinSubBlobs();
makeBlobs();
Side 101 af 131

18 Appendiks 18.9 Implementering
18.9 Implementering
18.9.1 Color
Da der er behov for at arbejde med billeder i forskellige størrelser, er bredden og højden variable.
Selve billedet gemmes i tre dobbeltarrays. Disse tre dobbeltarrays indeholder hver sin farve (rød,
grøn og blå). Det første index er y-koordinatet mens det andet index er x-koordinatet. På grund af
den variable højde og bredde er de tre dobbeltarrays allokeret dynamisk.
18.9.1.1 Color()
Ved hjælp af overloading er der lavet to forskellige versioner af constructoren Color(). Den ene er
en simpel constructor, som sørger for at højden, bredden bliver initialiseret til 0. Da der er behov for
at kunne kopiere et billede er den anden er en copy-constructor, der sørger for at kopiere et billede
fra det ene color-objekt til et andet. Dette gøres ved at kopiere variablerne, allokere plads til de tre
dobbelt arrays og kopiere værdierne fra de tre arrays til det nye objekt.
18.9.1.2 execute()
Ved hjælp af overloading er der lavet to forskellige versioner af execute(). Den ene version af
execute() tager den ønskede bredde og højde som parameter. Funktionen opretter de tre dobbeltarrays
og sørger for at nulstille disse så billedet er sort som udgangspunkt.
void Color::execute(int setWidth, int setHeight)
{
width = setWidth;
height = setHeight;
}
makeVirtualImage();
clearImage();
Den anden version af execute() tager et filnavn som parameter. Filen skal være et ikke
komprimeret BMP-billede. Hele filen bliver kopieret over i en buffer, så der kun skal læses fra
harddisken én gang. Ud fra oplysninger fra headeren findes billedets højde samt bredde og de
dynamiske arrays bliver allokeret.
Farvedybden læses ind fra headeren. Hvis farvedybden er 8 bit oprettes der en palette. Indlæsning af
billeddata starter fra den adresse som offset-værdien peger på. Hvis billedets farvedybde er 8 bit slås
billeddataene op i paletten for at finde farven. Hvis billedet er 24 bit læses billededataene direkte ind
i de 3 farvearrays.
18.9.1.3 save()
Funktionen sørger for at billedet bliver gemt til disken. For at undgå flere skrivninger til harddisken
oprettes der en buffer, hvor alle dataene skrives i. Billedet bliver gemt i 24-bit, så der er ikke nogen
palette med. Billedets højde, bredde, farvedybde mv. bliver skrevet til headeren. Efterfølgende bliver
de enkelte pixels farve skrevet i datadelen af bufferen. Når alle pixels er skrevet til bufferen kopieres
denne til harddisken hvor filen oprettes.
Side 102 af 131

18 Appendiks 18.9 Implementering
18.9.1.4 getWidth(), getHeight()
Da width og height er erklæret som ”private” bruges getWidth() og getHeight() til at hente
henholdsvis bredden og højden af det aktuelle billede.
18.9.1.5 getRedPointer(), getGreenPointer(), getBluePointer()
Funktionerne returnerer en pointer til det aktuelle dobbeltarray. Funktionerne bruges, hvis man har
behov for at tilgå billededataene direkte. Dette er det hurtigste, hvis man har mange skrivninger eller
læsninger til givent billede. Dog skal man selv holde styr på, at man skriver indenfor billedet.
18.9.1.6 getValue(), setValue()
getValue() bruges til at få oplyst farven i en given pixel. setValue() bruges til at sætte farven i en
given pixel. Når man benytter disse mutator- og accessor-funktioner sørger klassen for, at man ikke
læser/skriver uden for billedet.
18.9.1.7 clearImage()
Funktionen bruges til at nulstille alle pixels i billedet. Funktionen bruges bl.a. efter at man har
allokeret ny hukommelse, så de data der skulle ligge på de givne pladser bliver nulstillet.
18.9.1.8 makeVirtualImage()
Funktionen allokerer hukommelse til dobbeltarrays med de tre farver i.
18.9.1.9 ~Color()
Destuctoren sørger for at slette de tre dynamisk erklærede dobbeltarrays.
18.9.2 Binary
I funktionen execute() i klassen afvikles 2 funktioner, makeHistogram() og evaluateThreshold().
18.9.2.1 makeHistogram()
Det første trin i processen er at skabe et histogram. Dette gøres ved at traversere igennem billedet i
dets 2 dimensioner, og tælle op hvor mange gange hver pixelintensitet forekommer. ppGrayArray er
en dobbeltpointer, der peger på arrayet der indeholder billedet:
void Binary::makeHistogram(void)
{
for(int i=0; i

18 Appendiks 18.9 Implementering
}
}
Herefter er histogrammet til rådighed i klassen i arrayet histogram.
18.9.2.2 evaluateThreshold()
Næste trin er at udføre Ridler og Calvards iterative thresholding-teknik. Indledende deklareres og
initialiseres alle variable:
void Binary::evaluateThreshold(void)
{
int i = 0;
float backGroundMean = 0, foreGroundMean = 0;
int oldThreshold = 0, newThreshold = 127;
int backGroundItems = 0, foreGroundItems = 0;
int backGroundSum = 0, foreGroundSum = 0;
…
newThreshold er den variabel der indeholder k T . Dvs. For første iteration skal T0 sættes. Den sættes
altid til midt i histogrammet (127), da det er det bedste simple bud. Algoritmen er næsten ufølsom
overfor hvilken værdi T 0 antager, og derfor er der ikke nogen grund til at anvende mere
sofistikerede metoder til at bestemme T 0 .
Herefter begynder iterationen, der vil køre indtil en af to betingelser er falske: Enten er k T lig T k + 1
(dvs. der er altså ikke nogen ændring i thresholdværdien længere), eller også har iterationsloopet kørt
10 gange. Der er sat en øvre grænse på 10, da 6-7 iterationer som regel er nok:
…
bool breakLoop = false;
for(int k=0; !breakLoop; k++)
{
backGroundSum =0;
backGroundItems =0;
foreGroundSum =0;
foreGroundItems =0;
for(i=0; i0)
{
foreGroundMean = float(foreGroundSum)/foreGroundItems;
}
else
{
foreGroundMean = 0;
}
Side 104 af 131

18 Appendiks 18.9 Implementering
}
oldThreshold = newThreshold;
newThreshold = int((backGroundMean+foreGroundMean)/2+0.5);
if(oldThreshold==newThreshold || k>=10)
{
breakLoop=true;
}
}
threshold = newThreshold;
Den nye thresholdværdi er nu tilgængelig for klassen i variablen threshold.
Sidste trin i processen er selve thresholdingen af billedet. Dette foregår ved, at der først dannes et
nyt billede, der skal indeholde det nye thresholdede binære billede. Herefter traverseres billedet på
samme måde som ved genereringen af histogrammet, og det undersøges hvorvidt den aktuelle pixels
pixelintensitet er over eller under den fastsatte thresholdværdi. Hvis værdien er under eller lig sættes
0 ind i det binære billede, og hvis værdien er over sættes 255 ind:
void Binary::makeBinary(GrayScale &binaryImage)
{
binaryImage.execute(width, height);
unsigned char **ppBinaryArray = binaryImage.getPointer();
}
int x,y;
for(y=0; y

18 Appendiks 18.9 Implementering
18.9.3.3 Sikkerhedsproblematik
Alle variabler i Seed-klassen er erklæret som ”public”, så andre klasser kan rette i værdierne. Dette er
ikke god programmeringsskik, men det vurderes ikke at være et væsentligt problem, da gruppen godt
kan administrere tilgangen til klassen.
Seed-klassen indeholder ingen funktioner, men følgende variabler:
class Seed
{
private:
};
public:
// BlobDetection
int seedNumber;
int area;
int boundsXMin;
int boundsXMax;
int boundsYMin;
int boundsYMax;
GrayScale grayScale;
// EllipseApproximation
float centerOfMassX;
float centerOfMassY;
float eccentricity;
float majorAxis;
float minorAxis;
float thetaMajorAxis;
float thetaMinorAxis;
// Symetry
float symmetry;
// TopDetection
int centerTopX;
int centerTopY;
bool topDetection;
int expandShrinkPixels;
float thetaCenterTop;
float thetaTop;
// Quality
bool approved;
18.9.3.4 Sammenfatning
Der er med succes lavet en klasse, hvor de forskellige oplysninger omkring
de enkelte kim kan gemmes, så andre klasser kan tilgå relevante
oplysninger på kimene. Ydermere bør der ved en senere realisering laves
accessor- og mutator-funktioner, for at sikre korrekt tilgang til variablerne.
18.9.4 BlobDetection
Funktionen execute() analyserer det binære billede. Efterfølgende kan de
relevante objekter, trækkes ud med funktionen makeSeeds().
18.9.4.1 execute()
Funktionen sørger for at funktionerne; findSubBlobs(), joinSubBlobs()
Figur 18.18
Flowchart for execute
Side 106 af 131

18 Appendiks 18.9 Implementering
og makeBlobs() bliver eksekveret i nævnte rækkefølge (figur 18.18).
18.9.4.2 findSubBlobs()
Denne funktion sørger for at knytte de enkelte pixels i billedet til de forskellige subblobs. Hvis det
opdages, at 2 subblobs rører ved hinanden, bliver disse knyttet sammen med funktionen
rootUnion().
18.9.4.3 Træstrukturen
Træstrukturen realiseres med arrayet pSubBlobList, samt funktionerne rootFind() og rootUnion().
For hver subblob er der en plads i arrayet, som bruges til sammenknytning. Værdien i arrayet
afspejler hvilken subblob, subblobben er knyttet til. Hvis værdien svarer til subblobens eget
nummer, er subblobben en rod i sig selv.
18.9.4.4 rootFind()
Funktionen bruges til at finde roden til en subblob. Dette gøres ved at slå subblobbens nummer op i
pSubBlobList, hvorfra det kan indlæses hvilken subblob, den er knyttet til. Dog kan det forekomme,
at roden er knyttet til en tredje subblob. Derfor kalder funktionen sig selv med det nye
subblobnummer som parameter. Funktionen stopper med at kalde sig selv, når den har fundet
roden.
int BlobDetection::rootFind(int a)
{
if (pSubBlobList[a] == a)
{
return a;
}
else
{
return rootFind(pSubBlobList[a]);
}
}
18.9.4.5 rootUnion()
Funktionen bruges til at sætte to forskellige subblobs sammen. Da de begge kan være knyttet til
andre subblobs, er det nødvendigt først at finde deres rod med rootFind(). Når rødderne er fundet,
knyttes rødderne sammen, ved at lade den med det største nummer pege på den med det mindste
ved at rette i pSubBlobList.
void BlobDetection::rootUnion(int a, int b)
{
int rootA;
int rootB;
rootA = rootFind(a);
rootB = rootFind(b);
if(rootA < rootB)
{
pSubBlobList[rootB] = rootA;
}
else if(rootA > rootB)
{
pSubBlobList[rootA] = rootB;
}
Side 107 af 131

18 Appendiks 18.9 Implementering
}
18.9.4.6 joinSubBlobs()
Denne funktions laver en liste, der sammenkæder de enkelte subblobs, med de blobs som de er
knyttet til. Listen realiseres i arrayet pBlobList, hvor indexet er subblobnummeret og værdierne er
blobnummeret.
void BlobDetection::joinSubBlobs(void)
{
pBlobList = new int[numberOfSubBlobs];
}
for(int i=0; i 0
&& pBlob[i].boundsYMax < height-1
numberOfSeeds++;
}
}
return numberOfSeeds;
Side 108 af 131

18 Appendiks 18.9 Implementering
18.9.4.10 makeSeeds()
Funktionen genererer et array af seed-objekter, og kopierer værdierne fra blobsne over i disse.
18.9.5 EllipseApproximation
Formålet med afsnittet er at beskrive virkemåden af den C++-kode, der realiserer teorien i afsnit 9.2
Teori s. 34. Klassen er overordnet bygget op med en funktion execute(), der sørger for en korrekt
afvikling af funktionerne i klassen. execute() kan overordnet beskrives med følgende flowchart
(figur 18.19):
18.9.5.1 execute()
Funktionen består overordnet af en for-løkke,
der gennemløber alle kimene, der er fundet
med BlobDetection. numberOfSeeds er det
totale antal af kim (objekter) og seedCounter er
en tæller, der inkrementeres for hvert objekt
der arbejdes på. I execute() eksekveres 3
funktioner:
1. Find alle koordinater hvor der er hvide
pixels
2. Udregn massemidtpunktet for alle
hvide pixels
3. Bestem den principale stor- og lilleakse
samt vinklerne hertil
18.9.5.2 getCoordinates()
Denne funktion har til formål at finde alle
steder i billedet, hvor der er hvidt. Billedet
traverseres i både x- og y-dimensionen, og for
hver pixel der er hvid, afsættes x- og ykoordinatet
i hvert sit array. På den måde
opnås en samling af koordinater, hvor der
findes hvide pixels:
void EllipseApproximation::getCoordinates()
{
int i=0;
for(int y=0; y

18 Appendiks 18.9 Implementering
18.9.5.3 Utilities.calculateCenterOfMass()
Denne funktion er beskrevet i Appendiks 18.9.11.2 calculateCenterOfMass() s. 123.
18.9.5.4 calculateAxes()
Funktionen har overordnet til formål at udregne stor- og lilleaksen i ellipsen, samt disses vinkler med
den horisontale x-akse. Det gøres ved at implementere teorien beskrevet i afsnit 9.2.2 Orientering i
planet s. 35. Indledende skal massemidtpunktet bringes til centrum i koordinatsystemet ved at
fratrække alle x- og y-koordinater massemidtpunktets x- og y-koordinater (ligning (18.11)):
void EllipseApproximation::calculateAxes(Coordinates CM)
{
for(int i=0; i

18 Appendiks 18.9 Implementering
Til sidst i funktionen udregnes excentriciteten axisRatio og længderne på stor- og lilleakserne. Disse
længder skal bruges i en senere klasse til at tegne ellipsen med:
…
float axisRatio = 0;
if(momentOfInertiaMax>0)
{
axisRatio = momentOfInertiaMin/momentOfInertiaMax;
}
if(axisRatio>0)
{
majorAxis = float(sqrt(numberOfPixels/(M_PI*sqrt(axisRatio))));
minorAxis = float(numberOfPixels/(M_PI*majorAxis));
}
else
{
majorAxis = 0;
minorAxis = 0;
}
float eccentricity = sqrt(1-axisRatio);
…
Til sidst i funktionen opdateres det aktuelle seed med de nyudregnede oplysninger:
}
…
pSeed[seedCounter].thetaMajorAxis = thetaMajorAxis;
pSeed[seedCounter].thetaMinorAxis = thetaMinorAxis;
pSeed[seedCounter].majorAxis = majorAxis;
pSeed[seedCounter].minorAxis = minorAxis;
pSeed[seedCounter].eccentricity = eccentricity;
18.9.6 ExpandShrink
Klassen ExpandShrink indeholder de to funktioner expand() og shrink(). Der er ikke nogen
execute()-funktion, da de to algoritmer ikke nødvendigvis skal afvikles sekventielt.
18.9.6.1 expand()
Parametrene, som sendes til denne funktion, er pointerne til to GrayScale-billeder, samt antallet af
gange det ønskes at expande. Det første GrayScale-billede er det billede, som operationen skal
udføres på, source. Det andet er det, som der skal skrives til, altså resultatet destination. Det første
som udføres er, at dimensionerne på destination-billedet beregnes og oprettes. Herefter farves
destination-billedets pixels sorte:
void ExpandShrink::expand(GrayScale &source, GrayScale &destination, int magnification)
{
int width, height;
height = source.getHeight();
width = source.getWidth();
destination.execute(width+2*magnification, height+2*magnification);
unsigned char **ppSpurceGrayScalePointer = source.getPointer();
unsigned char **ppDestGrayScalePointer = destination.getPointer();
for(int y = 0; y < height+magnification*2; y++)
{
for(int x = 0; x < width+magnification*2; x++)
{
ppDestGrayScalePointer[y][x] = 0;
}
}
Side 111 af 131

18 Appendiks 18.9 Implementering
…
Nu traverseres der igennem source-billedet. Et eksempel på et source-
billede på 10 x 10 pixel er vist på figur 18.20. Den hvide pixel ligger på
position (1,1).
Expandes der én gang så bliver det nye destination-billede 12 x 12 pixel, og
den hvide pixel kommer til at ligge i (2,2). Nu skal alle dens naboer farves
hvide. Starter man i destination-billedet, der hvor man finder en hvid pixel
i source-billedet, altså i (1,1) og farver to gange antallet af gange, der skal
expandes i den positive x-retning. I dette tilfælde vil det sige, at der farves fra
(1,1) til (1,3). Dette resulterer i, at man får farvet den nederste række pixels
(figur 18.21), i den firkant man ønsker tegnet:
Gentages dette igen, to gange af antallet af gange det ønskes at expande, i den positive y-retning,
dvs. igen fra 1 til 3, opnås det ønskede resultat, at alle nabopixelene rundt om 2,2, bliver farvet hvide
(figur 18.22):
Dette princip er implementeret i expand()-funktionen:
…
Figur 18.21
Udvidet billede hvor den
nederste række i firkanten er
genereret
Figur 18.22
Det færdigt udvidede billede,
med 1 gang expand
for(int y = 0; y < height; y++)
{
for(int x = 0; x < width; x++)
{
if(ppSpurceGrayScalePointer[y][x] != 0)
{
for(int m = y ; m < y + 2*magnification+1; m++)
{
for(int n = x; n < x + 2*magnification+1; n++)
{
ppDestGrayScalePointer[m][n] = 255;
}
}
Figur 18.20
En figur bestående af 1
pixel
Side 112 af 131

18 Appendiks 18.9 Implementering
}
}
}
}
18.9.6.2 shrink()
Inputtene til denne funktion er de samme som til expand()-funktionen. De to GrayScale-billeder,
med henholdsvis source og destination, samt det antal gange det ønskes at formindske billedet.
Igen beregnes der først dimensioner på destination-billedet. Da det er muligt, at de nye
dimensioner bliver negative kontrolleres det, at dette ikke sker. Herefter farves destinationbilledets
pixels hvide:
void ExpandShrink::shrink(GrayScale &source, GrayScale &destination, int magnification)
{
int width, height;
height = source.getHeight();
width = source.getWidth();
if(width-2*magnification

18 Appendiks 18.9 Implementering
18.9.7 TopDetection
TopDetection-klassen er opbygget således, at den har en funktion
execute(), som er hovedfunktionen, der eksekverer alle
underfunktioner, som er nødvendige for at udføre klassens
formål.
18.9.7.1 execute()
execute()-funktionen består af en stor for-løkke hvori der
udføres en række operationer på hvert enkelt kim (figur 18.23).
I tilfælde af det ønskes at fjerne urenheder i kanten, kan kimet
shrinkes og expandes et antal gange. Herefter expandes og
shrinkes kimet 4 gange (afsnit 11.3 Test s. 51 for nærmere
information).
Nu findes forskellen mellem billedet, hvor kanten er blevet
renset, og det som er blevet expandet og shrinket 4 gange i
funktionen subtract(). I denne funktion udregnes også topmassemidtpunktet.
Til sidst beregnes vinklen mellem det
vandrette plan, som går igennem massemidtpunktet fra
ellipseapproksimationen, og den linie som dette punkt danner
med det nye massemidtpunkt beregnet i subtract(). Dette
sker i funktionen findTop(). I denne funktion kontrolleres
det også hvilken ende af kimet, der er toppen:
void TopDetection::execute(void)
{
for(int count = 0; count < numberOfSeeds; count++)
{
ExpandShrink expandShrink;
}
GrayScale expanded, shrinked, subtracted, forExpand, forShrink;
expandShrink.shrink(pSeed[count].grayScale, forShrink, 0);
expandShrink.expand(forShrink, forExpand, 0);
expandShrink.expand(forExpand, expanded, 4);
expandShrink.shrink(expanded, shrinked, 4);
subtract(forExpand, shrinked, subtracted, count);
}
findTop();
18.9.7.2 Subtract()
Start
execute()
Count

18 Appendiks 18.9 Implementering
…
for(int y = 0; y < height; y++)
{
for(int x = 0; x < width; x++)
{
if(ppTempSource1GrayScalePointer[y][x]!=
ppTempSource2GrayScalePointer[y][x])
{
ppTempDestGrayScalePointer[y][x] = 255;
numberOfWhitePixels++;
}
}
}
…
Derefter beregnes massemidtpunktet for de små arealer som er opstået. Til dette formål anvendes
Utilities-klassens calculateCenterOfMass(). Bagefter tilføjes koordinater for punktet i seedobjektet:
…
CenterOfMass centerOfMassCoordinates;
Utilities utilities;
centerOfMassCoordinates = utilities.calculateCenterOfMass(destination, numberOfWhitePixels);
pSeed[count].centerTopX = int(centerOfMassCoordinates.xCoordinate) + pSeed[count].boundsXMin;
pSeed[count].centerTopY = int(centerOfMassCoordinates.yCoordinate) + pSeed[count].boundsYMin;
pSeed[count].TopBottomDetection = true;
…
18.9.7.3 findTop()
I denne funktion implementeres beregningen af vinklen mellem den linie, der går igennem de to
massemidtpunkter og det vandrette plan. De to massemidtpunkter er fra henholdsvis
ellipseapproksimationen og subtract()-funktionen. Som det første beregnes sidelængderne i
trekanten a, b og c. Derefter beregnes vinklen. Herefter følger de to tjek der afgør om topmassemidtpunktet
ligger på henholdsvis den ene eller den anden side af lilleaksen. Til sidst tilføjes
det i hvilken ende toppen er beregnet til at ligge, i seed-objektet:
…
b = float(pSeed[count].centerTopX - pSeed[count].centerOfMassX);
a = float(pSeed[count].centerTopY - pSeed[count].centerOfMassY);
c = sqrt(pow(a,2)+pow(b,2));
angle = acos(b/c);
if(a pSeed[count].thetaMinorAxis && pSeed[count].thetaCenterTop <
pSeed[count].thetaMinorAxis + M_PI)
{
pSeed[count].thetaTop += float(M_PI);
}
}
else
{
if(pSeed[count].thetaCenterTop > pSeed[count].thetaMinorAxis || pSeed[count].thetaCenterTop <
pSeed[count].thetaMinorAxis - M_PI)
{
pSeed[count].thetaTop += float(M_PI);
}
}
…
Side 115 af 131

18 Appendiks 18.9 Implementering
18.9.8 Symmetry
I dette afsnit gennemgås implementeringen af en løsning på teorien beskrevet i 12 Symmetry s. 54.
Klassen er bygget op efter standarden med en execute() funktion, der sørger for at funktionerne i
klassen bliver afviklet i rigtig sekvens.
18.9.8.1 execute()
execute() indeholder en for-løkke, der gennemløber alle kimene (seedCounter). Hver gang afvikles
funktionen getPixelDeviation(), som har til formål at udregne den procentvise symmetri-værdi:
void Symmetry::execute(void)
{
int seedCounter;
for(seedCounter=0; seedCounter

18 Appendiks 18.9 Implementering
Når denne er udregnet roteres koordinatet tilbage (e), og origo flyttes tilbage fra massemidtpunktet:
…
e = rotateCoordinate(d, thetaMajorAxis);
e.xCoordinate += CM.xCoordinate;
e.yCoordinate += CM.yCoordinate;
x2 = int(e.xCoordinate+0.5);
y2 = int(e.yCoordinate+0.5);
…
Koordinatsættet (x2,y2) er nu punktet, som evt. kan være symmetripartner med (x1,y1). Herefter
undersøges det om (x2,y2) ligger inden for boundingboxen, og hvis dette er tilfældet skal det
undersøges om (x2,y2) er hvid pixel, og hvis ikke inkrementeres pixelsDeviation. Hvis den ligger
uden for boundingboxen kan den ikke være symmetrisk med andre pixels så derfor inkrementeres
der også i det tilfælde:
…
}
}
…
grayScale.setValue(x1,y1,255);
if((x2>=0 && x2=0 && y2

18 Appendiks 18.9 Implementering
række nøgleord initialiseres. I filen står der efter hvert af disse nøgleord et kolon og derefter den
tilhørende værdi:
void Quality::getParametersFromFile(void)
{
string line, sub;
int i = 0;
size_t offset1, offset2;
char *search0 = "#";
char *search1 = "areaLow";
char *search2 = "areaHigh";
char *search3 = "symmetryLow";
char *search4 = "symmetryHigh";
char *search5 = "eccentricityLow";
char *search6 = "eccentricityHigh";
char *search7 = "expandShrinkLow";
char *search8 = "expandShrinkHigh";
char *search9 = "selectionModel";
char *colon = ":";
…
Herefter hentes ”settings.ini” og det kontrolleres om den er åben. Hvis den er det, afvikles nu et
while-loop, der kører så længe enden i filen ikke er nået. I loopet læses filen ind linie for linie. Det
første der kontrolleres er om linien indeholder et # (search0) tegn. Er dette tilfældet, springes linien
over, da dette betyder udkommentering, ellers kontrolleres det om et af de andre nøgleord er
indeholdt i linien. Findes et af dem, overføres værdien til den respektive variabel i programmet:
…
ifstream infile("settings.ini");
if(infile.is_open())
{
while(infile.good())
{
getline(infile,line);
if(line.find(search0, 0) == string::npos)
{
if (offset1 = line.find(search1, 0) != string::npos)
{
offset2 = line.find(colon, offset1);
sub = line.substr((long)offset2+1);
std::istringstream strin(sub);
strin >> areaLow;
}
…
På denne måde fortsættes der for alle variablerne, der skal indlæses. Herefter kontrolleres det om alle
variable er blevet hentet ind fra filen, og der udskrives en fejlmeddelelse, hvis en af dem ikke er. Som
eksempel angives areaLow, men proceduren er ens for alle variablerne:
…
}
}
if(areaLow == PARAMETER_NOT_SPECIFIED)
{
cout

18 Appendiks 18.9 Implementering
18.9.9.3 evaluateSeeds()
Funktionen har til formål at implementere ønsket,
om at kunne udvælge kim ved både at bruge
boks- og ellipsoide-modellen. Fremgangsmetoden
er som følger (figur 18.24):
1. Først undersøges det om der ønskes
anvendt boks- eller ellipsoide-model
2. Hvis der anvendes ellipsoide-model
udregnes x0, y0, z0, a, b og c
3. Herefter gennemløber for-løkken alle
kimene i seeds-objektet
4. Det undersøges om det aktuelle kim
falder inden for grænserne for den valgte
model
Koden i C++ er som følger:
void Quality::evaluateSeeds(void)
{
float x0, y0, z0;
float aSquared, bSquared, cSquared;
…
På 1. og 2. trin i fremgangsmetoden ovenover undersøges det, om der er valgt ellipsoide-modellen,
og i så fald regnes x0, y0, z0, a, b og c ud:
…
if (selection!=0)
{
float temp;
temp = (float(expandShrinkHigh)-float(expandShrinkLow))/2;
x0 = expandShrinkHigh-temp;
aSquared = float(pow(double(temp),2));
}
…
temp = (float(symmetryHigh)-float(symmetryLow))/2;
y0 = float(symmetryHigh)-temp;
bSquared = float(pow(double(temp),2));
temp = (float(areaHigh)-float(areaLow))/2;
z0 = float(areaHigh)-temp;
cSquared = float(pow(double(temp),2));
På 3. trin gennemløbes for-løkken, og dataene hentes på kimet:
…
for(int i=0; i

18 Appendiks 18.9 Implementering
float x = float(pSeed[i].expandShrinkPixels);
float y = float(pSeed[i].symmetry);
float z = float(pSeed[i].area);
float eccentricity = float(pSeed[i].eccentricity);
bool condition = false;
…
Udregning af boks:
…
if(selection==0)
{
condition = (x>=expandShrinkLow && x=symmetryLow &&
y=areaLow && z=eccentricityLow &&
eccentricity

18 Appendiks 18.9 Implementering
18.9.10 Draw
For visuelt at kunne se resultaterne af de forskellige algoritmer, er denne klasse lavet. Klassen giver
mulighed for at tegne resultaterne af de forskellige algoritmer på det originale inputbillede eller på en
simpel sort baggrund.
Klassen giver mulighed for at tegne 5 forskellige elementer på billedet:
1. De enkelte blobs i tydeligt forskellige farver
2. De enkelte blobs i rød farve, hvor blobbens nummer står i den blå farvekanal
3. Boundingboxene omkring de enkelte objekter
4. Approksimerede ellipser med stor- og lilleaksen
5. Pink pixel til markering af top på kim
Ved tegning af de forskellige elementer kan det vælges, om der skal tegnes for alle de objekter som
BlobDetection har fundet, eller for alle objekter som Quality-klassen har godkendt.
18.9.10.1 drawBlobs()
Denne funktion har til formål, at give en måde hvorpå man tydeligt kan indikere, hvilke pixels der
hører til hvilken blob, i det samlede billede.
18.9.10.2 drawBlobNumbers()
Disse blobs tegnes ligeledes i det samlede billede, men denne gang gemmes blobbens id-nummer i
den blå farvekanal. Alle blobsne får derfor tildelt en farve på følgende måde:
Blob 0: (255, 0, 0)
Blob 1: (255, 0, 1)
Blob 2: (255, 0, 2)
osv…
På denne måde er det nemt i et billede, at se hvilken blob der har hvilket id-nummer, uden at skulle
lave en decideret skrive-funktionalitet i koden, der kunne skrive tal i billedet.
18.9.10.3 drawBounds()
Boundingboxene tegnes i det samlede billede, og viser grænserne for hver enkelt blob.
18.9.10.4 drawEllipse()
EllipseApproximation-klassen udregner parametrene til den ellipse, der passer bedst til de enkelte
objekter. Klassen skal derfor kunne tegne disse ellipser, samt deres stor- og lilleakser. Når
programmet er kompileret til ”Debug”-mode oprettes der billeder af de enkelte kim med ellipser og
akser.
Side 121 af 131

18 Appendiks 18.9 Implementering
18.9.10.5 Stor- og lilleakserne
Ud fra aksernes vinkel θ, med det vandrette plan, og objektets centerkoordinat, udregnes koordinaterne
for de pixels, der skal tændes ud, fra følgende parameterfremstilling:
x() t = xCM + tcos
θ
y() t = y + tsin
θ
CM
Hvor xCM og yCM er koordinatsættet for ellipsens massemidtpunkt.
18.9.10.6 Ellipse
(18.27)
En ellipse, der ligger vandret i planet, kan tegnes ud fra følgende parameterfremstilling:
x = acos
φ
y = bsin
φ
, hvor
a > b
a er længden af storaksen
b er længden af lilleaksen
φ∈[ 0;2 π]
x samt y er koordinatsættet for de enkelte punkter rundt i ellipsen
(18.28)
Da ellipsen, der ønskes tegnet, sjældent ligger vandret, er det nødvendigt at rotere denne. Et hvert
objekt, i et koordinatsystem, kan drejes omkring origo med følgende ligning:
x = x cos( −θ ) + ysin(
−θ)
2
y = ycos( −θ) −x sin( −θ)
2
, hvor
x og y er koordinatsættet for det punkt der ønskes drejet
θ er vinkel figuren ønskes drejet
x 2 og y 2 er koordinatsættet for det drejede punkt
18.9.10.7 drawCenterTop()
(18.29)
Denne funktionalitet angiver det sted, hvor TopDetection-klassen har fundet toppen af et kim, med
en pink pixel.
18.9.11 Utilities
18.9.11.1 average()
Funktionen udregner gennemsnittet af et array af tal.
Side 122 af 131

18 Appendiks 18.9 Implementering
18.9.11.2 calculateCenterOfMass()
Der lavet to udgaver af denne funktion. Dette er gjort, for at massemidtpunktsudregningen kan
bruges flere steder selvom det, det ene sted er et dobbeltarray af koordinater, og det andet sted er et
grayScale-objekt der arbejdes med:
Coordinates Utilities::calculateCenterOfMass(unsigned char **ppBlob, int ySize, int xSize, int
numberOfPixels)
{
Coordinates CM;
CM = calculateCM(ppBlob, ySize, xSize, numberOfPixels);
return CM;
}
Coordinates Utilities::calculateCenterOfMass(GrayScale &grayScale, int numberOfPixels)
{
Coordinates CM;
unsigned char **ppBlob = grayScale.getPointer();
int xSize = grayScale.getWidth();
int ySize = grayScale.getHeight();
}
CM = calculateCM(ppBlob, ySize, xSize, numberOfPixels);
return CM;
18.9.11.3 calculateCM()
calculateCM() er funktionen, der foretager den reelle massemidtpunktsudregning. Funktionen
består af to for-løkker der traverserer alle x- og y-koordinater igennem og summerer deres værdier
op. Når begge løkker er færdige, deles der med antallet af pixels for at få den gennemsnitlige x- og yværdi.
Disse to værdier er koordinatsættet for massemidtpunktet:
Coordinates Utilities::calculateCM(unsigned char **ppBlob, int ySize, int xSize, int
numberOfPixels)
{
int i=0;
float centerOfMassX = 0, centerOfMassY=0;
}
for(int y=0; y

18 Appendiks 18.10 Test af Binary
18.10 Test af Binary
Her følger testdataene fra testen af Binary-klassen (7.3 Test s. 26):
Billede Forgrund Baggrund Threshold Genereret histogram
blandet1 173,413 19,4556 96
159,905 17,4753 89
157,364 17,1948 87
156,585 17,1149 87
blandet2 191,585 18,3187 105
182,818 17,3078 100
180,957 17,1288 99
180,61 17,0968 99
blandet3 198,586 19,5937 109
191,694 18,735 105
190,213 18,5756 104
189,832 18,536 104
Side 124 af 131

18 Appendiks 18.10 Test af Binary
Billede Forgrund Baggrund Threshold Genereret histogram
blandet4 154,718 19,3838 87
132,542 15,1839 74
127,305 14,4492 71
126,114 14,305 70
125,718 14,259 70
blandet5 162,178 18,49 90
141,364 15,2627 78
135,859 14,5938 75
1134,595 14,4575 75
blandet6 149,828 19,6955 85
123,195 15,2926 69
115,14 14,1802 65
113,224 13,953 64
112,79 13,9039 63
112,295 13,8492 63
blandet7 152,184 18,7445 85
122,392 15,1006 69
112,882 13,9813 63
109,742 13,6578 62
109,243 13,6095 61
108,754 13,5631 61
Side 125 af 131

18 Appendiks 18.10 Test af Binary
Billede Forgrund Baggrund Threshold Genereret histogram
blandet8 173,457 18,0378 96
155,735 15,9664 86
150,170 15,4146 83
148,575 15,2481 82
148,11 15,2264 82
godkendte1 151,721 17,6763 85
132,626 15,3232 74
128,426 14,9924 72
127,694 14,9417 71
127,287 14,9144 71
godkendte2 174,647 16,8111 96
161,644 15,644 89
158,728 15,4239 87
157,925 15,3717 87
godkendte3 158,687 17,2375 88
141,795 15,3152 79
138,376 15,0511 77
137,541 14,9928 76
137,206 14,9701 76
Tabel 18.2
Side 126 af 131

18 Appendiks 18.11 Test af TopDetection
18.11 Test af TopDetection
Testen af TopDetection-algoritmen blev foretaget på 3 billeder. Testresultaterne fra disse bliver
præsenteret i dette Appendiks. For nærmere information omkring hvordan testresultaterne skal
fortolkes henvises der til 10.3 Test s. 47 i hovedrapporten.
18.11.1 Billede 1
Figur 18.25
Kombination
Arealer Antal
Udglatning
Antal
Expand-
Shrink
Antal
rigtigt
fundne
Antal
forkert
fundne
Antal
udefinerede
1 Alle arealer 0 1 17 2 9 60,7
2 Alle arealer 0 2 21 3 4 75,0
3 Alle arealer 0 3 23 3 2 82,1
4 Alle arealer 0 4 23 3 2 82,1
5 Alle arealer 0 5 23 3 2 82,1
6 Alle arealer 1 1 15 2 11 53,6
7 Alle arealer 1 2 20 3 5 71,4
8 Alle arealer 1 3 23 2 3 82,1
9 Alle arealer 1 4 22 3 3 78,6
10 Alle arealer 1 5 22 3 3 78,6
11 Alle arealer 2 1 9 0 19 32,1
12 Alle arealer 2 2 12 2 14 42,9
%
Side 127 af 131

18 Appendiks 18.11 Test af TopDetection
13 Alle arealer 2 3 13 4 11 46,4
14 Alle arealer 2 4 14 4 10 50,0
15 Alle arealer 2 5 14 4 10 50,0
16 Største areal 0 1 16 3 9 57,1
17 Største areal 0 2 20 4 4 71,4
18 Største areal 0 3 22 4 2 78,6
19 Største areal 0 4 22 4 2 78,6
20 Største areal 0 5 23 3 2 82,1
21 Største areal 1 1 15 2 11 53,6
22 Største areal 1 2 19 4 5 67,9
23 Største areal 1 3 21 4 3 75,0
24 Største areal 1 4 21 4 3 75,0
25 Største areal 1 5 22 3 3 78,6
26 Største areal 2 1 9 0 19 32,1
27 Største areal 2 2 13 1 14 46,4
28 Største areal 2 3 13 4 11 46,4
29 Største areal 2 4 13 5 10 46,4
30 Største areal 2 5 13 5 10 46,4
Tabel 18.3
18.11.2 Billede 2
Figur 18.26
Side 128 af 131

18 Appendiks 18.11 Test af TopDetection
Kombination
Arealer Antal
Udglatning
Antal
Expand-
Shrink
Antal
rigtigt
fundne
Antal
forkert
fundne
Antal
udefinerede
1 Alle arealer 0 1 20 2 3 76,9
2 Alle arealer 0 2 24 0 1 92,3
3 Alle arealer 0 3 23 1 1 88,5
4 Alle arealer 0 4 23 1 1 88,5
5 Alle arealer 0 5 22 2 1 84,6
6 Alle arealer 1 1 18 2 5 69,2
7 Alle arealer 1 2 21 2 2 80,8
8 Alle arealer 1 3 19 4 2 73,1
9 Alle arealer 1 4 20 3 2 76,9
10 Alle arealer 1 5 20 3 2 76,9
11 Alle arealer 2 1 10 1 14 38,5
12 Alle arealer 2 2 10 3 12 38,5
13 Alle arealer 2 3 11 3 11 42,3
14 Alle arealer 2 4 11 3 11 42,3
15 Alle arealer 2 5 11 4 10 42,3
16 Største areal 0 1 17 5 3 65,4
17 Største areal 0 2 24 0 1 92,3
18 Største areal 0 3 21 3 1 80,8
19 Største areal 0 4 22 2 1 84,6
20 Største areal 0 5 22 2 1 84,6
21 Største areal 1 1 15 5 5 57,7
22 Største areal 1 2 19 4 2 73,1
23 Største areal 1 3 17 6 2 65,4
24 Største areal 1 4 19 4 2 73,1
25 Største areal 1 5 19 4 2 73,1
26 Største areal 2 1 9 2 14 34,6
27 Største areal 2 2 10 3 12 38,5
28 Største areal 2 3 11 3 11 42,3
29 Største areal 2 4 11 3 11 42,3
30 Største areal 2 5 11 4 10 42,3
Tabel 18.4
%
Side 129 af 131

18 Appendiks 18.11 Test af TopDetection
18.11.3 Billede 3
Figur 18.27
Kombination
Arealer Antal
Udglatning
Antal
Expand-
Shrink
Antal
rigtigt
fundne
Antal
forkert
fundne
Antal
udefinerede
1 Alle arealer 0 1 20 4 4 71,4
2 Alle arealer 0 2 23 3 2 82,1
3 Alle arealer 0 3 23 3 2 82,1
4 Alle arealer 0 4 23 3 2 82,1
5 Alle arealer 0 5 23 3 2 82,1
6 Alle arealer 1 1 19 1 8 67,9
7 Alle arealer 1 2 23 1 4 82,1
8 Alle arealer 1 3 23 1 4 82,1
9 Alle arealer 1 4 23 1 4 82,1
10 Alle arealer 1 5 23 1 4 82,1
11 Alle arealer 2 1 8 3 17 28,6
12 Alle arealer 2 2 12 2 14 42,9
13 Alle arealer 2 3 12 2 14 42,9
14 Alle arealer 2 4 13 2 13 46,4
15 Alle arealer 2 5 12 3 13 42,9
16 Største areal 0 1 20 4 4 71,4
17 Største areal 0 2 23 3 2 82,1
18 Største areal 0 3 23 3 2 82,1
19 Største areal 0 4 23 3 2 82,1
20 Største areal 0 5 23 3 2 82,1
21 Største areal 1 1 19 1 8 67,9
22 Største areal 1 2 22 2 4 78,6
%
Side 130 af 131

18 Appendiks 18.11 Test af TopDetection
23 Største areal 1 3 22 2 4 78,6
24 Største areal 1 4 22 2 4 78,6
25 Største areal 1 5 21 3 4 75,0
26 Største areal 2 1 9 2 17 32,1
27 Største areal 2 2 11 3 14 39,3
28 Største areal 2 3 11 3 14 39,3
29 Største areal 2 4 12 3 13 42,9
30 Største areal 2 5 11 4 13 39,3
Tabel 18.5
Side 131 af 131