An FPGA Implementation of Displacement Vector Search for Intra Pattern Copy in JPEG XS

Diese Arbeit stellt eine effiziente, pipelinierte FPGA-Architektur für die Verschiebungsvektorsuche im Intra-Pattern-Copy-Modul von JPEG XS vor, die durch optimierte Speicherorganisation eine hohe Durchsatzrate von 38,3 Megapixeln pro Sekunde bei geringem Energieverbrauch erreicht und somit die praktische Hardware-Implementierung ermöglicht.

Das Wesentliche

Stellen Sie sich vor, Sie versuchen, ein riesiges, hochauflösendes Foto zu versenden, aber Ihre Internetleitung ist sehr langsam. Das ist das Problem, das JPEG XS lösen soll: Es ist ein neuer Standard, der Bilder so komprimiert, dass sie schnell übertragen werden können, ohne dass es zu lange dauert (niedrige Latenz). Das ist besonders wichtig für Dinge wie Fernsteuerung von Computern oder Videokonferenzen.

In diesem Papier geht es um eine spezielle Technik namens „Intra Pattern Copy" (IPC). Hier ist die einfache Erklärung, was die Autoren gemacht haben, mit ein paar anschaulichen Vergleichen:

1. Das Problem: Die große Suche

Stellen Sie sich das Bild als ein riesiges Puzzle vor. Die IPC-Technik versucht, Teile des Puzzles zu finden, die sich bereits im Bild befinden, und sagt: „Hey, dieses kleine Teil hier ist fast identisch mit jenem Teil da oben links. Wir müssen es nicht neu beschreiben, wir sagen einfach nur: Kopiere es von dort!"

Um das zu tun, muss der Computer eine Suche durchführen. Er muss herausfinden: „Wo genau ist das Originalteil?" Diese Suche nennt man Displacement Vector Search (Verschiebungsvektor-Suche).

Das Problem: Diese Suche ist extrem rechenintensiv. Es ist, als würde man in einer riesigen Bibliothek nach einem bestimmten Buch suchen, indem man jedes Regal einzeln und manuell durchsucht. Das dauert ewig und verbraucht viel Energie. Für echte Hardware (wie Chips in Kameras oder Routern) war das bisher zu langsam und zu kompliziert.

2. Die Lösung: Ein hochleistungsfähiger Such-Roboter (FPGA)

Die Autoren haben einen speziellen Chip (einen FPGA) entwickelt, der diese Suche extrem schnell erledigt. Man kann sich diesen Chip wie einen hochspezialisierten Such-Roboter vorstellen, der in der Bibliothek arbeitet.

Hier sind die zwei genialen Tricks, die sie benutzt haben:

Trick A: Die Fließband-Produktion (Pipelining)

Statt dass der Roboter ein Buch sucht, prüft, das nächste sucht, prüft usw. (eins nach dem anderen), haben die Autoren ein Fließband gebaut.

• Stufe 1: Der Roboter holt sich ein Buch.
• Stufe 2: Während er das erste Buch prüft, holt er sich schon das zweite.
• Stufe 3: Während er das zweite prüft, wird das erste verglichen.
• Stufe 4: Das Ergebnis wird ausgegeben, und das dritte Buch kommt rein.

Dadurch läuft die Suche wie ein gut geölter Motor: Es gibt keine Wartezeiten. Das nennt man Pipelining.

Trick B: Die intelligente Bibliotheksordnung (Speicher-Optimierung)

Stellen Sie sich vor, die Bücher (die Bilddaten) sind in der Bibliothek chaotisch verstreut. Um ein Kapitel zu finden, müsste man erst zum Regal A, dann zu Regal Z, dann zurück zu Regal B laufen. Das ist ineffizient.

Die Autoren haben die Bibliothek neu organisiert (Method 1):

• Sie haben alle Bücher, die zusammengehören (gleiche Bildteile), direkt nebeneinander auf einen Stapel gelegt.
• Statt zu suchen, wo was liegt, weiß der Roboter genau: „Wenn ich bei Buch Nr. 100 starte, sind die nächsten 10 Bücher direkt daneben."
• Sie haben sogar ein kleines Verzeichnis im Kopf des Roboters (eine Art „TLB" oder Adressbuch), das ihm sofort sagt, wie groß die Bücherstapel sind.

Dadurch muss der Roboter nicht mehr herumlaufen und suchen, sondern kann einfach einen ganzen Stapel auf einmal greifen. Das spart Zeit und Energie.

3. Das Ergebnis: Schnell und sparsam

Was haben sie erreicht?

• Geschwindigkeit: Ihr Roboter kann 38,3 Millionen Bildpunkte pro Sekunde verarbeiten. Das ist sehr schnell!
• Energie: Er verbraucht nur 277 Milliwatt. Das ist weniger als eine kleine LED-Lampe.
• Vergleich: Im Vergleich zu ihrer alten, weniger optimierten Version (Method 0) ist die neue Version nicht nur schneller, sondern auch effizienter im Energieverbrauch.

Zusammenfassung für den Alltag

Stellen Sie sich vor, Sie wollen ein Video auf einem Handy streamen. Dank dieser neuen Technik kann das Handy die Bilder so clever komprimieren, dass es keine Ruckler gibt (niedrige Latenz) und der Akku nicht sofort leer ist (niedriger Energieverbrauch).

Die Autoren haben also im Grunde einen super-schnellen, energieeffizienten Such-Assistenten gebaut, der Bilder in Echtzeit analysiert und die besten Kopien findet, damit wir Videos flüssig streamen können, ohne dass die Technik überhitzt. Das ist ein wichtiger Schritt, um diese Technologie in echte Geräte (wie ASICs) einzubauen.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „An FPGA Implementation of Displacement Vector Search for Intra Pattern Copy in JPEG XS" auf Deutsch:

1. Problemstellung

Das Paper adressiert die Herausforderungen bei der Hardware-Implementierung des Intra Pattern Copy (IPC)-Tools im Bildkompressionsstandard JPEG XS. JPEG XS wurde für Anwendungen mit geringer Latenz und geringer Komplexität entwickelt, wie z. B. Remote-Desktops und KVM-Systeme.

• Hintergrund: IPC reduziert räumliche Redundanzen in Bildschirminhalten durch Vorhersagen im Wavelet-Bereich. Dabei werden Wavelet-Koeffizienten in Gruppen (IPC Groups und IPC Units) eingeteilt und basierend auf einem Verschiebungsvektor (Displacement Vector, DV) aus rekonstruierten Precincts vorhergesagt.
• Die Herausforderung: Der DV-Suchprozess ist der rechenintensivste, ressourcenhungrigste und latenzkritischste Teil des IPC-Algorithmus. Er muss alle möglichen Kandidaten durchlaufen, um den optimalen Vorhersageoffset zu finden, der die Kodierkosten minimiert.
• Lücke: Bisherige FPGA- und ASIC-Implementierungen für Bewegungsabschätzung (Motion Estimation) und Intra-Vorhersage (z. B. in H.264/HEVC) basieren auf Pixelblöcken und regelmäßigen Speicherzugriffen. Sie sind nicht für die spezifischen, gruppierten und frequenzdomänenbasierten Vorhersageflüsse von JPEG XS IPC geeignet, was die praktische Hardware-Einführung behindert.

2. Methodik und Architektur

Die Autoren schlagen eine optimierte, pipelinierte FPGA-Architektur vor, die speziell für den DV-Suchprozess im JPEG XS IPC-Rahmenwerk entwickelt wurde.

A. Top-Level-Architektur

Das System besteht aus zwei Hauptkomponenten:

1. Residual Calculation Engine (Restberechnung):
   • Lädt originale und rekonstruierte Wavelet-Koeffizienten aus dem DRAM.
   • Berechnet blockweise Residuen (Differenzen zwischen Original und Vorhersage).
   • Nutzt FIFO-Puffer (Q0–Q3 für Original, C0–C3 für Rekonstruktion) für vier parallele IPC-Gruppen.
   • Berechnet vorzeichenbehaftete Residuen mittels paralleler Subtraktionspfade.
2. DV Comparison Engine (DV-Vergleich):
   • Bewertet die Bit-Kosten (GCLI-Kosten) der Residuen.
   • Sucht den optimalen DV durch Vergleich der geschätzten Bit-Planen-Anzahl.
   • Vierstufiges Pipeline-Design:
     • Stufe 0: Eingabe von Residuen und Parametern; Generierung von Konfigurationsdaten.
     • Stufe 1: Berechnung eines Bitwise-OR-Masks über die Gruppe (GetOrMask).
     • Stufe 2: Bit-Level-GCLI-Berechnung (CalGCLI) zur Ermittlung der Test-Bits.
     • Stufe 3: Vergleich der aktuellen Kosten mit dem bisherigen Minimum und Aktualisierung des besten DV (Compare & Update).

B. Optimierte Speicherorganisation

Ein zentraler Aspekt ist die Lösung des Problems der verstreuten Wavelet-Koeffizienten:

• Method 0 (Baseline): Speichert Daten precinct-basiert. Dies führt zu ineffizienten Zugriffen, da Blöcke aus verschiedenen Sub-Bands verstreut sind und individuelle Adressberechnungen erfordern.
• Method 1 (Vorgeschlagen): Organisiert die Daten nach IPC-Gruppen und -Units.
  • Alle Sub-Band-Blöcke einer IPC-Unit werden sequentiell gespeichert.
  • Dies ermöglicht das Laden ganzer Blöcke mit einer Basisadresse plus einem festen Offset.
  • Eine On-Chip Translation Lookaside Buffer (TLB) speichert die Längen der variablen Blockgrößen, um die Adressgenerierung zu beschleunigen und Burst-Zugriffe auf den DRAM zu erleichtern.

3. Hauptbeiträge

1. Erste FPGA-Architektur für DV-Suche in JPEG XS IPC: Das Paper stellt erstmals eine Hardware-Architektur für diesen spezifischen Algorithmus vor, die eine vierstufige Pipeline nutzt, um Durchsatz und Latenz auszubalancieren.
2. Neuartige Speicherorganisation: Durch die Neustrukturierung des Speichers nach Gruppen/Units und die Nutzung einer TLB wird die Speicherzugriffseffizienz drastisch verbessert und die Kontrollkomplexität reduziert.
3. Parallele Verarbeitung: Die Architektur ermöglicht die parallele Berechnung von Residuen und den Vergleich von DVs über mehrere IPC-Gruppen hinweg.

4. Experimentelle Ergebnisse

Die Implementierung wurde auf einem Xilinx Artix-7 (XC7A35T) bei 100 MHz durchgeführt.

• Durchsatz: Erreicht 38,3 Mpixels/s.
• Leistungsaufnahme: 277 mW.
• Latenz: 73,01 ms (konsistent mit der Referenz-Software).
• Ressourcennutzung:
  • Der DV-Vergleich (insbesondere GCLI CAL) dominiert die Logiknutzung (11,63 K LUTs, 19,98 K FFs, 17 DSPs).
  • Im Vergleich zur Baseline (Method 0) konnte der Durchsatz um 6,1 % gesteigert werden, während die Leistungseffizienz auf 138,27 Mpixels/s/W verbessert wurde.
  • Die Ressourcennutzung (LUTs und FFs) sank um ca. 7,5 % bzw. 8,4 %, bei einem moderaten Anstieg des BRAM-Verbrauchs.

5. Bedeutung und Ausblick

Die Arbeit demonstriert die Praktikabilität einer Hardware-Implementierung des DV-Suchmoduls für JPEG XS, was bisher aufgrund der hohen Komplexität ein Engpass war.

• Die vorgeschlagene Architektur bietet eine solide Grundlage für zukünftige ASIC-Entwicklungen.
• Sie ermöglicht die effiziente Nutzung von IPC in Echtzeitanwendungen mit begrenzter Leistungsaufnahme (Power-constrained).
• Die Ergebnisse zeigen, dass durch spezialisierte Pipelines und optimierte Speicherstrukturen auch komplexe Wavelet-domänenbasierte Vorhersagen effizient auf FPGAs realisiert werden können.

Zusammenfassend liefert das Paper einen entscheidenden Schritt zur Hardware-Realisierung von JPEG XS für anspruchsvolle Anwendungen wie Remote-Desktops, indem es den rechenintensivsten Teil des Algorithmus hardwarebeschleunigt und optimiert.