eevalaiho/focusstacking

TKT20010 Aineopintojen harjoitustyö: Tietorakenteet ja algoritmit (alkukesä), Helsingin yliopisto

Aineopintojen harjoitustyö: Tietorakenteet ja algoritmit (alkukesä 2019)

Eeva-Maria Laiho

Aihe: Focus stacking -algoritmi

Focus stacking -algoritmi on digitaalinen kuvankäsittelymenetelmä, minkä avulla useasta samasta kohteesta otetusta valokuvasta voidaan luoda yksi mahdollisimman tarkka kuva. Alkuperäisistä valokuvista erotetaan mahdollisimman tarkat kohdat ja kootaan ne uudeksi kuvaksi.

Viikkoraportit

• Viikko 1: Viikkoraportti 1 (11.5.2019)

• Viikko 2: Viikkoraportti 2 (17.5.2019)

• Viikko 3: Viikkoraportti 3 (24.5.2019)

• Viikko 4: Viikkoraportti 4 (31.5.2019)

• Viikko 5: Viikkoraportti 5 (7.6.2019)

• Viikko 6: Viikkoraportti 6 (14.6.2019)

• Viikko 7: Viikkoraportti 7 (20.6.2019)

Dokumentaatio

Määrittely

Toteutus

Testaus

Käyttöohje

focusstacking's Issues

code review

Latasin projektin 14.6.2019 n klo 19.30

1. Testasin ajaa projekti Netbeansin kautta

• Pääluokka antoi NullPuinterExceptionin.

2. Luin dokumentaation

• Olit laittanut kivasti linkkejä. Voisitko lisätä yhden vielä XX valmiskirjastoon, koska se mainittiin monta kertaa ja nimi ei hirveästi kerro niin linkki voisi olla paikallaan.
• Olit analysoinut perusteellisesti aika-ja tilavaativuudet. Huomasin, että olit merkannut esim. tarkimpien kuvapisteiden valintaan O(k * n * 3n). Muistelen tirasta, että esitystapa olisi ihan vaan O(kn).
• Yleisesti ottaen dokumentaatio näyttää olevan jo hyvällä mallilla.

3. Tsekkasin testit

• Testit menee läpi
• Valitettaasti gradle ei ole ennestään tuttu niin en lähtenyt selvittelemään miten saan ajettua testikattavuuden.
• Hienoa, että olit laittanut testeihin myös poikkeustilanteet, esim. IndexOutOfBoundsException.

4. Luin koodin läpi

• Oli vähän vaikea saada pakkausrakenteesta kiinni ja siitä mitä mikin yksittäinen luokka tekee. Voi johtua osittain siitä, että aihe oli vieras.
• Ehdottaisin, että laitat kovakoodatut numerot pääsääntöisesti muuttujaan, näin koodia on helpompi lukea ja muuttaa tarvittaessa. Esim. FocusTracking-luokan rivillä 33. Ja util-luokassa rivillä 65, eikö table[i] ajaisi saman asian?
• Mietin oliko sinulla, joku syy laittaa slidingwindow-luokan metodeissa Array parametriksi. Lähinnä ajattelin olisiko helpompi käyttää jos laittaisi globaaliksi muuttujaksi?
• Ymmärsinköhän oikein, että Util-luokassa riveillä 39-55 olisi loogisempaa nimetä height ja weight toisinpäin.
• Pitäisikö MyArrayListiin tehdä oma toteutus riville 101 eli ArrayCopy-metodiin?

5. Katsoin javadocin läpi

• MyArrayList-luokassa olet varmaan muuttanut set-metodia kun dokumentaatio on vanhentunut

Mielenkiintoinen aihe ja kiva, että näytit demossa ohjelman toimintaa.

Vertaisarviointi

Projekti ladattu: 5.6. klo 21

Algoritmin suoritus onnistui, ja se tuotti esimerkkikuvista selvästi tarkemman version. Se, miten tarkan kuvan algoritmi tuottaa, riippuu kuitenkin kuvan sisältämistä väreistä sillä algoritmi huomioi ainoastaan vihreän värikanavan.

Ohjelman logiikkaa oli suurimmaksi osaksi helppo ymmärtää, mutta siitä saisi vielä selkeämmän jakamalla koodiin pienimpiin metodeihin ja luokkiin. Esimerkiksi FocusStacking-luokan Stack-metodin voisi pilkkoa pienempiin osiin. Lisäksi jäi hieman epäselväksi, mitä osia algoritmista on vielä toteuttamatta koska sen kulku oli erilainen kuin Toteutus-dokumentin kulkukaaviossa ja projekti sisälsi poiskommentoitua koodia. Esimerkiksi ylipäästösuodatusta en löytänyt projektista.

MyArrayList-luokan käyttöä voisi optimoida lisäämällä konstruktorin, jolla voi asettaa luokan sisäisen taulukon alkukapasiteetin. Alustamalla taulukon koon oikeaksi vältytään datan kopioimiselta uudelleen aina kun taulukon kokoa pitää kasvattaa. Taulukon haluttu koko on tiedossa jo etukäteen, sillä se riippuu kuvan koosta, minkä ansiosta MyArrayList-luokan voisi luultavasti myös korvata Javan omalla taulukolla.

Yksi mahdollinen koodiparannus olisi käyttää MyArrayList-luokan sisäisessä taulukossa geneeristä luokkaa E Object-luokan sijaan jolloin vältyttäisiin tyyppimuunnoksilta (cast). FFT-luokan fft-metodissa käytettiin Javan omia Math.cos ja Math.sin metodeja. Kuuluisiko nämä korvata omilla implementaatiolla? Jos Math-kirjaston käyttö on sallittua, ei luultavasti muitakaan apumetodeja (sqrt, abs, hypot) tarvitsisi toteuttaa itse.

Koodia oli melko helppo ymmärtää, mutta sen luettavuutta voisi vielä parantaa kiinnittämällä enemmän huomiota metodien nimiin. Jos nimet ovat tarpeeksi kuvaavia, on myös kommenttien tarve pienempi. Esimerkiksi kohdasta

 // Compute FFT
 Complex[][] fft = FFT.fft2(window);

voisi tehdä hieman selkeämmän vaikka seuraavasti:

 Complex[][] fft = FFT.compute2dFft(window);

Jos koodia haluaa hioa, voi siihen tehdä pieniä tyyliparannuksia. Esimerkiksi joidenkin metodien nimet alkoivat isolla kirjaimella.

Projektin testikattavuus oli yksinkertaisempien luokkien osalta melko hyvä, mutta esimerkiksi FocusStacking-luokan logiikka oli vielä testaamatta. Koska Stack-metodi sekä lataa kuvat, käsittelee ne että lopussa tallentaa uuden kuvan, sen testaaminen on haastavaa. Myös tästä syystä koodi kannattaisi jakaa pienempiin metodeihin ja useampiin luokkiin.