4.13. Pixelformate

Die letzte Stufe der ISP-Pipeline packt jedes Pixel in ein bestimmtes Byte-Layout im Speicher. Das gewählte Format wägt Bildqualität, Speichergröße und die Art ab, wie nachgelagerter Code die Bytes wieder ausliest. Eine Handvoll Formate dominiert.

4.13.1. RAW (Bayer)

Die Standardausgabe ist rohes Bayer – dasselbe einkanalige Pro-Pixel-Mosaik, das der Sensor erzeugt. Ein Byte pro Pixel, angeordnet im Bayer-Muster: Rot und Grün wechseln sich in geraden Zeilen ab, Grün und Blau in ungeraden Zeilen. Es wurde kein Debayering angewendet, sodass jede Zelle nur den Wert enthält, den ihr Farbfilter durchgelassen hat.

Rohes Bayer benötigt ein Drittel des Speichers eines fertigen dreikanaligen RGB-Bildes – ein Byte pro Pixel statt drei – und es wurden keine ISP-Zyklen für das Debayering oder die Umwandlung aufgewendet. Der Preis dafür ist, dass der Benutzercode das Debayering selbst durchführen muss, bevor irgendeine farbbewusste Verarbeitung laufen kann.

4.13.2. RGB888

RGB888 ist das natürliche fertige Format für ein Farbbild: drei Bytes pro Pixel, je eines für den roten, grünen und blauen Kanal mit 8 Bit pro Kanal. Vierundzwanzig Bit pro Pixel und knapp unter siebzehn Millionen unterscheidbare Farben.

RGB888 ist die konzeptionelle Referenz für fertige Farbbilder und die meiste Software außerhalb der Platine spricht es. Auf eingebetteter Hardware ist sein Hauptnachteil die 24-Bit-Pixelgröße – kein Vielfaches der Wortgröße des Prozessors, ungünstig für die Speicherausrichtung und 50 % größer als das nächstkleinere Format.

4.13.3. RGB565

RGB565 packt jedes Pixel in zwei Bytes: fünf Bit Rot, sechs Bit Grün, fünf Bit Blau. Das zusätzliche Grün-Bit spiegelt die höhere Empfindlichkeit des Auges für Grün wider und entspricht der doppelten Gewichtung des Grünkanals im Bayer-Muster.

RGB565 ist das Standard-Farbformat der OpenMV Cam. Zwei Bytes pro Pixel sind 16-Bit-ausgerichtet, was zu den natürlichen Datenbreiten des MCU passt – Pixel-Ladevorgänge, -Speichervorgänge und -Arithmetik laufen alle mit voller Geschwindigkeit, und viele Operationen können ein Pixelpaar auf einmal verarbeiten. Die 24-Bit-Pixel von RGB888 richten sich nicht auf diese Weise aus und kosten bei jedem Zugriff. Die 33-prozentige Speichereinsparung gegenüber RGB888 summiert sich ebenfalls: QVGA (320 x 240) belegt 150 KB in RGB565 gegenüber 225 KB in RGB888, und der Abstand wächst mit der Auflösung.

Der Kompromiss sind 65 Tausend unterscheidbare Farben statt siebzehn Millionen. Für die meisten Aufgaben des maschinellen Sehens ist der Unterschied unsichtbar, da die Algorithmen das Einzelbild auf schwellenwert- oder kantenbasierte Darstellungen reduzieren, die ohnehin die meisten Farbdetails verwerfen. Für den menschlichen Betrachter zeigen sich die fehlenden Bits als schwaches Banding in glatten Farbverläufen, aber nicht als etwas, das dem Auge sofort auffällt.

4.13.4. YUV422

YUV422 teilt die Farbe jedes Pixels in einen Luminanz-Wert (Y) und zwei Chrominanz-Werte (U und V) auf und unterabtastet dann die Chrominanz, da das menschliche Sehen für Farbvariationen viel weniger empfindlich ist als für Helligkeitsvariationen. Jedes Pixel trägt sein eigenes Y, aber benachbarte Pixelpaare teilen sich ein U und ein V. Das Byte-Layout für jedes Paar umfasst vier Bytes – Y0, U, Y1, V – was im Durchschnitt zwei Bytes pro Pixel ergibt, identisch zu RGB565.

Die beiden Bytes bedeuten allerdings etwas anderes als bei RGB565. Der Y-Kanal allein ist ein gebrauchsfertiges 8-Bit-Graustufenbild, was die meisten klassischen Algorithmen des maschinellen Sehens (Kantenerkennung, Template-Matching, Blob-Analyse) tatsächlich verarbeiten; die U- und V-Kanäle tragen die Farbinformation für die kleine Anzahl von Algorithmen, die sie benötigen.

YUV422 ist die richtige Wahl, wenn die Pipeline beides benötigt – ein Algorithmus in einer frühen Stufe, der nur Y liest, gefolgt von einer späteren Stufe, die die Chrominanz für feinere Farbentscheidungen nutzt – denn die Y-Werte liegen direkt bereit, ohne dass eine Farbraumkonvertierung nötig ist.

4.13.5. Graustufen

Graustufen sind ein Byte pro Pixel: nur der Luminanzwert, überhaupt keine Farbe. Es ist das kleinste fertige Format – halb so groß wie RGB565 und YUV422, ein Drittel der Größe von RGB888.

Die meisten klassischen Algorithmen des maschinellen Sehens arbeiten ohnehin auf Graustufen, sodass das direkte Weglassen des Farbkanals aus dem Sensor heraus oft die einfachste und speichereffizienteste Wahl ist. Kantenerkennung, Linienfindung, Blob-Analyse, QR-Code-Decodierung, Template-Matching und AprilTag-Erkennung laufen alle auf Graustufen und profitieren vom kleineren Puffer.

4.13.6. Weitere Formate

Einige Formate, die die OpenMV Cam erzeugen kann, kommen nicht als Teil des normalen Ablaufs aus der ISP-Pipeline.

BINARY ist ein Bit pro Pixel – die kleinstmögliche Darstellung. Wird für schwellenwertbasierte Bilder, Maskenpuffer und die Ausgabe jeder Operation verwendet, die an jedem Pixel nur zwischen Treffer und Nicht-Treffer unterscheidet.

JPEG ist ein komprimiertes Farbformat. Einige Sensoren enthalten einen On-Chip-JPEG-Encoder und können JPEG-komprimierte Einzelbilder direkt liefern; bei Sensoren ohne einen solchen lässt der MCU einen JPEG-Encoder über ein fertiges RGB- oder Graustufen-Einzelbild nach dem ISP laufen. So oder so ist die Ausgabe ein JPEG-Bitstream, nützlich zum Speichern von Einzelbildern oder zum Senden über eine bandbreitenbegrenzte Verbindung.

PNG ist ein verlustfreies komprimiertes Format. Sensoren erzeugen PNG nicht direkt; der MCU komprimiert ein fertiges RGB- oder Graustufen-Einzelbild bei Bedarf. Nützlich, wenn Bandbreite oder Speicher von Bedeutung sind, die verlustbehaftete Kompression von JPEG aber Informationen verwerfen würde, die die Anwendung später benötigt.