DE102020122943A1 - Hardware-basierte beschleunigung eines optischen flusses - Google Patents

Hardware-basierte beschleunigung eines optischen flusses Download PDF

Info

Publication number
DE102020122943A1
DE102020122943A1 DE102020122943.7A DE102020122943A DE102020122943A1 DE 102020122943 A1 DE102020122943 A1 DE 102020122943A1 DE 102020122943 A DE102020122943 A DE 102020122943A DE 102020122943 A1 DE102020122943 A1 DE 102020122943A1
Authority
DE
Germany
Prior art keywords
optical flow
disparity
sgm
disparity search
ofa
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020122943.7A
Other languages
English (en)
Inventor
Dong Megamus Zhang
JinYue (Gser) Lu
Zejun (Harry) Hu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nvidia Corp
Original Assignee
Nvidia Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nvidia Corp filed Critical Nvidia Corp
Publication of DE102020122943A1 publication Critical patent/DE102020122943A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00Image analysis
    • G06T7/20Analysis of motion
    • G06T7/269Analysis of motion using gradient-based methods
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3877Concurrent instruction execution, e.g. pipeline or look ahead using a slave processor, e.g. coprocessor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T5/00Image enhancement or restoration
    • G06T5/70Denoising; Smoothing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00Image analysis
    • G06T7/20Analysis of motion
    • G06T7/207Analysis of motion for motion estimation over a hierarchy of resolutions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00Image analysis
    • G06T7/20Analysis of motion
    • G06T7/215Motion-based segmentation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06VIMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00Arrangements for image or video recognition or understanding
    • G06V10/10Image acquisition
    • G06V10/12Details of acquisition arrangements; Constructional details thereof
    • G06V10/14Optical characteristics of the device performing the acquisition or on the illumination arrangements
    • G06V10/147Details of sensors, e.g. sensor lenses
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06VIMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00Arrangements for image or video recognition or understanding
    • G06V10/70Arrangements for image or video recognition or understanding using pattern recognition or machine learning
    • G06V10/764Arrangements for image or video recognition or understanding using pattern recognition or machine learning using classification, e.g. of video objects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06VIMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V10/00Arrangements for image or video recognition or understanding
    • G06V10/70Arrangements for image or video recognition or understanding using pattern recognition or machine learning
    • G06V10/82Arrangements for image or video recognition or understanding using pattern recognition or machine learning using neural networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06VIMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V20/00Scenes; Scene-specific elements
    • G06V20/50Context or environment of the image
    • G06V20/56Context or environment of the image exterior to a vehicle by using sensors mounted on the vehicle
    • G06V20/58Recognition of moving objects or obstacles, e.g. vehicles or pedestrians; Recognition of traffic objects, e.g. traffic signs, traffic lights or roads
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00Indexing scheme for image analysis or image enhancement
    • G06T2207/10Image acquisition modality
    • G06T2207/10004Still image; Photographic image
    • G06T2207/10012Stereo images
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00Indexing scheme for image analysis or image enhancement
    • G06T2207/20Special algorithmic details
    • G06T2207/20016Hierarchical, coarse-to-fine, multiscale or multiresolution image processing; Pyramid transform
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00Indexing scheme for image analysis or image enhancement
    • G06T2207/20Special algorithmic details
    • G06T2207/20084Artificial neural networks [ANN]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Evolutionary Computation (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Databases & Information Systems (AREA)
  • Medical Informatics (AREA)
  • Computing Systems (AREA)
  • Vascular Medicine (AREA)
  • General Engineering & Computer Science (AREA)
  • Image Analysis (AREA)

Abstract

Ein Beschleuniger für einen optischen Fluss (OFA), der eine hardwarebasierte Beschleunigung einer Bestimmung eines optischen Flusses und einer Bestimmung von Stereodisparität ermöglicht, wird beschrieben. Es wird ein System beschrieben, das einen OFA umfasst, der so konfiguriert ist, dass er einen ersten optischen Fluss unter Verwenden einer ersten Disparitäts-Suchtechnik und einen zweiten optischen Fluss unter Verwenden einer zweiten Disparitäts-Suchtechnik, die sich von der ersten Disparitäts-Suchtechnik unterscheidet, bestimmt. Das System umfasst auch einen Prozessor, der so konfiguriert ist, dass er den ersten optischen Fluss und den zweiten optischen Fluss kombiniert, um einen dritten optischen Fluss zu erzeugen. In einigen Implementierungen basieren die erste und zweite Disparitäts-Suchtechnik auf dem Semi-Global Matching (SGM). In einigen Implementierungen ist der OFA weiter konfigurierbar, um die Stereodisparität zu bestimmen.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Offenbarung bezieht sich im Allgemeinen auf Techniken zum Erkennen von Bewegungen und zum Identifizieren von Objekten in einer Szene basierend auf einer Bildsequenz, und insbesondere auf optischen Fluss und Stereodisparität in der Grafikverarbeitung, und weiter insbesondere auf eine hardwarebasierte Beschleunigung einer Bestimmung eines optischen Flusses und einer Stereodisparität.
  • HINTERGRUND
  • Optischer Fluss ist eine grundlegende Technik in der Computervision. Der Begriff „optischer Fluss“ bezieht sich auf die Bewegung in einer Szene, die in einem Bild repräsentiert wird. Die Bewegung ist auf die relative Bewegung von Objekten in der Szene und der Kamera, die das Bild dieser Szene aufnimmt, zurückzuführen. Die relative Bewegung kann das Ergebnis einer Kamerabewegung, einer Objektbewegung oder einer Bewegung sowohl des Objekts als auch der Kamera sein. Optischer Fluss wird auch als die Verteilung der scheinbaren Bewegungsgeschwindigkeiten von Helligkeitsmustern in einem Bild beschrieben. Konkreter kann optischer Fluss als die Schätzung der zweidimensionalen (2D) Verschiebung von Pixeln zwischen zwei Einzelbildern (d.h. Frames) betrachtet werden, die zu unterschiedlichen Zeiten aufgenommen wurden. Verfahren zur Berechnung des optischen Flusses können die Bewegung zwischen zwei Einzelbildern berechnen, die zu den Zeiten t und t + δ an jeder Pixelposition aufgenommen wurden.
  • Der optische Fluss umfasst jedoch keine Tiefeninformationen. Bei zwei Paaren von Stereobildern, die in aufeinanderfolgenden Zeitintervallen t und t + δ aufgenommen wurden, erfordert die Abschätzung der dreidimensionalen (3D-)Szene daher zusätzlich zum optischen Fluss die Abschätzung der Stereodisparität in jedem Paar von Stereobildern. Die Stereodisparität schätzt die Verschiebung der einzelnen Pixel zwischen dem linken und rechten Stereobild ab.
  • Der optische Fluss und die Stereodisparität einer Szene liefert Informationen über räumliche Beziehungen und Änderungsraten, die mit den Objekten in der Szene assoziiert sind. Diskontinuitäten im optischen Fluss können verwendet werden, um Objekte in der Szene zu identifizieren, indem z.B. Bereiche im Bild segmentiert werden, die entsprechende Objekte abbilden. Das Feld des optischen Flusses und/oder die Stereodisparität können zur Bestimmung dreidimensionaler Strukturen in der Szene und/oder zur Bestimmung der Bewegung von Objekten und der Kamera relativ zur Szene verwendet werden.
  • Die schnelle und effiziente Berechnung des optischen Flusses und der Stereodisparität ist für viele Echtzeitanwendungen wie autonomes Fahren usw. wichtig. Der optische Fluss einer Szene, der basierend auf einer Sequenz von Einzelbildern bestimmt wird, kann bei der Bildverarbeitung und der Steuerung der Navigation verwendet werden und umfasst Bewegungserkennung, Objektsegmentierung, Informationen der Zeit bis zu einem Kontakt, Berechnungen des Fokus einer Ausdehnung, Luminanz, bewegungskompensierte Kodierung und Messung der Stereodisparität. Einige Automobilanwendungen (z.B. Advanced Driver Assistance Systems (ADAS), autonome Fahrsysteme usw.) erfordern eine Berechnung des optischen Flusses in Echtzeit zur Objekterkennung und/oder -verfolgung für die autonome Navigation und dergleichen. Ähnliche Anwendungen können auch für Roboter, Flugzeuge, auf Wasser basierende Fahrzeuge und andere sich bewegende Objekte gemacht werden. Die Objektidentifizierung und dergleichen aus Video-Einzelbildern kann ebenfalls vom optischen Fluss profitieren, um klarere Video-Einzelbilder für Deep Learning-Techniken für Videoinferenzierung und dergleichen bereitzustellen. Weitere Verwendungen für die Ausgabe von Techniken des optischen Flusses umfassen das Zusammenfügen von Einzelbildern in Virtual-Reality-Anwendungen, die Hochkonvertierung von Videobildraten in Spielanwendungen usw.
  • Bis vor einigen Jahren waren Aufgaben wie das Erkennen und Verfolgen eines Objekts oder das Klassifizieren einer Aktion in Videostreams aufgrund der damit verbundenen Rechenkomplexität, insbesondere bei der Berechnung des optischen Flusses, für Computer unerreichbar. Mit dem Aufkommen von Deep Neural Networks (DNNs) und der massiven Beschleunigung, die durch Graphics Processing Units (GPU) ermöglicht wird, können viele dieser Aufgaben heute mit hoher Genauigkeit von Computern ausgeführt werden. Es gibt zwei primäre Verfahren zur Verfolgung von Objekten innerhalb eines Video-Feeds: Detektieren in jedem Einzelbild - Identifizieren des Begrenzungsrahmens für das/die interessierende(n) Objekt(e) in jedem Einzelbild unter Verwendung von Objektklassifizierung und Verfolgen der Objektgrenzen von Einzelbild zu Einzelbild; und Detektieren und Verfolgen - Identifizieren des Begrenzungsrahmens für das Objekt im ersten Einzelbild (oder in jedem n-ten Einzelbild) und Berechnen der Bewegung der zu dem Objekt gehörenden Pixel (oder Blöcke) in den nachfolgenden Einzelbildern zur Verfolgung. Das erste Verfahren hat eine sehr hohe Genauigkeit, ist aber rechnerisch aufwendig, da die Objektklassifizierung (Inferenz) auf jedem Einzelbild ausgeführt werden muss. Das zweite Verfahren erfordert weniger Berechnungen, stützt sich jedoch auf genaue Abschätzungen der Bewegungs-/Flussvektoren der Pixel (oder Blöcke) zwischen aufeinanderfolgenden Einzelbildern.
  • Trotz Verbesserungen der Prozessorgeschwindigkeiten erweist sich ein vollständig softwarebasierter optischer Fluss für Echtzeitanwendungen oft als unzureichend. Mit den Turing™ Grafikprozessoren von NVIDIA wurde eine Hardware-Funktionalität zur Berechnung des optischen Flusses zwischen Bildern mit sehr hoher Leistung eingeführt. Siehe „An Introduction to the NVIDIA Optical Flow SDK‟ unter https://devblogs.nvidia.com/anintroduction-to-the-nvidia-optical-flow-sdk/ (Zugriff am 15. Juli 2019).
  • Da jedoch die Anwendungen des optischen Flusses zunehmen und die Genauigkeits-/Leistungsanforderungen immer strenger werden, kann eine dedizierte Hardware-Einheit für mindestens einige Echtzeitanwendungen wünschenswert sein. Zum Beispiel ist die Qualität des optischen Flusses und des Stereosignals für ADAS- und autonome Fahranwendungen von entscheidender Bedeutung, da sie sicherheitskritisch sind. Optischer Fluss ist auch einer der Schlüsselaspekte zur Verbesserung der Benutzererfahrung von Virtual-Reality (VR)/Gaming-Anwendungen. Andere Verwendungszwecke des optischen Flusses, wie das Abschätzen der Stereotiefe, die Interpolation von Video-Einzelbildern und die Extrapolation von Video-Einzelbildern, können ebenfalls von einem verbesserten und effizienteren optischen Fluss profitieren.
  • ZUSAMMENFASSUNG
  • Ein Ausführungsbeispiel stellt ein System bereit, das eine Schaltungsanordnung zur Beschleunigung des optischen Flusses und mindestens einen Prozessor umfasst. Die Schaltungsanordnung zur Beschleunigung des optischen Flusses ist konfiguriert zum: Bestimmen eines ersten optischen Flusses, der mit Eingabebildern assoziiert ist, wobei der erste optische Fluss unter Verwendung einer ersten Disparitäts-Suchtechnik bestimmt wird; und Bestimmen eines zweiten optischen Flusses, der mit den Eingabebildern assoziiert ist, wobei der zweite optische Fluss unter Verwendung einer zweiten Disparitäts-Suchtechnik bestimmt wird, die sich von der ersten Disparitäts-Suchtechnik unterscheidet. Der mindestens eine Prozessor ist konfiguriert, um den ersten optischen Fluss und den zweiten optischen Fluss zu kombinieren, um einen dritten optischen Fluss zu erzeugen, der mit den Eingabebildern assoziiert ist.
  • In einem Ausführungsbeispiel wird ein Verfahren für eine beschleunigte Erzeugung optischer Flüsse vorgestellt. Das Verfahren umfasst einen Schritt eines Bestimmens eines ersten optischen Flusses, der mit Eingabebildern assoziiert ist, wobei der erste optische Fluss unter Verwendung einer ersten Disparitätssuche bestimmt wird. Das Verfahren umfasst weiter einen Schritt eines Bestimmens eines zweiten optischen Flusses, der mit den Eingabebildern assoziiert ist, wobei der zweite optische Fluss unter Verwendung einer zweiten Disparitätssuche bestimmt wird, die sich von der ersten Disparitätssuche unterscheidet; und einen Schritt eines Kombinierens des ersten optischen Flusses und des zweiten optischen Flusses, um einen dritten optischen Fluss zu erzeugen, der mit den Eingabebildern assoziiert ist.
  • In einem Ausführungsbeispiel wird ein Beschleuniger für einen optischen Fluss bereitgestellt, der einen ersten Schaltkreis und einen zweiten Schaltkreis umfasst, wobei sich der erste Schaltkreis und der zweite Schaltkreis einen gemeinsamen Schaltkreis zur Durchführung einer Kernregularisierungstechnik für Pixelabgleichskosten teilen. Die erste Schaltungsanordnung ist zum Bestimmen eines ersten optischen Flusses konfiguriert, der mit ersten und zweiten Eingabebildern assoziiert ist, wobei der erste optische Fluss unter Verwendung einer ersten Disparitätssuche bestimmt wird; und die zweite Schaltungsanordnung ist zum Bestimmen eines zweiten optischen Flusses konfiguriert, der mit den Eingabebildern assoziiert ist, wobei der zweite optische Fluss unter Verwendung einer zweiten Disparitätssuche bestimmt wird, die sich von der ersten Disparitätssuche unterscheidet.
  • Figurenliste
    • 1 zeigt schematisch ein System, das einen Hardware-Beschleuniger für einen optischen Fluss (engl. optical flow accelerator, OFA) umfasst, gemäß einigen Ausführungsbeispielen.
    • 2 zeigt auf hoher Ebene eine logische Ansicht der Funktionen zur Beschleunigung des optischen Flusses, die durch ein System wie dem in 1 gezeigten bereitgestellt werden, gemäß einigen Ausführungsbeispielen.
    • 3A zeigt ein Beispiel für eine Disparität in Stereobildern, die von derselben Szene aufgenommen wurden.
    • 3B zeigt ein Beispiel für die epipolare Beziehung zwischen zwei Kameras, die für die Berechnung des optischen Flusses verwendet werden, gemäß einigen Ausführungsbeispielen.
    • 3C zeigt eine beispielhafte Pyramidenstruktur eines Bildes (als „Gauß-Pyramide“ bezeichnet), die für die Berechnung des optischen Flusses verwendet wird, gemäß einigen Ausführungsbeispielen.
    • 4 zeigt schematisch die Schaltung eines Beschleunigers für einen optischen Fluss, wie dem in gezeigten, gemäß einigen Ausführungsbeispielen.
    • 5 zeigt schematisch Schaltungen eines Cost-Volume-Constructors (CVC), wie er im Beschleuniger für einen optischen Fluss (engl. Optical Flow Accelerator, OFA) in 4 gezeigt wird, gemäß einigen Ausführungsbeispielen.
    • 6 zeigt ein Beispiel einiger Berechnungen, die von der Konsensus-Transformations- und Hamming-Distance-Schaltung (engl. consensus transform and hamming distance, CT und HD), wie in dem OFA von 4 gezeigt, durchgeführt wurden, gemäß einigen Ausführungsbeispielen.
    • 7 zeigt ein schematisches Blockdiagramm einer semi-globalen Anpassungsschaltung (engl. semi global matching circuitry, SGM), wie in dem OFA von 4 gezeigt, gemäß einigen Ausführungsbeispielen.
    • 8A zeigt beispielhafte Pfadrichtungen, die für SGM-Berechnungen konfigurierbar sind, die in einigen Ausführungsbeispielen verwendet werden können.
    • 8B zeigt ein Bestimmen von Abgleichskosten (engl. matching cost) in eindimensionalen (1D) Implementierungen, gemäß einigen Ausführungsbeispielen.
    • 8C und 8D zeigen ein Bestimmen von Abgleichskosten in zweidimensionalen (2D) Implementierungen, gemäß einigen Ausführungsbeispielen.
    • 8E und 8F zeigen mehrere Iterationen von SGM-Implementierungen, gemäß einigen Ausführungsbeispielen.
    • 8G zeigt ein Merkmal der Gittergröße für OFA, gemäß einigen Ausführungsbeispielen.
    • 9 zeigt eine Systempipeline für den epipolaren SGM-Modus für einen optischen Fluss in einem System wie dem in 1 gezeigten, gemäß einigen Ausführungsbeispielen.
    • 10 zeigt ein Flussdiagramm für eine Technik zum Generieren des Inputs für den OFA in einer Epipolarmodus-Systempipeline, gemäß einigen Ausführungsbeispielen.
    • 11 zeigt eine Systempipeline für den Pyramiden-SGM-Modus des optischen Flusses in einem System wie dem System in 1, gemäß einigen Ausführungsbeispielen.
    • 12 zeigt eine Systempipeline für den Stereomodus in einem System wie dem System in 1, gemäß einigen Ausführungsbeispielen.
    • 13 zeigt eine Systempipeline für einen Fusions-SGM-Modus für einen optischen Fluss in einem System wie dem System in 1, gemäß einigen Ausführungsbeispielen.
    • 14A zeigt schematisch ein System, wie das System in 1, einschließlich einem OFA, das in einer Automobilanwendung integriert ist, gemäß einigen Ausführungsbeispielen.
    • 14B zeigt ein Flussdiagramm für einen Prozess, der einen hardwarebeschleunigten optischen Fluss und eine Erzeugung von Stereodisparitäten verwendet, gemäß einigen Ausführungsbeispielen.
    • 15 zeigt eine Parallelverarbeitungseinheit, die sich in einem System, wie dem in 1 gezeigten, befinden kann, gemäß einem Ausführungsbeispiel.
    • 16A zeigt ein konzeptionelles Diagramm eines Verarbeitungssystems, das unter Verwendung der Parallelverarbeitungseinheit (PPU) von 15 und eines optischen Flusses (OFA) von 4 implementiert wurde, gemäß einem Ausführungsbeispiel.
    • 16B zeigt ein beispielhaftes System, in dem die verschiedenen Architekturen und/oder Funktionen der verschiedenen früheren Ausführungsbeispiele implementiert werden können.
  • DETAILLIERTE BESCHREIBUNG
  • Bestimmte Ausführungsbeispiele der vorliegenden Erfindung sehen eine hardwarebasierte Beschleunigung der Bestimmung des optischen Flusses vor. Die Beschleunigung wird durch eine Hardware-Einheit bereitgestellt, die in einigen Ausführungsbeispielen spezifisch ausschließlich dem optischen Fluss gewidmet ist. Die Hardware-Einheit wird hier als „Beschleuniger für einen optischen Fluss“ (OFA) bezeichnet. Der OFA kann auch zur Beschleunigung der Bestimmung von Stereodisparitäten dienen. Wenn das System so konfiguriert ist, dass es sowohl eine Beschleunigung der Bestimmung des optischen Flusses als auch eine Beschleunigung der Bestimmung der Stereodisparität bietet, kann ein System, das den OFA enthält, Eingabe-Videostreams verarbeiten, indem es basierend auf entsprechenden Paaren von Stereobildern, die in aufeinanderfolgenden Zeitintervallen t und t + δ aufgenommen wurden, die Abschätzung der 3D-Szene für den Echtzeiteinsatz in zahlreichen Anwendungen beschleunigt.
  • Der OFA ist für Anwendungen konzipiert, die sowohl eine hohe Qualität als auch eine hohe Leistung des optischen Flusses und der Stereodisparität erfordern. Obwohl in einigen bestehenden Systemen bestimmte Hardwarekomponenten durch eine Unterstützung von Aspekten des optischen Flusses und Stereodisparitiätsmerkmalen verbessert werden, wie im Hintergrundabschnitt beschrieben, scheinen die bestehenden Systeme nicht ausreichend zu sein, um die hohen Qualitäts- und Geschwindigkeitsanforderungen bestimmter neuerer Anwendungen, die immer beliebter werden, zu erfüllen. Sicherheitskritische Echtzeit-Anwendungen wie das vollständig autonome Fahren/Navigieren und ADAS (die als Objekt/Fußgänger-Erkennung/Verfolgung z.B. eine Bestimmung von Struktur aus Bewegung (engl. Structure From Motion, SFM), eine gleichzeitige Lokalisierung und Kartierung (engl. Simultaneous Localization and Mapping, SLAM) usw. beinhalten) können durch Verwenden des OFA zur Erzeugung des optischen Flusses und einer glatten dichten Disparitätskarte, die eine genaue 3D-Rekonstruktion einer Szene erleichtert, erheblich verbessert werden. Der optische Fluss, die Disparitäten und, optional, andere assoziierte Informationen, die von dem OFA für eine Szene ausgegeben werden, können von der autonomen Navigations- oder ADAS-Anwendung verwendet werden, um Objekte und andere Merkmale der Szene schneller und genauer zu erkennen, als dies bisher mit herkömmlichen Systemen möglich war. Die verbesserte Genauigkeit und Geschwindigkeit kann zu einer verbesserten Navigationskontrolle und Sicherheit des Fahrzeugs sowie zu einem verbesserten Erlebnis für den Fahrer des Fahrzeugs führen. Auch andere Anwendungen, die vielleicht nicht so sicherheitskritisch sind, aber erhebliche Echtzeitanforderungen stellen (z.B. 360 Video Stitching usw. für Virtual Reality, Up-Conversion der Bildrate für Spiele usw. und Video-Klassifizierung usw. für Deep Learning), können durch den Einsatz des OFA erheblich verbessert werden.
  • In vielen Anwendungen, einschließlich der oben genannten, kann der OFA einen Teil der frühen Verarbeitungsphasen umfassen und mit Eingabebildern mit oder ohne Vorverarbeitung durch eine GPU (Graphics Processing Unit) oder einen anderen Prozessor arbeiten. Der OFA kann z.B. Bilder einer Szene als Eingabe nehmen und den entsprechenden optischen Fluss und die Disparitätskarte zur Verwendung in späteren Phasen der Anwendungen erzeugen. Der hochwertige optische Fluss und die Disparitätskarte, wie sie von dem OFA in Echtzeit bereitgestellt werden, können einen echten optischen Fluss bei 100 % Dichte ermöglichen und noch anspruchsvollere Anwendungen, wie z.B. eine effiziente 6D-Echtzeit-Visionsanalyse, erleichtern.
  • Der OFA ist gemäß einigen Ausführungsbeispielen eine Hardware-Engine, die sowohl für ein Abschätzen der Stereodisparität als auch des optischen Flusses konfiguriert sein kann. Sie bietet eine einheitliche Architektur, die „Semi Global Matching“ (SGM) als Kernregularisierer für die Abgleichkostenbestimmung verwendet. In einigen Ausführungsbeispielen unterstützt der OFA möglicherweise eindimensionale (1D)/zweidimensionale (2D) Kostenanpassung und 1D/2D-SGM für Stereo, eine Abschätzung des optischen Flusses basierend auf epipolarem SGM und basierend auf pyramidalem SGM.
  • Verschiedene bestehende SGM-basierte Lösungen verwenden SGM zum Abschätzen von Stereodisparitäten. Der OFA hingegen ist so konfiguriert, dass er SGM sowohl für eine epipolare Beschleunigung des optischen Flusses mit SGM als auch für eine Beschleunigung des optischen Flusses mit pyramidalem SGM verwendet. Um ein hohes Niveau an Flexibilität und Anpassungsfähigkeit zu erreichen, unterstützt der OFA in einigen Ausführungsbeispielen vier Modi: optischer Fluss mittels epipolarem SGM, optischer Fluss mittels pyramidalem SGM, optischer Fluss mittels Fusion, und Stereo-SGM. Der Modus des optischen Flusses mittels epipolarem SGM basiert auf einer Geometrie mit nur einer Ansicht und wird zum Abschätzen der Bewegung stationärer Objekte verwendet. Der Modus des optischen Flusses mittels pyramidalem SGM ist eine generische Technik für optischen Fluss. Der Fusionsmodus für optischen Fluss ist eine Kombination der Modi des optischen Flusses mittels epipolarem und pyramidalen SGM mit einem weiteren Schritt eines Fusionierens der Ergebnisse von epipolaren und pyramidalen Verarbeitungspipelines. Der SGM-Stereomodus kann auf einem Standard-SGM-basierten Algorithmus basieren. In einigen Ausführungsbeispielen verwendet der OFA auch Hardware der monokularen Kamerabewegung (z.B. 3D-Bewegung der Kamera innerhalb einer Umgebung), um die Beschleunigung abzuschätzen. Darüber hinaus bietet der OFA die Flexibilität, selektiv entweder die Qualität oder die Leistung zu erhöhen. Die Fähigkeiten des OFA im Hinblick auf die Mehrfachverwendung von SGM sind besonders nützlich, da sowohl optischer Fluss als auch Stereo sowohl für autonome Fahranwendungen als auch für andere Anwendungen wie Videoklassifizierung/Aufwärtskonvertierung der Bildrate usw. wichtig sind.
  • Es wird erwartet, dass der OFA bestimmte Aspekte bestehender Implementierungen von beschleunigtem optischem Fluss, wie z.B. in den Xavier- und Turing-Prozessoren von NVIDIA, verbessern wird. Zum Beispiel verwendet der OFA aufgrund seiner Hardwarebeschleunigten SGM-Implementierung eine nicht-lokale Optimierung im Gegensatz zu den lokalen Verfahren, die Fehler bei der Anpassung in flachen/texturlosen Bereichen ergeben können, wie sie von den Implementierungen in Xavier- und Turing-Prozessoren verwendet werden. Der OFA ist so konzipiert, dass er auch Beschränkungen wie Bandbreiten- und/oder Berechnungsbeschränkungen überwindet, die eine volle High-Definition-Auflösung verhindern, wobei der Bewegungsvektor und/oder die Disparitätsgranularität auf 4x4-Block, die Subpixelpräzision auf Viertelgenauigkeit beschränkt und ausschließlich oder hauptsächlich auf Leistung ohne ausreichende Skalierbarkeit zwischen Leistung und Qualität optimiert ist.
  • System mit Hardware für eine Beschleunigung des optischen Flusses
  • 1 zeigt schematisch ein System, das einen Hardware-Beschleuniger für einen optischen Fluss umfasst, gemäß einigen Ausführungsbeispielen. Das gezeigte System 100 ist ein System auf einem Chip (engl. System on a Chip, SoC), das eine spezielle Schaltungsanordnung zur Beschleunigung des optischen Flusses in Form eines OFA umfasst. Der SoC 100 kann in verschiedenen Implementierungen verwendet werden, wie z.B. im Automobilbereich, einschließlich für Objekt-/Fußgängererkennung/-Verfolgung, SFM, SLAM usw.; Virtual-Reality-Anwendungen wie z.B. für 360-Grad-Videostitching usw.; Spielanwendungen wie z.B. Aufwärtskonvertierung von Einzelbildern usw.; Deep-Learning-Anwendungen wie z.B. Videoklassifizierung usw. oder andere Anwendungen, die optischen Fluss und/oder Stereodisparität verwenden.
  • Das System 100 umfasst einen OFA 102, der zumindest so konfiguriert ist, dass er aus Eingabebildern und zugehörigen Eingabeinformationen eine Karte des optischen Flusses und/oder eine Stereodisparitätskarte erzeugt. Der OFA 102 kann so konfiguriert sein, dass er in einem beliebigen Modus oder einer beliebigen Kombination von einem Modus des optischen Flusses der statischen Welt, einem Modus des allgemeinen optischen Flusses, einem Stereomodus oder einem Fusionsmodus des optischen Flusses arbeitet, in dem Karten des optischen Flusses/der Disparitäten, die für den optischen Fluss der statischen Welt und für den allgemeinen optischen Fluss erzeugt werden, kombiniert werden. Der spezielle Betriebsmodus des OFA 102 kann entweder bei der Initialisierung des Systems 100 oder dynamisch gemäß Verarbeitungsanforderungen ausgewählt werden. Wie oben und weiter unten in Bezug auf 2 und 4 erwähnt, implementiert der OFA 102 SGM als Kernregularisierer bei seinen Bestimmungen des optischen Flusses und der Stereodisparitäten.
  • Eine GPU 106 kann direkt und/oder indirekt über einen Grafik-Host 104 mit dem OFA 102 verbunden sein. Der Grafik-Host 104 bietet eine Programmier- und Steuerungsschnittstelle zu verschiedenen Grafik- und Video-Engines sowie zu der/den Anzeigeschnittstelle(n). Der Grafik-Host 104 kann auch Schnittstellen (nicht in 1 dargestellt) zu einem Switch (z. B. einem Crossbar-Switch o. ä.) zur Verbindung mit anderen Komponenten und eine direkte Speicherschnittstelle zum Abrufen von Befehls- und/oder Befehlsstrukturen aus dem Systemspeicher haben. In einigen Ausführungsbeispielen werden Befehle und/oder Befehlsstrukturen entweder aus einem Push-Puffer im Speicher geholt oder direkt von der Zentraleinheit (CPU) 108 bereitgestellt und dann an Clients geliefert, die ebenfalls mit dem Grafik-Host verbunden sind, wie z.B. der OFA 102. Auch ein Audio-/Video-Einzelbild-Kodierer/Dekodierer 112 ist über den Grafik-Host 104 angeschlossen. Der Audio-/Video-Einzelbild-Kodierer/Dekodierer 112 kann die Wiedergabe und/oder Erzeugung von Video in voller Bewegungs-Hochauflösung (z. B. 1440p High Definition) in einem beliebigen Format wie z. B. H.264 BP/MP/HP/MMC, VC-1, VP8, MPEG-2, MPEG-4 und verschiedenen Audiostandards unterstützen.
  • Der OFA 102 kann seine Eingabebilder erhalten und seine Ausgabebilder in einen Speicher (nicht in 1 gezeigt) schreiben, wie z.B. einen Einzelbild-Pufferspeicher, auf den über eine Schnittstelle 110 zugegriffen wird. Viele Komponenten im System 100, darunter z.B. GPU 106, der OFA 102, der Video-Kodierer/Dekodierer 112 und die Anzeigeschnittstelle 114, können an die Einzelbild-Pufferschnittstelle 110 angeschlossen werden, um auf den EinzelbildPuffer zuzugreifen.
  • Die CPU 108 steuert die Verarbeitung im System 100 und kann mit der GPU 106 verbunden sein. Die CPU 108 und die GPU 106 können mit einem Speicher-Controller 116 verbunden sein, um auf einen externen Speicher zuzugreifen.
  • In einem Ausführungsbeispiel, wenn das System 100 z.B. in einer Automobilanwendung verwendet wird, kann das eingehende Video von einer oder mehreren Kameras, die am Automobil (oder einem anderen Fahrzeug) angebracht sind, durch den VideoKodierer/Dekodierer 112 empfangen werden, der das Video decodiert und die Videobilder über die Einzelbildpuffer-Schnittstelle 110 in den Einzelbildpuffer (nicht gezeigt) schreibt. Die Video-Einzelbilder werden dann von dem OFA 102 aus dem Einzelbildpuffer erhalten, um den optischen Fluss und/oder die Stereodisparität zu erzeugen, die der GPU 106 über den EinzelbildPuffer zur Verfügung gestellt wird. Die GPU 106 kann den erzeugten optischen Fluss für die weitere Verarbeitung in einer beliebigen Anwendung verwenden, wie z.B., aber nicht beschränkt auf, Objekterkennung und/oder -verfolgung und/oder Deep Learning.
  • 2 zeigt eine logische Ansicht auf hoher Ebene der Beschleunigungsfunktionen für den optischen Fluss und die Stereodisparität, die von einem System wie dem in 1 gezeigten System 100 bereitgestellt werden, gemäß einigen Ausführungsbeispielen.
  • Die Funktionalität für den optischen Fluss des Systems 100 umfasst mehrere Betriebsmodi: eine Generierung eines allgemeinen optischen Flusses 202, eine Generierung eines optischen Flusses der statischen Welt 204, eine Generierung einer Stereodisparität 206 und eine Fusionsgenerierung des optischen Flusses 208, die allgemeine optische Flüsse und optische Flüsse der statischen Welt kombiniert, um einen kombinierten optischen Fluss / eine kombinierte Stereodisparität zu erzeugen. In den gezeigten Ausführungsbeispielen wird der SGM-Algorithmus als Kernregularisierer verwendet, zur Glättung der Abgleichskosten, und um den optischen Fluss in jedem Modus des optischen Flusses und/oder der Stereodisparität zu bestimmen.
  • Der allgemeine optische Fluss 202 umfasst eine Pyramidenerzeugungsstufe 210, eine Abschätzungsstufe 212 der vollständigen Bewegung und eine Nachbearbeitungsstufe 214 für den allgemeinen optischen Fluss. Die Abschätzungsstufe 212 der vollständigen Bewegung verwendet eine SGM-Technik, die ausgebildet ist, um eine oder mehrere Schichten der in Stufe 210 erzeugten Bildpyramide zu verwenden. Die in Stufe 212 verwendete, ausgebildete SGM-Technik kann aufgrund der pyramidenförmigen Verarbeitung der Eingabebilder als „pyramidales SGM“ bezeichnet werden. In einigen Ausführungsbeispielen werden die Stufen 210 und 214 in Software ausgeführt, während die Stufe 212 in Hardware wie dem OFA 102 ausgeführt wird. Die für die Stufen 210 und 214 erforderliche Befehlsausführung kann von GPU 106 und/oder Grafik-Host 104 ausgeführt werden. Ein Beispiel für die allgemeine Verarbeitung des optischen Flusses gemäß einigen Ausführungsbeispielen wird in Bezug auf 11 nachfolgend beschrieben.
  • Der optische Fluss der statischen Welt 204 umfasst eine Stufe 216 zum Abschätzen der Eigenbewegung, eine Stufe 218 zum Abschätzen der Bewegung der statischen Welt und eine Stufe 220 zur Nachbearbeitung des optischen Flusses der statischen Welt. Wie ebenfalls oben erwähnt, bezieht sich der Begriff „Eigenbewegung“ auf die 3D-Bewegung der Kamera in der Umgebung. In einigen Ausführungsbeispielen wird die Eigenbewegung durch Abschätzen der Bewegung der Kamera in Bezug auf die starre Szene basierend auf einer von der Kamera aufgenommenen Bildsequenz bestimmt. Die Abschätzungsstufe der Bewegung der statischen Welt 218 verwendet eine für zweidimensionale epipolare Bewegung ausgebildete SGM-Technik. Die in Stufe 218 verwendete, ausgebildete SGM-Technik kann als „epipolare SGM“ bezeichnet werden. Die Stufen 216 und 220 können mit Software durchgeführt werden, während Stufe 218 in Hardware wie der OFA 102 durchgeführt werden kann. Die in den Stufen 216 und 220 erforderliche Befehlsausführung kann von GPU 106 und/oder Grafik-Host 104 ausgeführt werden. Ein Beispiel für die Verarbeitung des optischen Flusses der statischen Welt wird nachfolgend in Bezug auf 9-10 beschrieben.
  • Die Stereodisparität 206 umfasst eine Stufe 222 zum Abschätzen der horizontalen Bewegung und eine Stufe 224 zur Nachbearbeitung der Stereodisparität. Stufe 222 kann für die Verwendung der epipolaren SGM-Technik zur Bestimmung der horizontalen Bewegung konfiguriert sein und wird in Hardware wie dem OFA 102 durchgeführt. Die Stufe 224 kann in Software ausgeführt werden. Die für Stufe 224 erforderliche Befehlsausführung kann von einer GPU 106 und/oder einem Grafik-Host 104 ausgeführt werden. Ein Beispiel für die Verarbeitung von Stereodisparitäten gemäß einigen Ausführungsbeispielen wird in Bezug auf 12 nachfolgend beschrieben.
  • Der fusionierte optische Fluss 208 umfasst eine Stufe 226 zum Abschätzen der Eigenbewegung, eine Stufe 228 zum Abschätzen der Bewegung der statischen Welt, eine Stufe 230 zur Erzeugung von Pyramiden, eine Stufe 232 zum Abschätzen der vollständigen Bewegung, eine Stufe 234 zur Fusion und eine Stufe 236 zur Nachbearbeitung des optischen Flusses der Fusion. Die Stufen 226, 228, 230 und 232 können jeweils identisch mit den Stufen 210, 212, 216 und 218 sein.
  • Die Fusionsstufe 234 empfängt den optischen Fluss aus der Abschätzungsstufe der Bewegung der statischen Welt 228 und der Abschätzungsstufe der vollständigen Bewegung 232 und kombiniert sie zu einem fusionierten optischen Fluss, wobei der Hintergrund durch die Abschätzung der Bewegung der statischen Welt (z.B. unter Verwendung epipolarer SGM) und der Vordergrund (einschließlich bewegter Objekte) durch eine Abschätzung der vollständigen Bewegung (z.B. unter Verwendung pyramidaler SGM) bestimmt wird. Die Fusion kann basierend auf einem Fusionieren der erzeugten Karten des optischen Flusses unter Verwenden der zugehörigen Disparitäts/Kostenkarte erfolgen. In einigen Ausführungsbeispielen kann für die Fusion eine Technik wie kostenbasierte Winner-Takes-All oder kostenbasierte Segmentierung verwendet werden. Das Ergebnis der Fusionsstufe 234 kann einen optischen Fluss umfassen, bei dem der Vordergrund auf pyramidalem SGM basiert und der Hintergrund auf epipolarem SGM, sowie die entsprechende Segmentierungskarte. Die Flusskarten, die in die Fusionsstufe eingegeben werden, können in einigen Ausführungsbeispielen durch ein sequentielles Durchführen eines optischen Flusses der statischen Welt und eines allgemeinen optischen Flusses erzeugt werden. In einigen Ausführungsbeispielen können die Input-Flusskarten jedoch durch ein gleichzeitiges Ausführen des statischen optischen Flusses und des allgemeinen optischen Flusses erzeugt werden. Die Fusionsstufe 234 und die Nachbearbeitungsstufe für den optischen Fluss der Fusion 236 können in Software ausgeführt werden, z.B. durch die GPU und/oder den Grafik-Host. Ein Beispiel für die Verarbeitung des fusionierten optischen Flusses gemäß einigen Ausführungsbeispielen wird in Bezug auf 13 nachfolgend beschrieben.
  • 3A zeigt ein Beispiel für die Disparität in Stereobildern, die von derselben Szene aufgenommen wurden. zeigt ein Objekt 304 in einer Szene, wie es von einer linken Kamera (in einem linken Bild 306) und einer rechten Kamera (in einem rechten Bild 308) aufgenommen wurde. zeigt die Diskrepanz zwischen dem linken und rechten Bild. Zum Beispiel ist das im linken Bild gezeigte Pixel 310 die Oberkante des Objekts 304, wie es im linken Bild aufgenommen wurde, aber das Bild des Objekts 304 im rechten Bild ist nach rechts gegenüber den x,y-Koordinaten von Pixel 310 verschoben. Die entsprechende x,y-Position 310' im rechten Bild hat einen anderen Inhalt als die x,y-Position 310 im linken Bild. Eine Stereodisparitätskarte repräsentiert für jedes Pixel in einem linken Bild (z.B. Basisbild) die beobachtete Verschiebung (Disparität) der Pixel im rechten Bild (Referenzbild) oder umgekehrt. Da die scheinbare Verschiebung in einem Pixel zwischen linken und rechten Stereobildern umgekehrt proportional zur Tiefe des im Pixel repräsentierten Orts oder Objekts ist. Eine „Disparitätskarte“ repräsentiert Disparitäten zwischen Bildern, Stereo- oder anderen Bildern. In einigen Fällen kodiert die Disparitätskarte die Disparität jedes Pixels in einem Grau- (oder Farb-) Wert. Beispielsweise kann die Beispielkodierung von Disparitäten dazu führen, dass eine Disparitätskarte dunklere Grautöne für kleine Disparitäten und hellere Grautöne für größere Disparitäten aufweist. Die Disparitätskarte enthält ausreichende Informationen zur Erzeugung eines 3D-Modells der Szene.
  • 3B zeigt ein Beispiel für die epipolare Beziehung zwischen zwei Kameras (linke Kamera 328 Position und rechte Kamera 330 Position). Für jeden Punkt in einem von einer Kamera aufgenommenen Bild ermöglicht die epipolare Beziehung zwischen dieser Kamera und einer anderen Kamera die Bestimmung des entsprechenden Punktes in einem von der anderen Kamera aufgenommenen Bild. Bei zwei Kameras, wie z.B. den Kameras 328 und 330, ergibt der Schnittpunkt zwischen der Verbindungslinie zwischen den beiden Kameras und den Bildebenen die jeweiligen Epipole. In 3B ist e der Epipol der Kamera 328 und e' ist der Epipol der Kamera 330. Dann ist in Bezug auf Kamera 328 und eine beliebige der Objekt-X-Positionen im 3D-Raum die Epipollinie auf dem von Kamera 330 aufgenommenen Bild l'. Das heißt, unter Berücksichtigung von x, dem Pixel in der Bildebene von Kamera 328, das jeder beliebigen gezeigten X-Position im 3D-Raum entspricht, ist gewährleistet, dass das entsprechende Pixel auf der entsprechenden Epipollinie l' 326 in Bild 322 zu finden ist. Ebenso kann in Bild 320 das Pixel, das einem beliebigen der Pixel x' in Bild 322 entspricht, auf der entsprechenden (konjugierten) Epipolarlinie 1324 gefunden werden.
  • 3C zeigt ein Beispiel einer Bildpyramidenstruktur (als „Gauß-Pyramide“ bezeichnet), die gemäß einigen Ausführungsbeispielen für Berechnungen des optischen Flusses verwendet wird. Da SGM-Berechnungen ressourcenintensiv sein können, erzeugen einige Ausführungsbeispiele eine Bildpyramide mit unterschiedlichen Auflösungsstufen für jedes der beiden zu vergleichenden Bilder. Die gezeigten Pyramiden 340 und 342 sind für Bild It bzw. It+i, für die der optische Fluss bestimmt werden soll. Das Bild 344, auf der niedrigsten Stufe (z.B. Stufe 0), kann die höchste (volle) Auflösung haben, und jede höhere Stufe (z.B. Stufen L-1, L) kann eine niedrigere Auflösung haben.
  • Während der Verarbeitung kann die Verarbeitung des optischen Flusses zunächst auf der höchsten Stufe (niedrigste Auflösung) zu den geringsten Kosten erfolgen und auf jeder nachfolgenden Stufe in den Pyramiden fortgesetzt werden. Tiefpassfilterung und Unterabtastung (engl. sub-sampling), die auf dem Ergebnis jeder Stufe implementiert werden, können verwendet werden, um die Berechnungsanforderungen auf der nächstfolgenden Stufe zu verringern, z.B. durch Hinweise auf bestimmte Bereiche, die eine Verarbeitung auf den höheren Auflösungsstufen erfordern.
  • Beschleuniger für einen optischen Fluss (OFA)
  • 4 zeigt schematisch die Schaltungsanordnung eines Beschleunigers für einen optischen Fluss wie z.B. des OFA 102 in 1, gemäß einigen Ausführungsbeispielen. In 4 ist der OFA 400 mit einem Grafik-Host 402 wie z.B. dem Grafik-Host 104 verbunden.
  • Die OFA 400 Schaltungsanordnung umfasst einen Mikrocontroller 404, eine Einzelbildpuffer-Schnittstelle 406, einen SGM-Block 408, einen Cost Volume Constructor (CVC)-Block 410, einen Referenz-Pixel-Cache (RPC)-Block 412, einen Referenz-Pixel-Abruf (RPF)-Block 414, einen Aktuelles-Pixel-Abruf (CPF)-Block 416 und einen DMA-Block 418.
  • Der Mikrocontroller 404 in dem OFA 400 verbindet sich mit dem Host 402, von dem er Anweisungen und Daten erhält. Der Mikrocontroller 404 verbindet auch mehrere Komponenten im OFA 400, um die Operationen im OFA gemäß den vom Host 402 erhaltenen Anweisungen zu steuern.
  • Der Mikrocontroller 404 verfügt über Schnittstellen für Signale wie z.B. Kontextwechsel-Signale, Mikrocode für bestimmte Befehle, Adressen und andere Daten, Privilegienbus und eine Interrupt-Schnittstelle mit dem Host 402. Er verarbeitet den Mikrocode, die Adresse, die Daten und/oder andere empfangene Signale und steuert den Rest der OFA. Er führt auch die Fehlerbehandlung durch und kann weitere Aufgaben wie z.B. die Geschwindigkeitssteuerung und allgemeines (z.B. auf Makroblock-Stufe) Housekeeping, Verfolgung und Konfiguration der Modusentscheidung übernehmen.
  • Die Einzelbildpuffer-Schnittstelle 406 ermöglicht dem OFA 400 das Lesen von und Schreiben in einen Einzelbildpuffer. Beispielsweise können Daten wie die in den OFA eingegebenen Einzelbilder über die Einzelbildpuffer-Schnittstelle 406 gemäß den vom Mikrocontroller 404 empfangenen Steuersignalen in den OFA eingelesen werden. Die optischen Flüsse und Disparitätskarten, die als Ausgabe von dem OFA 400 erzeugt werden, können über die Einzelbildpuffer-Schnittstelle 406 in den Einzelbildpuffer geschrieben werden.
  • Der SGM-Block 408 umfasst Schaltungsanordnungen für 1D- und/oder 2D-SGM-Operationen, historische und/oder zeitliche Pfadkostengenerierung und Gewinnerentscheidung. Block 408 kann auch Aspekte der Nachbearbeitung unterstützen. Gemäß einigen Ausführungsbeispielen umfasst die SGM-Schaltungsanordnung Unterstützung für drei verschiedene Arten der Suche nach Pixelunterschieden (Disparitäten), z.B. entlang horizontaler Linien, entlang epipolarer Linien und innerhalb eines rechteckigen Bereichs, auf den ein „Hinweis“ zeigt (z.B. eine feste 23x11-Pixel-Suchregion um einen vom CPF-Block 416 gelieferten Hinweis). SGM wird beschrieben in Hirschmuller, H., „Stereo Processing by Semi-Global Matching and Mutual Information“, Pattern Analysis and Machine Intelligence, 2008 („Hirshmuller 2008“), das durch Verweis in seiner Gesamtheit aufgenommen wird. Eine Implementierung von SGM in einer FPGA-basierten Implementierung wird beschrieben in Stefan K. Gehrig et al, „A Real-Time Low-Power Stereo Vision Engine Using Semi-Global Matching“, International Conference on Computer Vision System, 2009.
  • Der SGM-Block 408 kann so konfiguriert sein, dass das 1D/2D-SGM entlang einer konfigurierbaren Anzahl von Pfaden (z.B. 4 oder 8 Pfade) durchgeführt werden kann. Die SGM-Verarbeitung kann auch für verschiedene Disparitätsstufen (z.B. 128 oder 256 Disparitäten) für Stereo-SGM und epipolares SGM konfiguriert sein. Der Parameter „Disparitätsstufen“ definiert den für das Matching verwendeten Suchraum. Das heißt, wenn die Disparitätsstufe d ist, werden für jedes Pixel p im Basisbild d Pixel im Referenzbild nach Übereinstimmungen gesucht, wodurch d mit p assoziierte Disparitätsstufen erzeugt werden.
  • Der SGM-Block 408 kann in einigen Ausführungsbeispielen zusätzlich beliebige oder keines von einer gleichwinkligen Subpixel-Interpolation, adaptiven Glättungsstrafen sowie eSGM- und Wellenfrontverarbeitung (z.B. zur Bandbreiteneinsparung) implementieren. Die gleichschenklige Subpixel-Interpolation kann zur Subpixelverfeinerung durchgeführt werden und kann in einigen Ausführungsbeispielen basierend auf einem Konfigurationsparameter aktiviert oder deaktiviert werden.
  • Die SGM-Implementierung in dem OFA 400 bietet zusätzlich eine einheitliche Architektur sowohl für den SGM-basierten optischen Fluss als auch für die Stereodisparität und bietet eine konfigurierbare Skalierbarkeit zwischen Qualität und Leistung. Die SGM-Implementierung kann auch eine konfigurierbare Bewegungsvektor-/Disparitätsgranularität (z.B. mindestens 1×1 bis maximal 8x8), eine konfigurierbare Anzahl von Disparitätsstufen und einen Suchbereich und/oder eine Kostenberechnung bei der ursprünglichen Auflösung vorsehen, um die Matching-Präzision zu erhalten.
  • Der SGM-Block 408 ist für die Anwendung von SGM auf 2D-Flächen ausgebildet, um u.a. Vordergrund-Objekte und Bewegungen genauer und zuverlässiger zu erkennen. Es wird ein pyramidaler Ansatz implementiert, um die Komplexität der Anwendung von SGM in 2D zu reduzieren und die Hardware-Implementierung der Technik zu erleichtern. Die SGM-Implementierung kann in einigen Ausführungsbeispielen auch einen Wellenfrontverarbeitungsmodus (engl. wavefront processing mode) und eSGM umfassen, was die erforderliche Bandbreite drastisch reduzieren kann. In einigen Ausführungsbeispielen wird eSGM weiter verfeinert, um eine 1,5-fache Verbesserung der Leistung im Vergleich zum ursprünglichen eSGM zu erreichen. Die reduzierte Kostenpräzision kann in einigen Ausführungsbeispielen verwendet werden, um die erforderliche Datenpfadbreite ohne merkliche Qualitätseinbußen zu verringern.
  • Der CVC (Kostenvolumen-Konstruktor, engl. Cost Volume Constructor) Block 410 umfasst eine Schaltungsanordnung zur Erzeugung des den Eingabebildern entsprechenden Kostenvolumens. Das „Kostenvolumen“ (auch „Matching-Kostenvolumen“ oder Abgleichskostenvolumen genannt) ist ein dreidimensionales Array, in dem jedes Element die Abgleichskosten eines Pixels auf einer bestimmten Disparitätsstufe repräsentiert. Das in 6 gezeigte Kostenvolumen 618 ist ein Beispiel.
  • Der CVC-Block 410 ist für zwei Hauptfunktionen konfiguriert: Durchführen einer Censustransformation (engl. census transform, z.B. 5x5 Censustransformation) sowohl für aktuelle als auch für Referenzpixel und Berechnen der Hamming-Distanz zwischen aktuellen und Referenzpixel-Censustransformationsdatenblöcken (CT-Datenblöcke).
  • Der Aktuelle-Pixelabruf (CPF)-Block 416 dient dazu, das nächste auszuwertende Pixel zu erhalten. Der Referenzpixel-Cache-(RPC-)Block 412 und der Referenz-Pixelabruf-(RPF-)Block 414 dienen dazu, die Referenzpixel zu erhalten und zu speichern, die jedem durch den CPF-Block abgerufenen Pixel entsprechen. Der RPC ist der Cache zum Speichern von Referenzpixeln und kann die Speicherbandbreite aufgrund des Referenzpixelabrufs verringern. Die RPC akzeptiert die Abrufanforderung vom RPF, holt die Referenzpixel aus dem externen Speicher und gibt den Referenzpixelblock an den CVC-Block aus.
  • Der CPF-Block 416 umfasst Schaltungsanordnungen zum Abrufen des aktuellen Pixels und, falls zutreffend, zum Abrufen des Hinweises. Obwohl der CPF-Block 416 beispielsweise hauptsächlich für das Abrufen des aktuellen Pixels vorgesehen ist, ist der CPF-Block 416 in einigen Ausführungsbeispielen auch so konfiguriert, dass er den entsprechenden Hinweis abruft (z.B. Angabe der auszuwertenden Bereiche), wenn sich der OFA im Modus des optischen Flusses mittels pyramidalem SGM befindet. In einigen Ausführungsbeispielen kann der CPF-Block 416 aufgrund der Zickzack-Verarbeitung des OFA (siehe 8B) so konfiguriert sein, dass er die aktuellen Pixel in einer Reihenfolge abruft, die diesem Muster entspricht. In einigen Ausführungsbeispielen umfasst das Abrufen des aktuellen Pixels das Abrufen eines aktuellen Pixelblocks von einer Größe wie z.B. 9x9 Pixel. Das heißt, aufgrund von OFA-Funktionen wie der OFA 5x5-Censustransformation und der OFA 5x5-Kostenaggregation kann das Abrufen eines Blocks mit einer Größe wie 9x9 für jedes aktuelle Pixel erforderlich sein.
  • Der DMA-Block 418 kann eine separate Schaltungsanordnung für die DMA verschiedener Daten umfassen. Jeder DMA kann so konfiguriert sein, dass er das Laden oder Speichern eines bestimmten Datensatzes vom Mikrocontroller und/oder anderen Schaltungsblöcken übernimmt. Der OFA kann über mehrere DMAs verfügen, einschließlich des aktuellen DMA, der aktuelle Pixeldaten abruft; des Hinweis-DMA, der Hinweis-Bewegungsvektordaten abruft; des Gewinner- und Ausgabe-DMA, der Fluss/Disparitäten und Kosten an temporäre/historische Puffer ausgibt, die temporäre Pfadkosten/Kandidaten-Informationen lesen/schreiben, die vom SGM-Block oder einem anderen Speicher benötigt werden. Gemäß einem Ausführungsbeispiel ist der aktuelle Pixel-DMA ein Nur-Lese-DMA und ermöglicht es dem SGM-Block, Abrufanforderungen von 32x8 Pixeln zu unterstützen, der Hinweis-DMA ist ein Nur-Lese-DMA und unterstützt Abrufanforderungen von Bewegungsvektoren der Größe 8x8 (z.B. 32x8 Bytes), der Gewinner-DMA für den Fluss und der Gewinner-DMA für die Kosten sind jeweils als Nur-Schreib-DMA konfiguriert und unterstützen Schreibanforderungen der Größe 32x8 Bytes.
  • Wie ebenfalls oben erwähnt, können die Zielanwendungen für den OFA 400 Aufgaben der Computer Vision auf niedriger Ebene umfassen, wie z.B. ADAS und DL-basierte Videoinferenzierung. Um die End-to-End-Systemlatenz für ADAS-Anwendungen zu reduzieren, können große Probleme, wie z.B. die Verarbeitung eines 2-8-Megapixel-Bildes durch eine Anwendung, die aus einer langen Kette von Algorithmusschritten besteht, in einigen Ausführungsbeispielen typischerweise räumlich in Subframes aufgeteilt werden, um zwischen SoC-Komponenten mit kürzerer Latenz zu synchronisieren.
  • Das allgemeine Programmiermodell für den OFA ähnelt dem vieler hostbasierter Engines wie Hardware-Videodecoder und -Encoder. In einigen Ausführungsbeispielen umfasst das Programmiermodell die Treibersoftware (die auf einem Prozessor wie der CPU 108 oder GPU 106 ausgeführt wird), die die Bildflächen zuweist und die erforderlichen Eingabeinformationen vorbereitet und dann den Mikrocontroller der OFA startet (z.B. Mikrocontroller 404 der OFA 400). Mikrocode auf dem Mikrocontroller kann die Eingabeinformationen/-befehle parsen und Hardwareregister konfigurieren und dann den OFA anstoßen (d.h. initiieren oder auslösen), um die durch die Eingabeinformationen/-befehle erforderliche Verarbeitung durchzuführen.
  • Wenn der OFA ausgelöst wird (z. B. durch den Mikrocontroller auf Befehl des Treibers), startet zuerst der CPF-Block 416 und sendet den Befehl an den RPF-Block 414. Der RPF-Block 414 überträgt den Befehl an den CVC-Block 410 und startet den RPC-Block 412 für den Referenzpixelabruf. Wenn Referenzpixel und aktuelle Pixel bereit sind, berechnet der CVC-Block 410 die Kosten und sendet sie an den SGM-Block 408. Der SGM-Block 408 trifft die Entscheidungen und sendet seine Ergebnisse an den DMA-Block 418. Der DMA-Block 418 bearbeitet alle Anfragen der internen Einzelbildpuffer-Schnittstelle 406 mit den richtigen Formaten.
  • Der OFA kann so konfiguriert sein, dass er einen Interrupt an den Mikrocontroller ausgibt, sobald er einen Durchlauf der SGM-Verarbeitung abgeschlossen hat. Der Mikrocode im Mikrocontroller kann die abgeschlossenen SGM-Durchläufe verfolgen und kann so konfiguriert sein, dass er dem Treiber den Status des abgeschlossenen Einzelbildes (Frames oder Subframes) meldet, so dass der Treiber den nächsten Kickoff des Einzelbildes (Frames oder Subframes) steuern kann.
  • Der OFA kann in bestimmten Ausführungsbeispielen Eingabebilder und Output Flow Maps beliebiger Größe unterstützen. Einige Ausführungsbeispiele unterstützen beliebige Bildgrößen zwischen 32x32 Pixeln und 8192x8192 Pixeln als Eingabe, und die Größe der Ausgabe-Flusskarate oder der Disparitätskarte kann auf der Größe des Eingabebildes und der Gittergröße basieren. Zum Beispiel kann die Höhe der Ausgabe-Flusskarte auf der Basis von (K x Gittergröße y) multipliziert mit der Höhe des Eingabebildes basieren, und die Breite der Ausgabe-Flusskarte kann auf der Breite des Eingabebildes multipliziert mit (K x Gittergröße x) basieren, wobei K (z.B. K=1 oder 2) konfigurierbar sein kann, um Downsampling zu aktivieren/deaktivieren. In einigen Ausführungsbeispielen kann die Größe der Höhe/Breite des Eingabehinweises (z.B. im pyramidalen SGM-Modus) auf der Höhe/Breite des Eingabebildes und der Gittergröße basieren und in ähnlicher Weise auf der Basis von K konfigurierbar sein.
  • 5 zeigt schematisch eine Schaltungsanordnung des CVC-Blocks 410 des OFA, gemäß einigen Ausführungsbeispielen. Wie oben erwähnt, ist der CVC-Block 410 so konfiguriert, dass er das Kostenvolumen (z.B. das Entsprechungskostenvolumen 618) für die Bestimmung des optischen Flusses und der Stereodisparität erzeugt. Der CVC-Block 410 führt die Censustransformation (z.B. 5x5-Pixel-Censustransformation) sowohl für das aktuelle Pixel als auch für das Referenzpixel durch und berechnet den Abstand (z.B. Hamming-Distanz) zwischen aktuellen und Referenz-CT-Datenblöcken.
  • Gemäß einigen Ausführungsbeispielen umfassen die Verarbeitungsstufen im CVC 410 einen CT & HD-Block 502, einen Aggregations- (AGG) Block 504, einen Kostenarray-FIFO-Block 506, einen Selektionsinformations-FIFO-Block 510 und einen Kostenselektions-(CVS) Block 508.
  • Der CT&HD Block 502 führt Censustransformations- und Hamming-Distanzberechnungen durch. Die Censustransformation (CT) ist eine robuste Patch-Darstellung, die von Zabih und Woodfill in „Non-parametric Local Transforms for Computing Visual Correspondence‟, in Proceedings cf the Third European Conference-Volume II on Computer Vision (ECCV ‚94), Jan-Olof Eklundh (Hrsg.), Vol. II, Springer-Verlag, London, UK, 151-158, eingeführt wurde, die hiermit in seiner Gesamtheit aufgenommen wird. Die Censustransformation R(P), die in einigen Ausführungsbeispielen verwendet werden kann, ist eine nichtlineare Transformation, die eine lokale Nachbarschaft, die ein Pixel p umgibt, auf einen binären String abbildet, der die Menge benachbarter Pixel repräsentiert, deren Intensität geringer ist als die von P. Jede Censusziffer ξ(P,P‘) ist durch die folgende Beziehung definiert: ξ ( P , P ' ) = { 0, P > P ' 1, P P '
    Figure DE102020122943A1_0001
  • Das heißt, für ein Pixel p wird jedes Pixel P' in seiner Nachbarschaft als eine 1 oder eine 0 repräsentiert, basierend darauf, ob P' größer oder gleich bzw. kleiner als p ist. Die Größe der lokalen Nachbarschaft von Pixel p für die Censustransformation kann konfigurierbar sein. Basierend auf einem Kompromiss zwischen Ausgabequalität und Chipfläche für die OFA-Schaltungsanordnung, in einigen Beispielausführungsanordnungen, wird in dem OFA eine 5x5 Censustransformation verwendet.
  • Für jedes Pixel p wird die Censustransformation der binären Strings, die den Satz benachbarter Pixel für zwei Bilder repräsentieren, dann der Bestimmung der Hamming-Distanz (HD) unterzogen. Die HD ist eine Entfernungsmetrik, die zur Messung der Differenz von zwei Bitkettenwerten verwendet wird. Im Zusammenhang mit der CT ist die HD die Anzahl der unterschiedlichen Bits in zwei CT-Strings. Die HD für Pixel p kann durch XOR-Kombination der zwei Bitketten bestimmt werden.
  • Während jedes Pixel in einem Basisbild als aktuelles Pixel für die Verarbeitung erhalten wird, empfängt der CT&HD-Block 502 einen aktuellen Pixelblock (z.B. einen 5x5 Pixelblock mit dem aktuellen Pixel p als Zentrumspixel) aus dem Basisbild, wie es durch den CPF-Block 416 erhalten wird, und einen Referenzpixelblock (z.B. einen Pixelblock mit dem Referenzpixel p' als Zentrumspixel) aus dem Referenzbild, das aus dem RPC-Block 412 abgerufen wird. Der Referenzpixelblock kann die Größe WxH haben, wobei W und H so gewählt werden können, dass die Anzahl der Pixel im Datenblock der Anzahl der Disparitätsstufen entspricht, so dass WxH = d ist. Die dem aktuellen Pixel entsprechenden Referenzpixel können im RPC-Block 412 zwischengespeichert werden, wenn der RPF-Block 414 veranlasst wird, das entsprechende Referenzpixel durch den CPF-Block 416 abzurufen, der den RPF-Block 414 mit dem aktuellen Pixel und/oder dem aktuellen Pixel-Bewegungsvektorhinweis (in pyramidaler SGM) oder Informationen davon versorgt. Der CPF-Block 416 und der RPC-Block 412 können die Pixel und/oder Pixeldaten aus einem Einzelbildpuffer über die Einzelbildpuffer-Schnittstelle 406 auslesen.
  • So verarbeitet der CT&HD-Block 502 jedes Pixel eines aktuellen Basisbildes, indem er die entsprechenden aktuellen und Referenzpixelblöcke aus dem CPF-Block 416 bzw. dem RPC-Block 412 empfängt. Der aktuelle Pixelblock für Pixel p kann ein 5x5-Pixelblock sein, wie z.B. der Pixelblock 602 in 6, mit p als Zentrumspixel. Der aktuelle Pixelblock kann der Censustransformation unterzogen werden und, wie in 6 gezeigt, in einen Block 604 aus 1s und 0s und weiter in eine Bitkette 606 umgewandelt werden. Nachdem es der Censustransformation unterzogen wurde, wird das aktuelle Pixel p also durch eine Bitkette (engl. bit string) repräsentiert, die seiner Nachbarschaft entspricht (z.B. wie die 5x5-Nachbarschaft in diesem Beispiel).
  • Bei der Verarbeitung des Referenzpixelblocks für das Pixel p kann der CT&HD-Block 502 eine censustransformierte Bitkette für jedes Pixel p' im WxH-Pixel-Referenzpixelblock erzeugen.
  • Die HD-Schaltungsanordnung in Block 502 berechnet für jedes Pixel p' im Referenzpixelblock ein bitweises XOR der censustransformierten Bitketten (oder der censustransformierten Bitketten nach der Aggregation in Block 504) für das aktuelle Pixel p und das Referenzpixel p', um die jedem p' entsprechende Hamming-Distanz zu bestimmen. Um d Disparitätsstufen für das aktuelle Pixel p zu erzeugen, werden im Block 502 d Hamming-Distanz-Berechnungen durchgeführt. Die Abgleichskosten für d Disparitätsstufen bei einer gegebenen Pixelposition p im Basisbild werden durch Berechnung der Hamming-Distanz mit d Pixeln im Referenzbild berechnet. Die Abgleichskosten, C(p,a), werden an jeder Pixelposition, p, für jede Disparitätsstufe, d, berechnet, wobei 1 ≤ d ≤ D.
  • Die Kostenaggregation in Aggregationsblock 504 wird in einigen Ausführungsbeispielen verwendet, um die Robustheit des Abgleichs (engl. matching) zu verbessern. Kostenaggregation kann erwünscht sein, da Kosten auf der Basis von Einzelpixeln mehrdeutig und/oder fehlerhaft sein können. Um die Kostenaggregation durchzuführen, werden die Kosten der Nachbarpixel zum Zentrumspixel addiert (d.h. summiert). In einigen Ausführungsbeispielen können die summierten Pixelkosten am mittleren Pixel gemittelt werden, um die Kostenbreite zu reduzieren (d.h. die Anzahl der Bits zu reduzieren, die die summierten Kosten repräsentieren). Die in der OFA verwendete Kostenaggregationsfenstergröße kann konfigurierbar sein. In einigen Ausführungsbeispielen beträgt das Kostenaggregationsfenster 5x5 Pixel. Die Kostenaggregation kann auf jedes Referenzpixel p' nach den berechneten Disparitäten angewendet werden (z.B. durch Hamming-Distanzberechnungen, wie in Bezug auf Block 502 beschrieben), um die Anpassungskosten für jedes Pixel p' anzupassen. Zusätzlich oder alternativ kann die Kostenaggregation auf die censustransformierten Bitketten für jedes p' vor der Berechnung der Disparitäten durchgeführt werden und folglich die jeweiligen Referenzpixel-Bitketten gemäß ihrer Nachbarschaft (z.B. ein 5x5-Aggregationsfenster mit Referenzpixel p' als Zentrumspixel) anpassen, bevor sie der Hamming-Distanzberechnung mit der censustransformierten Bitkette des aktuellen Pixels p unterzogen werden.
  • Der Kosten-Array-Block 506 erhält die Abgleichkosten für die Referenzpixelp' aus dem Aggregationsblock 504, oder in einigen Ausführungsbeispielen direkt aus dem CT&HD-Block 502. Der Block 506 kann einen FIFO-Speicher (first-in-first-out) implementieren, um die empfangenen Bitketten zu speichern.
  • Der Kostenvolumen-Auswahlblock 508 empfängt die Kostenfelder für jedes aktuelle Pixel p und liefert die Kosten wie vom SGM-Block gefordert. Aufgrund des unregelmäßigen Suchmusters im epipolaren SGM-Modus des optischen Flusses kann die Kostenberechnung (z.B. im Kostenvolumen-Auswahlblock 508) über einen 16x16-Pixel-Block durchgeführt werden. Dann werden die Kosten an gültigen Positionen ausgewählt und gemäß dem Suchmuster an den SGM-Block 408 geschickt. Die Auswahl gültiger Positionen kann auf der Eingabe aus dem Selektionsinformations-FIFO-Block (SIF-Block) 510 basieren. Der SIF-Block 510 versorgt den SGM-Block 408 mit Bewegungsvektoren, die den aktuellen Pixeln entsprechen.
  • 6 zeigt ein Beispiel für einige Berechnungen, die vom CT und HD Block 502 durchgeführt werden, gemäß einigen Ausführungsbeispielen.
  • Der Pixelblock 602, der im Beispiel ein 5x5-Pixel-Block ist, kann der aktuelle Pixelblock sein, der abgerufen wird, wenn der CPF-Block 416 das Zentrumspixel x als aktuelles Pixel abruft. Der Wert jedes Pixels in dem abgerufenen Pixelblock kann einen Intensitätswert repräsentieren. Pixelblock 604 kann eine Darstellung des Pixelblocks 602 sein, nachdem er der Censustransformation unterzogen wurde, z. B. im CT&HD-Block 502. Wie oben erwähnt, wandelt die Censustransformation die Darstellung gemäß einer vorgegebenen oder konfigurierten Stufe der Schwellenintensität in eine binäre Darstellung um. Das eindimensionale Array 606 wird aus dem censustransformierten Block 604 abgeleitet, indem die Zeilen linear von oben nach unten angeordnet werden. 606 wird auch als Bitkette bezeichnet.
  • Die Arrays 610 und 612 repräsentieren Censustransformationsergebnisse für entsprechende linke bzw. rechte Stereobilder, entsprechend einem Beispiel. Array 610 kann als Sammlung von censustransformierten Ergebnissen (d.h. die eindimensionalen Bit-Arrays 606, die jedem Pixel des Bildes entsprechen) für jedes Pixel im linken Bild betrachtet werden. Ebenso kann Array 612 als die Sammlung censustransformierter Ergebnisse für jedes Pixel im rechten Bild betrachtet werden. 614 zeigt ein Beispiel für das aktuelle Pixel p mit seiner Bitfolge im linken Bild und ein Referenzpixel mit seiner Bitfolge im rechten Bild.
  • 616 zeigt die Berechnung der Hamming-Distanz, indem eine XOR-Operation an den censustransformierten Ergebnissen aus dem linken und rechten Bild durchgeführt wird. Die censustransformierten Ergebniswürfel 610 und 612 werden verglichen, um einen 3D-Unterschiedsraum („Abgleichkostenvolumen“ oder einfach „Kostenvolumen“) 618 zu erzeugen.
  • 7 ist ein schematisches Blockdiagramm eines Hardware-SGM-Blocks 408, gemäß einigen Ausführungsbeispielen. Bei dem OFA 400 ist der SGM-Block 408 die Untereinheit, die die Anpassungskosten vom CVC-Block erhält und die 1D/2D-SGM durchführt und die Nachbearbeitung der resultierenden Disparität (z.B. Gewinner-Disparität) durchführt. SGM ist ein auf dynamischer Programmierung basierender Algorithmus, der erstmals 2005 von H. Hirschmüller vorgeschlagen wurde (und auch in Hirschmüller 2008 beschrieben wurde, siehe oben) und für die Abschätzung von Stereodisparitäten verwendet wird. SGM und seine Varianten waren viele Jahre lang erstklassige Stereo-Algorithmen, bis zu den relativ neuen vorgeschlagenen DL-basierten Verfahren.
  • Die entsprechenden Kosten von dem CVC werden von einem Aktualisierungsblock 702 für Pfadkosten empfangen, der auch frühere Pfadkosten von einem Pfadkostenpuffer 704 erhält. Die vom Aktualisierungsblock 702 ausgegebenen Pfadkosten werden im Pfadkostenpuffer 704 gespeichert. Die Ausgabe von Pfadkosten-Aktualisierungsblock 702 wird auch dem Gewinner-Entscheidungsblock 706 zur Verfügung gestellt, der nach der Nachbearbeitung ebenfalls einen früheren Gewinnerwert erhält. Die Gewinnerentscheidung, die aus dem Gewinnerentscheidungsblock 706 ausgegeben wird, wird dem Nachbearbeitungsblock 708 zur Verfügung gestellt. Nach der Nachbearbeitung wird das Ergebnis an den Gewinner-Entscheidungsblock 706 und auch an den DMA-Block 718 zurückgegeben.
  • Die Hauptmerkmale, die vom SGM-Block 408 unterstützt werden, umfassen in einigen Ausführungsbeispielen die Unterstützung einer konfigurierbaren maximalen Anzahl von Disparitäten (z.B. 256 oder 128 Disparitäten, wobei die niedrigere Anzahl von Disparitäten für eine schnellere Leistung ausgewählt werden kann), die Unterstützung einer konfigurierbaren Anzahl von Richtungen, in denen die Abgleichkosten bewertet werden (z.B. 2/4/8: (horizontal + vertikal)/(horizontal + vertikal + links + rechts)/(horizontal + vertikal + links + rechts + diagonal)), und die Unterstützung einer konfigurierbaren Anzahl von SGM-Durchgängen (z.B. 1/2/3).
  • Eine Nachbearbeitung kann durchgeführt werden, um Fehler, die der Stereo-Algorithmus verursacht hat, zu beheben und ein dichtes Disparitätsbild ohne Lücken zu liefern. Die im SGM-Block durchgeführte Nachbearbeitung kann Subpixel-Interpolation, Konvertierung von VZ-Index in Bewegungsvektoren, Konvertierung von Disparitäten in Bewegungsvektoren usw. umfassen.
  • 8A zeigt beispielhafte Pfadrichtungen für SGM, die in einigen Ausführungsbeispielen verwendet werden können. In einigen Ausführungsbeispielen kann die Anzahl der Pfade 804, die bei der Bestimmung der Pfadkosten für ein Pixel p 802 berücksichtigt werden, konfigurierbar sein. Im gezeigten Einzelbild 806 können beispielsweise die mit dem Pixel p 802 assoziierten Pfadkosten basierend auf vier Pfaden (z.B. aufwärts L2, abwärts L6, links L0, rechts L4) oder acht Pfaden (z.B. L0-L7) bestimmt werden. Einige andere Ausführungsbeispiele verwenden möglicherweise eine andere Teilmenge der acht Pfade L0-L7 und/oder zusätzliche Pfade.
  • In einigen Ausführungsbeispielen ist das 1D-SGM, das im epipolaren Modus für den optischen Fluss verwendet wird, ein ID-SGM-Prozess, der derselbe wie im Stereofall ist. Der Input zu dieser Stufe ist das passende Kostenvolumen oder ein Teil davon, das von der Kostenvolumen-Konstruktionsstufe erzeugt wird, der Output ist die beste Disparität mit den minimalen aggregierten Pfadkosten aus allen Richtungen. Die Bestimmung der minimalen aggregierten ID-Pfadkosten umfasst ein Berechnen der aktuellen Kosten an der Disparitätsposition d unter Verwenden des Abgleichkostenwerts, der früheren Kostenwerte an den Disparitäten d-1, d und d+1 und des Minimums der früheren Kostenwerte.
  • 8B zeigt ein Beispiel für Pfadkosten-Update bei einem optischen Fluss mit 1D-SGM. Jedes Array 822, das die Pfadkosten L(p,a) und L(p-1,a) repräsentiert, umfasst d Pfadkosten. Die Notation L(p,a) repräsentiert die Pfadkosten entlang des Pfades L für Pixel p auf der Disparitätsstufe d. Das C(p)-Kosten-Array 820 zeigt entsprechende Abgleichkosten für Pixel p, für d Pixel, entlang eines Pfades.
  • In einigen Ausführungsbeispielen ergibt sich die Aktualisierung der Pfadkosten L für Pixel p entlang einer Richtung r für d Disparitätsstufen wie folgt: L r ( p , d ) = C ( p , d ) + S ( p , d ) m i n i L r ( p r , i )
    Figure DE102020122943A1_0002
    wobei S ( p , d ) = m i n { L r ( p r , d ) m i n L r ( p r , d ± 1 ) + P 1 m i n i L r ( p r , i ) + P 2
    Figure DE102020122943A1_0003
  • Grundsätzlich werden bei dieser rekursiven Berechnung, um die Pfadkosten L für ein Pixel p entlang eines Pfades r zu bestimmen, alle Pfadkosten des vorherigen Pixels entlang der Richtung r (repräsentiert als „ “) und zwei Strafterme P1 und P2 verwendet. Der erste Term (C(p,a)) ist die Summe aller Pixelabgleichkosten für die Disparitäten von d. Der zweite Term addiert eine konstante Strafe P1 für alle Pixel q in der Nachbarschaft Np von p, für die sich die Disparität ein wenig ändert (d.h. 1 Pixel). Der dritte Term fügt eine größere konstante Strafe P2 für alle größeren Disparitätsänderungen hinzu. Das Verwenden einer geringeren Strafe für kleine Änderungen erlaubt eine Anpassung an schräge oder gekrümmte Flächen. Die konstante Strafe für alle größeren Änderungen (d.h. unabhängig von ihrer Größe) bewahrt Diskontinuitäten. P1 und P2 werden in Bezug auf SGM-Techniken als Abgleichkosten-Glättungsstrafen (engl. Matching Cost Smoothing Penalties) bezeichnet.
  • Als Optimierungstechnik werden in einigen Ausführungsbeispielen neben der Speicherung aller Pfadkostenwerte auch die minimalen Pfadkosten der vorherigen Pixel in einem On-Chip-Puffer gespeichert, um eine Neuberechnung zu vermeiden miniLr(p - r, i).
  • Bestimmte Ausführungsbeispiele adaptieren die ursprünglich für die Suche entlang von ID-Pfaden ausgebildete SGM-Technik, um sie in 2D zu verwenden. Während z.B. Stereodisparität und epipolares SGM (z.B. im Modus des optischen Flusses der statischen Welt 204) die 1D-Implementierung von SGM im System 100 verwenden, basiert die pyramidale SGM-Implementierung (z.B. im Modus des optischen Flusses der allgemeinen Welt 202) auf einer 2D-Implementierung. 8C zeigt beispielhaft die Suchfenster 810 und 812 sowie Suchmuster, die für die Aktualisierung der Pfadkosten für ein Paar 814 von Pixeln p und p - 1 verwendet werden, und die entsprechende Pfadkostendatenstruktur 816. 8D zeigt, wie die Pfadkosten 826 für die Pixel p und p-1 in der 2D-Implementierung aktualisiert werden können. In der 2D-Implementierung ist das Kostenfeld C(p) 824 zweidimensional und entspricht dem 2D-Suchbereich, wie z.B. dem Suchfenster 810 oder 812. Eine der wichtigsten Änderungen von 1D zu 2D in SGM-Implementierungen in einigen Ausführungsbeispielen ist der Pfadkosten-Aktualisierungsteil (v entspricht einem Bewegungsvektor in der folgenden Gleichung), der wie folgt dargestellt werden kann: L r ( p , v ) = C ( p , v ) + S ( p , v ) m i n i L r ( p r , i )
    Figure DE102020122943A1_0004
    wobei S ( p , v ) = m i n { L r ( p r , v ) m i n v ^ v , R L r ( p r , v ^ ) + P 1 m i n i L r ( p r , i ) + P 2
    Figure DE102020122943A1_0005
  • Um die Komplexität der Hardware-Implementierung zu reduzieren, wird in einigen Ausführungsbeispielen das Suchfenster in x/y-Richtung auf 2/1 gesetzt, und v kann im Suchfenster ein Kandidatenbereich identifiziert werden.
  • Die SGM-Technik, wie sie in Hirschmüller 2008 vorgeschlagen wurde, erfordert eine Bandbreite für das Lesen/Schreiben des Abgleichkostenvolumens des zeitlichen Pfades, die für eine Hardware-Implementierung zu groß ist. Um dieses Problem zu lösen, implementieren einige Ausführungsbeispiele eine Variante der in Hirschmüller 2008 vorgeschlagenen SGM-Technik. Die Variante wird in diesem Dokument als „eSGM“ bezeichnet. eSGM wird im SGM-Block 408 nach bestimmten Ausführungsbeispielen implementiert.
  • Die erforderliche zeitliche Bandbreiten-Puffergröße nach den Techniken in Hirschmüller 2008 ist: z e i t l i c h e   B W = W × H × d M a x × b y t e s P e r C o s t
    Figure DE102020122943A1_0006
  • Das eSGM-Verfahren kann die erforderliche zeitliche Puffergröße reduzieren auf z e i t l i c h e   B W ( e S G M ) = W × H × ( p a t h N u m × ( b y t e s P e r D i s p + c o s t N u m × b y t e s P e r C o s t ) + b y t e s W i n n e r D i s p + b y t e s W i n n e r C o s t ) .
    Figure DE102020122943A1_0007
  • Bei der Hardware-Implementierung ist in einigen Ausführungsbeispielen die Anzahl der Aggregationspfade („pathNum“) auf 3 und die Anzahl der Bytes pro Disparität („bytesPerDisp“) auf 1, die Anzahl der Kosten („costNum“) für die Subpixel-Interpolation auf 3, die Anzahl der Bytes pro Kosten („bytesPerCost“) auf 1, die Anzahl der Bytes pro Gewinner-Disparität/Kosten („bytesWinnerDisp/Cost“) auf 2 festgelegt. Für 2D-SGM beträgt die CostNum 5 und bytesWinnerDisp 4, da mvx/mvy-Komponenten verarbeitet werden müssen.
  • In einigen Ausführungsbeispielen ist für eSGM ein Verfahren mit 3 Durchläufen implementiert. Um die Leistung (z.B. die Geschwindigkeit der Disparitätsberechnung zu erhöhen) in einigen Umgebungen zu verbessern, kann in einigen Ausführungsbeispielen ein vereinfachtes Verfahren mit 2 Durchläufen gewählt werden. Der SGM-Block in einigen Ausführungsbeispielen kann eSGM sowohl mit 2 als auch mit 3 Durchläufen unterstützen.
  • 8E und 8F zeigen grafisch eine Leistung mit 2 Durchläufen und eine Leistung mit 3 Durchläufen, gemäß einigen Ausführungsbeispielen.
  • In 8E zeigt die Operation „A“ den ersten Durchlauf, bei dem das Pfadkostenfeld für jeden der Pfade L1, L2, L3 und L4 ein Gewinnerpixel hat, das durch ein Schattierungsmuster gekennzeichnet ist. Die Summe aller Pfadkosten wird durch das Array „Sp“ repräsentiert. „Sp“ repräsentiert die Gewinnerpixel aus jedem der vier Pfade und identifiziert auch die an die Gewinnerpixel angrenzenden Pixel als Pixel, für die Nachbarinformationen erforderlich sind.
  • In einigen Ausführungsbeispielen wird der erste Durchlauf von links oben nach rechts unten durchgeführt. Für jedes Pixel,
    Berechne L r 1 ( p , d )
    Figure DE102020122943A1_0008
    für die 4 Richtungen, und
    Erhalte m i n i ( L r 1 ( p , i ) )
    Figure DE102020122943A1_0009
    und das korrespondierende d m i n 1 ,
    Figure DE102020122943A1_0010
    schreibe S p r 1 ( p , d m i n 1 ) ,
    Figure DE102020122943A1_0011
    S p r 1 ( p , d m i n 1 ± 1 ) , d m i n 1 ,
    Figure DE102020122943A1_0012
    wobei L d i r e c t i o n #pass
    Figure DE102020122943A1_0013
    (pixel location, disparity) und S p d i r e c t i o n #pass
    Figure DE102020122943A1_0014
    (pixel location, disparity).
  • Operation „B“ zeigt den zweiten Durchlauf (es werden keine Gewinner gezeigt) und veranschaulicht die Ermittlung der endgültigen Gewinnerkandidaten in Operation „C“. Das Summen-Array aus dem ersten Durchlauf wird mit der Summe aller Pfadkosten aus dem zweiten Durchlauf summiert, um das endgültige Array der Gewinnerkandidaten zu erzeugen. Dann wird der endgültige Gewinner aus dem finalen Gewinner-Kandidaten-Array ausgewählt. Dann wird in Operation „D“ der endgültige Gewinner einer Subpixelverfeinerung unterzogen, um die endgültige Disparität zu erzeugen.
  • In einigen Ausführungsbeispielen wird der zweite Durchlauf von rechts unten nach links oben im Bild durchgeführt. Für jedes Pixel, Berechne L r 2 ( p , d )
    Figure DE102020122943A1_0015
    für die 4 Richtungen;
    Lade S p r 1 ( p , d m i n 1 ) , S p r 1 ( p , d m i n 1 ± 1 ) , d m i n 1
    Figure DE102020122943A1_0016

    Erhalte S p r 2 ( p , d m i n 1 ) = S p r 1 ( p , d m i n 1 ) + S p r 2 ( p , d m i n 1 ) ,
    Figure DE102020122943A1_0017
    ähnlich für S p r 2 ( p , d m i n 1 ± 1 ) ;
    Figure DE102020122943A1_0018

    Erhalte das Minimum von S r 2 ( p , d ' ) ,
    Figure DE102020122943A1_0019
    führe Subpixel-Interpolation aus, um dsub' zu erhalten, schreibe S r 2 ( p , d ' ) ,
    Figure DE102020122943A1_0020
    dsub'
    Erhalte m i n i ( L r 2 ( p , i ) )
    Figure DE102020122943A1_0021
    und das korrespondierende d m i n 2 ,
    Figure DE102020122943A1_0022
    schreibe S p r 2 ( p , d m i n 2 ) , S p r 2 ( p , d m i n 2 ± 1 ) , d m i n 2 .
    Figure DE102020122943A1_0023
  • 8F zeigt eine SGM-Implementierung, bei der ein optionaler dritter Durchlauf durchgeführt wird. Der erste und zweite Durchlauf ist derselbe wie der in Bezug auf 8E beschriebene. Dann, nach dem ersten und zweiten Durchlauf, werden bei der Operation „E“ die Pfadkosten für L1-L4 im dritten Durchlauf bestimmt und die Summe der Pfadkosten des dritten Durchlaufs wird addiert, um Gewinnerkandidaten bei der Operation „F“ zu erhalten. Dann wird ein Gewinner, der aus den Gewinnerkandidaten des dritten Durchlaufs ausgewählt wurde, einer Subpixelverfeinerung unterzogen, um eine Disparität der Gewinner des dritten Durchlaufs und der Gewinnerkosten zu erhalten. Dann wird bei Operation „G“ ein endgültiger Gewinner basierend auf der im zweiten Durchlauf ermittelten Gewinnerdisparität und den Gewinnerkosten sowie der im dritten Durchlauf ermittelten Gewinnerdisparität und den Gewinnerkosten ausgewählt.
  • Der dritte Durchlauf wird von links oben im Bild nach rechts unten durchgeführt. Im dritten Durchlauf, für jedes Pixel,
    Lade S p r 2 ( p , d m i n 2 ) , S p r 2 ( p , d m i n 2 ± 1 ) , d m i n 2
    Figure DE102020122943A1_0024

    Lade S r 2 ( p , d ' ) , d s u b '
    Figure DE102020122943A1_0025

    Berechne L r 3 ( p , d m i n 2 )
    Figure DE102020122943A1_0026
    für die 4 Richtungen, erhalte S p r 3 ( p , d m i n 2 ) = S p r 2 ( p , d m i n 2 ) + S p r 3 ( p , d m i n 2 ) ,
    Figure DE102020122943A1_0027
    ähnlich S p r 3 ( p , d m i n 2 ± 1 ) ;
    Figure DE102020122943A1_0028

    Erhalte das Minimum von S r 3 ( p , d " ) ,
    Figure DE102020122943A1_0029
    führe Subpixel-Interpolation durch, um dsub" zu erhalten
    wenn S r 3 ( p , d " ) < S r 2 ( p , d ' ) ,  gebe   S r 3 ( p , d " ) ,
    Figure DE102020122943A1_0030
    und dsub'' aus, sonst gebe S r 2 ( p , d ' ) ,   d s u b '
    Figure DE102020122943A1_0031
    aus.
  • In einigen Ausführungsbeispielen führt der SGM-Block (z.B. SGM-Block 408) eine Strafe mit adaptiver Größe ein. Die adaptiv große Strafe (adaptive P2) ist zumindest in einigen Ausführungsbeispielen im SGM-Block implementiert, gemäß einigen Ausführungsbeispielen liegt der Vorteil der adaptiven P2 darin, dass die Objektgrenzen sowie dünne Objekte besser erhalten bleiben.
  • Die in Hardware implementierte adaptive P2 kann in einigen Ausführungsbeispielen basierend auf aktuellen und früheren Bildern wie folgt definiert werden: P 2 ' = 1 a a b s ( I c u r I p r e ) + P 2.
    Figure DE102020122943A1_0032
  • Um die Implementierung zu vereinfachen, kann α auf bestimmte Werte beschränkt werden (z.B. 1,2, 4 und 8).
  • In einigen Ausführungsbeispielen implementiert der SGM-Block die Subpixel-Interpolation. Der SGM-Block kann die gleichwinklige Subpixel-Interpolation implementieren, was einen Qualitätsvorteil gegenüber der bekannten Parabel-Interpolation ergibt. Die gleichwinklige Subpixel-Interpolation kann wie folgt bestimmt werden: d s u b P i x = { d i n t + C d + 1 C d 1 2 × ( C d C d 1 ) w e n n   C d + 1 < C d + 1 d i n t + C d + 1 C d 1 2 × ( C d C d + 1 ) s o n s t
    Figure DE102020122943A1_0033
    wobei cd die minimalen Pfadkosten und cd+1/cd-1 die benachbarten Pfadkosten sind, falls vorhanden.
  • Der OFA verwendet in einigen Ausführungsbeispielen Zwischenpuffer zum Schreiben/Lesen von temporären Informationen, die nicht im On-Chip-Speicher gespeichert werden können. Es gibt zwei Arten von Zwischenpuffern, die von dem OFA verwendet werden: Historienpuffer und temporärer Puffer. Der Historienpuffer wird verwendet, um Pfadkosten für jede Disparität/jeden Fluss von der vorherigen Pixelreihe zu speichern. Der temporäre Puffer wird verwendet, um den Zwischensieger/die Kosten des vorherigen SGM-Durchlaufs zu speichern.
  • Die Mindestgröße für den Verlaufspuffer kann als alignTo256B(output_width ∗ output_height ∗ (diagonal_enable?3:1) ∗ (pydSGM?256:(disparities))) bestimmt werden, wobei alignTo256B als alignTo256B(unsigned x){unsigned remainder = x % 256; return remainder == 0 ? x : x - remainder + alignment;}) definiert ist. Die Mindestgröße für den temporären Puffer kann als alignTo256B(output_width ∗ output_height ∗ (diagonal_enable?4:2) ∗ (pydSGM?6:4)) bestimmt werden.
  • Der OFA unterstützt in einigen Ausführungsbeispielen die Granularität von variablen Bewegungsvektoren/Disparitäten in der Ausgabe. In einigen Ausführungsbeispielen wird die Granularität des Bewegungsvektors und/oder die Ausgabegranularität der Disparität durch einen Gittergrößenparameter gesteuert. Die Gittergröße kann in x- und y-Richtung unabhängig voneinander auf 1/2/4/8 konfiguriert werden. Das heißt, (Gittergröße x)/(Gittergröße y) kann variabel konfiguriert werden (z.B. ½, 1, 2, usw.), indem Gittergröße x und Gittergröße y unabhängig voneinander geändert werden. 8F ist eine Illustration der Gittergrößen-Funktion in dem OFA für eine Gittergröße von 4x4, gemäß einigen Ausführungsbeispielen. Wie in der Figur dargestellt, kann der Ausgabeflussvektor und/oder die Disparität für die Verarbeitung auf einigen wenigen ausgewählten Pixeln der Originalpixel basieren. Das Merkmal der variablen Granularität ermöglicht es den Beispielausführungsbeispielen, Qualität und Leistung selektiv zu beeinflussen.
  • Epipolare SGM-Pipeline
  • 9 zeigt eine Systempipeline für den Modus für den optischen Fluss mit epipolarem SGM in einem System wie dem System 100, gemäß einigen Ausführungsbeispielen.
  • Die epipolare SGM-System-Pipeline umfasst eine Vorverarbeitungsstufe 902, die von der GPU und/oder einem anderen Prozessor (z.B. einem programmierbaren Bildbeschleuniger (engl. Programmable Vision Accelerator, PVA)) außerhalb der OFA durchgeführt werden kann, und eine beschleunigte Verarbeitungsstufe 904, die in dem OFA durchgeführt wird.
  • Der optische Fluss mit epipolarem SGM basiert auf einer Epipolargeometrie mit zwei Ansichten. Die Epipolargeometrie kodiert die Korrespondenzbeziehung zwischen zwei Bildern über die Fundamentalmatrix. Die Fundamentalmatrix F kann eine 3x3-Matrix sein, so dass l' = F x p und l = p' xF, wobei p und p' Punkte im linken bzw. rechten Bild sind, was der Epipolarbeziehung entspricht, die p auf die Epipolarlinie l' und p' auf die Epipolarlinie 1 abbildet. Daraus folgt, dass p'Fp = 0 ist. Bekannte Techniken können zur Bestimmung von F aus Punktkorrespondenzen verwendet werden. Grundsätzlich muss die Korrespondenz auf den entsprechenden Epipolarlinien liegen, siehe Beispiel in 3B. Die Berechnung der Epipolarlinien kann weiter vereinfacht werden, indem man die Tatsache verwendet, dass sich die Bewegung aus zwei Teilen zusammensetzt: Bewegung, die sich nur auf die Rotation der Kamera bezieht, und Bewegung, die sich nur auf die Translation der Kamera und die Pixeltiefe bezieht. Dann kann die Beziehung wie folgt neu formuliert werden: p' = K'RK-1p + K't/z.
  • Durch Verwenden der epipolaren Beschränkung wird das Problem des optischen Flusses von der 2D-Suche auf die ID-Suche reduziert, was die Berechnung drastisch reduziert. SGM wird bei dieser Technik auch als Regularisierung verwendet. Eine Beschreibung der Epipolarberechnung findet sich in K. Yamaguchi et al, „Robust Monocular Epipolar Flow Estimation", 2013 IEEE Conference on Computer Vision and Pattern Recognition, Portland, OR, 2013, S. 1862-1869, die hiermit durch Verweis aufgenommen wird.
  • Ein wichtiger Hinweis für epiSGM-Modus des OFA ist der Vorverarbeitungsschritt (Berechnung der monokularen Geometrie) unter der Annahme, dass die Kamera intrinsisch vorhanden ist. epiSGM sieht verallgemeinertes Stereo vor, ohne eine Entzerrungsannahme (z.B. beliebige Kamerapositionen).
  • Die Vorverarbeitungsstufe 902 nimmt zwei Eingabebilder I0 906 und I1 908 als Eingabe auf. Die Eingabe kann auch eine intrinsische Matrix K 910 (z.B. eine intrinsische 3x3 Matrix) umfassen.
  • Die Vorverarbeitung kann eine vorläufige Vorverarbeitung umfassen, wie z.B. Rauschunterdrückung und Berichtigung. Im Modus des epipolaren optischen Flusses kann die Vorverarbeitungsstufe 902 ein Modul 928 zur Bestimmung von Abgleichpunkten umfassen, das Abgleichpunkte zwischen den beiden Eingabebildern bestimmt, ein Modul 930 zur Bestimmung der Fundamentalmatrix, um die den beiden Eingabebildern entsprechende Fundamentalmatrix zu berechnen, einen Flussrichtungsbestimmer 936, der die Richtung des Flusses basierend auf Abgleichpunkten in den Eingabebildern bestimmt, einen Homographie-Matrixbestimmer 932, der die den Eingabebildern assoziierte Homographie erzeugt, und einen Epipolbestimmer 934, der den/die Epipol(e) für die Eingabebilder berechnet.
  • Das Modul 928 zur Bestimmung der Abgleichpunkte (d.h. Übereinstimmungspunkte oder Matching-Punkte, engl. matching points) kann einen Merkmalsdetektor verwenden, wie z.B. den Merkmalsdeskriptor SURF (Speeded-Up Robust Features) (beschrieben in H. Bay, T. Tuytelaars und L. V. Gool, „SURF: Speeded up robust features", in Proc. of the 9th European Conference on Computer Vision (ECCV'06), ser. Lecture Notes in Computer Science, A. Leonardis, H. Bischof, und A. Pinz, Hrsg., Band 3951. Graz, Österreich: Springer Verlag, Mai 2006, S. 404-417), um Abgleichpunkte zwischen den beiden Eingabebildern zu bestimmen. In einigen Ausführungsbeispielen können auch andere Merkmalsdeskriptoren wie z.B., aber nicht nur, die bekannte Scale-Invariant Feature Transform (SIFT) verwendet werden.
  • Die beschleunigte Verarbeitungsstufe 904 erhält als Eingabe die Flussrichtung 916 (z.B. 0-Vorwärts, 1-Rückwärts), den Status 918, die Fundamentalmatrix 920, die Homographiematrix 922, den Epipol 924 und die beiden Bilder 906 und 908.
  • Die OFA Schaltungsanordnung, die bei der Verarbeitung im Modus des epipolaren optischen Flusses beteiligt ist, umfasst mehrere Module, die spezifisch für den Epipolmodus sind, und mehrere Module, die mit einem oder mehreren anderen Betriebsmodi der OFA gemeinsam sind. Die für den epipolaren Modus spezifischen Module umfassen ein Rotationsflussmodul 942, ein Flussadditionsmodul 940, eine vz-Index-Kandidatengenerierung und ein Disparität zu optischer Fluss-Modul 948. Die Module, die mit einem oder mehreren anderen Modi gemeinsam sind, umfassen ein Kostenvolumen-Modul 950, ein SGM-Modul 952 und ein Subpixel-Verfeinerungsmodul 954.
  • In einigen Ausführungsbeispielen wird der Epipol-Modus hauptsächlich für den Hintergrund einer Szene verwendet.
  • In einigen Ausführungsbeispielen kann das RPF (z. B. RPF 414) die Startposition des Referenzpixels berechnen. Die Berechnung kann in zwei Schritten erfolgen: Berechnung des Rotationsbewegungsvektors und Erzeugung von Offsets entlang der Epipolarlinie. Die Berechnung des Rotationsbewegungsvektors kann Folgendes umfassen: einen ersten Schritt der Rotation Pi(x,y,z) = H(3x3) ∗ Po(x,y,1); einen zweiten Schritt der Normalisierung P1(x,y,1) = P1(x,y,z)/z; ein dritter Schritt der Epipolarlinienberechnung L2(x,y,z) = F(3x3) ∗ P0(x,y,1); vierter bis sechster Schritt der Normierung durch S= L2(x(x)2 + L2(y)2, N = rsqrt(S), und L2(x,y,z) = L2*N; einen siebten Schritt der Koeffizientenbestimmung C = L2,(x,y,z) ∗ P1 (x,y,1); einen achten Schritt der Versatzbestimmung O(x,y) = C* L2 (x, y); und einen neunten Schritt der endgültigen Referenzpixelbestimmung MV(x,y) = P1(x,y) - Po(x,y) - O(x,y). Die Offsets entlang der Epipolarlinie werden wie folgt berechnet d ( p , Z p ) = r ' r = r v z Z p 1 v z Z p = | p + u w ( p ) o' | v z Z p 1 v z Z p
    Figure DE102020122943A1_0034
    wobei |p + uw(p) - o'| der Pixelversatz von Epipol ist und vz/Zp eine Variable ist, die sich nur auf die Pixeltiefe bezieht.
  • vz/Zp kann im SGM-Rahmenwerk wie folgt berechnet werden: v z Z p = ω p n v m a x ,   m i t   ω p { 0,1,2,..., n 1 }
    Figure DE102020122943A1_0035
    wobei vmax den maximal möglichen Wert bezeichnet, n die Quantisierungsstufen und wp der v/z-Index ist.
  • In einigen Ausführungsbeispielen ist aufgrund von Überlegungen zur Hardware-Implementierung vmax auf 0,3 und n auf 256 festgelegt, so dass vz/Zp ein konstanter Wert für jede Disparität d ist: offset ( x ,y ) = sign * v ( x ,y ) * TAB [ d ]
    Figure DE102020122943A1_0036
    wobei v(x, y) = (x, y) + rotation_mv(x,y) ―epipole.
  • Nach der Verarbeitung der Eingabebilder in dem OFA im epipolaren Modus gibt der OFA eine Karte des optischen Flusses (z.B. epi-SGM-Flusskarte) 912 und eine Kostenkarte (z.B. eine epi-Kostenkarte) 914 aus. Die Pipeline kann so konfiguriert sein, dass die Kostenkarte 914 nicht generiert wird.
  • 10 zeigt ein Flussdiagramm für eine Technik zur Generierung des Inputs für den OFA in der Epipolarmodus-Systempipeline, gemäß einigen Ausführungsbeispielen. Beispielsweise kann der Prozess 1000 durch die GPU (z.B. GPU 106) und/oder einen anderen Prozessor wie einen PVA) ausgeführt werden, um die in Bezug auf die Vorverarbeitungsstufe 902 in der epipolaren SGM-Modus-Systempipeline beschriebenen Operationen durchzuführen.
  • Nach dem Eintritt in den Prozess 1000 werden die Bilder in Operation 1002 einer Merkmalsextraktion unterzogen. Operation 1002 nimmt als Eingänge 1001, die beiden Eingabebilder I0 906 und I1 908 und die intrinsische Matrix K 910 (z.B. eine intrinsische 3x3 Matrix).
  • Bei der Operation 1004 werden die extrahierten Merkmale zwischen den Eingabebildern abgeglichen. Der Merkmalsabgleich kann sich auf die Kenntnis der kamerainternen Parameter stützen, wie sie z.B. in der intrinsischen Matrix angegeben sind.
  • Bei der Operation 1006 wird die Fundamentalmatrix für die Eingabebilder erzeugt. Die Grundmatrix F kann basierend auf der Beziehung x 'TFx=0 bestimmt werden.
  • Bei der Operation 1008 werden die Rotation abgeschätzt und die Epipolberechnung durchgeführt. Dies kann unter Verwendung von E=K'FK durchgeführt werden, was r und den Epipol ergibt, wobei auf die Kenntnis kamerainterner Parameter, wie sie z.B. in der intrinsischen Matrix K vorliegen, zurückgegriffen wird.
  • Bei der Operation 1010 wird die Homographiematrix berechnet. Die folgende Beziehung kann verwendet werden H = KRK'.
  • Bei der Operation 1012 wird die Bewegungsrichtung bestimmt.
  • Nach der Operation 1012 werden die Ausgaben 1014 dem OFA zur Verfügung gestellt. Die Ausgaben 1014 umfassen die Fundamentalmatrix F, die Homographie H, die Epipolinformationen e und d.
  • Pyramidale SGM Pipeline
  • 11 zeigt eine Systempipeline für den optischen Fluss mittels pyramidalem SGM in einem System wie dem System 100, gemäß einigen Ausführungsbeispielen.
  • Die pyramidale SGM-Systempipeline besteht aus einer Vorverarbeitungsstufe 1102, die von der GPU und/oder einem anderen Prozessor (z.B. einem programmierbaren Bildbeschleuniger (PVA)) außerhalb des OFA durchgeführt werden kann, und einer beschleunigten Verarbeitungsstufe 1104, die in dem OFA durchgeführt wird. Im Gegensatz zur epipolaren SGM-Pipeline benötigt die pyramidale SGM-Pipeline im 2D-Fall keine geometrischen Informationen (z.B. intrinsische Parameter der Kameras). Wie oben erwähnt, wird die pyramidale SGM in Ausführungsbeispielen verwendet, um große Bewegungen genauer zu erfassen.
  • Pyramidales SGM ist eine Verallgemeinerung von Stereo-SGM vom 1D- zum 2D-Raum. Es ist ein generisches Verfahren für optischen Fluss und erfordert keine geometrischen Informationen (epipolare Geometrie). Da der Suchbereich für eine einzelne Schicht klein ist (z.B. 23x11 Pixel in der OFA-Implementierung), ist ein pyramidaler Ansatz erforderlich, um mit großen Bewegungen umzugehen, wobei grundsätzlich jede Stufe um das Ergebnis der vorherigen Stufe herum gesucht wird. 4: zeigt einen solchen Prozess.
  • Die Vorverarbeitungsstufe 1102 nimmt zwei Eingabebilder I0 906 und I1 908 als Eingabe auf.
  • Die Vorverarbeitungsstufe 1102 umfasst ein Bildpyramiden-Erzeugungsmodul 1106, das für jedes der Eingabebilder Bildpyramiden erzeugt. Die Pyramidengenerierung kann CUDA verwenden, um eine Bildpyramide zu erzeugen, z. B. unter Verwendung eines 5x5-Gauß-Kernels. Eine Bildpyramide besteht aus einer Reihe von Schichten, wobei je höher, desto kleiner die Größe ist. Jede Ebene ist von unten nach oben nummeriert, so dass Ebene i+ 1 kleiner als Ebene i ist. Um Ebene i+ 1 in der Gauß'schen Pyramide zu erzeugen, kann Ebene i mit einem Gauß'schen Kernel gefaltet werden, und jede geradzahlige Zeile und Spalte aus dem Ergebnis entfernt werden. Ein Beispiel für eine Gauß'sche Kernel-Faltung kann wie folgt aussehen: 1 16 [ 1 4 6 4 1 4 16 24 16 4 6 24 36 24 6 4 16 24 16 4 1 4 6 4 1 ]
    Figure DE102020122943A1_0037
  • In einigen Ausführungsbeispielen kann der OFA einen Skalierer zur Erzeugung des Bildes umfassen. Ein solcher hardwarebasierter Skalierer kann zum Beispiel eine Pyramide erzeugen, die einen kleineren 3x3 Gauß-Kernel verwendet, um den Einsatz von Chip fläche zu minimieren.
  • Die erzeugten Bildpyramiden, die Bildpyramide für die Bilder 1116 und die Bildpyramide für das Bild 1118 werden dann als Eingabe für die OFA Stufe 1104 im pyramidalen SGM-Modus bereitgestellt.
  • Zusätzlich zu den OFA Schaltungsanordnungen wie dem Kostenvolumen-Konstruktor 950, dem 1D/2D-SGM 952 und dem Subpixel-Verfeinerungsmodul 954 umfasst die OFA-Schaltungsanordnung für den pyramidalen SGM-Modus spezifische Module wie das Modul 1112 für den optischen Fluss und das Modul 1110 für die Generierung von Bewegungsvektorhinweisen und das Modul 1110 für die Kandidatengenerierung. Die Ausgabe der Subpixelverfeinerung wird dem Modul 1112 für den optischen Fluss bereitgestellt, und die Ausgabe des Hinweis-Moduls 1110 wird dem Kostenvolumen-Konstruktor 950 zur Verfügung gestellt. Die Operationen in dem OFA können für jede Stufe der Bildpyramide in einer Schleife ausgeführt werden.
  • Im pyramidalen Modus wird die ref-Pixelposition direkt durch einen Eingabehinweis-Bewegungsvektor bereitgestellt, der von der vorherigen Stufe des Bildes oder anderen Quellen stammt. Der OFA unterstützt ein festes 23x11 Suchfenster, wie in 8C gezeigt.
  • Nach der Verarbeitung in dem OFA werden ein pyramidaler SGM-Fluss 1120 und eine pyramidale SGM-Kosten 1122 ausgegeben. Die Pipeline kann so konfiguriert sein, dass die Kosten 1122 nicht generiert werden.
  • Stereo-Disparitäts Pipeline
  • 12 zeigt eine System-Pipeline für den Stereomodus in einem System wie System 100, gemäß einigen Ausführungsbeispielen.
  • Die Stereo-SGM-Systempipeline umfasst eine Vorverarbeitungsstufe 1202, die von der GPU und/oder einem anderen Prozessor (z.B. einem programmierbaren Bildbeschleuniger (engl. Programmable Vision Accelerator, PVA)) außerhalb des OFA durchgeführt werden kann, eine beschleunigte Verarbeitungsstufe 1104, die in dem OFA durchgeführt wird, und eine Nachverarbeitungsstufe 1212, die ebenfalls in einer GPU oder einem anderen Prozessor durchgeführt werden kann.
  • Die Vorverarbeitungsstufe 1202 nimmt zwei Eingabebilder I0 1201 und I1 1203 als Eingabe entgegen. Die Vorverarbeitungsstufe 1202 umfasst ein Stereobildentzerrungsmodul 1208, das jedes der Eingabebilder nach Bedarf entzerrt. Die entzerrten Bilder I0 1216 und I1 1218 werden dann der OFA-Stufe 1204 im Stereo-SGM-Modus als Eingabe zur Verfügung gestellt.
  • Zusätzlich zu den OFA Schaltungsanordnungen wie dem Cost Volume Constructor 950, dem 1D/2D SGM 952 und dem Subpixelverfeinerungsmodul 954 umfasst die OFA Schaltungsanordnung stereo-SGM-Modus-spezifische Module wie das horizontale Kandidatenauswahlmodul 1217.
  • Im Stereomodus ist die Suchrichtung immer horizontal, zur Bestimmung der Suchrichtung wird ein von der Software bereitgestellter Vorzeichenkennzeichner verwendet (Suche von links -> rechts oder rechts -> links).
  • Nach der Verarbeitung in dem OFA wird eine Stereodisparitätskarte, die den Eingabebildern 1201 und 1203 entspricht, der Nachbearbeitungsstufe 1212 zur Verfügung gestellt.
  • Die Nachbearbeitungsstufe 1212 umfasst ein LR-Prüfmodul 1220 für die Durchführung einer Bestätigung von links nach rechts und ein Lochfüllmodul 1222 to. Die Ausgabe des Systems umfasst eine Stereo-Disparitätskarte 1224.
  • Pipeline für optischen Fluss durch Fusion
  • 13 zeigt eine Systempipeline für den Fusionsmodus des optischen Flusses mittels SGM in einem System wie dem System 100, gemäß einigen Ausführungsbeispielen.
  • Im Fusionsmodus verwendet das System 100 sowohl die in 9 gezeigten epipolaren SGM-Modus-Systempipeline-Stufen als auch die in 11 gezeigte pyramidale SGM-Modus-Systempipeline. Dementsprechend umfasst die Vorverarbeitungsstufe 1302 des Fusionsmodus, die von der GPU und/oder einem anderen Prozessor (z.B. einem programmierbaren Bildbeschleuniger (PVA)) außerhalb des OFA durchgeführt werden kann, die Module der epipolaren SGM-Modus-Vorverarbeitungsstufe 902 und die Module der pyramidalen SGM-Vorverarbeitungsstufe 1102.
  • Die Ausgabe der Fusionsmodus-Vorverarbeitungsstufe 1302 kann die oben beschriebenen Ausgänge als Ausgänge der epipolaren Modus-Vorverarbeitungsstufe 902 und die Ausgänge der pyramidalen SGM-Modus-Vorverarbeitungsstufe 1102 umfassen. Die Ausgaben aus der Vorverarbeitungsstufe werden als Eingaben für die im Fusionsmodus beschleunigte Verarbeitungsstufe 1304 in dem OFA bereitgestellt.
  • Im Fusions-SGM-Modus werden die OFA-Module für den epipolaren Modus (z.B. die Module 942, 944, 946 und 948), die Module für den pyramidalen Modus (z.B. 1110 und 1112) und die gemeinsamen Module (z.B. 950, 952 und 954) aktiviert.
  • In einigen Ausführungsbeispielen kann der OFA einen Switch 1320 umfassen, um wahlweise die epipolare SGM-System-Pipeline oder die pyramidale SGM-System-Pipeline zu aktivieren. Der Switch kann verwendet werden, um die Eingabebilder I0 906 und I1 908 sequentiell durch die epipolare SGM-Pipeline und die pyramidale SGM-Pipeline laufen zu lassen und die Ausgaben von jedem zur Fusionsmodus-Nachbearbeitungsstufe 1306 zu liefern. Die sequentielle Durchführung des epipolaren SGM und des pyramidalen SGM in der OFA ermöglicht die Verwendung einer gemeinsamen Schaltungsanordnung (und damit die Einsparung von Platz auf dem Chip) für den Aufbau des Kostenvolumens (z.B. Modul 950), des SGM (z.B. Modul 952) und der Subpixelverfeinerung (z.B. Modul 954) ohne komplexes Pipelining.
  • In einigen anderen Ausführungsbeispielen kann der OFA so konfiguriert sein, dass er die Eingabebilder I0 906 und I1 908 parallel durch die epipolare SGM-Pipeline und die pyramidale SGM-Pipeline verarbeitet und die Ausgaben von jeder dieser Pipelines an die Nachbearbeitungsstufe 1306 des Fusionsmodus liefert. In solchen Ausführungsbeispielen kann die gemeinsame Schaltungsanordnung dupliziert werden und/oder eine Pipeline verwendet werden, um die gemeinsame Verarbeitung beider Modi auf effiziente Weise durchzuführen, um einen optischen Fluss in Echtzeit zu erreichen.
  • Die Fusionsmodus-Nachbearbeitungsstufe 1306 nimmt als Eingabe die epipolare SGM-Flusskarte 912, die epipolare SGM-Kostenkarte 914, die pyramidale SGM-Flusskarte 1120 und die pyramidale SGM-Kostenkarte 1122 und führt eine Nachbearbeitung des optischen Flusses 1316 durch, um einen optischen Fluss 1308 zu erzeugen.
  • Der optische Fluss 1308 wird durch ein Epipolar- und Pyramidenflussfusionsmodul 1318 erzeugt, das den Hintergrund des optischen Flusses 1308 basierend vollständig oder im Wesentlichen vollständig auf den Eingaben von dem epipolaren Modus des OFA erhält und den Vordergrund des optischen Flusses 1308 basierend vollständig oder im Wesentlichen vollständig auf den Eingaben von dem pyramidalen Modus des OFA erhält.
  • Die Fusion kann auf einem Fusionieren der erzeugten Flusskarten unter Verwendung der entsprechenden Kostenkarten basieren. In einigen Ausführungsbeispielen kann für die Fusion eine Technik wie kostenbasierte WTA oder kostenbasierte Segmentierung verwendet werden.
  • In einigen Ausführungsbeispielen kann die Separation und/oder Identifizierung von Hintergrund und Vordergrund für die Fusion auf einer einfachen bewegungsbasierten Analyse basieren. Bei Bildern, die mit statischen Kameras aufgenommen wurden, kann die Karte des optischen Flusses auf Vorhandensein und Ort von Aktivität analysiert werden. Begrenzungskästen für identifizierte Objekte können durch ein Verfahren erhalten werden, das die Bestimmung der Flussgröße, adaptive Schwellwertbestimmung, morphologisches Schließen/Öffnen, Blob-Analyse, Entfernen kleiner Blobs, einem Einfassen von Kästen und Zusammenführen von Kästen umfasst. In einem anderen Ansatz kann die einfache bewegungsbasierte Analyse auf der Eigenbewegungskompensation basieren, mit deren Hilfe sich bewegende Objekte erkannt werden können. Die Schritte in einem solchen Prozess können ein Bestimmen des epipolaren Flusses basierend auf I0 bis I1, ein Warpen von I1, ein Berechnen der Differenz zwischen I0 und dem Warp I1 und dann ein Filtern und Schwellenwertverfahren für die Segmentierung umfassen. Ein weiterer Ansatz kann auf der Identifizierung einer Zwischenhindernis-/Objektdarstellung basierend auf der Stereotiefe basieren. Die Schritte können die Bestimmung der Stereodisparität, die Bestimmung des Belegungsrasters, die Bestimmung des Freiraums, die Bestimmung der Höhensegmentierung und dann die Bestimmung der Stixel umfassen. Stixel-Cluster bilden Objektkandidaten, die dann Objekte unterscheiden können. Ein weiterer Ansatz zur Identifizierung von Vordergrundobjekten, der auf der Grundlage von Ausführungsbeispielen verwendet werden kann, wird in Geiger, et al., „Bounding Boxes, Segmentations and Object Coordinates How Important is Recognition for 3D Scene Flow Estimation in Autonomous Driving Scenarios“, International Conference on Computer Vision (ICCV) 2017, beschrieben, der hiermit durch Verweis in seiner Gesamtheit einbezogen wird. Geiger et al. beschreiben, dass bei gegebenen Stereobildpaaren bei t1 und t0 für jedes Pixel 3D-Punkte (XYZ) berechnet werden können. Für jedes der vier Eingabebilder, XYZ-Bildblöcke, werden neben Bounding Boxes Instanzsegmentierungen erhalten. Die Instanzen werden einzeln verarbeitet, um Objektkoordinaten für jede Instanz zu erhalten, wobei ein Neuronales Netz zur Faltung der Objektkoordinaten (CNN) verwendet wird. Danach werden, wie in Geiger et al. beschrieben, die gewonnenen Informationen in ein Instance Scene Flow-Verfahren (ISF) integriert, um die endgültige Ausgabe zu erzeugen.
  • Die Ausgabe der Fusion kann einen optischen Fluss umfassen, bei dem der Vordergrund auf pyramidalem SGM basiert und der Hintergrund auf epipolarem SGM, sowie die entsprechende Segmentierungskarte.
  • Der OFA in einem Anwendungsbeispiel
  • 14A zeigt schematisch ein System 1400, in dem ein Fahrzeug 1402 einen OFA, wie z.B. den OFA 400, zur Beschleunigung des optischen Flusses für den Einsatz in einer Anwendung, wie z.B. einer ADAS-Anwendung, enthält.
  • Das optische Fluss-System 1422 kann ein System wie das oben beschriebene System 100 sein und kann so konfiguriert sein, dass es Video von mehreren (z.B. 13) Kameras, die am Fahrzeug 1402 angebracht sind, empfängt und Informationen über einen beschleunigten optischen Fluss, Videoinferenz unter Verwendung von Informationen über einen beschleunigten optischen Fluss und/oder andere Informationen als Eingabe in das Fahrzeugsteuerungssystem 1420 liefert.
  • Jede der Kameras kann Video mit 30 Einzelbildern pro Sekunde ausgeben. Die Kameras können eine Frontkamera (z.B. 12,0-Megapixel-Kamera) umfassen, die ein Sichtfeld 1404 von der Vorderseite von 30 Grad bietet, eine Frontkamera (z.B. 12,0-Megapixel-Kamera), die ein Sichtfeld 1406 von 120 Grad bietet, zwei Seitenkameras (z.B. 1,2-Megapixel-Kameras), die jeweils ein Sichtfeld 1410 von 100 Grad haben, zwei Seitenflügelkameras (z.B. 1. 2-Megapixel-Kameras) mit je einem Sichtfeld 1412 von 100 Grad, zwei Querverkehrskameras (z.B. 8,3-Megapixel-Kameras) mit je einem Sichtfeld 1408 von 120 Grad, eine Rückfahrkamera (z.B. 2,3-Megapixel-Kamera) mit einem Sichtfeld 1414 von 50 Grad und vier Surround-Kameras (z.B. 1,2-Megapixel-Kameras) mit je einem Sichtfeld 1416 von 190 Grad.
  • Das Sichtfeld 1404 kann für Fernsicht, kleine Objekte und geringere Bewegung verarbeitet werden. Das Sichtfeld 1408 kann für die Nah-/Zwischensicht und Bewegungen mit hohem Bewegungsumfang verarbeitet werden. Die Sichtfelder 1406 und 1410 können für die Nahsicht und große Bewegungen verarbeitet werden, und das Sichtfeld 1414 kann für die Nah-/Intermediärsicht und große Bewegungen verarbeitet werden.
  • In einigen Anwendungen kann das Video von allen Kameras für den optischen Fluss verwendet werden. In einigen anderen Anwendungen kann das Video von einigen Kameras nicht für den optischen Fluss verwendet werden. Beispielsweise sind in einer Anwendung die Sichtfelder 1416 von den Berechnungen des optischen Flusses ausgeschlossen.
  • 14B ist ein Flussdiagramm für einen Prozess 1450, der eine hardwarebeschleunigte Erzeugung von optischem Fluss und Stereodisparitäten verwendet, gemäß einigen Ausführungsbeispielen.
  • Der dargestellte Teil des Prozesses 1450 beginnt mit dem Empfangen des Stereobildpaares It1 (linkes und rechtes Stereobild zur Zeit t1) bei der Operation 1452. Es wird angenommen, dass das Bildpaar It1 auf das Bildpaar It0 (linkes und rechtes Stereobild zum Zeitpunkt to) folgt, oder dass die beiden Bildpaare zusammen empfangen werden.
  • Bei der Operation 1454 kann das Bildpaar It1 verarbeitet werden, um die Stereodisparität für das Paar zu bestimmen. Zum Beispiel kann das Bildpaar It1 in der in 12 gezeigten Stereo-SGM-Pipeline verarbeitet werden. Die Pipeline erzeugt eine Stereodisparität Dt1 für das Bildpaar It1.
  • Bei der Operation 1456 wird die Bestimmung des optischen Flusses der statischen Welt z.B. unter Verwendung der in 9 und 10 gezeigten epipolaren SGM-Pipeline durchgeführt, um den epipolaren optischen Fluss (OFepipolar) von It0 nach It1 zu erzeugen. Die Eingabe in die epipolare SGM-Pipeline wird von den Bildpaaren It0 und It1 geliefert.
  • Bei der Operation 1458 wird eine allgemeine optische Flussbestimmung durchgeführt, indem z.B. die in 11 gezeigte pyramidale SGM Pipeline verwendet wird, um den allgemeinen/pyramidalen optischen Fluss (OFgeneral) von It0 nach It1 zu erzeugen. Die Eingabe in die allgemeine SGM-Pipeline erfolgt aus den Bildpaaren It0 und It1.
  • Bei der Operation 1460 werden der erzeugte epipolare optische Fluss OFepipolar und der allgemeine optische Fluss OFgeneral kombiniert, um einen fusionierten optischen Fluss OFfused zu erzeugen, wie in Bezug auf die Pipeline des fusionierten optischen Flusses in 13 beschrieben.
  • Zu diesem Zeitpunkt sind zumindest Informationen über den optischen Fluss und Stereo-Disparitätsinformationen, die aus den Bildpaaren abgeleitet werden, erhalten worden. Dann, bei 1462, stehen diese Informationen, die den fusionierten optischen Fluss OFfused, die Disparität für die Zeit t1 Dt1 und die Disparität für die Zeit t0 Dt0 umfassen, für den Zugriff durch einen Prozessor zur Verwendung in einer Anwendung wie z.B. der autonomen Fahrzeugnavigation zur Verfügung. In einigen Ausführungsbeispielen können der optische Fluss und die Disparitätsinformation der Anwendung als eine Szenenflusskarte zur Verfügung gestellt werden, in der für jedes Pixel der Wert des Feldes des optischen Flusses zusammen mit der Disparität für die Zeitschritte t1 und t0 spezifiziert ist.
  • Parallele Verarbeitunssarehitekturen, die den OFA umfassen
  • Es werden nun weitere illustrierende Informationen zu verschiedenen optionalen Architekturen und Funktionen gezeigt, mit denen das oben genannte System je nach Wunsch des Benutzers implementiert werden kann. Es wird nachdrücklich darauf hingewiesen, dass die folgenden Informationen zu illustrativen Zwecken dargestellt werden und nicht in irgendeiner Weise als Einschränkung ausgelegt werden sollten. Jede der folgenden Funktionen kann optional mit oder ohne Ausschluss anderer beschriebener Funktionen integriert werden.
  • 15 zeigt eine Parallelverarbeitungseinheit (PPU) 1500, die gemäß einigen Ausführungsbeispielen über einen Switch 1500 mit einer oder mehreren anderen PPUs oder anderen Geräten verbunden sein kann. Gemäß einigen Ausführungsbeispielen ist die in Bezug auf 1 beschriebene GPU 106 eine PPU wie PPU 1500. In einem Ausführungsbeispiel ist der PPU 1500 ein multi-threaded Prozessor, der auf einem oder mehreren integrierten Schaltkreisgeräten implementiert ist. Die PPU 1500 ist eine latenzverkleinernde Architektur, die darauf ausgelegt ist, viele Threads parallel zu verarbeiten. Ein Thread (z.B. ein Ausführungs-Thread) ist eine Instanziierung eines Befehlssatzes, der so konfiguriert ist, dass er von der PPU 1500 ausgeführt wird. In einem Ausführungsbeispiel ist der PPU 1500 eine Grafikverarbeitungseinheit (GPU), die so konfiguriert ist, dass sie eine Grafik-Rendering-Pipeline für die Verarbeitung von dreidimensionalen (3D) Grafikdaten implementiert, um zweidimensionale (2D) Bilddaten für die Anzeige auf einer Anzeigevorrichtung, wie z.B. einer Flüssigkristallanzeige (LCD), zu erzeugen. In anderen Ausführungsbeispielen kann die PPU 1500 zur Durchführung von allgemeinen Berechnungen verwendet werden. Während hier ein beispielhafter Parallelprozessor zu Illustrationszwecken dargestellt ist, wird nachdrücklich darauf hingewiesen, dass ein solcher Prozessor nur zu Illustrationszwecken dargestellt wird und dass jeder beliebige Prozessor als Ergänzung und/oder Ersatz für diesen eingesetzt werden kann.
  • Eine oder mehrere PPUs 1500 können so konfiguriert sein, dass sie Tausende von HPC- (High Performance Computing), Rechenzentrums- und Machine-Learning-Anwendungen beschleunigen. Die PPU 1500 kann so konfiguriert werden, dass sie zahlreiche Deep Learning-Systeme und -Anwendungen beschleunigt, darunter autonome Fahrzeugplattformen, Deep Learning, hochpräzise Sprach-, Bild- und Texterkennungssysteme, intelligente Videoanalyse, Molekularsimulationen, Arzneimittelentdeckung, Krankheitsdiagnose, Wettervorhersage, Analyse großer Datenmengen, Astronomie, Molekulardynamiksimulation, Finanzmodellierung, Robotik, Fabrikautomatisierung, Echtzeit-Sprachübersetzung, Optimierungen der Online-Suche und personalisierte Benutzerempfehlungen und dergleichen.
  • Wie in 51 dargestellt, umfasst die PPU 1500 eine Eingabe/Ausgabe-Einheit (I/O) 1505, eine Front-End-Einheit 1515, eine Scheduler-Einheit 1520, eine Arbeitsverteilungseinheit 1525, einen Hub 1530, eine Crossbar (Xbar) 1570, einen oder mehrere General Processing Cluster (GPCs) 1550 und eine oder mehrere Partitionseinheiten 1580. Die PPU 1500 kann mit einem Host-Prozessor oder anderen PPUs 1500 über eine oder mehrere NVLink 1510-Hochgeschwindigkeitsverbindungen verbunden sein. Die PPU 1500 kann über einen Interconnect 1502 mit einem Host-Prozessor oder anderen Peripheriegeräten verbunden sein. Die PPU 1500 kann auch mit einem lokalen Speicher verbunden sein, der aus einer umfassenden Anzahl von Speichergeräten 1504 besteht. In einem Ausführungsbeispiel kann der lokale Speicher aus einer umfassenden Anzahl von DRAM-Einheiten (Dynamic Random Access Memory) bestehen. Die DRAM-Bausteine können als Speichersubsystem mit hoher Bandbreite (HBM) konfiguriert sein, wobei mehrere DRAM-Chips innerhalb jedes Bausteins gestapelt sind.
  • Der NVLink 1510 Interconnect ermöglicht es, Systeme zu skalieren und eine oder mehrere PPUs 1500 in Kombination mit einer oder mehreren CPUs zu umfassen, unterstützt die Cache-Kohärenz zwischen den PPUs 1500 und den CPUs sowie das CPU-Mastering. Daten und/oder Befehle können durch den NVLink 1510 über den Hub 1530 zu/von anderen Einheiten der PPU 1500 übertragen werden, wie z.B. einer oder mehreren Copy Engines, einem Video-Encoder, einem Video-Decoder, einer Power-Management-Einheit usw. (nicht explizit dargestellt). Der NVLink 1510 wird in Verbindung mit 16A-B näher beschrieben.
  • Die E/A-Einheit 1505 ist konfiguriert, um Kommunikationen (z. B. Befehle, Daten usw.) von einem Host-Prozessor (nicht abgebildet) über die Verbindung 1502 zu senden und zu empfangen. Die E/A-Einheit 1505 kann mit dem Host-Prozessor direkt über die Interconnect 1502 oder über ein oder mehrere Zwischengeräte, wie z. B. eine Speicherbrücke, kommunizieren. In einem Ausführungsbeispiel kann die E/A-Einheit 1505 mit einem oder mehreren anderen Prozessoren, wie z.B. einer oder mehreren der PPUs 1500, über die Interconnect 1502 kommunizieren. In einem Ausführungsbeispiel implementiert die E/A-Einheit 1505 eine Peripheral Component Interconnect Express (PCIe)-Schnittstelle für die Kommunikation über einen PCIe-Bus, und die Interconnect 1502 ist ein PCIe-Bus. In alternativen Ausführungsbeispielen kann die E/A-Einheit 1505 andere Arten von bekannten Schnittstellen für die Kommunikation mit externen Geräten implementieren.
  • Die E/A-Einheit 1505 dekodiert Pakete, die über die Interconnect 1502 empfangen werden. In einem Ausführungsbeispiel sind die Pakete Befehle, die so konfiguriert sind, dass die PPU 1500 verschiedene Operationen ausführt. Die E/A-Einheit 1505 überträgt die dekodierten Befehle an verschiedene andere Einheiten der PPU 1500, je nachdem, was die Befehle vorgeben. Beispielsweise können einige Befehle an die Front-End-Einheit 1515 übertragen werden. Andere Befehle können an den Hub 1530 oder andere Einheiten der PPU 1500 übertragen werden, wie z. B. ein oder mehrere Copy Engines, einen Videokodierer, einen Videodekodierer, eine Power-Management-Einheit usw. (nicht explizit dargestellt). Mit anderen Worten, die E/A-Einheit 1505 ist so konfiguriert, dass sie die Kommunikation zwischen und zwischen den verschiedenen logischen Einheiten der PPU 1500 leitet.
  • In einem Ausführungsbeispiel kodiert ein vom Host-Prozessor ausgeführtes Programm einen Befehlsstrom in einem Puffer, der der PPU 1500 Arbeitslasten zur Verarbeitung bereitstellt. Eine Arbeitslast kann mehrere Befehle und Daten umfassen, die von diesen Befehlen verarbeitet werden sollen. Der Puffer ist ein Bereich in einem Speicher, auf den sowohl der Host-Prozessor als auch die PPU 1500 zugreifen können (z.B. Lesen/Schreiben). Beispielsweise kann die E/A-Einheit 1505 so konfiguriert sein, dass sie über Speicheranforderungen, die über die Interconnect 1502 übertragen werden, auf den Puffer in einem mit der Interconnect 1502 verbundenen Systemspeicher zugreift. In einem Ausführungsbeispiel schreibt der Host-Prozessor den Befehlsstrom in den Puffer und sendet dann einen Zeiger auf den Anfang des Befehlsstroms an die PPU 1500. Die Front-End-Einheit 1515 empfängt Zeiger auf einen oder mehrere Befehlsströme. Die Front-End-Einheit 1515 verwaltet den einen oder die mehreren Ströme, liest Befehle aus den Strömen und leitet Befehle an die verschiedenen Einheiten der PPU 1500 weiter.
  • Die Front-End-Einheit 1515 ist mit einer Scheduler-Einheit 1520 gekoppelt, die die verschiedenen GPCs 1550 für die Verarbeitung von Aufgaben konfiguriert, die durch einen oder mehrere Streams definiert sind. Die Schedulereinheit 1520 ist so konfiguriert, dass sie Statusinformationen in Bezug auf die verschiedenen von der Schedulereinheit 1520 verwalteten Aufgaben verfolgt. Der Status kann angeben, welchem GPC 1550 eine Aufgabe zugeordnet ist, ob die Aufgabe aktiv oder inaktiv ist, eine mit der Aufgabe assoziierte Prioritätsstufe usw. Die Scheduler-Einheit 1520 verwaltet die Ausführung einer Vielzahl von Aufgaben auf einem oder mehreren GPCs 1550.
  • Die Scheduler-Einheit 1520 ist mit einer Arbeitsverteilungseinheit 1525 gekoppelt, die so konfiguriert ist, dass sie Aufgaben zur Ausführung auf den GPCs 1550 verteilt. Die Arbeitsverteilungseinheit 1525 kann eine Reihe von geplanten Aufgaben verfolgen, die von der Schedulereinheit 1520 empfangen werden. In einem Ausführungsbeispiel verwaltet die Arbeitsverteilungseinheit 1525 einen Pool ausstehender Aufgaben und einen Pool aktiver Aufgaben für jeden der GPCs 1550. Der Pool ausstehender Aufgaben kann eine Anzahl von Slots (z.B. 32 Slots) umfassen, die Aufgaben enthalten, die einem bestimmten GPC 1550 zur Bearbeitung zugewiesen sind. Der Pool aktiver Aufgaben kann eine Anzahl von Slots (z.B. 4 Slots) für Aufgaben umfassen, die von den GPCs 1550 aktiv bearbeitet werden. Wenn eine GPC 1550 die Ausführung einer Aufgabe beendet, wird diese Aufgabe aus dem Pool aktiver Aufgaben für die GPC 1550 verdrängt, und eine der anderen Aufgaben aus dem Pool ausstehender Aufgaben wird ausgewählt und für die Ausführung auf der GPC 1550 eingeplant. Wenn eine aktive Aufgabe auf der GPC 1550 inaktiv war, z.B. während sie darauf wartet, dass eine Datenabhängigkeit aufgelöst wird, kann die aktive Aufgabe aus der GPC 1550 verdrängt und an den Pool ausstehender Aufgaben zurückgegeben werden, während eine andere Aufgabe aus dem Pool ausstehender Aufgaben ausgewählt und zur Ausführung auf der GPC 1550 eingeplant wird.
  • Die Arbeitsverteilungseinheit 1525 kommuniziert mit einem oder mehreren GPCs 1550 über die XBar 1570. Die XBar 1570 ist ein Interconnect-Netzwerk, das viele der Einheiten der PPU 1500 mit anderen Einheiten der PPU 1500 koppelt. Beispielsweise kann der XBar 1570 so konfiguriert sein, dass sie die Arbeitsverteilungseinheit 1525 mit einem bestimmten GPC 1550 koppelt. Obwohl nicht explizit dargestellt, können eine oder mehrere andere Einheiten der PPU 1500 auch über den Hub 1530 mit der XBar 1570 verbunden werden.
  • Die Aufgaben werden von der Scheduler-Einheit 1520 verwaltet und von der Arbeitsverteilungseinheit 1525 an einen GPC 1550 gesandt. Der GPC 1550 ist konfiguriert, um die Aufgabe zu verarbeiten und Ergebnisse zu erzeugen. Die Ergebnisse können von anderen Aufgaben innerhalb dem GPC 1550 verbraucht, über die XBar 1570 an einen anderen GPC 1550 weitergeleitet oder im Speicher 1504 gespeichert werden. Die Ergebnisse können über die Partitionseinheiten, die eine Speicherschnittstelle zum Lesen und Schreiben von Daten in den/aus dem Speicher 1504 implementieren, in den Speicher 1504 geschrieben werden. Die Ergebnisse können über den NVLink 1510 an eine andere PPU 1504 oder eine CPU übertragen werden. In einem Ausführungsbeispiel umfasst die PPU 1500 eine Anzahl U von Partitionseinheiten 1580, die der Anzahl der separaten und unterschiedlichen Speichereinheiten 904 entspricht, die mit der PPU 1500 gekoppelt sind. Eine Speicherverwaltungseinheit (MMU) bietet eine Schnittstelle zwischen dem GPC 1550 und der Partitionseinheit 1580. Die MMU kann die Übersetzung von virtuellen Adressen in physische Adressen, einen Speicherschutz und eine Arbitrierung von Speicheranforderungen bereitstellen.
  • Die Speicherpartitionseinheit 1580 kann eine Rasteroperationseinheit (ROP), einen Level-2- (Z2)-Cache und eine Speicherschnittstelle umfassen. Die Speicherschnittstelle ist mit dem Speicher 1504 gekoppelt. Die Speicherschnittstelle kann 32-, 64-, 128-, 1024-Bit-Datenbusse oder ähnliches für eine Hochgeschwindigkeits-Datenübertragung implementieren. In einem Ausführungsbeispiel enthält die PPU 1500 U-Speicherschnittstellen, eine Speicherschnittstelle pro Paar Partitionseinheiten 1580, wobei jedes Paar Partitionseinheiten 1580 mit einer entsprechenden Speichervorrichtung 1504 verbunden ist. Zum Beispiel kann die PPU 1500 mit bis zu Y-Speichereinheiten 1504 verbunden werden, wie z.B. mit Speicherstapeln mit hoher Bandbreite oder synchronen dynamischen Direktzugriffsspeichern mit doppelter Datenrate, Version 5, oder anderen Arten von persistenter Speicherung.
  • In einem Ausführungsbeispiel implementiert die Speicherschnittstelle eine HBM2-Speicherschnittstelle, wobei Y gleich der Hälfte von U ist. In einem Ausführungsbeispiel befinden sich die HBM2-Speicherstacks auf demselben physikalischen Gehäuse wie die PPU 1500, wodurch im Vergleich zu herkömmlichen GDDR5-SDRAM-Systemen erhebliche Einsparungen bei Strom und Fläche erzielt werden. In einem Ausführungsbeispiel umfasst jeder HBM2-Stapel vier Speicherchips und Y ist gleich 4, wobei der HBM2-Stapel zwei 128-Bit-Kanäle pro Chip für insgesamt 8 Kanäle und eine Datenbusbreite von 1024 Bit umfasst.
  • In einem Ausführungsbeispiel unterstützt der Speicher 1504 den Single-Error Correcting Double-Error Detecting (SECDED) Error Correction Code (ECC) zum Schutz von Daten. ECC bietet eine höhere Zuverlässigkeit für Rechenanwendungen, die empfindlich auf Datenkorruption reagieren. Die Zuverlässigkeit ist besonders wichtig in großen Cluster-Computing-Umgebungen, in denen PPUs 1500 sehr große Datensätze verarbeiten und/oder Anwendungen über längere Zeiträume laufen lassen.
  • In einem Ausführungsbeispiel implementiert die PPU 1500 eine mehrstufige Speicherhierarchie. In einem Ausführungsbeispiel unterstützt die Speicherpartitionseinheit 1580 einen einheitlichen Speicher, um einen einzigen einheitlichen virtuellen Adressraum für CPU- und PPU 1500-Speicher bereitzustellen, wodurch die gemeinsame Nutzung von Daten durch virtuelle Speichersysteme ermöglicht wird. In einem Ausführungsbeispiel wird die Häufigkeit der Zugriffe einer PPU 1500 auf Speicher, der sich auf anderen Prozessoren befindet, nachverfolgt, um sicherzustellen, dass Speicherseiten in den physischen Speicher der PPU 1500 verschoben werden, die häufiger auf die Seiten zugreift. In einem Ausführungsbeispiel unterstützt der NVLink 1510 Adress-Übersetzungsdienste, die es der PPU 1500 ermöglichen, direkt auf die Seitentabellen einer CPU zuzugreifen, und die den vollen Zugriff der PPU 1500 auf den CPU-Speicher ermöglichen.
  • In einem Ausführungsbeispiel übertragen Copy Engines Daten zwischen mehreren PPUs 1500 oder zwischen PPUs 1500 und CPUs. Die Copy Engines können Seitenfehler für Adressen erzeugen, die nicht in den Seitentabellen abgebildet sind. Die Speicherpartitionseinheit 1580 kann dann die Seitenfehler bedienen, indem sie die Adressen in die Seitentabelle abbildet, woraufhin die Copy Engine die Übertragung durchführen kann. In einem konventionellen System ist der Speicher für mehrere Copy-Engine-Operationen zwischen mehreren Prozessoren festgelegt (z.B. nicht auslagerbar), wodurch der verfügbare Speicher erheblich reduziert wird. Bei Hardware-Seitenfehlern können Adressen an die Copy Engines übertragen werden, ohne sich Sorgen machen zu müssen, ob die Speicherseiten resident sind, und der Kopiervorgang ist transparent.
  • Daten aus dem Speicher 1504 oder einem anderen Systemspeicher können von der Speicherpartitionseinheit 1580 abgerufen und im Z2-Cache gespeichert werden, der sich auf dem Chip befindet und von den verschiedenen GPCs 1550 gemeinsam genutzt wird. Wie gezeigt, umfasst jede Speicherpartitionseinheit 1580 einen Teil des Z2-Caches, der einem entsprechenden Speichergerät 1504 zugeordnet ist. Caches niedrigerer Stufen können dann in verschiedenen Einheiten innerhalb der GPCs 950 implementiert werden. Beispielsweise kann jeder der Streaming-Multiprozessoren (SMs) in der GPC einen Cache der ersten Stufe (L1) implementieren. Der L1 -Cache ist ein privater Speicher, der für einen bestimmten SM reserviert ist. Daten aus dem Z2-Cache können abgerufen und in jedem der L1-Caches zur Verarbeitung in den Funktionseinheiten der SMs gespeichert werden. Der Z2-Cache ist mit der Speicherschnittstelle und dem XBar 1570 gekoppelt.
  • In einem Ausführungsbeispiel führt ein Host-Prozessor einen Treiberkernel aus, der eine Schnittstelle zur Anwendungsprogrammierung (API) implementiert, die es einer oder mehreren Anwendungen, die auf dem Host-Prozessor ausgeführt werden, ermöglicht, Operationen zur Ausführung auf der PPU 1500 zu planen. In einem Ausführungsbeispiel werden mehrere Rechenanwendungen gleichzeitig von der PPU 1500 ausgeführt, und die PPU 1500 bietet Isolierung, Dienstgüte (engl. Quality of Service, QoS) und unabhängige Adressräume für die mehreren Rechenanwendungen. Eine Anwendung kann Anweisungen (z.B. API-Aufrufe) erzeugen, die den Treiberkernel veranlassen, eine oder mehrere Aufgaben zur Ausführung durch die PPU 1500 zu generieren. Der Treiberkernel gibt Aufgaben an einen oder mehrere Ströme aus, die von der PPU 1500 verarbeitet werden. Jede Task kann eine oder mehrere Gruppen verwandter Threads umfassen, die hier als Warp bezeichnet werden. In einem Ausführungsbeispiel umfasst der Warp 32 verwandte Threads, die parallel ausgeführt werden können. Kooperierende Threads können sich auf eine Vielzahl von Threads beziehen, die Anweisungen zur Ausführung der Aufgabe umfassen und die Daten über einen gemeinsamen Speicher austauschen können.
  • Die PPU 1500 kann einen Desktop-Computer, einen Laptop-Computer, einen Tablet-Computer, Server, Supercomputer, ein Smartphone (z.B. ein drahtloses, tragbares Gerät), einen persönlichen digitalen Assistenten (PDA), eine Digitalkamera, ein Fahrzeug, eine am Kopf angebrachte Anzeige, ein elektronisches in der Hand haltbares Gerät und ähnliches umfassen. In einem Ausführungsbeispiel ist die PPU 1500 auf einem einzigen Halbleitersubstrat verkörpert. In einem anderen Ausführungsbeispiel ist die PPU 1500 in einem System-on-a-Chip (SoC) zusammen mit einem oder mehreren anderen Geräten wie zusätzlichen PPUs 1500, dem Speicher 1504, einer RISC-CPU (Reduced Instruction Set Computer), einer Speicherverwaltungseinheit (MMU), einem Digital-Analog-Wandler (DAC) und ähnlichem enthalten.
  • In einem Ausführungsbeispiel kann die PPU 1500 auf einer Grafikkarte enthalten sein, die ein oder mehrere Speichergeräte 1504 umfasst. Die Grafikkarte kann für die Schnittstelle mit einem PCIe-Steckplatz auf der Hauptplatine eines Desktop-Computers konfiguriert sein. In einem weiteren Ausführungsbeispiel kann die PPU 1500 eine integrierte Grafikverarbeitungseinheit (iGPU) oder ein im Chipsatz der Hauptplatine enthaltener Parallelprozessor sein.
  • Beispielhaftes Rechensystem
  • Systeme mit mehreren GPUs und CPUs werden in einer Vielzahl von Branchen verwendet, da die Entwickler mehr Parallelität in Anwendungen wie Berechnungen mit künstlicher Intelligenz aufdecken und nutzen. Hochleistungsfähige GPU-beschleunigte Systeme mit zehn- bis zu vielen tausend Rechenknoten werden in Rechenzentren, Forschungseinrichtungen und Supercomputern eingesetzt, um immer größere Probleme zu lösen. Da die Anzahl der Verarbeitungsgeräte innerhalb der Hochleistungssysteme steigt, müssen die Kommunikations- und Datenübertragungsmechanismen skaliert werden, um die erhöhte Bandbreite zu stützen.
  • 16A ist ein konzeptionelles Diagramm eines Verarbeitungssystems 1600, das unter Verwendung der PPU 1500 von 15 implementiert wurde, gemäß einem Ausführungsbeispiel. Das Verarbeitungssystem 1600 umfasst eine CPU 1630, Switch 1655 und mehrere PPUs zu je 1500 und entsprechende Speicher 1504. Der NVLink 1610 bietet Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den einzelnen PPUs 1500. Obwohl eine bestimmte Anzahl von NVLink 1610- und Interconnect-1002-Verbindungen (bei denen es sich auch um NVLINK handeln kann) in 16A gezeigt wird, kann die Anzahl der Verbindungen zu jeder PPU 1500 und der CPU 1630 variieren. Der Switch 1655 bildet die Schnittstelle zwischen dem Interconnect 1602 und der CPU 1630. Die PPUs 1500, die Speicher 1504 und NVLinks 1610 können sich auf einer einzigen Halbleiterplattform befinden, um ein paralleles Verarbeitungsmodul 1625 zu bilden. Das Verarbeitungsmodul 1625 kann auch einen OFA, wie den oben beschriebenen OFA 400, umfassen, der direkt oder indirekt mit einer oder mehreren der PPUs und dem Switch 1655 verbunden ist. In einem Ausführungsbeispiel unterstützt der Switch 1655 zwei oder mehr Protokolle als Schnittstelle zwischen verschiedenen Verbindungen und/oder Links.
  • In einem weiteren Ausführungsbeispiel bietet der NVLink 1610 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen jeder der PPUs 1500 und der CPU 1630 und der Switch 1655 Schnittstellen zwischen der Interconnect 1602 und jeder der PPUs 1500. Die PPUs 1500, die Speicher 1504 und der Interconnect 1602 können sich auf einer einzigen Halbleiterplattform befinden, um ein paralleles Verarbeitungsmodul 1625 zu bilden. In einem weiteren Ausführungsbeispiel bietet die Interconnect 1602 eine oder mehrere Kommunikationsverbindungen zwischen jeder der PPUs 1500 und der CPU 1630 und der Switch 1655 Schnittstellen zwischen jeder der PPUs 1500 unter Verwendung des NVLink 1610, um eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den PPUs 1500 bereitzustellen. In einem anderen Ausführungsbeispiel stellt der NVLink 1610 eine oder mehrere Hochgeschwindigkeits-Kommunikationsverbindungen zwischen den PPUs 1500 und der CPU 1630 über den Switch 1655 bereit. In einem weiteren Ausführungsbeispiel stellt der Interconnect 1602 eine oder mehrere Kommunikationsverbindungen zwischen den PPUs 1500 direkt zur Verfügung. Eine oder mehrere der NVLink 1610 Hochgeschwindigkeits-Kommunikationsverbindungen können als physikalische NVLink-Verbindung oder als On-Chip- oder On-Die-Verbindung implementiert werden, wobei dasselbe Protokoll wie beim NVLink 1610 verwendet wird.
  • Im Zusammenhang mit der vorliegenden Beschreibung kann sich eine einzelne Halbleiterplattform auf eine einzige einheitliche integrierte Schaltung auf Halbleiterbasis beziehen, die auf einem Die oder Chip hergestellt wird. Es ist zu beachten, dass sich der Begriff Einzel-Halbleiterplattform auch auf Multi-Chip-Module mit erhöhter Konnektivität beziehen kann, die einen On-Chip-Betrieb simulieren und wesentliche Verbesserungen gegenüber der Verwendung einer herkömmlichen Bus-Implementierung aufweisen. Natürlich können die verschiedenen Schaltungen oder Geräte auch getrennt oder in verschiedenen Kombinationen von Halbleiterplattformen nach den Wünschen des Benutzers angeordnet werden. Alternativ kann das Parallelverarbeitungsmodul 1625 als Leiterplattensubstrat implementiert werden, und jede der PPUs 1500 und/oder Speicher 1504 können als gerätegepackte Geräte ausgeführt werden. In einem Ausführungsbeispiel befinden sich die CPU 1630, der Switch 1655 und das Parallelverarbeitungsmodul 1625 auf einer einzigen Halbleiterplattform.
  • In einem Ausführungsbeispiel beträgt die Signalübertragungsrate jedes NVLink 1510 20 bis 25 Gigabit/Sekunde und jede PPU 1500 umfasst sechs NVLink 1510 Schnittstellen (wie in FIGs gezeigt). 16A-B sind fünfNVLink 1610 Schnittstellen für jede PPU 1500 enthalten). Jeder NVLink 1510 bietet eine Datenübertragungsrate von 25 Gigabyte/Sekunde in jeder Richtung, wobei sechs Links 300 Gigabyte/Sekunde bereitstellen. Die NVLinks 1510 können ausschließlich für die PPU-zu-PPU-Kommunikation verwendet werden, wie in 16A-B dargestellt, oder eine Kombination aus PPU-zu-PPU und PPU-zu-CPU, wenn die CPU 1630 auch eine oder mehrere NVLink 1510-Schnittstellen umfasst.
  • In einem Ausführungsbeispiel ermöglicht der NVLink 1510 den direkten Lade-/Speicher-/Atomistischen -Zugriff von der CPU 1630 auf den 1500 Speicher 1504 jeder PPU. In einem Ausführungsbeispiel unterstützt der NVLink 1510 Kohärenzoperationen, so dass aus den Speichern 1504 gelesene Daten in der Cache-Hierarchie der CPU 1630 gespeichert werden können, wodurch die Cache-Zugriffslatenz für die CPU 1630 reduziert wird. In einem Ausführungsbeispiel umfasst der NVLink 1510 Unterstützung für Address Translation Services (ATS), wodurch die PPU 1500 direkt auf Seitentabellen innerhalb der CPU 1630 zugreifen kann. Einer oder mehrere NVLinks 1510 können auch für den Betrieb in einem Energiesparmodus konfiguriert werden.
  • 16B zeigt ein beispielhaftes System 1600', in dem die verschiedene Architekturen und/oder Funktionalitäten der verschiedenen früheren Ausführungsbeispiele implementiert werden können. System 1600' umfasst mindestens eine Zentralverarbeitungseinheit 1630, die mit einem Kommunikationsbus 1675 verbunden ist. Der Kommunikationsbus 1675 kann unter Verwendung beliebiger geeigneter Protokolle wie PCI (Peripheral Component Interconnect), PCI-Express, AGP (Accelerated Graphics Port), HyperTransport oder jedes anderen Bus- oder Punkt-zu-Punkt-Kommunikationsprotokolls implementiert werden. Das System 1600' umfasst auch einen Hauptspeicher 1640. Steuerlogik (Software) und Daten werden im Hauptspeicher 1640 gespeichert, der die Form eines Direktzugriffsspeichers (RAM) haben kann.
  • Das System 1600' umfasst auch die Eingabegeräte 1660, das Parallelverarbeitungssystem 1625 und die Anzeigegeräte 1645, z.B. eine konventionelle CRT (Kathodenstrahlröhre), LCD (Flüssigkristallanzeige), LED (Leuchtdiode), Plasmaanzeige oder ähnliches. Benutzereingaben können von den Eingabegeräten 1660 empfangen werden, z.B. Tastatur, Maus, Touchpad, Mikrofon und dergleichen. Jedes der vorgenannten Module und/oder Geräte kann sich sogar auf einer einzigen Halbleiterplattform befinden, um das System 1600' zu bilden. Alternativ können die verschiedenen Module auch separat oder in verschiedenen Kombinationen von Halbleiterplattformen je nach Wunsch des Benutzers angeordnet sein.
  • Weiter kann das System 1600' zu Kommunikationszwecken über eine Netzwerkschnittstelle 1635 an ein Netzwerk (z.B. ein Telekommunikationsnetzwerk, lokales Netzwerk (LAN), drahtloses Netzwerk, Wide Area Network (WAN) wie das Internet, Peer-to-Peer-Netzwerk, Kabelnetzwerk oder ähnliches) gekoppelt sein.
  • Das System 1600' kann auch einen Sekundärspeicher umfassen (nicht abgebildet). Der Sekundärspeicher umfasst z.B. ein Festplattenlaufwerk und/oder ein Wechselspeicherlaufwerk, das ein Diskettenlaufwerk, ein Magnetbandlaufwerk, ein Kompaktplattenlaufwerk, ein DVD-Laufwerk, ein Aufzeichnungsgerät, einen USB-Flash-Speicher (Universal Serial Bus) repräsentiert. Das Wechseldatenträger-Laufwerk liest und/oder schreibt auf bekannte Weise von einer Wechseldatenträgereinheit.
  • Computerprogramme oder Computer-Steuerlogik-Algorithmen können im Hauptspeicher 1640 und/oder im Sekundärspeicher gespeichert sein. Wenn solche Computerprogramme ausgeführt werden, kann das System 1600' verschiedene Funktionen ausführen. Der Hauptspeicher 1640, der Speicher und/oder jeder andere Speicher sind mögliche Beispiele für computerlesbare Medien.
  • Die Architektur und/oder Funktionalität der verschiedenen vorhergehenden Figuren kann im Kontext eines allgemeinen Computersystems, eines Platinensystems, eines Spielkonsolensystems für Unterhaltungszwecke, eines anwendungsspezifischen Systems und/oder eines beliebigen anderen gewünschten Systems implementiert werden. Beispielsweise kann das System 1600" die Form eines Desktop-Computers, eines Laptops, eines Tablet-Computers, von Servern, Supercomputern, eines Smartphones (z.B. ein drahtloses, tragbares Gerät), eines persönlichen digitalen Assistenten (PDA), einer Digitalkamera, eines Fahrzeugs, einer am Kopf angebrachten Anzeige, eines tragbaren elektronischen Geräts, eines Mobiltelefons, eines Fernsehers, einer Workstation, von Spielkonsolen, eines eingebetteten Systems und/oder jeder anderen Art von Logik annehmen.
  • Innerhalb der PPU 1500 können verschiedene Programme ausgeführt werden, um die verschiedenen Stufen einer Pipeline für die Grafikverarbeitung zu implementieren. Beispielsweise kann der Gerätetreiber einen Treiberkern auf der PPU 1500 starten, um die Vertex-Shading-Stufe auf einem SM (oder mehreren SMs) durchzuführen. Der Gerätetreiber (oder der anfängliche Kernel, der von der PPU 1500 ausgeführt wird) kann auch andere Kerne auf der PPU 1500 starten, um andere Stufen der Pipeline für die Grafikverarbeitung auszuführen, z. B. die Geometrie-Schattierungsstufe und die Fragment-Schattierungsstufe. Darüber hinaus können einige der Stufen einer Pipeline für die Grafikverarbeitung auf einer festen Hardwareeinheit wie einem Rasterizer oder einem in der PPU 1500 implementierten Datenassembler implementiert sein. Es ist zu beachten, dass die Ergebnisse eines Kernels von einer oder mehreren dazwischenliegenden Hardware-Einheiten mit fester Funktionalität verarbeitet werden können, bevor sie von einem nachfolgenden Kernel auf dem SM verarbeitet werden.
  • Maschinelles Lernen (engl. Machine Learning)
  • Auf Prozessoren wie dem PPU 1500 entwickelte Deep Neural Networks (DNNs) wurden für verschiedene Anwendungsfälle verwendet, vom selbstfahrenden Auto bis zur schnelleren Medikamentenentwicklung, von der automatischen Bildbeschriftung in Online-Bilddatenbanken bis zur intelligenten Echtzeit-Sprachübersetzung in Videochat-Anwendungen. Deep Learning ist eine Technik, die den neuronalen Lernprozess des menschlichen Gehirns modelliert und dabei kontinuierlich lernt, immer intelligenter wird und mit der Zeit immer schneller genauere Ergebnisse liefert. Einem Kind wird zunächst von einem Erwachsenen beigebracht, verschiedene Formen korrekt zu identifizieren und zu klassifizieren, um schließlich in der Lage zu sein, Formen ohne jegliche Nachhilfe zu identifizieren. In ähnlicher Weise muss ein Deep Learning oder neuronales Lemsystem in Objekterkennung und -klassifizierung trainiert werden, damit es intelligenter und effizienter bei der Identifizierung von Basisobjekten, verdeckten Objekten usw. wird, während es gleichzeitig den Objekten Kontext zuordnet.
  • Auf der einfachsten Stufe schauen die Neuronen im menschlichen Gehirn auf verschiedene Eingaben, die empfangen werden, jedem dieser Eingaben werden Wichtigkeitsstufen zugeordnet, und die Ausgaben werden an andere Neuronen weitergeleitet, um darauf zu reagieren. Ein künstliches Neuron oder Perceptron ist das grundlegendste Modell eines neuronalen Netzwerks. In einem Beispiel kann ein Perceptron eine oder mehrere Eingaben erhalten, die verschiedene Merkmale eines Objekts repräsentieren, auf deren Erkennung und Klassifizierung das Perceptron trainiert wird, und jedem dieser Merkmale wird basierend auf der Bedeutung dieses Merkmals für die Definition der Form eines Objekts ein bestimmtes Gewicht zugewiesen.
  • Ein Modell eines Deep Neural Network (DNN) umfasst mehrere Schichten mit vielen verbundenen Knoten (z.B. Perceptrons, Boltzmann-Maschinen, radiale Basisfunktionen, Faltungsschichten usw.), die mit enormen Mengen an Eingabedaten trainiert werden können, um komplexe Probleme schnell und mit hoher Genauigkeit zu lösen. In einem Beispiel zerlegt eine erste Schicht des DNN-Modells ein Eingabebild eines Automobils in verschiedene Abschnitte und sucht nach Grundmustern wie Linien und Winkel. Die zweite Schicht setzt die Linien zusammen, um nach Mustern höherer Stufen wie Rädern, Windschutzscheiben und Spiegeln zu suchen. Die nächste Schicht identifiziert den Fahrzeugtyp, und die letzten paar Schichten erzeugen ein Etikett für das Eingabebild, das das Modell einer bestimmten Automobilmarke identifiziert.
  • Sobald das DNN trainiert ist, kann das DNN eingesetzt und verwendet werden, um Objekte oder Muster in einem als Inferenz bezeichneten Prozess zu identifizieren und zu klassifizieren. Beispiele für Inferenz (der Prozess, durch den ein DNN nützliche Informationen aus einer gegebenen Eingabe extrahiert) umfassen das Identifizieren handschriftlicher Nummern auf Schecks, die in Geldautomaten eingezahlt wurden, das Identifizieren von Bildern von Freunden auf Fotos, das Liefern von Filmempfehlungen an über fünfzig Millionen Benutzer, das Identifizieren und Klassifizieren verschiedener Arten von Kraftfahrzeugen, Fußgängern und Gefahren im Straßenverkehr in fahrerlosen Autos oder das Übersetzen menschlicher Sprache in Echtzeit.
  • Während des Trainierens fließen die Daten in einer Vorwärtsausbreitungsphase durch das DNN, bis eine Vorhersage erstellt wird, die ein der Eingabe entsprechendes Label anzeigt. Wenn das neuronale Netz die Eingabe nicht korrekt kennzeichnet, werden Fehler zwischen der korrekten Kennzeichnung und der vorausgesagten Kennzeichnung analysiert, und die Gewichte werden für jedes Merkmal während einer Rückwärtsausbreitungsphase angepasst, bis die DNN die Eingabe und andere Eingaben in einem trainierten Datensatz korrekt kennzeichnet. Das Trainieren komplexer neuronaler Netze erfordert massive Mengen an paralleler Rechenleistung, einschließlich Fließkomma-Multiplikationen und Additionen, die von der PPU 1500 gestützt werden. Das Inferenzieren ist weniger rechenintensiv als das Trainieren, da es sich um einen latenzempfindlichen Prozess handelt, bei dem ein trainiertes neuronales Netz auf neue Eingaben angewendet wird, die es noch nie zuvor gesehen hat, um Bilder zu klassifizieren, Sprache zu übersetzen und allgemein neue Informationen abzuleiten.
  • Neuronale Netzwerke basieren in hohem Maße auf mathematischen Matrixoperationen, und komplexe mehrschichtige Netzwerke erfordern für Effizienz und Geschwindigkeit enorme Mengen an Gleitkomma-Leistung und Bandbreite. Mit Tausenden von Verarbeitungskernen, die für Matrix-Mathematik-Operationen optimiert sind und Dutzende bis Hunderte von TFLOPS an Leistung liefern, ist die PPU 1500 eine Computerplattform, die in der Lage ist, die Leistung zu erbringen, die für auf Deep Neural Network basierende Anwendungen für künstliche Intelligenz und maschinelles Lernen erforderlich ist.
  • Beispiele technischer Vorteile einiger Ausführungsbeispiele
  • Bestimmte Ausführungsbeispiele ermöglichen die Bestimmung eines optischen Flusses in Echtzeit für Eingabe-Videostreams unter Verwendung eines hardwarebasierten Beschleunigers für einen optischen Fluss, der hier als „OFA“ bezeichnet wird. Hardware-basierte Beschleuniger für einen optischen Fluss und Stereo-Disparitätsstufenbestimmung bieten hohe Genauigkeit in Echtzeit. Die hardwarebasierte Beschleunigung ermöglicht es dem ausgegebenen optischen Fluss, getrennte optische Flusserzeugungstechniken für Hintergrund und Vordergrund zu verwenden, um die Genauigkeit zu verbessern. Die Kombination der Ausgaben verschiedener Techniken zur Erzeugung des optischen Flusses für Hintergrund und Vordergrund wird durch die Verwendung derselben Technik (z.B. SGM) als Kernregularisierer für die verschiedenen Techniken des optischen Flusses erleichtert.
  • Verschiedene konfigurierbare Optionen ermöglichen es, den Hardware-Beschleuniger für einen optischen Fluss auf Qualität oder Leistung einzustellen, so dass er an die Anforderungen bestimmter Umgebungen angepasst werden kann.
  • Durch die Bereitstellung von optischem Fluss und Stereodisparität auf demselben Chip ist der OFA in der Lage, eine Vielzahl von Anwendungen zu handhaben, einschließlich der Erzeugung von optischem Fluss und/oder Stereodisparität für autonomes Fahren oder ADAS, für Deep Learning, Video Stitching usw.
  • Der OFA ermöglicht eine hohe Leistung, indem er die Verwendung der niedrigsten erforderlichen Eingabe- und Ausgabeauflösungen, die Verwendung des am besten geeigneten Betriebsmodus (z. B. allgemeiner optischer Fluss, optischer Fluss der statischen Welt und Fusion von optischen Flüssen), die Verwendung des ROI-Modus (Region of Interest) und die Verwendung einer zusätzlichen Leistungsabstimmung ermöglicht.
  • Obwohl verschiedene Ausführungsbeispiele oben beschrieben wurden, ist zu verstehen, dass diese nur als Beispiel und nicht als Einschränkung beschrieben wurden. Daher sollte die Breite und der Umfang eines bevorzugten Ausführungsbeispiels nicht durch irgendeines der oben beispielhaft beschriebenen Ausführungsbeispiele eingeschränkt werden, sondern nur gemäß den folgenden Ansprüchen und ihren Äquivalenten definiert sein.
  • Im Lichte der obigen Lehren sind zahlreiche Modifikationen und Variationen der vorliegenden Erfindung möglich. Es ist daher davon auszugehen, dass die Erfindung im Rahmen des Umfangs der beigefügten Ansprüche auch anders als in der vorliegenden Beschreibung beschrieben ausgeführt werden kann.
  • 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 Nicht-Patentliteratur
    • „Non-parametric Local Transforms for Computing Visual Correspondence‟, in Proceedings cf the Third European Conference-Volume II on Computer Vision (ECCV ‚94), Jan-Olof Eklundh (Hrsg.), Vol. II, Springer-Verlag, London, UK, 151-158 [0057]
    • K. Yamaguchi et al, „Robust Monocular Epipolar Flow Estimation“, 2013 IEEE Conference on Computer Vision and Pattern Recognition, Portland, OR, 2013, S. 1862-1869 [0105]
    • H. Bay, T. Tuytelaars und L. V. Gool, „SURF: Speeded up robust features“, in Proc. of the 9th European Conference on Computer Vision (ECCV'06), ser. Lecture Notes in Computer Science, A. Leonardis, H. Bischof, und A. Pinz, Hrsg., Band 3951 [0109]

Claims (27)

  1. System, umfassend: Schaltungsanordnung zum Beschleunigen eines optischen Flusses, die konfiguriert ist zum: Bestimmen eines ersten optischen Flusses, der mit Eingabebildern assoziiert ist, wobei der erste optische Fluss unter Verwendung einer ersten Disparitätssuchtechnik bestimmt wird; und Bestimmen eines zweiten optischen Flusses, der mit den Eingabebildern assoziiert ist, wobei der zweite optische Fluss unter Verwendung einer zweiten Disparitäts-Suchtechnik bestimmt wird, die sich von der ersten Disparitäts-Suchtechnik unterscheidet; und mindestens einen Prozessor, der konfiguriert ist, um den ersten optischen Fluss und den zweiten optischen Fluss zu kombinieren, um einen dritten optischen Fluss zu erzeugen, der mit den Eingabebildern assoziiert ist.
  2. System nach Anspruch 1, wobei die erste Disparitäts-Suchtechnik von Kamerapositionsinformationen abhängig ist, und die zweite Disparitäts-Suchtechnik von Kamerapositionsinformationen unabhängig ist.
  3. System nach Anspruch 1 oder 2, wobei die erste Disparitäts-Suchtechnik ein Suchen entlang epipolarer Linien in jeweiligen Eingabebildern umfasst, und die zweite Disparitäts-Suchtechnik ein Suchen in einem rechteckigen Bereich in jeweiligen Eingabebildern umfasst.
  4. System nach einem der Ansprüche 1 bis 3, wobei die Schaltungsanordnung für den optischen Fluss weiter konfiguriert ist, um den ersten optischen Fluss und den zweiten optischen Fluss unter Verwenden einer gleichen Kernregularisierungs-Technik zur Glättung von Pixelabgleichkosten zu bestimmen.
  5. System nach Anspruch 4, wobei die Kernregularisierungs-Technik auf dem Semi-Global Matching (SGM) basiert.
  6. System nach einem der Ansprüche 1 bis 5, wobei die Schaltungsanordnung für den optischen Fluss und der mindestens eine Prozessor als ein System-on-a-Chip (SoC) ausgebildet sind.
  7. System nach einem der Ansprüche 1 bis 6, wobei der Prozessor so konfiguriert ist, dass er den dritten optischen Fluss durch selektives Kombinieren von Hintergrund in den Eingabebildern unter Verwendung des ersten optischen Flusses und Vordergrund in den Eingabebildern unter Verwendung des zweiten optischen Flusses erzeugt.
  8. System nach einem der Ansprüche 1 bis 7, wobei die Schaltungsanordnung des Beschleunigers für einen optischen Fluss weiter konfiguriert ist, um eine Karte des optischen Flusses zu bestimmen, die mit den Eingabebildern assoziiert ist.
  9. System nach einem der Ansprüche 1 bis 8, wobei die zweite Disparitäts-Suchtechnik die Suche in einem rechteckigen Bereich umfasst, und wobei die zweite Disparitäts-Suchtechnik weiter die Suche in jeweiligen Schichten einer Gauß'schen Pyramide von jedem der Eingabebilder umfasst.
  10. System nach einem der Ansprüche 1 bis 9, wobei die Schaltungsanordnung des optischen Flusses weiter konfiguriert ist, um einen Bewegungsvektorhinweis in der zweiten Disparitäts-Suchtechnik zu verwenden.
  11. System nach einem der Ansprüche 1 bis 10, wobei Disparitätsmessungen für die erste Disparitäts-Suchtechnik auf eindimensionalen Disparitäten basieren, die entlang epipolarer Linien gemessen werden, und Disparitätsmessungen für die zweite Disparitäts-Suchtechnik auf zweidimensionalen Disparitäten basieren, die auf einem Kostenvolumen basieren, das durch die Schaltungsanordnung zur Beschleunigung des optischen Flusses erzeugt wird, wobei jedes Element in dem erzeugten Kostenvolumen eine Disparität im zweidimensionalen Raum ist.
  12. System nach einem der Ansprüche 1 bis 11, wobei die Eingabebilder Bilder sind, die von einer GPU (Graphics Processing Unit) ausgegeben werden.
  13. System nach einem der Ansprüche 1 bis 12, wobei der Prozessor weiter konfiguriert ist, um den erzeugten dritten optischen Fluss in mindestens einem von Objektdetektion, Verfolgen von Struktur aus Bewegung (engl. structure from motion, SFM) und/oder SLAM in einer Automobilanwendung, Videostitching in einer Virtual-Reality-Anwendung, Bildraten-Aufwärtskonvertierung in einer Spielanwendung und Videoklassifizierung in einer Deep-Learning-Anwendung zu verwenden.
  14. System nach einem der Ansprüche 1 bis 13, wobei die Schaltungsanordnung zur Beschleunigung des optischen Flusses weiter konfiguriert ist, um die erste Disparitätssuche und die zweite Disparitätssuche basierend auf einem Semi-Global Matching (SGM)-Algorithmus durchzuführen.
  15. System nach Anspruch 14, wobei eine Anzahl von Durchläufen des SGM-Algorithmus konfigurierbar ist.
  16. System nach Anspruch 14 oder 15, wobei ein erster Glättungsstrafterm und ein zweiter Glättungsstrafterm, die bei der Berechnung der Pfadkosten im SGM-Algorithmus verwendet werden, konfigurierbar sind.
  17. System nach einem der Ansprüche 14 bis 16, wobei der Beschleuniger für einen optischen Fluss für mindestens einen der folgenden Zwecke konfiguriert ist: Aktivieren und Deaktivieren von gleichwinkliger Subpixelverfeinerung; Unterstützen eines Subframe-Modus zur Verringerung der Ausgabe-Latenzzeit; Unterstützen einer Aktivierung und Deaktivierung der Ausgabe einer Kostenkarte; Unterstützen einer Aktivierung und Deaktivierung eines diagonalen Pfades in Pfadkosten-Aggregationen gemäß dem SGM-Algorithmus.
  18. System nach einem der Ansprüche 1 bis 17, wobei der Prozessor konfiguriert ist, um die Schaltungsanordnung des Beschleunigers für einen optischen Fluss für jeden einer Vielzahl von Bereichen von Interesse (engl. Region Of Interest, ROI) in einem Eingabebild zu initiieren.
  19. System nach einem der Ansprüche 1 bis 18, wobei der Prozessor konfiguriert ist, um die Schaltungsanordnung des Beschleunigers für einen optischen Fluss für jeden einer Vielzahl von Teilbildern eines Einzelbildes der Eingabe zu initiieren.
  20. System nach einem der Ansprüche 1 bis 19, wobei die Schaltungsanordnung für den optischen Fluss weiter konfiguriert ist, um während der ersten Disparitätssuche oder der zweiten Disparitätssuche auf einen Off-Chip-Speicher zuzugreifen, wobei der Off-Chip-Speicher Zwischenpuffer zum Speichern von Zwischenergebnissen aus einem vorhergehenden Durchlauf der Disparitätssuche und einen Historienpuffer zum Speichern von Pfadkosten für vorhergehende Pixel umfasst.
  21. System nach einem der Ansprüche 1 bis 20, wobei die Schaltungsanordnung des optischen Flusses einen konfigurierbaren Voreinstellungsparameter für Qualität gegenüber Leistung umfasst, um eine Größe des Bewegungsvektors und/oder die Granularität der Ausgabe der Karte des optischen Flusses variabel zu steuern, wobei die variable Steuerung auf einer konfigurierbaren Gittergröße basiert, die bei der zweiten Disparitätssuche verwendet wird.
  22. System nach Anspruch 21, wobei die konfigurierbare Gittergröße eine Auswahl von Pixeln steuert, die in den Eingabebildern verarbeitet werden sollen.
  23. System nach Anspruch 21 oder 22, wobei die Gittergröße in x-Richtung und in y-Richtung unabhängig voneinander konfigurierbar ist.
  24. Verfahren zur beschleunigten Erzeugung eines optischen Flusses, wobei das Verfahren umfasst: Bestimmen eines ersten optischen Flusses, der mit Eingabebildern assoziiert ist, wobei der erste optische Fluss unter Verwenden einer ersten Disparitätssuche bestimmt wird; Bestimmen eines zweiten optischen Flusses, der mit den Eingabebildern assoziiert ist, wobei der zweite optische Fluss unter Verwenden einer zweiten Disparitätssuche bestimmt wird, die sich von der ersten Disparitätssuche unterscheidet; und Kombinieren des ersten optischen Flusses und des zweiten optischen Flusses, um einen dritten optischen Fluss zu erzeugen, der mit den Eingabebildern assoziiert ist.
  25. Ein Beschleuniger für einen optischen Fluss, umfassend: eine erste Schaltungsanordnung zum Bestimmen eines ersten optischen Flusses, der mit einem ersten und einem zweiten Eingabe-Einzelbild assoziiert ist, wobei der erste optische Fluss unter Verwenden einer ersten Disparitätssuche bestimmt wird; und eine zweite Schaltungsanordnung zur Bestimmung eines zweiten optischen Flusses, der den Eingabe-Einzelbildern assoziiert ist, wobei der zweite optische Fluss unter Verwenden einer zweiten Disparitätssuche bestimmt wird, die sich von der ersten Disparitätssuche unterscheidet, wobei sich die erste Schaltungsanordnung und die zweite Schaltungsanordnung eine gemeinsame Schaltungsanordnung zur Durchführung einer Kernregularisierungstechnik für Pixelabgleichkosten teilen.
  26. Beschleuniger für einen optischen Fluss nach Anspruch 25, wobei die erste Schaltungsanordnung konfigurierbar ist, um eine Stereodisparität auszugeben.
  27. Beschleuniger für einen optischen Fluss nach Anspruch 25 oder 26, weiter umfassend eine Schaltungsanordnung zum selektiven Aktivieren der ersten Schaltungsanordnung und der zweiten Schaltungsanordnung sequentiell nacheinander, um die Eingabe-Einzelbilder zu verarbeiten.
DE102020122943.7A 2019-09-03 2020-09-02 Hardware-basierte beschleunigung eines optischen flusses Pending DE102020122943A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/558,788 US11430134B2 (en) 2019-09-03 2019-09-03 Hardware-based optical flow acceleration
US16/558,788 2019-09-03

Publications (1)

Publication Number Publication Date
DE102020122943A1 true DE102020122943A1 (de) 2021-03-04

Family

ID=74564626

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020122943.7A Pending DE102020122943A1 (de) 2019-09-03 2020-09-02 Hardware-basierte beschleunigung eines optischen flusses

Country Status (2)

Country Link
US (1) US11430134B2 (de)
DE (1) DE102020122943A1 (de)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10764561B1 (en) 2016-04-04 2020-09-01 Compound Eye Inc Passive stereo depth sensing
US11336750B1 (en) * 2019-06-10 2022-05-17 EMC IP Holding Company LLC Remote procedure calls that offload search pattern matching from clients to servers
EP4066162A4 (de) 2019-11-27 2023-12-13 Compound Eye Inc. System und verfahren zur bestimmung von korrespondenzkarten
US11270467B2 (en) 2020-01-21 2022-03-08 Compound Eye, Inc. System and method for camera calibration
US11069071B1 (en) * 2020-01-21 2021-07-20 Compound Eye, Inc. System and method for egomotion estimation
US11710247B2 (en) * 2020-01-30 2023-07-25 Unity Technologies Sf System for image compositing including training with synthetic data
US20210304457A1 (en) * 2020-03-31 2021-09-30 The Regents Of The University Of California Using neural networks to estimate motion vectors for motion corrected pet image reconstruction
CN113542712A (zh) * 2020-04-16 2021-10-22 钰立微电子股份有限公司 多深度信息的处理方法与处理系统
US11460854B1 (en) * 2020-04-28 2022-10-04 Amazon Technologies, Inc. System to determine floor or obstacle by autonomous mobile device
DE102020213587A1 (de) * 2020-10-29 2022-05-05 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Verknüpfen von optischen Fluss über eine Mehrzahl von Bildern einer Bilderfassungseinrichtung
CN114494087A (zh) * 2020-11-12 2022-05-13 安霸国际有限合伙企业 无监督的多尺度视差/光流融合
JP7451456B2 (ja) * 2021-03-22 2024-03-18 株式会社東芝 運動推定装置及びそれを用いた運動推定方法
US20220342702A1 (en) * 2021-04-26 2022-10-27 GM Global Technology Operations LLC Real-time scheduling for a heterogeneous multi-core system
US11882262B2 (en) * 2021-11-08 2024-01-23 Foresight Automotive Ltd. System and method for stereoscopic image analysis

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3679426B2 (ja) * 1993-03-15 2005-08-03 マサチューセッツ・インスティチュート・オブ・テクノロジー 画像データを符号化して夫々がコヒーレントな動きの領域を表わす複数の層とそれら層に付随する動きパラメータとにするシステム
US8897546B2 (en) * 2011-09-29 2014-11-25 Texas Instruments Incorporated Semi-global stereo correspondence processing with lossless image decomposition
JP5365823B2 (ja) * 2011-10-14 2013-12-11 株式会社モルフォ 画像合成装置、画像合成方法、画像合成プログラム及び記録媒体
JP6121776B2 (ja) * 2013-03-29 2017-04-26 ソニー株式会社 画像処理装置及び画像処理方法
GB2523149A (en) * 2014-02-14 2015-08-19 Nokia Technologies Oy Method, apparatus and computer program product for image-driven cost volume aggregation
US20150262380A1 (en) * 2014-03-17 2015-09-17 Qualcomm Incorporated Adaptive resolution in optical flow computations for an image processing system
US10268901B2 (en) * 2015-12-04 2019-04-23 Texas Instruments Incorporated Quasi-parametric optical flow estimation
US10212364B2 (en) * 2015-12-15 2019-02-19 Canon Kabushiki Kaisha Zoom control apparatus, image capturing apparatus and zoom control method
JP6795027B2 (ja) * 2016-03-15 2020-12-02 株式会社リコー 情報処理装置、物体認識装置、機器制御システム、移動体、画像処理方法およびプログラム
US10467768B2 (en) * 2017-04-07 2019-11-05 Intel Corporation Optical flow estimation using 4-dimensional cost volume processing
JP6986683B2 (ja) * 2018-01-05 2021-12-22 パナソニックIpマネジメント株式会社 視差値算出装置、視差値算出方法及びプログラム
US10977802B2 (en) * 2018-08-29 2021-04-13 Qualcomm Incorporated Motion assisted image segmentation
US11508079B2 (en) * 2019-06-28 2022-11-22 Intel Corporation Parallelism in disparity map generation

Also Published As

Publication number Publication date
US20210065379A1 (en) 2021-03-04
US11430134B2 (en) 2022-08-30

Similar Documents

Publication Publication Date Title
DE102020122943A1 (de) Hardware-basierte beschleunigung eines optischen flusses
US10986325B2 (en) Scene flow estimation using shared features
US20210150736A1 (en) Learning rigidity of dynamic scenes for three-dimensional scene flow estimation
DE102018132069A1 (de) Äquivariante Orientierungspunkt-Transformation für Orientierungspunkt-Lokalisierung
DE102018108324A1 (de) System und Verfahren zur Schätzung eines optischen Flusses
DE102019130889A1 (de) Schätzung der tiefe eines mit einer monokularen rgb-kamera aufgenommenen videodatenstroms
US11328173B2 (en) Switchable propagation neural network
DE102019103310A1 (de) Schätzer for einen optimalen betriebspunkt für hardware, die unter einer beschränkung der gemeinsam genutzten leistung/wärme arbeitet
DE102019102009A1 (de) Reduzierung des rauschens während des renderings durch parallele path-space-filterung unter verwendung von hashing
DE102022100360A1 (de) Framework für maschinelles lernen angewandt bei einer halbüberwachten einstellung, um instanzenverfolgung in einer sequenz von bildframes durchzuführen
DE102021121109A1 (de) Wiederherstellung dreidimensionaler modelle aus zweidimensionalen bildern
DE102018114799A1 (de) Halbüberwachtes lernen zur orientierungspunktlokalisierung
DE102018108314A1 (de) Durchführen einer autonomen Pfadnavigation unter Verwendung tiefer neuronaler Netzwerke
DE102021205690A1 (de) Trainieren neuronaler Netze mit begrenzten Daten unter Verwendung invertierbarer Augmentationsoperatoren
DE102018123761A1 (de) Sicherung gegen fehler in einem fehlerkorrekturcode (ecc), der in einem kraftfahrzeugsystem implementiert ist
DE102022118651A1 (de) Mehrfachauflösung-hash-codierung für neuronale netzwerke
DE102019103319A1 (de) Stochastisches runden von zahlenwerten
DE102022121509A1 (de) Einzelbild-inversrendering
DE102023104326A1 (de) Hierarchisches netzwerk für gestapeltes speichersystem
DE102020101525A1 (de) Blind-spot-faltungsarchitekturen und bayessche bildwiederherstellung
DE102022107232A1 (de) Gepackter fehlerkorrekturcode (ecc) für komprimierten datenschutz
DE102021128286A1 (de) Adaptives abtasten mit einer zielabtastrate
DE112019001978T5 (de) Verbesserung des realismus von szenen mit wasseroberflächen beim rendern
DE102021114013A1 (de) Techniken zum effizienten abtasten eines bildes
DE102021116231A1 (de) Störimpuls-freier multiplexer

Legal Events

Date Code Title Description
R012 Request for examination validly filed