Det var ett litet tag sedan senaste WebODM testet, och då version 1.9.11 nyligen släppts så tyckte jag att det var läge för ett återbesök för att se om jag kan identifiera något uppenbart nytt sedan förra gången jag använde programmet. Nu har jag faktiskt inte helt klart för mig när detta var, men jag tror att jag i alla fall testat 1.9 tidigare…
Uppdateringen via Docker var lite mer omfattande än en enkel uppdatering, men det kan bero på hur jag använt systemet. Jag var först tvungen att köra git stash för att sedan göra en –update med webodm-skriptet. När detta väl kört klart så kunde 1.9.11 verifieras i gränssnittet.
Då jag nyligen haft vägarna förbi Enköping och passade på att fotografera Vårfrukyrkan runtom med en GoPro, så använder jag dessa bilder för testet.
Det är 168 bilder taget handhållet runt om själva kyrkan med kameran inställd på 2 sekunders intervall. Med andra ord tog insamlingen av data runt 6 minuter, vilket då skall läggas till beräkningstiden på den ultralätta laptop jag kör beräkningen på. Tiden är med andra ord inte helt relevant, då denna typ av arbetsflöden, om det är en vanlig uppgift, kanske körs på något kraftfullare system.
Processen är sig lik från tidigare. Skapa projekt, lägg till bilder, ange ett namn och välj typ av projekt eller ställ in detaljer i inställningarna manuellt. Jag väljer ”Buildings” som snabbval, men ändrar linstyp från Auto till Fisheye, då jag haft bättre framgång med den inställningen för GoPro med ”Wide” inställning.
Förhållanden på platsen var inte helt optimala, men bör vara hanterbara för programmet. Några ortofoton eller höjdmodeller är jag inte intresserad av i det här fallet, utan det är punktmoln och 3D modeller som är av störst intresse. Beräkningen tog ändå lite tid, men det är framför allt den minimala arbetsinsatsen som skall vägas mot resultatet.
Och blev det något resultat då?
Jodå, efter en knapp timme så var beräkningen klar. En av nyheterna är att det går att välja format när man hämtar exempelvis ortofoto.
Nu hade jag inga som helst förväntningar på att det skulle bli ett bra ortofoto av dessa bilder, men jag testade ändå att ladda ner en JPEG bild och öppna den i QGIS.
Det visade sig att mina bilder var just bilder, utan georeferens. När jag läste in GeoTIFF bilden så hamnade den på rätt plats, men något verkar uppenbart vara fel (bilden ovan). I det här läget misstänker jag GPS onoggrannhet i bilderna, så jag är lite nyfiken på rapporten.
Och visst är här ett problem. Det är inte säkert det är GPS positionerna i kameran som är helt fel, utan något i beräkningen har gjort att programmet börjat placera bilder på ett visst sätt och detta sedan genererat detta stora GPS fel i modellen. Jag har varit med om liknande tidigare där enstaka byggnader fotograferats och där resultatet visat sig vara ”upp och ned” i 3D vyn.
Och så var fallet även här. Ett väldigt detaljerat punktmoln, men upp och ner, samt i felaktig skala. Jag läser dock in punktmolnet i CloudCompare för att städa det något och räta upp orienteringen, så att resultatet kan granskas lite bättre.
Det ser inte alls dåligt ut om man bortser från punkternas felaktiga geografiska position (och skala). Visst, en del tak är borta, men det var väntat med den här typen av bilder.
Om man var lite förutseende när man fotograferade så passade man på att ta ett mått på någon tydlig del av objektet (det gjorde inte jag) som kunde användas för att skala om punktmolnet. I mitt fall mätte jag i ett ortofoto och anpassade skalan efter detta så att det i alla fall blev rimliga värden i punktmolnet vid mätning.
På samma sätt kan jag sannolikt ”rädda” även dessa bilder genom att i stället för att förlita mig på GPS information ta ut GCP (referenspunkter på marken) från ortofotot för exempelvis några hörn på kyrkan och markera dessa i WebODM.
Och mycket riktigt. Några utvalda bilder och några tydliga punkter som gick att härleda geografiskt gjorde att en ny beräkning med GCP-fil faktiskt rättade till alla problem.
Det går direkt i WebODM att ”skära” punktmolnet ortografiskt och markera ytterväggar direkt som måttlinjer. Dessa linjer kan exporteras som DXF och öppnas i exempelvis QGIS. Nu lyckades jag inte med just det här, eftersom Firefox behagade krascha gång på gång när WebODM kördes. Det gick bra att klicka ut några punkter i en polygon, men rätt som det var, krasch! Nåja, över lag så tycker jag att programmet fungerar utmärkt, och jag kan alltid fortsätta i QGIS eller CloudCompare.
Att dynamiskt kunna välja vilka format som skall användas när data laddas ner är en bra nyhet i WebODM. Jag är inte 100% säker att det fungerade som det skall för mig den här gången, då det inte laddades ner några *.jgw eller *.pgw filer för georeferens av bilderna, men det kanske inte heller är syftet med dessa typer av bilder. Även punktmolnet gick att ladda ner i olika format. Såväl LAS som LAZ, men även PLY och CSV går att välja dynamiskt. För texturerade modeller är det dock fortfarande en ZIP med inkluderade texturfiler som gäller. Både punktmoln och ortofoton kan även hämtas i valbar projektion. Tidigare så var det alltid den aktuella UTM zonen som gällde, men nu kan man ange valfri EPSG kod eller någon av förvalen i stället.
På ytan är det i övrigt inte mycket som märks som revolutionerande nyheter. Men trots mitt misstag med GPS positionerna i bilderna, så hade jag faktiskt inte förväntat mig ett så här bra resultat i punktmolnet. Det har fungerat förvånansvärt bra att filtrera bort ”spökpunkter” som brukar dyka upp exempelvis runt träd i himmeln. Det har heller inte blivit några ”dubbla” punktmoln med överlappande punkter som inte riktigt kopplats samman. Det känns som att det skett ganska mycket bakom gränssnittet i programmet.
Nu skall jag bara få lite tid över att flyga lite så att jag även kan testa den typ av bilder som programmet framför allt är byggt för.