Jag har visat ODM och WebODM tidigare här på bloggen, men nu har det kommit en uppdatering som förtjänar att uppmärksammas.
ODM är ”Open Drone Map” och WebODM är det grafiska gränssnittet via en servertjänst och en webbläsare. ODM/WebODM är byggt för att snabbt och enkelt läsa in bilder tagna med UAV och så automatiskt som möjligt beräkna dessa med fotogrammetriverktyg och skapa ortofoton, höjdraster, punktmoln, 3D modeller, etc…
Jag har en Docker container med WebODM på min bärbara workstation redo att startas med en programstartare i programmenyn.
Tyvärr fungerade inte ”update” kommandot för att uppdatera till nya version 0.4 så jag fick köra ”rebuild”. Detta skapade mängder av röda varningar i terminalen, men när allt var klart så var resultatet ”sucessfully built”.
Detta hjälpte dock inte så i slutändan så var det manuell uppdatering via ”git” och sedan fungerade ”update” utan problem.
sudo git fetch --all sudo git reset --hard origin/master sudo ./webodm.sh update sudo ./webodm.sh start
Sedan kan jag som vanligt peka webbläsaren på localhost port 8000.
Det är egentligen ingenting som tydligt indikerar att programmet är uppgraderat.
Något som däremot är nytt, är den nya menyn ”OpenAerialMap” som gör det möjligt att koppla upp WebODM mot denna tjänst. Annars är det tydligaste beviset på ny version att läsa innehållet i vissa filer i kodbiblioteket för att säkerställa att programmet faktiskt är uppdaterat. Kanske skulle finnas en text i gränssnittet som angav versionsnummer?
Är det då något som är bättre?
Jag provade att köra ett av mina tidigare projekt, som misslyckades tidigare.
Och japp, det gick! Det är ett ”skitprojekt” utan värde, men bara att det körde klart har viss betydelse.
Jag provar att köra bilder från ett projekt som jag använt för att testa mängder av fotogrammetriprogram, inklusive tidigare versioner av ODM.
Även detta går igenom med standardinställningarna utan några som helst problem.
När processen körs så noterar jag att ”PDAL” används för att göra en del beräkningar, vilket inte användes tidigare.
När jag jämför resultatet från ett tidigare projekt (där jag valt till DTM) så är det vissa skillnader i den nya versionen (till höger). Nu kan man få ortofotot i formatet MBTiles och punktmolnet är i komprimerat laz-format.
Den spontana känslan när resultatet visas i webbläsaren är ”Wow”. Det känns väldigt mycket bättre än tidigare! Det faktiska resultatet tittar jag närmare på lite senare, men integrationen i gränssnittet är riktigt bra. MBTiles laddas och visas väldigt snyggt och snabbt. Integration med OpenStreetMap gör att data direkt kan digitaliseras till OSM. Mätningar i längd, area och volym görs väldigt simpelt med några klick i kartan.
Skall jag vara ärlig så vet jag inte riktigt hur volymberäkningen är tänkt att fungera och i mitt exempel så finns ingen naturlig volym att mäta så ta 10’000 kubikmeter med en nypa salt.
Som tidigare så är det bara i punktmolnet som det går att göra mätningar och skapa etiketter med mera, och texturmodellen har en annan höjdreferens i programmet. När man växlar mellan punkter och texturmodell så får man zooma och panorera lite för att komma till rätt ställe.
Exporterade data i QGIS är också väldigt enkla att hantera. Men nu över till jämförelsen av data.
(Vänster ”gamla” ODM, mitten nya versionen av ODM, och som jämförelse AgiSoft Photoscan i en gammal version)
Det som är mest slående är begränsningen av ytans utsträckning. Detta gillar jag starkt. Det tar bort sämre inpassade områden, som jag ändå hade behövt klippa bort manuellt. Ytan är ändå betydligt större än flygområdet och i kanterna så syns det även i den nya versionen.
Samma ordning i 1:1 pixelskala ovan som tidigare. Nya ODM har närmat sig det kommersiella alternativet betydligt i resultat, vilket är väldigt tydligt om man tittar på det träd som syns till vänster i mitten av bilderna (ytterligare inzoomad bild nedan).
I ett annat inzoomat område så är förbättringarna också tydliga, men här är även en del kvarstående problem också tydliga.
Ett annat tidigare problem som rör vertikala ytor verkar också ha blivit betydligt bättre i nya ODM. Notera att det bara är i gamla ODM (till vänster nedan) som några fönster i huset är tydligt synliga. AgiSoft är fortfarande bättre på detta, men skillnaden är inte längre så uppenbar.
Mycket är som sagt rejält mycket bättre, men det är fortfarande en bit kvar till de kommersiella alternativen. I alla fall när det gäller kvalité i ortofoto.
När vi kommer till höjddata så hittar jag inte en gammal bild från ODM så här jämför jag endast nya ODM (vänster) med AgiSoft (höger).
Lite bättre upplösning i AgiSoft som det verkar, men överensstämmelsen är ändå väldigt god. Det som fortfarande verkar vara ett problem hänger ihop med vertikala ytor. Om det är ”större” höjdskillnader som ligger nära varandra så ser det ut som att ODM har lite svårt att separera dessa och tenderar att jämna ut ytorna. Nu är ju inte fyrkanten ovan speciellt stor. Bara 8 x 8 meter.
Upplösningen i ODM bilden är runt 5 centimeter och i AgiSoft runt 9 centimeter. Så även med högre upplösning i ODM så är det tydligt att upplösning inte är allt.
När det gäller upplösningen i ortofotot så gäller det omvända. Detta är möjligen en inställningsfråga och nu kommer jag inte ihåg om jag använde defaultinställningarna i AgiSoft och gamla ODM. Gamla ODM låg runt 9 centimeter och nya ODM på runt 5 centimeter, medan AgiSoft är på makalösa 2 centimeter.
Nu går det ju att skruva lite på parametrarna för ODM också. Exempelvis finns två lägen vid namn ”High Resolution” och ”High Quality”. Med ”hög upplösning” så genereras ortofoto med runt 2 centimeter, vilket är samma som i AgiSoft. Med ”hög kvalité” så genereras en höjdmodell med bättre upplösning, men med lägre upplösning i ortofotot. Alla detaljer går dock att justera med ett ”custom” läge. Det går därför att generera såväl hög kvalité som hög upplösning, men det kan ta väldigt lång tid och kräva mycket resurser av datorn.
Om jag väljer hög kvalité och sedan ändrar ortofotoupplösningen till 2.5 centimeter, samt ändrar ”min-num-features” från 8’000 till 32’000 så får jag följande resultat (jämför med tidigare bilder).
Till synes inte någon större skillnad mot tidigare, förutom den högre upplösningen…
Jag kör därför ännu en gång med lite mer anpassade inställningar för dels typen av terräng och de brister jag hittar i bilderna.
Och dra på… det blev ju ganska bra.
Väldigt många av de vertikala problemen försvann med dessa inställningar, men det blev inte helt perfekt. AgiSoft är fortfarande lite bättre generellt, men mina experiment bevisar att om man lägger på lite erfarenhet, eller som i det här fallet experimenterande, så kan ODM och WebODM konkurrera fullt ut med kommersiella alternativ.
Det blir snarare tillämpningen och ”features” som avgör om WebODM eller ett kommersiellt alternativ är att föredra. WebODM är en suverän lösning för många användare i ett gemensamt nätverk, samt för alla som föredrar Open Source. AgiSoft erbjuder exempelvis exportmöjligheter till 3D-PDF och de inbyggda funktionerna för vektorisering med export till shape. WebODM kan exportera vektorer till JSON och DXF, men då handlar det bara om enstaka objekt.
WebODM version 0.4 är så bra att det utan tvekan kan användas i produktionssammanhang. Jag kan inte lova att alla typer av terräng fungerar lika bra som det som jag provat, och man får vara beredd på att prova en del inställningar för ett optimalt resultat. Men jag ser inte längre att man behöver ha dåligt samvete för att man inte använder kommersiella lösningar för tiotusentals kronor per licens för att framställa ortofoton, höjddata eller punktmoln från UAV bilder.