Project Sunstone. Et hovedprosjekt i data ved Høgskolen i Oslo

Transkript

1 Project Sunstone Et hovedprosjekt i data ved Høgskolen i Oslo Martin Haukeli Jostein Haukeli Marit Olsen

2 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKTETS TITTEL Project Sunstone PROSJEKTDELTAKERE Martin Haukeli (s147773) Jostein Haukeli (s147811) Marit Olsen (s140751) HOVEDPROSJEKT DATO 31/ ANTALL SIDER / BILAG 81 PROSJEKT NR TILGJENGELIGHET Papir og elektronisk INTERN VEILEDER Frode Eika Sandnes Telefon: Telefaks: OPPDRAGSGIVER Høgskolen i Oslo KONTAKTPERSON Frode Eika Sandnes SAMMENDRAG Project Sunstone Prosjektet har gått ut på å utvikle en photobrowser som kan bruke bildeklassifisering til å sortere bilder på en meningsfull måte. Bildeklassifikatorene kan være selvlagde eller stamme fra en tredjepart. En bildeklassifikator kan for eksempel utnytte metainformasjonen i en bildefil og finne ut om bildet er tatt om dagen eller natten. Brukeren kan så velge alternativet Dag i photobrowseren, som vil vise en samling av bilder som er tatt om dagen. Dette ekspanderbare rammeverket er utviklet med et sterkt fokus på fremtidig videreutvikling. Photobrowser Bildeklassifisering Exif-metadata Hovedprosjektrapport for Project Sunstone 2

3 Forord Denne prosjektrapporten inneholder dokumentasjonen for vårt hovedprosjekt «Project Sunstone», som er avlutningen på vårt treårige bachelorstudium i ingeniørfag retning data, ved Høgskolen i Oslo, våren Systemet er utviklet av Martin Haukeli, Jostein Haukeli og Marit Olsen. Dokumentasjonen består av prosessdokumentasjon, produktdokumentasjon, kravspesifikasjon, testrapport og brukermanual. Prosessdokumentasjonen beskriver vår arbeidsprosess fra ide til ferdig produkt. Her inkluderes blant annet informasjon om hvordan gruppen oppsto, arbeidsgiver, veileder og hva vi tenker om resultatet. Produktdokumentasjonen beskriver systemet i detalj. Blant annet datastrukturen og funksjonalitet. Kravspesifikasjonen beskriver hvilke krav arbeidsgiver har stilt til systemet vi har utviklet. I testrapporten finnes informasjon om tester som er utført, og eventuelle endringer som har blitt gjort som følge av disse. Brukermanualen er en god bruksanvisning for sluttbruker for å forstå og prøve ut systemet. Gruppen ønsker at systemet skal være såpass lett forståelig at denne manualen stort sett ikke er nødvendig, men være enkel å slå opp i om ønskelig. Hvert av disse dokumentene kan leses uavhengig av hverandre. Vi anbefaler at prosessdokumentasjonen leses først slik at man får en forståelse av systemets bakgrunn. Gruppen ønsker å takke vår veileder for prosjektet, professor Frode Eika Sandnes ved Høgskolen i Oslo for all uvurderlig hjelp og støtte underveis. Dette dokumentet er beregnet for arbeidsgiver, sensor, veileder og andre som er interessert i prosjektet. Brukermanualen er også beregnet for sluttbruker. Rapporten er optimalisert for papir. Hjemmesiden for prosjektet ligger på Hovedprosjektrapport for Project Sunstone 3

4 Innholdsfortegnelse HOVEDPROSJEKT... 2 FORORD... 3 INNHOLDSFORTEGNELSE... 4 PROSESSDOKUMENTASJON FOR PROJECT SUNSTONE... 5 PRODUKTDOKUMENTASJON FOR PROJECT SUNSTONE KRAVSPESIFIKASJON FOR PROJECT SUNSTONE TESTDOKUMENTASJON FOR PROJECT SUNSTONE BRUKERMANUAL FOR PROJECT SUNSTONE VEDLEGG 1 GANTT-DIAGRAM VERSJON VEDLEGG 2 GANTT-DIAGRAM VERSJON VEDLEGG 3 PROSJEKTSKISSE VEDLEGG 4 FORPROSJEKTRAPPORT VEDLEGG 5 JAVA CODE STYLE VEDLEGG 6 EXIF VEDLEGG 7 KLASSIFIKATORUTVIKLING VEDLEGG 8 ORDFORKLARINGER Hovedprosjektrapport for Project Sunstone 4

5 Prosessdokumentasjon for Project Sunstone Et hovedprosjekt i data ved Høgskolen i Oslo, våren 2010 Martin Haukeli Jostein Haukeli Marit Olsen Hovedprosjektrapport for Project Sunstone 5

6 1.1 Forord Dette er en prosessrapport som beskriver arbeidsprosessen fra ide til ferdig produkt. Dette dokumentet er beregnet for sensor, oppdragsgiver, veileder og andre som kan være interesserte i vårt arbeid. Gruppen fant frem til oppgaven gjennom hovedprosjektsiden til HiO. Her var det uttrykt et ønske om at en studentgruppe kunne utvikle et utvidbart rammeverk for photobrowsing. Ettersom det var enighet i gruppen om at dette virket som en interessant oppgave, valgte vi å ta kontakt med Frode Eika Sandnes som hadde lagt ut oppgaven. Vi hadde vårt første møte med oppdragsgiver kort tid etter, og vi ble raskt engasjert i problemstillingen etter hvert som vi ble mer kjent med oppdragets detaljer. På grunn av vårt engasjement for denne oppgaven, samt måten den dekket våre ønsker om arbeidsmetode og bruk av Java, endte vi opp med å ta dette oppdraget. Ved ingeniørutdanningen på HIO er det ved en tidligere anledning utviklet noen algoritmer som kan sortere bilder inn i meningsfylte kategorier. For og enkelt kunne benytte seg av algoritmene ble det uttrykt et behov for å designe og implementere en photobrowser som kunne bruke disse. Dette var grunnlaget for at dette prosjektet ble iverksatt. Etter endt prosjektperiode var målet å ha utviklet et rammeverk som enkelt kunne videreutvikles etter behov. Eksempler på noen slike utvidelser kan være inkorporering av nye klassifikatorer, visninger i brukergrensesnittet eller metoder for uthenting av metadata. Hovedprosjektrapport for Project Sunstone 6

7 Innholdsfortegnelse PROSESS- DOKUMENTASJON FOR PROJECT SUNSTONE FORORD... 5 INNHOLDSFORTEGNELSE INNLEDNING Prosjektgruppen Oppdragsgiver Dagens situasjon Mål Rammebetingelser Prosjektets navn PLANLEGGING OG METODE Innledende arbeid Fremdriftsplan Prosjektdagbok Veiledning Verktøy Kompetanseutvikling Arbeid Tilbakemelding fra oppdragsgiver OM UTVIKLINGSPROSESSEN Valg Utviklingsfaser Utfordringer og problemer Forhold til oppdragsgiver KRAVSPESIFIKASJONEN OG DENS ROLLE Rolle Endringer OM RESULTATET AVSLUTNING Eget utbytte Hva kunne blitt gjort annerledes Fremtiden Hovedprosjektrapport for Project Sunstone 7

8 1.3 Innledning Prosjektgruppen Ved prosjektets oppstart var alle gruppens medlemmer godt kjent fra tidligere prosjektoppgaver ved Høgskolen i Oslo (HiO). Av den grunn mener vi at vi var kjent med de enkelte medlemmenes arbeidsmetoder og preferanser, noe som har gitt oss et godt grunnlag for planlegging og fordeling av arbeidsoppgaver. Alle på gruppen studerer ved dataingeniørutdanningen på HiO. Det var ingen av oss som hadde noen gode kontakter å benytte oss av for å finne frem til et hovedprosjekt som dekket våre ønsker. Av denne grunn startet vi med å kontakte et par aktuelle bedrifter per e-post, og se igjennom prosjektforslagene som var blitt offentliggjort på HiO sin internettside for hovedprosjekter. Vi ønsket først og fremst å få en ekstern oppdragsgiver på grunn av mulighetene dette ville kunne gi oss til å danne et større kontaktnett. På denne måten ville vi kunne bedre mulighetene våre for å finne en attraktiv jobb etter endt utdanning. Til tross for dette endte vi opp med en intern oppdragsgiver hos HiO, noe som i ettertid har vist seg å ha fungert utmerket for vår prosjektgruppe. Vi har dessuten ingen tvil om at erfaring fra dette prosjektet vil ha en positiv og verdifull innvirking i fremtidige jobbsammenhenger Oppdragsgiver Vår oppdragsgiver er Høgskolen i Oslo ved Frode Eika Sandnes. Vi har hatt en svært god dialog med oppdragsgiver gjennom hele prosjekttiden. Dette har vært en viktig forutsetning for vårt engasjement for oppgaven, og har hatt en betydelig innvirkning på det endelige resultatet Dagens situasjon I dag er digitalkameraer blitt en svært vanlig eiendel blant personer over hele verden, samtidig som masseprodusering og stadig lavere kostnader gjør det mer lukrativt å gå til anskaffelse av et digitalkamera. Det blir tatt bilder i alle situasjoner og under alle omstendigheter. Disse bildene kan bli samlet på minnekort, eksterne harddisker, overført til datamaskiner eller eventuelt skrevet ut til papir. Over en tidsperiode kan dette føre til at store bildesamlinger blir lagret, som igjen kan føre til at fotografen får dårligere oversikt over samlingen og det dermed kan bli vanskeligere å finne frem til et utvalg bilder i denne. I denne situasjonen kan det være svært praktisk å ha en photobrowser som kan hjelpe brukeren med å navigere frem til et ønsket utvalg bilder. Det finnes mange forskjellige typer photobrowsere som er tilgjengelige i De aller fleste av disse gir brukeren mulighet til å sortere bilder etter informasjon som for eksempel dato, filnavn og størrelse på bildet. Ett eksempel på dette er Google Picasa som blant annet sorterer etter disse tre egenskapene. Vi har ingen kjennskap til photobrowsere som på en enkel måte kan sortere bilder etter hvor i verden de er tatt, om det er dag eller natt, eller egendefinerte kategorier. Det finnes digitalkameraer som bruker GPS (Global Positioning System) til å lagre informasjon om hvor bildene er tatt, men dette er ikke vanlig utstyr på de fleste kameraer. De kameraene som er utstyrt med GPS, bruker også som oftest lang tid for å låse seg til Hovedprosjektrapport for Project Sunstone 8

9 satellittsignalene og er dermed ikke så praktisk i bruk. Dette gjelder spesielt der en ikke har et stillestående motiv og dermed ikke har tid til å vente på at GPS en skal låses til signalet. De fleste digitalkameraer som produseres idag lagrer forøvrig metainformasjon som gjør det raskt og enkelt å finne mye informasjon om bildet. Eksempler på slik informasjon er innstillinger som ble brukt på tidspunktet da bildet ble tatt. Denne informasjonen blir lagret i et Exif-format (Exchangeable image file format). Slik informasjon kan vise seg svært nyttige i ettertid, ettersom den kan vise for eksempel kameramodell, dato og tid, eksponeringstid, brennvidde og mye mer. Ut fra denne informasjonen, eller ved å analysere bildets innhold, har vår oppdragsgiver laget en del algoritmer som kan implementeres i form av «klassifikatorer». Disse har mulighet til å bruke enten metadata, bildets innhold eller begge til for eksempel å finne ut omtrent hvor i verden bildene er tatt, om det er natt eller dag, eller om bildet er tatt ute eller inne. Dette gjør at man enklere kan finne frem i store bildesamlinger som gjerne er tatt på et mye tidligere tidspunkt Mål Målet med oppgaven var å designe et utvidbart rammeverk for en photobrowser som kan sortere bilder i meningsfylte kategorier. Dette skulle skje basert på algoritmer som er utviklet ved ingeniørutdanningen ved HiO. Det skulle på en enkel måte være mulig å installere nye klassifikatorer i systemet uten at det må gjøres endringer i brukergrensesnittet eller andre steder i programkoden. Denne photobrowseren skal gjøre det lettere for brukere å finne frem til ønskede bilder i store samlinger. Systemet vi skulle designe hadde noen spesielle mål, som blant annet at både brukergrensesnittet, koden og klassifikatorene skulle være utvidbare. Effektivitet i forhold til tid har vært et annet mål som vi har jobbet mye med. Eksempler på tidkrevende prosesser der dette har vært viktig er koden der bildene blir skannet, og metoden for generering av hash av bilder. Alle kravene til systemet kan leses om i kravspesifikasjonen som blir omhandlet i kapittel Rammebetingelser Dette har vært et relativt åpent prosjekt, hvor vi har hatt gode muligheter til å vurdere, samt velge blant verktøy og teknikker vi har ønsket å benytte oss av. I forbindelse med noe av den første kontakten vi hadde med oppdragsgiver kom vi inn på programmeringsspråket. Det som allerede var skrevet av kode i forbindelse med at en slik photobrowser skulle implementeres benyttet seg av Java som programmeringsspråk. Oppdragsgiver nevnte at det kunne være mulig og bruke et annet programmeringsspråk hvis det var ønskelig, noe det ikke var fra vår side. Dette førte til at vi da måtte forholde oss til at alt skulle implementeres i Java. Noen av valgene vi har gjort har ført til begrensninger i systemet. Ett eksempel på dette er vårt valg om å bruke en Apache Derby database. Som følge av dette har vi vært nødt til å bruke SQL syntaks som Derby støtter Prosjektets navn Prosjektets navn er Project Sunstone. Dette er et navn vår oppdragsgiver har tenkt på og som vi syntes hørtes bra ut. Bakgrunnen for denne tanken gikk tilbake til vikingtiden og Hovedprosjektrapport for Project Sunstone 9

10 deres myteomspunnende måte å navigere ved hjelp av en sunstone. Dette kan leses mer om på denne siden Planlegging og metode Innledende arbeid Vi ble oppmerksomme på dette prosjektet via HiO sin nettside for prosjektforslag. Vi hadde et møte med Frode E. Sandnes for å få mer informasjon om prosjektet. Her stilte vi en del spørsmål rundt muligheter for å gjøre prosjektet til et mer programmeringstungt prosjekt, ettersom den opprinnelige oppgaveformuleringen uttrykte et noe sterkt fokus på utforming av brukergrensesnittet. Dette skulle vise seg og ikke være noe problem for oppdragsgiver, og vi gikk fra møtet med et svært positivt inntrykk av dette prosjektet. Etter litt diskusjon innad i gruppen valgte vi å ta oppdraget som vårt hovedprosjekt. I løpet av oppstartsprosessen ble det utviklet en prosjektskisse og en forprosjektrapport. Disse ligger som vedlegg til prosjektrapporten Fremdriftsplan Vårt viktigste verktøy for planlegging av arbeidsflyten igjennom prosjekttiden har vært Gantt-diagrammet vi valgte å utvikle tidlig i prosjektet. Ved å ta oss tid til å anslå hvor lang tid vi vil bruke på de viktigste applikasjonsdelene, har vi kunnet følge dette diagrammet som en overordnet arbeidsplan. Gantt diagrammer ligger om vedlegg 1 og 2. Endringer Vi startet med å lage et Gantt-diagram i Microsoft Excel, men ved en senere anledning fant vi ut at vi ønsket en enklere måte å oppdatere diagrammet på. Dermed bestemte vi oss for å finne et program som egnet seg bedre til tegning av Gantt-diagrammer. Etter å ha brukt litt tid på leting etter et godt alternativ, endte vi opp med å bruke programmet GanttProject, som hadde alle funksjoner vi ønsket å benytte. Disse diagrammene ligger med som vedlegg i denne rapporten. Vi har kun følt behov for å oppdatere Gantt-diagrammet ved en anledning. Disse endringene ble gjort fordi vi på daværende tidspunkt innså at vi trengte lengre tid på flere deler av prosjektet, og at vi ønsket å jobbe med flere av disse delene samtidig. I den første versjonen av Gantt-diagrammet var det beregnet at klassifikatorbasisen skulle være ferdig etter kun 21 dager. Vi fant fort ut at dette ville være svært upraktisk, ettersom klassifikatorbasisen var avhengig av at andre deler av rammeverket ble utviklet samtidig. Ettersom det ikke var viktig å fullføre klassifikatorbasisen på dette stadiet, valgte vi å planlegge en utvikling av denne parallelt med implementeringen av rammeverket. Noe som i ettertid har sett ut til å fungere utmerket. Milepælen som beskrev utredning av datastrukturen ble også endret fra første til andre versjon av diagrammet. Dette ble gjort fordi vi følte vi ikke hadde nok detaljer klare omkring denne milepælen på daværende tidspunkt. På denne måten kunne vi unngå å sette uønskede begrensninger på datastrukturen på et tidlig stadium. Isteden bestemte vi oss for å bruke mars måned på å fullføre denne implementasjonen. Hovedprosjektrapport for Project Sunstone 10

11 Implementeringen av API/rammeverket endret vi slik at vi startet tidligere med dette enn planlagt i versjon en. Dette ble gjort fordi vi ønsket å komme raskt igang med implementering av arkitekturen vi designet tidligere. GUI delen var i første versjon kun satt opp fra slutten av mars til midten av mai måned. I versjon to delte vi opp denne slik at vi skisserte GUI i løpet av februar måned, og implementerte dette fra slutten av mars til midten av mai. På denne måten fikk vi en bedre oversikt over hvilke løsninger som ville være mest fornuftige, både i forhold til komponenter som skulle kommunisere med GUI, og de enkelte delene av brukergrensesnittet. Vi har kun beregnet en til to dager til å lage et selvinstalleringsprogram. Dette er et avvik fra Gantt-diagrammet som beskriver at denne prosessen vil ta opp til en uke. Grunnen til dette er at vi ønsker å benytte tiden helt frem til innlevering, og at vi allerede har gjort en del undersøkelse og dermed har klart for oss hvordan vi ønsker å lage installasjonsprogrammet. Test cases har vi endret fra tre uker til 4 uker, for å gi bedre rom for gjennomføring av dette. En grunn til dette var vårt ønske om å utvide testcase med fler bilder, og vurdere om disse var tilfredsstillende. Tiden som var satt av til testklassifikatorer ble økt fra omtrent en og en halv måned til rundt to måneder og en uke. Dette gjorde vi for å kunne utvikle disse parallelt med andre deler av rammeverket. Dette har gjort det lettere for oss å se hvordan det er å utvikle en klassifikator. I første versjon har vi skrevet innlevering som en egen milepæl, denne har vi valgt å fjerne helt fra andre versjon, ettersom dette er noe vi har jobbet med litt underveis i hele prosjektet og mye på slutten av prosjektperioden. Gjennomføring I all hovedsak har overholdt milepælene i det seneste gantt-diagrammet. Mot slutten av prosjektperioden feilberegnet vi tiden litt. Her burde vi satt fristen for å få ferdig programmet en del tidligere enn det vi gjorde, slik at vi kunne hatt mer tid til å konsentrere oss om dokumentasjonsskrivingen. Annet en dette føler vi at planlegging av arbeidet har gitt tilfredsstillende resultater Prosjektdagbok Vi har underveis i prosjektet ført en prosjektdagbok. Dette har vi gjort for å huske viktige hendelser som har skjedd underveis i prosjektperioden. Denne dagboken har hjulpet oss mye på slutten av prosjektet når prosjektrapporten skulle ferdigskrives. Det har vært en stor fordel å ha tilgang til notater og stikkord om hva som har skjedd underveis, slik at viktige detaljer ikke blir glemt like enkelt. Måten vi har valgt å gjøre dette på er å opprette en passordbeskyttet hjemmeside med en WordPress blogg for prosjektets medlemmer. Her har alle på gruppen hatt muligheter til å legge inn og modifisere notater på en ryddig måte ved hjelp av datoer og klokkeslett. Hovedprosjektrapport for Project Sunstone 11

12 1.4.4 Veiledning Gruppen fikk tildelt Frode Eika Sandnes som veileder under prosjektet. Siden han også er vår kontaktperson hos oppdragsgiver har vi hatt mye kontakt underveis i prosjektet. Spesielt i oppstarten av prosjektet fikk vi mange gode råd som har hjulpet oss med å komme i gang. Veileder har også vært lett tilgjengelig og har kunnet svare på spørsmål fortløpende der dette har vært nødvendig. På slutten av prosjektperioden har vi fått mange gode råd for hvordan dokumentasjonen bør utformes. Vi har hatt ukentlige møter hvor F. Sandnes har fungerte både som veileder fra skolen og kontaktperson fra oppdragsgiver samtidig. Dette har medført at vi har hatt mulighet til å stille spørsmål både angående systemet vi utviklet og prosessen med prosjektet på et og samme møte. Dette har vært en effektiv måte å jobbe på som har ført til raskere svar på eventuelle spørsmål vi har hatt Verktøy Gruppen har jobbet på forskjellige operativsystem og har brukt både gratis og betalte programvarer. En kort oversikt over verktøy vi har brukt underveis i prosjektet følger under. Apache Derby Database ( Apache Derby er en åpen kildekode relasjons database som er implementert i Java. Den er tilgjengelig under Apache License, Version 2.0. Derby kan implementeres som en innebygd database i et Java program. Eclipse har også plugins som er enkle å installere for Derby databasen. Adobe Photoshop ( Dette er et bilderedigeringsprogram hvor det blant annet er mulig å redigere og finjustere bilder. Brukt til å lage skisser og redigere bilder i sluttdokumentasjonen. Drew Noakes metadata-extractor ( Metadata-Extractor er et bibliotek for uthenting av Exif metadata fra JPEG bilder. Kildekoden er skrevet i Java og frigitt til Public Domain, som vil si at hvem som helst kan bruke, modifisere og redistribuere kildekoden etter behov eller ønske. Eclipse ( Eclipse Galileo er et utviklingsverktøy for å utvikle programvare. Galileo er siste versjon av programmet. Dette programmet hadde vi brukt tidligere i utdanninger og var dermed kjent med mye av dets muligheter. Fast MD5 ( Et åpent kildekode bibliotek skrevet i Java under lisensen GNU LGPL versjon 2.1, og tilbyr en enkel og svært rask implementering av MD5 hashfunksjon blant annet for bruk til hashing av filer. GanttProject ( GanttProject er et åpen kilde prosjektstyringsverktøy hvor en blant annet kan lage ganttdiagram som vi var interessert i. GIMP ( Hovedprosjektrapport for Project Sunstone 12

13 Gratis bilderedigeringsprogram hvor det blant annet er mulig å redigere og finjustere bilder. Brukt til å lage skisser og redigere bilder i sluttdokumentasjonen. Google Picasa ( Gratis fotoalbum fra Google. Har også web-album hvor bilder kan lastes opp på nett. Java SE (Standard Edition) 6 ( Dette var den siste utgitte versjonen av programmeringsspråket Java når utviklingen av dette systemet pågikk. Microsoft Office ( Kontorpakke som inneholder blant annet Excel og Word. Vi har brukt regneark til å lage første versjon av gantt-diagrammet vårt. Word har blitt brukt til dokumentasjon underveis og til sluttdokumentasjonen. Open Office ( Dette er en fri kontorpakke som inneholder blant annet Calc og Writer som har vært aktuelle i vårt prosjekt. Windows Live Messenger ( Kommunikasjonsprogram for å kommunisere via internett. Dette har blitt brukt til å diskutere problemer underveis, avtale møter og annen kommunikasjon som har vært prosjektrelatert. WordPress ( Gratis blogg og publiseringsplattform. Kan blant annet brukes til å publisere dokumenter Kompetanseutvikling For å kunne benytte oss av Derby databasen ble vi nødt til å sette oss inn i SQL syntaksen som blir brukt av denne. Dette medførte ingen problemer for oss ettersom vi allerede hadde erfaring med både databaser og SQL syntaks ved prosjektets oppstart. Hvordan denne databasen må opprettes og hvordan drivere lastes måtte også læres. Ettersom uthenting og bruk av Exif informasjon har en helt sentral rolle i vårt rammeverk, har vi måtte lese oss til svært mye informasjon om hvordan de ulike informasjonsfeltene fungerer, hva styrker og svakheter ved Exif er, og hvordan vi kan benytte oss av denne informasjonen i vår applikasjon. Her har vi blant annet benyttet oss av dokumenter som beskriver Exif spesifikasjonen for versjon 2.1 og 2.2 med alle detaljer. Disse dokumentene er publisert av Japan Electronics and Information Technology Industries Association, som forøvrig er organisasjonen som utviklet Exif formatet. Link til dette dokumentet: For å kunne bruke metadata-extracor biblioteket på en god måte har vi benyttet oss av javadoc samt eksempelkode som viser hvordan en kan benytte seg av dette biblioteket. Denne eksempelkoden er tilgjengelig på kildekodens hjemmeside: Hovedprosjektrapport for Project Sunstone 13

14 1.4.7 Arbeid Gruppen har for det meste jobbet hjemmefra, med god kommunikasjon over Live Messenger og e-post. Vi har hatt møter minimum en gang per uke der det har vært rom for diskusjoner og deling av tanker omkring viktige beslutninger. Vi har også brukt disse møtene til gjennomgang av arbeidet som er blitt gjort siden sist. På denne måten har vi sørget for at både gruppemedlemmene og oppdragsgiver har kunnet danne seg et godt oversiktsbilde av prosjektets fremgang. Fordeling av oppgaver er hovedsaklig blitt avtalt under møtene. Der det har oppstått nevneverdige problemer, har vi tatt kontakt med hverandre per e-post eller Live Messenger for å løse disse på en rask og enkel måte Tilbakemelding fra oppdragsgiver Vi har hatt jevnlig kontakt med oppdragsgiver underveis i hele prosjekttiden. Oppdragsgiver har også vært vår veileder gjennom hele prosjektperioden. Verdifull tilbakemelding fra oppdragsgiver har for eksempel vært respons på vår implementering av de ulike delene av rammeverket, spesielt under planleggingen og utviklingen av disse. På denne måten har vi hele tiden kunnet sørge for at programmet oppfyller de kravene som oppdragsgiver har uttrykt. Dermed har vi enklere kunne jobbe mot et resultat som tilsvarer oppdragsgivers beskrivelse. 1.5 Om utviklingsprosessen Valg Vi har vært nødt til å foreta en del viktige valg i løpet av prosjektet. Disse blir nærmere beskrevet under. Utviklingsverktøy Vi valgte å bruke Eclipse som vi er kjent med gjennom utdanningen vår. Dette var enklere enn å sette oss inn i ett nytt utviklingsprogram. Datastruktur Som vist i Gantt-diagrammet, brukte vi en del tid til å finne ut hva slags datastruktur som kunne passe vårt prosjekt. Vi har spesielt vurdert Set og forskjellige listetyper, men disse datatypene har ikke funksjonalitet for å trekke ut tilhørende verdier for en gitt nøkkelverdi. Noe som gjør disse uegnede til å identifisere verdier. Derfor endte vi opp med å bruke HashMap hvor verdier legges inn med en nøkkel og LinkedList der dette passet. Database I begynnelsen av prosjektet hadde oppdragsgiver uttrykt et ønske om en lagringsmetode som ikke implementerte en database. Etter hvert som vi undersøkte de ulike mulighetene og diskuterte disse med oppdragsgiver, ble vi enige om at en implementering av en enkel database kunne være ønskelig. Dermed begynte vi å undersøke om det fantes en god implementasjonsmulighet som passet for vårt prosjekt. Vi valgte å bruke Apache Derby database siden denne enkelt kunne integreres i vår applikasjon, er av liten størrelse og kan installeres i Eclipse ved hjelp av plugins. Den er basert på Java, JDBC og SQL standarder. Brukere av den ferdige applikasjonen vil i liten grad ha noe med databasen å gjøre. Hovedprosjektrapport for Project Sunstone 14

15 Brukergrensesnitt Siden vi valgte å utvikle brukergrensesnittet på en slik måte at det enkelt kunne byttes ut eller videreutvikles på et senere tidspunkt, valgte vi å dele inn de mest sentrale GUI komponentene i tre mindre visninger. Disse ble implementert med tanke på brukerens forventninger om hvordan en slik løsning ville fungere. Ved å designe brukergrensesnittet på denne måten har vi unnlatt å sette store begrensninger på utvidelsesmuligheter. For eksempel vil en kunne implementere nye visninger for bruk i rammeverket Utviklingsfaser I oppstarten av prosjektet valgte vi å arbeide etter UP-light metoden som er en lettvektsversjon av Unified Process. Vi hadde med både XP (extreme Programming) og Scrum i vår vurdering av utviklingsmetode. I XP er et av hovedpunktene i utviklingen parprogrammering. Denne måten å programmere på består i at to og to personer programmerer sammen. Vi har prøvd ut denne måten i andre fag på skolen og ville ikke bruke dette i prosjektet. Det kunne også bydd på problemer at vi var tre personer på gruppen. Scrum har korte daglige stående møter som et av sine hovedpunkter, og siden vi kom til å jobbe en god del hjemmefra ville dette by på problemer slik at vi ikke valgte denne metoden. Vanlig UP har mange artefakter som må være med, mens i lettvektsversjonen er det ikke behov for å lage artefakter kun fordi det skal gjøres. Her lages det isteden artefakter etter behov. Arbeidet foregår iterativt og består av ulike faser. Disse fasene er idéfase, utdypningsfase, konstruksjonsfase og overgangsfase. Vi har ikke fulgt denne utviklingsmetoden nøyaktig, men har heller brukt den som en veiledning underveis. I følge UP-light skal blant annet hver iterasjon i konstruksjonsfasen føre til ferdig dokumentert, testet og implementert produkt. Vi har kodet, skrevet kommentarer og testet underveis at det vi har gjort kodet fungerer, men har ikke alltid hatt et ferdig produkt etter hver iterasjon. Overgangsfasen har vi hatt helt mot slutten av prosjektperioden. Da drev vi med litt optimalisering av kode før systemet ble overlatt til oppdragsgiver, i denne fasen skrev vi også det meste av prosjektrapporten. Oppstart (Idéfase) I oppstarten hadde vi svært få detaljer klare, og måtte bruke mye tid til å stille spørsmål og undersøke forskjellige muligheter. Dette var viktig for at vi skulle få et godt utbytte av prosjektarbeidet, og at oppdragsgiver skulle få levert et godt resultat. Vi forsøkte å danne oss et godt bilde av hvordan systemet skulle bygges opp etter hvert som informasjonen vi ønsket kom på plass. I Denne fasen begynte arbeidet med kravspesifikasjonen. Ved prosjektets oppstart var det viktig for oss å undersøke de mange mulighetene for implementering av systemet. Dette fordi vi ønsket et godt strukturert system, som enkelt skulle kunne videreutvikles på et senere tidspunkt. Her endte vi opp med å designe et forenklet klassediagram som fulgte arkitekturen til en Model View Controller. På denne måten fikk vi en god oversikt over hvordan vi ønsket at programmet skulle henge sammen allerede fra starten, samtidig som vi ikke behøvde å bruke mye tid på å fokusere på detaljer. Hovedprosjektrapport for Project Sunstone 15

16 En videreutvikling av dette diagrammet vises i produktdokumentasjonens figur 2.1 (kapittel 2.7). Planlegging/Valg (Utdypningsfase) De aller fleste valgene vi har gjort har vært relatert til oppbyggingen av systemet, hvordan vi skulle lagre informasjonen vi hadde behov for, og hvilke biblioteker med kildekode vi har ønsket eller hatt behov for å bruke. Kravspesifikasjonen ble utdypet i denne fasen. Vi skisserte også hvordan vi ønsket at brukergrensesnittet skulle se ut. Her brukte vi både penn og papir og mer avansert bilderedigeringsprogram slik som figur 1.1 og figur 1.2 viser eksempler på. Figur 1.1 GUI skisse Hovedprosjektrapport for Project Sunstone 16

17 Figur 1.2 Grovt skissert GUI Utvikling (Konstruksjonsfase) Siden vi er tre personer på gruppen og vi alle har ulik kodestil bydde dette på problemer i begynnelsen. Det ble skrevet uoversiktlig kode og dermed vanskeligere for oss å forstå koden som hadde blitt implementert av de andre på gruppen. På grunn av dette og for å gjøre koden enklere å forstå for eventuelle senere utviklere, har vi skrevet en kodestil. Denne er skrevet på engelsk siden oppdragsgiver har tenkt at dette rammeverket skal være åpen kildekode og dermed kan videreutvikles av andre enn norskspråklige utviklere. Denne kodestilen ligger som vedlegg. Ettersom vi har jobbet med å utvikle programvare, har størsteparten av utviklingsfasen vært brukt på programmering. Under utviklingsfasen har vi dessuten brukt mye tid på undersøkelse av de ulike implementeringsmulighetene, slik at vi har kunnet gjøre gode beslutninger. Dette har vært svært viktig, slik at vi har kunnet ende opp med et produkt som henger sammen på en ønskelig måte. I denne fasen har vi også jobbet med å finne testcases som vi kunne bruke i testingen av systemet og til demonstrering av systemet. De bildene vi har brukt har blitt hentet fra Google Picasas web-album. Lisensen bildene er lagt under er Creative Commons ( Vi har sjekket at disse bildefilene inneholder Exif-informasjon slik at de gir et resultat fra klassifikatorene når de skannes gjennom disse. Testing Vi har gjort en rekke tester underveis i prosjektet for at sikre oss at de mest tidkrevende prosessene i systemet blir utført på en effektiv måte. Disse testene har stort sett foregått ved å implementere forskjellige muligheter, for så å velge ut den som gir det mest ønskelige resultatet. De enkelte delene av rammeverket er også testet underveis ved hjelp av vanlige debuggingsmetoder, slik at vi for eksempel har kunnet vurdere om input og output fra Hovedprosjektrapport for Project Sunstone 17

18 forskjellige metoder er som forventet. Vi har også utført en del testing av programflyt på det ferdige systemet helt mot slutten av prosjekttiden. Dette er for å sørge for at de ulike delene også fungerer sammen på en god måte. En mer detaljert beskrivelse av testing blir gjort rede for i testdokumentasjonen, som vil si del 4. Dokumentasjon Underveis i prosjektet har vi prøvd å skrive ned viktige hendelser i prosjektdagboken slik at det skulle være enklere å skrive sluttdokumentasjonen når den tid kom. Prosessdokumentasjonen startet vi med først siden vi kunne hente en del informasjon fra forprosjektrapporten. Vi har også kunnet skrive ned notater i denne underveis i løpet av utviklingsfasen. Hoveddelen av denne fasen har blitt utført mot slutten av prosjektperioden Utfordringer og problemer MainWindow Vi hadde et ønske om at det i brukergrensesnittet skulle være lettvint for brukeren og flytte, minimere og forstørre de enkelte mindre vinduene. Dette viste seg ikke å være like enkelt å implementere som vi i første omgang trodde. Problemene som oppstod i forbindelse med dette var å få rett størrelse på de mindre vinduene ved forstørring og minimering. Dette problemet løste vi ved å prøve ut forskjellige metoder og velge den beste av disse. Det ble gjort forsøk på å bruke Javas funksjonalitet for interne vinduer, men vi gikk etter hvert over til å benytte oss av vanlige paneler. ClassifierView Ettersom klassifikatorene som skal brukes i rammeverket må kunne utvikles og installeres uten behov for å rekompilere programmet, har vi måtte utvikle en fleksibel metode for visning av disse i brukergrensesnittet. Dette er gjort ved hjelp av en layout-manager som på mange måter er mer avansert en de mest brukte layout-managerne. For å mestre dette problemet har vi i stor grad benyttet oss av Javas veiledningsdokumenter tilgjengelig på Sun sine hjemmesider. Ved hjelp av disse har vi kunnet lære oss hvordan en kan implementere Swing komponenter som bruker denne layout-manageren. Vi er svært fornøyde med denne implementasjonen, ettersom vi mener den er svært plassbesparende, tiltalende og fungerer godt med muligheten vi ønsker å gi brukeren til å endre størrelse på de enkelte komponentene. ThumbnailView Det har vært en utfordring for oss å kunne utvikle en god visning av brukerens bilder til skjermen, ettersom de også skulle ha funksjonalitet som knapper, og kunne modifiseres rakst etter hvert som brukeren foretar valg blant klassifikatorene. Ettersom rammeverket er ment å brukes sammen med store samlinger bilder, har vi også måtte tenke ut implementasjonsmuligheter som ikke sløser med maskinens minne. For å få til dette på en god måte har vi benyttet oss av diskusjonstråder på Sun sine offisielle diskusjonsforum. Ble det stilt spørsmål om hvordan en generell thumbnailvisning kunne implementeres. Dette medførte at vi fikk råd som har hjulpet oss med å tenke ut alternative løsninger som vi kanskje ikke ellers ville ha kommet på. Som følge av dette, fikk vi etter en kort stund tenkt ut en implementasjon som kunne løse de viktigste problemene som oppsto i vår implementasjon av thumbnailvisningen. Dermed Hovedprosjektrapport for Project Sunstone 18

19 kunne vi forbedre skalerbarheten i applikasjonen med en stor margin. Den største samlingen som er testet med thumbnailviewet alene er på bilder, noe som har gått greit uten å måtte allokere mer minne til Javas virtuelle maskin. Denne implementasjonen blir beskrevet i produktrapporten med større fokus på detaljer. Core Klassifikatorer lastes inn dynamisk fra en mappe, her måtte vi slå opp på nettet for å finne ut hvordan man laster inn et objekt fra fil mens programmet kjører og likevel kunne bruke dette objektet som om det var en del av prosjektet. Det var også viktig å kontrollere om det innlastede objektet var av rett type. I Core har vi hatt store utfordringer med å designe en måte å kommunisere mellom alle delene i systemet. Ettersom vi har designet et objektorientert og utvidbart system har vi laget mange deler som må snakke sammen. Dette gjøres gjennom Core. For eksempel spør brukergrensesnittet Core om hvilke bilder som skal vises i grensesnittet og dette finner Core ut av ved å bruke DatabaseWrapperen og klassifikatorene. Core er også det som drar igang programmet ved å laste inn de forskjellige delene av systemet. Rekkefølgen er viktig og det gis også tilbakemelding til brukeren om fremdrift og status. En klassifikator kan være avhengig av å motta verdier den behøver. Dette kan være Exifinformasjon eller informasjon fra andre klassifikatorer. Dermed må alle klassifikatorer som er installert i programmet sorteres på en slik måte at alle verdier fra andre klassifikatorer de er avhengige av å ha, allerede må være lagt inn i systemet. Det har vært en utfordring å oppdage sykler i klassifikator avhengighet. Dette har vi løst som beskrevet i produktdokumentasjonen. Før bilder legges til i datastrukturen hentes metadata fra bildet. Vi valgte å legge denne funksjonaliteten i en wrapper klasse vi kalte ExifWrapper. Dette gjorde vi for at man senere skulle kunne endre på hvordan metadata trekkes ut av bildet. I likhet flyttet vi alt som har med SQL og databasen å gjøre inn i en wrapper klasse vi kalte DatabaseWrapper. Vi gjorde et forsøk på å få brukergrensesnittet til å kunne brukes mens programmet forsatt lagde miniatyrbilder. Men dette hadde en negativ konsekvens. Vi hadde ingen god måte å legge miniatyrbilder inn i brukergrensesnittet etter hvert som disse ble laget. Dermed måtte alle bilder legges inn på nytt for hvert nye miniatyrbilde som ble generert. Derfor gikk vi bort fra dette, men dette vil være en mulig utvidelse i fremtiden. Klassifikatoren Informasjon om bilder fra må gis til klassifikatoren sånn at den kan prosessere disse og gi bildet en verdi. Ettersom det kan være snakk om flere input verdier valgte vi å bruke en generisk datastruktur. Dette betyr at man kan sende nesten hva som helst som input til en klassifikator. Hovedprosjektrapport for Project Sunstone 19

20 En annen utfordring var at vi måtte sende verdier gitt av klassifikatorene til Core for lagring. Her tenkte vi først at den datastrukturen som blir sendt som input til klassifikatoren skulle modifiseres. Dette valgte vi å gå bort fra siden det ville kunne være forvirrende for klassifikatorutvikleren. Derfor valgte vi heller at klassifikatoren har to metoder for skanning; En for skanning av enkelt bilde og en for skanning av flere bilder samtidig. Verdien returneres i form av et objekt, som er en generisk datatype i Java. Klassifikatoren er et API for å utvikle klassifikatorer. Vi har brukt mye tid på å kunne støtte alle klassifikator ideene fra oppdragsgiver og også lage et så generisk som mulig grensesnitt. Derby Database Derby støtter ikke MySQL syntaks som vi har jobbet med tidligere og dette gjorde at mange av metodene i DatabaseWrapperen måtte implementeres annerledes en vi hadde tenkt. Siden vi bestemte oss for å lagre objekter i databasen måtte dette gjøres på en måte vi aldri hadde brukt før og dette skapte litt problemer til å begynne med. En nærmere beskrivelse av hvordan vi har brukt Derby blir gitt i produktdokumentasjonen Forhold til oppdragsgiver Vi har hatt en noe spesielt forhold til vår oppdragsgiver, med tanke på at han også har fungert som vår interne veileder ved Høgskolen i Oslo. Vi har ingen negative tilbakemeldinger på vårt samarbeid i løpet av prosjekttiden. Vi har følt at vi har blitt tatt seriøst, og at vi har hatt gode muligheter for å komme med innspill og spørsmål der vi har ønsket dette. Oppdragsgiver har også vært tilgjengelig per e-post gjennom hele perioden, i tillegg til ukentlige møter på høgskolen. 1.6 Kravspesifikasjonen og dens rolle Kravspesifikasjonen er en egen del av rapporten og kan leses i kapittel Rolle Kravspesifikasjonen har hatt en betydelig innvirkning på arbeidet gjennom hele prosjektet, ettersom den beskriver hvilke funksjoner og muligheter vi har måtte rette oss etter. Kravspesifikasjonen har fungert som en sjekkliste som vi har kunnet bruke underveis, sammen med Gantt-diagrammet for å få oversikt over hvordan prosjektarbeidet ligger an Endringer Kravspesifikasjonen ble ikke fastsatt tidlig i prosjektperioden, ettersom det var nødvendig for gruppen å sette seg godt inn i oppgaven og dens muligheter. Den ble isteden ferdigstilt et stykke ut i prosjektperioden. Et resultat av dette har vært at vi kunne finne en god løsning på en rekke viktige implementasjonsproblemer. Dessuten var det kun et fåtall krav som var fastsatt fra prosjektets oppstart. Prosjektoppgaven har vært svært åpen for innspill fra oss, angående hvordan vi ønsket å implementere rammeverket. Dermed var det behov for å ha noen møter med oppdragsgiver før vi kunne få på plass en god kravspesifikasjon. Av denne grunn og vårt valg av utviklingsmodell er ingen av kravene blitt endret siden siste iterasjon av kravspesifikasjonen. Vi har nummerert kravene i kravspesifikasjonen slik at vi enkelt har kunnet gå igjennom denne ved prosjektets avslutning og sikre oss at hvert krav er tilfredsstilt. Dette går frem av Hovedprosjektrapport for Project Sunstone 20

21 kapittel 2.4 i produktdokumentasjonen. Ettersom gjennomgang av denne har vist at alle krav er oppfylt, mener vi at det ferdige produktet står godt i samsvar med produktet som blir beskrevet i kravspesifikasjonen. 1.7 Om resultatet Vi er svært fornøyde med resultatet av vårt hovedprosjekt, ettersom vi mener vi har klart å oppfylle kravene til systemet på en tilfredsstillende måte. Resultatet kunne nok blitt noe annerledes dersom vi hadde endret på noen prioriteringer i begynnelsen av prosjektet. Videre mener vi at systemet har nådd målene som ble satt for en første versjon av dette produktet. 1.8 Avslutning Eget utbytte Vi føler vi har fått mye ut av dette prosjektet. Vi har lært en del nytt om databaser, Exif informasjon, implementering av MVC på større programvareprosjekter og hvordan en kan jobbe effektivt på et større prosjekt uten å miste oversikten over de enkelte delene. Samtidig har prosjektet vært en spennende utfordring, der vi har hatt muligheten til å vise at vi kan mestre å lage et meningsfylt produkt for en oppdragsgiver vi ikke er kjent med fra før Hva kunne blitt gjort annerledes Vi kunne ha brukt mer tid til planlegging av arbeidet, og på denne måten fått en mer jevn arbeidsprosess, i stedet for å ende opp med en skjev fordeling med spesielt mye arbeid mot slutten av prosjektet. Dersom vi hadde påbegynt arbeidet med brukergrensesnitt på et tidligere stadium, kunne dette ha gitt oss nok tid til å feilteste produktet bedre. Ved å sette av mer tid til utvikling av GUI kunne vi også benyttet oss av akseptansetester for å forbedre rammeverket ytterligere. Det ville vært en god ide å bruke et program for versjonskontroll til dette prosjektet. På denne måten kunne vi letter ha holdt oversikt over de mange programversjonene som er utviklet i løpet av dette prosjektet. Allikevel mener vi at vi har klart å håndtere dette på en god måte, gjennom bruk av skolens Fronter nettsted og vår egen prosjektside. Begge disse har god funksjonalitet for strukturering av filer med dato og navn. Når det gjelder prosessen med utvikling av de ulike dokumentasjonsdelene kunne vi gjerne fordelt denne over en lengre periode. Vi kom godt igang med produsering av dokumenter i prosjektets oppstart, men det ble etter hvert programmeringen som tok overhånd. Dette har ført til at mesteparten av dokumentasjonen er skrevet mot slutten av prosjektet Fremtiden Oppdragsgiver hadde et ønske om at systemet skulle legges ut som åpen kilde kode slik at det kan videreutvikles av personer som har interesser innenfor emnet. Hvis dette blir gjort kan produktdokumentasjonen, testdokumentasjonen og brukermanualen relativt enkelt oversettes til engelsk slik at de som ikke er norskspråklige også kan sette seg inn i systemet. Kodestilen og vedlegget om klassifikatorutvikling er allerede skrevet på engelsk slik at disse ikke må oversettes. Hovedprosjektrapport for Project Sunstone 21

22 Dette var første versjon av systemet, og det kan med fordel gjøres forbedringer med hensyn på blant annet effektivitet i forhold til tid når bilder skannes. Vi håper denne applikasjonen kan bli til nytte for brukere og at det finnes noen som vil videreutvikle den slik at den kan bli enda mer nyttig. Hovedprosjektrapport for Project Sunstone 22

23 Produktdokumentasjon for Project Sunstone Et hovedprosjekt i data ved Høgskolen i Oslo, våren 2010 Martin Haukeli Jostein Haukeli Marit Olsen Hovedprosjektrapport for Project Sunstone 23

24 2.1 Forord Dokumentet er beregnet for de som skal videreutvikle systemet, og for andre som kan være interessert i hvordan systemet er bygd opp. Det forutsettes generell kunnskap om Java programmering. Ettersom dette er et prosjekt med svært mye programmering, er det blitt produsert store menger kildekode. Av den grunn ønsker vi å presisere at denne er tilgjengelig for nedlasting på prosjektets hjemmeside. En vil også kunne oppleve at det er skrevet meningsfulle kommentarer og JavaDoc for de mest sentrale metodene og klassene i rammeverket. Systemets kildekode er tilgjengelig på Hovedprosjektrapport for Project Sunstone 24

25 2.2 Innholdsfortegnelse PRODUKTDOKUMENTASJON FOR PROJECT SUNSTONE FORORD INNHOLDSFORTEGNELSE BESKRIVELSE AV SYSTEMET SAMSVAR MELLOM KRAVSPESIFIKASJON OG FERDIG PRODUKT Systemkrav Andreprioritets systemkrav Rammekrav Systemkonstruksjonskrav Dokumentasjonskrav OPPBYGGING Programflyt Model View Controller FORHOLD TIL MASKIN OG PROGRAMVARE HOVEDDELER I SYSTEMET Core Angående Exif Generellt om Exif DatabaseWrapper Classifier MainWindow ThumbnailView PictureView PreviewWindow ClassifierView og Component ProgressBar Main Testklassifikatorer Hovedprosjektrapport for Project Sunstone 25

26 2.3 Beskrivelse av systemet Sunstone er et rammeverk for photobrowsing som er implementert slik at brukeren kan sortere bilder på en annerledes måte, i forhold til eksisterende photobrowsere. Dette skjer ved hjelp av klassifikatorer. Disse klassifikatorene kan bruke enten metainformasjonen i bildet, skanne selve bildet, eller begge deler. Eksempler på funksjonalitet slike klassifikatorer kan tilby, vil for eksempel være å finne ut om et bilde er tatt om dagen eller natten, inne eller ute, eller om den er del av en samling bilder tatt innenfor et angitt tidsrom. For at alle klassifikatorene skal fungere optimalt er det nødvendig å gjøre en del antagelser om bildesamlingene som skal sorteres. Disse samlingene bør inneholde bilder tatt utendørs og samtidig bestå av bilder tatt mens det er lyst ute. Dette fordi det ofte vil være ønskelig å sammenligne bilder mot hverandre. Videre bør kameraets klokke også være satt til riktig tid. Det kan også være en god ide og kun sortere på bildemapper tatt med ett og samme kamera om gangen, ettersom avvik i kamerafunksjoner vil kunne føre til uønskede søkeresultater. 2.4 Samsvar mellom kravspesifikasjon og ferdig produkt Kravspesifikasjonen ligger som et eget dokument (kapittel 3) i prosjektrapporten og vil derfor ikke bli gjengitt her. De nummererte kravene under henviser til de enkelte kravene i kravspesifikasjonen med det samme nummeret Systemkrav For en mer detaljert beskrivelse av hvordan de enkelte kravene er testet, henviser vi til testdokumentasjonens kapittel 4.5 om testing av fastsatte krav. Krav Implementasjon 1 Som beskrevet i kap har vi implementert en MVC arkitektur som skal gjøre det enkelt å legge inn nye vinduer. Nye vinduer kan legges inn ved hjelp av JSplitPanes, slik som beskrevet i kap Før et bilde blir skannet sjekkes det om bildet allerede er tildelt en verdi fra gitt klassifikator. Hvis dette ikke er tilfelle vil bildet bli undersøkt. 3 Avhengig av valg foretatt i GUI, vil ThumbnailView motta en oversikt over bilder som oppfyller valgenes kriterier. 4 Rammeverket vil lese inn kompilerte klassifikatorfiler fra en spesifisert mappe på systemet. 5 Når en ny klassifikator er lastet inn vil rammeverket undersøke om klassifikatoren har gitt en verdi til hvert bilde. 6 Dersom et eller flere bilder er endret, vil MD5 hash avsløre disse og lese inn bildene på nytt. Slik kan det også oppdages om det er nye bilder i samlingen og laste disse inn i rammeverket. 7 Ettersom det kun leses informasjon fra de enkelte filene, og miniatyrbilder blir generert i en ny mappe, vil det ikke være mulig for rammeverket å gjøre endringer på brukerens filer. 8 Ved at metoden som søker igjennom bilder får input gjennom en JOptionPane, der brukeren velger sin bildemappe, er dette kravet innfridd. Hovedprosjektrapport for Project Sunstone 26

27 2.4.2 Andreprioritets systemkrav Krav Implementasjon 9 Vi har underveis i prosjektet produsert et antall testklassifikatorer. Disse omtales i denne rapportens kapittel Vi har i løpet av prosjektet laget testcases med bilder som kan benyttes uten brudd på lisenser. 11 Vi har implementert dette ved hjelp av en fremdriftsindikator som gir tilbakemelding til brukeren om hva systemet arbeider med Rammekrav Krav Implementasjon 12 Databasen lagres etter hvert som data leses inn under oppstart. Konfigurasjonsfilen vil også bli lagret etter hvert som den blir endret. 13 Vi har definert en egen kodestil for prosjektet som alle på gruppen har godkjent. Denne er tilgjengelig som et vedlegg til rapporten. 14 Vi har laget en installer for Windows plattformen. Vi tilbyr også en zip fil som enkelt kan pakkes ut på alle plattformer. 15 Vi har implementert GUI med tanke på brukervennlighet ved hjelp av robusthet, konsistens i forhold til utseende og bruk av vanelige komponenter som menylinje, radioknapper, sliders og nedtrekksmenyer Systemkonstruksjonskrav Krav Implementasjon 16 Vi har implementert rammeverket gjennom bruk av JDK versjon Dette kravet er implementert ved at rammeverket kun vil søke igjennom filer i bildemappen som ender på enten.jpg eller.jpeg uten hensyn på små eller store bokstaver Dokumentasjonskrav Krav Implementasjon 18 Vi har brukt dokumentasjonsstandarden som en mal for utvikling av alle hoveddeler av prosjektrapporten. 2.5 Oppbygging Programflyt Ved systemets oppstart vil en ny instans av Core opprettes. Core lager så en fremdriftsindikator som vil vises på skjermen til all innlasting og skanning er ferdig. Hovedprosjektrapport for Project Sunstone 27

28 Det neste som skjer er at klassifikatorer lastes inn fra en fast mappe og blir instansiert. Når dette er ferdig vil det finnes en liste som inneholder alle av brukerens klassifikatorer uten duplikater. Når klassifikatorene er lastet inn blir avhengigheter kontrollert. Dette skjer ved at klassifikatorene uten avhengigheter til andre klassifikatorer, eller som har alle avhengighetene sine innfridd, blir lagt til i en liste over brukbare klassifikatorer. Hvis det finnes en klassifikator som er avhengig av en annen klassifikator som ikke finnes i lista, så vil denne bli lastet ut igjen. På denne måten sikrer vi at alle klassifikatorene kan brukes. Når klassifikatorene er kontrollerte og lastet inn blir DatabaseWrapperen instansiert. Den forsøker å åpne en tidligere lagret database, eller lager en ny hvis ingen finnes. Så blir alle bilder som ligger i valgt bildemappe beregnet hash på og lagt inn i en HashMap som inneholder hashen og bildelokasjonen. Hash blir beregnet ved hjelp av MD5. Deretter hentes det en liste fra databasen over alle lagrede bilder. Så sammenlignes alle bildene fra databasen mot alle bildene som ligger i den valgte bildemappen. Alle bildene som har blitt endret på eller fjernet fra samlingen blir slettet, og alle bildene som ikke ligger i databasen fra før blir så lagt inn. Det hentes ut metadata informasjon ved bruk av ExifWrapperen og så lagres dette i databasen ved bruk av DatabaseWrapperen. Når dette er ferdig startes en ny tråd som lager miniatyrbilder for alle nye og endrede bilder. Til slutt skannes alle bilder som mangler informasjon fra en eller fler klassifikator. Informasjon om hvert bilde hentes fra databasen og sendes til klassifikatorene sånn at de kan analysere og gjøre beregninger på bildets informasjon. Deretter svarer klassifikatorene med å gi en ny verdi, eller tag, til bildet. Denne verdien blir lagret i databasen slik at andre klassifikatorer kan dra nytte av den og sånn at man senere kan filtrere på den. Deretter vil hovedvinduet med filtre og miniatyrbilder vises og fremdriftsindikator blir borte Model View Controller Vi har ønsket å implementere applikasjonen ved hjelp av en model view controller arkitektur. Dette innebærer i store trekk at vi deler opp visning av informasjon til brukeren, beregninger som gjøres av applikasjonen, og håndtering av data som skal lagres i adskilte deler av rammeverket. Hovedprosjektrapport for Project Sunstone 28

29 Figur 2.1 Oversikt over Model View Controller arkitektur. Controller Dette har vi implementert ved å lage en egen kontroller klasse kalt Core, som har mulighet til å kalle på og sende informasjon fra og til de ulike delene av applikasjonen. Model Som modell har vi valgt å bruke en enkel database kalt Derby. Denne databasen tilbyr en integrert versjon og en vanlig nettverks versjon. Til dette rammeverket benytter vi oss av den integrerte versjonen. Det finnes også plugins som enkelt kan installeres i Eclipse. I denne databasen lagres all informasjon slik som Exif-informasjon, filsti for fullskala bilder og miniatyrbilder, samt resultatene fra klassifikatorene. View Applikasjonens brukergrensesnitt er delt inn i tre undervinduer. Dette er implementert på en slik måte at en enkelt kan endre, ta vekk eller legge til nye undervinduer etter behov. Denne klassen har ansvar for å opprette ThumbnailView, ClassifierView samt vinduet for forhåndsvisning av valgt bilde, PictureView. Hovedvinduet er også et kommunikasjonsledd mellom kontrolleren (Core), og de enkelte undervinduene. 2.6 Forhold til maskin og programvare Før systemet installeres, må Java være installert på datamaskinen. Java kan lastes ned fra denne siden: Hovedprosjektrapport for Project Sunstone 29

30 Ettersom bildeprossesering krever mye minne, har vi satt et krav om at datamaskinen applikasjonen kjører på, bør ha mer enn 512 MB minne tilgjengelig til programmet. 2.7 Hoveddeler i systemet Figur 2.2 Java klasser representert som sirkler. Streker viser hvor det foregår kommunikasjon. Figur 2.2 viser de forskjellige Java klassene representert som sirkler. Strekene mellom disse viser hvor det foregår kommunikasjon mellom dem, mens de tre større områdene viser den tilhørende pakken. Forklaring over hva disse inneholder og gjør kommer under. Vi har valgt å spesifisere metodene som ligger i Core mest fordi dette er kjernen i programmet Core Laste inn klassifikatorer loadclassifiers() leser inn alle klassifikatorer fra en mappe, lager nye instanser av disse og legger disse i en lenket liste som kalles classifiers. Når dette er gjort vil disse klassifikatorene sorteres i en rekkefølge hvor de kan brukes av scanimages(). Dette gjøres i metoden sortclassifiers. Her vil alle klassifikatorer som ikke har avhengigheter, og de som har alle sine avhangigheter innlagt, legges til i en liste. Hvis det eksisterer klassifikatorer som har gjensidig avhengighet, vil disse oppdages og fjernes fordi de går i en evig while løkke. Dette sjekkes enkelt med en boolean som viser om noe ble lagt til i listen ved hver gjennomløping. En alternativ metode som innebærer et Depth First Search med sirkel oppdaging(cycle detecting) kunne med fordel vært brukt dersom en skulle laste inn store mengder klassifikatorer. Hovedprosjektrapport for Project Sunstone 30

31 Etter denne metoden er klassifikatorene som ligger i den lenkede listen classifiers klare til bruk, uten å måtte modifisere/rekompilere systemet. Oppdaging av bilder En unik hashverdi tilknyttet hvert enkelt bilde er svært viktig for at programmet skal kunne skille mellom de ulike filene. Denne verdien beregnes ut ifra hele bildefilens innhold, og kan derfor oppdage både endringer i bildets datasegmenter og metadata. Verdien lagres i databasen der den også har en vital funksjon som primærnøkkel, dermed unngår vi også dobbeltlagring av bilder. Forøvrig er hash verdien spesielt viktig der en ønsker å bruke samlingsklassifikatorer, fordi disse opererer på bildesamlinger der hvert enkelt bilde får tilegnet en verdi. Andre fordeler med MD5 funksjonen er muligheten den gir oss for å oppdage endringer i bildesamlingene. Dette er implementert ved hjelp av et bibliotek kalt Fast MD5. Dette har gitt oss muligheten til enkelt å finne frem til en checksum på heksadesimalt format. En ulempe ved bruk av hash som primærnøkkel, er muligheten for at flere filer potensielt kan få tildelt identiske verdier. Ettersom dette vil kunne medføre at programmet ikke lenger fungerer som det skal, vil det være naturlig å forbedre sikkerheten omkring dette dersom rammeverket skulle vise seg å bli svært populært. Dersom det skulle oppstå en kollisjon, vil dette resultere i at et eller flere bilder ikke blir vist. Ettersom både sannsynlighet for tilfeldig kollisjon og risiko er svært liten, har vi til tross for dette valgt å gå for denne løsningen. Hvordan vi gått frem for å teste Fast MD5 beskrives nærmere i testrapporten. Metoden loadimagepathsandhashes benytter seg av getmd5 for å finne en checksum for hvert bilde. Videre vil addnewimages og removemissingimages oppdatere databasen med hvilke bilder som finnes i samlingen. Denne informasjonen stammer fra den førstnevnte metoden, loadimagepathsandhashes. Skanne bilder I scanimages vil den sorterte lista av klassifikatorer fra sortclassifiers benyttes til å skanne bildene. For å finne ut hvilke bilder som må skannes kontrolleres hvert bilde om de har fått tildelt en verdi fra hver klassifikator. For hvert bilde som skal skannes hentes det ut den informasjonen klassifikatoren ber om ved bruk av DatabaseWrapperen. Denne informasjonen sendes i form av et HashMap til klassifikatoren som deretter kan trekke ut informasjonen. Klassifikatoren returnerer deretter en verdi og denne lagres i databasen. Hvis det benyttes en samlingsklassifikator vil den istedenfor å motta en HashMap, motta et Set av HashMap. I dette settet inneholder hvert HashMap verdiene til hvert bilde. Core vil vente på at klassifikatoren blir ferdig. Hvis klassifikatoren returnerer null eller kaster en exception vil ingen data lagres om gjeldene bilde, men skanningen fortsetter som normalt. Miniatyrbilder Det ligger en egen klasse i Core som heter ThumbnailGenerator. Denne klassen tar seg av generering av miniatyrbildene, og klassen kjører i bakgrunnen som en egen tråd. Grunnen til at vi valgte dette er at å lage miniatyrbilder tar lang tid med store bildesamlinger og at det kan gjøres samtidig med at man skanner bildene. Hovedprosjektrapport for Project Sunstone 31

32 Metoden makethumbnails() i denne interne klassen sammenligner miniatyrbildenes filsti for alle bildene som ligger i bildesamlingen mot de som er lagret i databasen. For hver av filstiene som mangler lages det så miniatyrbilder. Miniatyrbilder blir skalert ned ved hjelp av JAI (Java Advanced Imaging) sin Bilinear metode. Denne metoden fokuserer på hastighet, fremfor bildekvalitet. Dette medfører at bildekvaliteten i stor grad blir degradert i forhold til det opprinnelige bildet. Maksimumstørrelsen blir satt til 140 piksler i den retningen bildet er størst. Miniatyrbildet blir lagret som en JPG fil, og filsti for miniatyrbilder blir lagret i databasen Angående Exif Generelt om Exif Exif lar digitalkameraet lagre et stort antall data om hvert enkelt bilde som blir tatt. Eksempel på slik data kan være dato og klokkeslett, kameramodell, og informasjon om innstillinger som eksponeringstid, ISO-hastighet og blits innstillinger. I tillegg gir Exif muligheter for at kameraprodusenten kan lagre informasjon som er spesifikk for et gitt kamera. Disse blir kalt for makernotes, og brukes i økende grad, ettersom kameraene får mer avanserte innstillinger som ikke er definert i Exif standarden. Dette gjør Exif metadata svært informasjonsrik og nyttig for fotografer og andre som er interessert i bildets opprinnelse. For øvrig er denne informasjonen det viktigste verktøyet brukeren har, dersom det er ønskelig å sortere store bildesamlinger uten å analysere hvert enkelt bilde basert på innhold. For en god oversikt over hvordan denne informasjonen vil kunne se ut, vil vi henvise til vedlegg 6 om Exif informasjon. En svakhet med Exif standarden er dens filstruktur som innebærer at data kan lagres hvor som helst i en fil. Hvis en fil med Exif data skal modifiseres i for eksempel et bilderedigeringsprogram, vil dette kunne medføre informasjonstap når det lagres endringer i bildet uten å ta spesielt hensyn til metadata. Vi har gjort en undersøkelse der vi har funnet ut at avanserte redigeringsprogrammer som for eksempel Photoshop vil kunne ta hensyn til de Exif feltene som er definert i Exif standarden. Det oppstår på den annen side problemer dersom bildet innholder makernotes, og disse vil bli slettet ved skriving til bildet. Et annet viktig poeng som er verd å merke seg, er at Exif informasjonen ikke er entydig i den forstand at felter for eksempel kan være representert på formen eller 1/50s. Av denne grunn var vi valgt å implementere den delen av rammeverket som her vil omtales som ExifWrapper. Metadata-Extractor Vi har valgt å bruke et bibliotek for uthenting av Exif data, skrevet av Drew Noakes. Biblioteket er åpen kildekode, frigitt under Public Domain. Dette tillater oss å gjøre alle modifikasjoner vi måtte ønske og tillater oss å frigi programmet med hvilket som helst lisens vi måtte ønske. Den første versjonen ble frigitt i 2002, og har seneste oppdatering datert til Biblioteket er oversatt til en del andre programmeringsspråk og har vært testet i en lang periode. Koden er blitt implementert i en rekke andre programmer. Et eksempel er JAlbum, som er et Hovedprosjektrapport for Project Sunstone 32

33 velbrukt verktøy for generering av bildealbum for enkel deling på internett. JAlbum nærmer seg forøvrig 6 millioner nedlastede eksemplarer fra programmets offisielle side. Måten vi har valgt å implementere dette biblioteket på, er å lage en såkalt wrapper klasse, som står for kommunikasjon mellom vår applikasjon og metadata-extractor biblioteket. Exif Wrapper Wrapper klassen mottar en filsti, og sender den spesifiserte filen til biblioteket for uthenting av metadata. Deretter vil wrapper klassen hente ut relevant data som vi ønsker å benytte for sortering av bildesamlingene. En av grunnene til denne implementasjonen, er vårt behov for en entydig representasjon av datafeltene, slik at klassifikatorene enkelt skal kunne gjøre beregninger på metadataen. En annen god grunn til å implementere programmet slik, er å gjøre det enklere å bytte ut deler av programmet, dersom det skulle vise seg nødvendig i fremtiden. Vi mener at dette er en god løsning som oppfyller krav om objektorientert og ryddig programkode. Ettersom metadata-extractor bibliotekets com.drew.metadata.exif pakke tilbyr identifisering av produsentspesifik metadata for en rekke kameramodeller fra de største produsentene, vil applikasjonen kunne utvides med uthenting av disse, dersom det i fremtiden skulle vise seg nyttig å hente ut informasjon fra disse feltene. Dette kan innebære at en må utvide Drew Noakes bibliotek med oppdaterte makernote formater, noe som kan være vanskelig ettersom en da må få tak i oppdaterte beskrivelser av disse formatene fra produsenten. For de tilfellene der informasjonen ikke vil kunne oversettes til en entydig form, vil det for tallverdier returneres 0, eller 0.0. I de fleste tilfeller vil klassifikatorutvikler kunne gjenkjenne disse verdiene og håndtere disse på ønskelig måte, ettersom for eksempel en eksponeringstid på 0 sekunder ikke gir mening. Dersom det ikke eksisterer et felt for en gitt verdi i metadataen, vil klassifikatorutvikler kunne håndtere disse feltene ved og for eksempel sette verdien til 0. I disse tilfellene vil også hovedvinduet kunne vise hva som er galt, gjennom menylinjens feilmeldingsvindu DatabaseWrapper Siden Apache Derby database ikke gir støtte for innsetting av objekter direkte, benytter vi oss av ByteArrayOutputStream og ObjectOutputStream slik som det vises i den koden under. Uthenting av objekter gjøres på lignende måte. PreparedStatement psinsert = null; ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos); oos.writeobject(value); oos.close(); psinsert = dbcon.preparestatement("insert INTO images (hash, field, value) VALUES (?,?,?)"); psinsert.setstring(1, imagehash); psinsert.setstring(2, key); psinsert.setbytes(3, bos.tobytearray()); Hovedprosjektrapport for Project Sunstone 33

34 Når det blir instansiert en ny DatabaseWrapper vil driveren først lastes inn ved hjelp av loaddriver før det blir forsøkt åpnet en lagret database. Dersom det ikke finnes en database fra før i loaddatabasefromfile, vil det bli opprettet en ny database. Tabellen images vil også bli opprettet hvis den ikke finnes fra før. Når det skal legges til et nytt bilde kalles det på addimage(hashmap<string,object> image_data), den medfølgende HashMap en inneholder verdiene som skal settes inn i databasen. For hver nøkkel i denne HashMap en blir det kalt på setimagevalue(string imagehash, String key, Object value) hvor imagehash blir satt til hashen til bildet, key blir satt til den enkelte nøkkel og value blir satt til nøkkelens verdi. I denne metoden settes verdiene inn i databasen. Metoden getimagevalues(string imagehash) henter alle verdier for bildet som har hashen imagehash og legger disse inn i en HashMap med navnet på verdien som nøkkel og verdien til denne som verdi. getmatchingimages(string key, Object value) vil hente alle bildehasher som har et nøkkel/verdi par lik key/value. Dette legges i et HashSet slik at eventuelle duplikater ikke blir med. Informasjon i databasen kan slettes ved å kalle på deleteimage(string imagehash) hvor imagehash er det bildet som skal slettes. En lenket liste over alle bilder som er lagret i databasen kan fås ved å kalle på getimagelist(). Denne returnerer kun unike bilde hasher Classifier Klassifikatoren er komponenten som tar imot informasjon om et bilde og gir det en verdi som kan brukes til å sammenlikne bilder. Et eksempel på en klassifikator er en Dag eller natt klassifikator som sier om hvert bilde er tatt om dagen eller om natten. Denne verdien er implementert på en generisk måte, så utvikler av klassifikatoren selv kan velge hvordan dette skal representeres (Noen eksempler: Boolsk valg, en streng, heltall). Klassifikatorer lastes inn ved oppstart fra en undermappe som heter classifiers. Her kan brukeren legge til nye eller ta vekk gamle klassifikatorer som han ønsker. Klassen Classifier er et API for å lage nye klassifikatorer. For å lage en ny klassifikator begynner man med å 'extende' Classifier. Classifier er en abstrakt klasse og har en rekke abstrakte metoder som klassifikatorutvikleren må lage. En klassifikator kan ha en grafisk komponent som skal vises I GUI'et I form av et filter. Dette gjøres ved at klassifikatoren lager en ny Component og sender denne til Core. Component klassen lager grafiske komponenter klare til å legges inn i classifierview Panelet utifra verdiene klassifikatoren gir den. Når Core skanner med en klassifikator kjører den scanimage eller scancollection metoden I klassifikatoren. Dette er to av de abstrakte metodene som må lages av klassifikatorutvikleren. Hovedprosjektrapport for Project Sunstone 34

35 2.7.5 MainWindow MainWindow er hovedvinduet i systemet. Hovedvinduet i seg selv er en JFrame som har en menylinje. Denne tilbyr blant annet funksjonalitet for endring av filsti til brukerens bildemappe, mulighet til å skru av og på klassifikatorer, og informasjon om hvordan en kan få hjelp til bruk av rammeverket, samt informasjon om hvem som har utviklet dette. Mainwindow starter nye instanser av ThumbnailView, PictureView og ClassifierView. Disse tre er laget som JPanels, som etter tur legges inn i JSpiltPanes. En JSplitPane er designet for å inneholde kun to komponenter, en i hver pane. En måte å omgå dette på, og slik vi har implementert dette, blir beskrevet her. Vi begynner med å legge inn de to første komponentene, i dette tilfellet et undervindu i hvert panel i en JSplitPane. Deretter legger vi denne ferdige JSplitPane komponenten inn i den andre JsplitPanen, sammen med det siste vinduet. Ved å dele inn hovedvinduet på en slik måte, vil det også kunne legges inn nye vinduer ved en senere videreutvikling av applikasjonen. Koden vi har brukt for å legge til disse er: verticalsplit.add(twindow, JSplitPane.LEFT); verticalsplit.add(iwindow, JSplitPane.RIGHT); horizontalsplit.add(verticalsplit, JSplitPane.LEFT); horizontalsplit.add(cwindow, JSplitPane.RIGHT); add(horizontalsplit, BorderLayout.CENTER); Her er verticalsplit og horizontalsplit JSplitPanes og twindow, iwindow, cwindow er de enkelte undervinduene. Hver enkelt komponent som skal legges inn i en JSplitPane, legges inn i den spesifiserte siden av skillelinjen. Her kan det som i vår kode anvendes høyre og venstre, men det er også mulig å bruke topp og bunn som parameter. Til slutt er den siste JSplitPanen lagt til sentrert i JFrame ved hjelp av en borderlayout. Med en JSplitPane har brukeren mulighet til å endre størrelsen på hvert enkelt undervindu etter egne preferanser. Siden det her ikke finnes mulighet for å maksimere eller minimere har vi valgt å legge til en funksjon som åpner ett nytt vindu med det valgte bildet når det trykkes på. Mainwindow lager en HashMap paths som henter en HashMap fra Core sin metode getremainingimages(). Denne HashMap en innholder alle stier til gjenværende bilder og deres tilhørende miniatyrbilder. Metoden selectimage(string thumbnailpath) bruker HashMap en paths for å finne filstien til bildet som tilhører det miniatyrbildet som ble valgt. Denne metoden vil bli kalt på fra ThumbnailView dersom brukeren trykker på et angitt bilde ThumbnailView ThumbnailView er en klasse som lager et antall knapper som tilsvarer antallet bilder som skal vises for brukeren. Oversikten over disse bildene sendes fra Core til MainWindow, og videre til Thumbnailview. Knappene er implementert ved hjelp av Swing komponenten JButton, som har et miniatyrbilde. Ettersom det er en kjent feil i Java, som gjør at JScrollPane ikke kan ha et vertikalt scrollefelt dersom det innholder en JPanel med FlowLayout, har vi implementert en Hovedprosjektrapport for Project Sunstone 35

36 klasse som håndterer dette problemet. Denne klassen er basert på en klasse frigitt på Sun sitt diskusjonsforum i Ettersom vi ønsker at programmet skal skalere så godt som mulig med veldig store mengder bilder, har minnebruk for miniatyrbilder vært en implementasjonsutfordring. Måten vi har løst dette på, er å kalle på java.awt.image sin flush() metode. Dette vil skje jevnlig mens scrollbarens posisjon endres. På denne måten vil ressurser for bilder som ikke vises på skjermen frigjøres, og miniatyrbildene vil automatisk bli lastet inn igjen for de bildene som skal tegnes til skjerm. Et viktig poeng her var å sørge for at ikke bilder som er synlige på skjermen får sine ressurser frigjort. Dette er implementert ved å teste at hver enkelt knapp har en bredde eller høyde lik 0, ved hjelp av knappens getvisiblerect(). Deretter gjøres det kall på flush() metoden PictureView PictureView er en JPanel som gir brukeren mulighet for visning av et valgt bilde i større format. PictureView mottar en filsti i konstruktøren og laster inn dette bildet i en BufferedImage, som så blir tegnet av klassens paint(graphics g) metode. Her blir bildet skalert til en mer passende størrelse i forhold undervinduets størrelse. Plasseringen på bildet blir også satt slik at hvis bildet er mindre enn rammen det er satt i, vil bildet plasseres i midten av rammen. Denne klassen implementerer også en MouseListener slik at bildet kan klikkes på for visning av en fullskjerm versjon av det valgte bildet i en egen ramme PreviewWindow PreviewWindow er et eget vindu som kun viser det valgte bildet i stort format. Dette er en egen JFrame som blir satt til samme størrelse som skjermen. Deretter settes det inn en ny PreviewPanel som forøvrig er en JPanel. I dette panelet blir bildet som er klikket på tegnet slik som i PictureView ClassifierView og Component Classifierview er brukerens kontrollpanel for applikasjonen. Her vil hver klassifikator som er installert på systemet være representert i et eget panel med en tittel, beskrivelse og alternativer som er fastsatt av utvikleren. Det er viktig å merke seg at definisjoner for hvordan de ulike klassifikatorene skal vises i brukergrensesnittet, er definert i klassen Component. De forskjellige typene klassifikatorer er JComboBox, JSlider og JRadioButton. For at hver enkelt klassifikator skal utnytte den avsatte plassen på en god måte, har vi valgt å implementere denne klassen ved hjelp av layout-manageren GroupLayout. Selv om GroupLayout ble utviklet for bruk av GUI byggingsprogrammer, kan den fungere utmerket for programmering for hånd. Dette har krevd at vi satte oss godt inn i hvordan denne layout-manageren fungerer, slik at vi effektivt har kunnet bruke denne på ønskelig måte. Det som er spesielt med GroupLayout er at utvikleren må spesifisere komponentenes posisjon både på den horisontale aksen og den vertikale aksen hver for seg. Ved hjelp av denne svært fleksible og avanserte layout-manageren har vi kunnet definere hvordan hver enkelt komponent skal oppføre seg når brukeren endrer vinduets størrelse, noe som ellers kunne vist seg å bli svært problematisk. Hovedprosjektrapport for Project Sunstone 36

37 Forøvrig er klassifikatorvinduet optimalisert for vertikal visning. Dette vil relativt enkelt kunne endres slik at også horisontal visning effektivt kan utnytte plassen som er satt av. En måte å implementere dette på kan være å teste om klassifikatorbredden er større en høyden, og bytte visning til horisontalt optimalisert visning dersom dette er tilfellet. Forøvrig har vi valgt å implementere en klasse som gir JSlider-baserte klassifikatorer økt funksjonalitet ved å legge til en tooltip som viser den nåværende verdien. Ideen for denne tooltip klassen stammer fra brukere ved Sun sine offisielle brukerforum, der en slik implementasjon ble diskutert over en periode. Vi har skrevet en noe modifisert versjon av denne, som blant annet reparerer en bug som gjorde at tooltipen var tom ved første museklikk ProgressBar JProgressBar er brukt for å lage fremdriftsindikatoren. Den inneholder en metode for å endre tittel på rammen slik at brukeren kan se hva systemet jobber med. En metode for å endre antall prosent ferdig, og en metode for å legge til tekst i JTextArea området. Figur 2.3 Progress bar Main Main klassen lager et nytt Core objekt, og deretter et nytt MainWindow. Idet Core objektet lages vil det starte og laste inn data og skanne nye bilder. Imens Core jobber vil det vises en fremdriftsindikator. Når Core er ferdig med å jobbe vil Main fortsette med å lage MainWindow og sende med Core som et argument Testklassifikatorer Det finnes 5 testklassifikatorer som alle er laget av gruppen. Det er viktig å understreke at disse klassifikatorene ikke er ment å brukes av sluttbruker, men som en demonstrasjon av grensesnittet og eksempler for utvikling av nye klassifikatorer. ClassifierExposureValue regner ut ExposureValue(EV) for hvert bilde, men har inget synlig filter i guiet. Formelen vi har brukt for EV er fra wikipedia: Log 2 ( N 2 /t). ClassifierDayNight bruker EV regnet ut av ClassifierExposureValue til å anslå om det er dag eller natt i et bilde. Klassifikatoren har en nedtrekksmeny hvor man kan velge natt eller dag. Bakgrunnen for verdiene brukt av denne klassifikatoren stammer fra oppdragsgiver. ClassifierContentRGB ser på hver piksel i et bilde og regner ut gjennomsnittet av alle RGB verdiene. Dette sier noe om hvor lyst det er i bildet. Denne klassifikator er den som trenger mest tid til å skanne hvert bilde. Dette er fordi hele bildet må analyseres, istedenfor bare metadataen. Hovedprosjektrapport for Project Sunstone 37

38 ClassifierBrightness ser på verdiene gitt av ClassifierContentRGB og sier om hvert bilde er mørkt, lyst eller midt i mellom. Klassifikatoren har en kolonne med radiobokser hvor disse tre alternativene finnes. Formelen for dette er noe vi har funnet på selv, men som ser ut til å virke ganske bra. ClassifierSelfDependency er en klassifikator er avhengig av seg selv. Dette betyr at den allerede må være lastet inn før den kan lastes inn. Noe som er umulig. Derfor vil denne klassifikatoren aldri virke. Denne er altså kun ment for testing av programmet. Hovedprosjektrapport for Project Sunstone 38

39 Kravspesifikasjon for Project Sunstone Et hovedprosjekt i data ved Høgskolen i Oslo, våren 2010 Martin Haukeli Jostein Haukeli Marit Olsen Hovedprosjektrapport for Project Sunstone 39

40 3.1 Forord Denne kravspesifikasjonen beskriver kravene til vårt hovedprosjekt «Project Sunstone». Kravene deles opp i systemkrav, rammekrav, systemkonstruksjonskrav og dokumentasjonskrav. Den er laget for sensor, veileder, oppdragsgiver, prosjektgruppen og andre som kan ha interesse for den. Dokumentet er også ment å kunne brukes som en sjekkliste og rettesnor for systemet. Hovedprosjektrapport for Project Sunstone 40

41 3.2 Innholdsfortegnelse KRAVSPESIFIKASJON FOR PROJECT SUNSTONE FORORD INNHOLDSFORTEGNELSE INNLEDNING Presentasjon Bakgrunn KORT SYSTEMBESKRIVELSE RAMMEKRAV I SYSTEMET EVENTUELLE KRAV TIL SYSTEMKONSTRUKSJON EVENTUELLE KRAV TIL DOKUMENTASJON DATAMODELL Hovedprosjektrapport for Project Sunstone 41

42 3.3 Innledning Presentasjon Tittel: Project Sunstone Oppgave: Lage et utvidbart rammeverk for photobrowsing Oppdragsgiver: Frode Eika Sandnes, Høgskolen i Oslo Veileder: Frode Eika Sandnes Gruppe nr: 17 Gruppemedlemmer: Jostein Haukeli, Martin Haukeli og Marit Olsen Bakgrunn Vårt hovedprosjekt skal utføres på oppdrag fra Frode Eika Sandnes, Høgskolen i Oslo. Vi skal i løpet av prosjekttiden utvikle et fleksibelt rammeverk for sortering og kikking på bildesamlinger tatt med digitalkamera. Systemet skal kunne implementere en rekke klassifikatorer som kan analysere ulike deler av bildenes metadata og innhold, og på denne måten sortere bildene inn i meningsfylte kategorier spesifisert av brukeren. Dette gjør at brukeren enkelt kan finne frem i store bildesamlinger som gjerne er tatt på et mye tidligere tidspunkt. Vi har ingen kjennskap til photobrowsere som kan sortere bilder etter hvor de er tatt, om det er dag eller natt, eller egendefinerte kategorier. De photobrowserene vi vet om sorterer stort sett etter dato, navn og størrelse på bildet. Ett eksempel på dette er Google Picasa som blant annet sorterer etter disse tre egenskapene. 3.4 Kort systembeskrivelse Systemet skal oppfylle følgende krav: 1. Systemet skal innholde et utvidbart brukergrensesnitt 2. Metoden for å undersøke bilder skal ikke skanne det samme bildet mer enn en gang 3. Systemet skal gjøre det mulig å arrangere bilder i en samling etter valgte klassifikatorer 4. Systemet skal kunne utvides med brukerens egne klassifikatorer ved runtime, altså uten behov for rekompilering. 5. Ved aktivering av ny klassifikator skal bildene skannes gjennom denne 6. Systemet skal kunne oppdage alle endringer i bildesamlingene og skanne disse på nytt om nødvendig 7. Systemet skal ikke gjøre noen endringer på brukerens filer 8. Det skal kun søkes etter bilder i kataloger og underkataloger som er valgt av brukeren Systemet bør oppfylle følgende krav: Hovedprosjektrapport for Project Sunstone 42

43 9. Systemet bør innholde noen testklassifikatorer 10. Det bør lages test cases slik at det er mulig å demonstrere systemet 11. Det bør implementeres en løsning som øker toleransen for ventetid ved innlasting av bilder 3.5 Rammekrav i systemet 12. Brukerens data må sikres slik at informasjon ikke går tapt 13. All kode skal være skrevet med konkrete regler for kodestil, slik at det blir mulig for andre å sette seg inn i koden dersom det skal videreutvikles på et senere tidspunkt 14. Det skal være mulig å laste ned, installere og kjøre systemet i henhold til vanlige selvinstalleringsmetoder 15. Brukergrensesnittet bør følge vanlige konvensjoner slik at det kan brukes av personer uten spesielle it-kunnskaper eller opplæring 3.6 Eventuelle krav til systemkonstruksjon 16. Systemet skal kunne kjøres med Java Standard Edition 6 (Java SE 6) eller senere 17. Systemet skal jobbe mot Exif data med JPEG fil format 3.7 Eventuelle krav til dokumentasjon 18. Vi skal bruke Dokumentasjonsstandarden som er utarbeidet av førstelektor Ann-Mari Torvatn ved Høgskolen i Oslo. 3.8 Datamodell Figur 3.1 Bildet viser en mulig implementasjon av brukergrensesnittet i et Windows miljø Hovedprosjektrapport for Project Sunstone 43

44 Testdokumentasjon for Project Sunstone Et hovedprosjekt i data ved Høgskolen i Oslo, våren 2010 Martin Haukeli Jostein Haukeli Marit Olsen Hovedprosjektrapport for Project Sunstone 44

45 4.2 Forord Dette er en testrapport for hovedprosjektet Project Sunstone ved Høgskolen i Oslo, våren I denne rapporten tar vi for oss en rekke ulike tester som er gjort i løpet av utviklingsprosessen, og etter at rammeverket var ferdig utviklet. Disse testene er i hovedsak utført av programmereren selv. Hovedprosjektrapport for Project Sunstone 45

46 4.1 Innholdsfortegnelse TESTDOKUMENTASJON FOR PROJECT SUNSTONE FORORD INNHOLDSFORTEGNELSE TESTING UNDERVEIS Bildeskalering Miniatyrbildevisning Hash EXIF FERDIG PRODUKT Oppstart GUI Bak kulissene TESTING AV FASTSATTE KRAV Hovedprosjektrapport for Project Sunstone 46

47 4.3 Testing underveis Ved implementering av de delene av programmet som krever mye ressurser i form av tid, bruk av prosessorkraft eller minne, har vi utført ulike former for effektivitetstester. Dette er blant annet gjort for og lettere kunne foreta gode valg mellom ulike implementasjonsmetoder. Etter at milepæler i utviklingsprosessen er nådd, har vi også foretatt tester for å sikre oss at koden gir et forventet resultat. Måten vi har gjort dette på er i mange tilfeller enkel bruk av printing av informasjon til konsollen Bildeskalering Formålet med testen var å produsere miniatyrbilder på en effektiv måte. Dette hadde stor betydning for tidsbruk ved oppstart av systemet der det blir oppdaget nye filer i bildemappen som skal gjennomsøkes. Generering av miniatyrbilder vil altså skje ved programmets første oppstart, og dersom brukeren har lagt til nye bilder i bildemappen. Vi har søkt etter metoder for skalering av bilder i Java tutorials på internett. I tillegg til dette har vi vært på utkikk etter informasjon om de vanligste metodene for generering av miniatyrbilder i programmer som benytter seg av slike. Vi fant etter hvert frem til fem forskjellige måter som vi syntes virket aktuelle for vårt prosjekt. Måten vi har gått frem for å teste disse ulike metodene har vært å utvikle programkode som anvender disse, tilpasset vårt behov. De ulike metodene for bildeskalering som er blitt testet er JAI Bilinear JAI Bicubic JAI Bicubic_2 AWT (Abstract Window Toolkit) JMagick Resultatet av testen følger under. JAI (Java Advanced Imaging) ( Miniatyrbildene blir generert på en slik måte at det medfører store mengder informasjonstap. Dette fører til at bildene blir svært uklare i forhold til de andre metodene vi har testet for generering av miniatyrbilder. På den annen side blir bildene generert med større effektivitet med hensyn på tid enn den tilsvarende AWT metoden. JAI tilbyr tre forskjellige metoder for generering av miniatyrbilder. Slik vi har forstått det, benytter disse seg av ulike former for interpolasjon mellom utvalgte punkter i bildet. På denne måten kan en finne frem til en passende farge og lyshetsgrad for hver enkelt piksel i miniatyrbildet. AWT (Abstract Window Toolkit) Hovedprosjektrapport for Project Sunstone 47

48 Denne metoden lager miniatyrbilder av ønskelig bildekvalitet, men bruker samtidig lengre tid på generering av disse. Av metodene AWT tilbyr, forsøkte vi kun med SCALE_FAST metoden, ettersom dette skulle være den minst tidkrevende prosessen. JMagick JMagick er et JNI (Java Native Interface) til ImageMagick. ImageMagick er skrevet i C, og må installeres på den maskinvaren JMagick skal brukes på. Dette krever da altså at brukeren enten må ha applikasjonen installert på forhånd, eller få beskjed om at dette må installeres før installering av Sunstone på maskinen for at bildeskalering skal fungere. Det som er veldig positivt med programmet er den korte tiden det tar å lage miniatyrbilder. Hvis brukeren har mange bilder i sin fotosamling kan dette har stor betydning for ventetiden når programmet skal startes for første gang. Bildene som blir laget oppfyller også våre krav til bildekvalitet. Figur 2 JMagick Figur 3 AWT Figur 4 JAI Bilinear Figur 5 JAI Bicubic Figur 6 JAI Bicubic_2 Figur 6 viser tiden det tok å lage et miniatyrbilde under testing på vårt system. I denne testen er det brukt 118 bilder på ca 10 megapiksler, miniatyrbildestørrelse på 140 * 105. Datamaskinen testen er gjort på har en Intel Core 2 Solo prosessor(1,4 GHz, 800 MHz FSB) Hovedprosjektrapport for Project Sunstone 48

49 Metode: Millisekunder per bilde Sekunder per bilde JMagick 1022,4 ms 1,0 s AWT 2983,4 ms 2,9 s JAI Bicubic 1563,9 ms 1,5 s JAI Bicubic_2 1698,6 ms 1,7 s JAI Bilinear 1415,8 ms 1,4 s Figur 7 Tidsforbruk skalering Konklusjon: JMagick er den metoden vi har testet som har vært mest effektiv i forhold til hastighet. Men det vil også by på størst utfordringer for brukeren siden ImageMagick må installeres først. Av de andre metodene er JAI Bilinear den raskeste og bør derfor bli den vi anbefaler å bruke Miniatyrbildevisning Denne visningen kan potensielt oppta store mengder plass i minnet. Grunnen til dette er at det må genereres knapper med miniatyrbilder for hvert enkelt bilde i systemet. Tidlig i utviklingen fant vi ved hjelp av testcase ut at minnebruken var unødvendig høy. Dette satte igang en prosess der vi undersøkte muligheter for frigjøring av ressurser for de bildene som ikke er synlige for brukeren. Ved å implementere en slik metode kunne vi øke skalerbarheten av visningen med en svært stor margin. Opprinnelig kunne vi ved testing kun laste inn i underkant av 1000 bilder før vi overskred grensen for allokert minne i Javas virtuelle maskin. Denne grensen er opprinnelig satt til 64 MB minne. Ved siste versjon av miniatyrbildevisningen er denne testet med innlastede bilder Hash Ettersom vi ønsker å kunne identifisere endringer i bildesamlingen har vi implementert en metode for dette gjennom bruk av hash algoritmen MD5. Genereringen av verdier på denne måten er en tidkrevende prosess, og det har derfor vært viktig for oss å finne en god løsning på denne delen av rammeverket. Av denne grunn bestemte vi oss for å bruke biblioteket FastMD5. Bruk av dette biblioteket har hatt en rekke fordeler for dette prosjektet. Den viktigste av disse er selvsagt den bruken av tid for beregning av hver checksum. Biblioteket er også svært enkel å benytte til vårt formål, der vi ønsker å lese inn en fil og få ut en heksadesimal verdi. På bibliotekets hjemmeside er det vist en oversikt og beskrivelse over de tidsmessige fordelene ved bruk av dette biblioteket, i forhold til de ulike JDK implementasjonene. Vi valgte derfor å teste en versjon som benytter seg av FastMD5 metoden, og en versjon som benytter seg av Javas security.messagedigest bibliotek. På denne måten kunne vi sikre oss at informasjonen stemte for vårt system. Denne informasjonen skulle vise seg å stemme. For en mer detaljert oversikt over de ulike hastighetene, refererer vi til FastMD5s hjemmeside. ( EXIF Når det gjelder implementasjonen av Exif biblioteket, var det svært viktig for oss å sikre at informasjonen som blir hentet ut fra bildene er i forventet format. For å teste dette har vi benyttet oss av forskjellige testcases, med tilfeldige bilder tatt med et stort antall forskjellige kameraer. Grunnen til dette er at Exif informasjon ikke nødvendigvis er konsekvent, og at Hovedprosjektrapport for Project Sunstone 49

50 wrapper klassen derfor må konvertere alle felter vi ønsker å foreta beregninger på til et konsekvent format. Dette har innebært store mengder analysering av input og output data fra ExifWrapper klassen. Ettersom denne klassen ble utviklet på et svært tidlig stadium av prosjektet, brukte vi også mye tid til å sette oss inn i Exif spesifikasjonene under testingen. Eksempler på hvordan slik data vil kunne se ut er beskrevet i vedlegg 6 om Exif informasjon. 4.4 Ferdig produkt Oppstart Ved oppstart vil programmet lage en database dersom denne ikke eksisterer. Exif informasjon vil så bli hentet ut av de aktuelle bildene. Miniatyrbilder blir laget for alle JPG bilder i den angitte mappen, samtidig som fullskala-bildene vil kunne bli lest igjennom av klassifikatorer. Ved en senere oppstart vil databasen lastes inn, samtidig som nye bilder vil gjennomgå innlastingprosessen som beskrevet tidligere. Dersom brukeren skulle finne på å slette en eller flere av de tidligere innleste dataene, vil disse bli lest inn på nytt ved systemets oppstart. Et unntak vil oppstå dersom brukeren sletter et fullskala bilde fra sin bildemappe. Dersom dette skjer, vil programmet isteden slette informasjonen om dette fra databasen og thumbnailfilen dersom denne eksisterer. Altså vil det opprettes en ny database dersom denne slettes, og nye miniatyrbilder dersom disse ikke blir funnet på systemet. Dette er testet ved gjentatt kjøring av systemet. Ved testing fant vi ut at miniatyrbilder ikke blir slettet dersom databasen blir slettet. Dette kan føre til en opphoping av bilder i sunstone_thumbnails for hver gang databasen slettes. Vi har valgt og ikke håndtere dette, fordi dette er et problem som kun vil oppstå dersom brukeren selv sletter databasen uten og samtidig slette miniatyrbilder. Videre vil dette ikke skape noen problemer for systemet bortsett fra en liten, men unødvendig sløsing av diskplass. Vi har utført en test der vi har kjørt det ferdige programmet som en jar fil, på en rekke forskjellige datamaskiner, med forskjellige operativsystemer. Operativsystemer vi har testet på er Windows XP 32 bit, Kubuntu bit, Ubuntu bit, og Vista 32 bit. Dette har blitt gjort på 8 forskjellige maskiner. Her fant vi ut at det kunne oppstå et problem ved bruk av JAI biblioteket. Dette viste seg da en av maskinene med Vista 32 bit ikke kunne generere miniatyrbilder. Grunnen til dette kan ha vært et feil oppsett av Java på den aktuelle maskinen, ettersom det også ble oppdaget at denne ikke hadde nok minne tilgjengelig til applikasjonen. Allikevel har vi valgt å implementere en løsning for dette problemet. Dette innebærer at brukeren utvider konfigurasjonsfilen med en linje, awt_thumbnails=true, som ber om å bruke AWT istedenfor JAI. Dersom det ved en feil ikke kan genereres miniatyrbilder, vil det istedet vises et standard bilde fra systemet GUI Størrelsen på vinduene kan justeres ved å flytte på skillelinjen mellom vinduene. Miniatyrbildevindu Hovedprosjektrapport for Project Sunstone 50

51 Hvis det er flere bilder enn det er plass til i synlig del av vinduet vil det kunne scrolles i bildene for enkel navigering i samlingen. Bilder som vises i dette vinduet kan klikkes på en gang for vise større versjon av dette. Bildevindu Her vises det valgt bilde fra miniatyrbildevinduet. Dette bildet kan også klikkes en gang på for å få opp en egen ramme med bildet. På denne måten kan brukeren få opp en versjon av bildet som fyller hele skjermen. Større bilde vindu I dette vinduet vises bildet som er valgt i en egen stor ramme. Vinduets størrelse kan justeres etter eget ønske ved å dra ytterkantene på rammen. Klassifikatorvindu Klassifikatorvinduet er brukerens kontrollpanel for bildesamlingen. Her kan brukeren trykke på ulike knapper og justere innstillinger for hver enkelt klassifikator. Resultatet av disse nye innstillingene vil øyeblikkelig vises for brukeren når et valg er foretatt. Menylinje Menylinjen befinner seg på toppen av hovedvinduet, som et horisontalt panel. Her vil brukeren kunne endre på filsti for bildesamlingen gjennom «File» knappen, skru av og på klassifikatorer gjennom «Edit» knappen, eller få hjelp og informasjon om programmet gjennom «Help» knappen. Disse er testet for ønsket funksjonalitet. Det er også testet at av og på status for hver enkelt klassifikator vil bli husket mellom hver oppstart Bak kulissene For å teste om rett informasjon har blitt trukket ut, eller lagret har vi brukt enkle kodelinjer der vi har følt behov for dette. Et eksempel på dette er: System.out.println("Scanned image, got: " + value); På denne måten har vi kunnet teste at Forventet data blir lagt inn og trekkes ut av databasen Exif informasjon blir formattert som forventet og videresendt til rett sted i rammeverket Klassifikatorer vil kunne justere visningen av miniatyrbilder, og at dette skjer på forventet måte. Testklassifikatorene gir forventede verdier til bilder ved skanning. Klassifikatorer med cycliske avhengigheter, eller manglende avhengigheter blir oppdaget og håndtert. 4.5 Testing av fastsatte krav De nummererte testene beskrevet under, refererer til de nummererte kravene definert i kravspesifikasjonen. Krav Testing 1 Under utvikling kunne vi sikre oss at GUI var utvidbart, ved å legge til nye vinduer og komponenter til disse etter hvert som milepæler for disse er nådd. Hovedprosjektrapport for Project Sunstone 51

52 2 Vi har undersøkt hvilke bilder som blir skannet i løpet av oppstartsprosessen. Dette vil selvsagt ikke gjelde for samlingsklassifikatorer som vil måtte skanne alle bilder på en gang. 3 Vi har testet dette ved bruk av programmet og undersøking av hvilke endringer som skjer i bildesamlingen når det gjøres valg i klassifikatorer. 4 Testet ved å legge til testklassifikatorer i angitt mappe, og bruke disse i programmet. 5 Vi har testet dette ved at den installerte klassifikatoren virker med en gang etter oppstartsprosessen. 6 Vi har testet dette ved å legge til, trekke fra og modifisere bilder i samlingen. 7 Siden det ikke skrives til annet en applikasjonens egne filer, er det eksplisitt gitt at brukerens filer ikke endres. 8 Ved bruk av systemet er det testet at filstien som defineres stemmer overens med visningen av mappenes innhold. 9 Vi har lagt testklassifikatorer til i den komprimerte.zip filen og sjekket at disse fungerer. 10 Vi har laget en samling bilder som kan brukes i systemet. Det er sjekket at disse innholder Exif informasjon som kan leses av systemet. 11 Progressbar vises i oppstartsprosessen og viser relevant informasjon til brukeren, slik at en kan se at systemet faktisk jobber til enhver tid. 12 Vi har forsøkt å avslutte programmet under oppstart og sett at programmet vil fortsette omtrent der det ble avbrutt. 13 Vi har ved gjennomgang av koden sjekket av hver del oppfyller de fastsatte kravene til kodestil 14 Programmet er lagt ut i form av kjørbar.exe fil for Windows plattformen, og som.zip fil for alle plattformer. 15 Vi har ikke hatt tid til å utføre brukertester for å sikre oss at programmet vil virke intuitivt for alle brukere, men vi har hele tiden hatt i tankene at GUI skal være robust, intuitivt og konsistent. Det er også implementert på en slik måte at brukeren ikke blir overlesset med informasjon fra applikasjonen, som for eksempel utskrift av metadata til skjerm. 16 Applikasjonen er forsøkt kjørt med Java SE 6 på en rekke forskjellige plattformer. 17 Det vil kun leses metadata fra filer som ender på JPEG eller JPG. 18 Vi har ved gjennomgang av prosjektrapporten fastslått at dokumentasjonsstandarden er fulgt. Hovedprosjektrapport for Project Sunstone 52

53 Brukermanual for Project Sunstone Et hovedprosjekt i data ved Høgskolen i Oslo, våren 2010 Martin Haukeli Jostein Haukeli Marit Olsen Hovedprosjektrapport for Project Sunstone 53

54 5.1 Forord Dette er en brukermanual som beskriver hvordan en kan benytte seg av funksjonaliteten applikasjonen Sunstone tilbyr, samt mulige løsninger på problemer som kan oppstå. Dokumentet er beregnet å kunne leses av brukere med minimale kunnskaper om datamaskiner. Hovedprosjektrapport for Project Sunstone 54

55 5.2 Innholdsfortegnelse BRUKERMANUAL FOR PROJECT SUNSTONE FORORD INNHOLDSFORTEGNELSE INNLEDNING INSTALLASJON Innstallering Legge til klassifikatorer BRUK AV SYSTEMET Oppstart Bildeklassifikatorer Klassifikatorutvikling FEIL OG RETTINGSMULIGHETER ORDLISTE Hovedprosjektrapport for Project Sunstone 55

56 5.3 Innledning Formålet med programmet er å gjøre det enklere å navigere frem til et antall bilder i en stor bildesamling. Dette blir gjort ved at en eller flere bildeklassifikatorer leser gjennom bildene. Disse bildeklassifikatorene kan benytte seg av Exif informasjonen som er lagret i JPEG filen, eller ved å analysere bildets innhold, som for eksempel farger og skygger. Klassifikatoren vil tildele hvert bilde en verdi som brukeren kan sortere på. Eksempel på en verdi som kan være nyttig å sortere på er den gjennomsnittlige lysintensiteten i bildet. Ved å sortere bilder basert på denne verdien, kan en finne frem til bilder som er lyse, mørke, eller ligger et sted mellom to gitte verdier. Videre kan denne informasjonen hjelpe til med å avsløre om bildet er tatt om dagen eller natten, om bildet er tatt innendørs eller utendørs, eller kanskje tatt i en sammenheng som for eksempel på en ferietur i utlandet. 5.4 Installasjon Installering Ved installering på Windows ved hjelp av installasjonsfil vil vi henvise til installasjonsfilen. Ved nedlasting av.zip fil vil brukeren måtte pakke ut filene i en valgt mappe. Deretter kan programmet kjøres ved å kjøre sunstone.jar Legge til klassifikatorer Systemet kan utvides med tredjeparts klassifikatorer. Bildeklassifikatoren som består av en klassefil kan ofte være komprimert og må derfor dekomprimeres først. For å installere en bildeklassifikator av type <klassifikatornavn>.class, må filen flyttes til mappen ved navn classifiers. Denne mappen vil være tilgjengelig der programmet er installert eller pakket ut. Når filen ligger i rett mappe kan programmet startes på nytt og bildene vil da automatisk bli skannet gjennom med den nye klassifikatoren. Dermed vil klassifikatoren vises i oversikten over installerte klassifikatorer og være klar til bruk. 5.5 Bruk av systemet Oppstart Når systemet startes for første gang vil det vises en dialogboks, der en vil bli bedt om å angi hvilken mappe som innholder brukerens bilder. For at alle klassifikatorer skal fungere på tiltenkt måte, bør den valgte mappen kun inneholde bilder tatt med ett og samme kamera. Samlingen bør også bestå av bildet tatt utendørs i dagslys. Hvis dette ikke er tilfellet vil enkelte klassifikatorer, som for eksempel de som bruker kameraets klokke i sine beregninger, ikke fungere slik de er ment. Det forventes også at bildene ikke er modifisert på en slik måte at Exif-informasjonen er ødelagt eller fjernet. Under oppstartsprosessen vil det også være synlig en fremdriftsindikator på skjermen. Denne vil kunne gi brukeren et inntrykk av hvor mye tid som gjenstår, og samtidig hva applikasjonen jobber med til enhver tid. Dersom en forsøker å lukke denne, vil en få opp en Hovedprosjektrapport for Project Sunstone 56

57 dialogboks som forklarer at dette vil avslutte programmet. Brukeren kan deretter velge å avslutte programmet eller fortsette innlastingen. Figur 5.8 Fremdriftsindikator Første gangen systemet startes vil det ta lengre tid enn etterfølgende oppstarter. Dette kommer av at all Exif-informasjonen skal trekkes ut fra hvert enkelt bilde. Deretter skal bildene skannes gjennom hver av de installerte bildeklassifikatorene. I løpet av oppstartsprosessen vil det også bli generert miniatyrbilder for visning i programmet. Hvor lang tid denne prosessen vil ta kommer an på hvor mange bilder som ligger i den valgte mappen og hvor mange bildeklassifikatorer som brukes. Når systemet startes på nytt ved en senere anledning, vil oppstartstiden være avhengig av hvor mange nye bilder som er lagt til i bildemappen. For hvert nye bilde som blir oppdaget, vil nødvendig uthenting av data bli utført som beskrevet ovenfor. Hvis det er lagt til en ny bildeklassifikator vil alle bildene i mappen skannes gjennom denne. Figur 5.2 Hovedvindu Photobrowseren fremstår som et hovedvindu som består av tre mindre vinduer. Et vindu viser alle valg en kan gjøre i forbindelse med bildeklassifikatorene. Et annet vindu viser alle miniatyrbilder, og det siste vinduet viser et valgt bilde i større format. Hovedprosjektrapport for Project Sunstone 57