Kort oppsummert s? er et bilde egentlig bare en samling av dotter jevnt fordelt utover en flate, der hver dott har blitt gitt en spesifikk farge. Alle disse enkelt dottene p? overflaten vil s? danne et bilde n?r det blir mange nok av dem. Hver av dottene er det vi kaller for en piksel, og er det man bruker for ? definere st?rrelsen p? et bilde. S? n?r man sier at man har et bilde p? 64x64 piksler s? betyr det at bildet inneholder 64x64 dotter med hver sin farge. Rent teknisk s? er dottene kvadratiske og vil fylle ut et kvadrat med bare den designerte fargen for den pikselen.
Det neste som burde komme opp som et sp?rsm?l burde v?re hva det er som bestemmer hvilken farge hver piksel skal ha, og hvordan disse blir justert for ? skape alle fargene man trenger til et hvilket som helst bilde. Bilder bruker i stor grad tiln?rmet system som det digitale skjermer bruker, eneste forskjellen er at farger oppf?rer seg forskjellig fra lys til farger p? en overflate som maling. Ta for eksempel en TV, hvis du g?r n?rme nok skjermen, "NB! ikke anbefalt ? gj?re det", s? vil du kunne se at bilde p? skjermen egentlig bare er en samling av sm? lys av fargen r?dt, gr?nt og bl?tt. Disse sitter s? tett p? hverandre i et repeterende m?nster og vil til sammen danne bilde som du ser p? skjermen, ved ? justere styrken p? hvert eneste av disse sm? r?de, gr?nne og bl? lysene. Det samme skjer i et bilde bare med fargekoder, for hver eneste piksel i et digitalt bilde vil inneholde tre verdier, (R, G, B) som st?r for red, green, blue. Disse verdiene g?r fra 0 til 255, og kombinasjonen av verdiene fra de tre ulike fargene vil bestemme hvilken farge den gitte pikselen har. Ta for eksempel at alle har verdien 0, det betyr at pikselen blir svart, og hvis alle har 255, s? blir det hvitt.
Vi vil her kun forholde oss til et filformat som heter png, og fargekodene vil v?re (R, G, B), det finnes nemlig andre m?ter ? oppgi farger som data som vi ikke vil g? n?rmere inn p?, vi er fysikere v?r kunst er ikke innenfor fargeteori. Kan du tenke deg hvorfor dette var viktig ? f? frem?
For ? oppsummere kort.
Et bilde kan bli sett p? som en annen m?te ? lagre data p?, det er bare strukturert p? en annen m?te enn det vi er vant til ? se. Hver piksel inneholder tre verdier (R, G, B) som betyr at man i praksis kan tenke p? dottene i bildet ovenfor som en slags tabell med verdier i hver av dottene.
Fra simuleringen av partikkelboksen s? nevnte vi array, en slags tabellform, som er det verdiene her vil v?re lagret i. Ved ? lage et program som kan lese av denne array'en kan vi n? hente ut denne dataen som betyr at bilder kan bli tatt i bruk som et verkt?y. Da er det bare ? sette i gang med ? eksperimentere med png formatet, det er bare en liten ting til som vi m? innom f?r vi kan g? l?s p? bildene, nemlig noe som heter stereografisk projeksjon.
En av v?re antagelser er at bildene vi tar er fra himmelen rundt oss, det vil si en kule med oss et sted i sentrum. Denne kulen med horisonten, bakgrunnen, vil vi kalle for himmelkulen. Det er nemlig et ganske problematisk geometrisk problem vi n? st?r ovenfor, som kartografer har vridd hodene sine rundt siden man ble enige om at jorden var rund. Hvordan representerer man noe som ligger p? overflaten til en kule i et 2 dimensjonalt plan samtidig som man beholder den opprinnelige formen og st?rrelsen?
Essensen i problemet kan i stor grad bli oppsummert via et lite eksempel. Se for deg at du har en appelsin, la oss si at du har en tegning eller figur p? dette skallet. En dag blir du lei av ? m?tte snu p? hele appelsinen hver gang du skal beundre mesterverket ditt, s? du bestemmer deg for ? ta av skallet og legge det flatt p? et bord med lik form som et rektangel. Resultatet du f?r burde likne litt slik som det er vist i neste bilde.
Man kan ogs? tenke p? det som ? skulle f? en badeball til ? ligge helt flatt n?r den ikke har noe luft i seg. Det man ender opp med er at den alltid vil ha noe krumming.
I v?r projeksjon vil vi overf?re bildet fra himmelkulen over til en flat overflate ved ? ha et punk, der v?rt kamera vil v?re, som vil ta et utsnitt av kulen, der st?rrelsen av utsnittet blir bestemt av kameraets FOV, field of view. Se for deg at vi sender et gitt antall str?ler innenfor v?rt FOV, disse vil s? treffe overflaten p? kulen, og vi vil hente ut verdiene som den pikselen en gitt str?le treffer, og plassere en ny piksel med samme verdi som den pikselen p? kulen hadde for den gitte str?len, p? en flat overflate bak. Denne overflaten vil st? normalt for overflaten fra en str?le som g?r fra sentrum av v?r FOV til himmelkulen.
Dersom du er interessert i ? vite mer s? kan vi anbefale ? se 3Blue1Brown sin video om But why is a sphere's surface area four times its shadow? Det som er mest relevant for dette er rundt 3 minutter merket.
Vi vil n? gj?re noe som kalles for koordinattransformasjon som vil si at vi bytter om p? type koordinatsystem som blir brukt. I v?rt tilfelle s? g?r vi fra et sf?risk koordinatsystem til et kartesisk koordinatsystem, der kartesisk er det vanlige koordinatsystemet man er vant til ? bruke.
Fra tidligere innlegg vet vi at min/maks verdier for x og y er gitt som
\(X_{max/min} = \pm \frac{2\sin{\left(\frac{\alpha_{\phi}}{2}\right)}}{1+ \cos{ \left(\frac{\alpha_{\phi}}{2}\right)}}\\ Y_{max/min} = \pm \frac{2\sin{\left(\frac{\alpha_{\theta}}{2}\right)}}{1+ \cos{ \left(\frac{\alpha_{\theta}}{2}\right)}}\) der \(-\frac{\alpha_{\phi}}{2} \leq?\phi - \phi_0 \leq?\frac{\alpha_{\phi}}{2}?\\ -\frac{\alpha_{\theta}}{2} \leq?\theta - \theta_0 \leq?\frac{\alpha_{\theta}}{2}\)
og \(\alpha_{\phi} = \phi_{max}-\phi_{min}? \\ \alpha_{\theta} = \theta_{max}-\theta_{min}\)
Heldigvis for oss s? trenger vi ikke ? tenke s? mye over de to siste delene, for vi vet, f?r oppgitt, at \(\alpha_{\theta} = \alpha_{\phi} = 70^o \) som gir oss at \(X_{max/min} = Y_{max/min} = \pm 0.63\), vi vet ogs? at \(\theta_0 = 90^o \) og at \(\phi_0 = 0^o\). X og Y max/min sier oss hvilke verdier p? overflaten vi prosjekterer over vil ha.
Videre har vi ogs? den f?lgende forholdet som kommer fra transformasjonen
\(\theta = \theta_0 - \arcsin{\left[\cos{\beta}\cos{\theta_0}+\frac{Y}{p}\sin{\beta}\sin{\theta_0}\right]}\\ \phi = \phi_0 + \arctan{\left[\frac{X\sin{\beta}}{p\sin{\theta_0}\cos{\beta}-Y\cos{\theta_0}\sin{\beta}}\right]}\\ p = \sqrt{X^2+Y^2}\\ \beta = 2\arctan(\frac{p}{2}) \)
som gir oss den korresponderende vinkelen som et punkt p? himmelkulen har gitt X og Y. Det vil si at vi kan ta et punkt innenfor v?re \(X_{max/min} \) og \(Y_{max/min}\) verdier og f? ut hvor p? himmelkulen dette ville ha v?rt.
kort oppsummert
Vi vil lage et bilde ved ? gj?re en koordinattransformasjon fra sf?risk koordinatsystem som er himmelkulen, og overf?re pikslene derifra ned p? et kartesisk koordinatsystem i xy planet. Ved ? bruke oppgitte forhold kan vi f? ut posisjonen til en piksel gjennom ? vite hvor p? himmelkulen vi ser p?, og posisjonen i v?rt xy plan gjennom x og y verdiene. Alt vi trenger ? gj?re blir da ? overf?re verdien til den gitte pikselen fra himmelkulen over til de x og y verdiene vi brukte. Ved ? gj?re dette p? en systematisk m?te vil vi til slutt f? et bilde som da er resultatet etter en stereografisk projeksjon.
Da har vi det vi trenger for ? utf?re v?r projeksjon, vi starter med ? hente ut v?rt referansebilde for ? vite hvilke dimensjon, st?rrelse, det er i. Dette gj?res ved ? importere bildet inn til python for s? ? lese av formen p? array'en som alle piksel verdiene er lagret i, fra dette finner man ut at bildet har en st?rrelse p? 640x480 piksler. En annen metode man kunne ha brukt er via paint og telle pikslene manuelt, men det er tungvint.
Deretter finner vi \(X_{max/min} = Y_{max/min} = \pm 0.63 \) som vi gjorde ovenfor, og det vi bruker dette til er ? lage et slags rutenett som en slags oppdeling. Oppdelingen blir da 640 ruter for bredden og 480 ruter for h?yden, for dette er da plasseringene for hver piksel vi skal bruke. Vi vet koordinatene allerede, for dette er plasseringen til hver av boksene i xy planet, og med det s? legger vi inn formlene ovenfor og setter inn hver x og y verdi fra rutenettet. Det vi f?r er at x og y verdiene byttes ut med \(\theta \) og \(\phi\) som korresponderer til den gitte x og y verdien. Dette bruker vi igjen ved ? hente ut verdien som en gitt piksel har for en gitt \(\theta \) og \(\phi\) fra himmelkulen. Sluttresultatet er at v?rt tomme rutenett n? inneholder (R, G, B) verdien fra himmelkulen i sine korresponderende posisjoner.
Vi ble ogs? n?dt til ? flippe det fra h?yre til venstre for s? ? rotere det \(180^o\) p? grunn av at det ikke var riktig rotert fra uthenting av verdiene. Et bilde er s? og si det samme bilde s? lenge man ikke endrer p? hva verdiene er i forhold til pikslene rundt, s? man kan rotere, og speile det om uten at det har noe ? si.
Panorama?
For videre referanser vil det v?re nyttig ? ha et bilde for hver hele vinkel \(\phi\) som dekker \(360^o\). Det vil si at vi gj?r en hel rotasjon og tar et bilde for hver hele vinkel, dette kunne vi ha gjort manuelt, men det er tungvint, s? vi lagde heller en liten modul som gjorde det for oss. Lagde ogs? en egen kode-del som lagde filnavnene for oss slik at vi slapp ? skrive panorama0000.png helt til panorama0359.png manuelt. Tallet som kommer etter panorama indikerer hva vinkelen \(\phi\) er for det gitte bilde, s? panorama0000.png vil ha en vinkel \(\phi = 0^o\).
Litt mer avansert konsept for smak og behag
Selv om vi lager bildene automatisk uten at vi trenger ? skrive filnavnene manuelt s? tar det fremdeles, relativt, lang tid ? lage alle bildene. Vi valgte derfor ? tilpasse koden slik at den kunne gj?re noe som kalles for parallellisering av prosessen. Parallellisering er n?r vi f?r en kode til ? gj?re flere ting p? en gang, og det er ulike former for parallellisering, men vi brukte en av de enklere metodene, som er multiprosessing.
En pc har noe vi kaller for prosessor kjerner og antallet varierer fra pc til pc. Under vanlige omstendigheter vil en kode bare bruke en av disse kjernene n? den kj?res, mens de andre ikke blir brukt. Multiprosessing er egentlig at vi bruker av flere av disse kjernene n?r koden kj?res, dette vil da dele p? arbeidsmengden som hver kjerne m? gj?re, og dermed redusere tiden.
For ? visualisere dette kan du tenke deg at du jobber i en butikk og at du sitter bak kasseapparatet. Det er bare du som tar i mot kunder akkurat n?, s? k?en med kunder vil da bli lang, fordi vi antar at butikken har mange kunder. La oss si at det tar deg 10 minutter p? ? gj?re deg ferdig med alle kundene, som blir da tiden det tar ? kj?re en kode. Neste dag s? har du en medarbeider, som er like effektiv som deg, og med like mange kunder som dagen f?r vil k?en bli fordelt p? to. Tiden det n? tar ? bli ferdig med alle kundene blir totalt 5 minutter.
I eksempelet blir da en kjerne deg som tar imot kunder, og kundene representerer arbeidsmengden som m? gj?res. Multiprosessing er dermed en metode som kan gj?re koden raskere ved ? dele opp arbeidsmengden p? flere kjerner. Det er selvf?lgelig mer detaljer bak det hele som at det som gj?res m? v?re uavhengig av hverandre, og at alt m? samles f?r man kan fortsette videre i koden, men det er ting som vi ikke trenger ? g? i detalj for n?.
Tanken bak ? skulle g? gjennom bryet med ? gj?re det mulig ? bruke flere kjerner samtidig for ? lage alle de 360 bildene var at det skulle g? raskere ? lage dem dersom vi m?tte endre p? noe, som for eksempel st?rrelsen eller endre p? noen av vinklene. Under er det en video som viser resultatet etter at bildene har blitt satt sammen.
Forrige innlegg finner du her
Neste finner du her