đČ â mikrobloggeriet jals â jals-6 · jals-7 · jals-8
Jeg jobber nÄ med refactorering (igjen). MÄlet er Ä fjerne kompleksitet og Þke fleksibilitet i en flyt. Denne flyten kan beskrives som: hvordan lese et satellittbilde for:
Bildene er veldig store, og passer ikke i minnet (âCPU-â eller GPU-minne), sĂ„ vi chunker opp bildet i mindre vinduer. Kan sammenlignes med convolution, âbare ett lag utâ.
Se for dere at proposjonene er 10.000 x 10.000 for satellittbilde (blĂ„ rute) og 512 X 512 for hver chunk (vindu vi laster inn i minnet om gangen). Som i gifâen vil vi ogsĂ„ la hver chunk overlappe med den forrige med feks. 50 pixler.
Jeg fant et relativt nytt bibliotek TorchGeo som kan erstatte mye av den kompliserte koden. Denne har vi en del krav til for at den skal kunne stÞtte vÄr bruk.
Jeg gjorde noe de-risking ved Ä én-til-én teste med den eksisterende koden og fant fort ut at den kom til kort pÄ ett punkt. Den kan ikke lese bilder direkte fra en cloud bucket, slik som vÄr kode kan.
Her har heller ikke kildekoden lagt opp til at man kan tweake den sÄ
lett. Jeg mÄ override hele init
-metoden kun for Ă„ fjerne en
sjekk pÄ om filen eksisterer. Selve lese-metoden klarer fint Ä lese fra
bucket, men sjekken gjĂžr ikke.
Da har jeg to alternativer:
init
I nummer 1. vil jo min implementasjon overskrive resten av logikken i
init
for alltid, og fremtidige oppdateringer i kildekoden
gÄr tapt.
Det riktige er helt sikkert nummer 2. med en fiks som lÞser problemet for alle andre brukere av bibliotek. Men det tar tid, og jeg mÄ gjÞre det skikkelig og sette meg inn i nye ting jeg ikke kan. Samtidig sÄ har jeg jo en stor gjeld til open-source-miljÞet. Samtidig har jeg ikke fÄtt de-risket biblioteket fullt ut enda. Jeg tror jeg mÄ gÄ for 2 likevel, mÄ jeg ikke?