DE102019002951A1

DE102019002951A1 - Pixelspeicherung für graphische Bildspeicher

Info

Publication number: DE102019002951A1
Application number: DE102019002951.8A
Authority: DE
Inventors: Richard Hayden Wyman; Brian Francis Schoner; David Chao Hua Wu; Timothy James MAMTORA
Original assignee: Avago Technologies International Sales Pte Ltd
Current assignee: Avago Technologies International Sales Pte Ltd
Priority date: 2018-04-25
Filing date: 2019-04-24
Publication date: 2019-10-31
Also published as: US11308649B2; US20210134019A1

Abstract

Eine Vorrichtung, die die erfindungsgegenständliche Pixelspeicherung für graphische Bildspeicher implementiert, kann wenigstens einen Prozessor aufweisen, der dafür konfiguriert ist, eine Vielzahl von Dateneinheiten zu erhalten, die eine Vielzahl von Pixeln enthalten, die in einem Speicher gespeichert sind, wobei jede von der Vielzahl von Dateneinheiten ein erstes Pixel von der Vielzahl von Pixeln gepackt in Aufeinanderfolge mit wenigstens einem Teil eines zweiten Pixels der Vielzahl von Pixeln umfasst, wobei die Vielzahl von Pixeln durch eine Anzahl von Bits repräsentiert wird, eine Gruppe von Pixeln aus der Vielzahl von Pixeln zu erhalten und die Gruppe von Pixeln unter Verwendung einer angestrebten Anzahl von Bits zu speichern. Ein Verfahren und ein Computerprogrammerzeugnis, die die erfindungsgegenständliche Pixelspeicherung für graphische Bildspeicher implementieren, sind ebenfalls vorgesehen.

Description

Die vorliegende Beschreibung bezieht sich allgemein auf die Videocodierung, - kompression und/oder -speicherung und auf die Videodecodierung, -dekompression und/oder - speicherung, aber nicht ausschließlich, zur Pixelspeicherung für graphische Bildspeicher bzw. Framebuffers.
SDR-(Standard Dynamic Range; Standarddynamikumfang)-Medien, die Bilder, Videos und Renderings einschließen, haben einen begrenzten Dynamikumfang für Luminanzwerte oder die Helligkeit von Pixeln beschränkt durch die Bit-Tiefe oder die Anzahl von Bits, die verwendet werden kann bzw. können, um die Luminanz der Pixel entsprechend den Codierungs- und Decodierungsstandards (z.B. 8 Bits pro Abtastwert) zu repräsentieren. Demgegenüber stellen HDR-(High Dynamic Range; hoher Dynamikumfang)-Medien-Standards mehr Bits oder eine größere Bit-Tiefe (z.B. 10, 12, 16, 24, 32 Bits oder mehr pro Abtastwert) bereit, was ein größeres Spektrum in dem Bild zwischen Weiß und Schwarz oder hellen und dunklen Bereichen erlaubt, ohne unakzeptable Mengen an Konturierung aufgrund einer übermäßigen Quantisierung einzuführen. Als Folge davon können Medien einen höheren Kontrast, dunklere dunkle Abschnitte und hellere helle Abschnitte haben.
In Übereinstimmung mit einem Aspekt der Erfindung ist eine Vorrichtung vorgesehen, die Folgendes aufweist:

wenigstens einen Prozessor, der dafür konfiguriert ist:
- eine Vielzahl von Dateneinheit zu erhalten, die eine Vielzahl von Pixeln enthalten, die in einem Speicher gespeichert sind, wobei jede von der Vielzahl von Dateneinheiten ein erstes Pixel von der Vielzahl von Pixeln gepackt in Aufeinanderfolge mit wenigstens einem Teil eines zweiten Pixels von der Vielzahl von Pixeln umfasst, wobei die Vielzahl von Pixeln durch eine Anzahl von Bits repräsentiert wird;
- eine Gruppe von Pixeln aus der Vielzahl von Pixeln zu erhalten; und
- die Gruppe von Pixeln unter Verwendung einer angestrebten Anzahl von Bits zu speichern.

Vorteilhafterweise unterscheidet sich die angestrebte Anzahl von Bits von der Anzahl von Bits.
Vorteilhafterweise ist der wenigstens eine Prozessor dafür konfiguriert:

einen verlustbehafteten Kompressionsvorgang an die Vielzahl von Pixeln anzulegen; und
die Gruppe von Pixeln als komprimierte Daten unter Verwendung der angestrebten Anzahl von Bits auf der Basis des angelegten verlustbehafteten Kompressionsvorgangs zu erzeugen.

Vorteilhafterweise ist der wenigstens eine Prozessor dafür konfiguriert:

eine statistische Redundanz zwischen Pixeln von der Gruppe von Pixeln unter Verwendung des angelegten verlustbehafteten Kompressionsvorgangs zu ermitteln; und
eine oder mehrere Informationseinheiten aus der Gruppe von Pixeln auf der Basis der statistischen Redundanz zu entfernen, um die Gruppe von Pixeln auf eine Größe zu reduzieren, die der angestrebten Anzahl von Bits entspricht.

Vorteilhafterweise ist der wenigstens eine Prozessor dafür konfiguriert:

einen Block von komprimierten Pixeldaten aus einem ersten Bildspeicher in einem Speicher zu erhalten;
den Block von komprimierten Pixeldaten in einen Block von unkomprimierten Pixeldaten zu dekomprimieren;
den Block von unkomprimierten Pixeldaten zu verarbeiten;
den verarbeiteten Block von unkomprimierten Pixeldaten in einen Block von komprimierten Pixeldaten unter Verwendung der angestrebten Anzahl von Bits zu komprimieren; und
den Block von komprimierten Pixeldaten in einen zweiten Bildspeicher in dem Speicher hinein zu speichern.

Vorteilhafterweise umfasst der Block von komprimierten Pixeldaten entsprechende Pixel von dem Block von unkomprimierten Pixeldaten.
Vorteilhafterweise ist der wenigstens eine Prozessor dafür konfiguriert:

die angestrebte Anzahl von Bits auf der Basis eines vorbestimmten Kompressionsverhältnisses zu bestimmen, wobei das vorbestimmte Kompressionsverhältnis ein Verhältnis von der Anzahl von Bits, die der Gruppe von Pixeln entspricht, zu der angestrebten Anzahl von Bits ist.

Vorteilhafterweise entspricht die angestrebte Anzahl von Bits einem Vielfachen einer Burst-Länge, die beim Senden von Daten zu dem Speicher verwendet wird.
Vorteilhafterweise ist der wenigstens eine Prozessor dafür konfiguriert:

einen empfangenen Videodatenstrom (Videostream) in die Vielzahl von Pixeln zu decodieren;
ein Pixelformat für die Gruppe von Pixeln auf der Basis eines Speicherungsformats eines Speichers auszuwählen;
die Gruppe von Pixeln gemäß dem ausgewählten Pixelformat zu packen;
festzustellen, dass es notwendig ist, dass zu der Gruppe von Pixeln ein Padding (Auffüllung mit Fülldaten) hinzugefügt werden muss, um dem Pixelformat zu entsprechen;
ein Padding zu der Gruppe von Pixeln gemäß dem Pixelformat hinzuzufügen; und
die Gruppe von Pixeln mit dem Pixelformat in einen Bildspeicher in dem Speicher hinein zu speichern.

Vorteilhafterweise ist der wenigstens eine Prozessor dafür konfiguriert:

einen Block von unkomprimierten Pixeldaten aus einem ersten Bildspeicher in einem Speicher zu erhalten;
festzustellen, dass ein Pixelformat des Blocks von unkomprimierten Pixeldaten ein oder mehrere Padding-Bits (Füll-Bits) umfasst;
das eine oder die mehreren Padding-Bits aus dem Block von unkomprimierten Pixeldaten zu entfernen;
den Block von unkomprimierten Pixeldaten zu verarbeiten;
festzustellen, dass das Pixelformat des Blocks von unkomprimierten Pixeldaten wenigstens ein einziges Padding-Bit für die Speicherung benötigt;
das wenigstens eine Padding-Bit zu dem Block von unkomprimierten Pixeldaten hinzuzufügen; und
den Block von unkomprimierten Pixeldaten mit dem hinzugefügten wenigstens einen Padding-Bit in einen zweiten Bildspeicher in dem Speicher hinein zu speichern.

Vorteilhafterweise ist der wenigstens eine Prozessor dafür konfiguriert:

die Vielzahl von Pixeln als unkomprimierte Pixeldaten auf der Basis eines ausgewählten Pixelformats, das der Anzahl von Bits entspricht, zu speichern; und
die Gruppe von Pixeln als komprimierte Pixeldaten auf der Basis der angestrebten Anzahl von Bits zu speichern,
wobei die Vielzahl von Pixeln und die Gruppe von Pixeln in verschiedenen Bildspeichern gespeichert werden.

Gemäß einem Aspekt umfasst ein Verfahren die folgenden Schritte:

Erhalten einer Vielzahl von Dateneinheiten, die eine Vielzahl von Pixeln enthalten, die in einem Speicher gespeichert sind, wobei jede von der Vielzahl von Dateneinheiten ein erstes Pixel von der Vielzahl von Pixeln gepackt in Aufeinanderfolge mit wenigstens einem Teil eines zweiten Pixels von der Vielzahl von Pixeln umfasst, wobei die Vielzahl von Pixeln durch eine Anzahl von Bits repräsentiert wird;
Erhalten einer Gruppe von Pixeln aus der Vielzahl von Pixeln;
Komprimieren der Gruppe von Pixeln unter Verwendung einer angestrebten Anzahl von Bits; und
Speichern der komprimierten Gruppe von Pixeln.

Vorteilhafterweise umfasst das Komprimieren der Gruppe von Pixeln die folgenden Schritte:

Anlegen eines verlustbehafteten Kompressionsvorgangs an die Gruppe von Pixeln; und
Erzeugen der komprimierten Gruppe von Pixeln mit der angestrebten Anzahl von Bits auf der Basis des angelegten verlustbehafteten Kompressionsvorgangs.

Vorteilhafterweise umfasst das Anlegen des verlustbehafteten Kompressionsvorgangs die folgenden Schritte:

Ermitteln einer statistischen Redundanz zwischen Pixeln von der Gruppe von Pixeln unter Verwendung des angelegten verlustbehafteten Kompressionsvorgangs; und
Entfernen von einer oder von mehreren Informationseinheiten aus der Gruppe von Pixeln auf der Basis der statistischen Redundanz, um die Gruppe von Pixeln auf eine Größe zu reduzieren, die der angestrebten Anzahl von Bits entspricht.

Vorteilhafterweise umfasst das Verfahren des Weiteren den folgenden Schritt:

Bestimmen der angestrebten Anzahl von Bits auf der Basis eines vorbestimmten Kompressionsverhältnisses, wobei das vorbestimmte Kompressionsverhältnis ein Verhältnis von der Anzahl von Bits, die der Gruppe von Pixeln entspricht, zu der angestrebten Anzahl von Bits ist.

In Übereinstimmung mit einem Aspekt ist ein Computerprogrammerzeugnis vorgesehen, das Anweisungen aufweist, die in einem greifbaren computerlesbaren Speichermedium gespeichert sind, wobei die Anweisungen Folgende umfassen:

Anweisungen für das Erhalten einer Vielzahl von Dateneinheiten, die eine Vielzahl von Pixeln enthalten, die in einem Speicher gespeichert sind, wobei jede von der Vielzahl von Dateneinheiten ein erstes Pixel von der Vielzahl von Pixeln gepackt in Aufeinanderfolge mit wenigstens einem Teil eines zweiten Pixels von der Vielzahl von Pixeln umfasst, wobei die Vielzahl von Pixeln durch eine Anzahl von Bits repräsentiert wird;
Anweisungen für das Erhalten einer Gruppe von Pixeln aus der Vielzahl von Pixeln;
Anweisungen für die Komprimierung der Gruppe von Pixeln unter Verwendung einer angestrebten Anzahl von Bits, die sich von der Anzahl von Bits unterscheidet; und
Anweisungen für das Speichern der komprimierten Gruppe von Pixeln.

Vorteilhafterweise umfassen die Anweisungen des Weiteren die Folgenden:

Anweisungen für das Anlegen eines verlustbehafteten Kompressionsvorgangs an die Gruppe von Pixeln; und
Anweisungen für das Erzeugen der komprimierten Gruppe von Pixeln mit der angestrebten Anzahl von Bits auf der Basis des angelegten verlustbehafteten Kompressionsvorgangs.

Vorteilhafterweise umfassen die Anweisungen des Weiteren die Folgenden:

Anweisungen für das Ermitteln einer statistischen Redundanz zwischen Pixeln von der Gruppe von Pixeln unter Verwendung des angelegten verlustbehafteten Kompressionsvorgangs; und
Anweisungen für das Entfernen von einer oder mehreren Informationseinheiten aus der Gruppe von Pixeln auf der Basis der statistischen Redundanz, um die Gruppe von Pixeln auf eine Größe zu reduzieren, die der angestrebten Anzahl von Bits entspricht.

Vorteilhafterweise umfassen die Anweisungen des Weiteren die Folgenden:

Anweisungen für das Bestimmen der angestrebten Anzahl von Bits auf der Basis eines vorbestimmten Kompressionsverhältnisses, wobei das vorbestimmte Kompressionsverhältnis ein Verhältnis von der Anzahl von Bits, die der Gruppe von Pixeln entspricht, zu der angestrebten Anzahl von Bits ist.

Vorteilhafterweise repräsentiert die Vielzahl von Pixeln HDR-(High Dynamic Range)-Pixel.
Figurenliste
Bestimmte Merkmale der erfindungsgegenständlichen Technologie sind in den angehängten Ansprüchen dargelegt. Aber zum Zwecke der Erläuterung werden mehrere Ausführungsformen der erfindungsgegenständlichen Technologie in den folgenden Figuren dargelegt.

1 veranschaulicht eine beispielhafte Netzwerkumgebung, in der ein Videocodiersystem in Übereinstimmung mit einer oder mehreren Implementierungen implementiert werden kann.
2 veranschaulicht ein beispielhaftes elektronisches Gerät, das ein Graphiksystem für eine Pixelspeicherung in graphischen Bildspeichern in Übereinstimmung mit einer oder mehreren Implementierungen implementiert.
3 veranschaulicht einen Datenfluss für ein beispielhaftes Graphiksystem für eine Pixelspeicherung in graphischen Bildspeichern in Übereinstimmung mit einer oder mehreren Implementierungen.
4 veranschaulicht einen unkomprimierten graphischen Bildspeicher und einen entsprechenden komprimierten graphischen Bildspeicher in Übereinstimmung mit einer oder mehreren Implementierungen.
5A bis 5C veranschaulichen Ablaufdiagramme von jeweiligen beispielhaften Pixelspeicherungsprozessen eines Systems für eine Pixelspeicherung in graphischen Bildspeichern in Übereinstimmung mit einer oder mehreren Implementierungen.
6 veranschaulicht konzeptionell ein elektronisches System, mit dem alle Implementierungen der erfindungsgegenständlichen Technologie implementiert werden.

AUSFÜHRLICHE BESCHREIBUNG
Die ausführliche Beschreibung, die unten dargelegt ist, ist als eine Beschreibung von verschiedenen Konfigurationen der erfindungsgegenständlichen Technologie gedacht und ist nicht dazu gedacht, die einzigen Konfigurationen darzustellen, in denen die erfindungsgegenständliche Technologie praktiziert werden kann. Die angehängten Zeichnungen sind hier aufgenommen und bilden einen Teil der ausführlichen Beschreibung. Die ausführliche Beschreibung umfasst spezifische Einzelheiten für den Zweck des Bereitstellens eines umfassenden Verständnisses der erfindungsgegenständlichen Technologie. Aber die erfindungsgegenständliche Technologie ist nicht auf die hier dargelegten spezifischen Einzelheiten beschränkt, und sie kann unter Verwendung von einer oder mehreren Implementierungen praktiziert werden. In einem Fall oder in mehreren Fällen sind Strukturen und Komponenten in einer Blockdiagrammform gezeigt, um zu vermeiden, dass die Konzepte der erfindungsgegenständlichen Technologie unklar werden.
Graphikverarbeitungssysteme unterhalten typischerweise zwei Arten von Pufferspeichern bzw. Zwischenspeichern, nämlich anzeigbare und nicht anzeigbare Pufferspeicher. Anzeigbare Pufferspeicher enthalten Pixel, die an eine Anzeige, wie etwa ein Fernsehgerät oder einen Computermonitor, gesendet werden können. Nicht anzeigbare Pufferspeicher können zusätzliche Daten wie etwa eine Tiefenkarte enthalten, die die Anwendung verwendet, um das Rendering der anzeigbaren Pufferspeicher zu unterstützen, oder sie können Pixeldaten wie etwa Texturkarten enthalten, die für eine Zwischenverarbeitung verwendet werden und nicht direkt an eine Anzeige gesendet werden.
Alte Systeme umfassen SDR-Systeme und speichern Pixel für ihre anzeigbaren Pufferspeicher typischerweise in einem Speicher mit 8 Bits pro Komponente. Drei Komponenten (Rot (R), Grün (G) und Blau (B)) werden typischerweise zusammen mit einem Term, der Alpha (A) genannt wird, gespeichert, der verwendet wird, um die Stärke des Blending (Vermischens) zwischen Schichten von gerenderten Graphiken zu steuern. In einigen Implementierungen können diese Komponenten, nämlich R, G, B und A, allgemein zusammen als „RGBA“ bezeichnet werden. Ein typisches RGBA-Pixel kann in eine 32-Bit-Speicherstelle passen. Dies ist eine günstige Anzahl von Bits, die sich gut in die Organisation eines Speichers in traditionellen Zentralverarbeitungseinheit- bzw. Zentraleinheit-(CPU; Central Processing Unit)- und Graphikverarbeitungseinheit-(GPU; Graphic Processing Unit)-Systemen einfügt (oder sich gut damit packen lässt). In dieser Hinsicht eignet sich jedes Vielfache von 32 Bits gut für das Packen. In einigen Aspekten können Pixeldaten, die 64 Bits (oder ein anderes Vielfaches) haben, die effizienteste Verwendung eines Speichers, wie etwa eines DRAM (Dynamic Random Access Memory; dynamischer Direktzugriffsspeicher), sein. In diesem Beispiel würden zwei Pixel (d.h. 2 * 32 Bits = 64 Bits) als eine einzige Dateneinheit behandelt werden. In einigen Aspekten bezieht sich der Begriff „Pufferspeicher“ (Buffer) allgemein auf einen DRAM-Pufferspeicher, der außerhalb eines Chips angeordnet ist.
Die traditionelle Speicherorganisation kann auch als effizient gelten. Alle 32 Bits in dem gepackten RGBA-Pixel können nützliche und gültige Informationen enthalten. Man kann auch sagen, dass die traditionelle Speicherorganisation einen leichten direkten Zugriff bietet. Da ein einziges Pixel in einem 32-Bit-Wort enthalten ist, ist, um auf ein bestimmtes Pixel mit einer CPU oder GPU zuzugreifen, die Adressenberechnung, die benötigt wird, um auf das 32-Bit-Wort zuzugreifen, unkompliziert und effizient.
Wenn ein anzeigbarer Pufferspeicher zur Anzeige ausgelesen wird, können die Pixel aus dem Speicherungspufferspeicher (typischerweise ein DRAM) mit einer Rate ausgelesen werden, die dem Fluss von Pixeln über die Schnittstelle (wie etwa eine HDMI (High-Definition Multimedia Interface; hochauflösende Multimedia-Schnittstelle) oder ein DisplayPort) zu der Anzeige entspricht. Wenn die Rate des Flusses von Pixeln nicht der Rate entspricht, die für die Anzeige zu jeder Zeit benötigt wird, kann das Bild auf der Anzeige fehlerhaft bzw. verstümmelt sein. Um solche Probleme zu vermeiden, ist es notwendig, zu garantieren, dass die notwendige Rate durch das System bereitgestellt werden kann. Um zu garantieren, dass die notwendige Datenflussrate durch das System bereitgestellt werden kann, ist es notwendig, zu wissen, wie viele Daten aus dem DRAM mit welcher Rate ausgelesen werden müssen. Für das oben angegebene RGBA-Beispiel führen die genau definierten Pixelspeicherungsparameter, die damit gekoppelt sind, wie viele Pixel in dem Pufferspeicher gespeichert sind, und die des Weiteren mit der Einzelbild-(Frame)-Dauer gekoppelt sind (z.B. das Umgekehrte der Bildwiederholfrequenz der Anzeige), zu einer klar definierten benötigten Pixelflussrate von dem DRAM, die notwendig ist, um eine Anzeigenstörung bzw. Anzeigenkorrumpierung zu vermeiden.
HDR-Systeme erlauben einen größeren Umfang bei der Helligkeit (sowohl in Bezug auf heller als auch auf dunkler) als SDR-Systeme. HDR-Systeme erlauben auch einen breiteren Umfang im Farbspektrum (Color Gamut). In dieser Hinsicht können HDR-Systeme ein breiteres Spektrum von Helligkeiten und Farben anzeigen als im Vergleich dazu SDR-Systeme. Somit werden HDR-Pixel nicht so effizient wie SDR-Pixel gepackt. Wenn Pixel in einem HDR-System repräsentiert werden, wird ein Minimum von 10 Bits pro Komponente für anzeigbare Pufferspeicher benötigt, um eine allgemein akzeptable Bildqualität bereitzustellen. Wenn weniger als 10 Bits pro Komponente verwendet werden, kann der Mangel an Bit-Tiefen-Auflösung der Komponenten zur Streifenbildung und zu anderen Quantisierungsbildfehlern auf der Anzeige führen. Somit müsste ein Pixelformat ausgewählt werden, das mindestens 10 Bits pro Komponente vorsieht. Aber es steht kein momentanes Pixelformat zur Verfügung, das die Pack-, Effizienz-, Direktzugriffs- und Echtzeitzugriffs-Anforderungen erfüllt, die notwendig sind, um ein kosteneffizientes HDR-Graphiksystem zu implementieren.
Die erfindungsgegenständliche Technologie stellt einen verlustbehafteten Kompressionsprozess zum Speichern von Pixeln in HDR-Graphiksystemen für die Verwendung mit den anzeigbaren graphischen Bildspeichern mit den Eigenschaften bereit, wie sie in 2 bis 4 beschrieben sind. Anzeigbare graphische Bildpuffer von HDR-Graphiksystemen können kosteneffektiv unterstützt werden, während sie die notwendigen Graphiksystemanforderungen erfüllen. Mit den beschriebenen Eigenschaften des Pixelformats und der verlustbehafteten Kompression in Übereinstimmung mit einer oder mehreren Implementierungen können die Pack-, Effizienz-, Direktzugriffs- und Echtzeit-Anforderungen erfüllt werden.
1 veranschaulicht eine beispielhafte Netzwerkumgebung 100, in der ein Videocodiersystem in Übereinstimmung mit einer oder mehreren Implementierungen implementiert werden kann. Aber nicht alle der dargestellten Komponenten müssen notwendig sein, und eine oder mehrere Implementierungen können auch zusätzliche Komponenten umfassen, die in der Figur nicht gezeigt sind. Variationen in der Anordnung und der Art der Komponenten können vorgenommen werden, ohne dass von dem Erfindungsgedanken oder dem Schutzumfang der Ansprüche, wie sie hier dargelegt sind, abgewichen wird. Zusätzliche Komponenten, andere Komponenten oder weniger Komponenten können vorgesehen werden.
Die beispielhafte Netzwerkumgebung 100 umfasst ein Content-Delivery-(Inhalte-Weitergabe)-Netzwerk (CDN) 110, das kommunikationsfähig mit einer elektronischen Vorrichtung 120 gekoppelt ist, wie etwa durch ein Netzwerk 108. Das CDN 110 kann einen Inhaltsserver bzw. Content-Server 112 zum Codieren und/oder Senden von codierten Datenströmen, wie etwa mit HEVC (High-Efficiency Video Coding; Hochleistungs-Videocodierung) codierte Videodatenströme (Videostreams), mit AV1 codierte Videodatenströme und/oder mit H266 codierte Videodatenströme, über das Netzwerk 108, eine Antenne 116 zum Senden von codierten Datenströmen über den Äther und eine Satellitensendevorrichtung 118 zum Senden von codierten Datenströmen an einen Satelliten 115 aufweisen oder es kann kommunikationsfähig mit diesen gekoppelt sein.
Die elektronische Vorrichtung 120 kann eine Satellitenempfangsvorrichtung 122, wie etwa eine Satellitenschüssel, die codierte Datenströme von dem Satelliten 115 empfängt, aufweisen und/oder sie kann damit gekoppelt sein. In einer oder mehreren Implementierungen kann die elektronische Vorrichtung 120 des Weiteren eine Antenne zum Empfangen von codierten Datenströmen, wie etwa codierte Videodatenströme, über den Äther von der Antenne 116 des CDN 110 aufweisen. Der Inhaltsserver 112 und/oder die elektronische Vorrichtung 120 kann bzw. können eine oder mehrere Komponenten des elektronischen Systems, das unten in Bezug auf 2 erörtert wird, sein oder sie können diese einschließen.
Das Netzwerk 108 kann ein öffentliches Kommunikationsnetzwerk (wie etwa das Internet, ein Mobilfunkdatennetzwerk, Wählmodems über ein Telefonnetzwerk) oder ein privates Kommunikationsnetzwerk (wie etwa ein privates lokales Netzwerk („LAN“), Standleitungen bzw. Mietleitungen) sein. Das Netzwerk 108 kann auch, ohne darauf beschränkt zu sein, eine oder mehrere der folgenden Netzwerktopologien einschließen, die ein Busnetzwerk, ein Sternnetzwerk, ein Ringnetzwerk, ein Maschennetzwerk, ein Stern-Bus-Netzwerk, ein Baumnetzwerk oder ein hierarchisches Netzwerk und dergleichen einschließen. In einer oder mehreren Implementierungen kann das Netzwerk 108 Übertragungsleitungen wie etwa koaxiale Übertragungsleitungen, Glasfaser-Übertragungsleitungen oder allgemein alle Übertragungsleitungen, die kommunikativ den Inhaltsserver 112 und die elektronische Vorrichtung 120 koppeln, umfassen.
Der Inhaltsserver 112 kann eine oder mehrere Verarbeitungsvorrichtungen, einen Datenspeicher 114, einen Codierer und/oder eine Kompressionsvorrichtung umfassen oder er kann damit gekoppelt sein. Die eine oder die mehreren Verarbeitungsvorrichtungen führen Computeranweisungen aus, die in dem Datenspeicher 114 gespeichert sind, zum Beispiel um ein Content-Delivery-Netzwerk zu implementieren. Der Datenspeicher 114 kann die Computeranweisungen auf einem nichtflüchtigen computerlesbaren Medium speichern. Der Datenspeicher 114 kann des Weiteren ein oder mehrere Programme, z.B. Video- und/oder Audioströme, speichern, die durch das CDN 110 weitergegeben bzw. geliefert werden. Der Codierer kann einen Codec verwenden, um Videodatenströme zu codieren, wie etwa einen HEVC-Codec, einen AV1-Codec, einen H266-Codec oder jeden anderen geeigneten Codec. In einer oder mehreren Implementierungen kann der Codierer eine oder mehrere der Codierungs-, Kompressions- und/oder Speicherungstechniken implementieren.
In einer oder mehreren Implementierungen kann der Inhaltsserver 112 eine einzelne Rechenvorrichtung wie etwa ein Computer-Server sein. Alternativ dazu kann der Inhaltsserver 112 mehrere Rechenvorrichtungen repräsentieren, die zusammenarbeiten, um die Aktionen eines Server-Computers durchzuführen (wie etwa eine Cloud von Computern und/oder ein verteiltes System). Der Inhaltsserver 112 kann mit verschiedenen Datenbanken, Speicherungsdiensten oder anderen Rechenvorrichtungen gekoppelt sein, die zusammen mit dem Inhaltsserver 112 angeordnet sein können oder die sich disparat von dem Inhaltsserver 112 befinden können.
Die elektronische Vorrichtung 120 kann eine oder mehrere Verarbeitungsvorrichtungen, einen Speicher und/oder einen Decodierer, wie etwa einen Hardware-Decodierer, umfassen oder sie kann mit diesen gekoppelt sein. Die elektronische Vorrichtung 120 kann jegliche Vorrichtung sein, die zur Decodierung und/oder Dekompression eines codierten Datenstroms, wie etwa eines codierten Videodatenstroms, in der Lage ist. In einer oder mehreren Implementierungen kann der Decodierer eine oder mehrere der Decodier-, Dekompressions- und/oder Speicherungstechniken implementieren.
Wenn zum Beispiel Pixel und/oder Pixelkomponenten in einen Speicher durch zum Beispiel eine Video Processing Engine (Video-Verarbeitungs-Engine) geschrieben werden, kann eine Gruppe von Pixeln zusammen gehandhabt werden, um die statistische Redundanz innerhalb dieser Pixel zu nutzen. In einer oder mehreren Implementierungen kann der Speicher ein DRAM sein und er kann zum Beispiel einem oder mehreren graphischen Bildspeichern entsprechen. In einer oder mehreren Implementierungen kann eine angestrebte Anzahl von Bits verwendet werden, um die Gruppe von Pixeln zu repräsentieren. Die angestrebte Anzahl von Bits kann zum Beispiel größer als, kleiner als oder gleich groß wie die ursprüngliche Anzahl von Bits sein, die der Gruppe von Pixeln entspricht.
In einer oder mehreren Implementierungen kann die elektronische Vorrichtung 120 ein Laptop- oder Schreibtisch-Computer, ein Smartphone, ein Tablet-Gerät, ein tragbares elektronisches Gerät wie etwa eine Brille oder eine Uhr mit einem oder mehreren damit gekoppelten und/oder darin eingebetteten Prozessoren, eine Set-Top-Box (Digitalempfänger), ein Fernsehgerät oder eine andere Anzeige mit einem oder mehreren damit gekoppelten und/oder darin eingebetteten Prozessoren oder irgendwelche anderen geeigneten elektronischen Vorrichtungen sein, die verwendet werden können, um einen codierten Datenstrom, wie etwa einen codierten Videodatenstrom, zu decodieren, oder die elektronische Vorrichtung 120 kann all diese oder einen Teil davon umfassen.
In 1 ist die elektronische Vorrichtung 120 als eine Set-Top-Box dargestellt, z.B. als ein Gerät, das mit einer Anzeige 124, wie etwa einem Fernsehgerät, einem Monitor oder irgendeinem anderen Gerät, das in der Lage ist, Videoinhalt anzuzeigen, gekoppelt ist und das in der Lage ist, Videoinhalt auf der Anzeige 124 anzuzeigen. In einer oder mehreren Implementierungen kann die elektronische Vorrichtung 120 in die Anzeige 124 integriert sein und/oder kann die Anzeige 124 fähig sein, einen Audioinhalt zusätzlich zu einem Videoinhalt auszugeben. Die elektronische Vorrichtung 120 kann Datenströme (Streams) von dem CDN 110 empfangen, wie etwa codierte Datenströme, die Inhaltselemente enthalten, wie etwa Fernsehprogramme, Filme oder allgemein irgendwelche Inhaltselemente. Die elektronische Vorrichtung 120 kann die codierten Datenströme von dem CDN 110 über die Antenne 116, über das Netzwerk 108 und/oder über den Satelliten 115 empfangen und die codierten Datenströme z.B. unter Verwendung des Hardware-Decodierers decodieren.
2 veranschaulicht eine beispielhafte elektronische Vorrichtung 120, die ein Graphiksystem für eine Pixelspeicherung in graphischen Bildspeichern in Übereinstimmung mit einer oder mehreren Implementierungen implementiert. Aber es müssen nicht alle der dargestellten Komponenten verwendet werden, und eine oder mehrere Implementierungen können auch zusätzliche Komponenten umfassen, die in der Figur nicht gezeigt sind. Variationen in der Anordnung und der Art der Komponenten können vorgenommen werden, ohne dass von dem Erfindungsgedanken oder dem Schutzumfang der Ansprüche, wie sie hier dargelegt sind, abgewichen wird. Zusätzliche Komponenten, andere Komponenten oder weniger Komponenten können vorgesehen werden.
Die elektronische Vorrichtung 120 weist einen Graphik-Rendering- und -Aufbereitungsabschnitt 202 und einen Anzeigeabschnitt 204 auf. Der Graphik-Rendering- und -Aufbereitungsabschnitt 202 kann einen oder mehrere Decodierer 222 (veranschaulicht als „Video-Decodierer“), einen Verarbeitungseinheitblock 224 und einen Speicher 226 umfassen. Der Anzeigeabschnitt 204 kann einen Display-Engine-(Anzeige-Engine)-Block 240 umfassen. In einer oder mehreren Implementierungen kann der Speicher 226 ein DRAM sein oder er kann einen solchen umfassen. In einer oder mehreren Implementierungen umfasst der Verarbeitungseinheitblock 224 einen oder mehrere Zentral(verarbeitungs)einheitblöcke 235 (veranschaulicht als „CPU“), einen 3D-(Dreidimensional)-Graphics-Engine-(Graphik-Engine)-Block 237 und einen 2D-(Zweidimensional)-Graphics-Engine-Block 239. Jeder von dem einen oder den mehreren CPU-Blöcken 235, 3D-Graphics-Engine-Block 237 und 2D-Graphics-Engine-Block 239 kann individuell auf den Speicher 225 zugreifen und Pixeldaten aus dem Speicher 226 lesen und Pixeldaten in den Speicher 226 schreiben. In einer oder mehreren Implementierungen kann jeder von den CPU-Blöcken 235, den 3D-Graphics-Engine-Blöcken 237 und/oder den 2D-Graphics-Engine-Blöcken 239 jegliche Vorrichtung sein, die in der Lage ist, einen codierten Datenstrom, wie etwa einen codierten Videodatenstrom, zu decodieren und/oder zu dekomprimieren, und die in der Lage ist, einen decodierten Datenstrom, wie etwa einen decodierten Videodatenstrom, zu codieren und/oder zu komprimieren. In einer oder mehreren Implementierungen kann der Verarbeitungseinheitblock 224 ein oder mehrere MPEG-Feeder-(Zubringer)-Module, ein oder mehrere Scaler-(Skalierer)-Module oder allgemein irgendwelche Bildverarbeitungsblöcke oder -module umfassen.
Während des Betriebs kann der Decodierer 222 einen oder mehrere Videodatenströme z.B. von einer oder mehreren AV-Datenstrom-(AV Stream)-Quellen empfangen. Der Decodierer 222 kann zum Beispiel ein eingehendes Videodatenstrom-Signal 212 empfangen. Das eingehende Videodatenstrom-Signal 212 kann als komprimierte digitale Daten oder als ein digitalisiertes analoges Basisband-Video fließen. Der Decodierer 222 kann das eingehende Videodatenstrom-Signal 212 dekomprimieren und decodieren und Standbild-Bilder des Videodatenstroms in dem Speicher 226 zwischenspeichern. Der Decodierer 222 kann decodierbare Datenströme (Streams) auf der Basis des eingehenden Videodatenstrom-Signals 212 erzeugen. Der Decodierer 222 kann die decodierbaren Datenströme aus dem Speicher 226 abrufen, diese decodieren und erneut in dem Speicher 226 speichern. In einigen Aspekten kann der Speicher 226 durch ein Speichersteuerungsmodul (nicht gezeigt) gesteuert werden. In einer oder mehreren Implementierungen kann das eingehende Videodatenstrom-Signal 212 Videodatenströme enthalten, die bereits in einem decodierten Format vorliegen, z.B. einen Videodatenstrom, der von einem Blue-Ray-Player empfangen wird, und der Decodierer 222 kann übersprungen bzw. umgangen werden.
Mehrere Verarbeitungsblöcke (z.B. CPU-Block 235, 3D-Graphics-Engine-Block 237, 2D-Graphics-Engine-Block 239) lesen und schreiben Pixeldaten aus dem/in den Speicher 226. Jeder von den Verarbeitungsblöcken kann Pixel rendern, und die ausgegebenen Pixel von einem Block können danach in einen anderen eingegeben werden, um diese weiter zu verarbeiten, wie etwa um mehrere Ebenen in einen einzigen zusammengesetzten Graphikpufferspeicher (nicht gezeigt) zu vermischen. In einigen Implementierungen kann wenigstens einer der Verarbeitungsblöcke 224 dann auf die decodierten Datenströme einwirken. Die Verarbeitungsblöcke 224 können eine Bildbearbeitung bzw. Bildverarbeitung bei den Standbild-Bildern der Videodatenströme durchführen, z.B. eine Skalierung, etc., und die verarbeiteten und bearbeiteten Einzelbilder (Frames) dem Display-Engine-Block 240 zuführen. Der CPU-Block 235 kann zum Beispiel eine Skalierung anwenden und Einzelbilder zusammensetzen. In anderen Beispielen kann einer bzw. können beide von dem 3D-Graphics-Engine-Block 237 und/oder von dem 2D-Graphics-Engine-Block 239 Graphiken oder ein zusätzliches Video mit dem eingehenden Videodatenstrom-Signal 212 kombinieren. Der sich ergebende Datenstrom kann dann zu einem oder mehreren Video-Codierern (nicht gezeigt) für das Anzeigen durch geeignete Ausgabeschnittstellen, wie etwa die Videoausgabeschnittstelle 214, gesendet werden.
Jeder der Verarbeitungsblöcke 224 kann eine unkomprimierte Pixeldatenausgabe von anderen Verarbeitungsblöcken, wie etwa von dem CPU 235, dem 3D-Graphics-Engine-Block 237 oder dem 2D-Graphics-Engine-Block 239, über den Speicher 226 erhalten. Die Verarbeitungsblöcke 224 können das eingehende Videodatenstrom-Signal 212 auf der Basis des Eingabeformats und des Aufgabeformats des Signals und jeglicher entsprechenden Systemanforderungen verarbeiten. Das eingehende Videodatenstrom-Signal 212 kann skaliert und direkt in das Ausgabeanzeigeformat konvertiert werden, oder es kann durch einzelne und mehrere Erfassungs- und Wiedergabeschleifen über die 3D/2D-Engine-Blöcke 235, 237 laufen. Jede Erfassungs- und Wiedergabeschleife kann unter anderem eine Datenverarbeitung, wie etwa DNR, MAD-IT, oder eine Skalierung beinhalten. Der Speicher 226 kann eine Reihe von graphischen Bildspeichern, wie etwa anzeigbare Pufferspeicher, einschließen, die es erlauben, dass eine unbegrenzte Anzahl von graphischen Schichten zusammengesetzt und miteinander vermischt werden können, bevor sie angezeigt werden. Die Display-Engine (Anzeige-Engine) 240 kann eine Anzahl von aufbereiteten bzw. verarbeiteten graphischen Bildspeichern parallel lesen und ein abschließendes Vermischen für eine Anzeige durchführen. Ein beispielhafter Prozess des Decodierens der komprimierten Pixel und des Speicherns der unkomprimierten Pixel in einem Speicher wird weiter unten im Hinblick auf 5A erörtert werden.
Wenn die graphischen Bildspeicher dann zur Verfügung stehen, können sie mit dem Video unter Verwendung eines Compositors (Zusammensetzer) kombiniert werden. Der Compositor kann erlauben, dass bis zu zwei Videooberflächen mit Daten kombiniert werden können, die in einem graphischen Bildspeicher gespeichert sind. In einigen Implementierungen kann die Blending-Reihenfolge (Vermischungs-Reihenfolge) von irgendeiner Oberfläche durch einen mit einem Computer implementierten Prozess gesteuert werden. Die Verarbeitungseinheitblöcke 224 empfangen die Standbild-Bilder und bestimmen die Pixel der Standbild-Bilder, die in einem zusammengesetzten Bild sichtbar sein werden, z.B. nicht ausgeschlossen sein werden.
In einer oder mehreren Implementierungen können die Verarbeitungseinheitblöcke 224 und/oder der Display-Engine-Block 240 dann, wenn die Bilder zu einem zusammengesetzten Bild zusammengesetzt werden sollen, Positionsinformationselemente und Schichtangaben für jedes der Standbild-Bilder z.B. von der Anwendungsschicht empfangen. Die Verarbeitungseinheitblöcke 224 und/oder der Display-Engine-Block 240 können zum Beispiel kommunikativ mit einem Host-Prozessor (nicht gezeigt) der elektronischen Vorrichtung 120 gekoppelt sein, und der Host-Prozessor kann die Positionsinformationselemente und/oder die Schichtangaben zu den Verarbeitungseinheitblöcken 224 und/oder zu dem Display-Engine-Block 240 zuführen.
Während der Videoverarbeitung wird jede Graphik oder jedes zusätzliche Video sofort kombiniert, bevor sie angezeigt werden, und das manipulierte Video wird dann zu einem oder mehreren Video-Codierern (nicht gezeigt) für die Anzeige durch die Videoausgabeschnittstelle 214 gesendet. Jeder der Verarbeitungseinheitblöcke 224 kann einen Codierer enthalten, der die Pixel der Bilder codiert, z.B. komprimiert, die in dem zusammengesetzten Bild sichtbar sein werden und die als die sichtbaren Pixel der Bilder bezeichnet werden können, und er speichert die komprimierten sichtbaren Pixel in den graphischen Bildspeichern des Speichers 226. Der Erfassungsblock 239 ermittelt dann eine Stelle, z.B. eine Adresse, in dem Speicher 226, um die komprimierten Pixel von jedem der Bilder z.B. basierend auf wenigstens den Positionsinformationen für jedes der Bilder zu schreiben, und er schreibt die komprimierten Pixel in die ermittelten Stellen des Speichers 226. Ein beispielhafter Prozess des Komprimierens der sichtbaren Pixel der Bilder und des Schreibens der komprimierten Pixel in den Speicher 226 wird weiter unten im Hinblick auf 5B erörtert werden.
Das Graphiksystem kann gerenderte Graphiken in einem oder mehreren von dem 3D-Graphics-Engine-Block 237 oder dem 2D-Graphics-Engine-Block 239 in Reaktion auf eine Aufforderung, gerenderte Graphiken anzuzeigen, erzeugen. Beispiele für Aufforderungen zum Anzeigen von gerenderten Graphiken können das Aktivieren eines Menüs, das Ändern eines Kanals, das Durchsuchen eines Kanalführers, das Anzeigen eines Fotos oder eines Videos und andere Aufforderungen umfassen, die dazu führen können, dass gerenderte Graphiken angezeigt werden. In Reaktion auf eine Aufforderung zum Rendern von Graphiken kann das Graphiksystem zuerst den Farbraum und den nichtlinearen Raum ermitteln, die verwendet werden, um die Graphik zu rendern. Die Entscheidung, die Graphik in einem bestimmten Farbraum oder nichtlinearen Raum zu rendern, kann von mehreren Leistungsparametern abhängen, die der Kapazität der verschiedenen Komponenten des Graphiksystems entsprechen, und/oder von anderen Parametern von Komponenten abhängen, die sich extern zu dem Graphiksystem befinden.
Nach der Vollendung des Rendering der Graphiken können die Verarbeitungseinheitblöcke 224 und/oder der Display-Engine-Block 240 verschiedene Farbraumkonvertierungen oder Konvertierungen des nichtlinearen Raums bei den gerenderten Graphiken durchführen. Die konvertierten Graphiken können dann mit den Standbild-Bildern und mit dem Video in dem Compositor kombiniert werden, um eine vermischte Videoausgabe zu erzeugen. Der Compositor kann zum Beispiel die Standbild-Bilder des Videodatenstroms empfangen, um zusätzliche gerenderte Graphiken und Erweiterungs- bzw. Verbesserungsinformationen zu jedem Standbild-Bild hinzuzufügen. Die vermischte Videoausgabe kann einem Postprozessor (nicht gezeigt) zugeführt werden. Der Postprozessor kann Farbraumkonvertierungen oder Nichtlinear-Konvertierungen bei dem vermischten Video durchführen, um eine konvertierte Ausgabe zu erzeugen.
Der Display-Engine-Block 240 kann das zusammengesetzte Bild in einem im Chip integrierten Anzeige-Pufferspeicher (nicht gezeigt) erzeugen und kann das zusammengesetzte Bild der Ausgabevorrichtung 124 z.B. zur Anzeige bereitstellen. Das zusammengesetzte Bild, das kombinierte Videobilder und Graphiken umfasst, kann an eine Anzeige durch die Videoausgabeschnittstelle 214 ausgegeben werden, die für die spezielle Anwendung des Graphikskalierungssystems oder der Anzeigevorrichtung relevant ist. Die Videoausgabeschnittstelle 214 kann eine HDMI-Graphik-Verbindung, ein Component Video (Komponentenvideo), A/V, Composite-Verbindungen, koaxiale Verbindungen oder jegliche andere Verbindungen einschließen, die mit einer bestimmten Video-Anzeige kompatibel sind.
Der Display-Engine-Block 240 kann Ausgangssignale in jedem geeigneten Format bereitstellen. Der Display-Engine-Block 240 kann zum Beispiel HD/SD, ITU-R-656 TTX, HDMI oder jedes andere geeignete Format bereitstellen. In einigen Implementierungen umfasst der Display-Engine-Block 240 einen Video-Codierer, der die folgenden Ausgabestandards unterstützt: NTSC-M, NTSC-J, PAL-BDGHIN, PAL-M, PAL-Nc und SECAM. In einigen Implementierungen werden zusätzlich die folgenden Ausgabeformate unterstützt: Composite, S-video, SCART1, SCART2, RGB und YPrPb Component (Komponente), und der Display-Engine-Block 240 kann unter anderem Ausgabeauflösungen von 480i, 480p, 576i, 576p, 720p, 1080i, 1080p, 2K, Ultra-High Definition (UHD), 4K, 8k unterstützen. In einigen Implementierungen sind die High-Quality-Video- und -Graphik-Verarbeitung in einen integrierten Schaltkreis-Chip integriert, der mit der Funktion einer 2D/3D-Graphikverarbeitung ausgestattet ist, während er immer noch eine effiziente Verwendung einer Speicherbandbreite aufrecht erhält.
In einer oder mehreren Implementierungen können der Decodierer 222, der Verarbeitungseinheitblock 224 und/oder der Display-Engine-Block 240 in Software implementiert sein (z.B. Subroutinen und Code). In einer oder mehreren Implementierungen können der Decodierer 222, der Verarbeitungseinheitblock 224 und/oder der Display-Engine-Block 240 in Hardware (z.B. ein anwendungsspezifischer integrierter Schaltkreis (ASIC; Application Specific Integrated Circuit), ein vom Anwender programmierbares Gate-Array (FPGA; Field Programmable Gate Array), ein programmierbarer Logikbaustein (PLD; Programmable Logic Device), ein Controller, eine Zustandsmachine, eine gattergesteuerte Logik, diskrete Hardware-Komponenten oder irgendwelche anderen geeigneten Geräte bzw. Vorrichtungen) und/oder in einer Kombination aus beiden implementiert sein. Weitere Merkmale und Funktionen dieser Module in Übereinstimmung mit verschiedenen Aspekten der erfindungsgegenständlichen Technologie werden in der vorliegenden Offenbarung noch weiter beschrieben werden.
3 veranschaulicht einen Datenfluss für ein beispielhaftes Graphiksystem 300 für eine Pixelspeicherung in graphischen Bildspeichern in Übereinstimmung mit einer oder mehreren Implementierungen. Es müssen aber nicht alle der dargestellten Komponenten verwendet werden, und eine oder mehrere Implementierungen können auch zusätzliche Komponenten umfassen, die in der Figur nicht gezeigt sind. Variationen in der Anordnung und der Art der Komponenten können vorgenommen werden, ohne dass von dem Erfindungsgedanken oder dem Schutzumfang der Ansprüche, wie sie hier dargelegt sind, abgewichen wird. Zusätzliche Komponenten, andere Komponenten oder weniger Komponenten können vorgesehen werden.
Das Graphiksystem 300 weist einen Verarbeitungsblock 310 und den Speicher 226 auf. Der Verarbeitungsblock 310 umfasst einen Dekompressionblock 312, einen Padding-Lösch- bzw. -Verwerfungs-Block 314, einen Verarbeitungseinheitkern 316, einen Block 320 für eine verlustbehaftete Kompression und einen Padding-Einfügungs-Block 318. In einer oder mehreren Implementierungen kann jeder von den CPU-Blöcken 235, dem 3D-Graphics-Engine-Block 237 und dem 2D-Graphics-Engine-Block 239 der Verarbeitungsblock 310 sein oder sie können wenigstens einen Teil davon einschließen. Der Speicher 226 umfasst graphische Bildspeicher 332-1 und 332-2 zum Speichern von verlustbehaftet komprimierten HDR-Pixeldaten, und er umfasst graphische Bildspeicher 334-1 und 334-2 zum Speichern von unkomprimierten HDR-Pixeldaten. Der Dekompressionsblock 312 schließt eine Eingabeschnittstelle mit dem graphischen Bildspeicher 332-1 ein, um die verlustbehaftet komprimierten HDR-Pixeldaten aus der Speicherung zu erhalten. Der Block 320 für die verlustbehaftete Kompression schließt eine Ausgabeschnittstelle zu dem graphischen Bildspeicher 332-2 ein, um die verlustbehaftet komprimierten HDR-Pixeldaten zu speichern. Der Padding-Lösch-Block 314 besitzt eine Eingabeschnittstelle mit dem graphischen Bildspeicher 334-1, um die umkomprimierten HDR-Pixeldaten zu empfangen und jegliches Padding aus dem Pixeldatenrahmen zu entfernen (oder zu löschen bzw. zu verwerfen). Der Padding-Einfügungs-Block 318 besitzt eine Ausgabeschnittstelle mit dem graphischen Bildspeicher 334-2, um Pixeldatenrahmen zu speichern, die ein Padding enthalten, das mit den unkomprimierten HDR-Pixeldaten eingefügt ist. Jeder von dem Dekompressionsblock 312 und dem Padding-Lösch-Block 314 hat eine jeweilige Ausgabeschnittstelle zu dem Verarbeitungseinheitkern 316 für das Durchführen einer Verarbeitung bei den unkomprimierten HDR-Pixeldaten. Jeder von dem Block 320 für die verlustbehaftete Kompression und dem Padding-Einfügungs-Block 318 besitzt eine jeweilige Eingabeschnittstelle mit dem Verarbeitungseinheitkern 316, um die verarbeiteten unkomprimierten HDR-Pixeldaten zu empfangen, um die jeweiligen HDR-Pixeldaten in den Speicher 226 hinein zu speichern.
Während des Betriebs ruft der Verarbeitungsblock 310 Bytes von komprimierten sichtbaren Pixeln, wie etwa die verlustbehaftet komprimierten HDR-Pixeldaten, aus dem graphischen Bildspeicher 332-1 des Speichers 226 ab, er ermittelt das Bild, das den komprimierten sichtbaren Pixeln entspricht, z.B. auf der Basis von wenigstens den Positionsinformationen und der Speicheradresse, aus der die Bytes aus dem Speicher 226 abgerufen wurden, und er kann die komprimierten sichtbaren Pixel in einem anderen graphischen Bildspeicher in dem Speicher 226 speichern, der dem ermittelten Bild zugeordnet ist, wie etwa der graphische Bildspeicher 332-2. Der Verarbeitungsblock 310 kann ein zusammengesetztes Bild erzeugen, z.B. Zeile für Zeile, indem er die entsprechenden komprimierten sichtbaren Pixel aus den entsprechenden graphischen Bildspeichern 332-1 abruft, z.B. basierend auf wenigstens den Positionsinformationen und den Schichtangaben, und indem er die komprimierten HDR-Pixeldaten unter Verwendung eines lokalen Decodierers, wie etwa des Dekompressionsblocks 312, decodiert, z.B. dekomprimiert.
In einigen Implementierungen sind viele nicht anzeigbare Pufferspeicher (z.B. Pufferspeicher, die zusätzliche Daten enthalten) nicht für eine verlustbehaftete Kompression geeignet, da jeglicher Verlust an Informationen gravierende nachteilige Folgen für den Graphik-Rendering-Prozess haben kann. Andere nicht anzeigbare Pufferspeicher können Pixel enthalten, die nicht für eine verlustbehaftete Kompression geeignet sind, da jeglicher Verlust an Informationen die mathematische Exaktheit gefährden kann, die für Konformitätsprüfungen für bestimmte Graphiksysteme (z.B. OpenGL, Vulkan) erwartet wird. Aber da sie nicht anzeigbar sind, haben sie nicht die Echtzeitanforderungen wie anzeigbare Pufferspeicher, und somit können sie für eine verlustfreie Kompression geeignet sein. Aber anzeigbare Pufferspeicher sind letztendlich für die Anzeige auf einem Fernsehgerät oder einem Computermonitor bestimmt. In Anbetracht der Eigenschaften des menschlichen visuellen Systems und der Unvollkommenheiten in den Ende-zu-Ende-Graphiksystemen kann, solange die Qualität der Kompression hoch genug ist, eine verlustbehaftete Kompression für die Verwendung mit anzeigbaren Pufferspeichern geeignet sein.
Um die effektive Anzahl von Bits pro Pixel zu reduzieren, kann eine Kompression der Pixel durchgeführt werden, indem eine statistische Redundanz zwischen Pixeln genutzt wird. Während eine verlustfreie Kompression oftmals die Anzahl von Bits reduzieren kann, die benötigt werden, um eine vorgegebene Anzahl von Pixeln zu repräsentieren, kann in Abhängigkeit von den tatsächlichen Pixeln und ihrer statistischen Verteilung eine verlustfreie Kompression manchmal zu einem Anstieg der Anzahl von Bits führen, die benötigt werden, um die Pixel zu repräsentieren. Dieser Anstieg an Bits kann bedingt sein durch die Zufälligkeit oder durch zusätzliche Informationen, die effektiv in den Pixeln sind, wodurch verursacht wird, dass der Algorithmus für die verlustfreie Kompression die Kompression nicht wie erwartet durchführt. Obwohl es möglich ist, diesem Anstieg eine Obergrenze aufzuerlegen, so dass dieser gerade oberhalb der unkomprimierten Größe nach oben ist, kann keine Annahme gemacht werden, dass eine Anzahl von Bits niedriger als die ursprüngliche Anzahl von Bits ist. Um die Echtzeit-Zugriffs-Anforderungen zu erfüllen. muss dieser Schlimmstfall-Anstieg berücksichtigt werden. Obwohl eine verlustfreie Kompression oftmals die Anzahl von Bits reduziert, die benötigt werden, um Pixel zu repräsentieren, kann eine verlustfreie Kompression für Echtzeit-Zugriffs-Zwecke eher ein Nachteil als ein Vorteil sein.
In einer oder mehreren Implementierungen sieht die erfindungsgegenständliche Technologie ein Verfahren für eine verlustbehaftete Kompression zum Speichern von HDR-Pixeldaten in Graphiksystemen für die Verwendung mit den anzeigbaren graphischen Bildspeichern mit den unten beschriebenen Eigenschaften vor. Wenn zum Beispiel Pixel und/oder Pixelkomponenten in den Speicher 226 als Pixeldaten geschrieben werden, wie etwa durch den Verarbeitungsblock 310, dann kann eine Gruppe von Pixeln zusammen behandelt werden, um die statistische Redundanz innerhalb dieser Pixel zu nutzen. In einer oder mehreren Implementierungen kann der Speicher 226 ein DRAM sein und er kann zum Beispiel einem oder mehreren graphischen Bildspeichern (z.B. 332-1, 332-2, 334-1, 334-2) entsprechen oder diese enthalten. In einer oder mehreren Implementierungen kann eine angestrebte Anzahl von Bits verwendet werden, um die Gruppe von Pixeln zu repräsentieren. Die angestrebte Anzahl von Bits kann zum Beispiel größer als, kleiner als oder gleich groß wie die ursprüngliche Anzahl von Bits sein, die der Gruppe von Pixeln entspricht.
Wie in 3 veranschaulicht ist, beinhaltet der Datenfluss innerhalb des Graphiksystems 300, dass der Verarbeitungsblock 310 komprimierte oder unkomprimierte HDR-Pixel liest und schreibt. Der Verarbeitungsblock 310 kann in Abhängigkeit von Systemanforderungen alle Kombinationen von Eingaben und/oder Ausgaben unterstützen, die komprimiert oder umkomprimiert sind. Obwohl unkomprimierte HDR-Pixeldaten in dem Speicher 226 mit einem Padding gespeichert werden können, kann der Verarbeitungsblock 310 das Padding für die interne Verarbeitung löschen bzw. verwerfen. Und der Block 320 für die verlustbehaftete Kompression kann die echten Daten komprimieren, da jegliche zukünftige Dekompression dieser Daten das Padding (typischerweise Nullen) zum Ausgabezeitpunkt wieder einfügen kann.
In einer oder mehreren Implementierungen kann der Verarbeitungsblock 310 Pixel in den anzeigbaren graphischen Bildspeichern des Speichers 226 unter Verwendung von 10 Bits, 12 Bits oder mehr für jede der R-, G-, B- und A-Komponenten intern in dem Graphiksystem 300 speichern. Aber wenn die Pixeldaten in den Speicher 226 geschrieben werden, wird eine Gruppe von Pixeln (z.B. 4 Pixel mal 4 Pixel für insgesamt 16 Pixel) zusammen gehandhabt, um die statistische Redundanz innerhalb dieser Pixel zu nutzen. Aber kritisch verglichen mit dem oben genannten Fall der verlustfreien Kompression wird eine angestrebte Anzahl von Bits verwendet, die kleiner sein kann als die ursprüngliche Anzahl von Bits, um die Gruppe von Pixeln zu repräsentieren. In einigen Implementierungen ist die angestrebte Anzahl von Bits größer als diese benötigt wird, um die Gruppe von Pixeln zu repräsentieren. In diesem Fall werden aber die benötigten Bits mit einem Padding versehen, um die angestrebte Anzahl von Bits zu erfüllen, und deshalb können die erforderlichen Direktzugriffseigenschaften aufrecht erhalten werden. Wenn mehr als die angestrebte Anzahl von Bits benötigt wird, um die Gruppe von Pixeln zu repräsentieren, dann wird die Anzahl von verwendeten Bits auf die angestrebte Anzahl von Bits begrenzt. In einigen Aspekten wird eine Teilmenge der Informationen verworfen, und der Verarbeitungsblock 310 versucht, Informationen zu verwerfen bzw. zu löschen, die visuell nicht signifikant sind. Im Vergleich zu dem Algorithmus für die verlustfreie Kompression, der mathematischidentische ursprüngliche und später dekomprimierte komprimierte Pufferspeicher produzieren kann, kann der Algorithmus für die verlustbehaftete Kompression eine visuell (aber nicht mathematisch identische) verlustfreie Kompression vorsehen.
In einigen Implementierungen kann die angestrebte Anzahl von Bits ein Zweierpotenz- Wert sein (z.B. 32, 64, 128, etc) und sie kann auf einem Kompressionsverhältnis basieren. Wenn die angestrebte Anzahl von Bits zu klein ist, kann das Kompressionsverhältnis zu hoch sein, und somit ist dies nachteilig für die visuelle Qualität. Die erfindungsgegenständliche Technologie sieht das Bestimmen der geeigneten angestrebten Anzahl von Bits vor, um eine ausreichende visuelle Qualität zu erzielen. In einer oder mehreren Implementierungen basiert die angestrebte Anzahl von Bits auf einem Vielfachen der DRAM-Burst-Größe. Die DRAM-Burst-Größe kann zum Beispiel als eine Burst-Länge bezeichnet werden, die beim Senden von Daten zu dem Speicher 226 verwendet wird.
Das Kompressionsverhältnis kann die tatsächliche Anzahl von Bits im Verhältnis zu der angestrebten Anzahl von Bits sein. Der Stand der Technik für Kompressionsverhältnisse liegt bei etwa 10:1, aber der Verhältniswert kann in Abhängigkeit von einer Implementierung variieren. Da das erfindungsgegenständliche System dafür konfiguriert ist, einen kleinen Block (z.B. 4x4-Pixel-Block) zu verarbeiten und die Bildverarbeitung relativ in Echtzeit durchgeführt wird, kann das Ziel des erfindungsgegenständlichen Systems bei 2:1 konservativer sein als im Vergleich zum Stand der Technik bei 10:1. Tatsächlich können Kompressionsverhältnisse von 10:1 zum Beispiel mit einer solch relativ kleinen Anzahl von Pixeln für die Verarbeitung nicht durchführbar sein, weil es keine ausreichende Redundanz in diesen Pixeln gibt, um die Kompression effektiv auszunutzen.
4 veranschaulicht einen unkomprimierten graphischen Bildspeicher 334 und einen entsprechenden komprimierten graphischen Bildspeicher 332 in Übereinstimmung mit einer oder mehreren Implementierungen. Es müssen aber nicht alle der dargestellten Komponenten verwendet werden, und eine oder mehrere Implementierungen können auch zusätzliche Komponenten umfassen, die in der Figur nicht gezeigt sind. Variationen in der Anordnung und der Art der Komponenten können vorgenommen werden, ohne dass von dem Erfindungsgedanken oder dem Schutzumfang der Ansprüche, wie sie hier dargelegt sind, abgewichen wird. Zusätzliche Komponenten, andere Komponenten oder weniger Komponenten können vorgesehen werden.
Der unkomprimierte graphische Bildspeicher 334 kann in einigen Implementierungen einem anzeigbaren Pufferspeicher entsprechen, der HDR-Pixeldaten für die Anzeige enthält, oder er kann in anderen Implementierungen einem nicht anzeigbaren Pufferspeicher entsprechen, der zusätzliche Daten (nicht für das Anzeigen) enthält. In einigen Implementierungen entspricht der komprimierte graphische Bildspeicher 332 dem anzeigbaren Pufferspeicher, der verlustbehaftet komprimierte HDR-Pixeldaten enthält. Der komprimierte graphische Bildspeicher 332 kann komprimierte HDR-Daten enthalten, die dann, wenn sie dekomprimiert sind, dem gleichen Block von HDR-Pixeldaten des entsprechenden unkomprimierten graphischen Bildspeichers 334 entsprechen.
In einer oder mehreren Implementierungen kann der graphische Bildspeicher 334 Pixeldaten speichern, die ein erstes Pixelformat haben, das für HDR-Graphiksysteme in Betracht gezogen wird und das allgemein als RGB10_A2 bezeichnet werden kann. In einem einzigen 32-Bit-Wort umfasst das erste Pixelformat zum Beispiel die Rot-, Grün- und Blau-Komponenten, die jeweils mit 10 Bits gepackt sind, und eine Alpha-Komponente, die zwei Bits hat. Im Allgemeinen sind zwei Bits für die Alpha-Komponente nicht ausreichend, um ein ordentliches Blending (Vermischen) durchzuführen. Aber ein Reservieren von 10 Bits für die Alpha-Komponente passt nicht in das erste Pixelformat. Das erste Pixelformat erfüllt die Pack-, Effizienz-, Direktzugriffs- und Echtzeitzugriffs-Anforderungen, aber mit nur zwei Bits, die für Alpha zur Verfügung stehen, erfüllt das erste Pixelformat nicht die Auflösung, die in Alpha benötigt wird, um adäquat für eine moderne Benutzerschnittstelle verwendet zu werden.
In einer oder mehreren Implementierungen kann der graphische Bildspeicher 334 Pixeldaten speichern, die ein zweites Pixelformat haben, das für HDR-Graphiksysteme in Betracht gezogen wird und das allgemein als RGBA10x6 bezeichnet werden kann. Zum Beispiel hat jede von den R-, G-, B- und A-Komponenten 10 Bits, aber jede ist auf 16 Bits mit einem Padding aufgefüllt, um in ein 16-Bit-Halbwort pro Komponente zu passen, so dass das gesamte Pixel in 64 Bits für Pack- und Direktzugriffszwecke passt. Dies stellt den Vorteil bereit, dass 10 Bits pro Komponente bereitgestellt werden können, aber mit 40 Bits an Informationen nimmt das zweite Pixelformat 64 Bits eines DRAM ein. In dieser Hinsicht ist die Effizienz des zweiten Pixelformats niedrig, da 24 Bits von 64 Bits ungenutzt bleiben. Auch durch das Verlangen von 64 Bits pro Pixel wird die Menge an Speicher und Bandbreite, die benötigt werden, im Vergleich zu SDR-Graphiksystemen und dem ersten Pixelformat verdoppelt. In dieser Hinsicht sieht das zweite Pixelformat eine geringe Effizienz vor, und durch eine Erweiterung auch hohe Kosten bedingt durch die Extra-Lesestellen in dem DRAM, die keine nützlichen und gültigen Informationen enthalten.
In einer oder mehreren Implementierungen kann der graphische Bildspeicher 334 Pixeldaten speichern, die ein drittes Pixelformat haben, das für HDR-Graphiksysteme in Betracht gezogen wird und das allgemein als RGBA10 bezeichnet werden kann. Zum Beispiel hat jede von den R-, G-, B- und A-Komponenten 10 Bits, aber jede Komponente ist im Vergleich zum zweiten Pixelformat nicht durch ein Padding auf 16 Bits aufgefüllt. Vielmehr ist jede 10-Bit-Komponente aufeinanderfolgend gepackt, um 40 Bits in einer Dateneinheit, wie etwa einem 64-Bit-Wort, zu bilden, und packt einen Teil des nächsten Pixels in eben dieses 64-Bit-Wort. Zum Beispiel belegt ein erstes Pixel 40 Bits von den 64 Bits, und die restlichen 24 Bits werden für die R- und G-Komponenten eines zweiten Pixels und vier Bits der B-Komponente des zweiten Pixels verwendet. Die restlichen 6 Bits der B-Komponente und die Alpha-Komponente des zweiten Pixels werden in einer anderen Dateneinheit gespeichert, wie etwa in einem weiteren 64-Bit-Wort. Dieser Prozess wird dann in dem nächsten 64-Bit-Wort wiederholt. Das dritte Pixelformat ist effizienter als das zweite Pixelformat, da das dritte Pixelformat weniger Raum einnimmt und dadurch weniger Bits vergeudet. Aber das dritte Pixelformat kann die Fähigkeit beeinträchtigen, einen Direktzugriff durchführen zu können, so dass die Methodik der erfindungsgegenständlichen Technologie das Auslesen von mehreren Pixeln gleichzeitig (z.B. mehrere 64-Bits-Dateneinheiten) aus dem Speicher erfordern kann, um die angestrebte Anzahl von Bits zu extrahieren.
In einer oder mehreren Implementierungen kann der graphische Bildspeicher 334 Pixeldaten speichern, die ein viertes Pixelformat haben, das für HDR-Graphiksysteme in Betracht gezogen wird und das allgemein als FP16 bezeichnet werden kann. FP16 ist ein Gleitkomma-Pixelformat, bei dem jede der RGBA-Komponenten mit einer Gleitkommazahl dargestellt wird, die in 16 Bits gespeichert wird. In einigen Aspekten benötigt das gesamte RGBA-FP16-Pixel 64 Bits für die Speicherung. Das vierte Pixelformat hat eine ausreichende Auflösung, um HDR-Pixel darstellen zu können. Aber mit seiner Erfordernis zum Speichern von 64 Bits pro Pixel hat das vierte Pixelformat ein äquivalente niedrige Effizient wie das zweite Pixelformat. Im Vergleich zu SDR-Systemen und dem ersten Pixelformat benötigt das vierte Pixelformat auch das Doppelte der Menge an Speicher und Bandbreite, und durch Erweiterung sind die Kosten hoch.
Der unkomprimierte graphische Bildspeicher 334 kann Pixeldaten mit unkomprimiertem Packen speichern. Der unkomprimierte graphische Bildspeicher 334 kann zum Beispiel Pixeldaten speichern, die das zweite Pixelformat, nämlich RGBA10x6, haben, bei dem die Pixeldaten-Bits mit 10 Bits pro Komponente RGBA gepackt sind. In diesem Format sind pro Komponente 10 Bits als reale Daten repräsentiert und sind 6 Bits als Padding repräsentiert. Wenn der unkomprimierte graphische Bildspeicher 334 einen Block von Pixeldaten speichert, wie etwa eine 4x4-Gruppe von Pixeln, kann der gepackte Block von Pixeldaten insgesamt 1024 Bits enthalten, wenn er mit dem zweiten Pixelformat dargestellt wird. In einigen Implementierungen kann der unkomprimierte graphische Bildspeicher 334 alternativ dazu Pixeldaten speichern, die das dritte Pixelformat, nämlich RGBA10, haben, bei dem die Pixeldaten-Bits in Aufeinanderfolge mit 10 Bits pro Komponente RGBA gepackt sind. Wenn der unkomprimierte graphische BildSpeicher 334 einen Block von Pixeldaten speichert, wie etwa die 4x4-Gruppe aus Pixeln, kann der gepackte Block von Pixeldaten insgesamt 640 Bits umfassen.
Da der unkomprimierte graphische Bildspeicher 334 unkomprimierte Pixeldaten in einer Speichereinheit (z.B. 64-Bit-Wort) speichern kann, die mehr als einem einzigen HDR-Pixel entsprechen, wird auf mehrere Speichereinheiten von dem DRAM (die einem Block von unkomprimierten HDR-Pixeldaten entsprechen) zugegriffen und werden diese mit dem Algorithmus für die verlustbehaftete Komprimierung verarbeitet, um einen entsprechenden Block von komprimierten HDR-Pixeldaten auszugeben. In dieser Hinsicht speichert der komprimierte graphische Bildspeicher 332 komprimierte Daten, die einer angestrebten Anzahl von Bits entsprechen. In einer oder mehreren Implementierungen kann die angestrebte Anzahl von Bits verwendet werden, um die Gruppe von Pixeln zu repräsentieren. Die angestrebte Anzahl von Bits kann zum Beispiel größer als, kleiner als oder gleich groß wie die ursprüngliche Anzahl von Bits sein, die der Gruppe von Pixeln entsprechen.
In einer oder mehreren Implementierungen kann eine Gruppe von Pixeln (z.B. ein 4x4-Block von Pixeln) aus einer Vielzahl von Pixeln in einem DRAM (oder dem Speicher 226) unter Verwendung einer angestrebten Anzahl von Bits gespeichert werden. Die angestrebte Anzahl von Bits kann so ausgewählt werden, dass sie einen vorteilhaften Betrag an Kompression bereitstellt, und sie kann so konzipiert werden, dass sie gut in den Speicher gepackt werden kann. Die 4x4-Gruppe von Pixeln kann in unkomprimierter Form 640 Bits mit dem dritten Pixelformat umfassen. Diese Gruppe von Pixeln kann unter Verwendung eines Algorithmus für eine verlustbehaftete Kompression, der von dem Block 320 für eine verlustbehaftete Kompression durchgeführt wird (3), herunter auf eine angestrebte Anzahl von Bits basierend auf einem Kompressionsverhältnis komprimiert werden. Auf der Basis eines Kompressionsverhältnisses von etwa 2,5:1, und wenn die ursprüngliche Anzahl von Bits, die der Gruppe von Pixeln entspricht, 640 Bits ist, kann die angestrebte Anzahl von Bits so ausgewählt werden, dass sie zum Beispiel 256 Bits ist. Dies ist äquivalent zu 16 Bits pro Pixel. In anderen Beispielen kann die angestrebte Anzahl von Bits dann, wenn das Kompressionsverhältnis bei etwa 1,25:1 liegt, so ausgewählt werden, dass sie 512 Bits ist. In noch anderen Beispielen kann die angestrebte Anzahl von Bits dann, wenn das Kompressionsverhältnis bei etwa 5:1 liegt, so ausgewählt werden, dass sie 128 Bits ist (wenn die ursprüngliche Anzahl von Bits, die der Gruppe von Pixeln entspricht, 640 Bits ist). In anderen Implementierungen kann die angestrebte Anzahl von Bits einem Vielfachen der DRAM-Burst-Größe entsprechen. Die angestrebte Anzahl von Bits kann in einigen Implementierungen einem Zweierpotenz-Wert (z.B. 16, 32, 64, 128, 256, 512, etc.) entsprechen, oder sie kann in anderen Implementierungen einem Wert eines Vielfachen von zwei entsprechen.
In einem Beispiel kann eine Gruppe von Pixeln als ein Block verarbeitet werden. Wie in 4 veranschaulicht ist, umfasst ein Block 410 einen NxM-Block von unkomprimierten HDR-Pixeldaten. Der Block 410 kann eine 4x4-Gruppe von Pixeln enthalten, die in einen entsprechenden NxM-Block von komprimierten HDR-Pixeldaten (z.B. 420) komprimiert werden kann. Der Block 410 kann zum Beispiel 640 Bits an unkomprimierten HDR-Pixeldaten enthalten, wobei jedes von den 16 Pixeln 10 Bits pro Komponente (R, G, B, A) umfasst. Der Block 410 von unkomprimierten HDR-Pixeldaten muss in eine bekannte Anzahl von Bits in dem DRAM passen (z.B. eine angestrebte Anzahl von 256 Bits). Vorausgesetzt, dass die Gruppe von Pixeln 640 Bits an Informationen enthält, die in einen 256-Bit-Block in dem DRAM passen müssen, wird ein Algorithmus für eine verlustbehaftete Kompression an diesen unkomprimierten Block von Informationen angelegt, um jegliche Informationen zu entfernen, die visuell weniger wichtig sind. Das Ziel des verlustbehafteten Kompressionsvorgangs ist, komprimierte Daten auszugeben, die äquivalent zu dem angestrebten Betrag an Bits sind (z.B. 256 Bits). In einigen Implementierungen kann ein Block von komprimierten Daten ein gewisses Padding benötigen, um zu gewährleisten, dass der komprimierte Block von Daten der angestrebten Anzahl von Bits entspricht (z.B. 256 Bits enthält). Wenn der unkomprimierte Block von Daten zusätzliche Informationen enthält, die über das hinausgehen, was für eine Kompression benötigt wird, dann wird der komprimierte Block von Daten immer noch auf die angestrebte Anzahl von Bits begrenzt, um die Konformität mit der Speicherzuordnung in dem DRAM aufrecht zu erhalten. In einigen Implementierungen ist die komprimierte Ausgabe ungeachtet der Art von Information (oder der Art von Pixeln), die in einer Gruppe von Pixeln enthalten ist, ein bekannter Bit-Wert (oder äquivalent zu der angestrebten Anzahl von Bits).
5A bis 5C veranschaulichen Ablaufdiagramme von jeweiligen beispielhaften Pixelspeicherungsprozessen eines Systems für eine Pixelspeicherung in graphischen Bildspeichern in Übereinstimmung mit einer oder mehreren Implementierungen, wobei 5A ein Ablaufdiagramm eines beispielhaften Pixelspeicherungsprozesses 510 veranschaulicht, 5B ein Ablaufdiagramm eines beispielhaften Pixelspeicherungsprozesses 500 veranschaulicht und 5C ein Ablaufdiagramm eines beispielhaften Pixelspeicherungsprozesses 530 veranschaulicht. Zu Zwecken der Erläuterung werden die beispielhaften Pixelspeicherungsprozesse 510, 520 und 530 hier primär unter Bezugnahme auf den Verarbeitungsblock 310 von 3 beschrieben; aber die beispielhaften Pixelspeicherungsprozesse 510, 520 und 530 sind nicht auf den Verarbeitungsblock 310 von 3 begrenzt, und die beispielhaften Pixelspeicherungsprozesse 510, 520 und 530 können durch eine oder mehrere andere Komponenten der elektronischen Vorrichtung 120 durchgeführt werden. Des Weiteren werden die Blöcke der beispielhaften Pixelspeicherungsprozesse 510, 520 und 530 zu erläuternden Zwecken hier so beschrieben, dass sie seriell oder linear stattfinden. Aber mehrere Blöcke der beispielhaften Pixelspeicherungsprozesse 510, 520 und 530 können parallel stattfinden. Außerdem können die Blöcke der beispielhaften Pixelspeicherungsprozesse 510, 520 und 530 in einer anderen Reihenfolge als in der gezeigten Reihenfolge durchgeführt werden, und/oder einer oder mehrere der Blöcke der beispielhaften Pixelspeicherungsprozesse 510, 520 und 530 werden nicht durchgeführt.
In 5A startet der Prozess 510 beim Schritt 511, in dem der Verarbeitungsblock 310 einen empfangenen Videodatenstrom (z.B. 212) decodiert. Als nächstes erhält der Verarbeitungsblock 310 im Schritt 512 eine Gruppe von Pixeln von dem decodierten Videodatenstrom. Danach packt der Verarbeitungsblock 310 im Schritt 513 die Gruppe von Pixeln gemäß einem Pixelformat auf der Basis eines Speicherungsformats. Das Speicherungsformat kann einer Speicherzugriffsgröße (z.B. ein 32-Bit-Wort-Zugriff) entsprechen. Als nächstes stellt der Verarbeitungsblock 310 beim Schritt 514 fest, ob das Pixelformat der Gruppe von Pixeln ein Padding benötigt. Wenn das Pixelformat ein Padding benötigt, geht der Prozess 510 weiter zu Schritt 515. Anderenfalls geht der Prozess 510 weiter zum Schritt 516. Beim Schritt 515 fügt der Verarbeitungsblock 310 ein oder mehrere Padding-Bits zu der Gruppe von Pixeln gemäß dem Pixelformat hinzu. Danach speichert der Verarbeitungsblock beim Schritt 516 die Gruppe von Pixeln mit dem Pixelformat in einen graphischen Bildspeicher (z.B. 334) in dem DRAM (z.B. 226) hinein.
In 5B startet der Prozess 520 beim Schritt 521, in dem der Verarbeitungsblock 310 einen Block von komprimierten Pixeldaten aus einem ersten Bildspeicher (z.B. 332-1) in einem DRAM (z.B. 226) decodiert. Als nächstes verarbeitet der Verarbeitungsblock 310 beim Schritt 522 den Block von decodierten Pixeldaten. Danach bestimmt der Verarbeitungsblock 310 beim Schritt 523 eine angestrebte Anzahl von Bits, um eine Anzahl von Bits zu repräsentieren, die dem verarbeiteten Block von Pixeldaten entsprechen. In einigen Aspekten unterscheidet sich die angestrebte Anzahl von Bits von der Anzahl von Bits. Als nächstes führt der Verarbeitungsblock 310 im Schritt 524 einen verlustbehafteten Kompressionsvorgang bei dem verarbeiteten Block von Pixeldaten durch, um komprimierte Pixeldaten unter Verwendung der angestrebten Anzahl von Bits auszugeben. Danach speichert der Verarbeitungsblock 310 beim Schritt 525 die komprimierten Pixeldaten in einen zweiten graphischen Bildspeicher (z.B. 334-2) in dem DRAM hinein.
In 5C startet der Prozess 530 bei dem Schritt 531, in dem der Verarbeitungsblock 310 einen Block von unkomprimierten Pixeldaten aus einem ersten graphischen Bildspeicher (z.B. 334-1) in dem DRAM (z.B. 226) erhält. Als nächstes verwirft bzw. löscht der Verarbeitungsblock 310 in dem Schritt 532 jegliches Padding aus dem Block von unkomprimierten Pixeldaten gemäß einem Pixelformat des Blocks von unkomprimierten Pixeldaten. Danach verarbeitet der Verarbeitungsblock 310 beim Schritt 533 den Block von unkomprimierten Pixeldaten. Als nächstes stellt der Verarbeitungsblock 310 in dem Schritt 534 fest, ob das Pixelformat des Blocks von unkomprimierten Pixeldaten ein Padding benötigt. Wenn das Pixelformat ein Padding benötigt, geht der Prozess 530 weiter zum Schritt 535. Anderenfalls geht der Prozess 530 weiter zu dem Schritt 536. Im Schritt 535 fügt der Verarbeitungsblock 310 ein oder mehrere Padding-Bits zu dem Block von unkomprimierten Pixeldaten gemäß dem Pixelformat hinzu. Danach speichert der Verarbeitungsblock 310 beim Schritt 536 den Block von unkomprimierten Pixeldaten mit dem Pixelformat in einen zweiten graphischen Bildspeicher (z.B. 334-2) in dem DRAM (z.B. 226) hinein.
6 veranschaulicht konzeptionell ein elektronisches System 600, mit dem eine oder mehrere Implementierungen der erfindungsgegenständlichen Technologie implementiert werden kann bzw. können. Das elektronische System 600 kann zum Beispiel ein Netzwerkgerät, ein Medienkonverter, ein Schreibtisch-Computer, ein Laptop-Computer, ein Tablet-Computer, ein Server, ein Smartphone oder allgemein irgendeine elektronische Vorrichtung sein, die Video- und/oder Audiodatenströme codiert und/oder decodiert. Ein solches elektronisches System 600 umfasst verschiedene Arten von computerlesbaren Medien und Schnittstellen für verschiedene andere Arten von computerlesbaren Medien. Das elektronische System 600 umfasst einen Bus 608, eine oder mehrere Verarbeitungseinheit(en) 612, einen Systemspeicher 604, einen Nur-Lese-Speicher (ROM; Read Only Memory) 610, ein Permanentspeichergerät 602, eine Eingabevorrichtungsschnittstelle 614, eine Ausgabevorrichtungsschnittstelle 606 und eine Netzwerkschnittstelle 616 oder Teilmengen und Variationen davon.
Der Bus 608 repräsentiert kollektiv alle System-, Peripherie- und Chipsatz-Busse, die die zahlreichen internen Vorrichtungen und Geräte des elektronischen Systems 600 kommunikativ verbinden. In einer oder mehreren Implementierungen verbindet der Bus 608 kommunikativ die eine oder die mehreren Verarbeitungseinheit(en) 612 mit dem ROM 610, dem Systemspeicher 604 und dem Permanentspeichergerät 602. Aus diesen verschiedenen Speichereinheiten ruft bzw. rufen die eine oder die mehreren Verarbeitungseinheit(en) 612 Anweisungen zum Ausführen und Daten zum Verarbeiten ab, um die Prozesse der erfindungsgegenständlichen Offenbarung auszuführen. Die eine oder die mehreren Verarbeitungseinheit(en) 612 kann bzw. können in unterschiedlichen Implementierungen ein einzelner Prozessor oder ein Multi-Core-Prozessor sein.
Der ROM 610 speichert statische Daten und Anweisungen, die von der einen oder den mehreren Verarbeitungseinheit(en) 612 und von anderen Modulen des elektronischen Systems benötigt werden. Das Permanentspeichergerät 602 andererseits ist eine Lese-und-Schreib-Speichervorrichtung. Das Permanentspeichergerät 602 ist eine nichtflüchtige Speichereinheit, die Anweisungen und Daten speichert, selbst wenn das elektronische System 600 ausgeschaltet ist. Eine oder mehrere Implementierungen der erfindungsgegenständlichen Offenbarung verwenden eine Massenspeichervorrichtung (wie etwa eine Magnetplatte oder eine optische Speicherplatte und deren entsprechendes Plattenlaufwerk) als das Permanentspeichergerät 602.
Andere Implementierungen verwenden eine entfernbare Speicherungsvorrichtung (wie etwa eine Floppy Disk, einen Speicher-Stick und das entsprechende Diskettenlaufwerk) als das Permanentspeichergerät 602. Wie das Permanentspeichergerät 602 ist auch der Systemspeicher 604 eine Lese-und-Schreib-Speichervorrichtung. Aber anders als das Permanentspeichergerät 602 ist der Systemspeicher 604 ein flüchtiger Lese-und-Schreib-Speicher, wie etwa ein Direktzugriffsspeicher. Der Systemspeicher 604 speichert alle Anweisungen und Daten, die die eine oder die mehreren Verarbeitungseinheit(en) 612 während der Laufzeit benötigen. In einer oder mehreren Implementierungen werden die Prozesse der erfindungsgegenständlichen Offenbarung in dem Systemspeicher 604, dem Permanentspeichergerät 602 und/oder dem ROM 610 gespeichert. Aus diesen verschiedenen Speichereinheiten ruft bzw. rufen die eine oder die mehreren Verarbeitungseinheit(en) 612 Anweisungen zum Ausführen und Daten zum Verarbeiten ab, um die Prozesse von einer oder mehreren Implementierungen auszuführen.
Der Bus 608 verbindet auch mit der Eingabevorrichtungsschnittstelle 614 und der Ausgabevorrichtungsschnittstelle 606. Die Eingabevorrichtungsschnittstelle 614 ermöglicht es einem Benutzer, Informationen zu dem elektronischen System zu kommunizieren und Befehle für das elektronische System auszuwählen. Eingabevorrichtungen, die mit der Eingabevorrichtungsschnittstelle 614 verwendet werden, schließen zum Beispiel alphanumerische Tastaturen und Zeigegeräte (die auch „Cursorsteuerungsvorrichtungen“ genannt werden) ein. Die Ausgabevorrichtungsschnittstelle 606 ermöglicht zum Beispiel die Anzeige von Bildern, die durch das elektronische System 600 erzeugt werden. Ausgabevorrichtungen, die mit der Ausgabevorrichtungsschnittstelle 606 verwendet werden, umfassen zum Beispiel Drucker und Anzeigegeräte wie etwa eine Flüssigkristallanzeige (LCD; Liquid Crystal Display), eine LED-(lichtemittierende Dioden)-Anzeige, eine OLED-(organische lichtemittierende Dioden)-Anzeige, eine flexible Anzeige, eine Flachbildschirmanzeige, eine Festkörperanzeige, einen Projektor oder irgendeine andere Vorrichtung zum Ausgeben von Informationen. Eine oder mehrere Implementierungen können Vorrichtungen und Geräte einschließen, die sowohl als Eingabe- wie auch als Ausgabevorrichtungen funktionieren, wie etwa ein Touchscreen (Berührungsbildschirm). In diesen Implementierungen kann eine Rückmeldung, die dem Benutzer bereitgestellt wird, jede Form von sensorischer Rückmeldung sein, wie etwa eine visuelle Rückmeldung, eine auditive Rückmeldung oder eine taktile Rückmeldung; und eine Eingabe von dem Benutzer kann in jeglicher Form empfangen werden, die eine akustische, sprachliche oder taktile Eingabe einschließt.
Schließlich koppelt der Bus 608, wie in 6 gezeigt ist, das elektronische System 600 auch mit einem oder mehreren Netzwerken (nicht gezeigt) durch eine oder mehrere Netzwerkschnittstellen 616. Auf diese Weise kann der Computer ein Teil von einem oder mehreren Netzwerken von Computern sein, wie etwa von einem Peer-to-Peer-Netzwerk, einem lokalen Netzwerk („LAN“), einem Weitbereichsnetzwerk („WAN“) oder einem Intranet, oder von einem Netzwerk von Netzwerken, wie etwa das Internet. Jegliche oder alle Komponenten des elektronischen Systems 600 können in Verbindung mit der erfindungsgegenständlichen Offenbarung verwendet werden.
Implementierungen innerhalb des Schutzumfangs der vorliegenden Offenbarung können teilweise oder vollständig unter Verwendung eines greifbaren computerlesbaren Speichermediums (oder von mehreren greifbaren computerlesbaren Speichermedien von einer oder mehreren Arten), die eine oder mehrere Anweisungen codieren, realisiert werden. Das greifbare computerlesbare Speichermedium kann vom Wesen her auch nichtflüchtig sein.
Das computerlesbare Speichermedium kann jedes Speichermedium sein, das gelesen, beschrieben werden kann oder auf das auf andere Weise durch eine Universalrechenvorrichtung oder eine Spezialrechenvorrichtung zugegriffen werden kann, was jegliche Verarbeitungselektronik und/oder Verarbeitungsschaltungen einschließt, die in der Lage sind, Anweisungen ausführen zu können. Das computerlesbare Medium kann zum Beispiel, ohne dass dies eine Einschränkung darstellt, jeglichen flüchtigen Halbleiterspeicher einschließen, wie etwa RAM, DRAM, SRAM, T-RAM, Z-RAM, und TTRAM. Das computerlesbare Medium kann auch jeglichen nichtflüchtigen Halbleiterspeicher einschließen, wie etwa ROM, PROM, EPROM, EEPROM, NVRAM, Flash, nvSRAM, FeRAM, FeTRAM, MRAM, PRAM, CBRAM, SONOS, RRAM, NRAM, Racetrack-Speicher, FJG und Millipede-Speicher.
Des Weiteren kann das computerlesbare Speichermedium jeglichen Nicht-HalbleiterSpeicher einschließen, wie etwa einen optischen Plattenspeicher, einen Magnetplattenspeicher, ein Magnetband, andere magnetische Speichervorrichtungen oder irgendein anderes Medium, das eine oder mehrere Anweisungen speichern kann. In einigen Implementierungen kann das greifbare computerlesbare Speichermedium direkt mit einer Rechenvorrichtung gekoppelt sein, während in anderen Implementierungen das greifbare computerlesbare Speichermedium indirekt mit einer Rechenvorrichtung über zum Beispiel eine oder mehrere drahtgebundene Verbindungen, eine oder mehrere drahtlose Verbindungen oder über irgendeine Kombination davon verbunden sein kann.
Anweisungen können direkt ausführbar sein oder sie können verwendet werden, um ausführbare Anweisungen zu entwickeln. Anweisungen können zum Beispiel als ein ausführbarer oder nicht ausführbarer Maschinencode oder als Anweisungen in einer höheren Programmiersprache realisiert werden, die kompiliert werden können, um einen ausführbaren oder einen nicht ausführbaren Maschinencode zu erzeugen. Des Weiteren können Anweisungen auch als Daten realisiert werden oder sie können Daten umfassen. Von einem Computer ausführbare Anweisungen können auch in jeglichem Format organisiert sein, das Routinen, Subroutinen, Programme, Datenstrukturen, Objekte, Module, Anwendungen, Applets, Funktionen, etc. einschließt. Wie von den Fachleuten auf dem Gebiet erkannt wird, können Einzelheiten, die die Anzahl, Struktur, Sequenz und Organisation von Anweisungen einschließen, aber nicht darauf beschränkt sind, beträchtlich variieren, ohne dass die zugrundeliegende Logik, Funktion, Verarbeitung und Ausgabe variiert wird.
Obwohl sich die obige Erörterung primär auf einen Mikroprozessor oder auf Multi-Core-Prozessoren bezieht, die eine Software ausführen, wird bzw. werden eine oder mehrere Implementierungen durch einen oder mehrere integrierte Schaltkreise durchgeführt, wie etwa durch anwendungsspezifische integrierte Schaltkreise (ASICs) oder durch vom Anwender programmierbare Gate-Arrays (FPGAs). In einer oder mehreren Implementierungen führen solche integrierten Schaltkreise Anweisungen aus, die in dem Schaltkreis selbst gespeichert sind.
Die Fachleute auf dem Gebiet würden erkennen, dass die verschiedenen veranschaulichenden Blöcke, Module, Elemente, Komponenten, Verfahren und Algorithmen, die hier beschrieben worden sind, als elektronische Hardware, Computer-Software oder als Kombinationen von beiden implementiert werden können. Zur Veranschaulichung dieser Austauschbarkeit von Hardware und Software sind verschiedene veranschaulichende Blöcke, Module, Elemente, Komponenten, Verfahren und Algorithmen oben allgemein in Bezug auf ihre Funktionalität beschrieben werden. Ob eine solche Funktionalität als Hardware oder Software implementiert wird, hängt von der speziellen Anwendung und den Design-Beschränkungen ab, die dem Gesamtsystem auferlegt sind. Fachleute können die beschriebene Funktionalität auf unterschiedliche Arten für jede spezielle Anwendung implementieren. Verschiedene Komponenten und Blöcke können unterschiedlich angeordnet werden (z.B. in einer anderen Reihenfolge angeordnet oder auf eine andere Weise aufgeteilt), und dies alles, ohne dass von dem Schutzumfang der erfindungsgegenständlichen Technologie abgewichen wird.
Es ist selbstverständlich, dass jegliche spezifische Reihenfolge oder Hierarchie von Blöcken in den offenbarten Prozessen eine Veranschaulichung von beispielhaften Lösungsansätzen ist. Es ist klar, dass die spezifische Reihenfolge oder Hierarchie von Blöcken in den Prozessen basierend auf Design-Vorlieben neu angeordnet bzw. umgeordnet werden kann, oder dass alle veranschaulichten Blöcke durchgeführt werden können. Alle von den Blöcken können gleichzeitig durchgeführt werden. In einer oder mehreren Implementierungen können ein Multitasking und eine parallele Verarbeitung vorteilhaft sein. Darüber hinaus sollte die Trennung von verschiedenen Systemkomponenten in den oben beschriebenen Ausführungsformen nicht so verstanden werden, dass eine solche Trennung in allen Ausführungsformen notwendig ist, und es sollte klar sein, dass die beschriebenen Programmkomponenten und Systeme allgemein zusammen in einem einzigen Software-Erzeugnis integriert sein können oder in mehrere Software-Erzeugnisse gepackt werden können.
So, wie sie hier in der vorliegenden Patentspezifikation und in irgendwelchen Ansprüchen der vorliegenden Anmeldung verwendet sind, beziehen sich die Begriffe „Prozessor“ und „Speicher“ alle auf elektronische oder andere technologische Vorrichtungen bzw. Geräte. Diese Begriffe schließen Personen oder Gruppen von Personen aus. Für die Zwecke der Patentspezifikation bedeuten die Begriffe „Anzeige“ oder „Anzeigen“ das Anzeigen auf einer elektronischen Vorrichtung bzw. einem elektronischen Gerät.
In einer oder mehreren Implementierungen kann ein Prozessor, der dafür konfiguriert ist, einen Vorgang oder eine Komponente zu überwachen und zu steuern, auch bedeuten, dass der Prozessor dafür programmiert ist, den Vorgang zu überwachen und zu steuern, oder dass der Prozessor dahingehend betreibbar ist, den Vorgang zu überwachen und zu steuern. Gleichermaßen kann ein Prozessor, der dafür konfiguriert ist, einen Code auszuführen, auch als ein Prozessor interpretiert werden, der dafür programmiert ist, einen Code auszuführen, oder der dahingehend betätigbar ist, einen Code auszuführen.

Claims

Vorrichtung, die Folgendes aufweist: wenigstens einen Prozessor, der dafür konfiguriert ist: eine Vielzahl von Dateneinheit zu erhalten, die eine Vielzahl von Pixeln enthalten, die in einem Speicher gespeichert sind, wobei jede von der Vielzahl von Dateneinheiten ein erstes Pixel von der Vielzahl von Pixeln gepackt in Aufeinanderfolge mit wenigstens einem Teil eines zweiten Pixels von der Vielzahl von Pixeln umfasst, wobei die Vielzahl von Pixeln durch eine Anzahl von Bits repräsentiert wird; eine Gruppe von Pixeln aus der Vielzahl von Pixeln zu erhalten; und die Gruppe von Pixeln unter Verwendung einer angestrebten Anzahl von Bits zu speichem.
Vorrichtung nach Anspruch 1, wobei sich die angestrebte Anzahl von Bits von der Anzahl von Bits unterscheidet.
Vorrichtung nach Anspruch 1, wobei der wenigstens eine Prozessor dafür konfiguriert ist: einen verlustbehafteten Kompressionsvorgang an die Vielzahl von Pixeln anzulegen; und die Gruppe von Pixeln als komprimierte Daten unter Verwendung der angestrebten Anzahl von Bits auf der Basis des angelegten verlustbehafteten Kompressionsvorgangs zu erzeugen.
Vorrichtung nach Anspruch 3, wobei der wenigstens eine Prozessor dafür konfiguriert ist: eine statistische Redundanz zwischen Pixeln von der Gruppe von Pixeln unter Verwendung des angelegten verlustbehafteten Kompressionsvorgangs zu ermitteln; und eine oder mehrere Informationseinheiten aus der Gruppe von Pixeln auf der Basis der statistischen Redundanz zu entfernen, um die Gruppe von Pixeln auf eine Größe zu reduzieren, die der angestrebten Anzahl von Bits entspricht.
Vorrichtung nach Anspruch 1, wobei der wenigstens eine Prozessor dafür konfiguriert ist: einen Block von komprimierten Pixeldaten aus einem ersten Bildspeicher in einem Speicher zu erhalten; den Block von komprimierten Pixeldaten in einen Block von unkomprimierten Pixeldaten zu dekomprimieren; den Block von unkomprimierten Pixeldaten zu verarbeiten; den verarbeiteten Block von unkomprimierten Pixeldaten in einen Block von komprimierten Pixeldaten unter Verwendung der angestrebten Anzahl von Bits zu komprimieren; und den Block von komprimierten Pixeldaten in einen zweiten Bildspeicher in dem Speicher hinein zu speichern.
Vorrichtung nach Anspruch 5, wobei der Block von komprimierten Pixeldaten entsprechende Pixel von dem Block von unkomprimierten Pixeldaten umfasst.
Vorrichtung nach Anspruch 1, wobei der wenigstens eine Prozessor dafür konfiguriert ist: die angestrebte Anzahl von Bits auf der Basis eines vorbestimmten Kompressionsverhältnisses zu bestimmen, wobei das vorbestimmte Kompressionsverhältnis ein Verhältnis von der Anzahl von Bits, die der Gruppe von Pixeln entspricht, zu der angestrebten Anzahl von Bits ist.
Vorrichtung nach Anspruch 1, wobei die angestrebte Anzahl von Bits einem Vielfachen einer Burst-Länge entspricht, die beim Senden von Daten zu dem Speicher verwendet wird.
Verfahren, das die folgenden Schritte umfasst: Erhalten einer Vielzahl von Dateneinheiten, die eine Vielzahl von Pixeln enthalten, die in einem Speicher gespeichert sind, wobei jede von der Vielzahl von Dateneinheiten ein erstes Pixel von der Vielzahl von Pixeln gepackt in Aufeinanderfolge mit wenigstens einem Teil eines zweiten Pixels von der Vielzahl von Pixeln umfasst, wobei die Vielzahl von Pixeln durch eine Anzahl von Bits repräsentiert wird; Erhalten einer Gruppe von Pixeln aus der Vielzahl von Pixeln; Komprimieren der Gruppe von Pixeln unter Verwendung einer angestrebten Anzahl von Bits; und Speichern der komprimierten Gruppe von Pixeln.
Computerprogrammerzeugnis, das Anweisungen aufweist, die in einem greifbaren computerlesbaren Speichermedium gespeichert sind, wobei die Anweisungen Folgende umfassen: Anweisungen für das Erhalten einer Vielzahl von Dateneinheiten, die eine Vielzahl von Pixeln enthalten, die in einem Speicher gespeichert sind, wobei jede von der Vielzahl von Dateneinheiten ein erstes Pixel von der Vielzahl von Pixeln gepackt in Aufeinanderfolge mit wenigstens einem Teil eines zweiten Pixels von der Vielzahl von Pixeln umfasst, wobei die Vielzahl von Pixeln durch eine Anzahl von Bits repräsentiert wird; Anweisungen für das Erhalten einer Gruppe von Pixeln aus der Vielzahl von Pixeln; Anweisungen für die Komprimierung der Gruppe von Pixeln unter Verwendung einer angestrebten Anzahl von Bits, die sich von der Anzahl von Bits unterscheidet; und Anweisungen für das Speichern der komprimierten Gruppe von Pixeln.