Das Thema Pixelverhältnisse ist normalerweise für Cutter weniger interessant. In letzter Zeit häuften sich jedoch die Anfragen zu diesem Thema. Auslöser war nicht zuletzt die Schnittsoftware Vegas, die mit unbekannten Faktoren und Verhältnissen immer wieder zur Unsicherheit führte. Dieser Artikel will daher die Grundlagen klären und taucht dazu tief ein in die Welt der Videotechnik, der Computer und der Mathematik.
Die analoge Welt
Insgesamt besteht das analoge Videobild im PAL-Format aus 625 Zeilen, davon werden 575 (2X287,5) für das aktive Bild benutzt. Pro Zeile wird davon ein Zeitfenster von 52µs für die Darstellung des Videobildes benutzt:
Die digitale Welt – am Anfang
Als bei PAL mit der Digitalisierung begonnen wurde, stellte man fest, dass digitale Geräte mit einigen Dingen der Videotechnik nicht zurecht kamen. U.A. war ein großes Problem der Umgang mit den 2x287,5 Zeilen, weshalb man sich schnell für zwei halbe Leerzeilen entschied, um mit 2x288 Zeilen arbeiten zu können.
Bei der Suche nach einer digitalen Norm für PAL wurde am Anfang davon ausgegangen, dass horizontal und vertikal die gleiche Auflösung verwendet werden sollte. Bei vorgegeben 576 (2x288) Zeilen und einem Bildseitenverhältnis von 3:4 wäre das korrekte Verhältnis also 576/3*4=768.
Sollte mit diesen Vorgaben im Vollformat 16:9 produzieren werden, wäre ein Verhältnis von 576/9*16=1024 korrekt. Dies ist jedoch nicht darstellbar, da es die Übertragungskette überfordert. Entsprechend wäre das Letterbox-Format (d.h. es wird von den maximal möglichen 768 Spalten ausgegangen) 768/16*9=432.
Beide Formate (768x576) und (768x432) gehen von den gleichen Voraussetzungen aus:
1.horizontale und vertikale Auflösung sind gleich, was man auch als „quadratisches Pixelseitenverhältnis“, auf Neudeutsch „square Pixel“, bezeichnet.
2.Das aktive Bildsignal passt mit seinen 768 Spalten weiterhin in das Zeitfenster von 52µs.
So viel zur Vorgeschichte.
Die neue Norm
Nachdem einige Zeit mit diesem Format produziert worden war, gab es Bestrebungen, die Gelegenheit der Einführung neuer Technik dazu zu benutzen, die verschiedenen Fernsehnormen PAL und NTSC aneinander anzunähern. Außerdem sollte ein weiteres Problem der existierenden Technik gelöst werden: analoge Geräte sind nie perfekt. Zwar zeigen sie recht genau das Zeitfenster von 52us an, aber nicht alle exakt zum gleichen Zeitpunkt. Zumindest Profimaschinen hatten daher immer einen Regler, mit dem man das Bild ein wenig nach rechts oder links schieben konnte, um Einmess- und Laufzeitfehler ausgleichen zu können. Bei digital exakt abgetasteten 52us ist das nicht mehr möglich, denn was bei der Digitalisierung verloren gegangen ist, ist nicht wieder rückholbar. In einer analog-digitalen Mischumgebung waren daher viele Videos mit einem störenden schwarzen Rand behaftet.
Zum ersten Wunsch: Die Änderung von Bildwechselfrequenz (NTSC 60Hz, PAL 50Hz) oder Zeilenzahl (NTSC 480, PAL 576) hätte zu einem Problem geführt: Der Kunde braucht einen neuen Fernseher. Da dieses nicht in Betracht kam, wurde das Einzige angepasst, was anpassbar war: Die Spaltenzahl. Es gibt eine Reihe von Herleitungen, die einfachste ist mit Sicherheit folgende: Wer aus 640 (NTSC) Spalten und 768 (PAL) Spalten eine Norm machen möchte, trifft sich etwa in der Mitte: also z.B. (640+768)/2=704. Genauer gesagt wurde sich auf eine maximale Frequenz von 6.75MHz geeinigt, das entspricht einer Pixelzahl von >702 und <=704 innerhalb von 52µs.
Zum zweiten Wunsch: Die einzige Möglichkeit, das Problem der leichten Lageverschiebungen zu umgehen, ist die Einführung eines Sicherheitsrandes. Als mehr oder weniger willkürliche Grenze hielt man eine maximale Erweiterung um etwa 9 Spalten rechts und links als ausreichend. Zieht man diese 2x9 Spalten zu den 702 vorhandenen hinzu, kommt man als Gesamtzahl auf die bekannten 720.
Die Eckdaten der 1981 von der CCIR (Comité Consultatif International des Radiocommunications) unter der Nummer 601 veröffentlichten Empfehlung waren daher folgende:
Die Anzahl der Abtastwerte über die digitale aktive Zeile von 53.3~3µs sind
für das Helligkeitssignal Y: 720
für jedes Farbdifferenzsignal Cr und Cb: 360
Die Anzahl der aktiven Zeilen im PAL 625-System beträgt 576.
Das Normungsgremium CCIR erfuhr im Laufe der Jahre mehrere Umbenennungen. Aus CCIR wurde erst ETSI, heute ist es unter dem Namen ITU (International Telecommunications Union) bekannt. Die Normen sind unter anderem auf der Website http://www.itu.int verfügbar.
Nach dieser Norm besteht also ein Bild aus 576x720 Pixeln auf einer Breite von 53,3~3µs. Da die Auflösung in diesem Fall nur in einer Richtung geändert wurde, ist sie horizontal und vertikal nicht mehr gleich. Das bedeutet auch, dass es sich nicht mehr um ein quadratisches Pixelseitenverhältnis handelt, sondern um ein rechteckiges, auf Neudeutsch: „non-square“.
Bei non-square Formaten ist es üblich, den Korrekturfaktor der Auflösung mit anzugeben:
Die vertikale Auflösung beträgt dabei 576Zeilen pro 1/25 Sekunde = 7.2MHz (ohne Kell-Faktor ),
die horizontale Auflösung beträgt 720Spalten pro 53,3~3µs = 6.75MHz.
Setzt man die beiden Auflösungen ins Verhältnis, ergibt sich ein Wert von gerundet 1.0667.
Soll mit dieser non-square Norm in 16:9 produziert werden, ist zu beachten, dass nur die horizontalen Werte geändert wurden, die vertikalen dagegen nicht! Bei Letterbox 16:9 sind nach wie vor die schon oben erwähnten 432 Zeilen (also 720x432) korrekt. Einzig die horizontalen Werte des theoretischen Vollformats würden angepasst werden, das wären 960x576.
Die Computer kommen
Bis zu diesem Zeitpunkt bewegen wir uns im Bereich der Videotechnik. Auch Grafikmaschinen und Bildspeichersysteme arbeiten (zumindest im Broadcastbereich) mit diesen Werten. Wer z.B. einmal Quantel- oder discreet-Systeme bedient hat, dem wird das alles bekannt vorkommen. Zur Darstellung benutzen diese Grafic-Workstations meist einen gewöhnlichen Fernseher oder TV-Monitor. Dadurch ist das zu bearbeitende Bild immer mit dem Endergebnis identisch.
"Leider" kamen immer mehr die liebevoll als „Heimcomputer“ bezeichneten Rechner in Mode und damit fing das ganze Schlamassel an. Highend Grafic-Workstations sind teuer und eine typische Äußerung der IT-Branche ist seit jeher zu sagen: Wir können es besser und billiger.
Es wurde also versucht, z.B. mit Grafikprogrammen wie Photoshop, Bilddateien aus Videos zu extrahieren, zu bearbeiten und wieder in ein Video einzufügen. Wer das schon einmal selbst versucht hat, wird feststellen, dass es damit ein Problem gibt: Normale Grafikprogramme arbeiten horizontal und vertikal immer mit der gleichen Auflösung. Die Bearbeitung von Material der alten Norm von 768x576 Pixeln ist damit also kein Problem. Aber: Was ist mit einer non-square Norm von 720x576?
Und dann gibt es plötzlich noch ein zweites Problem: Die Geometrie! Wer sich jetzt fragt, wo da der Unterschied ist, dem sei der Blick zurück empfohlen: non-square bezeichnet eine Norm, deren horizontales und vertikales Pixelseitenverhältnis nicht identisch ist. Bei 601 und DV ist das der Faktor 1.0667. Jedoch gilt dieser Faktor unabhängig davon, ob von einer aktiven Breite von etwa 702 Spalten innerhalb von 52us ausgegangen, oder das Gesamtsignal mit 720 Spalten in 53.3~3us betrachtet wird. In beiden Fällen ist der non-square Faktor 1.0667, denn in beiden Fällen ist die horizontale Grenzfrequenz 6.75 MHz! Für die Geometrie eines Bildes ist es aber ein Unterschied, von welcher Breite und von welchem Zeitfenster ausgegangen wird:
Einzig die Umrechnung von Verhältnissen mit gleichem Zeitfenster ist erlaubt, bei den bisher bekannten Formaten wäre das 702x576 -> 768x576. Das Verhältnis zwischen 768 und 702 beträgt gerundet 1.094 und dient als neuer Faktor für geometrisch korrekte Skalierungen.
Durch diesen Faktor ergibt sich eine weitere Möglichkeit: Die Erstellung eines geometrisch korrekten square-Formats für das Zeitfenster von 53,33µs. Aus den vollen 720 Spalten und dem Korrekturfaktor 1.094 ergeben sich 787 Spalten für ein voll ausgeschriebenes Videobild:
Ein Verhältnis wie 787x576 ist im Konsumerbereich recht unbekannt. Man hat es wahrscheinlich bewusst außen vor gelassen, denn es führt zu einer schwer zu verstehenden Konsequenz: 787x576 ist ein square Pixelformat, das aber nicht mehr im Bildseitenverhältnis 4:3 ist. Zudem hat es ein weiteres Problem: Das Format ist direkt abhängig vom verwendeten geometrischen Korrekturfaktor. Dieser ist jedoch in keiner Norm definiert. Rechnet man die Rundungsfehler ein, so ist jeder Bezugspunkt >702 und <=704 erlaubt. Als geometrische Korrektur-Faktoren könne daher alle Werte <1.09402 und >=1.0909 verwendet werden, was zu den Formaten 785-, 786-, 787- und 788x576 führen könnte.
Gehen wir mit 787x576 in etwa von der Mitte der möglichen Verhältnisse aus, existieren mittlerweile 3 Formate mit unterschiedlichen horizontalen Werten:
768x576 bei 52us
720x576 bei 53,33µs
787x576 bei 53,33µs
Was bis jetzt noch nicht berücksichtigt wurde: Es gibt Anwendungsfälle, bei denen ist eine Anpassung in horizontaler Richtung nicht möglich. Dazu gehören Bilder oder Grafiken mit fest definierter horizontaler Auflösung wie z.B. ein Sweep. In solchen Fällen wäre es auch möglich, die vertikale Pixelanzahl zu verringern, was zu einem weiteren Verhältnis führt:
576/1.094 ergibt gerundet etwa 527, das entstehende Format wäre also 720x527.
Alle diese neuen Pixelverhältnisse und ihre Korrekturfaktoren sind im Grunde genommen Krücken. Sie können immer nur einen Teil der Anforderungen erfüllen. Zur besseren Übersichtlichkeit sind die Eigenheiten noch einmal in einer Tabelle zusammengefasst:
| 768x576 in 52µs | square | vertikale Auflösung korrekt | ||
| 720x576 in 53,33µs | non-square | vertikale Auflösung korrekt | horizontale Auflösung korrekt | |
| 787x576 in 53,33µs | square | vertikale Auflösung korrekt | ||
| 720x527 in 53,33µs | square | horizontale Auflösung korrekt |
Korrekturen
Nachdem jetzt die wichtigsten Verhältnisse vorgestellt sind, sollte geklärt werden, wie und an welcher Stelle überhaupt Korrekturen notwendig sind. Zur besseren Veranschaulichung dienen zwei Konsumerprogramme, Premiere 6.5 und Vegas 4.0, die mit diesen Korrekturfaktoren jeweils unterschiedlich umgehen.
1. Die Effekte
Videoprogramme im Konsumerbereich rechnen genauso wie Bildbearbeitungssoftware nur mit square Pixeln. Das hat neben dem Vorteil der einfacheren Programmierung auch Vorteile bei der Anpassung an verschiedene Normen.
Um diesen Effekten nun bei geometrischen Figuren wie Kreisblenden oder ähnlichem eine korrekte Darstellung beizubringen, gibt es in der Regel einen globalen Korrekturfaktor. Dieser wird in den Projekteinstellungen einmal eingestellt und dann auf alle Effekte angewandt.
Premiere bezeichnet den Korrekturfaktor in der deutschen Übersetzung richtig als „Pixelseitenverhältnis“, meint damit also den non-square Faktor. Er ist für DV natürlich 1.0667 und somit richtig. Allerdings ist nirgendwo zu finden, wie der geometrische Bezug ist. Daher wurde eine Kreisblende erstellt und nachgemessen, ob die Anpassung korrekt ist. Leider ist sie es nicht. Premiere verwendet den Faktor des Pixelseitenverhältnisses auch für die Skalierung, berücksichtigt aber nicht die kompletten 53,33µs für das voll ausgeschriebene Videobild. Die Kreisblende erzeugt daher eine leichte, liegende Eiform.
Bei Vegas steht in den ProjectProperties unter PixelAspectRatio der Wert Korrekturfaktor 1.0926. Die Bezeichnung „PixelAspectRatio“ ist hier eigentlich nicht korrekt, denn der Faktor ändert nicht das Pixelseitenverhältnis. Dieses beträgt für DV bekanntermaßen immer 1.0667. Gemeint und auch geändert wird hier die geometrische Anpassung von 702.9 auf 768 oder von 720 auf 787 Pixel. Diese Anpassung ist richtig und führt daher auch bei Effekten, wie z.B. einer Kreisblende, zu einem völlig korrekten Kreis. Man sollte dort also 1.0926 stehen lassen und sich vom Wort „Pixel“ nicht verwirren lassen.
Der Unterschied der Faktoren ist in der Praxis zwar gering, aber sichtbar:
 |
| blauer Innenkreis von Premiere, weißer Außenkreis von Vegas |
2. Das Overlay
Natürlich soll der Computermonitor das Bild geometrisch möglichst korrekt darstellen. Diese Einstellung sollte eigentlich unabhängig sein von der Ansteuerung der Effekte und keinerlei Auswirkungen auf die Berechnung haben.
Premiere benutzt auch für das Overlayfenster wieder den Wert von 1.06~6 aus den Projekteinstellungen, eine getrennte Anpassung ist nicht vorgesehen. Hier entsteht wiederum eine geometrische Ungenauigkeit, denn die gesamte Breite des Videobildes von 53,3~3µs wird zur Erstellung des nur 768x576 großen Overlays herangezogen.
Bei Vegas erreicht man diese Anpassung im Video-Preview-Fenster unter „Simulate Device Aspect Ratio“, die das Overlayfenster auf 787x576 streckt. Das Verhältnis entsteht wieder durch die korrekte Darstellung des vollen Videobildes und seine anschließende Hochskalierung mit dem in den ProjectProperties eingetragenen Faktor. Die Anpassung des Overlays hat keine Auswirkungen auf die Effektberechnung, genau so soll es sein.
Bei Computermonitoren gibt es noch ein weiteres Problem: Für 21"-Bildschirme bietet Windows eine eigene non-square Auflösung (Faktor 0.938), die bekannten 1280x1024. Kein Schnittprogramm kann diesen Fehler abfangen, daher sollte für eine genaue Darstellung das Verhältnis 1280x960 benutzt werden.
3. Die PlugIn-Schnittstelle
Fast alle Schnittprogramme übertragen drei verschiedene Informationen an die PlugIns.
A. Die ursprüngliche Auflösung des Videos als Wert, z.B. 576x720
B. Den in den Projekteinstellungen angegeben Korrekturfaktor
C. Den eigentlichen Videodatenstrom
Je nach PlugIn/Videoschnittprogramm-Kombination kann das verschiedene Auswirkungen haben.
Ein paar Beispiele:
BorisFX in Premiere. In den Premiere-Einstellungen steht ein Pixelseitenverhältnis von 1.067, der Codec-Wert kommt mit 576x720 an. BorisFx lässt sich aber ebenfalls anpassen. In den BorisFX-Einstellungen muss aber 576x768 stehen!! Was würde sonst passieren? Der Datenstrom würde mit DV-Auflösung und Korrekturfaktor ankommen und BorisFX würde die Auflösung nochmals reduzieren. Das führt zu unscharfen Bildern.
Auch die Kombination Canopus-Codec und Adorage-Magic führte am Anfang zu Problemen. Canopus verwendet bei 4:3 die 720x576 und schreibt als Pixelseitenverhältnis 1.0667. Adorage ignoriert aber die 1.0667, weil es intern anscheinend immer mit diesem Faktor rechnet. Schaltet man bei Canopus auf 16:9, schreibt Canopus 1024x576 und 1:1 in die Premiere Projekt-Einstellungen. Das funktioniert natürlich nicht mit AdorageMagic, denn es kann mit 1:1-Werten nichts anfangen, das Bild wird wiederum unscharf.
PlugIns unter Vegas. Der auffälligste Unterschied dürfte das unterschiedliche Verhalten des Pan/Crop-Filter von Vegas und das der PlugIns sein. Das 3DPlugIn-Pack z.B. arbeitet relativ zur Auflösung. Die Veränderungen sind in Prozent des Bildes anzugeben, das macht es praktisch mit allen Formaten einsetzbar. Dieses PlugIn wird bei DV über die PlugIn Schnittstelle mit einem 576x720 Datenstrom und einem Korrekturfaktor von 1.0926 versorgt. Das entstehende Bild ist daher 576x787 groß. Für Umrechnungen von Pixel und Prozent ist das daher auch der Ausgangswert.
Der Vegas Pan&Crop-Filter dagegen greift nicht über eine PlugIn-Schnittstelle, sondern direkt auf die Timeline zu. Aus diesem Grund ist er auch separat aufrufbar. Pan/Crop ist in der Lage, die Videodaten direkt aus den Dateien auf der Timeline zu lesen. Da Pan/Crop bei DV-Dateien die VIDEODATEN anzeigt, sind hier auch nur die Werte 720x576 zu finden.
4. Der Grafikimport
Videoprogramme sollten grundsätzlich zwei Möglichkeiten des Grafikimports anbieten:
A. Import als square. Grafiken werden also mit dem Pixelverhältnis in die Timeline übernommen, das sie besitzen.
B. Import mit Korrekturfaktor. Grafiken werden von Hand oder per Automatik in der Timeline skaliert. Als Wert sollte dabei natürlich der zum Projekt passende geometrische Korrekturfaktor dienen.
Premiere erkennt beim Import die Formate 768x576 und 720x576 selbstständig. Die 768x576 werden automatisch mit dem Korrekturfaktor 1.0667 belegt und Format füllend in die Timeline importiert. Das führt, wie schon bei den Effekten, zu einer leichten Streckung in horizontaler Richtung. Mit den eigentlich richtigen Formaten 787x576 und 720x527 kann Premiere nichts anfangen und fügt sie anhand einer Grundeinstellung ein: In den Voreinstellungen -> Allgemein und Standbild kann unter „Seitenverhältnis erhalten“ wahlweise square (was oben und unten zu schwarzen Rändern führt) oder das Vollbild erzwungen werden.
Vegas geht beim Grafikimport grundsätzlich von geometrisch korrekten Verhältnissen aus. Es importiert daher 787x576 und 720x527 ohne schwarze Ränder auf 53,33µs. 768X576 große Dateien werden ebenfalls korrekt eingebunden, führen aber auf dem Overlay zu schwarzen Rändern, da Vegas dafür korrekt nur 52µs annimmt. Das Verhältnis 720x576 braucht einen Korrekturfaktor, der von Hand gesetzt werden muss: In den Media Properties die Vorlage 1.9026 DV auswählen, dann passt es.
Fazit
Die hier vorgestellte Problematik gehört schon zur hohen Schule, keine Frage. In erster Linie ist sie daher für Entwickler und Beschäftigte im Broadcastbereich interessant. Der Konsumer hat davon zumindest einen kleinen Nutzen: Zu wissen, was sein Programm wann tut, und daraus die Konsequenzen ziehen zu können. Für Premiere könnte das z.B. heißen, als Importformate nur Verhältnisse mit dem Faktor 1.0667 oder 1 zu verwenden und auf das letzte Quentchen Geometrie zu verzichten. Bei Vegas darf es schon etwas mehr sein: auch 1.0926 wird korrekt importiert, damit stehen sogar geometrisch korrekte Grafiken zur Verfügung.
Schön wäre es, wenn der Artikel zumindest ein grundlegendes Gefühl für die Skalierungsprobleme vermitteln konnte, denn: Stand der Technik sind leider noch eine Menge Videoprogramme, die überhaupt nicht mit non-square Pixelverhältnissen umgehen können. Dazu gehört z.B. der Windows MediaPlayer (getestete Version 8 aus WindowsXP), der auf dem Computermonitor DV-Dateien unkorrigiert mit 720x576Pixeln darstellt. Auch bei MediaStudioPro wurde anscheinend erst in Version 7 darüber nachgedacht. Traurig, bei einer Norm, die schon 23 Jahre alt ist. Aber so ist sie halt, die IT-Branche: Wir können alles besser und billiger...
