DE112018002572T5

DE112018002572T5 - Verfahren, systeme und vorrichtungen zur optimierung der pipeline-ausführung

Info

Publication number: DE112018002572T5
Application number: DE112018002572.1T
Authority: DE
Inventors: Vasile Toma; Richard RICHMOND; Fergal CONNOR; Brendan BARRY
Original assignee: Movidius Ltd Ireland; Movidius Ltd Netherland
Current assignee: Movidius Ltd Ireland; Movidius Ltd Netherland
Priority date: 2017-05-19
Filing date: 2018-05-18
Publication date: 2020-06-04
Also published as: CN110998660A; CN110998660B; US11954879B2; KR20200020705A; US20230084866A1; US11380005B2; KR102655086B1; US20200226776A1; WO2018211127A1

Abstract

Verfahren, Vorrichtungen, Systeme und Fertigungsartikel zur Optimierung der Rohrleitungsausführung werden offengelegt. Eine exemplarische Vorrichtung beinhaltet einen Kostenberechnungsmanager zum Bestimmen eines Wertes, der einem ersten Ort eines ersten Pixels eines ersten Bildes und einem zweiten Ort eines zweiten Pixels eines zweiten Bildes zugeordnet ist, durch Berechnen von Abgleichkosten zwischen dem ersten Ort und dem zweiten Ort, und einen Aggregationsgenerator zum Erzeugen einer Disparitätskarte, die den Wert beinhaltet, und zum Bestimmen eines Mindestwertes basierend auf der Disparitätskarte, der einem Unterschied in horizontalen Koordinaten zwischen dem ersten Ort und dem zweiten Ort entspricht.

Description

ZUGEHÖRIGE ANMELDUNG
Dieses Patent ergibt sich aus einer Anmeldung, die den Vorteil der provisorischen U.S.-Patentanmeldungs-Seriennummer 62/508,891 begründet und am 19. Mai 2017 eingereicht wurde. Die provisorische U.S.-Patentanmeldungs-Seriennummer 62/508,891 wird hierin durch Verweis in ihrer Gesamtheit aufgenommen. Die Priorität der provisorischen U.S.-Patentanmeldungs-Seriennummer 62/508,891 wird hiermit begründet.
GEBIET DER OFFENLEGUNG
Diese Offenlegung bezieht sich im Allgemeinen auf die Bildverarbeitung und insbesondere auf Verfahren, Systeme und Vorrichtungen zur Optimierung der Pipeline-Ausführung.
HINTERGRUND
In den letzten Jahren sind auf einer größeren Anzahl von Geräten Bildverarbeitungsanwendungen aufgetaucht. Während Bildverarbeitung wie Gesichtserkennung, Objekterkennung usw. auf Desktop-Plattformen existiert hat, ist in jüngster Zeit eine Zunahme der Bildverarbeitungsmerkmale von Mobilgeräten zu beobachten. Mobilgeräte haben im Vergleich zu Desktop-Plattformen in der Regel einen relativ weniger leistungsfähigen Prozessor, Speicherkapazität und Energiereserven.
Figurenliste

1 ist eine schematische Darstellung einer exemplarischen Hardwarearchitektur eines exemplarischen Pipeline-Optimierungssystems, das in Übereinstimmung mit den Inhalten dieser Offenlegung konstruiert wurde.
2A ist eine schematische Darstellung einer exemplarischen Zensus-Transformations-Engine des exemplarischen Pipeline-Optimierungssystems von 1.
2B ist eine schematische Darstellung einer exemplarischen Deskriptor-Puffer-Engine des exemplarischen Pipeline-Optimierungssystems von 1.
2C ist eine schematische Darstellung einer exemplarischen Kostenabgleich-Engine des exemplarischen Pipeline-Optimierungssystems von 1.
2D ist eine schematische Darstellung einer exemplarischen Kostenkonsolidierungs-Engine des exemplarischen Pipeline-Optimierungssystems von 1.
2E ist eine schematische Darstellung einer exemplarischen SGBM-Aggregations-Engine des exemplarischen Pipeline-Optimierungssystems von 1.
3 ist eine schematische Darstellung einer exemplarischen Verkettungslogik, die in Übereinstimmung mit den Inhalten dieser Offenlegung konstruiert wurde.
4 ist eine schematische Darstellung einer exemplarischen Korrelationsoperation, die von der exemplarischen Deskriptor-Puffer-Engine von 2A, der exemplarischen Kostenabgleich-Engine von 2C und der exemplarischen Kostenkonsolidierungs-Engine von 2D durchgeführt wird.
5 ist eine schematische Darstellung einer exemplarischen SGBM-Aggregationszelle.
6 ist eine schematische Darstellung eines exemplarischen Datenflusses einer Stereo-Pipeline zur Umsetzung der hier offengelegten Beispiele.
7 ist ein Blockdiagramm einer exemplarischen Implementierung eines exemplarischen SIPP-Beschleunigers 700.
8 ist ein Flussdiagramm, das exemplarische maschinenlesbare Anweisungen darstellt, die ausgeführt werden können, um das exemplarische Pipeline-Optimierungssystem von 1 und/oder den exemplarischen SIPP-Beschleuniger von 7 zu implementieren, um eine Bildfunktionsabgleichsoperation zu beschleunigen.
9 stellt exemplarische computerlesbare Anweisungen dar, die ausgeführt werden können, um das exemplarische Pipeline-Optimierungssystem von 1 und/oder den exemplarischen SIPP-Beschleuniger von 7 zu implementieren, um eine Disparität mit minimalen Kosten zu bestimmen, die mit einem ersten Pixel in einem ersten Bild und einem zweiten Pixel in einem zweiten Bild verbunden ist.
10 stellt exemplarisch computerlesbare Anweisungen dar, die ausgeführt werden können, um das exemplarische Pipeline-Optimierungssystem von 1 und/oder den exemplarischen SIPP-Beschleuniger von 7 zu implementieren, um die mit einem Ausbreitungsweg verbundenen Kosten zu bestimmen.
11 zeigt ein exemplarisches Zeitdiagramm.
12 ist ein Blockdiagramm einer exemplarischen Prozessorplattform, die strukturiert ist, um die exemplarischen maschinenlesbaren Anweisungen der 8-10 auszuführen, um das exemplarische Pipeline-Optimierungssystem von 1 und/oder den exemplarischen SIPP-Beschleuniger von 7 zu implementieren.

Die Zahlen sind nicht skalierbar. Im Allgemeinen werden in der (den) gesamten Zeichnung(en) und in der dazugehörigen schriftlichen Beschreibung dieselben Referenznummern verwendet, um auf dieselben oder ähnliche Teile zu verweisen.
DETAILLIERTE BESCHREIBUNG
Computational Imaging ist ein neues Bildgebungsparadigma, das beispiellose Nutzererfahrungen und Informationen auf der Grundlage von Bildern und Videos bereitstellen kann. So kann beispielsweise das Computational Imaging Bilder und/oder Videos verarbeiten, um eine Tiefenmap einer Szene bereitzustellen, eine Panoramasicht einer Szene bereitzustellen, Gesichter aus Bildern und/oder Videos zu extrahieren, Text, Funktionen und Metadaten aus Bildern und/oder Videos zu extrahieren und sogar automatisierte Funktionen zur visuellen Wahrnehmung basierend auf Objekt- und Szenenerkennungsfunktionen bereitzustellen.
Computational Imaging kann die Art und Weise, wie Maschinen die physikalische Welt erfassen und mit ihr interagieren, verändern. Beispielsweise können Maschinen über Computational Imaging Bilder erfassen, die mit herkömmlichen Bildgebungsverfahren nur sehr schwer zu erfassen waren. Als weiteres Beispiel können Maschinen über Computational Imaging Merkmale verstehen und/oder anderweitig ableiten, die mit ihrer Umgebung verbunden sind, und entsprechend ihrer Umgebung reagieren.
Eine der Herausforderungen bei der Einführung von Computational Imaging in einen Massenmarkt besteht darin, dass das Computational Imaging von Natur aus rechenintensiv ist. Das Computational Imaging verwendet oft große Mengen an Bildern in hoher Auflösung und/oder eine große Menge an Videos mit hoher Bildrate. Daher benötigt das Computational Imaging oft die Unterstützung leistungsfähiger Computerplattformen. Da das Computational Imaging häufig in mobilen Umgebungen verwendet wird, z.B. mit einem Smartphone oder einem Tablet-Computer, benötigt das Computational Imaging oft die Unterstützung leistungsfähiger Computerplattformen, die mit einem geringen Energiebudget arbeiten können.
Die hier offengelegten Beispiele verbessern verschiedene Arten von Bildverarbeitungsaufgaben, die typischerweise eine beträchtliche Menge an Rechenressourcen erfordern. Die hier offengelegten Beispiele unterstützen Stereoabgleichsaufgaben, die sich auf den Prozess der Aufnahme von zwei oder mehr Bildern und das Schätzen eines dreidimensionalen (3D-)Modells einer Szene beziehen, indem sie passende Pixel in den zwei oder mehr Bildem finden und die zweidimensionalen (2D-)Positionen in 3D-Tiefen umwandeln. Anders ausgedrückt, nimmt der Stereoabgleich zwei (oder mehr) 2D-Bilder auf, um ein 3D-Bild zu erzeugen. Die Stereo-Bildgebung beinhaltet Berechnungen, um zu bestimmen, wie weit ein Objekt von einem entsprechenden Aufnahmegerät (z.B. einer Kamera) entfernt sein könnte.
In einigen Beispielen werden die mit einem Eingabebild verbundenen Bilddaten (z.B. ein Foto, ein Videobild usw.) von zwei oder mehr Kameras (z.B. Kamerapaare, Stereokamerapaare usw.) und/oder einer beliebigen Anzahl von mehreren Kamerapaaren empfangen und/oder anderweitig abgerufen. Die hier dargestellten Beispiele ermöglichen eine flexible Pipeline-Hardwarearchitektur zur Beschleunigung von Stereo-Visionsalgorithmen. In einigen Beispielen werden zwei Taktzyklen pro Pixel erreicht. Diese Leistungsmerkmale ermöglichen die Echtzeitverarbeitung von beispielsweise vier Kamerapaaren mit einer Auflösung von 720p bei 30 Hz, zwei Kamerapaaren mit einer Auflösung von 720 bei 60 Hz oder acht Kamerapaaren mit einer VGA-Auflösung bei 60 Hz. Die hier offengelegten Beispiele unterstützen 8- und 10-Pixel-Daten und haben einen konfigurierbaren Disparitätssuchbereich von 64 oder 96. Im Allgemeinen ist der Suchbereich ein Indikator für eine Metrik, die einem unterstützten Tiefenbereich entspricht.
Wie hier verwendet, bezieht sich der Begriff „Disparität“ auf einen Unterschied in den Koordinaten (z.B. horizontale Koordinaten, vertikale Koordinaten, etc.) eines ersten Pixels in einem ersten Bild und eines zweiten Pixels in einem zweiten Bild eines Stereo-Bildpaares. In einigen Beispielen sind das erste Pixel und das zweite Pixel identische Pixel, die sich in verschiedenen Bildern befinden. Ein Disparitätswert ist hoch für eine nähere Entfernung und niedrig für eine weitere Entfernung, da die Disparität umgekehrt proportional zur Tiefe ist. Die Disparität der Merkmale (z.B. ein oder mehrere Pixel) zwischen zwei Stereo-Bildern werden typischerweise als Verschiebung nach links von einem Bildfeld berechnet, wenn sie im rechten Bild betrachtet werden. So kann beispielsweise ein einzelner Punkt, der bei einer X-Koordinate t (gemessen in Pixeln) im linken Bild erscheint, bei der X-Koordinate t-3 im rechten Bild vorhanden sein, wobei die Abweichung an der Stelle im rechten Bild 3 Pixel beträgt.
Die hier offengelegten Beispiele ermöglichen eine flexible Architektur, in der jede Einheit (z.B. eine Verarbeitungseinheit, ein Modul usw.) einzeln oder in Kombination mit einer oder mehreren anderen hierarchischen Einheiten verwendet und/oder anderweitig implementiert werden kann, wie im Folgenden näher beschrieben. In einigen Beispielen können bestimmte Betriebseinheiten umgangen werden, um die Ausbreitungseffizienz einer Pipeline zu erhöhen, insbesondere wenn einige der Eingabedaten möglicherweise von anderen Engines vorverarbeitet wurden.
Die hier dargestellten Beispiele ermöglichen eine flexible Zensus-Transformation (CT)-Kostenfunktion, die auch ohne eine oder mehrere Betriebseinheiten der Architektur (z.B. eigenständige Basis) genutzt werden kann. Die hier offengelegten Beispiele ermöglichen eine Semi Global Block Matching (SGBM)-Algorithmus-Kostenaggregation (z.B. SGBM3) und können auf zwei oder mehr Ebenen-Bildern in zwei oder mehr Durchgängen betrieben werden. Zu den hier offengelegten Beispielen gehören der Graustufen-Bildeingabemodus und/oder Eingabemodi, die mit vorberechneten Kosten verbunden sind. Beispiele, die hier offengelegt werden, sind unter anderem Disparitätsausgabemodi, Disparität plus Fehlerausgabemodi, beste und zweitbeste Disparitätsmodi und/oder Rohaggregationskostenausgabemodi.
1 veranschaulicht eine exemplarische Hardwarearchitektur eines exemplarischen Pipeline-Optimierungssystems 100. Das exemplarische Pipeline-Optimierungssystem 100 stellt einen oder mehrere Hardwarebeschleuniger dar, die einer flexiblen Pipeline-Hardwarearchitektur zur Beschleunigung eines Stereo-Visionsalgorithmus oder eines anderen Bildverarbeitungsalgorithmus entsprechen. Das exemplarische Pipeline-Optimierungssystem 100 ist ein Streaming Image Processing Pipeline (SIPP)-Beschleuniger. So kann beispielsweise das Pipeline-Optimierungssystem 100 vollständig in Hard- und Software oder einer diesbezüglichen Kombination implementiert werden. In einigen Beispielen kann jedoch das Ersetzen einer oder mehrerer Hardwarekomponenten des Pipeline-Optimierungssystems 100 durch Software oder eine softwarebasierte Implementierung zu Leistungseinbußen führen. In dem veranschaulichten Beispiel von 1 beinhaltet das Pipeline-Optimierungssystem 100 eine exemplarische Zensus-Transformation (CT)--Engine 102, eine exemplarische Deskriptor-Puffer-Engine 104, eine exemplarische Deskriptor-Auswahl 106, eine exemplarische Abgleichtskosten-Engine 108, eine exemplarische Kostenkonsolidierungs-Engine 110 und eine exemplarische SGBM-Aggregations-Engine 112. Zusammen bilden die exemplarische CT-Engine 102, die exemplarische Deskriptor-Puffer-Engine 104, die exemplarische Abgleichkosten-Engine 108, die exemplarische Kostenkonsolidierungs-Engine 110 und die exemplarische SGBM-Aggregations-Engine 112 eine exemplarische Pipeline 114, in der jede Komponente hier manchmal als „Stufe“ der exemplarischen Pipeline 114 bezeichnet wird.
Um die Übersichtlichkeit jeder Stufe in der exemplarischen Pipeline 114 zu verbessern, wird die exemplarische CT-Engine 102 in 2A, die exemplarische Deskriptor-Puffer-Engine 104 in 2B, die exemplarische Abgleichkosten-Engine 108 in 2C, die exemplarische Kostenkonsolidierungs-Engine 110 in 2D und die exemplarische SGBM-Aggregations-Engine 112 in 2E dargestellt.
Im Betrieb werden die Roh-Bilddaten typischerweise am Anfang der exemplarischen Pipeline von einer exemplarischen Eingabeschnittstelle 116 aus 1 in die exemplarische CT-Engine 102 eingespeist. In einigen Beispielen entspricht die Eingabeschnittstelle 116 von 1 einer Bildquelle (z.B. einer Kamera, mehreren Kameras, einer Videokamera usw.) oder einem Speicher, der Bilddaten speichert. In einigen Beispielen ist die Eingabeschnittstelle 116 von 1 eine AMC-Schnittstelle (Accelerator Memory Controller) (z.B. eine AMC-Leseclient-Schnittstelle, etc.). Alternativ kann die exemplarische Eingabeschnittstelle 116 auch ein speicherabgebildeter Prozessorbus sein. So ist beispielsweise die Eingabeschnittstelle 116 als Pseudo Direct Memory Access (DMA)-Steuerung wirksam, die Daten aus dem Speicher in die Pipeline 114 überträgt.
Im veranschaulichten Beispiel von 1 erhält die Eingabeschnittstelle 116 Bilddaten, die einem linken Beispiel-Bild 118 und/oder einem rechten Beispiel-Bild 120 entsprechen. In einigen Beispielen ruft die Eingabeschnittstelle 116 die Bilddaten aus einem exemplarischen Hauptspeicher 122 ab. Der exemplarische Hauptspeicher 122 von 1 ist der dynamische Direktzugriffsspeicher (DRAM). Alternativ kann der exemplarische Hauptspeicher 122 auch statischer Direktzugriffsspeicher (SRAM), Verbindungsmatrix (CMX)-Speicher usw. sein.
Im veranschaulichten Beispiel von 1 beinhalten die im Hauptspeicher 122 gespeicherten Bilddaten Pixelwerte von Beispielpixeln, wie beispielsweise ein im linken Bild 118 enthaltenes linkes Beispiel Pixel 124 und/oder ein im rechten Bild 120 enthaltenes rechtes Beispiel Pixel 126. So können beispielsweise die Pixelwerte einer Pixelleuchtdichte (z.B. einer Pixelintensität) des Pixels entsprechen. Jedes der linken Beispiel-Bilder 118 und das rechte Beispiel-Bild 120 hat eine Breite X von 1280 Pixel und eine Höhe Y von 1920 Pixel, aber die hier offengelegten Beispiele sind nicht darauf beschränkt. So entspricht beispielsweise jede Zeile der Bilder 118, 120 1280 Pixel und jede Spalte 1920 Pixel.
Die Roh-Bilddaten (z.B. die Pixelwerte des linken Bildpunkts 124, des rechten Bildpunkts 126 usw.) werden von der exemplarischen Pipeline 114 verarbeitet, um eine oder mehrere Bildverarbeitungsaufgaben durchzuführen, wie beispielsweise die oben beschriebenen exemplarischen Stereoabgleichaufgaben. Jede Stufe der exemplarischen Pipeline 114 verbraucht eine entsprechende Menge an Ressourcen (z.B. Rechenressourcen, Bandbreite, Speicherressourcen, etc.) und damit eine entsprechende Menge an Energie. In einigen Beispielen können eine oder mehrere Stufen der exemplarischen Pipeline 114 unabhängig von einer oder mehreren anderen Stufen der exemplarischen Pipeline 114 arbeiten. Daher können unter Umständen, in denen eine bestimmte Stufe nicht benötigt wird, eine oder mehrere Stufen deaktiviert und/oder anderweitig umgangen werden, um den Verbrauch zu reduzieren oder die Effizienz oder die Betriebsgeschwindigkeit usw. der exemplarischen Pipeline 114 zu erhöhen.
In einigen Beispielen sind eine oder mehrere Stufen nicht erforderlich, da ein anderer (externer) Prozess eine bestimmte Aufgabe im Zusammenhang mit dieser Stufe ausgeführt haben kann. Daher sind Versuche, eine Dateneinspeisung in Bezug auf Verarbeitungszeit und Energieverbrauch erneut zu verarbeiten, verschwenderisch. In einigen hier offengelegten Beispielen werden eine oder mehrere Stufen von der Verarbeitung der Eingabedaten verzögert, um Energie zu sparen. So kann beispielsweise die Kostenkonsolidierungs-Engine 110 Bitausrichtungsvorgänge durchführen, die bei zu großer Größe (z.B. Überschreiten einer oder mehrerer Bitbreitenschwellen) eine relativ große Menge an Rechenleistung verbrauchen können. Daher analysieren die hier offengelegten Beispiele die Pipeline 114, um Latenzreduzierungsmöglichkeiten zu identifizieren, die dazu führen, dass eine oder mehrere Stufen in einer alternativen Reihenfolge betrieben werden, auf den Betrieb verzichten oder eine Anzahl von Eingabedaten ändern, die von der jeweiligen Stufe verarbeitet werden sollen, um Energie zu sparen. In einigen hier offengelegten Beispielen wird eine zeitliche Abhängigkeit, die normalerweise mit einer herkömmlichen Pipeline verbunden ist, aufgehoben, wodurch Effizienzverbesserungen und gegebenenfalls die Energieeinsparung erleichtert werden.
Im veranschaulichten Beispiel von 1 beinhaltet das Pipeline-Optimierungssystem 100 die CT-Engine 102, um Pixelwerte, die Pixel zugeordnet sind, in Deskriptoren wie Blockdeskriptoren oder Bitdeskriptoren zu transformieren. Die exemplarische CT-Engine 102 bezieht Roh-Bilddaten, die Pixeln entsprechen, die im linken Bild 118 des Beispiels, im rechten Bild 120 des Beispiels usw. enthalten sind, von der exemplarischen Eingabeschnittstelle 116. Die exemplarische CT-Engine 102 erzeugt Bit-Deskriptoren, indem sie die in den Roh-Bilddaten enthaltenen Pixelwerte mit einem Vergleichswert vergleicht. Die Roh-Bilddaten können Pixelwerte beinhalten, die einem exemplarischen Pixel-Kernel 128 zugeordnet sind. Der exemplarische Pixel-Kernel 128 von 1 beinhaltet 25 Pixel, die als 5x5 Pixel-Kernel organisiert und/oder anderweitig ausgerichtet sind. Alternativ können die Roh-Bilddaten auch einem 7x7-Pixel-Kernel, einem 7x9-Pixel-Kernel usw. oder einer anderen Pixel-Kernelgröße entsprechen. Das rechte Pixel 126 des Beispiels aus 1 ist ein Zentralpixel (z.B. ein Center-Pixel) des exemplarischen Pixel-Kernels 128.
In einigen Beispielen vergleicht die CT-Engine 102 einen Pixelwert des Zentralpixels 126 des Pixel-Kernels 128 mit Pixelwerten der umgebenden Pixel des Pixel-Kernels 128, um aus dem Vergleich einen Bit-Deskriptor (z.B. 32-Bit-Deskriptor, 64-Bit-Deskriptor, etc.) zu erzeugen. So kann beispielsweise die CT-Engine 102 einen rechten Deskriptor ausgeben, der einem Bit-Deskriptor entspricht, der dem Zentralpixel 126 im rechten Bild 120 zugeordnet ist. Alternativ kann die exemplarische CT-Engine 102 einen Bit-Deskriptor erzeugen, wobei der Vergleichswert ein durchschnittlicher Pixelwert des Pixel-Kernels 128, ein Schwellenwert basierend auf einem Wert, der um einen Schwellenwert größer als der Zentralpixelwert ist, usw. ist. Als Reaktion auf die Verarbeitung des exemplarischen Pixel-Kernels 128 verarbeitet die exemplarische CT-Engine 102 einen zweiten Pixel-Kernel, wobei der zweite Pixel-Kernel an den in 1 dargestellten Pixel-Kernel 128 angrenzend (z.B. auf der rechten Seite des Pixel-Kernels 128, unter dem Pixel-Kernel 128, etc.) sein kann. Alternativ kann der zweite Pixel-Kernel ein oder mehrere Pixel des Pixel-Kernels 128 von 1 beinhalten, wobei sich der Pixel-Kernel 128 und der zweite Pixel-Kernel durch eine oder mehrere Spalten, Indizes, Zeilen usw. und/oder eine Kombination derselben überlappen.
Im veranschaulichten Beispiel von 1 überträgt die CT-Engine 102 den rechten Deskriptor an die Deskriptor-Puffer-Engine 104. Im veranschaulichten Beispiel von 1 ist die CT-Engine 102 mit der Kostenabgleich-Engine 108 gekoppelt (z.B. ist ein Schreib-Client der CT-Engine 102 mit einem Lese-Client der Kostenabgleich-Engine 108 gekoppelt). Alternativ kann die exemplarische CT-Engine 102 auch nicht mit dem Kostenabgleich-Engine 108 gekoppelt sein. Die exemplarische Deskriptor-Puffer-Engine 104 ruft einen linken Deskriptor von einer ersten exemplarischen Schreibschnittstelle 130 ab und sendet ihn an die exemplarische Kostenabgleich-Engine 108. In einigen Beispielen ist die erste Schreibschnittstelle 130 von 1 eine AMC-Schnittstelle (Accelerator Memory Controller) (z.B. eine AMC-Schreib-Client-Schnittstelle, etc.). Alternativ kann die erste exemplarische Schreibschnittstelle 130 auch ein speicherabgebildeter Prozessorbus sein. Der linke Deskriptor entspricht einem Bit-Deskriptor, der den Pixelwerten von Pixeln zugeordnet ist, die das linke Pixel 124 aus dem linken Bild 118 des Beispiels umgeben und/oder anderweitig benachbart sind. Als Reaktion auf das Abrufen des linken Deskriptors und/oder des rechten Deskriptors überträgt die exemplarische Deskriptor-Puffer-Engine 104 den linken Deskriptor an die exemplarische Kostenabgleich-Engine 108 und überträgt einen oder mehrere rechte Deskriptoren einschließlich des von der CT-Engine 102 erzeugten rechten Deskriptors an den exemplarischen Deskriptor-Selektor 106.
In dem veranschaulichten Beispiel von 1 beinhaltet das Pipeline-Optimierungssystem 100 den Deskriptor-Selektor 106, um eine Teilmenge der rechten Deskriptoren aus der Deskriptor-Puffer-Engine 104 basierend auf Disparitätskompandierung auszuwählen. Disparitätskompandierung ermöglicht es dem exemplarischen Pipeline-Optimierungssystem 100, einen effektiven Stereotiefenbereich zu erweitern, indem es verstreute Disparitätspunkte auf den Bereich nimmt. Disparitätskompandierung komprimiert den effektiven Nennbereich in einen kleineren effektiven Bereich mit geringerer Auflösung. So ist beispielsweise die Auflösung bei den Werten für den flachen Bereich höher und die Auflösung reduziert sich bei tiefen Bereichen schrittweise. So kann beispielsweise die Deskriptor-Puffer-Engine 104 176 rechte Deskriptoren ausgeben. Der exemplarische Deskriptor-Selektor 106 kann 96 der 176 rechten Deskriptoren auswählen, indem er eine verstreuten Abgleichsoperation an den 176 rechten Deskriptoren durchführt. In einigen Beispielen wird der Deskriptor-Selektor 106 durch einen oder mehrere 2:1-Multiplexer implementiert.
In dem veranschaulichten Beispiel von 1 beinhaltet das Pipeline-Optimierungssystem 100 die Kostenabgleich-Engine 108, um für jede Kandidaten-Disparität bei jedem Pixel Abgleichkosten oder einen Abgleichsparameter zu berechnen und/oder anderweitig zu bestimmen. In einigen Beispielen sind die Abgleichkosten, die einem ersten Pixel in einem ersten Bild zugeordnet sind, ein Parameter (z.B. ein ganzzahliger Wert, der in einem Bereich von 0 bis 128, 0 bis 255, usw. eingespannt ist), der berechnet und/oder anderweitig bestimmt wird, basierend auf einer Intensität des ersten Pixels und einer vermuteten Übereinstimmung oder einem potenziell passenden Pixel in einem zweiten Bild. So können beispielsweise die Abgleichkosten eine Quantifizierung darstellen, wie ähnlich eine erste Position eines ersten Pixels in einem ersten Bild einer zweiten Position eines zweiten Pixels in einem zweiten Bild ist. Das exemplarische Kostenabgleich-Engine 108 von 1 bestimmt die Abgleichkosten basierend auf den Bit-Deskriptoren, die aus der Deskriptor-Puffer-Engine 104 und/oder dem Deskriptor-Selektor 106 abgerufen und/oder anderweitig erhalten wurden. Das exemplarische Kostenabgleich-Engine 108 identifiziert Pixelintensitätswerte und berechnet Disparitätswerte, die an die exemplarische Kostenkonsolidierungs-Engine 110 ausgegeben werden. So kann beispielsweise die Kostenabgleich-Engine 108 einen Pixelintensitätswert des linken Pixels 124 basierend auf den 8 niederwertigsten Bits (LSBs) des linken Deskriptors bestimmen, der dem linken Pixel 124 zugeordnet ist. In anderen Beispielen bestimmt die Kostenabgleich-Engine 108 eine Disparität zwischen dem linken Pixel 124 und den Pixeln des Pixel-Kernels 128 basierend auf einem Vergleich des linken Deskriptors und der Vielzahl der rechten Deskriptoren. Die Diskrepanz bezieht sich auf einen Abstand oder einen Koordinatenunterschied (z.B. horizontale Koordinaten, vertikale Koordinaten, etc.) zwischen zwei entsprechenden Punkten im linken Bild 118 und dem rechten Bild 120, wobei das linke Bild 118 und das rechte Bild 120 ein exemplarisches Stereo-Bildpaar 132 bilden.
In dem veranschaulichten Beispiel von 1 beinhaltet das Pipeline-Optimierungssystem 100 die Kostenkonsolidierungs-Engine 110 zur Neuausrichtung verarbeiteter Bilddaten aufgrund der Verwendung einer Ringspeicherstrategie durch mindestens eine der CT-Engine 102, die Deskriptor-Puffer-Engine 104 und die Kostenabgleich-Engine 108. In einigen Beispielen sind die Eingaben für die exemplarische Kostenkonsolidierungs-Engine 110 ziemlich hoch, z.B. mit 128 Datensätzen, wobei jeder Datensatz 32 Bit aufweist. Anstatt sofort eine Ausrichtung auf diese Datenmenge zu Beginn der exemplarischen Deskriptor-Puffer-Engine 104 durchzuführen, warten die hier offengelegten Beispiele auf Umstände, bei denen eine geringere Anzahl von Bits pro Datensatz empfangen und/oder anderweitig abgerufen wird, bevor diese eine Neuausrichtung durchführen. Anders ausgedrückt werden die Neuausrichtungsbemühungen auf eine alternative Stufe der exemplarischen Pipeline 114 wie die exemplarische Kostenkonsolidierungs-Engine 110 verschoben, um die Effizienz des Pipeline-Optimierungssystems 100 zu verbessern.
In dem veranschaulichten Beispiel von 1 beinhaltet das Pipeline-Optimierungssystem 100 die SGBM-Aggregations-Engine 112, um die Aggregation und Verfeinerung der Abgleichkosten und der entsprechenden Disparitäten durchzuführen, die von der Kostenabgleich-Engine 108 basierend auf den von der Kostenkonsolidierungs-Engine 110 erhaltenen Eingaben erzeugt werden. Alternativ kann die exemplarische SGBM-Aggregations-Engine 112 auch eigenständig verwendet werden (z.B. extern zur exemplarischen Pipeline 114) und Eingaben aus dem exemplarischen Hauptspeicher 122 abrufen. In einigen Beispielen beinhaltet die SGBM-Aggregations-Engine 112 einen Eingabekostenpuffer und eine Vielzahl von Aggregationszellen, die kommunikativ mit einem oder mehreren Steuersignalen gekoppelt sind, um einen Ausgabeaggregationspuffer zu erzeugen, der einem endgültigen Disparitätswert für jeden Bildpunkt innerhalb des Stereo-Bildpaares 132 zugeordnet ist. Die exemplarische SGBM-Aggregations-Engine 112 überträgt den Ausgabeaggregationspuffer an eine zweite exemplarische Schreibschnittstelle 134. Das zweite Beispiel der Schreibschnittstelle 134 von 1 ist eine Accelerator Memory Controller (AMC)-Schnittstelle (z.B. eine AMC-Schreib-Client-Schnittstelle, etc.). Alternativ kann die zweite exemplarische Schreibschnittstelle 134 auch ein speicherabgebildeter Prozessorbus sein.
In einigen Beispielen arbeiten eine oder mehrere Komponenten der Pipeline 114 von 1 und/oder ganz allgemein das Pipeline-Optimierungssystem 100 von 1 in einem Ausgabemodus. So kann beispielsweise der Ausgabemodus ein Disparitätsmodus, ein Disparitäts- und Fehlermodus, ein bester und zweitbester Disparitätsmodus oder ein Aggregationskostenmodus (z.B. ein Rohaggregationskostenmodus) sein. In solchen Beispielen gibt das Pipeline-Optimierungssystem 100 im Disparitätsmodus eine komplette Kosten- oder Disparitätskarte pro Pixel aus. Das exemplarische Pipeline-Optimierungssystem 100 gibt eine beste (z.B. ein Minimum) und eine zweitbeste (z.B. ein zweites Minimum) Disparität aus, wenn es im besten und zweitbesten Disparitätsmodus arbeitet. Das exemplarische Pipeline-Optimierungssystem 100 gibt im Betrieb im Aggregationskostenmodus eine oder mehrere Aggregationskosten aus.
Das exemplarische Pipeline-Optimierungssystem 100 gibt bei Betrieb im Disparitäts- und Fehlermodus eine Disparität und eine entsprechende Konfidenzgröße (z.B. ein Konfidenzniveau) aus. So kann beispielsweise das Pipeline-Optimierungssystem 100 die Vertrauensmetrik verwenden, um fehlerhafte oder ungenaue Disparitätsvorhersagen aus der Disparitätskarte zu bestimmen und/oder anderweitig zu invalidieren. In derartigen Beispielen kann das Pipeline-Optimierungssystem 100 solche ungenauen Disparitätswerte durch Relevanz- oder Ersatzwerte unter Verwendung verschiedener Nachbearbeitungsfilter (z.B. Gap-Füllfilter, Medianfilter, etc.) ersetzen. In einigen Beispielen ist die Vertrauensmetrik ein Vertrauensquotient (z.B. eine Vertrauensquotientmetrik). DerVertrauenquotient verwendet ein erstes Minimum (c(p, d0)) und ein zweites Minimum (c(p, d1) aus den Abgleichkosten (z.B. dem Abgleichkostenvektor) und bestimmt den Vertrauensquotienten, wie unten in Gleichung (1) beschrieben: $r (p) = \frac{c (p, d 0)}{(p, d 1) 0} * 255$
Im Beispiel der obigen Gleichung (1) liegt ein Wert des Vertrauensquotienten in einem Bereich von 0 bis 1 ([0,1]). Im obigen Beispiel der Gleichung (1) entspricht ein kleinerer Wert (z.B, r(p) Annäherung 0) einer hohen Wahrscheinlichkeit, dass die bestimmte Disparität eine genaue Schätzung oder Bestimmung ist, verglichen mit einer Disparität, die mit einem größeren Wert der Vertrauensquotientmetrik verbunden ist (z.B, r(p) Annäherung 1). So ist beispielsweise ein höheres Vertrauen mit einer Disparität verbunden, wenn das globale Minimum kleiner ist (z.B. um den Faktor 2, 5, 10 usw. kleiner) als das zweite Minimum.
In einigen Beispielen bestimmt das Pipeline-Optimierungssystem 100, dass die berechnete Disparität, die einem Bildpunkt zugeordnet ist, nicht gültig, ungenau, nicht für eine Bildverarbeitungsaufgabe zu verwenden ist usw., wenn die Vertrauensquotientmetrik einen Schwellenwert nicht erfüllt. So kann beispielsweise das Pipeline-Optimierungssystem 100 (z.B. eine der Komponenten des Pipeline-Optimierungssystems 100 wie die SGBM-Aggregations-Engine 112) den Vertrauensquotienten mit einem Verhältnisschwellenwert vergleichen und die damit verbundene Disparität ungültig machen, wenn der Vertrauensquotient größer als der Verhältnisschwellenwert ist. Als Reaktion auf das Bestimmen, dass die zugehörige Disparität aufgrund des Vergleichs ungültig ist, ersetzt das exemplarische Pipeline-Optimierungssystem 100 den Disparitätswert im Kostenabgleichsvektor durch einen Wert, der einer ungültigen Wertkennung zugeordnet ist. Das exemplarische Pipeline-Optimierungssystem 100 oder eine externe Komponente des Pipeline-Optimierungssystems 100 kann den dem ungültigen Wertidentifikator zugeordneten Wert durch einen Relevant- oder einen Ersatzwert mit einem oder mehreren Nachbearbeitungsfiltern (z.B. einem Gap-Füllfilter, einem Medianfilter, etc.) ersetzen.
Während eine Beispiel-Implementierungsart der exemplarischen Pipeline 114 von 1 in 1 dargestellt ist, können eines oder mehrere der in 1 dargestellten Elemente, Prozesse und/oder Vorrichtungen kombiniert, geteilt, neu ausgerichtet, weggelassen, eliminiert und/oder auf andere Weise implementiert werden. Weiterhin kann die exemplarische CT-Engine 102, die exemplarische Deskriptor-Puffer-Engine 104, der exemplarische Deskriptor-Selektor 106, die exemplarische Kostenabgelich-Engine 108, die exemplarische Kostenkonsolidierungs-Engine 110, die exemplarische SGBM-Aggregations-Engine 112 und/oder ganz allgemein die exemplarische Pipeline 114 von 1 durch Hardware, Software, Firmware und/oder eine beliebige Kombination von Hardware, Software und/oder Firmware implementiert werden. So kann beispielsweise jede der exemplarischen CT-Engine 102, die exemplarische Deskriptor-Puffer-Engine 104, der exemplarische Deskriptor-Selektor 106, die exemplarische Kostenabgleich-Engine 108, die exemplarische Kostenkonsolidierungs-Engine 110, die exemplarische SGBM-Aggregations-Engine 112 und/oder ganz allgemein die exemplarische Pipeline 114 durch eine oder mehrere analoge oder digitale Schaltungen, Logikschaltungen, programmierbare(r) Prozessor(en), programmierbare(r) Controller, Grafikprozessor(en) (GPU(s)), digitale Signalprozessoren (DSP(s)), anwendungsspezifische integrierte Schaltung(en) (ASIC(s)), programmierbare(r) Logikgerät(e) (PLD(e)) und/oder feldprogrammierbare(r) Logikgerät(e) (FPLD(e)) implementiert werden. Um eine reine Software- und/oder Firmware-Implementierung abzudecken, wird bei der Betrachtungeiner der Vorrichtungs- oder Systemansprüche dieses Patents mindestens eine/einer der exemplarischen CT-Engine 102, der exemplarischen Deskriptor-Puffer-Engine 104, des exemplarischen Deskriptor-Selektors 106, der exemplarischen Kostenabgleich-Engine 108, der exemplarischen Kostenkonsolidierungs-Engine 110 und/oder der exemplarischen SGBM-Aggregations-Engine 112 hiermit ausdrücklich definiert, um eine nicht-flüchtige computerlesbare Speichervorrichtung oder Speicherplatte wie einen Speicher, eine Digital Versatile Disk (DVD), eine Compact Disk (CD), eine Blu-ray-Disk usw. einschließlich der Software und/oder Firmware zu beinhalten. Weiterhin kann die exemplarische Pipeline 114 von 1 ein oder mehrere Elemente, Prozesse und/oder Vorrichtungen zusätzlich zu oder anstelle der in 1 dargestellten Elemente beinhalten und/oder mehr als eines der dargestellten Elemente, Prozesse und Vorrichtungen beinhalten. Wie hierin verwendet, umfasst der Begriff „in Kommunikation“, einschließlich seiner Variationen, die direkte Kommunikation und/oder indirekte Kommunikation über eine oder mehrere Zwischenkomponenten und erfordert keine direkte physikalische (z.B. drahtgebundene) Kommunikation und/oder konstante Kommunikation, sondern zusätzlich eine selektive Kommunikation in periodischen Intervallen, geplanten Intervallen, aperiodischen Intervallen und/oder einmaligen Ereignissen.
2A ist eine schematische Darstellung der exemplarischen CT-Engine 102 des exemplarischen Pipeline-Optimierungssystems 100 aus 1. Die exemplarische CT-Engine 102 erzeugt und überträgt eine Bit-Deskriptor-Ausgabe, wie beispielsweise einen exemplarischen rechten Deskriptor 202, an die exemplarische Deskriptor-Puffer-Engine 104. Im veranschaulichten Beispiel von 2A erzeugt die CT-Engine 102 den richtigen Deskriptor 202, indem sie Beispielpixel 204 eines Beispielpixel-Kernels 206 verarbeitet, der einem Bild eines Stereo-Bildpaares zugeordnet ist. Im veranschaulichten Beispiel von 2A beträgt jedes der Pixel 204 8 Bit. Alternativ kann jedes der Beispielpixel 204 10 Bit oder eine andere Anzahl von Bits sein. Der exemplarische Pixel-Kernel 206 von 2A kann dem exemplarischen Pixel-Kernel 128 von 1 entsprechen.
Im veranschaulichten Beispiel von 2A bezieht die CT-Engine 102 Bilddaten von der Eingabeschnittstelle 116. Im Beispiel von 2A beinhalten die Bilddaten Pixelwerte der Pixel 204, die einem Bild eines Stereo-Bildpaares zugeordnet sind. So können beispielsweise die Pixelwerte der Pixel 204 den Pixelwerten der Pixel entsprechen, die im Pixel-Kernel 128 von 1 des rechten Bildes 120 des Stereo-Bildpaares 132 enthalten sind. Die Pixelwerte entsprechen einer Leuchtdichtekomponente oder einer Intensität des Pixels.
In dem veranschaulichten Beispiel von 2A erhält die CT-Engine 102 von der Eingabeschnittstelle 116 während jeder Zeitinstanz (z.B. eines Taktzyklus) des Betriebs eine Beispielspalte 208 aus Pixelwerten. Im veranschaulichten Beispiel von 2A beinhaltet der Pixel-Kernel 206 fünf Spalten 208 mit je 5 Pixeln, um einen 5x5 Pixel-Kernel zu bilden. Alternativ kann die CT-Transformations-Engine 102 7x7 Pixel-Kernel, 7x9 Pixel-Kernel oder jede andere Pixel-Kernelgröße verarbeiten.
Im veranschaulichten Beispiel von 2A berechnet die CT-Engine 102 eine Summe von Pixelwerten für die Spalten 208 des Pixel-Kernels 206 unter Verwendung eines exemplarischen Pixelsummenoperators 210. Im veranschaulichten Beispiel von 2A ist jede der Spalten 208 mit einem der Pixelsummenoperatoren 210 gekoppelt. Jeder der Pixelsummenoperatoren 210 berechnet eine Summe von 5 Pixelwerten der Spalte 208, mit der der Pixelsummenoperator 210 gekoppelt ist.
Im veranschaulichten Beispiel von 2A berechnet die CT-Engine 102 einen Mittelwert aus Pixelwerten für die Spalten 208 des Pixel-Kernels 206 unter Verwendung eines exemplarischen Pixelmittelwertoperators 212. Im veranschaulichten Beispiel von 2A ist jeder der Pixelmitteloperatoren 212 mit einem der Pixelsummenoperatoren 210 und einem Beispiel Modulo-N-Zähler 214 gekoppelt. Jeder der exemplarischen Pixelmittelwertoperatoren 212 berechnet einen Durchschnitt von 5 Pixelwerten der Spalte 208, mit der der Pixelmittelwertoperator 212 gekoppelt ist, wenn dieser angewiesen und/oder anderweitig angewiesen wird.
Im veranschaulichten Beispiel von 2A ruft die CT-Engine 102 in jedem Taktzyklus eine neue Spalte mit Pixeln 204 ab, basierend auf einer Implementierung oder einem Verfahren des Ringspeichers. So ersetzt beispielsweise die CT-Engine 102 die älteste Spalte durch eine neue Spalte, während der Rest des Pixel-Kernels 206 an Ort und Stelle bleibt, um zusätzliche Schalt- oder Datenbewegungen zu vermeiden. Die exemplarische CT-Engine 102 von 2A verwendet den exemplarischen Modulo-N-Zähler 214, um einen Index zu verfolgen und/oder anderweitig zu pflegen, der der entspricht, welche der Spalten 208 ersetzt werden sollen. So wird beispielsweise ein erster der Spalten 208 ersetzt, wenn der Modulo-N-Zähler 214 einen Wert von Null hat (z.B. ==0), ein zweiter der Spalten 208 wird ersetzt, wenn der Modulo-N-Zähler 214 einen Wert von eins hat (z.B. ==1), etc. So kann beispielsweise der Modulo-N-Zähler 214 mit einem oder mehreren Flip Flops (z.B. einem D-Flip Flop) realisiert werden.
In der Operation ruft die exemplarische CT-Transformations-Engine 102 eine erste der Spalten 208a während eines ersten Taktzyklus ab und speichert sie. Ein erster der exemplarischen Pixelsummenoperatoren 210, die mit der ersten Spalte 208a gekoppelt sind, berechnet eine Summe der fünf Pixelwerte, die in der ersten Spalte 208a enthalten sind. Ein erster der exemplarischen Pixelmittelwertoperatoren 212, der mit dem ersten der exemplarischen Pixelsummenoperatoren 210 gekoppelt ist, berechnet einen Durchschnitt der fünf Pixelwerte basierend auf der von dem Pixelsummenoperator 210 berechneten Summe und der Menge der in der ersten Beispielspalte 208a enthaltenen Beispielpixel 204. So werden beispielsweise der Pixelsummenoperator 210 und der mit der ersten Spalte 208a gekoppelte Pixelmittelwertoperator 212 basierend auf einem Wert von 0 für den Modulo-N-Zähler 214 ausgelöst. So können beispielsweise die ersten der Pixelsummenoperatoren 210 und die Pixelmittelwert 212 alle fünf Takte ausgelöst werden. Der erste der exemplarischen Pixelmittelwertoperatoren 212 sendet den berechneten Durchschnitt zur Verarbeitung an eine Beispielfunktion (FN) 216.
Während eines zweiten Taktzyklus ruft die exemplarische CT-Transformations-Engine 102 eine zweite der Spalten 208b ab und speichert diese. Ein zweiter der exemplarischen Pixelsummenoperatoren 210, der mit der zweiten Beispielspalte 208b gekoppelt ist, berechnet eine Summe der fünf Pixelwerte, die in der zweiten Spalte 208b enthalten sind. Ein zweiter der exemplarischen Pixelmittwelwertoperatoren 212, der mit dem zweiten der exemplarischen Pixelsummenoperatoren 210 gekoppelt ist, berechnet einen Durchschnitt der fünf Pixelwerte basierend auf der von dem Pixelsummenoperator 210 berechneten Summe und der in der zweiten Spalte 208b enthaltenen Anzahl von Pixeln 204. So werden beispielsweise der Pixelsummenoperator 210 und der mit der ersten Spalte 208a gekoppelte Pixelmittelwertoperator 212 basierend auf einem Wert von 1 für den Modulo-N-Zähler 214 ausgelöst. Der zweite der exemplarischen Pixelmittelwertoperatoren 212 sendet den berechneten Durchschnitt zur Verarbeitung an die Beispielfunktion 216.
Als Reaktion auf die Beispielfunktion 216, die fünf Pixelmittelwerte empfängt, die den fünf Beispielspalten 208 des exemplarischen Pixel-Kernels 206 entsprechen (z.B. hat der Modul-N-Zähler 214 einen Wert von 5), berechnet die Funktion 216 einen endgültigen Mittelwert des Pixel-Kernels 206 basierend auf den Teilmittelwerten, die von den exemplarischen Pixelmittelwertoperatoren 212 berechnet wurden. Die Beispielfunktion 216 ruft auch exemplarische Zentralpixel ab, die ein erstes exemplarisches Zentralpixel 218a, ein zweites exemplarisches Zentralpixel 218b und ein drittes exemplarisches Zentralpixel 218c für eine exemplarische Zensus-Transformation 220 beinhalten, um Vergleiche durchzuführen. So ordnet die CT-Engine 102 beispielsweise ein Zentralpixel eines Abschnitts oder ein Fenster (z.B. den Pixel-Kernel 128 von 1) des Eingabebildes (z.B. das rechte Bild 120 von 1) zu, das verarbeitet wird, um ein aktuelles Zentralpixel des Pixel-Kernels 206 während jedes Taktzyklus im Auge zu behalten. So entspricht beispielsweise das erste Zentralpixel 218a einem Zentralpixel des Pixel-Kernels 206. So kann beispielsweise das erste Zentralpixel 218a von 2A dem rechten Pixel 126 von 1 und der Pixel-Kernel 206 von 2A dem Pixel-Kernel 128 von 1 entsprechen. Das zweite exemplarische Zentralpixel 218b entspricht einem Zentralpixel des nächsten Pixel-Kernels 206 des Eingabebildes, wenn das Fenster verschoben wird. So kann beispielsweise das zweite Zentralpixel 218b dem Zentralpixel eines benachbarten Pixel-Kernels dem Pixel-Kernel 128 von 1 entsprechen.
Im veranschaulichten Beispiel von 2A vergleicht die Zensus-Transformation 220 jeden der Pixelwerte der Pixel 204 mit einem Zentralpixel des Pixel-Kernels 206. So kann beispielsweise die Zensus-Transformation 220 das erste Zentralpixel 218a mit jedem der Pixelwerte des Pixel-Kernels 206 vergleichen und basierend auf dem Vergleich einen exemplarischen Pre-Mask-Bitdeskriptor 222 erzeugen. Im veranschaulichten Beispiel von 2A ist der Pre-Mask-Bitdeskriptor 222 ein 25-Bit-Deskriptor, basierend auf dem Pixel-Kernel 206 mit 25 Pixeln (z.B. 25 Pixelwerte). In einigen Beispielen kann der Pre-Mask-Bitdeskriptor 222 ein 49-Bit-Deskriptor sein, wenn der Pixel-Kernel 206 ein 7x7-Pixel-Kernel ist. In anderen Beispielen kann der Pre-Mask-Bitdeskriptor 222 ein 63-Bit-Deskriptor sein, wenn der Pixel-Kernel 206 ein 7x9-Pixel-Kernel ist.
Im veranschaulichten Beispiel von 2A weist die Zensus-Transformation 220 einem der Pixel 204 eine 0 zu, wenn der entsprechende Pixelwert kleiner oder kleiner als ein Vergleichspunkt ist. So kann beispielsweise der Vergleichspunkt ein Pixelwert der Zentralpixel 218a, 218b, 218c oder ein Mittelwert der Pixelwerte des verarbeiteten Pixel-Kernels 206 sein. Alternativ kann der Vergleichspunkt auch ein Schwellenwert sein, der basierend auf der Addition eines Wertes zu einem Pixelwert des Zentralpixels berechnet wird, um sicherzustellen, dass der zu vergleichende Pixelwert um einen definierten (Schwellen-)Rand größer als der Zentralpixelwert ist. Im veranschaulichten Beispiel von 2A weist die Zensustransformation 220 einem der Pixel 204 eine 1 zu, wenn der entsprechende Pixelwert größer oder größer als der Vergleichspunkt ist.
Die exemplarische Zensus-Transformation 220 von 2A überträgt den exemplarischen Pre-Mask-Bitdeskriptor 222 an die exemplarische Verkettungslogik 224, um den richtigen Deskriptor 202 zu erzeugen. Der exemplarische rechte Deskriptor 202 von FIGABB 2A ist ein 32-Bit-Deskriptor, der ein entsprechendes der exemplarischen Zentralpixel 218a, 218b, 218c (z.B. ein 8-Bit-Zentralpixel) und einen exemplarischen Post-Mask-Deskriptor 226 basierend auf dem exemplarischen Pre-Mask-Bitdeskriptor 222 beinhaltet.
Im veranschaulichten Beispiel von 2A entspricht die Verkettungslogik 224 der Null-Latenz, der Zufallsbit-Kettenlogik. So kann beispielsweise die Verkettungslogik 224 der Hardwarelogik entsprechen, die bei der Verarbeitung von Eingaben eine vernachlässigbare Latenzzeit aufweist. Die exemplarische Verkettungslogik 224 von 2A verarbeitet die 25 Bit des exemplarischen Pre-Mask-Bitdeskriptors 222 zu 24 Bit des exemplarischen rechten Deskriptors 202, indem sie eine exemplarische Verkettungsmaske 228 auf den exemplarischen Pre-Mask-Bitdeskriptor 222 anwendet. Die exemplarische CT-Engine 102 verwendet die exemplarische Verkettungsmaske 228, um bitweise Operationen durchzuführen, die in der exemplarischen Verkettungslogik 224 enthalten sind. Unter Verwendung der exemplarischen Verkettungsmaske 228 kann die exemplarische CT-Engine 102 entweder Bits des exemplarischen Pre-Mask-Bitdeskriptors 222 ein- oder ausschalten (z.B. ein Bit auswählen oder kein Bit auswählen), je nachdem, wo die Einsen in der Verkettungsmaske 228 platziert sind. Die exemplarische Verkettungsmaske 228 von 2A beträgt 64 Bit. Alternativ kann die exemplarische Verkettungsmaske 228 32 Bit oder eine beliebige andere Anzahl von Bits sein.
In einigen Beispielen verkettete die Verkettungslogik 224 einen ersten Satz von Bits (z.B. eine Folge von 0 Bits) mit einem zweiten Satz von Bits, die den Bits im Pre-Mask-Bitdeskriptor 222 entsprechen, dessen Rang gleich den Positionen von Einsen in der Verkettungsmaske 228 ist. Für einen exemplarischen 16-Bit-Eingabestroms und eines entsprechenden 16-Bit-Maskenstroms wird im Folgenden die Logik der Verkettungslogik 224 beschrieben:

Beispiel Eingabestrom: 0 1 1 1 0 0 0 1 0 1 0 1 1 1 1 0 0 0 0 0 0 0 1 0 1 0 1 1
Beispiel Maskenstrom: 0 0 0 1 0 0 0 0 0 1 0 1 0 1 1 1 0 0 0 1 1 1 1 0
Beispiel Ausgabestrom: 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0

So haben beispielsweise die Indizes 1, 2, 5, 6, 9 und 13 des Eingabestroms einen Rang (z.B. eine Bitposition), der den Positionen der Einser im Maskenstrom entspricht. So sind beispielsweise die Werte des Eingabestroms im gleichen Rang wie die Einsen im Maskenstrom 1 0 0 0 0 0 0 10. Die exemplarische Verkettungslogik 224 verkettete eine Folge von Nullen mit den Werten von 1 0 0 0 0 0 1 0, um den Ausgabestrom wie oben beschrieben zu erzeugen. Die exemplarische Verkettungslogik 224 von 2A kann den oben beschriebenen exemplarischen Prozess für Eingabeströme von 25 Bit, 49 Bit, 63 Bit usw. und einen entsprechenden Maskenstrom (z.B. eine Verkettungsmaske) von 64 Bit implementieren. Alternativ kann die exemplarische Verkettungsmaske 228 eine unterschiedliche Anzahl von Bits (z.B. 32 Bit) beinhalten. Die exemplarische Verkettungslogik 224 von 2A und/oder, allgemeiner gesagt, die exemplarische CT-Engine 102 überträgt den exemplarischen rechten Deskriptor 202 an die exemplarische Deskriptor-Puffer-Engine 104 von 1.
2B ist eine schematische Darstellung der exemplarischen Deskriptor-Puffer-Engine 104 des exemplarischen Pipeline-Optimierungssystems 100 aus 1. Die exemplarische Deskriptor-Puffer-Engine 104 ist ein Puffer, der einen Datenaustausch zwischen (1) mindestens einem der exemplarischen CT-Transformations-Engines 102 von 1 und 2A oder der ersten exemplarischen Schreibschnittstelle 130 von 1 und (2) dem exemplarischen Deskriptor-Selektor 106 und/oder dem exemplarischen Kostenabgleich-Engine 108 von 1 überträgt und/oder anderweitig ermöglicht.
Im veranschaulichten Beispiel von 2B bezieht die Deskriptor-Puffer-Engine 104 den richtigen Deskriptor 202 von der CT-Engine 102. Der exemplarische rechte Deskriptor 202 von 2B ist ein 32-Bit-Deskriptor, der einem der Zentralpixel 218a, 218b, 218c entspricht, die zuletzt von der CT-Engine 102 verarbeitet wurden. Alternativ kann der exemplarische rechte Deskriptor 202 auch 64-Bit oder eine beliebige andere Anzahl von Bits sein.
In dem veranschaulichten Beispiel von 2B erhält die Deskriptor-Puffer-Engine 104 einen exemplarischen linken Deskriptor 230 von der ersten Schreibschnittstelle 130. Im veranschaulichten Beispiel von 2B ist der linke Deskriptor 230 ein 32-Bit-Deskriptor, der dem linken Pixel 124 von 1 entspricht. Alternativ kann der linke Beispiel-Deskriptor 230 64 Bit oder eine beliebige andere Anzahl von Bits sein. Die exemplarische Deskriptor-Puffer-Engine 104 leitet den exemplarischen linken Deskriptor 230 an den exemplarischen Kostenabgleich-Engine 108 weiter. Alternativ kann die exemplarische Deskriptor-Puffer-Engine 104 den exemplarischen linken Deskriptor 230 zwischenspeichern (z.B. für einen Taktzyklus, zwei Taktzyklen, etc.), bis er angefordert wird, an die exemplarische Kostenabgleich-Engine 108 übertragen zu werden.
In der Operation erhält und speichert die exemplarische Deskriptor-Puffer-Engine 104 während einer ersten Phase den Post-Mask-Bitdeskriptor 202 aus 2A, wie er von der exemplarischen CT-Engine 102 erzeugt wird. So speichert beispielsweise die Deskriptor-Puffer-Engine 104 in der ersten Phase einen oder mehrere rechte Deskriptoren, die den Pixeln des rechten Bildes 120 von 1 zugeordnet sind, wie sie von der CT-Engine 102 erzeugt werden. Die exemplarische Deskriptor-Puffer-Engine 104 speichert den exemplarischen Post-Mask-Bitdeskriptor 202 in einem exemplarischen Ringspeicher 232. Der exemplarische Ringspeicher 232 von 2B speichert 1280 Wörter, wobei jedes Datenwort 32 Bit beträgt, aber die hier offengelegten Beispiele beschränken sich nicht darauf. Der exemplarische Ringspeicher 232 enthält 1280 Datenwörter, um für jedes Pixel einen Bit-Deskriptor in einer Zeile des rechten Beispielbildes 120 speichern zu können. Alternativ kann der exemplarische Ringspeicher 232 weniger oder mehr als 1280 Datenwörter speichern und/oder jedes Datenwort kann weniger oder mehr als 32 Bit enthalten.
Während einer zweiten Phase erhält die exemplarische Deskriptor-Puffer-Engine 104 für jeden Taktzyklus den exemplarischen linken Deskriptor 230, der einem Pixel des linken Bildes 118 von 1 entspricht (z.B. das linke Pixel 124 von 1). In der zweiten Phase überträgt die exemplarische Deskriptor-Puffer-Engine 104 den exemplarischen linken Deskriptor 230 an die exemplarische Kostenvergleich-Engine 108. Alternativ kann die exemplarische Deskriptor-Puffer-Engine 104 einen von der CT-Engine 102 empfangenen linken Deskriptor senden. Während des zweiten Taktzyklus überträgt die exemplarische Deskriptor-Puffer-Engine 104 176 exemplarische rechte Deskriptoren 234, wobei jeder der rechten Deskriptoren 234 32 Bit beträgt, an den exemplarischen Deskriptor-Selektor 106, aber die hier offengelegten Beispiele beschränken sich nicht darauf. So kann beispielsweise die Deskriptor-Puffer-Engine 104 176 der gespeicherten Deskriptoren aus dem Ringspeicher 232 lesen, beginnend bei einem ersten Index (RD_X) bis zu einem 176. Index (RD_X-175) und die gespeicherten Deskriptoren in einem exemplarischen Ausgabepuffer 233 zur Übertragung ausgeben. So bezieht sich beispielsweise der Ausdruck X auf den aktuellen Taktzyklus. Zum Beispiel während eines ersten Taktzyklus, X=1, während eines zweiten Taktzyklus, X=2, etc. In Beispielen, in denen der aktuelle Taktzyklus einen Index negativ setzt (z.B. X=2 setzt den Index RD_X-175 gleich RD_-173), ersetzt die Deskriptor-Puffer-Engine 104 die negativen Indizes durch den niedrigsten nicht-negativen Index. Wenn der Taktzyklus beispielsweise 2 ist, liest die Deskriptor-Puffer-Engine 104 RD_0, RD_1 und RD_2, wobei die restlichen Indizes (z.B. RD_X-174, RD X-175, etc.) durch den dem RD_0 zugeordneten Deskriptor ersetzt werden. In solchen Beispielen überträgt die Deskriptor-Puffer-Engine 104 5664 Bit pro Taktzyklus (z.B. 5664 Bit/Taktzyklus = ((1 linker Deskriptor x 32 Bit/linker Deskriptor) + (176 rechte Deskriptoren x 32 Bit/rechter Deskriptor)), was etwa 4 Gigabyte (GB) pro Sekunde bei einer Frequenz von 700 Megahertz (MHz) entspricht.
Während der zweiten Phase führt der exemplarische Deskriptor-Selektor 106 für jeden Taktzyklus eine Kompandierungsoperation (z.B. einen Disparitätskompandierungsoperation) durch, um die 176 exemplarischen rechten Deskriptoren 234 auf 96 rechte Deskriptoren 234 basierend auf der folgenden Gleichung (2) zu komprimieren und/oder anderweitig zu reduzieren: $D = N + M + T$
Im obigen Beispiel von Gleichung (2) bestimmt der exemplarische Deskriptor-Selektor 106 eine Menge von Disparitäten (D) (hierin auch als Disparitätsmenge (D) bezeichnet), die nach dem Beispiel des Kostenabgleich-Engine 108 zu berechnen ist. Im veranschaulichten Beispiel von 2B bestimmt der Deskriptor-Selektor 106D auf 96. Der exemplarische Deskriptor-Selektor 106 wählt 96 der 176 rechten Deskriptoren 234 aus dem Beispiel Deskriptor-Puffer-Engine 104 aus, basierend auf D = 96, einen erster Kompandierungsparameter N = 48, einen zweiten Kompandierungparameter M = 32, und einen dritten Kompandierungsparameter T = 16. So kann beispielsweise der Deskriptor-Selektor 106 die 176 rechten Deskriptoren 234 in 96 rechte Deskriptoren 234 komprimieren, indem er Pixel für Pixel auf N-Disparitäten abgleicht, jeden zweiten Pixel auf M-Disparitäten abgleicht und jedesvierte Pixels auf T-Disparitäten abgelciht, wie unten beschrieben:

Jeder Deskriptor von Deskriptor 1 bis Deskriptor 48 der 176 rechten Deskriptoren 234 wird ausgewählt basierend auf N = 48, um 48 Deskriptoren zu erhalten;
Jeder zweite Deskriptor von Deskriptor 49 bis Deskriptor 112 der 176 rechten Deskriptoren 234 basierend auf M = 32, um 32 Deskriptoren zu erhalten; und
Jeder vierte Deskriptor von Deskriptor 113 bis Deskriptor 176 der 176 rechten Deskriptoren 234 basierend auf T = 16, um 16 Deskriptoren zu erhalten. Der exemplarische Deskriptor-Selektor 106 kann 96 der 176 rechten Deskriptoren 234 (z.B. 96 = 48 + 32 + 16) basierend auf Werten von N, Mund T wie oben beschrieben auswählen. Alternativ können auch alle anderen Werte von N, M und/oder T kann verwendet werden. Als Reaktion auf die Auswahl von 96 der 176 rechten Deskriptoren 234 überträgt der exemplarische Deskriptor-Selektor 106 die 96 Deskriptoren an die exemplarische Kostenabgleich-Engine 108.

Während der zweiten Phase speichert und/oder überträgt die exemplarische Deskriptor-Puffer-Engine 104 für jeden Taktzyklus einen weiteren linken Deskriptor 230, der einem zweiten Pixel entspricht, das im linken Bild 118 von 1 enthalten ist. So kann beispielsweise das zweite Pixel ein benachbartes Pixel zu einer rechten Seite des linken Pixels 124 im linken Bild 118 oder auf einer benachbarten Linie unter dem linken Pixel 124 sein. In der zweiten Phase speichert die exemplarische Deskriptor-Puffer-Engine 104 einen weiteren exemplarischen rechten Deskriptor 202 im exemplarischen Ringspeicher 232. So kann beispielsweise die Deskriptor-Puffer-Engine 104 den richtigen Deskriptor 202 an einem leeren oder unbesetzten Ort im Ringspeicher 232 speichern oder einen der ältesten der im Ringspeicher 232 gespeicherten Deskriptoren ersetzen.
2C ist eine schematische Darstellung der exemplarischen Kostenabgleich-Engine 108 des exemplarischenPipeline-Optimierungssystem 100 aus 1. Die exemplarische Kostenabgleich-Engine 108 identifiziert und/oder bestimmt anderweitig eine exemplarische Pixelintensität 236, die dem exemplarischen linken Pixel 124 von 1 zugeordnet ist, und bestimmt exemplarische Disparitäten 238, die dem linken Pixel 124 zugeordnet sind, basierend auf dem exemplarischen linken Deskriptor 230 und den exemplarischen rechten Deskriptoren 234 von 2B.
Im veranschaulichten Beispiel von 2C identifiziert die Kostenabgleich-Engine 108 die Pixelintensität 236 und bestimmt die Disparitäten 238 am Beispiel der Kostenabgleichzellen 240. Im veranschaulichten Beispiel von 2C gibt es 96 der Kostenabgleichzellen 240. Alternativ kann die exemplarische Kostenabgleich-Engine 108 weniger oder mehr als 96 der exemplarischen Kostenabgleichzellen 240 verwenden. Jede der exemplarischen Kostenabgleichzellen 240 erhält den linken Deskriptor 230 und einen der exemplarischen rechten Deskriptoren 234, die durch RD[0], RD[1], RD[127], etc. angezeigt werden. Die exemplarischen Kostenabgleichzellen 240 bestimmen einen Abgleichswert, der angibt, wie nah/fern das linke Pixel 124 von einer Kameraquelle ist, indem sie Disparitäten zwischen dem linken Pixel 124 und den entsprechenden Pixeln im Pixel-Kernel 128 im rechten Bild 120 von 1 berechnen. Die exemplarischen Kostenabgleichzellen 240 berechnen die Disparitäten basierend auf einer exemplarischen Kostenfunktion, die im Folgenden in den Gleichungen (3) und (4) beschrieben wird: $C O M B_C O S = α * A D + β (C T C ≪ 3)$
$C L A M P (C O M B_C O S T ≫ 5,127)$
Im obigen Beispiel von Gleichung (3) stellen die Abgleichkosten (COMB_COST) einen Parameter dar, der eine Ähnlichkeit der Bildorte für ein erstes Pixel in einem ersten Bild und ein zweites Pixel in einem zweiten Bild eines Stereo-Bildpaares misst und/oder anderweitig quantifiziert. Das Beispiel der obigen Gleichung (3) ist eine arithmetische Funktion, die eine Korrelation zwischen zwei Pixeln reduziert (z.B. minimiert). Beispielsweise gilt: Je kleiner der Wert für die COMB_COST desto besser ist die Korrelation zwischen den beiden Pixeln aus den beiden Ebenen (z.B. das linke Bild 118 und das rechte Bild 120 aus 1).
Im obigen Beispiel von Gleichung (3) sind die Ausdrücke α und β programmierbare Werte (z.B. konstante Werte). In einigen Beispielen sind α und β Werte, die von 0 bis 15 reichen können. Zum Beispiel, α kann einen Wert von 8 haben und β kann einen Wert von 12 haben. Im Beispiel der obigen Gleichung (3), ist AD die absolute Differenz zwischen zwei Pixelwerten. So kann beispielsweise die Kostenabgleichzelle 240 die absolute Differenz bestimmen, indem sie eine Differenz zwischen den ersten 8 Bit des linken Deskriptors 230 und den ersten 8 Bit des entsprechenden rechten Deskriptors 234 berechnet. Im Beispiel der obigen Gleichung (3) ist CTC die Zensus-Transformation der Kosten zwischen zwei Pixeln basierend auf des Hamming-Abstands. Zum Beispiel ist CTC der Hamming-Abstand basierend auf der Anzahl der Einser in der bitweisen XOR-Operation zwischen dem linken Deskriptor 230 und dem entsprechenden rechten Deskriptor 234. Im Beispiel von Gleichung (3) oben, bezieht sich „«“ auf einen Linksverschiebungsoperation. Als solche stellt„CTC « 3“ das Verschieben von CTC um 3 Bit nach links dar.
Im Beispiel von Gleichung (4) oben bezieht sich „»“ auf eine Rechtsverschiebungsoperation. Als solche stellt „COMB_COST » 5“ das Verschieben der COMB_COST nach rechts um 5 Bit dar. Im Beispiel der obigen Gleichung (4) spannen die exemplarischen Kostenabgleichzellen 240 den verschobenen COMB_COST -Wert zu einer ganzen Zahl in einem Bereich von 0 bis 127. Im veranschaulichten Beispiel von 2C erzeugen die Kostenabgleichzellen 240 die Disparitäten 238 unter Verwendung der Beispiele der obigen Gleichungen (3) und (4). So erzeugt beispielsweise jede der Kostenabgleichzellen 240 eine der 96 Disparitäten 238, wobei die 96 Disparitäten einem der Pixel im linken Bild 118 (z.B. dem linken Pixel 124) entsprechen. Die exemplarische Kostenabgleich-Engine 108 überträgt mindestens eine der exemplarischen Pixelintensitäten 236 oder die 96 Disparitäten 238 pro linkem Pixel an die exemplarische Kostenkonsolidierungs-Engine 110.
2D ist eine schematische Darstellung der exemplarischen Kostenkonsolidierungs-Engine 110 des exemplarischen Pipeline-Optimierungssystem 100 aus 1. Im veranschaulichten Beispiel von 2D empfängt und/oder erhält die Kostenkonsolidierungs-Engine 110 die Pixelintensität 236 von 2C von der Kkostenabgleich-Engine 108 von 2C. Im veranschaulichten Beispiel von 2D empfängt und/oder erhält die Kostenkonsolidierungs-Engine 110 die 96 Disparitäten 238 von 2C von der Kostenabgleich-Engine 108.
Im veranschaulichten Beispiel von 2D reduziert die Kostenkonsolidierungs-Engine 110 den Leistungsbedarf für die Operation des Pipeline-Optimierungssystems 100 durch die Reduzierung von Datenbewegungen in exemplarischen Barrel-Shiftern 241. Die exemplarische Kostenkonsolidierungs-Engine 110 von 2D beinhaltet 8 der exemplarischen Barrel-Shifter 241. Alternativ kann die exemplarische Kostenkonsolidierungs-Engine 110 weniger oder mehr als 8 der Barrel-Shifter 241 beinhalten. So ersetzt beispielsweise die Kostenkonsolidierungs-Engine 110 die in den Barrel-Shiftern 241 enthaltenen Daten ringförmig. In solchen Beispielen ersetzt die Kostenkonsolidierungs-Engine 110 Daten in einem der Barrel-Shifter 241 (z.B. #0 Barrel-Shifter, #1 Barrel-Shifter, etc.), je nachdem welcher der Barrel-Shifter 241 die ältesten Daten aus den Barrel-Shiftern 241 enthält. Jeder der exemplarischen Barrel-Shifter 241 speichert 96 Bits, wobei jedes Bit einer der Disparitäten 238 entspricht, die aus der Kostenabgleich-Engine 108 entnommen wurden, aber die hier offengelegten Beispiele beschränken sich nicht darauf. So ist beispielsweise jede der 96 Disparitäten 238 ein Bit (z.B. entsprechen 96 Disparitäten insgesamt 96 Bit) und kann vollständig in einem der Barrel-Shifter 241 gespeichert werden.
Im veranschaulichten Beispiel von 2D ordnet die Kostenkonsolidierungs-Engine 110 die von der Kostenabgleich-Engine 108 empfangenen Disparitäten 238 von den neuesten Daten auf die ältesten Daten um. So kann beispielsweise die Kostenkonsolidierungs-Engine 110 die 96 Disparitäten 238 neu ausrichten, wobei die mit den neuesten Pixeldaten verbundene Disparität auf Rang 0 und die ältesten Pixeldaten auf Rang 95 gesetzt werden. Als Reaktion auf die Neuausrichtung der Daten aus der exemplarischen Kostenabgleich-Engine 108 über die exemplarischen Barrel-Shifter 241 überträgt die Kostenkonsolidierungs-Engine 110 exemplarisch neu ausgerichtete Daten 242 an den exemplarischen SGBM-Aggregator 112. Die exemplarisch neu ausgerichteten Daten 242 beinhalten Daten, die in jedem der exemplarischen Barrel-Shifter 241 gespeichert sind, einschließlich der neuesten neu ausgerichteten Daten basierend auf den 96 Disparitäten 238, die aus der exemplarischen Kostenabgleich-Engine 108 abgerufen wurden. Die exemplarisch neu ausgerichteten Daten 242 des veranschaulichten Beispiels von 2D sind 96 Bytes (z.B. 96 Bytes = (12 Bytes/Barrel-Shifter) x 8 Barrel-Shifter)).
2E ist eine schematische Darstellung der exemplarischen SGBM-Aggregations-Engine 112 des exemplarischen Pipeline-Optimierungssystems 100 aus 1. Die exemplarische SGBM-Aggregations-Engine 112 verwendet eine semi-globale Technik zur Aggregation einer Kosten- oder Disparitätskarte. Eine Disparitätskarte (z.B. ein Diagramm, eine graphische Darstellung, eine Tabelle,usw.) kann einer Abbildung eines Disparitätswertes als Funktion der Tiefe entsprechen. So kann beispielsweise die Disparitätskarte verwendet werden, um eine Funktion zu erzeugen, die den Abstand einer Kamera zu einem Bildmerkmal (z.B. einem Becher, einem Tier, einem Gesicht usw.) in einer von der Kamera aufgenommenen Szene bestimmt, wobei der Abstand zwischen der Kamera und dem Bildmerkmal als Tiefe bezeichnet wird. So erzeugt beispielsweise die SGBM-Aggregations-Engine 112 eine Disparitätskarte, die auf einem Satz von Disparitätswerten für jedes Pixel im linken Bild 118 des Beispiels basiert. In solchen Beispielen kann die SGBM-Aggregations-Engine 112 eine Disparitätskarte für das linke Pixel 124 erzeugen, indem sie eine Menge von Disparitäten berechnet, die dem Tiefenbereich entspricht (z.B. ein Tiefenbereich von 64 Disparitäten, 96 Disparitäten, etc.) und die Disparitäten auf Tiefen oder Abstände zwischen dem linken Pixel 124 und einer Kameraquelle abbildet. Als Reaktion auf das Erzeugen der Disparitätskarte kann die exemplarische SGBM-Aggregations-Engine 112 einen Minimalwert der Disparitätskarte bestimmen. In einigen Beispielen entspricht der Mindestwert einer Koordinatendifferenz (z.B. horizontale Koordinaten, vertikale Koordinaten usw.) zwischen dem linken Pixel 124 und einem passenden der Pixel des rechten Bildes 120. In anderen Beispielen entspricht der Minimalwert einer Tiefe des linken Pixels 124 in Bezug auf die Kameraquelle.
Die semi-globale Technik ist mit einer Klasse von Algorithmen verbunden, die als dynamische Programmierung oder Glaubensausbreitung bekannt sind. Bei der Glaubensausbreitung wird ein Glaube oder Grenzkosten (z.B. ein Schätzwert) entlang eines bestimmten Pfades verbreitet, wobei das betrachtete vorherige Pixel (z.B. das linke Pixel 124 von 1) eine Auswahl beeinflusst, die an einem aktuellen Pixel getroffen wurde (z.B. ein benachbartes Pixel an einer rechten Seite des linken Pixels 124). Die exemplarische SGBM-Aggregations-Engine 112 reduziert und/oder minimiert anderweitig eine globale zweidimensionale (2D) Energiefunktion, die auf Disparitäten zwischen dem linken Pixel 124 und den im rechten Pixel-Kernel 128 von 1 enthaltenen Pixeln basiert, um Pfadkosten L_r zu erzeugen, wo r die Anzahl der ausgewerteten Pfade ist. Die exemplarische SGBM-Aggregations-Engine 112 bestimmt die Pfadkosten, wie sie unten in Gleichung (5) für jeden Pfad beschrieben sind: $\begin{matrix} L_{r} (x, y, d) = C (x, y, d) + min [E (x - 1, y, d), \\ E (x - 1, y, d - 1) + P_{1}, \\ E (x - 1, y, d + 1) + P_{1}, \\ min_{i} (E (x - 1, y, i) + P_{2})] \end{matrix}$
Das Beispiel der SGBM-Aggregations-Engine 112 verwendet das Beispiel der obigen Gleichung (5), um nach minimalen Pfadkosten einschließlich eventuell zusätzlicher Strafen P₁ und P₂ an der Position des vorherigen Pixels in einem Pfad (z.B. einer Pfadrichtung) zu suchen und die minimalen Pfadkosten zum Kostenwert C(x, y, d) an dem aktuellen Pixel x und die Ungleichheit d zu addieren.
Im Beispiel der obigen Gleichung (5) stellt der erste Ausdruck C(x,y, d) die entsprechenden Kosten C zwischen einem ersten Pixel (x) in einem ersten Bild (z.B. dem linken Pixel 124 von 1) und einem zweiten Pixel (y) in einem zweiten Bild (z.B. dem rechten Pixel 126 von 1) mit einer Disparität (d) dar. Der erste Ausdruck stellt beispielsweise die Abgleichkosten eines Pixels im Pfad r dar. Der zweite Ausdruck (E(x - 1, y, d)) stellt eine erste Energie dar, die den Abgleichkosten zwischen einem benachbarten Pixel und dem ersten Pixel (x - 1) und das zweite Pixel mit der Disparität entspricht. Zum Beispiel fügt der zweite Ausdruck die niedrigsten Abgleichkosten des vorherigen Pixels (x - 1) im Pfad r hinzu. Der dritte Ausdruck (E(x - 1, y, d - 1) + P₁) stellt eine zweite Energie dar, die einem Abgleichkosten zwischen dem benachbarten Pixel und dem zweiten Pixel entspricht, mit einem Disparitätswert, der dem benachbarten Pixel zugeordnet ist (d - 1), wobei ein erster Strafwert P₁ zu den Abgleichkosten für Disparitätsänderungen addiert wird. Der erste Strafwert wird zu den Abgleichkosten addiert, um den Einfluss eines früheren Aggregationsergebnisses zu drosseln und/oder anderweitig (E(x - 1,y,d)) im aktuellen Pixelergebnis E(x, y, d) zu erhöhen. Der vierte Ausdruck $(min_{i} (E (x - 1, y, i, i) + P_{2})$
verhindert ständig steigende PfadAbgleichkosten, indem die minimalen PfadAbgleichkosten des vorherigen Pixels von der gesamten Laufzeit abgezogen werden.
Die exemplarische SGBM-Aggregations-Engine 112 berechnet eine Summe der Energien für jeden Pfad, wie nachfolgend in Gleichung (6) beschrieben: $S (x, d) = \sum_{r = 1}^{3} L_{r} (x, d)$
Im obigen Beispiel von Gleichung (6) berechnet die SGBM-Aggregations-Engine 112 eine Summe von drei (3) Pfadkosten. Alternativ kann die exemplarische SGBM-Aggregations-Engine 112 weniger oder mehr als drei Pfadkosten berechnen, basierend auf einer Konfiguration einer oder mehrerer Komponenten der exemplarischen Pipeline 114 von 1. Die exemplarische SGBM-Aggregations-Engine 112 bestimmt eine endgültige Disparität zwischen dem linken Pixel 124 von 1 und dem rechten Pixel 126 von 1, indem sie die minimale Disparität für jeden Pfad sucht und/oder anderweitig bestimmt. Die exemplarische SGBM-Aggregations-Engine 112 speichert die endgültige Disparität für jedes Pixel des linken Bildes 118 von 1, um die Disparitätskarte zu erzeugen.
In einigen Beispielen werden mehrere Pfade als Eingangspfad in jedem Pixel betrachtet. In dem veranschaulichten Beispiel von 2E implementiert die SGBM-Aggregations-Engine 112 mindestens einen ersten Pfad, der einer Linksbewegung des aktuellen Pixels entspricht (z.B. einem horizontalen Pfad), einen zweiten Pfad, der einer Rechtsbewegung des aktuellen Pixels entspricht (z.B. einem horizontalen Pfad), oder einen dritten Pfad, der einer vertikalen Bewegung über dem aktuellen Pixel entspricht (z.B. einem vertikalen Pfad). In solchen Beispielen ist die Anzahl der betrachteten Pfade ein Parameter, der von der SGBM-Aggregations-Engine 112 zur Verarbeitung von Bilddaten verwendet wird.
Die exemplarische SGBM-Aggregations-Engine 112 von 2E beinhaltet einen exemplarischen Eingabekostenpuffer 250 und exemplarische Kostenaggregationszellen 252. Der exemplarische Eingabekostenpuffer 250 beinhaltet einen ersten exemplarischen Pixelpuffer 254 und einen zweiten exemplarischen Pixelpuffer 256. Jeder der exemplarischen Pixelpuffer 254, 256 sind 8 Bits, die einer Anzahl von Bits der exemplarischen Pixelintensität 236 entsprechen, die aus der exemplarischen Kostenkonsolidierungs-Engine 110 abgerufen werden. Alternativ können die Pixelpuffer 254, 256 des ersten und zweiten Beispiels 10 Bit betragen, wenn die Pixelintensität 236 10 Bit beträgt. Der erste exemplarische Pixelpuffer 254 erhält und speichert einen aktuellen Pixelwert, der verarbeitet wird (z.B. das linke Pixel 124 von 1). Der zweite exemplarische Pixelpuffer 256 erhält und speichert einen zuvor verarbeiteten Pixelwert (z.B. ein benachbartes Pixel auf der linken Seite des linken Pixels 124). Der zweite exemplarische Pixelpuffer 256 bildet den zuvor verarbeiteten Pixelwert (8 BIT Y) auf eine erste exemplarische Lookup-Tabelle (LUT) 258 und eine zweite exemplarische LUT 260 ab und/oder gibt sie anderweitig aus. Die exemplarische SGBM-Aggregations-Engine 112 überträgt die exemplarische Pixelintensität 236 über einen ersten exemplarischen Bypasspfad 262 an die erste und zweite exemplarische LUT 258, 260.
Im veranschaulichten Beispiel von 2E entspricht die erste LUT 258 einer horizontalen Ausgabe. So kann beispielsweise die SGBM-Aggregations-Engine 112 die Pixelintensität 236 des aktuellen Pixels über den ersten Bypasspfad 262 an die erste LUT 258 und die Pixelintensität eines zuvor verarbeiteten Pixels an die erste LUT 258 über den zweiten Pixelpuffer 256 übertragen. In solchen Beispielen berechnet die erste LUT 258 eine absolute Differenz zwischen dem aktuellen Pixelwert und dem zuvor verarbeiteten Pixelwert und bildet die absolute Differenz auf mindestens einen von einem ersten Strafwert (P1) oder einem zweiten Strafwert (P2) ab. Als Reaktion auf das Mapping überträgt die erste exemplarische LUT 258 mindestens einen der ersten Strafwerte oder den zweiten Strafwert an jede der exemplarischen Kostenaggregationszellen 252.
Im veranschaulichten Beispiel von 2E entspricht die zweite LUT 260 einer vertikalen Ausgabe. So kann beispielsweise die SGBM-Aggregations-Engine 112 den aktuellen Pixelwert über den ersten Bypasspfad 262 an die zweite LUT 260 und den zuvor verarbeiteten Pixelwert an die zweite LUT 260 über den zweiten Pixelpuffer 256 übertragen. In solchen Beispielen berechnet die zweite LUT 260 eine absolute Differenz zwischen dem aktuellen Pixelwert und dem zuvor verarbeiteten Pixelwert und bildet die absolute Differenz auf mindestens einen von einem ersten Strafwert (P1) und einem zweiten Strafwert (P2) ab. Als Reaktion auf das Mapping überträgt das zweite Beispiel LUT 260 mindestens einen der ersten Strafwerte oder den zweiten Strafwert an jede der exemplarischen Kostenaggregationszellen 252.
Im veranschaulichten Beispiel von 2E beinhaltet der Eingabekostenpuffer 250 einen exemplarischen Eingabekostenspeicher 264. Der exemplarische Eingabekostenspeicher 264 von 2E beinhaltet 1280 Datenwörter, wobei jedes der Datenwörter 768 Bit sind, aber die hier offengelegten Beispiele beschränken sich nicht darauf. So entspricht beispielsweise jedes der Datenwörter einem empfangenen der neu ausgerichteten Beispieldaten 242, die von der exemplarischen Kostenkonsolidierungs-Engine 110 empfangen wurden. So beträgt beispielsweise eine Instanz der neu ausgerichteten Daten 242 96 Byte oder 768 Bit. Der exemplarische Eingabekostenspeicher 264 überträgt einen zuvor bearbeiteten Satz der exemplarisch neu ausgerichteten Daten 242 an jede der exemplarischen Kostenaggregationszellen 252. Die exemplarische SGBM-Aggregations-Engine 112 überträgt den aktuellen Satz der neu ausgerichteten exemplarischen Daten 242 über einen zweiten exemplarischen Bypasspfad 266 an jede der Kostenaggregationszellen 252.
Im veranschaulichten Beispiel von 2E beinhaltet die SGBM-Aggregations-Engine 112 96 Kostenaggregationszellen 252, um die mit jedem Path-of-Interest verbundenen Abgleichkosten zu bewerten und/oder anderweitig zu verfeinern, jedoch werden nur vier der 96 aus Gründen der Übersichtlichkeit dargestellt. So berechnet beispielsweise jede der Kostenaggregationszellen 252 einen Abgleichsaufwand, der mindestens einem der horizontalen Pfade oder vertikalen Pfade des aktuellen Pixels zugeordnet ist. Jede der exemplarischen Kostenaggregationszellen 252 berechnet ein Beispiel für vertikale Gesamtkosten (TOP_AGR) 268 und ein Beispiel für horizontale Gesamtkosten (HOR_AGR) 270. So erzeugt beispielsweise eine erste der Kostenaggregationszellen 252 vertikale Gesamtkosten (T), die T[K+3][X] zugeordnet sind, wobei X das Pixel eines Eingabestroms und K ein Index eines 96er Kostenabgleichssatzes des X-Pixels ist. So ist beispielsweise ein Eingabestrom einer aggregierten Richtung (z.B. eine Richtung von links nach rechts, eine Richtung von rechts nach links, eine Richtung von rechts nach links, usw.) eine Anordnung von Pixeln mit einer Breite einer Bildlinie (z.B. eine Linie des linken Bildes 118), wobei jedes der Pixel 96 entsprechende Bits aufweist, die die Abgleichkosten für das Pixel darstellen. So stellt beispielsweise[K+3][X] einen K+3-Index der 96 übereinstimmenden Kosten für einen Eingabestromindex X dar. In solchen Beispielen erzeugt die erste der Kostenaggregationszellen 252 horizontale Gesamtkosten (A), die A[K+3][X] zugeordnet sind.
In dem veranschaulichten Beispiel von 2E gibt jede der Kostenaggregationszellen 252 die vertikalen Gesamtkosten 268 über einen exemplarischen vertikalen Zwischenaggregationspuffer 274 und einen exemplarischen vertikalen Aggregationspuffer 276 an einen exemplarischen Ausgabe-Aggregationspuffer 272 aus. Der exemplarische Ausgabeaggregationspuffer 272 von 2E speichert 1280 Datenwörter, wobei jedes der Datenwörter 768 Bit sind, aber die hier offengelegten Beispiele beschränken sich nicht darauf. Der exemplarische Ausgabeaggregationspuffer 272 speichert jeweils die exemplarischen vertikalen Aggregationskosten 268 aus den exemplarischen Kostenaggregationszellen 252. Der exemplarische vertikale Aggregationspuffer 276 von 2E beinhaltet 1280 Datenwörter, wobei jedes der Datenwörter 768 Bit sind, aber die hier offengelegten Beispiele beschränken sich nicht darauf.
Im veranschaulichten Beispiel von 2E speichert der exemplarische vertikale Aggregationspuffer 276 jeweils die exemplarischen vertikalen Aggregationskosten 268, bevor die vertikalen Aggregationskosten 268 an einen exemplarischen vertikalen Mindestkostendeterminator 278 übertragen werden. Der exemplarische vertikale Mindestkostendeterminator 278 identifiziert und/oder bestimmt anderweitig einen Mindestwert aus 96 Kosten, einschließlich der vier exemplarischen vertikalen Gesamtkosten 268, die durch die exemplarischen Kostenaggregationszellen 252 erzeugt werden, wobei die 96 Kosten mit 96 Disparitäten verbunden sind. Als Reaktion auf das Bestimmen der minimalen vertikalen Gesamtkosten überträgt der exemplarische vertikale Mindestkostendeterminator 278 die minimalen vertikalen Gesamtkosten an die jeweiligen Eingaben jeder der exemplarischen Kostenaggregationszellen 252.
In dem veranschaulichten Beispiel von 2E gibt jede der Kostenaggregationszellen 252 die horizontalen Gesamtkosten 270 an die jeweiligen Eingaben der Kostenaggregationszellen 252, einen exemplarischen horizontalen Mindestkostendeterminator 280 und den exemplarischen Ausgabe-Aggregationspuffer 272 über einen exemplarischen horizontalen Zwischenspeicher 282 aus. Der exemplarische horizontale Mindestkostendeterminator 280 von 2E identifiziert und/oder bestimmt anderweitig einen Mindestwert aus 96 Kosten, einschließlich der vier exemplarischen horizontalen Gesamtkosten 270, die durch die exemplarischen Kostenaggregationszellen 252 erzeugt werden, wobei die 96 Kosten mit 96 Disparitäten verbunden sind. Als Reaktion auf das Bestimmen der minimalen horizontalen Gesamtkosten überträgt der exemplarische horizontale Mindestkostendeterminator 280 die minimalen horizontalen Gesamtkosten an die jeweiligen Eingaben jeder der exemplarischen Kostenaggregationszellen 252.
3 ist eine schematische Darstellung der exemplarischen Verkettungslogik 224 von 2A. 3 stellt die exemplarische Verkettungslogik 224 für ein 16-Bit-Beispiel aus Gründen der Übersichtlichkeit dar. So kann beispielsweise die Verkettungslogik 224 eine 24-Bit-Deskriptoreingabe, eine 49-Bit-Deskriptoreingabe, eine 63-Bit-Deskriptoreingabeusw. erhalten und verarbeiten. Die exemplarische Verkettungslogik 224 stellt einen Sortierbaumansatz mit einer minimalen Tiefe von log(N)+1 Stufen dar, wobei N die Länge des Eingabestroms ist. Im veranschaulichten Beispiel von 3 wird ein exemplarischer Eingabebitstrom 302 mit einer exemplarischen Selektionsmaske 304 verarbeitet. Der exemplarische Eingabebitstrom 302 von 3 beträgt 16 Bit. Alternativ kann der exemplarische Eingabebitstrom 302 auch eine beliebige andere Anzahl von Bits sein, wie beispielsweise 24 Bit, 49 Bit oder 63 Bit. Die exemplarische Selektionsmaske 304 von 3 beträgt 16 Bit. Alternativ kann die exemplarische Selektionsmaske 304 eine beliebige andere Anzahl von Bits sein, wie beispielsweise 32 Bit oder 64 Bit. Die exemplarische Selektionsmaske 304 kann der exemplarischen Verkettungsmaske 228 aus 2A entsprechen.
Im veranschaulichten Beispiel von 3 werden die ersten Bits des Eingabebitstroms 302 und die zweiten Bits der Selektionsmaske mit der Beispiellogik UND den Gates 306 während einer ersten Beispielstufe 308 verarbeitet. Alternativ kann auch die erste Beispielstufe 308 entfernt werden. In dem veranschaulichten Beispiel von 3 beinhaltet eine zweite Beispielstufe 310 eine Reihe von 2-Bit-Sortierbäumen, die sich in Richtung des niedrigsten Bits (LSB) des Eingabebitstroms 302 um ein Maskenbit des Wertes 1 ausrichten und gleichzeitig die Anzahl der erforderlichen Verschiebungen in jedem 2-Bit-Paar zählen.
In dem veranschaulichten Beispiel von 3 beinhaltet eine dritte exemplarische Stufe 312 4-Bit-Sortierbäume, basierend auf den vorherigen 2-Bit-Paaren der zweiten Stufe 310. In dem veranschaulichten Beispiel von 3 beinhaltet eine vierte exemplarische Stufe 314 8-Bit-Sortierbäume, basierend auf den vorherigen 4-Bit-Paaren der dritten Stufe 312. Im veranschaulichten Beispiel von 3 führt eine fünfte Beispielstufe 316 eine bitweise ODER-Verknüpfung der vorherigen 8-Bit-Paare durch, um ein exemplarisches Endergebnis 318 zu erzeugen. Das exemplarische Endergebnis 318 von 3 kann dem exemplarischen Post-Masken-Deskriptor 226 von 2A entsprechen.
4 ist eine schematische Darstellung einer exemplarischen Korrelationsoperation 400, die von der exemplarischen Deskriptor-Puffer-Engine 104, der exemplarischen Kostenabgleichmaschine 108 und der exemplarischen Kostenkonsolidierungsmaschine 110 von 1 durchgeführt wird. Im veranschaulichten Beispiel von 4 ist die Korrelationsoperation 400 in mindestens drei Stufen unterteilt, um die Energieeffizienz zu erhöhen und/oder anderweitig zu verbessern. So reduziert beispielsweise die Korrelationsoperation 400 den Energieverbrauch der Pipeline 114 von 1, indem sie Datenbewegungen über Ringspeicher reduziert.
Im veranschaulichten Beispiel von 4 speichert die Deskriptor-Puffer-Engine 104 176 der rechten Deskriptoren 202 von 2A entsprechend den Pixeln, die im rechten Bild 120 von 1 enthalten sind, die durch die R-Reihe für jedes zu verarbeitende Pixel bezeichnet werden. Die exemplarische Deskriptor-Puffer-Engine 104 speichert den exemplarischen linken Deskriptor 230, der einem Pixel entspricht, das im linken Bild 118 von 1 enthalten ist, das durch die Zeile L bezeichnet wird.
Im veranschaulichten Beispiel von 4 gibt die Deskriptor-Puffermaschine 104 176 der rechten Deskriptoren 234 an den Deskriptor-Selektor 106 aus, um 96 der 176 rechten Deskriptoren 234 auszuwählen. Der exemplarische Deskriptor-Selektor 106 gibt die ausgewählten 96 rechten Deskriptoren 234 an die exemplarische Kostenablgleich-Engine108 aus, um die dem linken Deskriptor 230 und den jeweiligen rechten Deskriptoren 234 zugeordneten Abgleichkosten zu berechnen. Die exemplarische Kostenabgleich-Engine 108 von 4 berechnet 96 Beispielkosten 402, die durch C0, C1, etc. bezeichnet werden, wobei jeder der 96 Kosten 402 einer Differenz zwischen einem der rechten Deskriptoren 234 und dem linken Deskriptor 230 entspricht. So können beispielsweise die Kosten 402 den Disparitäten 238 von 2C entsprechen.
Im veranschaulichten Beispiel von 4 gibt der Kostenübereinstimmungs-Engine 108 die 96 Kosten 402 an den Kostenkonsolidierer 110 aus, um die Kosten 402 neu zu ordnen. Die exemplarische Kostenkonsolidierungs-Engine 110 organisiert die Beispielkosten 402 in einer Reihenfolge, in der der neueste der Kosten 402 als Rang 0 (z.B. der erste Index) und der älteste der Kosten 402 als Rang 95 (z.B. der letzte Index) identifiziert wird.
Die exemplarische Korrelationsoperation 400 von 4 stellt eine Vielzahl von Pixeln dar, die im linken Bild 118 von 1 enthalten sind und verarbeitet werden (z.B. iterativ verarbeitet). Die Korrelationsoperation 400 stellt beispielsweise ein erstes Beispielpixel (PIXEL 0) 404 dar, das verarbeitet wird. Das erste Beispielpixel 404 kann dem Beispiel des linken Pixels 124 aus 1 entsprechen. Der exemplarische Deskriptor-Puffer-Engine 104 lädt 176 der rechten Deskriptoren 234 und des linken Deskriptors 230 in den exemplarischen Ringspeicher 232 von 2B. Der exemplarische Deskriptor-Selektor 106 wählt 96 der 176 richtigen Deskriptoren 234 aus, die exemplarische Kostenabgleich-Engine 108 berechnet 96 exemplarische Kosten 402, die den 96 ausgewählten rechten Deskriptoren 234 zugeordnet sind, und die exemplarische Kostenkonsolidierungs-Engine 110 ordnet die 96 Kosten 402 neu.
Als Reaktion auf die Verarbeitung des ersten Beispielpixels 404 verarbeitet die exemplarische Korrelationsoperation 400 ein zweites Beispielpixel (PIXEL 1) 406, wobei die exemplarische Deskriptor-Puffer-Engine 104 den dem ersten Beispielpixel 404 zugeordneten exemplarischen rechten Deskriptor 234 durch den einem benachbarten Pixel zugeordneten rechten Deskriptor 234 ersetzt, während die verbleibenden rechten Deskriptoren 234 erhalten bleiben, um Datenbewegungen zu reduzieren und damit den Energieverbrauch der exemplarischen Pipeline 114 aus 1 zu reduzieren. So kann beispielsweise die Deskriptor-Puffer-Engine 104 ein im Pixel-Kernel 128 von 1 enthaltenes linkes Pixel durch ein angrenzendes Pixel (z.B. das nächste Pixel rechts vom Pixel-Kernel 128) ersetzen, wenn das den Pixel-Kernel 128 umgebende Fenster um einen Index nach rechts verschoben wird. Die exemplarische Deskriptor-Puffer-Engine 104 gibt die 176 exemplarischen rechten Deskriptoren 234 einschließlich des rechten Deskriptors 234 des benachbarten Pixels an den exemplarischen Deskriptor-Selektor 106 aus, der 96 der 176 rechten Deskriptoren 234 an die exemplarische Kostenabgleich-Engine 108 auswählt. Die exemplarische Kostenabgleich-Engine 108 berechnet 96 der exemplarischen Kosten 402, indem sie die ersten Kosten 402 (C0) durch eine neue Kostenart (C95) ersetzt, die dem benachbarten Pixel im rechten Bild 120 zugeordnet ist. Die exemplarische Korrelationsoperation 400 führt die obigen Operationen für eine Vielzahl von Pixeln (z.B. PIXEL 2, PIXEL 3, etc.) durch.
5 ist eine schematische Darstellung einer exemplarischen SGBM-Aggregationszelle (K) 502 aus 2E. Das Beispiel SGBM-Aggregationszellen 502 ist ein erstes Beispiel für eine SGBM-Aggregationszellen. Im veranschaulichten Beispiel von 5 kann die erste SGBM-Aggregationszelle 502 einer der Kostenaggregationszellen 252 von 2E entsprechen. Die erste exemplarische SGBM-Aggregationszelle 502 von 5 beinhaltet eine erste Beispiel-Pipe (PIPE 1) 504 (z.B. eine Pipeline), das ein Beispiel für Abgleichkosten 506 über ein Beispiel für Abgleichkostenregister 508 abruft und speichert. Das exemplarische Abgleichkostenregister 508 speichert Abgleichkosten, die verarbeitet und an die nächste Stufe der ersten exemplarischen SGBM-Aggregationszelle 502 weitergeleitet werden sollen. So kann beispielsweise das Abgleichkostenregister 508 die 96 Bytes große Disparität von 2E speichern, die vom Eingabeostenspeicher 264 ausgegeben werden.
Die erste Beispiel-Pipe 504 von 5 ruft ein exemplarisches Bypass-Flag 510 über ein exemplarisches Bypass-Flag-Register 512 ab. Das exemplarische Bypass-Flag 510 ist für einen ersten Kostenpunkt in einer Bildzeile (z.B. einen Kostenpunkt, der einem ersten Pixel in einer Zeile des linken Bildes 118 von 1 zugeordnet ist) pro Aggregationsrichtung gesetzt, so dass die ersten Kosten unverändert durch die Beispiel-SGBM-Aggregationszelle 500 gedrückt werden, da als erste Kosten keine vorherigen Kosten oder Daten zu aggregieren sind. Für Folgekosten in der Bildzeile ist das exemplarische Bypass-Flag 510 nicht gesetzt.
Die erste Beispiel-Pipe 504 von 5 ruft eine exemplarische Pixelintensität 514 in einem exemplarischen Pixelintensitätsregister 516 ab und speichert diese. Das exemplarische Pixelintensitätsregister 516 sendet Pixelintensitätswerte an einen exemplarischen absoluten Differenzrechner 518, um eine Differenz zwischen zwei aufeinanderfolgenden Pixeln (z.B. einem aktuellen Pixel (Y_IN) und einem vorherigen Pixel (Y_IN) zu berechnen. So können beispielsweise die beiden aufeinanderfolgenden Pixel das linke Pixel 124 von 1 und ein benachbartes Pixel zu einer rechten Seite des linken Pixels 124 sein. Der exemplarische Absolutdifferenzrechner 518 überträgt die absolute Differenz an eine exemplarische Straf-Lookup-Tabelle (LUT) 520, um die absolute Differenz zwischen den aufeinanderfolgenden Pixeln auf einen ersten exemplarischen Strafwert (P1) 522 und einen zweiten exemplarischen Strafwert (P2) 524 abzubilden.
In der Operation berechnet die erste exemplarische SGBM-Aggregationszelle 502 aus 5 eine erste Beispielsumme 526 eines ersten Beispiels aggregierter Kosten 528, berechnet durch eine zweite exemplarische Aggregationszelle (K + 1) 530 und dem ersten exemplarischen Strafwert 522Die erste exemplarische SGBM-Aggregationszelle 502 von 5 berechnet eine zweite Beispielsumme 532 eines zweiten Beispiels aggregierter Kosten 534, die von der ersten SGBM-Aggregationszelle 502 und dem ersten exemplarischen Strafwert 522 berechnet wird. Die erste exemplarische SGBM-Aggregationszelle 502 von 5 berechnet eine dritte Beispielsumme 536 eines dritten Beispiels aggregierter Kosten 538, berechnet durch eine dritte exemplarische SGBM-Aggregationszelle (K-1) 540 und dem ersten exemplarischen Strafwert 522.
Die erste exemplarische SGBM-Aggregationszelle 502 von 5 berechnet eine vierte Beispielsumme 542 des zweiten Beispiels Strafenwert 524 und ein viertes Beispiel aggregierter Kosten 544, wobei die vierten aggregierten Kosten 544 ein Mindestwert sind, der durch einen exemplarischen Sortierbaum 546 berechnet wird. Der exemplarische Sortierbaum 546 bestimmt einen Mindestwert aus einer Vielzahl von horizontalen Aggregatkosten und/oder vertikalen Aggregatkosten. So kann beispielsweise der Sortierbaum 546 dem vertikalen Mindestwertdeterminator 278, dem horizontalen Mindestwertdeterminator 280 und/oder einer Kombination davon entsprechen. So stellt beispielsweise der Sortierbaum 546 hardware- und/oder maschinenlesbare Anweisungen zum Ausführen eines Sortieralgorithmus dar, der aus den zu sortierenden Elementen einen binären Suchbaum aufbaut und dann den Baum (in Reihenfolge) durchläuft, so dass die Elemente in sortierter Reihenfolge ausgegeben werden. Der exemplarische Sortierbaum 546 ermöglicht eine Latenzzeit der exemplarischen SGBM-Aggregationszellen 502, 530, 540 zu einem Taktzyklus, indem 96 gespeicherte Kosten (z.B. horizontale Kosten, vertikale Kosten, etc.) in einen Mindestwert entsprechend einem der 96 sortierten Kosten sortiert werden.
Im veranschaulichten Beispiel von 5 führt jede der exemplarischen SGBM-Aggregationszellen 502, 530, 540 jeden der drei Aggregationspfade in zwei aufeinanderfolgenden Zyklen aus. So führt beispielsweise jede der SGBM-Aggregationszellen 502, 530, 540 während eines ersten Zyklus den Aggregationsweg von links nach rechts durch und/oder erleichtert ihn anderweitig. Während eines zweiten Zyklus führt jede der exemplarischen SGBM-Aggregationszellen 502, 530, 540 den Aggregationspfad von rechts nach links und den Aggregationspfad von oben nach unten durch und/oder erleichtert ihn anderweitig. Jede der exemplarischen SGBM-Aggregationszellen 502, 530, 540 ist für die Aggregation einer der 96 Disparitäten oder Kostensätze für ein Pixel verantwortlich.
In dem veranschaulichten Beispiel von 5 stellen die ersten bis vier aggregierten Kosten 528, 534, 538, 544 ein Verfahren zur Verbesserung der Qualität der Korrelationskosten pro Pixel von ihren Anfangswerten dar, die von der Kostenabgleich-Engine 108 von 1 ausgegeben werden, indem Trends von benachbarten Pixeln in aggregierten Richtungen oder Pfaden ausgebreitet werden. So kann beispielsweise erste aggregierte Kosten 528 einem ersten horizontalen Pfad von links nach rechts entsprechen, wobei der erste horizontale Pfad die Verarbeitungspixel im linken Bild 118 von 1 von links nach rechts darstellt, wobei die Pixel (z.B. die Abgleichkosten der Pixel) rechts durch das Ergebnis der vorherigen Aggregation ihres linken Nachbarn beeinflusst werden. Für einen Pfad r kann die exemplarische SGBM-Aggregationszelle 502 einen Abgleich der Kosten berechnen, der mit einem Pixel am Rand eines Bildes beginnt und mit dem Bildpunkt endet. So bestimmt beispielsweise die SGBM-Aggregationszelle 502 für einen Links-Rechts-Pfad des rechten Bildes 120 aus 1 für jedes Pixel im Pfad Abgleichkosten, die von einem ersten Pixel am linken Rand des rechten Bildes 120 bis zum Zentralpixel 126 des rechten Bildes 120 reichen.
In anderen Beispielen können die dritten Gesamtkosten 538 einem zweiten horizontalen Pfad von rechts nach links entsprechen, wobei der zweite horizontale Pfad Verarbeitungspixel im linken Bild 118 von 1 von rechts nach links darstellt, wobei die Pixel (z.B. die Abgleichkosten der Pixel) auf der linken Seite durch das Ergebnis der vorherigen Aggregation ihres rechten Nachbarn beeinflusst werden. So bestimmt beispielsweise die SGBM-Aggregationszelle 502 für einen Rechts-Links-Pfad des rechten Bildes 120 aus 1 für jedes Pixel im Pfad Abgleichkosten, der von einem ersten Pixel am rechten Rand des rechten Bildes 120 bis zum Zentralpixel 126 des rechten Bildes 120 reicht.
Im veranschaulichten Beispiel von 5 bestimmt eine erste exemplarische Minimalfunktion 548 einen ersten Mindestwert der ersten bis vierten Summen 526, 532, 536, 542. Die exemplarische SGBM-Aggregationszelle 502 beinhaltet eine zweite exemplarische Minimalfunktion 550, um aus einer Differenz zwischen (1) einer Summe der exemplarischen Abgleichkosten K 506 und den vierten exemplarischen Gesamtkosten 544 und (2) dem ersten Mindestwert einen zweiten Mindestwert zu bestimmen. So bestimmt beispielsweise die zweite Minimalfunktion 550, ob ein mit einem aktuellen Pixel verbundener Abgleichsaufwand (z.B. das linke Pixel 124 von 1) eine minimale Abweichung ist. So führt beispielsweise jede der SGBM-Aggregationszellen 502, 530, 540 die Beispiele der obigen Gleichung (5) und/oder (6) über die erste Minimalfunktion 548 und die zweite Minimalfunktion 550 aus und/oder implementiert diese anderweitig.
Die zweite exemplarische Minimalfunktion 550 des veranschaulichten Beispiels von 5 gibt den zweiten Minimalwert an ein exemplarisches Aggregationskostenregister 552 aus, das in einer zweiten Beispiel-Pipe (PIPE 2) 554 enthalten ist, um den zweiten Mindestwert zu speichern. Obwohl sich die Beschreibung in Verbindung mit 5 auf die ersten exemplarischen SGBM-Aggregationszellen 502 bezieht, gilt die Beschreibung auch für die zweite nund dritten exemplarischen SGBM-Aggregationszellen 530, 540. So beinhalten beispielsweise die zweiten und dritten SGBM-Aggregationszellen 530, 540 im Wesentlichen ähnliche Komponenten (z.B. einen Teil oder eine Gesamtheit der Komponenten) und erfüllen im Wesentlichen die gleichen Funktionen (z.B. einen Teil oder eine Gesamtheit der Funktionen) wie die ersten SGBM-Aggregationszellen 502.
6 ist eine schematische Darstellung eines exemplarischen Stereo-Pipeline-Datenstroms 600 zur Umsetzung der hier offengelegten Beispiele. Während einer ersten Zeitinstanz liest die exemplarische CT-Engine 102 von 1 eine erste rechte Zeile (RL_0) 602 aus. Während einer zweiten Zeitinstanz erzeugt die exemplarische CT-Engine 102 einen ersten CT (CT RL_0) 604 der ersten rechten Zeile 602. So erzeugt beispielsweise die CT-Engine 102 den richtigen Deskriptor 202 aus 1. Während der zweiten Zeitinstanz liest die exemplarische CT-Engine 102 eine erste linke Zeile (LL_0) 606 aus. Während einer dritten Zeitinstanz liest und speichert die exemplarische Deskriptor-Puffer-Engine 104 von 1 den ersten CT 604 im exemplarischen Ringspeicher 232 von AB. 2B, der als erste exemplarische rechte Deskriptorzeile (BUFF RDL_0) 608 gespeichert wird.
Während einer vierten Zeitinstanz überträgt die exemplarische Deskriptor-Puffer-Engine 104 die erste exemplarische rechte Deskriptorzeile 608 an den exemplarischen Deskriptor-Selektor 106 und/oder die exemplarische Kostenabgleich-Engine 108. Während der vierten Zeitinstanz erhält die exemplarische Kostenabgleich-Engine 108 die erste linke Zeile 606, um eine Kostenabgleichsoperationdurchzuführen. Während einer fünften Zeitinstanz erzeugt die exemplarische Kostenabgleich-Engine 108 eine erste exemplarische Kostenabgleichzeile von links nach rechts (L2R CML_0) 610.
Während einer sechsten Zeitinstanz überträgt die exemplarische Kostenabgleich-Engine 108 die erste linke zu rechte Kostenabgleichzeile 610 an die exemplarische Kostenkonsolidierungs-Engine 110, um Bilddaten einschließlich der ersten linken zu rechten Kostenabgleichszeile 610 zu sortieren. Während einer siebten Zeitinstanz überträgt die exemplarische Kostenkonsolidierungs-Engine 110 die sortierten Bilddaten an die SGBM-Aggregations-Engine 112 von 1, um eine erste exemplarische linke zu rechte Kostenaggregationszeile (L2R CAL_0) 612, eine erste exemplarische rechte zu linke Aggregationszeile (R2L AL_0) 614 und eine erste exemplarische obere zu untere Aggregationszeile (T2B AL_0) 616 zu bestimmen. Während einer achten Zeitinstanz erzeugt die exemplarische SGBM-Aggregations-Engine 112 eine erste exemplarische Ausgabedisparitätslinie (ODL_0) 618.
Als Reaktion auf das Erzeugen von Ausgabedisparitätslinien für jede Zeile des Eingabebildes (z.B. das linke Bild 118 von 1) beinhaltet der exemplarische Pipeline-Datenfluss 600 Dumping-Zensus-Transformdeskriptoren (DCTD) 620, Dumping einer Kostenkarte (DCM) 622 und Dumping einer aggregierten Kostenkarte (DACM) 624. Der exemplarische Pipeline-Datenfluss 600 endet, wenn für jede Zeile des Eingangsbildes Ausgabedisparitätslinien bestimmt werden. So kann beispielsweise die Pipeline 114 von 1 basierend auf den Ausgabedisparitätslinien eine Stereoabgleich der im linken Bild 118 von 1 enthaltenen Pixel und der im rechten Bild 120 von 1 enthaltenen Pixel durchführen.
7 ist ein Blockdiagramm einer exemplarischen Implementierung eines exemplarischen SIPP-Beschleunigers 700. Der exemplarische SIPP-Beschleuniger 700 führt eine Bildverarbeitungsoperation wie z.B. die Stereoabgleich durch. So kann beispielsweise der SIPP-Beschleuniger 700 ein 3D-Modell einer Umgebung, einer Szene usw. schätzen und/oder anderweitig bestimmen, indem er zwei oder mehrere Bilder (z.B. Fotos, Videobilder usw.) aufnimmt und passende Pixel in den zwei oder mehreren Bildern identifiziert und 2D-Positionen der Pixel in 3D-Tiefen umwandelt. So kann beispielsweise der SIPP-Beschleuniger 700 die relative Tiefe von Punkten in der Umgebung mit einer Stereo-Disparitätskarte schätzen, die aus dem Abgleich entsprechender Punkte in den beiden oder mehreren Bildern (z.B. einem Stereo-Bildpaar) aufgebaut ist. Der exemplarische SIPP-Beschleuniger 700 beschleunigt und/oder erhöht anderweitig die Geschwindigkeit einer Disparitätsberechnung aus ausgerichteten Bildern, die einen entsprechend großen Durchsatz aufweisen.
In dem veranschaulichten Beispiel von 7 beinhaltet der SIPP-Beschleuniger 700 einen exemplarischen Zensus-Transformationshandler 702, einen exemplarischen Deskriptormanager 704, einen exemplarischen Kostenberechnungsmanager 706 und einen exemplarischen Aggregationsgenerator. Der exemplarische SIPP-Beschleuniger 700 von 7 beinhaltet den exemplarischen Zensus-Transformationshandler 702, um eine Zensus-Transformation durchzuführen und/oder anderweitig zu erleichtern. So kann beispielsweise der Zensus-Transformationshandler 702 der CT-Engine 102 von 1 entsprechen und/oder anderweitig implementieren. Der exemplarische Zensus-Transformationshandler 702 beinhaltet Mittel zum Abrufen von Pixelwerten, die Pixeln eines in einem Eingabebild enthaltenen Pixel-Kernels oder Auswertefensters zugeordnet sind, zum Vergleichen der Pixelwerte mit einem Pixelwert eines Zentralpixels, einem Schwellenwert, einem Mittelwert usw. und zum Erzeugen von Deskriptoren basierend auf dem Vergleich.
In einigen Beispielen erzeugt der Zensus-Transformationshandler 702 einen 25-Bit Pre-Mask-Bit-Deskriptor (z.B. den Pre-Mask-Bit-Deskriptor 222 von 2A), basierend auf dem Vergleich von Pixeln eines 5x5-Pixel-Kernels mit einem Vergleichswert. In anderen Beispielen erzeugt der Zensus-Transformationshandler 702 einen 49-Bit Pre-Mask-Bit-Deskriptor basierend auf einem 7x7-Kernel, einen 63-Bit Pre-Mask-Bit-Deskriptor basierend auf einem 7x9-Kernel, etc. Der exemplarische Zensus-Transformationshandler 702 wendet die Null-Latenz, zufällige Bitverkettungslogik auf den Pre-Mask-Bitdeskriptor an, um einen Post-Mask-Bitdeskriptor (z.B. den Post-Mask-Bitdeskriptor 202 von 2A) zu erzeugen. So kann beispielsweise der Zensus-Transformationshandler 702 die Verkettungslogik 224 der 2A und/oder 3 implementieren, um den Post-Mask-Bitdeskriptor zu erzeugen.
Der exemplarische SIPP-Beschleuniger 700 von 7 beinhaltet den exemplarischen Deskriptormanager 704, um einen Deskriptor (z.B. den Post-Mask-Bitdeskriptor 202 von 2A) für eine Kostenkorrelationsoperation zu behandeln und/oder anderweitig vorzubereiten. So kann beispielsweise der Deskriptormanager 704 mindestens einer der Deskriptor-Puffer-Engines 104 oder dem Deskriptor-Selektor 106 von 1 entsprechen und/oder anderweitig implementieren. Der exemplarische Deskriptormanager 704 beinhaltet Mittel zum Abrufen eines oder mehrerer Bitdeskriptoren nach der Maske, die durch den exemplarischen Zensus-Transformationshandler 702 erzeugt wurden, und zur Selektion eines oder mehrerer der Bitdeskriptoren nach der Maske basierend auf der Befehlslogik. So kann beispielsweise der Deskriptormanager 704 einen vom Zensus-Transformationshandler 702 erzeugten Post-Mask-Bitdeskriptor abrufen, den Post-Mask-Bitdeskriptor ringförmig über einen oder mehrere Ringspeicher speichern und eine Teilmenge der gespeicherten Post-Mask-Bitdeskriptoren basierend auf einer Befehlslogik auswählen.
Der exemplarische SIPP-Beschleuniger 700 von 7 beinhaltet den exemplarischen Kostenberechnungsmanager 706, um Abgleichkosten zu erzeugen und/oder anderweitig zu bestimmen, die einer Differenz in den Bildorten von Pixeln in verschiedenen Bildern entsprechen. So kann beispielsweise der Kostenberechnungsmanager 706 mindestens einer der Kostenübereinstimmungs-Engine 108 oder der Kostenkonsolidierungs-Engine 110 aus 1 entsprechen und/oder anderweitig implementieren. Der exemplarische Kostenberechnungsmanager 706 beinhaltet Mittel zum Abrufen eines ersten Deskriptors, der einem ersten Pixel eines ersten Bildes zugeordnet ist (z.B. der exemplarische linke Deskriptor 230 von 2C) und Deskriptoren, die einem zweiten Pixel eines zweiten Bildes zugeordnet sind (z.B. die 96 rechten Deskriptoren 234 von 2C), und zum Bestimmen mindestens eines der Pixelintensitätswerte des ersten Pixels oder der dem ersten Pixel zugeordneten Disparitäten. So kann beispielsweise der Kostenberechnungsmanager 706 eine Disparität berechnen, indem er mindestens eine der obigen Gleichungen (4) oder Gleichung (5) bewertet und/oder anderweitig ausführt.
In einigen Beispielen bestimmt der Kostenberechnungsmanager 706 eine Vielzahl von Disparitäten für jeden Bildpunkt. So kann beispielsweise der Kostenberechnungsmanager 706 das linke Pixel 124 von 1 zur Verarbeitung auswählen. Der exemplarische Kostenberechnungsmanager 706 wählt den Pixel-Kernel 128 von 1 zur Verarbeitung aus. Der exemplarische Kostenberechnungsmanager 706 berechnet eine Disparität für jedes der im Pixel-Kernel 128 enthaltenen Pixel in Bezug auf das linke Pixel 124. Als Reaktion auf die Berechnung der Disparitäten kann der exemplarische Kostenberechnungsmanager 706 einen anderen Pixel-Kernel des exemplarischen rechten Bildes 120 zur Verarbeitung auswählen. So kann beispielsweise der Kostenberechnungsmanager 706 Pixel-Kernel des rechten Bildes 120 verarbeiten, bis das gesamte rechte Bild 120 verarbeitet ist.
Der exemplarische SIPP-Beschleuniger 700 von 7 beinhaltet den exemplarischen Aggregationsgenerator 708, um eine Disparitätskarte mit einer oder mehreren Disparitäten zu erzeugen und eine minimale Disparität basierend auf der Disparitätskarte zu bestimmen, wobei die minimale Disparität einer Differenz in Koordinaten (z.B. horizontale Koordinaten, vertikale Koordinaten usw.) zwischen Pixeln in verschiedenen Bildern entspricht. Der exemplarische Aggregationsgenerator 708 beinhaltet Mittel zum Bestimmen der aggregierten Kosten, die einem oder mehreren Ausbreitungspfaden zugeordnet sind, zum Erzeugen einer Disparitätskarte basierend auf den aggregierten Kosten und/oder zum Identifizieren eines passenden Pixel im rechten Beispielbild 120 von 1 zum linken Beispielbild 118 basierend auf mindestens einem der aggregierten Kosten, einem oder mehreren der Disparitäten oder der Disparitätskarte.
In einigen Beispielen berechnet der Aggregationsgenerator 708 erste aggregierte Kosten, die einem ersten Ausbreitungspfad zugeordnet sind, das einem von links nach rechts gerichteten Eingabepfad vom zweiten Pixel zum ersten Pixel entspricht. Der exemplarische Aggregationsgenerator 708 berechnet zweite aggregierte Kosten, die einem zweiten Ausbreitungsweg zugeordnet sind, der einem rechts-nach-links-Eingabepfad vom zweiten Pixel zum ersten Pixel entspricht. Der exemplarische Aggregationsgenerator 708 berechnet dritte aggregierte Kosten, die einem dritten Ausbreitungsweg zugeordnet sind, der einem von oben nach unten verlaufenden Eingabepfad vom zweiten Pixel zum ersten Pixel entspricht. Als Reaktion auf das Bestimmen der ersten, zweiten und dritten aggregierten Kosten bestimmt der exemplarische Aggregationsgenerator 708 einen Mindestwert aus den ersten bis dritten aggregierten Kosten und erzeugt eine Disparitätskarte für eine Vielzahl von Pixeln, um Pixel in verschiedenen Bildern eines Stereo-Bildpaares abzugleichen.
Die Mittel des exemplarischen Zensus-Transformationshandlers, des exemplarischen Deskriptormanagers, des exemplarischen Kostenrechnungsmanagers und/oder des Aggregationsgenerators des veranschaulichten Beispiels von 7 werden durch Software implementiert, die auf einem Hardwareprozessor ausgeführt wird. Zusätzlich oder alternativ könnten die Mittel des exemplarischen Zensus-Transformationshandlers, des exemplarischen Deskriptormanagers, des exemplarischen Kostenberechnungsmanagers und/oder des Aggregationsgenerators stattdessen durch eine Logikschaltung implementiert werden, die so strukturiert ist, dass sie logische Operationen durchführt, um die gewünschte Funktionalität zu erreichen, wie beispielsweise ein ASIC, ein FPGA oder dergleichen und/oder eine Kombination aus solchen Schaltungen und Software und/oder Firmware.
Während eine exemplarische Art der Implementierung des exemplarischen SIPP-Beschleunigers 700 von 7 in 7 dargestellt ist, können eines oder mehrere der in 7 dargestellten Elemente, Prozesse und/oder Vorrichtungen kombiniert, geteilt, neu ausgerichtet, weggelassen, eliminiert und/oder auf andere Weise implementiert werden. Weiterhin kann der exemplarische Zensus-Transformationshandler 702, der exemplarische Deskriptormanager 704, der exemplarische Kostenberechnungsmanager 706, der exemplarische Aggregationsgenerator 708 und/oder ganz allgemein der exemplarische SIPP-Beschleuniger 700 aus 7 durch Hardware, Software, Firmware und/oder eine beliebige Kombination aus Hardware, Software und/oder Firmware implementiert werden. So kann beispielsweise jeder der exemplarischen Zensus-Transformationshandler 702, der exemplarische Deskriptormanager 704, der exemplarische Kostenberechnungsmanager 706, der exemplarische Aggregationsgenerator 708 und/oder ganz allgemein der exemplarische SIPP-Beschleuniger 700 durch eine oder mehrere analoge oder digitale Schaltungen, Logikschaltungen, programmierbare(r) Prozessor(en), programmierbare(r) Controller, Grafikprozessor(en) (GPU(s)), digitale Signalprozessoren (DSP(s)), anwendungsspezifische integrierte Schaltung(en) (ASIC(s)), programmierbare(r) Logikgerät(e) (PLD(e)) und/oder feldprogrammierbare(r) Logikgerät(e) (FPLD(e)) implementiert werden. Um eine reine Software- und/oder Firmware-Implementierung abzudecken, wird bei Betrachtung eines der Vorrichtungs- oder Systemansprüche dieses Patents mindestens einer der exemplarischen Zensus-Transformationshandler 702, der exemplarischen Deskriptormanager 704, der exemplarischen Kostenberechnungsmanager 706 und/oder der exemplarischen Aggregationsgeneratoren 708 hiermit ausdrücklich definiert, um eine nicht-flüchtige computerlesbare Speichervorrichtung oder Speicherplatte wie einen Speicher, eine Digital Versatile Disk (DVD), eine Compact Disk (CD), eine Blu-ray-Disk usw. einschließlich der Software und/oder Firmware zu beinhalten. Weiterhin kann der exemplarische SIPP-Beschleuniger 700 von 7 ein oder mehrere Elemente, Prozesse und/oder Vorrichtungen zusätzlich zu oder anstelle von den in 7 dargestellten beinhalten und/oder mehr als eines der dargestellten Elemente, Prozesse und Vorrichtungen beinhalten. Wie hierin verwendet, umfasst der Begriff „in Kommunikation“, einschließlich seiner Variationen, die direkte Kommunikation und/oder indirekte Kommunikation über eine oder mehrere Zwischenkomponenten und erfordert keine direkte physikalische (z.B. drahtgebundene) Kommunikation und/oder konstante Kommunikation, sondern zusätzlich eine selektive Kommunikation in periodischen Intervallen, geplanten Intervallen, aperiodischen Intervallen und/oder einmaligen Ereignissen.
Flussdiagramme, die für exemplarische Hardwarelogik, maschinenlesbare Anweisungen, hardwareimplementierte Zustand-Engines und/oder jede beliebige Kombination davon zur Implementierung des exemplarischen SIPP-Beschleunigers 700 von 7 stehen, sind in den 8-10 dargestellt. Die maschinenlesbaren Anweisungen können ein ausführbares Programm oder ein Teil eines ausführbaren Programms zur Ausführung durch einen Computerprozessor sein, wie beispielsweise den Prozessor 1212, der in der exemplarischen Prozessorplattform 1200 dargestellt ist, die nachfolgend in Verbindung mit 12 erläutert wird. Das Programm kann in Software enthalten sein, die auf einem nicht-flüchtigen, computerlesbaren Speichermedium gespeichert ist, wie beispielsweise einer CD-ROM, einer Diskette, einer Festplatte, einer DVD, einer Blu-ray-Disk oder einem dem Prozessor 1212 zugeordneten Speicher, aber das gesamte Programm und/oder Teile davon können alternativ von einer anderen Vorrichtung als dem Prozessor 1212 und/oder in Firmware oder dedizierter Hardware ausgeführt werden. Obwohl das Beispielprogramm mit Bezug auf die in den 8-10 dargestellten Flussdiagramme beschrieben ist, können alternativ viele andere Methoden zur Implementierung des exemplarischen SIPP-Beschleunigers 700 verwendet werden. So kann beispielsweise die Reihenfolge der Ausführung der Sätze geändert werden und/oder einige der beschriebenen Sätze können geändert, eliminiert oder kombiniert werden. Zusätzlich oder alternativ können einzelne oder alle Blöcke durch eine oder mehrere Hardwareschaltungen (z.B. diskrete und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, ein ASIC, ein Komparator, ein Operationsverstärker (op-amp), eine Logikschaltung usw.) implementiert werden, die so aufgebaut sind, dass sie die entsprechende Operation ohne Ausführung von Software oder Firmware durchführen.
Wie vorstehend erwähnt, können die exemplarischen Prozesse von 8-10 unter Verwendung ausführbarer Anweisungen (z.B. computer- und/oder maschinenlesbare Anweisungen) implementiert werden, die auf einem nicht-flüchtigen Computer und/oder maschinenlesbaren Medium gespeichert sind, wie beispielsweise einer Festplatte, einem Flash-Speicher, einem Read-Only-Speicher, einer Compact-Disk, einer Digital Versatile Disk, einem Cache, einem Direktzugriffsspeicher und/oder jeder anderen Speichervorrichtung oder Speicherplatte, auf der Informationen für eine beliebige Dauer gespeichert sind (z.B, für längere Zeiträume, dauerhaft, für kurze Zeiträume, für die Zwischenspeicherung und/oder für das Caching der Informationen). Wie hier verwendet, wird der Begriff nicht-flüchtiges, computerlesbares Medium ausdrücklich definiert, um jede Art von computerlesbarer Speichervorrichtung und/oder Speicherplatte zu erfassen und Ausbreitungssignale und Übertragungsmedien auszuschließen.
„Einschließlich“ und „umfassend“ (und alle Formen und Zeitformen davon) werden hier als offene Begriffe verwendet. Wenn also ein Anspruch jedwede Form von „beinhaltet“ oder „enthält“ (z.B. umfassend, beinhaltet, einschließlich, enthalten, aufweisen, etc.) als Präambel oder innerhalb eines Anspruchs jeglicher Art verwendet, ist zu verstehen, dass zusätzliche Elemente, Begriffe usw. vorhanden sein können, ohne dass sie aus dem Anwendungsbereich des entsprechenden Anspruchs oder dem entsprechenden Verweis fallen. Wie hier verwendet, wenn der Ausdruck „mindestens“ als Übergangsbegriff in z.B. einer Präambel eines Anspruchs verwendet wird, ist er offen und endet auf die gleiche Weise wie der Begriff „umfassend“ und „einschließend“ offen ist. Der Begriff „und/oder“, wenn er beispielsweise in einer Form wie A, B und/oder C verwendet wird, bezieht sich auf jede Kombination oder Teilmenge von A, B, C wie (1) A allein, (2) B allein, (3) C allein, (4) A mit B, (5) A mit C, (6) B mit C und (7) A mit B und C.
8 ist ein Flussdiagramm, das exemplarisch für maschinenlesbare Anweisungen 800 steht, die ausgeführt werden können, um das exemplarische Pipeline-Optimierungssystem 100 von 1 und/oder den exemplarischen SIPP-Beschleuniger 700 von 7 zu implementieren, um eine Bildmerkmalabgleichsoperation zu beschleunigen. Die exemplarischen maschinenlesbaren Anweisungen 800 von 8 beginnen bei Block 802, bei dem der exemplarische SIPP-Beschleuniger 700 einen Pixelwert eines ersten Pixels in einem ersten Bild und Pixelwerte eines zweiten Pixels in einem zweiten Bild erhält. So kann beispielsweise der Zensus-Transformationshandler 702 von 7 einen Pixelintensitätswert des linken Pixels 124 des linken Bildes 118 und Pixelintensitätswerte von Pixeln des Pixel-Kernels 128 des rechten Bildes 120 von 1 erhalten.
Bei Block 804 führt der exemplarische SIPP-Beschleuniger 700 eine Zensus-Transformation der Pixelwerte durch, um einen ersten Deskriptor und einen zweiten Deskriptor zu erzeugen. So kann beispielsweise der Zensus-Transformationshandler 702 Pixelwerte benachbarter Pixel (z.B. innerhalb eines Pixel-Kernels) des linken Pixels 124 mit einem Pixelwert des linken Pixels 124 vergleichen, um den linken Deskriptor 230 von 2B zu erzeugen. In anderen Beispielen vergleicht der Zensus-Transformationshandler 702 Pixelwerte des Pixel-Kernels 128 aus 1 mit einem Vergleichswert, wie beispielsweise einem Pixelwert des Zentralpixels 126, einem Mittelwert der Pixelwerte des Pixel-Kernels 128, einem Schwellenwert usw., um den Pre-Mask-Bitdeskriptor 222 aus 2A zu erzeugen. In solchen Beispielen wendet der Zensus-Transformationshandler 702 die Verkettungsmaske 228 von 2A und die Verkettungslogik 224 von 2A auf den Pre-Mask-Bitdeskriptor 222 an, um den Post-Mask-Bitdeskriptor 202 von 2A zu erzeugen. Der exemplarische Post-Mask-Bitdeskriptor 202 kann ein dem Pixel-Kernel 128 zugeordnetes Bildmerkmal charakterisieren, basierend auf einem Vergleich der Pixelintensitätswerte der im Pixel-Kernel 128 enthaltenen Pixel mit einem Vergleichswert. So kann beispielsweise der Post-Mask-Bitdeskriptor 202 einem rechten Deskriptor entsprechen, der einem Pixel des rechten Bildes 120 zugeordnet ist.
Bei Block 806 speichert der exemplarische SIPP-Beschleuniger 700 den zweiten Deskriptor im Deskriptorpuffer. So kann beispielsweise der Deskriptormanager 704 den richtigen Deskriptor 202 im Ringspeicher 232 von 2B speichern. Der exemplarische Deskriptormanager 704 kann 176 der rechten Deskriptoren 202 aus dem exemplarischen Ringspeicher 232 lesen und ausgeben.
Bei Block 808 wählt der exemplarische SIPP-Beschleuniger 700 eine Teilmenge der gespeicherten Deskriptoren aus dem Deskriptorpuffer aus. So kann beispielsweise der Deskriptormanager 704 96 der 176 richtigen Deskriptoren 202 basierend auf der Befehlslogik auswählen.
Bei Block 810 berechnet der exemplarische SIPP-Beschleuniger 700 Disparitäten, die dem ersten Deskriptor und der Teilmenge der gespeicherten Deskriptoren zugeordnet sind. So kann beispielsweise der Kostenberechnungsmanager 706 96 Disparitäten berechnen, die dem linken Deskriptor 230 und den entsprechenden der 96 ausgewählten rechten Deskriptoren 202 zugeordnet sind.
Bei Block 812 berechnet der exemplarische SIPP-Beschleuniger 700 die Aggregationskosten, die dem/den Ausbreitungsweg(en) von den zweiten Pixeln zum ersten Pixel zugeordnet sind. So kann beispielsweise der Aggregationsgenerator 708 erste Aggregationskosten berechnen, die einem Ausbreitungsweg von links nach rechts zugeordnet sind, zweite Aggregationskosten, die einem Ausbreitungsweg von rechts nach links zugeordnet sind, und dritte Aggregationskosten, die einem Ausbreitungsweg von oben nach unten zugeordnet sind.
Bei Block 814 bestimmt der exemplarische SIPP-Beschleuniger 700 minimale Aggregationskosten. So bestimmt beispielsweise der Aggregationsgenerator 708 aus den ersten, zweiten und dritten Aggregationskosten einen minimalen Aggregationsaufwand. So bestimmt beispielsweise der Aggregationsgenerator 708 die minimalen Aggregationskosten für jede Disparität (z.B. für jede der 96 Disparitäten 238), die für den exemplarischen linken Pixel 124 berechnet wurden.
Bei Block 816 passt der exemplarische SIPP-Beschleuniger 700 einen der zweiten Pixel an das erste Pixel an, basierend auf den minimalen Aggregationskosten. So erzeugt beispielsweise der Aggregationsgenerator 708 eine Disparitätskarte (z.B. einen zweidimensionalen Vektor mit 64 oder 96 Abgleichkosten pro Pixel) basierend auf den minimalen Aggregationskosten für jede der 96 Disparitäten. In solchen Beispielen bestimmt der Aggregationsgenerator 708 basierend auf der Disparitätskarte eine minimale Disparität. Der exemplarische Aggregationsgenerator 708 kann ein passendes Pixel im rechten Bild 120 zum linken Beispiel Pixel 124 basierend auf der minimalen Disparität identifizieren. So kann beispielsweise der Aggregationsgenerator 708 bestimmen, dass eines der im Pixel-Kernel 128 von 1 enthaltenen Pixel eine erste Position im rechten Bild 120 aufweist, die im Wesentlichen mit einer zweiten Position des linken Pixels 124 im linken Bild 118 basierend auf den minimalen Aggregationskosten übereinstimmt (z.B. Übereinstimmung innerhalb einer Toleranzschwelle). Als Reaktion auf die Übereinstimmung schließen die exemplarisch maschinenlesbaren Anweisungen 800 aus 8. So kann beispielsweise der exemplarische SIPP-Beschleuniger 700 bestimmen, dass ein anderes Pixel im linken Bild 118 mit einem der Pixel im rechten Bild 120 von 1 übereinstimmt.
9 stellt den exemplarischen Quellcode 900 dar, der exemplarisch für computerlesbare Anweisungen steht, die ausgeführt werden können, um das exemplarische Pipeline-Optimierungssystem 100 von 1 und/oder den exemplarischen SIPP-Beschleuniger 700 von 7 zu implementieren, um eine Disparität mit minimalen Kosten zu bestimmen, die mit einem ersten Pixel in einem ersten Bild und einem zweiten Pixel in einem zweiten Bild verbunden ist. Der exemplarische Quellcode 900 von 9 kann von mindestens einer der SGBM-Aggregations-Engines 112 von 1, den exemplarischen Kostenaggregationszellen 252 von 2E, den exemplarischen SGBM-Aggregationszellen 502, 530, 540 von 5 oder dem Aggregationsgenerator 708 von 7 implementiert und/oder anderweitig ausgeführt werden.
So führt beispielsweise der Aggregationsgenerator 708 den Quellcode 900 von 9 für jedes Pixel in einer Zeile eines Eingangsbildes aus (z.B. das linke Bild 118 von 1, das rechte Bild 120 von 1, etc.). Der exemplarische Quellcode 900 von 9 verarbeitet Bilddaten aus einem Eingabekostenpuffer (ICB) und einem Teilkostenpuffer (PCB). So kann beispielsweise der ICB dem Eingabekostenpuffer 250 von 2E entsprechen. Der exemplarische PCB kann dem exemplarischen Aggregationskostenregister 552 von 5 entsprechen.
Im exemplarischen Quellcode 900 von 9 bestimmt der exemplarische Aggregationsgenerator 708 für jedes Pixel in der Zeile aktualisierten Pfadkosten (PathCostNew[n][x]) für drei Pfade, wobei die drei Pfade von links nach rechts entsprechend n=0, von oben nach unten entsprechend n=1 und von rechts nach links entsprechend n=2 sind. Im exemplarischen Quellcode 900 von 9 ist PathCostNew ein 3D-Array, das nach Pfad (n), Pixel (x) und Disparität (d) indiziert ist (z.B. PathCostNew[0][x][d]). Der exemplarische Aggregationsgenerator 708 berechnet für jeden Pfad eine Summe zu aggregierten Kosten (AGV). Im exemplarischen Quellcode 900 von 9 ist AGV ein 2D-Array von aggregierten Kosten, indiziert nach Pixel und Disparität. Als Reaktion auf die Berechnung der Gesamtkosten für jede Disparität bestimmt und/oder identifiziert der exemplarische Aggregationsgenerator 708 die Disparität mit einem minimalen Kostenwert und speichert die Pfadkosten für jeden der Pfade in einem Zwischenspeicher oder Speicher.
10 stellt den exemplarischen Quellcode 1000 dar, der exemplarisch für computerlesbare Anweisungen steht, die ausgeführt werden können, um das exemplarische Pipeline-Optimierungssystem 100 von 1 und/oder den exemplarischen SIPP-Beschleuniger 700 von 7 zu implementieren, um die mit einem Ausbreitungsweg verbundenen Kosten zu bestimmen. Der exemplarische Quellcode 1000 von 10 kann von mindestens einer der SGBM-Aggregations-Engines 112 von 1, der exemplarischen Kostenaggregationszellen 252 von 2E, der exemplarischen SGBM-Aggregationszellen 502, 530, 540 von 5 oder dem Aggregationsgenerator 708 von 7 implementiert und/oder anderweitig ausgeführt werden.
So bestimmt beispielsweise der Aggregationsgenerator 708 die minimalen Kosten (MIN_2) eines unmittelbaren oder aktuellen Pixels (x) über alle mit dem aktuellen Pixel verbundenen Disparitäten. So kann beispielsweise der Aggregationsgenerator 708 einen minimalen Disparitätswert der 96 Disparitäten bestimmen, die für das linke Pixel 124 von 1 berechnet und/oder anderweitig zugeordnet sind. Der exemplarische Aggregationsgenerator 708 bildet eine Differenz (intensityDiff) zwischen Intensitätswerten des aktuellen Pixels und eines vorherigen Pixels auf einen ersten Strafenwert (P1) und einen zweiten Strafenwert (P2) ab. Der exemplarische Aggregationsgenerator 708 ermittelt die neuen Kosten für jede Disparität. Der exemplarische Aggregationsgenerator 708 bestimmt die neuen Kosten, indem er bestimmt (z.B. iterativ bestimmt), ob eine ausgewählte Disparität plus der erste Strafwert kleiner als die aktuellen Kosten ist. Als Reaktion auf die Bestimmung, dass die ausgewählte Disparität plus der erste Strafwert kleiner als die aktuellen Kosten ist, werden die aktuellen Kosten auf die ausgewählte Disparität plus der erste Strafwert gesetzt.
11 stellt ein exemplarisches Zeitdiagramm 1100 dar, das einer exemplarischen Datenpfad-Wellenform der exemplarischen SGBM-Aggregations-Engine 112 von 1 und/oder des exemplarischen Aggregationsgenerators 708 von 7 entspricht. Das exemplarische Zeitdiagramm 1100 stellt Operationen dar, die dem ersten exemplarischen Pfad 1102 zugeordnet sind, der einem Links-Rechts-Pfad entspricht, und dem zweiten exemplarischen Pfad 1104, der einem Top-Down-Pfad oder einem Top-Bottom-Pfad entspricht.
Im exemplarischen Zeitdiagramm 1100 von 11 erreicht die exemplarische SGBM-Aggregations-Engine 112 und/oder der exemplarische Aggregationsgenerator 708 einen 1-Pfad-Kostensatz (z.B. ein Satz von 64 aggregierten Kosten pro Pfad, ein Satz von 96 aggregierten Kosten pro Pfad, etc.) pro 2-Taktzyklus-Durchsatz. So kann beispielsweise die SGBM-Aggregations-Engine 112 alle 2 Taktzyklen 96 Disparitäten verarbeiten, die einem Pixel für einen bestimmten Aggregationspfad zugeordnet sind. So erhält beispielsweise die SGBM-Aggregations-Engine 112 im ersten Weg 1102 während eines ersten Taktzyklus (CYCLE 0) einen ersten Satz von Abgleichkosten (Abgleichkosten K = Cost 0, K) (z.B. 96 Kosten, die durch die exemplarische Kostenabgleich- Engine 108 aus 1 bestimmt werden) eines ersten Pixels, eines ersten Pixelintensitätswertes (Y0) des ersten Pixels und eines Bypasswertes von 1. Der Bypasswert wird im ersten Taktzyklus gesetzt, da bei einer Bewegung von links nach rechts das oberste Pixel keine zuvor aggregierten Daten aufweist. Während eines zweiten Taktzyklus (CYCLE1) erhält die SGBM-Aggregations-Engine 112 einen zweiten Satz von Abgleichkosten (Abgleichkosten K = Cost 1) eines zweiten Pixels, eines zweiten Pixelintensitätswertes (Y1) des zweiten Pixels und ein verzögerte Pixelintensitätsregister wird auf den ersten Pixelintensitätswert (Y0) gesetzt, das während des ersten Taktzyklus erhalten wurde. Während eines dritten Taktzyklus (CYCLE 2) bildet die exemplarische SGBM-Aggregations-Engine 112 eine Differenz des ersten Pixelintensitätswertes und des zweiten Pixelintensitätswertes auf einen Strafwert ab (Read Penalty LUT). Während des dritten Taktzyklus berechnet die exemplarische SGBM-Aggregations-Engine 112 einen ersten Pfadkostensatz (Path_cost[n]) von A0 und validiert den ersten Pfadkostensatz. So berechnet beispielsweise die SGBM-Aggregations-Engine 112 während des zweiten Taktzyklus und des dritten Taktzyklus aggregierte Kosten für einen Path-of-Interest für ein Pixel auf der Grundlage der Verarbeitung von 96 mit dem Pixel verbundenen Kosten.
Im exemplarischen Zeitdiagramm 1100 von 11, im zweiten Pfad 1104, während eines ersten Taktzyklus (CYCLE 0), erhält die exemplarische SGBM-Aggregations-Engine 112 erste Gesamtkosten (Previews_Top_Aggr) von TA0 und bestimmt erste minimale Gesamtkosten (Top_Aggr_Min) von min(TA0). Während eines zweiten Taktzyklus (CYCLE 1) bestimmt die exemplarische SGBM-Aggregations-Engine 112 einen ersten Strafwert (p1/p2 LUT) von LUT_0. Während eines dritten Taktzyklus (Zyklus 2) erhält die exemplarische SGBM-Aggregations-Engine 112 einen zweiten aggregierten Wert von TA1 und bestimmt einen zweiten minimalen aggregierten Wert von min(TA1). Während des dritten Taktzyklus bestimmt die exemplarische SGBM-Aggregations-Engine 112 erste Pfadkosten von A0 und schreibt die Pfadkosten in einen Ausgabepuffer. Die exemplarische SGBM-Aggregations-Engine 112 verarbeitet (z.B. iterativ) die mit Pixeln eines Eingabebildes verbundenen Gesamtkosten, um einen Durchsatz von 2 Taktzyklen zu 1 Pfadkostensatz zu erreichen (z.B. ein Satz von 64 aggregierten Kosten für einen Pfad, ein Satz von 96 aggregierten Kosten für einen Pfad, usw.).
12 ist ein Blockdiagramm einer exemplarischen Prozessorplattform 1200, die strukturiert ist, um die Anweisungen der 8-10 auszuführen, um den exemplarischen SIPP-Beschleuniger 700 von 7 zu implementieren. Die Prozessorplattform 1200 kann beispielsweise ein Server, ein Personal-Computer, eine Arbeitsstation, eine selbstlernende Maschine (z.B. ein neuronales Netzwerk), eine mobile Vorrichtung (z.B. ein Mobiltelefon, ein Smartphone, ein Tablett wie ein iPad™), ein persönlicher digitaler Assistent (PDA), ein Internetgerät, ein DVD-Player, ein CD-Player, ein digitaler Videorekorder, ein Blu-ray-Player, eine Spielkonsole, ein persönlicher Videorekorder, eine Set-Top-Box, ein Headset oder eine andere tragbare Vorrichtung oder eine andere Art von Computergerät sein.
Die Prozessorplattform 1200 des veranschaulichten Beispiels beinhaltet einen Prozessor 1212. Der Prozessor 1212 des veranschaulichten Beispiels ist Hardware. So kann beispielsweise der Prozessor 1212 durch eine oder mehrere integrierte Schaltungen, Logikschaltungen, Mikroprozessoren, GPUs, DSPs oder Controller einer beliebigen Familie oder eines beliebigen Herstellers implementiert werden. Der Hardware-Prozessor kann eine halbleiterbasierte (z.B. siliziumbasierte) Vorrichtung sein. In diesem Beispiel implementiert der Prozessor 1212 den exemplarischen SIPP-Beschleuniger 700, den exemplarischen Zensus-Transformationshandler 702, den exemplarischen Deskriptormanager 704, den exemplarischen Kostenrechnungsmanager 706, den exemplarischen Aggregationsgenerator 708.
Der Prozessor 1212 des veranschaulichten Beispiels beinhaltet einen lokalen Speicher 1213 (z.B. einen Cache). Der Prozessor 1212 des veranschaulichten Beispiels ist in Verbindung mit einem Hauptspeicher mit einem flüchtigen Speicher 1214 und einem nicht-flüchtigen Speicher 1216 über einen Bus 1218. Der flüchtige Speicher 1214 kann durch Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS® Dynamic Random Access Memory (RDRAM®) und/oder jede andere Art von Direktzugriffsspeichervorrichtung implementiert werden. Der nicht-flüchtige Speicher 1216 kann durch Flash-Speicher und/oder jede andere gewünschte Art von Speichervorrichtung implementiert werden. Der Zugriff auf den Hauptspeicher 1214, 1216 wird durch eine Speichersteuerung gesteuert.
Die Prozessorplattform 1200 des veranschaulichten Beispiels beinhaltet auch eine Schnittstellenschaltung 1220. Die Schnittstellenschaltung 1220 kann durch jede Art von Schnittstellenstandard implementiert werden, wie beispielsweise eine Ethernet-Schnittstelle, einen universellen seriellen Bus (USB), eine Bluetooth®-Schnittstelle, eine Nahfeldkommunikationsschnittstelle (NFC) und/oder eine PCI-Express-Schnittstelle.
Im dargestellten Beispiel sind eine oder mehrere Eingabevorrichtungen 1222 an die Schnittstellenschaltung 1220 angeschlossen. Die Eingabevorrichtung(en) 1222 ermöglichen es einem Nutzer, Daten und/oder Befehle in den Prozessor 1212 einzugeben. Die Eingabevorrichtung(en) 1222 können beispielsweise durch einen Audiosensor, ein Mikrofon, eine Kamera (Standbild oder Video), eine Tastatur, eine Taste, eine Maus, einen Touchscreen, ein Track-Pad, einen Trackball, eine Isopunktvorrichtung und/oder ein Spracherkennungssystem implementiert werden.
Eine oder mehrere Ausgabevorrichtungen 1224 sind ebenfalls an die Schnittstellenschaltung 1220 des dargestellten Beispiels angeschlossen. Die Ausgabevorrichtungen 1224 können beispielsweise durch Anzeigevorrichtungen (z.B. eine Leuchtdiode (LED), eine organische Leuchtdiode (OLED), eine Flüssigkristallanzeige (LCD), eine Kathodenstrahlröhrenanzeige (CRT), eine In-Place-Switching (IPS)-Anzeige, einen Touchscreen usw.), eine taktile Ausgabevorrichtung, einen Drucker und/oder Lautsprecher realisiert werden. Die Schnittstellenschaltung 1220 des veranschaulichten Beispiels beinhaltet somit typischerweise eine Grafiktreiberkarte, einen Grafiktreiberchip und/oder einen Grafiktreiberprozessor.
Die Schnittstellenschaltung 1220 des veranschaulichten Beispiels beinhaltet auch eine Kommunikationsvorrichtung wie einen Sender, einen Empfänger, einen Sender-Empfänger, ein Modem, ein Kabelmodem, einen drahtlosen Zugangspunkt und/oder eine Netzwerkschnittstelle, um den Datenaustausch mit externen Engines (z.B. Rechenvorrichtungen jeglicher Art) über ein Netzwerk 1226 zu erleichtern. Die Kommunikation kann beispielsweise über eine Ethernet-Verbindung, eine Digitale Teilnehmeranschlussleitung (DSL), eine Telefonleitungsverbindung, ein Koaxialkabelsystem, ein Satellitensystem, ein drahtloses Ortsystem, ein Mobilfunksystem usw. erfolgen.
Die Prozessorplattform 1200 des veranschaulichten Beispiels beinhaltet auch ein oder mehrere Massenspeichergeräte 1228 zum Speichern von Software und/oder Daten. Beispiele für solche Massenspeichergeräte 1228 sind Diskettenlaufwerke, Festplatten, Compact-Disk-Laufwerke, Blu-ray-Laufwerke, redundante Anordnung von unabhängigen Festplatten (RAID-Systeme) und Digital Versatile Disk (DVD-Laufwerke).
Die maschinenausführbaren Anweisungen 1232 der 8-10 können in der Massenspeichervorrichtung 1228, im flüchtigen Speicher 1214, im nicht-flüchtigen Speicher 1216 und/oder auf einem entfernbaren, nicht-flüchtigen, computerlesbaren Speichermedium wie einer CD oder DVD gespeichert werden.
Aus diesem Grund ist es zu beachten, dass exemplarische Verfahren, Vorrichtungen und Fertigungsgegenstände offengelegt wurden, die die Ausführung von Pipelines optimieren. Die hier offengelegten Beispiele führen eine Stereoabgleich unter Verwendung eines Pipeline-Optimierungssystems durch, das eine oder mehrere Pipelinekomponenten beinhaltet, um die Bestimmung von Disparitäten und/oder Pfadkosten zu erleichtern, die mit übereinstimmenden Pixeln in Stereobildern verbunden sind. Die hier offengelegten Beispiele ermöglichen eine Architektur, die Zensus-Transformationsfunktionen von 1 Pixel pro 1 Taktzyklusdurchsatz verarbeitet und/oder anderweitig erleichtert. Die hier offengelegten Beispiele reduzieren den Energieverbrauch von Ressourcen durch die Reduzierung von Datenbewegungen unter Verwendung eines Ringspeicherschemas in einem oder mehreren offenbarten Puffern oder Speicherkonstrukten. Beispiele, die hier offengelegt werden, erzeugen eine Stereo-Disparitätskarte, die durch Abgleich entsprechender Punkte im Stereopaar unter Verwendung einer Architektur konstruiert wird, die Disparitätsberechnungen beschleunigt, die mit Pixeln in Stereobildern verbunden sind.
Beispiel 1 beinhaltet eine Vorrichtung zum Durchführen einer Stereoabgleich, wobei die Vorrichtung einen Kostenberechnungsmanager zum Bestimmen eines Wertes, der einem ersten Ort eines ersten Pixels eines ersten Bildes und einem zweiten Ort eines zweiten Pixels eines zweiten Bildes zugeordnet ist, durch Berechnen von Abgleichkosten zwischen dem ersten Ort und dem zweiten Ort und einen Aggregationsgenerator zum Erzeugen einer Disparitätskarte mit dem Wert und zum Bestimmen eines Mindestwertes basierend auf der Disparitätskarte, der einem Unterschied in horizontalen Koordinaten zwischen dem ersten Ort und dem zweiten Ort entspricht, umfasst.
Beispiel 2 beinhaltet die Vorrichtung von Beispiel 1, ferner beinhaltet es einen Zensus-Transformationshandler, um einen Bit-Deskriptor zu erzeugen, der Intensitätswerte eines Satzes von Pixeln eines Pixel-Kernels, der das zweite Pixel beinhaltet, auf eine Bitfolge abbildet.
Beispiel 3 beinhaltet die Vorrichtung von Beispiel 2, worin der Zensus-Transformationshandler die Bitfolge erzeugen soll, indem er die Intensitätswerte des Satzes von Pixeln mit einem Intensitätswert eines Zentralpixels des Pixel-Kernels, einem Mittelwert der Intensitätswerte oder einem Schwellenwert vergleicht.
Beispiel 4 beinhaltet die Vorrichtung von Beispiel 2, wobei der Bitdeskriptor ein Post-Mask-Bitdeskriptor ist, der Zensus-Transformationshandler zum Erzeugen der Bitfolge durch Anwenden einer Verkettungsmaske und eines oder mehrerer Sortierbäume auf einen Pre-Mask-Bitdeskriptor, um den Post-Mask-Bitdeskriptor zu erzeugen.
Beispiel 5 beinhaltet die Vorrichtung von Beispiel 2, wobei der Bitdeskriptor ein erster Bitdeskriptor ist, der Kostenberechnungsmanager zum Bestimmen der Disparität durch Berechnen einer absoluten Differenz zwischen einem ersten Pixelintensitätswert des ersten Pixels und einem zweiten Pixelintensitätswert des zweiten Pixels, Berechnen eines Hamming-Abstands zwischen dem ersten Bitdeskriptor des ersten Pixels und einem zweiten Bitdeskriptor des zweiten Pixels, Berechnen einer Summe aus der absoluten Differenz und des Hamming-Abstands und Bestimmen der Disparität durch Spannen der Summe auf eine ganze Zahl.
Beispiel 6 beinhaltet die Vorrichtung von Beispiel 1, worin die Abgleichkosten erste Abgleichkosten sind, den Kostenberechnungsmanager, um die Abgleichkosten einschließlich der ersten Abgleichkosten unter Verwendung von Barrel-Shiftern neu auszurichten.
Beispiel 7 beinhaltet die Vorrichtung von Beispiel 1, wobei der Aggregationsgenerator erste aggregierte Kostenberechnung durchführen soll, die einem ersten Ausbreitungsweg zugeordnet ist, der einem linken zu rechten Eingabeweg vom zweiten Pixel zum ersten Pixel entspricht, eine zweite aggregierte Kostenberechnung, die einem zweiten Ausbreitungsweg zugeordnet ist, der einem rechten zu linken Eingabeweg vom zweiten Pixel zum ersten Pixel entspricht, Berechnen eines dritten aggregierten Kostenbetrags, der einem dritten Ausbreitungsweg zugeordnet ist, der einem von oben nach unten verlaufenden Eingangspfad vom zweiten Pixel zum ersten Pixel entspricht, und Bestimmen der Disparitätskarte basierend auf dem Berechnen einer Summe aus den ersten aggregierten Kosten, den zweiten aggregierten Kosten und den dritten aggregierten Kosten.
Beispiel 8 beinhaltet ein nicht-flüchtiges, computerlesbares Speichermedium mit Anweisungen, die, wenn sie ausgeführt werden, eine Engine veranlassen, mindestens einen Wert zu bestimmen, der einem ersten Ort eines ersten Pixels eines ersten Bildes und einem zweiten Ort eines zweiten Pixels eines zweiten Bildes zugeordnet ist, indem Abgleichkosten zwischen dem ersten Ort und dem zweiten Ort berechnen, eine Disparitätskarte mit dem Wert erzeugen und einen Mindestwert basierend auf der Disparitätskarte bestimmen, der einem Unterschied in horizontalen Koordinaten zwischen dem ersten Ort und dem zweiten Ort entspricht.
Beispiel 9 beinhaltet das nicht-flüchtige, computerlesbare Speichermedium von Beispiel 8, ferner Anweisungen, die, wenn sie ausgeführt werden, bewirken, dass die Engine mindestens einen Bit-Deskriptor erzeugt, der Intensitätswerte eines Satzes von Pixeln eines Pixel-Kernels, der das zweite Pixel beinhaltet, auf eine Bitfolge abbildet.
Beispiel 10 beinhaltet das nicht-flüchtige, computerlesbare Speichermedium von Beispiel 9, ferner Anweisungen, die, wenn sie ausgeführt werden, die Engine veranlassen, zumindest die Bitfolge zu erzeugen, indem sie die Intensitätswerte der Pixelmenge mit einem Intensitätswert eines Zentralpixels des Pixel-Kernels, einem Mittelwert der Intensitätswerte oder einem Schwellenwert vergleichen.
Beispiel 11 beinhaltet das nicht-flüchtige, computerlesbare Speichermedium von Beispiel 9, wobei der Bit-Deskriptor ein Post-Mask-Bitdeskriptor ist, ferner Anweisungen beinhaltend, die, wenn sie ausgeführt werden, die Engine veranlassen, zumindest die Bitfolge durch Anwenden einer Verkettungsmaske und eines oder mehrerer Sortierbäume auf einen Pre-Mask-Bitdeskriptor zu erzeugen, um den Post-Mask-Bitdeskriptor zu erzeugen.
Beispiel 12 beinhaltet das nicht-flüchtige, computerlesbare Speichermedium von Beispiel 9, wobei der Bit-Deskriptor ein erster Bit-Deskriptor ist, ferner Anweisungen beinhaltend, die, wenn sie ausgeführt werden, die Engine veranlassen, zumindest eine absolute Differenz zwischen einem ersten Pixelintensitätswert des ersten Pixels und einem zweiten Pixelintensitätswert des zweiten Pixels zu berechnen, einen Hamming-Abstand zwischen dem ersten Bit-Deskriptor des ersten Pixels und einem zweiten Bit-Deskriptor des zweiten Pixels zu berechnen, eine Summe aus der absoluten Differenz und dem Hamming-Abstand zu berechnen und die Disparität durch Spannen der Summe auf eine ganze Zahl zu bestimmen.
Beispiel 13 beinhaltet das nicht-flüchtige, computerlesbare Speichermedium von Beispiel 8, worin die Abgleichkosten erste Abgleichkosten sind, ferner einschließlich Anweisungen, die, wenn sie ausgeführt werden, die Engine veranlassen, zumindest die Abgleichkosten einschließlich der ersten Abgleichkosten unter Verwendung von Barrel-Shiftern neu auszurichten.
Beispiel 14 beinhaltet das nicht-flüchtige, computerlesbare Speichermedium von Beispiel 1, ferner Anweisungen, die, wenn sie ausgeführt werden, bewirken, dass die Engine zumindest erste aggregierte Kosten berechnet, die einem ersten Ausbreitungsweg zugeordnet ist, der einem von links nach rechts verlaufenden Eingabepfad vom zweiten Pixel zum ersten Pixel entspricht, Berechnen von zweiten aggregierten Kosten, die einem zweiten Ausbreitungsweg zugeordnet sind, der einem rechts-nach-links-Eingabepfad vom zweiten Pixel zum ersten Pixel entspricht, Berechnen von dritten aggregierten Kosten, die einem dritten Ausbreitungsweg zugeordnet sind, der einem oben-nach-unten-Eingabepfad vom zweiten Pixel zum ersten Pixel entspricht, und Bestimmen der Disparitätskarte basierend auf dem Berechnen einer Summe aus den ersten aggregierten Kosten, den zweiten aggregierten Kosten und den dritten aggregierten Kosten.
Beispiel 15 beinhaltet ein Verfahren zum Durchführen eines Stereoabgleichs, wobei das Verfahren das Bestimmen eines Wertes, der einem ersten Ort eines ersten Pixels eines ersten Bildes und einem zweiten Ort eines zweiten Pixels eines zweiten Bildes zugeordnet ist, durch Berechnen von Abgleichkosten zwischen dem ersten Ort und dem zweiten Ort, das Erzeugen einer Disparitätskarte mit dem Wert und das Bestimmen eines Mindestwertes basierend auf der Disparitätskarte, der einem Unterschied in den horizontalen Koordinaten zwischen dem ersten Ort und dem zweiten Ort entspricht, umfasst.
Beispiel 16 beinhaltet das Verfahren von Beispiel 15, ferner das Erzeugen eines Bitdeskriptors, der Intensitätswerte eines Satzes von Pixeln eines Pixel-Kernels, der das zweite Pixel beinhaltet, auf eine Bitfolge abbildet.
Beispiel 17 beinhaltet das Verfahren von Beispiel 16, wobei das Erzeugen der Bitfolge das Vergleichen der Intensitätswerte des Satzes von Pixeln mit einem Intensitätswert eines Zentralpixels des Pixel-Kernels, einem Mittelwert der Intensitätswerte oder einem Schwellenwert beinhaltet.
Beispiel 18 beinhaltet das Verfahren von Beispiel 16, wobei der Bitdeskriptor ein Post-Mask-Bitdeskriptor ist und das Erzeugen der Bitfolge durch Anwenden einer Verkettungsmaske und eines oder mehrerer Sortierbäume auf einen Pre-Mask-Bitdeskriptor, um den Post-Mask-Bitdeskriptor zu erzeugen.
Beispiel 19 beinhaltet das Verfahren von Beispiel 16, wobei der Bitdeskriptor ein erster Bitdeskriptor ist und das Bestimmen der Disparität durch Berechnen einer absoluten Differenz zwischen einem ersten Pixelintensitätswert des ersten Pixels und einem zweiten Pixelintensitätswert des zweiten Pixels, das Berechnen eines Hamming-Abstands zwischen dem ersten Bitdeskriptor des ersten Pixels und einem zweiten Bitdeskriptor des zweiten Pixels, das Berechnen einer Summe aus der absoluten Differenz und des Hamming-Abstands und das Bestimmen der Disparität durch Spannen der Summe auf eine ganze Zahl.
Beispiel 20 beinhaltet das Verfahren des Beispiels 15, worin die Abgleichkosten erste Abgleichkosten sind, ferner einschließlich der Neuausrichtung der Abgleichkosten einschließlich der ersten Abgleichkosten unter Verwendung von Barrel-Shiftern.
Beispiel 21 beinhaltet das Verfahren von Beispiel 15, ferner das Berechnen von ersten aggregierten Kosten, die einem ersten Ausbreitungsweg zugeordnet sind, der einem linken zu rechten Eingabepfad vom zweiten Pixel zum ersten Pixel entspricht, das Berechnen von zweiten aggregierten Kosten, die einem zweiten Ausbreitungsweg zugeordnet sind, der einem rechten zu linken Eingabepfad vom zweiten Pixel zum ersten Pixel entspricht, Berechnen eines dritten aggregierten Kostenbetrags, der einem dritten Ausbreitungsweg zugeordnet ist, der einem von oben nach unten verlaufenden Eingabepfad vom zweiten Pixel zum ersten Pixel entspricht, und Bestimmen der Disparitätskarte basierend auf dem Berechnen einer Summe aus den ersten aggregierten Kosten, den zweiten aggregierten Kosten und den dritten aggregierten Kosten.
Beispiel 22 beinhaltet eine Vorrichtung zum Durchführen eines Stereoabgleichs, wobei die Vorrichtung ein erstes Mittel zum Bestimmen eines Wertes, der einem ersten Ort eines ersten Pixels eines ersten Bildes und einem zweiten Ort eines zweiten Pixels eines zweiten Bildes zugeordnet ist, durch Berechnen von Abgleichkosten zwischen dem ersten Ort und dem zweiten Ort, und ein zweites Mittel zum Erzeugen einer Disparitätskarte, die den Wert beinhaltet, und zum Bestimmen eines Mindestwertes basierend auf der Disparitätskarte, der einem Unterschied in horizontalen Koordinaten zwischen dem ersten Ort und dem zweiten Ort entspricht.
Beispiel 23 beinhaltet die Vorrichtung von Beispiel 22, ferner beinhaltet es ein drittes Mittel zum Erzeugen eines Bit-Deskriptors, der Intensitätswerte eines Satzes von Pixeln eines Pixel-Kernels, der das zweite Pixel beinhaltet, auf eine Bitfolge abbildet.
Beispiel 24 beinhaltet die Vorrichtung von Beispiel 23, worin das dritte Mittel zum Erzeugen der Bitfolge durch Vergleichen der Intensitätswerte des Satzes von Pixeln mit einem Intensitätswert eines Zentralpixels des Pixel-Kernels, einem Mittelwert der Intensitätswerte oder einem Schwellenwert besteht.
Beispiel 25 beinhaltet die Vorrichtung von Beispiel 23, wobei der Bitdeskriptor ein Post-Maske-Bitdeskriptor ist, das dritte Mittel zum Erzeugen der Bitfolge durch Anwenden einer Verkettungsmaske und eines oder mehrerer Sortierbäume auf einen Pre-Maske-Bitdeskriptor, um den Post-Maske-Bitdeskriptor zu erzeugen.
Beispiel 26 beinhaltet die Vorrichtung von Beispiel 23, wobei der Bitdeskriptor ein erster Bitdeskriptor ist, das erste Mittel zum Bestimmen der Disparität durch Berechnen einer absoluten Differenz zwischen einem ersten Pixelintensitätswert des ersten Pixels und einem zweiten Pixelintensitätswert des zweiten Pixels, Berechnen eines Hamming-Abstandes zwischen dem ersten Bitdeskriptor des ersten Pixels und einem zweiten Bitdeskriptor des zweiten Pixels, Berechnen einer Summe aus der absoluten Differenz und dem Hamming-Abstand und Bestimmen der Disparität durch Spannen der Summe auf eine ganze Zahl.
Beispiel 27 beinhaltet die Vorrichtung von Beispiel 22, worin die Abgleichkosten erste Abgleichkosten sind, das erste Mittel zur Neuausrichtungvon Abgleichkosten, einschließlich der ersten Abgleichkosten unter Verwendung von Barrel-Shiftern.
Beispiel 28 beinhaltet die Vorrichtung von Beispiel 22, wobei das zweite Mittel zum Berechnen von ersten aggregierten Kosten, die einem ersten Ausbreitungsweg zugeordnet sind, der einem linken zu rechten Eingabepfad vom zweiten Pixel zum ersten Pixel entspricht, und zum Berechnen von zweiten aggregierten Kosten, die einem zweiten Ausbreitungsweg zugeordnet sind, der einem rechten zu linken Eingabepfad vom zweiten Pixel zum ersten Pixel entspricht, Berechnen eines dritten aggregierten Kostenbetrags, der einem dritten Ausbreitungsweg zugeordnet ist, der einem von oben nach unten verlaufenden Eingangspfad vom zweiten Pixel zum ersten Pixel entspricht und Bestimmen der Disparitätskarte basierend auf dem Berechnen einer Summe aus den ersten aggregierten Kosten, den zweiten aggregierten Kosten und den dritten aggregierten Kosten.
Die hier offengelegten Beispiele können sich auf Internet-of-Things (I-oT)-Netze beziehen, die über Links zu den jeweiligen Gateways gekoppelt sind. Internet-of-Things (IoT) ist ein Konzept, bei dem eine große Anzahl von Computergeräten miteinander und mit dem Internet verbunden sind, um Funktionalität und Datenerfassung auf sehr niedrigem Niveau zu ermöglichen. So kann eine IoT-Vorrichtung, wie hierin verwendet, eine halbautonome Vorrichtung beinhalten, die eine Funktion erfüllt, wie z.B. das Erfassen oder Steuern, unter anderem in Verbindung mit anderen IoT-Vorrichtungen und einem breiteren Netzwerk, wie z.B. dem Internet.
Häufig sind IoT-Geräte in Bezug auf Speicher, Größe oder Funktionalität begrenzt, so dass größere Mengen zu ähnlichen Kosten bereitgestellt werden können wie kleinere Mengen größerer Geräte. Ein IoT-Gerät kann jedoch ein Smartphone, ein Laptop, ein Tablett, ein PC oder ein anderes größeres Gerät sein. Darüber hinaus kann ein IoT-Gerät ein virtuelles Gerät sein, wie beispielsweise eine Anwendung auf einem Smartphone oder einem anderen Computergerät. IoT-Geräte können IoT-Gateways beinhalten, die zur Kopplung von IoT-Geräten an andere IoT-Geräte und an Cloud-Anwendungen, zur Datenspeicherung, Prozesskontrolle und dergleichen verwendet werden.
Netzwerke von IoT-Geräten können kommerzielle und haustechnische Geräte beinhalten, wie z.B. Wasserverteilungssysteme, elektronische Energieverteilungssysteme, Pipelinesteuerungssysteme, Anlagensteuerungssysteme, Lichtschalter, Thermostate, Schlösser, Kameras, Alarme, Bewegungssensoren und dergleichen. Die IoT-Geräte können über entfernte Computer, Server und andere Systeme zugänglich sein, z. B. zur Steuerung von Systemen oder zum Zugriff auf Daten.
Das zukünftige Wachstum des Internets und ähnlicher Netzwerke kann sehr viele IoT-Geräte betreffen. Dementsprechend werden im Rahmen der hier diskutierten Techniken eine Reihe von Innovationen für eine solche zukünftige Vernetzung der Notwendigkeit Rechnung tragen, dass alle diese Schichten ungehindert wachsen, verbundene Ressourcen entdecken und zugänglich machen und die Fähigkeit unterstützen, verbundene Ressourcen zu verstecken und zu unterteilen. Es können beliebig viele Netzwerkprotokolle und Kommunikationsstandards verwendet werden, wobei jedes Protokoll und jeder Standard so konzipiert ist, dass er spezifische Ziele erfüllt. Darüber hinaus sind die Protokolle Teil der Struktur zur Unterstützung von Diensten, die für Menschen zugänglich sind und unabhängig von Ort, Zeit und Ort funktionieren. Zu den Innovationen gehören die Bereitstellung von Diensten und der dazugehörigen Infrastruktur, wie Hard- und Software, Sicherheitsverbesserungen und die Bereitstellung von Diensten auf der Grundlage von Quality of Service (QoS)-Bedingungen, die in Service Level- und Service Delivery-Vereinbarungen festgelegt sind.
Backbone-Verbindungen können eine beliebige Anzahl von kabelgebundenen oder drahtlosen Technologien, einschließlich optischer Netzwerke, beinhalten und können Teil eines lokalen Netzwerks (LAN), eines Wide Area Networks (WAN) oder des Internets sein. Darüber hinaus erleichtern solche Kommunikationsverbindungen optische Signalwege sowohl zwischen IoT-Geräten als auch zwischen Gateways, einschließlich der Verwendung von MUX/DeMUXing-Komponenten, die die Verbindung der verschiedenen Geräte erleichtern.
Die Netzwerktopologie kann eine beliebige Anzahl von IoT-Netzwerken beinhalten, wie beispielsweise ein Mesh-Netzwerk, das mit dem Netzwerk über Bluetooth-Low-Energy (BLE)-Verbindungen ausgestattet ist. Andere Arten von IoT-Netzwerken, die vorhanden sein können, beinhalten ein WLAN-Netzwerk (Wireless Local Area Network), das zur Kommunikation mit IoT-Geräten über IEEE 802.11 verwendet wird, (Wi-Fi®)-Verbindungen, ein Mobilfunknetz, das zur Kommunikation mit IoT-Geräten über ein LTE/LTE-A- (4G) oder 5G-Mobilfunknetz verwendet wird, und ein Low-Power-Weitbereichsnetz (LPWA), beispielsweise ein LPWA-Netz, das mit der von der LoRa-Allianz veröffentlichten LoRaWan-Spezifikation kompatibel ist, oder ein IPv6 over Low-Power-Weitbereichsnetz (LPWAN), das mit einer von der Internet Engineering Task Force (IETF) veröffentlichten Spezifikation kompatibel ist. Darüber hinaus können die jeweiligen IoT-Netzwerke mit einem externen Netzbetreiber (z.B. einem Tier-2- oder Tier-3-Provider) über eine beliebige Anzahl von Kommunikationsverbindungen kommunizieren, wie z.B. eine LTE-Mobilfunkverbindung, eine LPWA-Verbindung oder eine Verbindung nach dem IEEE-Standard 802.15.4, wie z.B. Zigbee®. Die jeweiligen IoT-Netzwerke können auch mit der Verwendung einer Vielzahl von Netzwerk- und Internet-Anwendungsprotokollen wie dem Constrained Application Protocol (CoAP) arbeiten. Die jeweiligen IoT-Netzwerke können auch mit Koordinatorgeräten integriert werden, die eine Kette von Gliedern bilden, die einen Cluster-Baum aus verbundenen Geräten und Netzwerken bildet.
Jedes dieser IoT-Netze kann Möglichkeiten für neue technische Merkmale bieten, wie sie hier beschrieben sind. Die verbesserten Technologien und Netze können ein exponentielles Wachstum von Geräten und Netzwerken ermöglichen, einschließlich der Nutzung von IoT-Netzen als Nebelgeräte oder -systeme. Mit zunehmendem Einsatz dieser verbesserten Technologien können die IoT-Netzwerke für Selbstmanagement, funktionale Evolution und Zusammenarbeit entwickelt werden, ohne dass direkte menschliche Eingriffe erforderlich sind. Die verbesserten Technologien können es sogar ermöglichen, dass IoT-Netzwerke ohne zentrale Steuerungssysteme funktionieren. Dementsprechend können die hier beschriebenen verbesserten Technologien zur Automatisierung und Verbesserung von Netzwerkmanagement- und Betriebsfunktionen weit über die derzeitigen Implementierungen hinaus eingesetzt werden.
In einem Beispiel kann die Kommunikation zwischen IoT-Geräten, beispielsweise über die Backbone-Verbindungen, durch ein dezentrales System für Authentifizierung, Autorisierung und Accounting (AAA) geschützt werden. In einem dezentralen AAA-System können verteilte Zahlungs-, Kredit-, Audit-, Autorisierungs- und Authentifizierungssysteme über eine vernetzte heterogene Netzwerkinfrastruktur implementiert werden. Dies ermöglicht es Systemen und Netzwerken, sich in Richtung autonome Operationen zu bewegen. Bei diesen Arten von autonomen Operationen können Engines sogar Verträge über Personalressourcen abschließen und Partnerschaften mit anderen Maschinennetzwerken aushandeln. Dies kann die Erreichung gemeinsamer Ziele und eine ausgewogene Leistungserbringung im Vergleich zu skizzierten, geplanten Service-Level-Vereinbarungen sowie Lösungen ermöglichen, die Zähler, Messungen, Rückverfolgbarkeit und Nachvollziehbarkeit bieten. Die Schaffung neuer Lieferkettenstrukturen und -methoden kann es ermöglichen, eine Vielzahl von Dienstleistungen zu schaffen, wertschöpfend abzubauen und ohne menschliche Beteiligung zu schließen.
Diese IoT-Netze können durch die Integration von Sensortechnologien wie Schall, Licht, elektronischer Verkehr, Gesichts- und Mustererkennung, Geruch, Vibration in die autonomen Organisationen unter den IoT-Geräten weiter verbessert werden. Die Integration sensorischer Systeme kann eine systematische und autonome Kommunikation und Koordination der Leistungserbringung im Hinblick auf vertragliche Serviceziele, Instrumentierung und Quality of Service (QoS) basiertes Schwärmen und Fusion von Ressourcen ermöglichen.
Cluster von IoT-Geräten können für die Kommunikation mit anderen IoT-Geräten sowie mit einem Cloud-Netzwerk ausgestattet werden. Dadurch können die IoT-Geräte ein Ad-hoc-Netzwerk zwischen den Geräten bilden, so dass sie als eine einzige Vorrichtung fungieren können, die als Nebelvorrichtung bezeichnet werden kann.
Ein Cloud-Computing-Netzwerk in Verbindung mit einem Mesh-Netzwerk von IoT-Geräten kann als Nebelgerät am Rande des Cloud Computing-Netzwerks betrieben werden. Das Mesh-Netzwerk von IoT-Geräten kann als Nebel bezeichnet werden, der am Rande der Cloud arbeitet.
Der Nebel kann als ein stark miteinander verbundenes Netzwerk betrachtet werden, bei dem eine Reihe von IoT-Vorrichtungen miteinander kommunizieren, beispielsweise über Funkverbindungen. Als Beispiel kann dieses Verbundnetz durch eine Verbindungsspezifikation erleichtert werden, die von der Open Connectivity Foundation™ (OCF) veröffentlicht wurde. Diese Norm ermöglicht es Geräten, sich gegenseitig zu entdecken und eine Kommunikation für Verbindungen herzustellen. Es können auch andere Verbindungsprotokolle verwendet werden, wie beispielsweise unter anderem das Optimized Link State Routing (OLSR)-Protokoll, der bessere Ansatz für das mobile Ad-hoc-Netzwerkprotokoll (B.A.T.M.A.N.) oder das OMA Lightweight M2M (LWM2M)-Protokoll.
Drei Arten von IoT-Geräten umfassen Gateways, Datenaggregate und Sensoren, wobei jedoch jede Kombination von IoT-Geräten und -Funktionen verwendet werden kann. Die Gateways können Randvorrichtungen sein, die die Kommunikation zwischen der Cloud und dem Nebel ermöglichen und können auch die Backend-Prozess-Funktion für Daten von Sensoren bereitstellen, wie beispielsweise Bewegungsdaten, Strömungsdaten, Temperaturdaten und dergleichen. Die Datenaggregatoren können Daten von beliebig vielen Sensoren sammeln und die Backend-Verarbeitungsfunktion für die Analyse ausführen. Die Ergebnisse, Rohdaten oder beides können über die Gateways an die Cloud weitergeleitet werden. Bei den Sensoren kann es sich beispielsweise um vollwertige IoT-Geräte handeln, die sowohl Daten erfassen als auch verarbeiten können. In einigen Fällen können die Sensoren in ihrer Funktionalität eingeschränkter sein, z.B. beim Sammeln der Daten und beim Verarbeiten der Daten durch die Datenaggregatoren oder Gateways.
Die Kommunikation von jedem IoT-Gerät aus kann über einen geeigneten Weg (z.B. einen bequemsten Weg) zwischen jedem der IoT-Geräte erfolgen, um die Gateways zu erreichen. In diesen Netzen bietet die Anzahl der Verbindungen eine erhebliche Redundanz, so dass die Kommunikation auch bei Verlust einer Reihe von IoT-Geräten aufrechterhalten werden kann. Darüber hinaus kann die Verwendung eines Mesh-Netzwerks die Verwendung von IoT-Geräten ermöglichen, die sehr energiesparend sind oder sich in einer Entfernung von der Infrastruktur befinden, da die Reichweite für die Verbindung zu einem anderen IoT-Gerät viel geringer sein kann als die Reichweite für die Verbindung zu den Gateways.
Der von diesen IoT-Geräten bereitgestellte Nebel kann den Geräten in der Cloud, wie beispielsweise einem Server, als eine einzige Vorrichtung am Rande der Cloud, z.B. eine Nebelvorrichtung, präsentiert werden. In diesem Beispiel können die von der Nebelvorrichtung ausgehenden Warnungen gesendet werden, ohne dass identifiziert werden kann, dass sie von einem bestimmten IoT-Gerät innerhalb des Nebels stammen. Auf diese Weise kann der Nebel als eine verteilte Plattform betrachtet werden, die Rechen- und Speicherressourcen zur Verfügung stellt, um Verarbeitungs- oder datenintensive Aufgaben wie unter anderem Datenanalyse, Datenaggregation und Maschinenlernen durchzuführen.
In einigen Beispielen können die IoT-Geräte mit einem zwingenden Programmierstil konfiguriert werden, wobei z.B. jedes IoT-Gerät eine bestimmte Funktion und bestimmten Kommunikationspartner hat. Die IoT-Vorrichtungen, die die Nebelvorrichtung bilden, können jedoch in einem deklarativen Programmierstil konfiguriert werden, der es den IoT-Vorrichtungen ermöglicht, ihre Operationen und Kommunikationen neu zu konfigurieren, um beispielsweise die benötigten Ressourcen als Reaktion auf Bedingungen, Abfragen und Geräteausfälle zu bestimmen. Eine Abfrage eines Nutzers auf einem Server nach den Vorgängen einer Teilmenge von Geräten, die von den IoT-Geräten überwacht werden, kann beispielsweise dazu führen, dass die Nebelvorrichtung die IoT-Geräte, wie beispielsweise bestimmte Sensoren, auswählt, die zur Beantwortung der Abfrage benötigt werden. Die Daten dieser Sensoren können dann durch eine beliebige Kombination von Sensoren, Datenaggregatoren oder Gateways aggregiert und analysiert werden, bevor sie von der Nebelvorrichtung an den Server gesendet werden, um die Anfrage zu beantworten. In diesem Beispiel können IoT-Geräte im Nebel die verwendeten Sensoren basierend auf der Abfrage auswählen, wie z.B. das Hinzufügen von Daten aus Strömungssensoren oder Temperatursensoren. Wenn einige der IoT-Geräte nicht betriebsbereit sind, können andere IoT-Geräte in der Nebelvorrichtung, falls vorhanden, analoge Daten liefern.
Obwohl bestimmte exemplarische Verfahren, Vorrichtungen und Herstellungsgegenstände hier offengelegt wurden, ist der Erfassungsbereich dieses Patents nicht darauf beschränkt. Im Gegenteil, dieses Patent umfasst alle Verfahren, Vorrichtungen und Herstellungsgegenstände, die in den Anwendungsbereich der Ansprüche dieses Patents fallen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 62/508891 [0001]

Claims

Vorrichtung zum Durchführen eines Stereoabgleichs, wobei die Vorrichtung umfasst: einen Kostenberechnungsmanager, um einen Wert zu bestimmen, der einem ersten Ort eines ersten Pixels eines ersten Bildes und einem zweiten Ort eines zweiten Pixels eines zweiten Bildes zugeordnet ist, indem Abgleichkosten zwischen dem ersten Ort und dem zweiten Ort berechnet werden; und einen Aggregationsgenerator zum: Erzeugen einer Disparitätskarte mit dem Wert; und Bestimmen eines Mindestwertes basierend auf der Disparitätskarte entsprechend einem Unterschied in horizontalen Koordinaten zwischen dem ersten Ort und dem zweiten Ort.
Vorrichtung nach Anspruch 1, die ferner einen Zensus-Transformationshandler zum Erzeugen eines Bitdeskriptors beinhaltet, der Intensitätswerte eines Satzes von Pixeln eines Pixel-Kernels, der das zweite Pixel beinhaltet, auf eine Bitfolge abbildet.
Vorrichtung nach Anspruch 2, wobei der Zensus-Transformationshandler die Bitfolge erzeugt, indem er die Intensitätswerte des Satzes von Pixeln mit einem Intensitätswert eines Zentralpixels des Pixel-Kernels, einem Mittelwert der Intensitätswerte oder einem Schwellenwert vergleicht.
Vorrichtung nach Anspruch 2, worin der Bitdeskriptor ein Post-Mask-Bitdeskriptor ist, wobei der Zensus-Transformationshandler die Bitfolge durch Anwenden einer Verkettungsmaske und eines oder mehrerer Sortierbäume auf einen Pre-Mask-Bitdeskriptor erzeugt, um den Post-Mask-Bitdeskriptor zu erzeugen.
Vorrichtung nach Anspruch 2, worin der Bitdeskriptor ein erster Bitdeskriptor ist, der Kostenberechnungsmanager die Disparität bestimmt durch: Berechnen einer absoluten Differenz zwischen einem ersten Pixelintensitätswert des ersten Pixels und einem zweiten Pixelintensitätswert des zweiten Pixels; Berechnen eines Hamming-Abstand zwischen dem ersten Bitdeskriptor des ersten Pixels und einen zweiten Bit-Deskriptor des zweiten Pixels; Berechnen einer Summe aus der absoluten Differenz und des Hamming-Abstands; und Bestimmen der Disparität durch Spannen der Summe auf eine ganze Zahl.
Vorrichtung nach Anspruch 1, worin die Abgleichkosten erste Abgleichkosten sind, wobei der Kostenberechnungsmanager die Abgleichkosten einschließlich der ersten Abgleichkosten unter Verwendung von Barrel-Shiftern neu ausrichtet.
Vorrichtung nach Anspruch 1, worin der Aggregationsgenerator eingerichtet ist zum: Berechnen von ersten aggregierten Kosten, die mit einem ersten Ausbreitungsweg verbunden sind, entsprechend einem von links nach rechts gerichteten Eingabepfad von dem zweiten Pixel zu dem ersten Pixel; Berechnen von zweiten aggregierten Kosten, die mit einem zweiten Ausbreitungsweg verbunden sind, entsprechend einem von rechts nach links gerichteten Eingabepfad von dem zweiten Pixel zu dem ersten Pixel; Berechnen von dritten aggregierten Kosten, die mit einem dritten Ausbreitungsweg verbunden sind, entsprechend einem von oben nach unten gerichteten Eingabepfad von dem zweiten Pixel zu dem ersten Pixel; und Bestimmen der Disparitätskarte basierend auf der Berechnung einer Summe aus den ersten aggregierten Kosten, den zweiten aggregierten Kosten und den dritten aggregierten Kosten.
Nicht-flüchtiges, computerlesbares Speichermedium, das Anweisungen umfasst, die, wenn sie ausgeführt werden, eine Engine mindestens dazu veranlasst: einen Wert zu bestimmen, der einem ersten Ort eines ersten Pixels eines ersten Bildes und einem zweiten Ort eines zweiten Pixels eines zweiten Bildes zugeordnet ist, durch Berechnen von Abgleichkosten zwischen dem ersten Ort und dem zweiten Ort; eine Disparitätskarte mit dem Wert zu erzeugen; und einen Mindestwert basierend auf der Disparitätskarte zu bestimmen, der einer Differenz in horizontalen Koordinaten zwischen dem ersten Ort und dem zweiten Ort entspricht.
Nicht-flüchtiges, computerlesbares Speichermedium nach Anspruch 8, ferner mit Anweisungen, die, wenn sie ausgeführt werden, die Engine veranlassen, mindestens einen Bitdeskriptor zu erzeugen, der Intensitätswerte eines Satzes von Pixeln eines Pixel-Kernels, der das zweite Pixel beinhaltet, auf eine Bitfolge abbildet.
Nicht-flüchtiges, computerlesbares Speichermedium nach Anspruch 9, ferner mit Anweisungen, die, wenn sie ausgeführt werden, die Engine veranlassen, mindestens die Bitfolge zu erzeugen, indem sie die Intensitätswerte des Satzes von Pixeln mit einem Intensitätswert eines Zentralpixels des Pixel-Kernels, einem Mittelwert der Intensitätswerte oder einem Schwellenwert vergleichen.
Nicht-flüchtiges, computerlesbares Speichermedium nach Anspruch 9, worin der Bitdeskriptor ein Post-Mask-Bitdeskriptor ist, ferner Anweisungen beinhaltend, die, wenn sie ausgeführt werden, die Engine veranlassen, zumindest die Bitfolge durch Anwenden einer Verkettungsmaske und eines oder mehrerer Sortierbäume auf einen Pre-Mask-Bitdeskriptor, um den Post-Mask-Bitdeskriptor zu erzeugen.
Nicht-flüchtiges, computerlesbares Speichermedium nach Anspruch 9, worin der Bit-Deskriptor ein erster Bit-Deskriptor ist, ferner mit Anweisungen, die bei Ausführung die Engine zumindest dazu veranlassen: eine absolute Differenz zwischen einem ersten Pixel-Intensitätswert des ersten Pixel und einen zweiten Pixelintensitätswert des zweiten Pixels zu berechnen; einen Hamming-Abstand zwischen dem ersten Bit-Deskriptor des ersten Pixels und einen zweiten Bit-Deskriptor des zweiten Pixels zu berechnen; eine Summe aus der absoluten Differenz und des Hamming-Abstands zu berechnen; und die Disparität durch Spannen der Summe auf eine ganze Zahl zu bestimmen.
Nicht-flüchtiges, computerlesbares Speichermedium nach Anspruch 8, wobei die Abgleichkosten erste Abgleichkosten sind, ferner einschließlich Anweisungen, die, wenn sie ausgeführt werden, die Engine veranlassen, zumindest die Abgleichkosten einschließlich der ersten Abgleichkosten unter Verwendung von Barrel-Shiftern neu auszurichten.
Nicht-flüchtiges, computerlesbares Speichermedium nach Anspruch 1, ferner mit Anweisungen, bei Ausführung die Engine mindestens wie folgt zu veranlassen: Berechnen von ersten aggregierten Kosten, die mit einem ersten Ausbreitungsweg verbunden sind, entsprechend einem von links nach rechts gerichteten Eingabepfad von dem zweiten Pixel zu dem ersten Pixel; Berechnen von zweiten aggregierten Kosten, die mit einem zweiten Ausbreitungsweg verbunden sind, entsprechend einem von rechts nach links gerichteten Eingabepfad von dem zweiten Pixel zu dem ersten Pixel; Berechnen von dritten aggregierten Kosten, die mit einem dritten Ausbreitungsweg verbunden sind, entsprechend einem von oben nach unten gerichteten Eingabepfad von dem zweiten Pixel zu dem ersten Pixel; und Bestimmen der Disparitätskarte basierend auf der Berechnung einer Summe aus den ersten aggregierten Kosten, den zweiten aggregierten Kosten und den dritten aggregierten Kosten.
Verfahren zum Durchführen eines Stereoabgleichs, wobei das Verfahren umfasst: Bestimmen eines Wertes, der einem ersten Ort eines ersten Pixels eines ersten Bildes und einem zweiten Ort eines zweiten Pixels eines zweiten Bildes zugeordnet ist, durch Berechnen von Abgleichkosten zwischen dem ersten Ort und dem zweiten Ort; Erzeugen einer Disparitätskarte mit dem Wert; und Bestimmen eines Mindestwertes basierend auf der Disparitätskarte, der einer Differenz der horizontalen Koordinaten zwischen dem ersten Ort und dem zweiten Ort entspricht.
Verfahren nach Anspruch 15, ferner umfassend das Erzeugen eines Bitdeskriptors, der Intensitätswerte eines Satzes von Pixeln eines Pixel-Kernels, der das zweite Pixel beinhaltet, auf eine Bitfolge abbildet.
Verfahren nach Anspruch 16, wobei das Erzeugen der Bitfolge das Vergleichen der Intensitätswerte des Satzes von Pixeln mit einem Intensitätswert eines Zentralpixels des Pixel-Kernels, einem Mittelwert der Intensitätswerte oder einem Schwellenwert beinhaltet.
Verfahren nach Anspruch 16, wobei der Bitdeskriptor ein Post-Mask-Bitdeskriptor ist, und Erzeugen der Bitfolge durch Anwenden einer Verkettungsmaske und eines oder mehrerer Sortierbäume auf einen Pre-Mask-Bitdeskriptor, um den Post-Mask-Bitdeskriptor zu erzeugen.
Verfahren nach Anspruch 16, wobei der Bitdeskriptor ein erster Bitdeskriptor ist, und Bestimmen der Disparität durch: Berechnen einer absoluten Differenz zwischen einem ersten Pixelintensitätswert des ersten Pixels und einem zweiten Pixelintensitätswert des zweiten Pixels; Berechnen eines Hamming-Abstands zwischen dem ersten Bitdeskriptor des ersten Pixels und einem zweiten Bitdeskriptor des zweiten Pixels; Berechnen einer Summe aus der absoluten Differenz und des Hamming-Abstands; und Bestimmen der Disparität durch Spannen der Summe auf eine ganze Zahl.
Verfahren nach Anspruch 15, worin die Abgleichkosten erste Abgleichkosten sind, ferner umfassend eine Neuausrichtung von Abgleichkosten einschließlich der ersten Abgleichkosten unter Verwendung von Barrel-Shiftern.
Verfahren nach Anspruch 15, ferner umfassend: Berechnen von ersten aggregierten Kosten, die mit einem ersten Ausbreitungsweg verbunden sind, entsprechend einem von links nach rechts gerichteten Eingabepfad von dem zweiten Pixel zu dem ersten Pixel; Berechnen von zweiten aggregierten Kosten, die mit einem zweiten Ausbreitungsweg verbunden sind, entsprechend einem von rechts nach links gerichteten Eingabepfad von dem zweiten Pixel zu dem ersten Pixel; Berechnen von dritten aggregierten Kosten, die mit einem dritten Ausbreitungsweg verbunden sind, entsprechend einem von oben nach unten gerichteten Eingabepfad von dem zweiten Pixel zu dem ersten Pixel; und Bestimmen der Disparitätskarte basierend auf der Berechnung einer Summe aus den ersten aggregierten Kosten, den zweiten aggregierten Kosten und den dritten aggregierten Kosten.
Vorrichtung zum Durchführen eines Stereoabgleichs, wobei die Vorrichtung umfasst: ein erstes Mittel zum Bestimmen eines Wertes, der einem ersten Ort eines ersten Pixels eines ersten Bildes und einem zweiten Ort eines zweiten Pixels eines zweiten Bildes zugeordnet ist, durch Berechnen von Abgleichkosten zwischen dem ersten Ort und dem zweiten Ort; und ein zweites Mittel zum: Erzeugen einer Disparitätskarte mit dem Wert; und Bestimmen eines Mindestwertes basierend auf der Disparitätskarte entsprechend einem Unterschied in horizontalen Koordinaten zwischen dem ersten Ort und dem zweiten Ort.
Die Vorrichtung nach Anspruch 22, die ferner ein drittes Mittel zum Erzeugen eines Bitdeskriptors beinhaltet, der Intensitätswerte eines Satzes von Pixeln eines Pixel-Kernels, der das zweite Pixel beinhaltet, auf eine Bitfolge abbildet.
Vorrichtung nach Anspruch 23, wobei das dritte Mittel zum Erzeugen der Bitfolge durch Vergleichen der Intensitätswerte des Satzes von Pixeln mit einem Intensitätswert eines Zentralpixels des Pixel-Kernels, einem Mittelwert der Intensitätswerte oder einem Schwellenwert dient.
Vorrichtung nach Anspruch 23, wobei der Bitdeskriptor ein Post-Mask-Bitdeskriptor ist, wobei das dritte Mittel zum Erzeugen der Bitfolge durch Anwenden einer Verkettungsmaske und eines oder mehrerer Sortierbäume auf einen Pre-Mask-Bitdeskriptor, um den Post-Mask-Bitdeskriptor zu erzeugen.
Vorrichtung nach Anspruch 23, worin der Bitdeskriptor ein erster Bitdeskriptor ist, das erste Mittel zum Bestimmen der Disparität ist eingerichtet durch: Berechnen einer absoluten Differenz zwischen einem ersten Pixelintensitätswert des ersten Pixels und einem zweiten Pixelintensitätswert des zweiten Pixels; Berechnen eines Hamming-Abstands zwischen dem ersten Bitdeskriptor des ersten Pixels und einem zweiten Bit-Deskriptor des zweiten Pixels; Berechnen einer Summe aus der absoluten Differenz und des Hamming-Abstands; und Bestimmen der Disparität durch Spannen der Summe auf eine ganze Zahl.
Vorrichtung nach Anspruch 22, worin die Abgleichkosten erste Abgleichkosten sind, wobei das erste Mittel eingerichtet ist zur Neuausrichtung von Abgleichkosten einschließlich der ersten Abgleichkosten unter Verwendung von Barrel-Shiftern.
Die Vorrichtung nach Anspruch 22, worin das zweite Mittel eingerichtet ist zum: Berechnen von ersten aggregierten Kosten, die mit einem ersten Ausbreitungsweg verbunden sind, entsprechend einem von links nach rechts gerichteten Eingabepfad von dem zweiten Pixel zu dem ersten Pixel; Berechnen von zweiten aggregierten Kosten, die mit einem zweiten Ausbreitungsweg verbunden sind, entsprechend einem von rechts nach links gerichteten Eingabepfad von dem zweiten Pixel zu dem ersten Pixel; Berechnen von dritten aggregierten Kosten, die mit einem dritten Ausbreitungsweg verbunden sind, entsprechend einem von oben nach unten gerichteten Eingabepfad von dem zweiten Pixel zu dem ersten Pixel; und Bestimmen der Disparitätskarte basierend auf der Berechnung einer Summe aus den ersten aggregierten Kosten, den zweiten aggregierten Kosten und den dritten aggregierten Kosten.