TIFF-Orthofotos zusammenfassen und für cardo aufbereiten (GDAL)

Ausgangslage ist ein Ordner mit vielen einzelnen Orthofoto-Tiff-Dateien. Sollte es nur eine Ausgangs-Tiff-Datei geben, kann und muss Schritt 1 dennoch ausgeführt werden.

Die von den Landesämtern angebotenen Orthofotos verfügen meist über keinen Alpha-Kanal, sondern haben an den Rändern, außerhalb der Landesgrenze lediglich weiße Pixel.

Die Bildkacheln folgen der Form des Gebietes (i.d.R. Bundesland), d. h. in einem rechteckigen Gesamt-Kachel-Raster gibt es Stellen, an denen gar keine Bilddatei existiert, weil diese komplett außerhalb der Gebietsgrenzen liegt.

Zielvorstellung ist ein Gesamtbild, mit gesamt einheitlichem Hintergrund, der je nach Bedarf auch transparent dargestellt werden kann.

Der Weg führt über drei Schritte:

1. Erzeugung einer Hilfsdatei, die alle einzelnen Dateien als "virtuelle Rasterdatei" (VRT) repräsentiert. Im Zuge der Erstellung dieser Datei werden die Positionen aller Einzeldateien ermittelt und passend einsortiert sowie weitere Metadaten gesammelt bzw. vorgegeben.

2. Erzeugung der Tiff-Datei auf Basis der zuvor erstellten VRT-Datei.

3. Erzeugung einer Übersichts-Pyramiden-Datei (OVR), zur gleichzeitig (deutlichen) Steigerung von Performance und Ausgabequalität in herausgezoomten Ansichten.

Im Folgenden werden die in Frage kommenden Optionen und deren Effekte für die Erzeugung der VRT-Datei betrachtet und schließlich die mutmaßlich beste Kombination der Parameter dargestellt. Daran schließen sich die Empfehlungen und Erläuterungen für die empfohlenen Parameter der Schritte 2 und 3 an.

Benötigte Software (GDAL)

Die Operationen werden mit dem frei verfügbaren Kommandozeilen-Werkzeug GDAL durchgeführt.

Wichtig: Es sollte mindestens die Version 3.1 verwendet werden, da in älteren Versionen die Erstellung der Übersichts-Pyramiden unaussprechlich langsam ist (Tage bei der Größenordnung eines Landkreises).

Tipp: Bei Installationen von QGis ist eine entsprechend aktuelle Version von GDAL typischerweise mit dabei. Diese kann problemlos verwendet werden und ist im Installations-Ordner von QGis, z. B. C:\Programme\QGIS 3.40.0\bin\ zu finden.

Schritt 1: VRT-Erstellung für Orthofotos (Varianten)

Erläuterungen allgemeiner Parameter:

-overwrite gibt an, dass eine ggf. schon existierende VRT-Datei mit gleichem Namen überschrieben werden soll

-resolution highest gibt an, dass bei einer Menge von Einzelbildern die Auflösung des Bildes mit der höchsten Auflösung als Auflösung für das Gesamtbild verwendet werden soll. In der Praxis wird das selten relevant sein, da die Bilder i.d.R. alle die gleiche Auflösung haben werden, aber zur Absicherung kann das nicht schaden.

-b 1 -b 2 -b 3 Diese Parameter sind noch zu ergänzen, sollten die Ausgangsbilder mehr als 3 Kanäle enthalten (manchmal ist z. B. noch der Infrarot-Kanal mit dabei), um 3 Kanäle als Quelle für die RGB-Kanäle zu wählen. Die Nummerierung der Kanäle beginnt mit der Ziffer 1. Welche Kanäle im Quellbild tatsächlich Rot, Grün, Blau sind, muss ggf. erfragt oder ausprobiert werden.

Folgend werden die Auswirkungen einiger Parameter bezüglich Ihrer Eignung zur Herstellung einer Transparenten Darstellung im Randbereich (weiße Pixel untersucht), deren Auswirkungen kurz beschriebne und schließlich eine Empfehlung abgegeben. Bei abweichender Ausgangslage (z. B. Bilder mit Alpha-Kanal) oder anderem gewünschten Resultat muss jedoch diese Empfehlung nicht mehr zutreffen und evtl. einer der anderen Parameter oder Kombinationen daraus sinnvoller sein, daher werden diese hier mit beschrieben.

Test 1: Argument "addalpha"

gdalbuildvrt -addalpha -resolution highest "Z:\Ortho\gesamt.vrt" "Z:\Ortho\*.tif" -overwrite

addalpha gibt an, dass für das virtuelle Raster ein Alpha-Kanal erzeugt werden soll.

Einen Effekt hat das nur für die Stellen, wo Kacheln im Mosaik gänzlich fehlen. Diese Stellen haben dann im Alpha-Kanal einen Transparanzwert. Alle anderen Luftbild-Kachlen sind bis zum Rand vollflächig gefüllt, also nicht transparent.

Die Grundfarbe der transparent erzeugten Bildbereiche ist schwarz (0, 0, 0). An den Übergängen zu benachbarten Kacheln, die nicht transparent sind, kann es dadurch zu grauen Kanten kommen, weil die Übergänge "weich" gezeichnet werden.

Test 2: Hinzunahme von "srcnodata", also Gemeinsame Verwendung von "addalpha" und "srcnodata"

gdalbuildvrt -addalpha -srcnodata "255 255 255" -resolution highest "Z:\Ortho\gesamt.vrt" "Z:\Ortho\*.tif" -overwrite

Der Parameter srcnodata "255 255 255" legt weiß als Farbwert für alle NODATA-Werte der Quelle fest, wodurch die Grundfarbe der fehlenden Kachlen zu weiß wird (alles was "leer" ist wird zu weiß). Damit verschwinden die grauen Streifen an den Rändern, weil nun am Übergang nicht mehr zwischen schwarz und weiß gemischt wird, was eine Verbesserung gegenüber der alleinigen Verwendung von addalpha darstellt.

Durch srcnodata wird außerdem die Information über die NODATA-Farbe als Meta-Information im VRT und später dann auch im Tiff mitgeführt. Das hat den Effekt, dass Anzeigeprogramme wie IWAN oder QGis die Farbe weiß ohne weitere Konfiguration als NODATA interpretieren und transparent darstellen, egal ob man das möchte oder nicht.

Test 3: Verzicht auf "addalpha", also nur "srcnodata"

gdalbuildvrt -srcnodata "255 255 255" -resolution highest "Z:\Ortho\gesamt.vrt" "Z:\Ortho\*.tif" -overwrite

Da der Parameter srcnodata ohnehin dazu führt, dass weiß als NODATA und damit transparent erscheint, ist der Alpha-Kanal praktisch überflüssig und kann entfallen. Man spart dadurch einen Farbkanal und damit etwas Dateigröße.

Final empfohlene Argumente: Kombination von "srcnodata" mit "hidenodata"

Dies ist die mutmaßlich beste Variante für die Erzeugung der VRT-Datei zur Zusammenfassung der Orthofotos, die in der oben beschriebenen Form vorliegen.

gdalbuildvrt -srcnodata "255 255 255" -hidenodata -resolution highest "Z:\Ortho\gesamt.vrt" "Z:\Ortho\*.tif" -overwrite

Der Parameter srcnodata "255 255 255" legt weiß als Farbwert für alle NODATA-Werte der Quelle fest, wodurch die Grundfarbe der fehlenden Kachlen zu weiß wird (alles was "leer" ist wird zu weiß)

hidenodata bewirkt, dass die Meta-Information über den NODATA-Wert (in dem Fall die Farbe weiß) vom VRT nicht mitgeführt werden soll. Auf diese Weise ist nicht gleich von Grund auf die Farbe Weiß "gebrandmarkt" und man behält sich mehr Flexibilität in der späteren Verwendung.

Die Anzeigeprogramme (IWAN, QGis) können i. d. R. problemlos eine beliebige Farbe (oder Farbbereiche) transparent darstellen, so dass man nicht auf die NODATA-Meta-Information angewiesen ist.

Tipp

Angabe der Transparenz im Iwan7 CSS:

special-raster-properties
{
    transparent-colors: RGB(255,255, 255); 
}

Schritt 2: Gesamt-Tiff-Datei erzeugen

Folgende Paramter gelten unabhängig von der gewählten Komprimierung:

TILED=YES sollte unbedingt als Parameter verwendet werden. Er führt dazu, dass die Daten in der Tiff-Datei in Blöcken (Kacheln) abgelegt werden und nicht zeilenweise. In der Praxis passt die blockweise Ablageform perfekt zur typischerweise rechteckig, ausschnittweise stattfindenden Datenabforderung, wodurch die Lesezugriffe deutlich effizienter stattfinden können als bei einer zeilenweisen Speicherung, wo für einen solchen Ausschnitt verschwenderischer Weise immer alle betroffenen Zeilen komplett gelesen werden müssen.

BIGTIFF=YES notwendig um Tiff-Dateien erzeugen zu können, die größer als 4 GB werden. Unschädlich, wenn die Dateigröße darunter bleibt.

Die Komprimierung der Bilddaten ist dringend angeraten. Es besteht dabei die Wahl zwischen einer sehr guten, aber leicht verlustbehafteten Variante und einer verlustfreien Komprimierung. Im farbigen Bildbereich ist bei sinnvoll gewählter Kompressionsstärke vom menschlichen Auge kein Unterschied zwischen den Varianten auszumachen. Lediglich bei einer transparenten Darstellung im Randbereich treten bei der verlustbehafteten Variante kleine Artefakte auf, die dazu führen, dass keine perfekt saubere Kante erscheint.

Hinweis: Warnungen mit dem Wortlaut The definition of projected CRS EPSG:25833 got from GeoTIFF keys is not the same as the one from the EPSG registry ... können ignoriert werden. Diese besagen nur, dass eine im Tiff hinterlegte Definition des Koordinatenbezugssystems nicht exakt mit der Definition übereinstimmt, die im "offiziellen" EPSG-Register geführt wird. Die Abweichungen sind i. d. R. sowieso nicht substanziell und im gesamten hier beschriebenen Prozess werden durch GDAL auch keinerlei Koordiatentransformationen durchgeführt.

... mit JPEG-Komprimierung (deutlich kleinere Dateigröße, aber dafür leicht verlustbehaftet)

Für 3-Kanal-Luftbilder (RGB) bietet sich JPEG als effizientes Komprimierungsverfahren an. Es ist verlustbehaftet, aber für diese Art von Daten ("Foto") ist das aus praktischer Sicht meist nicht relevant. Sichtbar wird der Effekt am ehesten an den Kanten, beim Überganng von "farbigem Bild" zu "weißem Hintergrund", wenn der weiße Hintergrund per Farb-Ersetzung transparent erscheinen soll. Durch die JPEG-Komprimierung sind im Übergangsbereich nicht alle Pixel rein weiß und bleiben dann als helle, nicht transparente Pixel erhalten.

Dies ist die allgemein empfohlene Variante!

gdal_translate -of GTiff -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co JPEG_QUALITY=85 -co TILED=YES -co BIGTIFF=YES --config GDAL_CACHE_MAX 128 "Z:\Ortho\gesamt.vrt" "Z:\Ortho\gesamt.tif" 

Mittels PHOTOMETRIC=YCBCR wird "YCbCr" als das interne Farbmodell für die JPEG-Komprimierung vorgegeben.

Ab Oktober 2024 unterstützt cardo4/Iwan7 das "YCbCr"-Farbmodell. Orthofotos, die damit komprimiert sind, haben eine Dateigröße von nur ca. 40% bis 50% im Vergleich zur Kompression mit dem "RGB"-Farbmodell!

Die JPEG_QUALITY kann angepasst werden. Werte über 90 sollten nicht verwendet werden. Eine Qualitätsverbesserung ist bei Orthofotos dann nicht mehr sichtbar und die Dateigrößen steigen exorbitant. (Der Standardwert für JPEG-Komprimierungen ist 75.)

... mit DEFLATE-Komprimierung (größere Dateigröße, aber dafür verlustfrei)

Ist ein 100%-ig sauberer Übergang im Übergangsbereich von "farbigem Bild" zu "weißem Hintergrund" erforderlich, dann muss ein Komprimierungsverfahren eingesetzt werden, welches die Daten verlustfrei komprimiert. Dazu stehen DEFLATE und LZW zur Verfügung.

Diese Variante sollte nur nach gründlicher Abwägung gewählt werden!

Die Ergebnisdatei ist 10- bis 15-fach größer als bei einer JPEG-Komprimierung, selbst bei der sehr hoch eingestellten JPEG-Qualität von 85.

gdal_translate -of GTiff -co COMPRESS=DEFLATE -co PREDICTOR=2 -co TILED=YES -co BIGTIFF=YES --config GDAL_CACHE_MAX 128 "Z:\Ortho\gesamt.vrt" "Z:\Ortho\gesamt.tif" 

DEFLATE scheint bei Luftbildern gerinfügig besser zu komprimieren als LZW. Die Resultate können jedoch abhängig vom Bildmaterial variieren und im Zweifel kann man beide Varianten vergleichen.

PREDICTOR=2 ist für RGB-Kanalwerte zu wählen, weil dies immer ganzzahlige Werte sind (im Bereich 0 bis 255). (2 = Ganzzahlen, 3 = Dezimalzahlen).

Schritt 3: Übersichts-Pyramide erzeugen

Außer bei sehr kleinen Tiff-Dateien (wenige MB) ist die Erstellung von Übersichts-Pyramiden immer zu empfehlen. Sie dienen gleichermaßen der Performance und der Darstellungsqualität in herausgezoomten Ansichten.

Das Speicherlayout tiled wird für die Übersichts-Datei offenbar von der Basisdatei übernommen, braucht daher nicht explizit angegeben werden.

-r average Gibt an, dass beim Herunterrechnen der Auflösung in den Pyramiden-Leveln ein mittlerer Farbwert aus allen Pixeln gebildet werden soll, die aus dem Level darunter in diesem Pixel vereint werden.

-minsize 256 gibt an, dass beim Aufbau der Pyramide so lange neue (kleinere) Level "zur Spitze hin" erzeugt werden sollen, bis die Kantenlänge des obersten Bildes 256 Pixel unterschreiten würde. Die Anzahl der dafür benötigten Pyramiden-Level (Teilungen des Basis-Tiff) wird hierbei automatisch berechnet und ist die deutlich bequemere und sinnvollere Form gegenüber der expliziten Angabe der Liste der gewünschten Teiler (2 4 8 ...) als explizite Parameter.

Da die Basis-Tiff-Datei wird mit der Option -ro ("read only") geöffnet wird, wird die Übersichtspyramide in einer separaten ovr-Datei mit gleichem Basis-Namen erzeugt. Diese OVR-Datei muss dann immer zusammen mit der Basis-Tiff-Datei abgelegt werden und wird automatisch erkannt und verwendet. Ohne das -ro Argument wird die Pyramide direkt in das Basis-Tiff geschrieben. Das ist prinzipiell auch möglich. Man hat dann im Ergebnis nur eine Datei, aber verliert Flexibilität (man hätte dann kein Tif mehr, welches "rein" die Daten enthält, sondern immer die Übersichtspyramiden mit im "Gepäck").

Wichtig:

Wenn ein Tiff über eine Übersichts-Pyramide verfügt, dann sollte bei der Verwendung im cardo die CSS-Eigenschaft render-quality auf den Wert standard gesetzt bzw. diese Angabe gänzlich weggelassen werden! Alle anderen render-quality Werte zielen darauf ab, sich dem Effekt anzunähern, den die vorberechnete Pyramide bereits als ureigenes Feature mit sich bringt, nämlich die Verrechnung vieler Quell-Pixel zu einem kombinierten Farbwert eines Darstellungs-Pixels im Ausgabebild in herausgezoomten Ansichten.

Bezüglich der Komprimierung besteht die gleiche Wahl wie bei der Erstellung der "Haupt"-Tiff-Datei und es gelten die gleichen Hinweise zur Auswahl.

... mit JPEG-Komprimierung (kleinere Dateigröße, aber dafür verlustbehaftet)

gdaladdo --config COMPRESS_OVERVIEW JPEG --config PHOTOMETRIC_OVERVIEW YCBCR --config JPEG_QUALITY 75 -r average -minsize 256 -ro "Z:\DOP-SN\gesamt.tif" 

Die JPEG-Qualität von 75 (was auch der Standardwert ist), ist als Qualität für die Übersichts-Ansichten absolut ausreichend. In den Übersichts-Ansichten werden ohnehin die Farbwerte vieler Pixel des voll aufgelösten Bildes zu einem gemeinsamen Farbwert in einer verkleinerten Ansicht kombiniert. Die komprimierungsbedingt geringfügigen Abweichungen von Farbwerten sind in diesem Kontext irrelevant.

... mit DEFLATE-Komprimierung (größere Dateigröße, aber dafür verlustfrei)

gdaladdo --config COMPRESS_OVERVIEW DEFLATE --config PREDICTOR_OVERVIEW 2 -r average -minsize 256 -ro "Z:\DOP-SN\gesamt.tif"  

Weiterführende Links

Doku der Rasterbild-Datenquelle

Doku der Rasterbild Symbolik-Parameter