Jag har en mängd flygfoton som är sparade i JP2 (jpeg2000), vilket är en effektiv komprimeringsmetod som inte är lika förstörande som vanlig JPEG. Formatet använder en wavelet komprimering men i övrigt hanterar man formatet på samma sätt som JPEG med GDAL.
Tyvärr så hittar jag inte JP2000 som alternativ när man exporterar ett rasterlager från QGIS, men det går att använda ”Translate” som man hittar i rastermenyn.
Jag kommer dock att använda GDAL direkt som kommando, vilket du kan se exempel på i rutan nertill i bilden ovan. Det dialogrutan gör är att helt enkelt göra om vanliga formulärval till ett GDAL kommando.
Jag använder ett litet utsnitt från ett ortofoto som jag dessutom sparat som okomprimerad GeoTiff, för att titta på kompressionsgrader för olika inställningar.
gdal_translate ortofoto.tif ortofoto.jp2
Kommandot ovan använder defaultinställningar för konvertering till ”OpenJpeg2000”. Detta innebär kvalité på 25 (1-100).
GeoTiff var 548 MB och JP2 filen blev 88 MB (16%). Detta är en signifikant vinst, utan att bilden är märkbart påverkad.
Det går dock att komprimera lite mer än standard…
gdal_translate -co QUALITY=10 ortofoto.tif ortofoto_10.jp2
Detta skapar en JP2 som är 54 MB (10%) och bilden är fortfarande inte märkbart sämre än originalet.
För att jämföra än mera så testar jag även QUALITY=5, vilket ger en märkbar förändring i resultatet, men storleken är bara 27 MB (5%).
Vid en första anblick så är skillnaderna obetydliga, men det blir tydligare om man kan tända och släcka lager samtidigt som man kan panorera och zooma i ett GIS. Hur som helst, om man är intresserad av att få ner filstorlekar så mycket som möjligt utan att bildkvalitén försämras allt för påtagligt, så är JP2 ett högst tänkbart alternativ.
Men vänta nu. Var inte originalbilderna i JPEG 2000? Jo det var de, och då kommer vi till problemet jag upplever med dessa bilder i QGIS. Det är stora filer och de är väldigt långsamma att hantera, speciellt om man vill visa många filer samtidigt. Visst, det går att bygga pyramider, men då bygger man ytterligare på ett annat problem nämligen att det är många filer samtidigt. Dessutom så blir pyramidfilen gigantisk i jämförelse med JP2 filen. I fallet med 5% komprimering där filen var 27 MB blev ovr-filen 252 MB. Om man använder Erdas RRD i stället blir aux-filen 186 MB, vilket inte heller är speciellt lite.
I stället så kan man tänka sig att använda Raster Tiles. Vilket görs automatiskt om man sparar raster i GeoPackage. Då kan man däremot inte använda Jpeg2000 utan är begränsad till vanlig JPEG för lite ”hårdare” komprimering.
JPEG är mer förstörande än Jpeg2000 så här får vi hålla oss runt standard 75 i QUALITY inställningarna för att ha motsvarande resultat som med Jpeg2000.
Jag testar att generera 50, 75 och 85 i QUALITY i ett och samma GeoPackage, men jag börjar med en på 100 för att inte räkna med det lilla overhead som genereras i formatet i sig. Det kan även vara en del i jämförelsen med ett ”okomprimerat” format som TIFF (även om det är komprimerat).
| Jpeg | Storlek | % av GTIFF |
| Q100 | 116 MB | 21 % |
| Q85 | 40 MB | 7,3 % |
| Q75 | 31 MB | 5,6 % |
| Q50 | 22 MB | 4,0 % |
Jämfört med storleken på Jpeg2000 där kvalité ”5” var den som tydligast var märkbart komprimerad, och som hade en filstorlek på 27 MB, så hamnar vi inom intervallen ovan. Med Jpeg2000 kvalité 10, som var 54 MB så ligger detta lite över Q85 för Jpeg. Om Jpeg Q85 är i närheten av hur Jpeg2000 Q10 såg ut, så kan vi vara något på spåren…
Det syns inte lika tydligt i bilderna här, men Q75 som är standard för JPEG-komprimeringen i GeoPackage har tydliga artefakter, speciellt när man zoomar in förbi 1:1 i pixelförhållande. Med Q50 blir det ännu tydligare. Med Q85 så går det att hitta skillnader mot Q100, men framför allt lite mera utzoomat så är detta i praktiken mycket svårt att se. Jämför man GPKG/JPG Q85 med JP2 Q5, så är JP2 ”snällare” i avvikelserna och behagligare att titta på, vilket man delvis kan kompensera för med omsampling i stilinställningarna. För normalanvändning så är det däremot mycket svårt att se uppenbara skillnader. Speciellt när man inte jämför de olika lagren direkt med varandra.
Om man så kan acceptera att filer i GeoPackage blir något större, så kan det vara ett bättre alternativ, om det blir snabbare att hantera filerna i QGIS (eller annat GIS).
Att konvertera JP2 filer till GeoPackage är inte en ”hastig” process! Inte när källfilerna är runt 1 GB styck och man vill få med flera i varje rastertabell i GPKG-filen. När man därför gjort lite tester för att reda ut komprimering och vilka kommandon som skall användas så är det bara att rensa en diskyta, kontrollera alla källfiler, skriva in kommandot, trycka enter och ta helg… (beroende på omfattning).
Belöningen är en enda samlad fil, om än gigantisk, med tilade rasterdata som dynamiskt kan läsas in efter behov i valfritt GIS. För att undvika att bygga pyramider så bör man sätta ett skalintervall för när dessa data skall visas, så att inte allt för mycket data behöver läsas in åt gången. Om man ändå skapar pyramider så får man räkna med att filen blir ännu större.
För andra typer av rasterdata så kan motsvarande metod också användas, men andra komprimeringsnivåer kan vara acceptabla. Dessutom så bör man få med större ytor, på kortare tid, med mindre filstorlekar som resultat, om man har rasterdata som inte har pixelstorlekar på 0.5 meter.
Beroende på förutsättningar så kommer resultatet att bli bättre eller sämre, men om snabbhet är viktigt så blir det till att bygga pyramider i alla fall. Det finns inget sätt runt det, eller…
Det finns ju en spelare till man kan testa. Cloud optimized GeoTiff – COG.
Dessa kan göras riktigt stora, men så länge program har stöd för formatet så läser man bara in det som efterfrågas. Det går dessutom att paketera exempelvis JPEG i en COG, så det borde gå att få ganska rimligt hanterbara komprimeringar också. Dessutom är en del i finesserna med COG att pyramider redan hanteras internt, så även i det fallet finns det en fördel mot Jpeg2000.
Medan jag skriver detta så har jag inte haft enorma framgångar med COG, då gdal_translate konsumerar alla tillgängliga Ram (jag har 64 GB) och hänger därefter datorn innan processen nått 10%… Jag får återkomma till tester med lite större filer i COG vid ett annat tillfälle. Under tiden så verkar GeoPackage med ”lagom” komprimering och pyramider vara en universallösning för många av de GIS jag använder (även ArcGIS), så länge det är tre band. Allt annat än tre band (fyra egentligen) så vägrar ArcGIS att kännas vid dessa. Men som sagt, tre band med pyramider och det kan vara väldigt stora filer. Dessa hanteras utan problem och med ytterst tillfredsställande prestanda, om man har tålamod att bygga dessa och lagringsutrymme. Jag har däremot en känsla av att COG kan vara en bättre lösning, om nu alla GIS har stöd för formatet…
Noterar att FME har stöd för COG från och med version 2022.0. Du hittar inställningen i GeoTiff parametrar under ”File Structure”. Bilden nedan är FME 2021 till vänster och 2022 till höger.
Noterar även att JPEG inte kan användas för så stora filer som Lantmäteriets JP2 filer på 100’000×100’000 pixlar. Deflate är inte i närheten lika effektiv komprimering storleksmässigt, så beroende på syfte och användningsområde så kan GPKG fortfarande vara ett bättre alternativ än COG.