Bildegjenkjenning gjort enkelt. Slik gjenkjenner du en bestemt gjenstand ved hjelp av et kamera.

• Utfordringen
• Litt teori
• Hvor starter jeg?
• La oss kjøre bildegjenkjenning
• Bonus: Video

Utfordringen

Denne uken har jeg fått utfordringen å foreslå en løsning på følgende problem:

“Med en enkel datamaskin, som en Raspberry Pi, et kamera og et fuglebrett, lag et program som kan artsbestemme hvilke fugler som er innom brettet og spiser i løpet av en dag.”

Siden spørsmålet var av mer teoretisk art, bestemte jeg meg for å begrense dette innlegget til å introdusere byggeblokkene og gi en forklaring på hvordan du typisk kan bygge et slikt system.

Å gjenkjenne gjenstander er en ganske vanlig oppgave nå for tiden, og den har blitt løst på flere forskjellige måter, og med forskjellige tilnærminger. La oss se på hvordan dette virker.

TL;DR Det fins noen tradisjonelle måter å lage bilde- og gjenstandsgjenkjenning på, som i OpenCV, og det fins noen teknikker basert på Deep Learning, som i TensorFlow. Vil du vite mer? Fortsett å lese.

Litt teori

De mer tradisjonelle prinsippene bak OpenCV for å oppdage er godt beskrevet i dette blogginnlegget, så vel som i denne veiledningen for å gjenkjenne (hold dere fast!) katter på bilder.

Mens dette innlegget forklarer hvordan bildegjenkjenning virker i TensorFlow, som bruker en modell kalt dypt konvolverende nevrale nettverk, vil det også la deg trene opp din egen bildeklassifiserer, slik som OpenCV.

Hvor starter jeg?

I utgangspunktet har du to valg – du bør enten lære opp din egen modell eller finne en modell som har blitt lært opp av noen andre, og du vil kanskje alltid starte med å se etter en forhåndsopplært modell. Men jo mer spesifiserte bildeklassifiseringskravene dine er, jo høyere er sjansen for at du må lære opp din egen modell. Dette vil være det samme enten du velger OpenCV eller TensorFlow.

Siden vi vil kjøre modellen på en relativt enkel datamaskin, kan du vurdere å gjøre prosesseringen i skyen. Det bør imidlertid også være mulig å kjøre OpenCV og TensorFlow på den nyeste Raspberry Pi.

La oss kjøre bildegjenkjenning

Nå vet du litt om teorien. La oss så ta en rask titt på hvordan vi kan lære opp modellene i våre behov.

TL;DR Måten dette virker på, er at du viser modellen ganske mange bilder av en gjenstand, og en tilsvarende mengde bilder uten gjenstanden på.

La oss si at du vil bruke modellen til å gjenkjenne fugler utenfor huset ditt i Norge. Et godt utgangspunkt vil da være å få en liste over de typiske artene som du mest sannsynlig ser i hagen din, og samle så mange bilder av hver art som mulig.

Her er hva du kan gjøre:

1. Start med å finne en liste over norske fugler på Wikipedia, eller Store Norske Leksikon.
2. Søk på nettet etter bilder av hver fugleart. Det kan være du vil automatisere dette arbeidet, og sørg for at du plukker ut bilder med de riktige opphavsrettstillatelsene.
3. Bruk disse bildene i opplæringen av din modell.
4. Sett opp din Raspberry Pi med et kamera og fuglebrett, og gjør deg klar til å identifisere fuglearter. Du bør optimalisere programvaren slik at bildeklassifiseringen ikke skjer hele tiden, men kun når man ser en bevegelse.

Pro tip: Det kan også være litt utfordrende å ta gode bilder av våre fjærkledde venner, så sørg for at kameraet ditt er godt plassert, og materen er på et godt opplyst sted. Uten å forstyrre dyrelivet, så klart.

Lurer du på om lignende systemer har blitt implementert eller om det er mulig? Svaret er ja. Her er det noen lenker til inspirasjon for videre lesning:

• En fugleklassifiserer med tensorflow
• Trene opp en fugleklassifiserer med Tensorflow og TFLearn
• Kjøretøyklassifisering og -telling med OpenCV
• Blomstergjenkjenning i naturen (på dansk)
• Maskinlæring er morsomt! Del 3: Dypt konvolverende nevrale nettverk. (Ta også gjerne en titt på de andre delene i denne artikkelserien.)

Prøv nå å sette alt dette sammen, og fortell meg gjerne hvordan det går!

Lykke til!

Bonus: Video

En video vi har laget av mine tegninger og en kort forklaring på hvordan dette virker.

Jeg har skrevet en artikkel for studentmagasinet INDEX som utgis ved Institutt for Informatikk (Ifi), Universitetet i Oslo. Den ble publisert 30.04.2016, og er tilgjengelig for alle studenter på Ifi. Nå vil jeg også å dele den med alle dere andre som ikke kunne sikre dere en utgave av INDEX på fredag. Enjoy!

• Automatiser
• Automatiske tester og sjekk av kodekvalitet
• Miljøer
• Versjoner
• Veien videre

Tenk deg følgende scenario: Du er en student og har fått i oppgave om å skrive enten et helt nytt program, eller gjøre noen endringer i noe kode som finnes fra før av. Så, hvordan går du fram? Du begynner å skrive kode, du kompilerer og kjører den med jevne mellomrom for å teste at den fungerer og gjør det den skal. Du skriver mer, du kjører den igjen. Slik fortsetter du til du er fornøyd og koden skal leveres. Etter det pakker du koden din pent i en arkiv med litt dokumentasjon, laster den opp på en side hvor det skal leveres og venter på tilbakemelding. Høres det kjent ut?

Prosessen er vel ikke så langt unna det du vil oppleve i arbeidslivet, bare i miniatyrform. Du har noen som bestiller en type funksjonalitet – i dette tilfelle din lærer, men senere en kunde eller produkteier – og du har en eller flere leveranser som skal leveres til den som har bestilt jobben. Fra et funksjonelt perspektiv vil du være sikker på tre ting – at den bestilte funksjonaliteten er med, at den ikke ødelegger for noe annet og at koden vil oppføre seg på samme måte når bestilleren kjører det hos seg.

Den enkle «kode-teste-kode»-metoden fungerer fint for små oppgaver, men hva ville du gjort hvis du skulle jobbe på et stort prosjekt hvor flere jobber på forskjellige deler av koden? Hvordan kan du sjekke at koden din fortsatt fungerer når du har gjort dine endringer? Hvordan kan du være sikker på at dine endringer ikke har ødelagt andres kode?

Og, hvordan kan du sjekke at koden som fungerer på din maskin fortsatt fungerer når du leverer den fra deg?

Velkommen til min arbeidshverdag. Jeg jobber ofte med store datasystemer som består av mange hundre tusener kodelinjer og med flere titalls utviklere som jobber med forskjellige deler av den koden. I tillegg til å være teknisk prosjektleder med overordnet ansvar for blant annet applikasjonsarkitektur, bygg, og miljøer den kjører på, har jeg samtidig hatt rollen som leveranseansvarlig. Sistnevnte har ansvaret med å til slutt pakke all koden og levere den til kunden. Ved hver leveranse må man passe på at alle biter er med, at de fungerer som de skal og at mottakeren av pakken vil kunne installere det på sitt system uten noen overraskelser.

Automatiser

En prosess med å bygge, deploye og levere et system består ofte av flere steg og de kan som regel automatiseres. Det er mange årsaker til at man ønsker automatisering. Den ene årsaken er at det skal være enklere for deg og alle andre å bygge systemet – det korter ned tiden det tar å gjøre det, ergo å teste en endring du har gjort i koden. Den andre årsaken er at det kan gjøre det lettere for andre å ta over eller hjelpe til på et prosjekt uten å måtte sette seg inn i hele byggeprosessen. Det vil også gjøre det lettere å bygge med forskjellige konfigurasjoner dersom man ønsker det. I tillegg til alt dette, vil det også eliminere den menneskelige faktoren i hele prosessen. Vi mennesker kan gjøre feil, og ved å automatisere manuelt arbeid fjerner vi en kilde for en del feil.

Automatisering kan oppnås ved hjelp av forskjellige verktøy. Alt fra enkle make- og shell-skript til ganske avanserte byggeverktøy som Apache Maven og Gradle kan hjelpe deg, litt avhengig av oppgaven som skal gjøres. Oftest blir det en kombinasjon av noen ovennevnte verktøy. Disse kan hjelpe deg både med generell automatisering av bygge- og deploy-prosessen, og med automatisering av punktene under.

Automatiske tester og sjekk av kodekvalitet

Når koden din er skrevet og byggingen av den er et knappetrykk eller en skriptkjøring unna, kan du begynne å se på en annen viktig del av automatisering – kjøring av tester og sjekk av kodekvalitet. De automatiske testene kan være både på lavnivå – enhetstester – og på funksjonell nivå. Enhetstester sjekker at metodene dine fungerer som de skal, for eksempel å returnere riktig svar, gitt noen inputparametre. De funksjonelle testene vil teste systemet som en svart boks. Her vil du få svar om systemet ditt fortsatt kan utføre et sett med bestemte oppgaver. Det finnes også integrasjonstester som kan og bør automatiseres, og disse brukes for å sjekke at systemet snakker med og til andre systemer på den måten det var tiltenkt.

Uansett type tester kan disse, dersom de feiler, fortelle deg om at noe dramatisk har skjedd i ditt system og om at systemet har sluttet å oppføre seg som forventet. Det vil også gi deg en mulighet til å oppdage potensielle feil mye tidligere i utviklingsprosessen.

En annen måte å oppdage skjulte problemer er å kjøre statisk kodeanalyse som kan oppdage kjente mønstre for feil, sikkerhetssvakheter, uvaner eller unødvendig kompleksitet.

Miljøer

Når du utvikler et system bør du vite hvilket miljø og oppsett dette vil kjøre på når systemet går live, dvs. legges ut i produksjonsmiljøet. Denne informasjonen kan du bruke til å sette opp tilsvarende miljøer for utvikling, og spesielt med tanke på testing. Dette er nødvendig for å være i stand til å oppdage feil som vil kunne oppstå kun med et bestemt oppsett, eller spesifikk hardware. Når disse miljøene er satt opp kan du automatisere utrulling av din kode til disse miljøene. Dette kan være veldig praktisk, og spare deg for mye tid. Tenk at du sjekker inn en endring (for du bruker vel et versjonskontrollsystem, ikke sant?), og vips, er det ute på et passende miljø, klar til å testes eller demonstreres.

Versjoner

Versjonering av koden vil gjøre at du lett kan svare på to viktige spørsmål:

• Hvilken versjon av koden kjører her?
• Hvilken funksjonalitet er en del av bestemt versjon?

Begge disse spørsmålene er noe du kommer til å spørre deg selv og vil bli spurt om fra andre. Svarene på disse vil hjelpe deg når du skal jobbe med feil som blir fikset eller oppdaget, eller ny funksjonalitet som blir rullet ut. Dersom du lager et større produkt, vil du også få bruk for disse når du skal lage Release Notes for den nyeste versjonen. Versjoner vil også hjelpe deg å holde styr på en oppdatert dokumentasjon for ditt system.

Veien videre

Automatisering av bygg og deploy er et veldig stort tema. Punktene som jeg nevner her kan brukes som et springbrett, en slags sjekkliste for et bedre system. Du trenger ikke gjøre alt på en gang, eller gå i dybden på alle punkter, men start et sted og jobb deg videre mot full automatisering.

Disse punktene – og litt mer – er en del av en kontinuerlig leveranseprosess som skal bidra til at det kun vil ta noen minutter fra du sjekker inn en endring til det er ute i produksjon. Så langt trenger du ikke å gå i første omgang, men det kan jo være noe å strekke seg etter? Men det disse punktene kan gjøre med en gang er å forenkle din hverdag så vel som hele prosessen rundt håndtering av et system, slik at du kan bruke mer tid på det du liker best, nemlig programmering!

Denne artikkelen ble publisert i magasinet INDEX (2. utgave, 2016), Institutt for Informatikk, Universitetet i Oslo.