ffmpeg bgr vs. rgb und andere ähnliche Pixelformate

Ich habe mich über den Unterschied zwischen RGB- und BGR-Pixelformaten gewundert, die in vielen Codecs verfügbar sind.

Es erinnert mich in gewisser Weise an die Big-Endian- und Little-Endian-Varianten von Computerprozessoren.

Während ich immer vermutete, dass Big / Little Endian eher eine Frage von Patenten als von Leistung ist, warum haben wir sowohl RGB als auch BGR?

Encoder huffyuv [Huffyuv / HuffYUV]:
Threading-Fähigkeiten: nein
Unterstützte Pixelformate: yuv422p rgb24 bgra

Es hat rgb24 , aber dann nicht rgba , wie ich erwarten könnte. Es springt direkt zu bgra !

Könnte es sich wieder um Patente handeln, die der Codec-Autor nicht brechen konnte?

Bitte füttern Sie meine Neugier mit einer ausführlichen Erklärung hier, wenn möglich, ich möchte etwas mehr über diese verschiedenen Pixelformate wissen!

Antworten (2)

Die Reihenfolge der Komponenten in RGB32 scheint mit Endianness zu tun zu haben :

PIX_FMT_RGB32 wird endianspezifisch behandelt. Eine RGBA-Farbe wird zusammengesetzt als: (A << 24) | (R << 16) | (G << 8) | B Dies wird auf Little-Endian-CPU-Architekturen als BGRA und auf Big-Endian-CPUs als ARGB gespeichert.

Die Beschreibungen der verschiedenen verwandten Formate, die auf dieser Seite aufgeführt sind, enthalten weitere Einzelheiten.

Ach, das war mir nicht bewusst! Stimme zu. Meine Kernfrage war jedoch auf eine detaillierte Erklärung geschlossen, wie diese Formate entstehen, Vor- und Nachteile, warum einige Software oder Standards in eine Richtung statt in die andere gehen, ob sie auch mit Subpixel-Rendering zu tun haben und wie viele detaillierte Informationen möglich sind . Eine Summe einiger Themen + externe Referenzen, um alle mögliche Neugier zu stillen.
Meinen Sie, warum Endianness oder warum unterschiedliche Stapelreihenfolgen? Letztere scheinen aus Gründen der Effizienz an die Existenz der ersteren gebunden zu sein. Denke nicht, dass es tiefer geht.
@ user3450548: Eher haben die Designer verschiedener Systeme willkürliche Entscheidungen unterschiedlich getroffen. Vielleicht auf Videospeicher / 3D-Texturlayout zurückgehend. Vielleicht haben einige Hardware-Designentscheidungen eine Bestellung effizienter gemacht als die andere. Obwohl Sie wahrscheinlich mit dem Endian-Argument etwas anfangen können. Anders ausgedrückt: Eine unbearbeitete Pixmap-Datei/ein Speicherblock mit gepackten Farbkomponenten wird von Little-Endian-CPUs in die eine Richtung gelesen, von Big-Endian-CPUs in die andere Richtung.

Während ich immer vermutete, dass Big / Little Endian eher eine Frage von Patenten als von Leistung ist,

Nein, Little Endian wurde als Leistungsoptimierung entwickelt, wenn auf Multi-Byte-Wörter umgestellt wird. https://en.wikipedia.org/wiki/Endianness#Optimization

Nichts mit Patenten. Unterschiedliche Darstellungen haben unterschiedliche Vor- und Nachteile. Daher können unterschiedliche Situationen unterschiedliche Darstellungen verwenden. Codecs leiden unter Netzwerkeffekten. Niemand möchte Ihren Encoder verwenden, wenn niemand Ihren Decoder verwendet. Und umgekehrt. Daher streben Codec-Designer nach maximaler Kompatibilität und unterstützen oft mehrere Formate. Aber die unterstützen normalerweise nicht alle, weil es Dutzende gibt. Sie verwenden also eine Kombination der gebräuchlichsten und am einfachsten in das Design einzubeziehenden.

Vielen Dank für den Hinweis auf die Leistung von Endianess und die Patentangelegenheit;)
ffmpeg bgr vs. rgb und andere ähnliche Pixelformate
AntwortenHierDatenschutz-Bestimmungen1y, 0v