Bachelorarbeit Parameteroptimierung des H.265/HEVCs f ur ... · ter des H.265/HEVCs mit der RExt...

Friedrich-Alexander-Universitat Erlangen-Nurnberg

Lehrstuhl fur Multimediakommunikation und

Signalverarbeitung

Prof. Dr.-Ing. Andre Kaup

Bachelorarbeit

Parameteroptimierung des H.265/HEVCsfur die verlustfreie Kompression

medizinischer Datensatze

von Osman Demir

September 2017

Betreuer: M.Sc. Karina Jaskolka

Sara Ates

Erklarung

Ich versichere, dass ich die vorliegende Arbeit ohne fremde Hilfe und

ohne Benutzung anderer als der angegebenen Quellen angefertigt habe,

und dass die Arbeit in gleicher oder ahnlicher Form noch keiner anderen

Prufungsbehorde vorgelegen hat und von dieser als Teil einer Prufungs-

leistung angenommen wurde. Alle Ausfuhrungen, die wortlich oder sinn-

gemaß ubernommen wurden, sind als solche gekennzeichnet.

————————————

Ort, Datum

————————————

Unterschrift

INHALTSVERZEICHNIS I

Inhaltsverzeichnis

Kurzfassung IV

Abkurzungsverzeichnis V

Formelzeichen VII

1 Einleitung 1

2 Stand der Technik 3

2.1 Bildkompression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 H.265/HEVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Vorstellung der Erweiterung RExt . . . . . . . . . . . . . . . . . . . . . 11

2.4 Vorstellung der Erweiterung SCC . . . . . . . . . . . . . . . . . . . . . 14

2.5 Parameter fur eine verlustfreie Kompression . . . . . . . . . . . . . . . 17

3 Auswertung 19

3.1 Eigenschaften der Sequenzen und vorgehen bei der Parameteroptimierung 19

3.2 Bittiefe von 8 Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2.1 Voreinstellungen fur die 8 Bit pro Pixel Sequenzen . . . . . . . . 22

3.2.2 Optimierung der Unit definierenden Parameter . . . . . . . . . . 22

3.2.3 Optimierung der Codierstruktur Parameter . . . . . . . . . . . . 24

3.2.4 Optimierung der Bewegungsabschatzung . . . . . . . . . . . . . 25

3.2.5 Parameter fur die Quantisierung . . . . . . . . . . . . . . . . . . 26

3.2.6 Optimierung der Loopfilter Parameter . . . . . . . . . . . . . . 27

3.2.7 Optimierung der Slice und Rate Control Parameter . . . . . . . 27

3.2.8 Optimierung der Codier-Tool Parameter . . . . . . . . . . . . . 28

3.2.9 Veranschaulichung der Bedeutung der RExt Parameter . . . . . 30

3.2.10 Vergleich der Grundeinstellungen mit dem optimierten Fall . . . 31

3.3 Bittiefe von 12 Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.3.1 Voreinstellungen fur die 12 Bit pro Pixel Sequenzen . . . . . . . 34

3.3.2 Optimierung der Parameter

QuadtreeTUMaxDepthIntra und QuadtreeTUMaxDepthInter . 34

3.3.3 Einfluss der Parameter FastSearch, SearchRange und Bipred-

SearchRange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3.4 Veranschaulichung der Bedeutung der RExt Parameter fur jede

Sequenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.3.5 Ergebnisse des Kompressionsverhaltnisses und des Speicherbedarfs 39

3.4 Vergleich mit dem SCC . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Zusammenfassung und Ausblick 47

A Anhang 51

A.1 Anhang 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

A.2 Anhang 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

A.3 Anhang 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Abbildungsverzeichnis 57

Tabellenverzeichnis 61

Literaturverzeichnis 63

KURZFASSUNG III

Kurzfassung

Zentraler Inhalt der Arbeit ist die komprimierende Wirkung der einzelnen Parame-

ter des H.265/HEVCs mit der RExt Erweiterung auf die medizinischen Datensatze.

Zunachst werden die Grundlagen des Coders H.265/HEVC und seiner Erweiterung

RExt veranschaulicht. Hinzu kommt ein Uberblick uber die SCC Erweiterung. Im an-

schließenden Teil wird Schritt fur Schritt die verlustfreie Kompression fur die funf

Sequenzen optimiert. Als Nachstes folgt ein Vergleich zwischen den Anfangseinstellun-

gen, Grundeinstellungen und den optimierten Einstellungen. Hinzu kommt, dass die

Wirkung der RExt Parameter veranschaulicht wird. Im folgenden Abschnitt wird die

Kompressionsperformance des SCC mit dem der RExt Erweiterung verglichen. Ab-

schließend werden universelle Parameter und eine Kompromisslosung veranschaulicht,

welche in der Praxis fur jede medizinische Sequenz angewendet werden kann, um ein

moglichst hohes Kompressionsverhaltnis zu erhalten.

ABKURZUNGSVERZEICHNIS V

Abkurzungsverzeichnis

ACQP Adaptive Chroma Quantization Parameter

ACT Adaptive color transformation

AMP Asymmetric motion partitions

AMVR Adaptive motion vector resolution

AVC Advanced Video Coding

BV Bewegungsvektor

CABAC Context-adaptive binary arithmetic coding

CAVLC Context-adaptive variable length coding

CB Coding block

CCP Cross-Component Predicition

CRA Clean random access

CT Computertomographie

CTB Coding tree blocks

CTU Coding tree units

CU Coding unit

E-Health elektronische Datenverarbeitung im Gesundheitswesen

FEN Fast encoder

FDM Fast encoder decision mode

GIF Graphics Interchange Format

GOP Group Of Pictures

HEVC High Efficiency Video Coding

IBC Intra-Block-Copy

VI

JCT-VC Joint Collaborative Team on Video Coding

JPEG Joint Photographic Experts Group

MPEG Moving Picture Experts Group

MRT Magnetresonanztomographie

PCM Pulse-Code-Modulation

PNG Portable Network Graphics

PPS Picture parameter setting

PU Prediction unit

RDPCM Residual Diffential Pulse Code Modulation

RExt Range Extension

RGB-Farbraum Rot-Grun-Blau-Farbraum

SAD Sum of absolute differences

SAO Sample adaptive offset

SCC Screen Content Coding

SPS Sequenz-Parameter-Set

TB Transform block

TU Transform unit

TZSearch schnelle Suche

VCEG Video Coding Experts Group

WPP Wavefront parallel processing

FORMELZEICHEN VII

Formelzeichen

d horizontale oder vertikale Richtungsachse des Restblocks

n Anzahl darstellbarer Farben

rd(x, y) Element des Restblock

B Blaue Komponente im RGB-Farbraum

Bi Bit

Cg Grune Chrominanz im Y CoCg − Farbraum

Co Orange Chrominanz im Y CoCg − Farbraum

G Grune Komponente im RGB-Farbraum

R Rote Komponente im RGB-Farbraum

Y Luminanz im Y CoCg − Farbraum

KAPITEL 1. EINLEITUNG 1

Kapitel 1

Einleitung

Der H.265/HEVC (High Efficiency Video Coding), mit dem man Bilder und Videos

komprimieren kann, ist ein wichtiger Bestandteil der Unterhaltungsbranche. Er ist der

Nachfolger des H.264/AVCs (Advanced Video Coding), der in vielen Geraten zur Kom-

primierung genutzt wird und soll dessen komprimierende Wirkung verbessern. Da-

durch, dass der Coder H.265/HEVC nun auch verbessert verlustlos Daten verkleinern

kann, ist er im Bereich der Medizintechnik interessant geworden. Durch eine Anpas-

sung der Parameter des H.265/HEVCs fur medizinische Datensatze sollte eine gute

Kompression ermoglicht werden.

Die Motivation fur dieses Thema entstand dadurch, dass in der Medizin zur Hilfe fur die

Arzte zahlreiche medizinische Volumendaten mittels Computertomographie (CT) oder

Magnetresonanztomographie (MRT) aufgenommen werden. Die dadurch entstehende

Menge von Datensatzen und deren Große ergibt einen enormen Speicheraufwand. Hinzu

kommt die besondere Gesetzeslage in der Medizin, die dazu verpflichtet, solche Daten

fur mehrere Jahre und in besonderen Fallen sogar bis zu mehreren Jahrzehnten aufzube-

wahren. Durch die verlustlose Kompression ist es moglich, die rechtlichen Gesetze nicht

zu verletzen und trotzdem die benotigte Speicherkapazitat zu verkleinern. Ein weiterer

Vorteil ist die verbesserte Ubermittlung an Facharzte, die durch die verkleinerten Da-

tensatze erleichtert wird. Normalerweise nutzt man hierfur CDs als Speichermedium.

Durch die verkleinerte Datei konnte die Ubermittlung auch anderes stattfinden. Großes

2

Potenzial hatte diese Anwendung im Bereich der elektronischen Datenverarbeitung im

Gesundheitswesen (E-Health), wo die Sequenzen direkt in die elektronische Patienten-

akte einfugt werden konnten. In dieser Arbeit werden funf Sequenzen ausgewertet und

evaluiert. Dabei handelt es sich um 2 CT- und 3 MRT-Aufnahmen.

Im zweiten Kapitel wird eine Einfuhrung und Erklarung zum H.265/HEVC und seine

Unterschiede zum H.264/AVC aufgezeigt. Anschließend werden die Erweiterung Range

Extension (RExt) und Screen Content Coding (SCC) vorgestellt, die in dieser Arbeit

genutzt werden. Wichtig hierbei sind die zu beachtenden Parameter fur eine verlust-

freie Datenverkleinerung.

Das dritte Kapitel ist der Kern dieser Arbeit. Hier werden die optimierten Parameter

fur einen Datensatz mithilfe des H.265/HEVCs und seiner Erweiterung RExt vorge-

stellt und anschließend bewertet. Zusatzlich findet eine Evaluierung des Screen Content

Coding statt, um die Unterschiede veranschaulichen zu konnen.

Im vierten Kapitel wird abschließend ein Ausblick und eine Zusammenfassung verfasst.

KAPITEL 2. STAND DER TECHNIK 3

Kapitel 2

Stand der Technik

2.1 Bildkompression

In diesem Abschnitt wird kurz die Bild- und Videokompression erklart. Die Bildkom-

pression verkleinert die benotigte Speichermenge einer Datei. Hierbei gibt es zwei Un-

terscheidungen: Zum einen die verlustbehaftete Kompression und zum anderen die

verlustfreie Kompression. Wahrend im verlustfreien Fall nur die Redundanzen erkannt

und entfernt werden, werden in der verlustbehaftete Komprimierung zusatzlich fur das

Auge nicht erkennbare Daten entfernt. Bei der verlustbehafteten Kompression kann

das Bild nicht mehr 1 : 1 wiederhergestellt werden. Redundanzen konnen durch die

Speicherung in einem Worterbuch eingespart werden. Die Fehler, die bei einer zu star-

ken Kompression entstehen konnen, nennt man Artefakte. Bekannte Programme, die

zur Bildkompression genutzt werden sind, JPEG (Joint Photographic Experts Group),

PNG (Portable Network Graphics) und GIF (Graphics Interchange Format) [1].

Die Videokompression komprimiert im einfachsten Fall jedes Bild unabhangig vonein-

ander (Intraframe-Kompression). Komplexere Verfahren nutzen Informationen mehre-

rer aufeinanderfolgender Bilder zur Codierung der Videodatei

(Interframe-Kompression) [2]. Die Kompression der Sequenzen ahnelt dem Vorgehen

der Videokompression.

4

2.2 H.265/HEVC

Der H.265/HEVC ist im Moment der neueste Coder fur die Komprimierung von Bild-

und Videodaten. Er wurde von der Joint Collaborative Team on Video Coding (JCT-

VC) entwickelt und ist der Nachfolger des H.264/AVCs. Die JCT-VC ist eine Koope-

ration zwischen der ITU-T Video Coding Experts Group (VCEG) und der ISO/IEC

Moving Picture Experts Group (MPEG). Vergleicht man den H.265/HEVC mit dem

H.264/AVC, erkennt man, dass die Codiereffizienz verbessert wird. Die Datensicherheit

wurde erhoht und die parallele Verarbeitungsfahigkeit des Coder wurde gesteigert [3].

Nun wird die allgemeine Funktionsweise des H.265/HEVCs erlautert und anschließend

einige Erneuerungen veranschaulicht.

Eine der Gemeinsamkeiten des H.265/HEVCs mit seinem Vorganger ist, dass der Video

Coding Layer vom H.265/HEVC die gleiche hybrid codierende Struktur besitzt wie der

H.264/HEVC. Zur Codierung wird eine inter- und intrapicture Pradiktion und eine 2-D

Transformation verwendet. In der Abbildung 2.1 kann man ein sogenanntes Blockdia-

gramm von einem hybriden Video Encoder betrachten. Dieser veranschaulicht, wie man

einen Bitstream durch die Anwendung des H.265/HEVCs kreiert. Das Ziel der Para-

meteroptimierung ist es, diesen Bitstream zu minimalisieren und den Speicheraufwand

zu verringern [3].

Wie der H.265/HEVC einen Bitstream anfertigt wird im Folgenden mithilfe der Ab-

bildung 2.1 beschrieben.

Zunachst wird das Bild in CTUs (coding tree units) unterteilt. Die Rechtecke wer-

den dem Coder ubermittelt. Anschließend wird das Bild mithilfe von verschiedenen

Schritten komprimiert. Das erste Bild einer Sequenz nutzt zur Pradiktion nur Da-

ten innerhalb des ersten Bildes. Dies bezeichnet man als intrapicture pradiktive Co-

dierung (Block Intra-Picutre Estimation/Prediction Abbildung 2.1). Fur die meisten

folgenden Bilder einer Sequenz wird das interpicture zeitlich pradiktive Codiermodel

angewendet. Die interpicture Pradiktion nutzen zur Bestimmung der Blocke nicht nur

Informationen des momentan betrachtenden Bildes sondern ist bildubergreifend. Um

2.2. H.265/HEVC 5

Abbildung 2.1: Typischer HEVC Video Encoder [3]

eine Pradiktion berechnen zu konnen benotigt man Informationen. Diese Daten erhalt

der Coder durch die Bewegungsdaten und Bewegungsvektoren, anhand derer man die

Samples in jedem Block berechnen kann. Ein wichtiges Hilfsmittel zur Vermeidung von

Fehlern ist die Bewegungskompensation. Die Bewegungskompensation (engl. Motion

Compensation; Abbildung 2.1) soll die Ungenauigkeiten, die durch eine Bewegung ent-

stehen, kompensieren. Fur die Berechnung der Kompensation benotigt der Coder die

Bewegungsvektoren und die Daten der Mode-Entscheidung. Das Ergebnis der Bewe-

gungskompensation wird als Seiteninformation vermittelt und generiert interpicture

pradiktive Signale, die dem Decoder und Encoder ubermittelt werden. Ein Problem

der Pradiktion ist, dass die Signale nur geschatzt werden und somit verlustbehaftet

sind. Um diesen Verlust zu beseitigen, nutzt man das sogenannte Restsignal. Dieses

Restsignal von intra- oder interpicture Pradiktion wird durch die Differenz des Orginal-

bildes und seiner Schatzung bestimmt und anschließend mit einer linearen raumlichen

Transformation transformiert. Ohne die Berechnung des Restsignals ware eine verlust-

6

freie Kompression nicht moglich. Nun werden die Blocke Transformation (Transform),

Skalierung (Scaling) und Quantisierung (Quantization), die in der Abbildung 2.1 zu se-

hen sind, naher erlautert. Die ermittelten Transformationskoeffizienten werden skaliert,

quantisiert, entropie-codiert und zusammen mit der erhaltenen Information durch die

Pradiktion ubermittelt. Auch in diesem Fall werden die Pradiktionen dupliziert. Alle

grau hinterlegten Blocke in der Abbildung 2.1 duplizieren die Pradiktion und uber-

mitteln diese an den Decoder und Encoder. Mithilfe der inversen Skalierung erhalt

man die quantisierten und transformierten Koeffizienten. Diese Koeffizienten werden

invers transformiert. Das Resultat kann nun weiter bearbeitet werden. Hierfur bietet

der H.265/HEVC beispielsweise die Loopfilter, mithilfe derer man die Artefakte, die

durch das blockweise Verarbeiten und die Quantisierung entstanden sind, glatten kann.

Die finale Bilddarstellung wird in einem decodierten Bildspeicher gespeichert, um die

Pradiktion fur nachfolgende Bilder verwenden zu konnen [3].

Wie in Abbildung 2.1 werden alle ermittelten Informationen dem context-adaptive

binary arithmetic coding (CABAC) zur Entropiekodierung ubermittelt.

Durch den Anwender konnen mithilfe einer Parameteranpassung auch Schritte uber-

sprungen werden. Beispielsweise werden fur die verlustlose Verarbeitung die Blocke

Transformation, Skalierung und Quantisierung (erster Block) und Skalierung und In-

verse Transformation (zweiter Block) umgangen.

An dieser Stelle sollen ein paar Merkmale fur das hybride Video-Codieren durch Nut-

zung des H.265/HEVCs hervorgehoben werden.

Zum einen nutzt der HEVC die CTUs und coding tree blocks (CTBs). Der Vorganger

nutzte noch Makroblocke zum Unterteilen der Bilder. Ein CTU Block kann in drei

Blocke unterteilt werden. In einen Luminanz CTB Block und in zwei Chrominanz

CTB Blocke (plus ein Syntax Element). Die CTBs konnen in coding blocks (CBs)

weiter unterteilt werden. Durch diese Unterteilung wird der CTU auch als Wurzel des

quadtrees bezeichnet (Abbildung 2.2). Die Große L × L der coding tree blocks ist

identisch zu der Große der CTU Blocke und kann zwischen L = 16, 32, 64 gewahlt

werden. Die Anzahl der CBs in einem CTB kann variieren. Die Große der CBs kann

2.2. H.265/HEVC 7

Abbildung 2.2: Unterteilung der CTU [4]

zwsichen 8 × 8 und 64 × 64 liegen [3], [4].

Die intrapicture Pradiktion des H.265/HEVCs, die in der Abbildung 2.1 als ein eigener

Block veranschaulicht wird, unterstutzt 33 Richtungsmodi (Abbildung 2.3 links) und

zusatzlich noch einen planar und DC pradiktiven Modus. Somit hat der H.265/HEVC

insgesamt 35 verschiedene Richtungsmodi. Der H.264 hingegen hatte nur 8 Richtungs-

modi zur Verfugung (Abbildung 2.3 rechts). Die Performance und Werte der intrapic-

ture Pradiktion hangen von den transformierten Blocken (TB) ab. Die Große der TB

beginnt bei 4 × 4 und kann bis 32 × 32 erhoht werden. Die TB erhalt man durch die

weitere Aufteilung der CBs. Wichtig fur die Pradiktion des Restsignals ist neben der

Große der TBs, die vorigen decodierten Grenzsamples der raumlichen benachbarten

TBs [3], [4].

Ob der Coder eine intrapicture oder interpicture Pradiktion nutzt ist von den coding

units (CUs) abhangig. CUs werden in zwei Chrominanz CBs und eine Luminanz CB

unterteilt. Die CBs konnen dann weiter unterteilt werden in die sogenannten prediction

blocks (PBs). Diese PBs entscheiden, welche Art von Pradiktion genutzt werden soll.

Zur Berechnung des Restsignals nutzt man die transform blocks (TBs) anstatt der

CBs, da diese zu groß sein konnten [4]. Wie in den Fallen zuvor werden die Einheiten,

8

Abbildung 2.3: Links Anzahl der Richtungsmodi im HEVC; [3] Rechts ein Beispiel der8 Richtungswinkel vom AVC [5]

welche die Luminanz und Chrominanz enthalten, als unit bezeichnet woraus dann die

prediction unit (PU) und transform unit (TU) folgt.

Im Bereich der Entropiecodierung besitzt der H.265/HEVC nur den CABAC, wie in

Abbildung 2.1 dargestellt. Im H264/AVC hatte man noch die Auswahl zwischen dem

CABAC und context-adaptive variable-length coding (CAVLC). CABAC ist qualita-

tiv dem CAVLC uberlegen. Durch die geringere Komplexitat des CAVLC benotigt

dieser eine geringere Rechnerleistung. Allerdings hat der CABAC eine bessere Kom-

pressionsperformance [6]. Durch die stetige Verbesserung der Technologie ist jedoch

die technische Anforderung fur den CABAC nicht mehr als hoch zu betrachten und

deswegen wird der CAVLC nicht mehr im H.265/HEVC zur Verfugung gestellt.

Die Tabelle 2.1 veranschaulicht kompakt die beschriebenen Unterschiede des

H.265/HEVC und seinem Vorganger.

Im nachsten Abschnitt werden Erneuerungen veranschaulicht, welche die Verarbeitung

der Bild- und Videokompression beeinflussen.

2.2. H.265/HEVC 9

Tabelle 2.1: Die Unterschiede zwischen dem H.264/AVC und seinem Nachfolger [7]

H.264/AVC H.265/HEVC

Codierungsstruktur Makroblock CU, PU, TU

Bewegungsvektor (BV) Raumlicher BVRaumlicher BV,

Zeitlicher BV

Intrapicture Pradiktion Richtungen 8 33 + 2

Entropie CodierungCAVLC

CABACCABAC

Als erstes waren die Tiles zu erwahnen. Mithilfe der Tiles kann das Bild in rechteckige

Regionen unterteilt werden. Diese sind ab dem H.265/HEVC zur Verfugung gestellt

worden. Ein Vorteil ist die Zeitersparnis, die durch die bessere parallele Verarbeitung

ermoglicht wird. Der Grund fur die erhohte Kompatibilitat fur eine parallele Verarbei-

tung der Tiles ist die Moglichkeit, dass die Regionen des Bildes unabhangig voneinander

codiert werden konnen. Eine typische Tiles Unterteilung eines Bildes wird in Abbildung

2.4 veranschaulicht. In der Anwendung wird zunachst das Bild in rechteckige Regionen

(Tiles) unterteilt. Anschließend werden die Tiles in CTUs unterteilt. Ein Nachteil der

Tiles ist, dass die parallele Verabeitung zu einer schlechteren Datengenauigkeit fuhrt.

Die Tiles benotigen wegen ihrer einfachen Funktionsweise keine komplexe Synchroni-

sation [3].

Als nachstes wird die wavefront parallele Verarbeitung (wavefront parallel processing;

WPP) beschrieben. Das WPP wird aktiviert, um einen Slice in CTUs zu teilen. Die

erste Reihe wird wie ublich verarbeitet. Die Verarbeitung der folgenden Reihen folgt

einem gewissen Muster. Die nachste Reihe kann nur mit der Verarbeitung beginnen,

wenn die Reihe zuvor zwei CTUs verarbeitet hat. Wie in Abbildung 2.5 dargestellt kann

nach der Auswertung des zweiten CTUs in der dritten Reihe im nachsten Schritt die

vierte Reihe mit der Verarbeitung beginnen. Dieses Muster gilt fur alle Nachfolgenden

Reihen. Durch diese Art von Auswertung hat die WPP immer eine Verzogerung von

zwei CTUs pro Reihe. Verglichen mit den Tiles hat die wavefront parallelen Verarbei-

10

Abbildung 2.4: Aufteilung eines Bildes mithilfe von Tiles [3]

tung eine gute Datengenauigkeit. Die erhohte Datengenauigkeit hat eine verbesserte

Kompressionsperformance zur Folge [3].

Abschließend zu den Erneuerungen wird das abhangige Slice Segment erklart. Zunachst

soll eine kurze Ubersicht uber den Begriff Slice gegeben werden, der in Abbildung 2.6

verbildlicht ist. Ein Slice kann wie bei der WPP beschrieben in eine Sequenz von

CTUs unterteilt werden. Ein Bild kann in ein oder mehrere Slices aufgeteilt werden.

Im H.265/HEVC gibt es drei verschiedene Modi zur Aufteilung der Slices.

Ein Aspekt zur Nutzung der abhangigen Slice Segmente ist, dass Daten separiert

befordert werden konnen. In einem Slice mussten die Daten komplett zusammen co-

diert werden, aber durch das abhangige Slice Segment ist eine sogenannte fragmentierte

Paketierung der Daten moglich. Durch dieses Verfahren wird die Latenz des Coders ge-

ring gehalten. Wie im Fall des WPP kann das abhangige Slice Segment nur mit der

Codierung beginnen, wenn im Prozess vorher ein Part mithilfe des abhangigen Slice

Segments bearbeitet wurde. Dies fuhrt ebenfalls zu einer Verzogerung im Prozess. Die-

ser Verzug ist gewollt und wird in der Encodierung ausgenutzt. Die WPPs haben eine

bessere Kompressionsperformance als die Tiles, aber sie haben trotzdem einen storen-

2.3. VORSTELLUNG DER ERWEITERUNG REXT 11

Abbildung 2.5: Wavefront parallele Verarbeitung

den Effekt auf die Performance. Hier findet sich der große Vorteil des abhangigen Slice

Segmentes, welche die Kompressionsperformance nicht beeintrachtigt [3]. Jedes dieser

Merkmale kann bestimmte Vorteile haben, es liegt im Allgemeinem am Anwender, den

Nutzen zu finden.

2.3 Vorstellung der Erweiterung RExt

Die Range Extension (RExt) ist eine Erweiterung fur den H.265/HEVC. Sie verbessert

die Verarbeitung in den Bereichen der Datenerfassung, Nachbearbeitung, Archivie-

rung, Standbilder und - wichtig fur diese Arbeit - medizinischen Bilder. Zum einen

ermoglicht die RExt die Verwendung von anderen Chromaformaten. Der H.265/HEVC

war hauptsachlich auf die Nutzung des 4:2:0 Chromaformats ausgelegt. Die RExt er-

weitert das Spektrum, sodass es moglich ist, Sequenzen mit den Formaten 4:0:0, 4:2:2

und 4:4:4 zu bearbeiten. Durch den RExt werden nun auch Bittiefen von bis zu 16 Bit

unterstutzt. Die Funktionen wurden um neue Tools erweitert, die gezielt zur Steigerung

der Codiereffizienz, einer großeren Flexibilitat und den Datendurchsatz von hohen Bit-

12

Abbildung 2.6: Slice [3]

tiefen/Bitraten fuhren. Ein weiterer Punkt, mit dem sich die Erweiterung beschaftigt,

ist die Verbesserung der verlustlosen Codierung [8].

Im diesem Abschnitt werden die Erweiterungen naher beschrieben. Von Bedeutung fur

die Bearbeitung von medizinischen Datensatzen ist die verlustfreie Kompression, die

Verwendung von hohren Bittiefen und anderen Chromaformaten als 4:2:0. Genaueres

ist dem Paper [8] zu entnehmen.

Fur die medizinischen Datensatze ist ein Chromaformat von 4:0:0 notwendig, da die

Bilder der Sequenzen aus Graustufenbildern bestehen. Die Bittiefen von medizinischen

Datensatzen konnen auf bis zu 16 Bit pro Pixel steigen, je nach Aufnahme [8]. Der

H.265/HEVC unterstutzt nur Bittiefen von bis zu 10 Bit, dies ist oft nicht genug um

die medizinischen Sequenzen bearbeiten zu konnen. Die Bittiefe beschreibt die Anzahl

der Grauabstufungen in einem Bild. Die Anzahl (n) der Abstufungen kann mit

n = 2Bi (2.1)

berechnet werden, Bi steht hierbei fur die genutzen Bits pro Pixel. Daraus folgt, dass

2.3. VORSTELLUNG DER ERWEITERUNG REXT 13

ein Bild mit einer Bittiefe von 8 Bit 256 Abstufungen hat und ein Bild mit einer Tiefe

von 12 Bit 4096. Mithilfe der RExt Erweiterung werden diese Anforderungen abgedeckt.

Die Erweiterungen Cross-Component Prediction (CCP) und Adaptive Chroma Quanti-

zation Parameter (ACQP) konnen durch den Anwender in den Bild-Parameter-Setting

(picture parameter setting, PPS) aktiviert werden, die Residual Differential Pulse Code

Modulation (RDPCM) hingegen in dem Sequenz-Parameter-Set (SPS) [8]. Eine genaue-

re Erklarung dieser neuen Parameter ist im Verlauf dieses Abschnittes zu finden.

Der CCP basiert auf einem linearen Modell. Wie die interpicture Pradiktion hangt die

CCP von den TBs ab. Cross-Component Prediction konnte man auf deutsch mit Kom-

ponenten ubergreifende Pradiktion ubersetzten. Sie ist Komponenten ubergreifend, da

die Pradiktion die Abhangigkeit der Chrominanzen und Luminanz im Restsignal be-

rechnet. Hierbei ist zu beachten, dass das CPP Tool nur fur Chrominazformate von

4:4:4 anwendbar ist. Mithilfe des CPPs wird die Codiereffizienz gesteigert [8].

Ein weiterer Fortschritt im Bereich der Codiereffizenz ist durch die Erweiterung des

Transform Skip Modes moglich. Der H.265/HEVC konnte nur TUs mit der Große von

4× 4 uberspringen, dies wurde mit diesem Tool fur den RExt auf jede beliebige Große

erweitert [9].

Der ACQP Offset ist ein Parameter, der den Bereich der Quantisierung erweitert. Mit-

hilfe des ACQP konnen den Chrominanz quantisierten Parametern Offsets hinzugefugt

werden [8].

Eine neue Einstellung, die die verlustlose Verkleinerung unterstutzt, ist das RDPCM.

Der RDPCM verwendet eine differential pulse code modulation, um das Restsignal

abzutasten. In der Abbildung 2.1 wurde diese Abtastung nach dem Uberspringen der

inversen Transformation und der Skalierung stattfinden (im verlustfreien Fall). Es gibt

zwei Parameter fur den RDPCM: Zum einen den Implicit-RDPCM und zum ande-

ren den Explicit-RDPCM. Implicit-RDPCM unterstutzt die intrapicture pradiktiven

Blocke und Explicit-RDPCM interpicture pradiktive Blockem in der Verarbeitung. Im

Abschnitt 2.5 wird der RDPCM mit einem Beispiel naher veranschaulicht [8].

14

2.4 Vorstellung der Erweiterung SCC

Die neuste Erweiterung des H.265/HEVCs ist das screen content coding (SCC). Uber-

setzt bedeutet screen content Bildinhalt, was auch der Bereich ist, mit dem sich die Co-

dierung des SCCs hauptsachlich beschaftigt. In Abbildung 2.7 kann eine Veranschauli-

chung des Encoders mit der Erweiterung SCC betrachtet werden. Hierbei erkennt man,

dass im Vergleich zur Abbildung 2.1 neue Blocke hinzu kommen. Hinzugefugt werden

zum einen die Palette Codierung und zum anderen die adaptiven Farbtransformation,

die vor der Transformation und Quantisierung durchzufuhren ist. Diese Erneuerungen

und weitere werden nun genauer vorgestellt. Zunachst wird der Palette Mode beschrei-

ben. Der Palette Mode nutzt die CBs zur Unterteilung der unterschiedlichen Farbwer-

te. Jeder Farbwert erhalt einen Index. Die Samples mit diesem bestimmten Farbwert

werden diesem Index zugeordnet. In Abbildung 2.8 ist eine grafische Darstellung aufge-

zeigt. In der Regel werden in einem Bild nur eine bestimmte Anzahl von verschiedenen

Farbwerten genutzt. Dadurch, dass die Farbwerte begrenzt sind, erhoht der Modus die

Effizienz des Coders im Vergleich zu anderen Verfahren [9].

Mithilfe der adaptiven Farbtransformation (adaptive color transformation, ACT) ist

es moglich, den Farbraum zu wechseln. Der von uns bekannte Farbraum Rot-Grun-

Blau-Farbraum (RGB-Farbraum) wird durch den ACT in eine Y CoCg Darstellung

umgewandelt. Das Y steht fur die Luminanz, Co fur die orange Chrominanz und Cg

fur die grune Chrominanz. Zu beachten ist, dass diese Umformung verlustfrei ist. Wegen

dieser Umformung ist die inverse Farbtransformation (Inv. color transform) nach der

Dequantization und inversen Transformation notig. Zur Berechnung der Werte fur den

Y CoCg Farbraum nutzt man folgende Matrizengleichung [9]:

Y

Co

Cg

=

1/4 1/2 1/4

1/2 0 −1/2

−1/4 1/2 −1/4

R

G

B

(2.2)

Durch die Umwandlung in einen anderen Farbraum kann die Pradiktion der Farben

2.4. VORSTELLUNG DER ERWEITERUNG SCC 15

Bitstreams

SAO

parameters

Split into

CTUs

Coder

Control

Adaptive

color

transform

De-quant. & inv.

transform

Inv. color

transform

Block vector

estimation

Intra block

copy

Hash-based block

matching & motion

estimation

Intra

prediction

CABC

Motion

compensation

Deblocking

& SAO filters

Partitioning & mode

information

Block vectors

Motion vectors

Palette & index map

Transf. Coef

Palette

coding

Transform

& Quant.+

+

Abbildung 2.7: Encoder mit der SCC Erweiterung [9]

16

Abbildung 2.8: Palette Beispiel [9]

unabhangig voneinander bestimmt werden. Es ist moglich ein Bildblock im RGB-

Farbraum zu bearbeiten oder mithilfe der Aktivierung des ACT den Y CoCg-Farbraum

zu nutzen. Die Bearbeitung in einem Farbraum fuhrt zu sogenannten

inter-color-Redundanzen. Die Redundanzen entstehen durch die Korrelation zwischen

unterschiedlichen Farbkomponenten. Durch die Umwandlung in einen anderen Far-

braum konnen diese Redundanzen verhindert werden. Ein weiterer Vorteil ist, dass

auch diese Erneuerung zu einer effektiveren Codierung fuhrt [9]. Ein weiteres Problem,

fur das der SCC eine Losung bietet, ist die diskrete Bewegung. Die diskrete Bewegung

kann zu Detailungenauigkeiten in einem oder mehreren Samples fuhren. Die adapti-

ve Bewegungsvektor Auflosung (adaptive motion vector resolution; AMVR) ist eine

Art Kontrolle, die es ermoglicht, fur die Bewegungsvektoren zwischen einer ganzzah-

ligen oder rationalen Auflosung zu wahlen. Wegen der diskreten Bewegung benotigt

die Bewegungskompensation nicht immer eine rationale Zahl zur Darstellung, sondern

es genugen ganzzahlige Werte. Der AMVR wird bei einer positiven Flag aktiviert und

ubermittelt ganzzahlige Zahlen zur Berechnung. Der Coder spart sich somit unnotige

Bits was zu einer Reduktion der Bitrate fuhrt [9]. Mit dem Intra-Block-Copy (IBC)

2.5. PARAMETER FUR EINE VERLUSTFREIE KOMPRESSION 17

erhalt der SCC eine Alternative im Bereich der Pradiktion (Abbildung 2.7). Der IBC

ahnelt in seiner Funktionsweise sehr der interpicture Pradiktion mit dem Hauptun-

terschied, dass der IBC rekonstruierte Samples (vom aktuellen Bild) nutzt, um die

pradiktiven Blocke zu berechnen. Vereinfacht kann man behaupten, dass der IBC als

eine Art von Bewegungskompensation innerhalb eines Bildes angesehen werden kann

[9].

2.5 Parameter fur eine verlustfreie Kompression

In diesem Abschnitt werden die Parameter genannt, die fur die Arbeit eingestellt wer-

den sollten, um eine verlustfreie Kompression zu versichern oder verbessern.

Durch den RExt kommt der Lossless Operation Mode hinzu. Wie vorher schon erwahnt,

ist der RDPCM fur die verlustlose Verarbeitung hilfreich. Durch die Aktivierung RDP-

CM werden Redundanzen, die immer noch vorhanden sind, verringert. Dafur nutzt

der Coder eine Rekonstruktion entlang der horizontalen oder vertikalen Richtung der

Samples. Ein einfaches Beispiel: r(x, y) ist ein Element von dem Restblock mit einer

Große von N×N . d ist die Richtungsachse mit d = hor fur die horizontale oder d = ver

fur die vertikale Achse. Im verlustfreien Modus gilt dann fur rd(x, y) die Formel [8]:

rhor(x, y) =

r(x, y) fur x = 0

r(x, y) − r(x− 1, y) sonst

(2.3)

rver(x, y) =

r(x, y) fur x = 0

r(x, y) − r(x, y − 1) sonst

(2.4)

Ein Parameter, welcher die verlustfreie Verkleinerung gewahrleistet, ist der Costmo-

de (Kostenmodus), der auf lossless gestellt wird. Der Costmode setzt den Quantisie-

rungsparamter auf 0. Der TransquantBypassEnableFlag kann aktiviert werden, um die

Transformation, Quantisierung und Filterung im CU Level zu umgehen. Der CUTrans-

quantBypassFlagForce kontrolliert die CU Transformation und wird bei einer high Flag

18

die Umgehung der verlustbehafteten Parameter jedes einzelnen CUs erzwingen. Eine

Voraussetzung fur den CUTransquantBypassFlagForce ist die Aktivierung des Trans-

quantBypassEnableFlag [10].

KAPITEL 3. AUSWERTUNG 19

Kapitel 3

Auswertung

3.1 Vorgehen bei der Parameteroptimierung

Die Parameteroptimierung wurde durch einfaches Ausprobieren bestimmt. Falls die

Anderung eines Parameterwertes die Kompression verbessert hat, wurde dieser Wert

weiter verwendet. Zudem wurden auch zufallige Kombinationen der Werte ausprobiert,

jedoch war dies meistens ohne Erfolg. Das Ziel der Untersuchungen ware, eine univer-

selle Losung fur alle medizinischen Datensatze zu finden. Bei genauerem Betrachten

ist aufgefallen, dass eine Unterteilung der Sequenzen in ihre unterschiedlichen Bittiefen

sinnvoll ist. Andere Eckdaten wie zum Beispiel Große, Aufnahmegerat der Testsequen-

zen sind in den folgenden Tabelle 3.1, 3.2, 3.3 nachzulesen.

Tabelle 3.1: Daten der Sequenzen

Sequenz Schadel Sag-Kopf Kopf Herz063 Herz1 P05

Aufnahmegerat CT MRT MRT CT CT

Bittiefe 8 8 12 12 12

Frames 203 58 176 10 127

Große 256 × 256 256 × 256 256 × 256 512 × 512 512 × 512

Speichergroße (Bytes) 13303808 3801088 23068672 5242880 66854576

20

Abbildung 3.1: CT-Aufnahme des Herzens

An dieser Stelle soll noch eine kurze Erlauterung zu den Herz CT-Aufnahmen (Abbil-

dung 3.1). Das Herz wurde im 4-dimensionalem Raum aufgenommen und anschließend

fur die weitere Bearbeitung in eine raumliche und eine zeitliche Sequenz unterteilt.

Die zeitliche Darstellung heißt Herz063, die raumliche Aufnahme wird, als Herz1 P05

bezeichnet.

Das Ziel der Parameteroptimierung ist es, das Kompressionsverhaltnis zu vergroßern.

Das Kompressionsverhaltnis lasst sich wie folgt berechnen:

Kompressionsverhaltnis =Große des Orginals

Große der komprimierten Daten(3.1)

Somit ist ein moglichst kleiner Bitstream die beste Losung. Die Auswertungsergebnisse

werden in den folgenden Abschnitten veranschaulicht.

Zur Kompression wurde das random access main rext Configuration-File verwendet.

Zu beachten ist, dass neben den Grundeinstellungen (Anhang A.1) noch die Anfangs-

einstellungen der Parameter vorhanden sind (Anhang A.2). Die Parameter wurden aus-

gehend von den Anfangseinstellungen optimiert. In den Tabellen 3.2 und 3.3 konnen

beide Einstellungen in den Bereichen Speicherverbrauch (im komprimierten Fall) und

3.2. BITTIEFE VON 8 BIT 21

Tabelle 3.2: Die Grundeinstellungen


Benotigter Speicher (Bytes) 2933158 829962 4050325 1158831 13876770

Kompressionsverhaltnis 4, 536 4, 580 5, 670 4, 524 4, 818

Tabelle 3.3: Die Anfangseinstellungen


Benotigter Speicher 2933954 830760 4053374 1159822 13883324


Kompressionsverhaltnis fur jede Sequenz verglichen werden.

Man erkennt, dass die Anfangseinstellungen in jedem Bereich schlechter als die Gr-

undeinstellungen sind. Die Anfangseinstellung wurde nur wegen der ubersichtlicheren

Arbeitsweise eingefuhrt.

3.2 Bittiefe von 8 Bit

3.2.1 Voreinstellungen fur die 8 Bit pro Pixel Sequenzen

Fur die zwei Sequenzen mit einer Bittiefe von 8 Bit, welche in der Tabelle 3.1 aufgeli-

stet sind, mussen zunachst einige Voreinstellungen vorgenommen werden. Zur korrekten

Auswertung werden die Parameter InternalBitDepth und InputBitDepth auf 8 gesetzt.

Medizinische Datensatze haben ein Chromaformat von 4:0:0. Mit der Einstellung des

Parameters InputChromaFormat = 400 wird dies dem Coder ubermittelt. Stellvertre-

tend fur die 8 Bit pro Pixel Sequenzen wird die CT-Aufnahme vom Schadel (Abbildung

3.2) naher betrachtet (die Sag-Kopf-Aufnahme ist im Anhang A.3 beschrieben). Die

Variablen TransquantBypassEnableFlag und CUTransquantBaypassFlagForce werden

hier aktiv gelassen, um eine verlustfreie Kompression zu gewahrleisten.

22

Abbildung 3.2: CT-Aufnahme des Schadels

3.2.2 Optimierung der Unit definierenden Parameter

Die Werte fur die maximale CU Breite und Hohe (MaxCUWidth = 64, MaxCUHeight

= 64) wurden nicht verandert. Die Parameter werden nicht variiert, da anschließend

eine weitere Unterteilungen in TUs stattfindet und somit eine kleinere Blockgroße nicht

sinnvoll erscheint. Die ersten Parameter, die verandert wurden und direkt einen Einfluss

auf die Kompressionsperformance haben sind die Variablen QuadtreeTULog2MaxSize

und QuadtreeTULog2MinSize. Die Große der TUs werden mithilfe dieser Variablen

definiert. Wie erwahnt hangt die Pradikition von diesem Parameter ab, deswegen hat

die Optimierung in diesem Fall einen großen Effekt auf die Komprimierung der Sequenz.

Im Code werden die Werte logarithmisch mit der Basis 2 angegeben. Die TU Großen

liegen zwischen 4 und 32. Der Maximalwert liegt somit bei log2(32) = 5 und das

Minimum bei log2(4) = 2. Die nachsten Parameter QuadtreeTUMaxDepthIntra und

QuadtreeTUMaxDepthInter schließen die Parameter fur die Unit-Definition des Coders

ab. In diesem Fall definieren die Großen die Tiefe der TU-Baume fur die intra oder

inter codierten CUs [10]. Durch die Parameteroptimierung kommen die in Tabelle 3.4

aufgelisteten Ergebnisse heraus. Die Optimierung unterscheidet sich nur im Fall der


Tabelle 3.4: Unit definierende Parameter

Parameter Anfangswerte Optimale Werte

MaxCUWidth 64 64

MaxCuHeight 64 64

MaxPartitionDepth 4 4

QuadtreeTULog2MaxSize 5 5

QuadtreeTULog2MinSize 2 2

QuadtreeTUMaxDepthIntra 2 4

QuadtreeTUMaxDepthInter 1 4

letzten zwei Variablen von den Anfangseinstellungen.

Fur die Anfangswerte benotigt die Kompression 2933954 Bytes zum Speichern mit dem

Kompressionsverhaltnis von

13303808

2933954

Bytes

Bytes= 4, 534. (3.2)

QuadtreeTULog2MaxSize hat die beste Kompression fur die Zahl 5. Bei diesem Para-

meter wurde festgestellt, dass eine großere Zahl immer einen kleineren Bitstream zur

Folge hat. Die QuadtreeTULog2MinSize bleibt auf ihrem Minimalwert. Das bedeutet,

die Anzahl der TUs, die einen CU Block unterteilen, variiert. Der CU Block kann in 2

oder aber auch in 16 TUs aufgeteilt werden. Die Variablen QuadtreeTUMaxDepthIntra

und QuadtreeTUMaxDepthInter wurden jeweils auf 4 angehoben, sodass eine bessere

Kompression entsteht (Tabelle 3.4). Diese zwei Parameter mussen fur jede Sequenz

einzeln optimiert werden, da hier kein Muster erkannt wurde, das immer zu einer bes-

seren Verkleinerung fuhrt. Der optimierte Fall hat die Große 2931439 Bytes mit dem

vergroßerten Verhaltnis von 4, 538. Durch diese einfache Anpassung dieser zwei Para-

meter wird der Speicherverbrauch um nahe zu 0, 09 % verbessert (vergleiche Tabelle

3.5).

24

Tabelle 3.5: Ergebnis der Verbesserung

Speicherbedarf Kompressionsverhaltnis

Anfangseinstellung 2933954 Bytes 4, 534

Optimierte Einstellung 2931439 Bytes 4, 538

Tabelle 3.6: Codierstruktur Parameter


IntraPeriod −1 −1

DecodingRefreshType 1 1

GOPSize 8 8

3.2.3 Optimierung der Codierstruktur Parameter

Die nachsten Variablen gehoren zu der Codierstruktur. Die IntraPeriod bestimmt wie

der Name aussagt, die intra Frameperiode. Der IntraPeriod Parameter hat die beste

Performance beim Wert -1. Das bedeutet, dass die Periode unendlich lang ist [10]. Zur

Aktualisierung der Codierung der Bilder verfugt der H.265/HEVC mit dem Decodin-

gRefreshType, uber vier verschiedene Optionen. Die Auswahl fallt auf die Anwendung

zufalliger CRA (clean random access) intra Accespoints (DecodingRefreshType auf 1

gesetzt). Der H.265/HEVC bietet vier verschiedene Moglichkeiten fur die Decoderer-

neuerung an, das Kompressionsverhaltnis wird dadurch jedoch nicht verandert. Der

Grund fur die Wahl DecodingRefreshType = 1 ist, dass dies in den Anfangseinstellung

eingestellt war. Die GOP (Group Of Pictures) Große von 8 und die Frames wurden

nicht verandert.

Die Anfangswerte entsprechen in diesem Fall den optimierten Einstellungen (vergleiche

Tabelle 3.6). Im Fall der IntraPeriod wird ab dem Wert 240 das gleiche Ergebnis wie fur

-1 erreicht, allerdings wird eine langere Laufzeit benotigt, deswegen bleibt die Variable

im optimalen Fall unverandert.


Tabelle 3.7: Bewegungsabschatzungsparameter

FastSearch 1 1

SearchRange 64 0

BipredSearchRange 4 1

HadamardME 0 0

FEN 1 0

FDM 1 0

3.2.4 Optimierung der Bewegungsabschatzung

Im Bereich der Bewegungsabschatzung mussen fur die medizinischen Datensatze mit

einer Bittiefe von 8 Bit nahezu alle Parameter angepasst werden (siehe Tabelle 3.7).

Fur den FastSearch wird die schnell suchende Methode (TZSearch) festgelegt. Der

Suchbereich fur die Bewegungsschatzungen hat seine optimale Große bei 0. Das bedeu-

tet, dass der Suchradius einen ganzen Frame abdeckt. Dass die TZSearch ein besseres

Ergebnis als die vollstandige Suche liefert, ist uberraschend, da die vollstandige Bewe-

gungssuche genauer sein sollte. Eine Erklarung ware, dass in diesem Fall die TZSearch

die Bewegung genauso gut abschatzt, aber durch die geringere genutzte Information

weniger Bytes zur Speicherung benotigt. Mit der Zuordnung von BipredSearchRange

= 1 wird der Bereich fur eine Bi-Pradiktion ebenfalls klein gehalten. Die HadamardME

wird deaktiviert, um zu testen ob die SAD (sum of absolute differences) fur die Ko-

stenschatzung besser als die Hadamard Transformation ist. Dabei stellt sich herraus,

dass die Kompression nicht von dem Parameter abhangt. FEN (fast encoder) und

FDM (fast encoder decision mode) werden beide ebenfalls deaktiviert, um eine gutes

Kompressionsverhaltnis zu erhalten. Wahrend die Ausschaltung des FEN die Verklei-

nerung begunstigt, wurde der FDM wegen der besseren Zeit zusatzlich deaktiviert. In

der Tabelle 3.7 konnen die Parameteranderungen nachgelesen werden.

Nach Anderung dieser Parameter und Beibehalten der zuvor optimierten Parameter

(aus 3.2.2) erhalten wir fur den benotigen Speicherplatz den Wert 2928265 Bytes. Ver-

26



Vorherige Einstellung 2931439 Bytes 4, 538


glichen mit dem Vorwert von 2931439 Bytes verbessert sich der Vorgang um ungefahr

0, 11 %. Das Kompressionsverhaltnis steigt auf 4, 543 an (vergleiche Tabelle 3.8).

3.2.5 Parameter fur die Quantisierung

Wegen der verlustefreien Komprimierung der Sequenzen werden die Quantisierungs-

parameter (siehe 3.2.1) ubersprungen. Die einzelnen Variablen des Coders, welche die

Quantisierung beeinflussen, haben keinen Effekt auf die verlustlose Kompression, des-

wegen werden diese Parameter nicht naher ausgefuhrt.

3.2.6 Optimierung der Loopfilter Parameter

Wahrend des Tests stellt sich heraus, dass der Loopfilter die Verkleinerung nicht

begunstigt, deswegen wird er mit dem Parameter LoopFilterDisable deaktiviert (Tabel-

le 3.9). Dadurch sind Parameter wie LoopFilterTCOffset div2 unbedeutend. Die Varia-

ble LoopFilterOffsetInPPS wird hingegen aktiviert, um die in-loop deblocking Filter an

die Slice Segment header zu ubermitteln [10]. Der Coder verbessert seine Performan-

ce dadurch um einige Bytes. Mit einer Steigerung des Kompressionsverhaltnisses von

4, 543 auf 4, 544, sinkt der benotigte Speicherplatz auf 2927820 Bytes (Tabelle 3.10).

Diese minimale Steigerung im Kompressionsverhaltnis fuhrt zu einer Einsparung von

445 Bytes. Prozentual gesehen hat die Anpassung eine Gesamtverbesserung von

0, 21 % verglichen mit den Anfangseinstellungen.


Tabelle 3.9: Parameter fur die Loopfilter


LoopFilterOffsetInPPS 0 1

LoopFilterDisable 0 1

LoopFilterBetaOffset div2 4 0

LoopFilterTCOffset div2 4 0

DeblockingFilterMetric 0 0



Vorherige Einstellung 2928265 Bytes 4, 543


3.2.7 Optimierung der Slice und Rate Control Parameter

Die Codier Parameter fur die Slices werden untersucht. Es stellt sich raus, dass die

Variable SliceMode als einzige fur die Kompression von Relevanz ist. Der SliceMode

bestimmt, wie genau der Slice aufgeteilt wird. Im optimierten Fall wird der Slice,

ohne weitere Unterteilungen, als ein einzelnes Slice genutzt (SliceMode = 0, vergleiche

Tabelle 3.11) [10]. Die anderen zwei untersuchten Parameter fuhren immer zu dem

gleichen Kompressionsverhaltnis. Der Unterschied besteht in der benotigten Zeit, die

der Coder benotigt, den Bitstream zu erzeugen. Gleiches gilt fur die Parameter der

Rate Control. Die Optimierung der Zeit wird hier nicht naher betrachtet, da sich der

Zeitaufwand fur die 8 Bit Sequenzen mit ungefahr 4 Minuten pro Prozess im Rahmen

halt und nur wenige Sekunden gespart werden. In der Tabelle 3.11 sind alle eingestellten

Parameter veranschaulicht.

28

Tabelle 3.11: Slice Parameter und Rate Control


SliceMode 1 0

SliceArgument 1000 1000

LFCCrossSliceBoundaryFlag 1 1

RateControl 0 0

TargetBitrate 1000000 1000000

KeepHierarchicalBit 2 2

LCULevelRateControl 1 1

RCLCUSeparateModel 1 1

3.2.8 Optimierung der Codier-Tool Parameter

Die Codier-Tools SAO (sample adaptive offset) und TransformSkipFast mussen fur eine

Erhohung des Verhaltnisses ausgeschaltet werden, im Gegensatz zu den Grundeinstel-

lung, wo sie aktiviert sind. Die asymmetrische Bewegungstrennung (AMP; asymmetric

motion partitions auf high) bleibt aktiv. Ein weiterer wichtiger Parameter, der die Kom-

pressionsperformance verbessert, ist die Pulse-Code-Modulation (PCM). Die PCM wird

mithilfe der PCMEnabledFlag aktiviert, wenn man die Flag auf high setzt. Mithilfe

der Variablen PCMLog2MaxSize und PCMLog2MinSize legt man die Großen der PCM

Blocke fest [10]. Analog zur Festlegung der Große fur die TUs ist hier die Aufgabe, die

optimalen Werte zu finden. Die beste Kompression wird erzielt, wenn man die Parame-

ter PCMLog2MaxSize und PCMLog2MinSize = 3 setzt (vergleiche Tabelle 3.12). Bei

der Optimierung der Tiles ist aufgefallen, dass die Werte der Anfangseinstellungen die

beste Losung liefern. In den Grundeinstellungen ist der Parameter TileUniformSpacing

auf 0 gesetzt, aber dieser hat keinen direkten Einfluss auf die Große des Bitstreams.

Nach der Optimierung all dieser Parameter und dem Beibehalten der zuvor angepassten

Variablen haben wir ein Ergebnis von 2927672 Bytes (zum Vergleich 2933954 Bytes).

Der Zeitaufwand hat sich durch die Parameteroptimierung um ungefahr 35 % erhoht,


Tabelle 3.12: Codier Tool Parameter


SAO 1 0

AMP 1 1

TransformSkip 1 1

TransformSkipFast 0 0

SAOLcuBoundary 0 0

PCMEnabledFlag 1 1

PCMLog2MaxSize 5 3

PCMLog2MinSize 3 3

PCMInputBitDepthFlag 1 1

PCMFilterDisableFlag 0 0

Tabelle 3.13: Vergleich optimierter Fall und Anfangswert

Anfangseinstellung Optimale Einstellung

Benotigter Speicher 2933954 Bytes 2927672 Bytes

Kompressionsverhaltnis 4, 534 4, 544

Laufzeit in Sekunden 183, 660 248, 320

aber das Kompressionsverhaltnis auf 4, 544 verbessert. In der Tabelle 3.13 werden alle

Unterschiede kompakt dargestellt. Das Ergebnis konnte nicht weiter verbessert werden.

Durch die Optimierung kann man den Bitstream um 6282 Bytes verkleinern. Je nach

Große der Sequenz unterschiedet sich der gewonnene Speicherplatz (vergleiche Anhang

A.3).

3.2.9 Veranschaulichung der Bedeutung der RExt Parameter

Abschließend werden noch die RExt Parameter genauer betrachtet. Wie erwahnt bieten

die RExt Parameter eine Verbesserung der verlustfreien Kompression, deswegen sind

30

die meisten Parameter bei der Optimierung aktiviert. Parameter, die keinen Einfluss

auf das Ergebnis haben, sind vorwiegend Variablen, die fur andere Chromaformate

definiert sind, wie zum Beispiel der CrossComponentPrediction Parameter, welcher

nur fur Formate von 4:4:4 anwendbar ist. Das Endergebnis von 2927672 Bytes konnte

nicht weiter verbessert werden, da die Parameter im RExt im Anfangsmodus schon

aktiviert sind. Zur Veranschaulichung der Bedeutung der Erweiterung ist die Tabel-

le 3.14 und das dazugehorige Diagramm zu betrachten. Hierbei erkennt man, dass

die RExt Variablen einen großen Anteil zu der Kompression beitragen. Wie schon in

2.4 vorgestellt, haben die Parameter des RDPCM - Implicit-RDPCMs und Explicit-

RDPCMs - eine große Wirkung auf die verlustlose Kompression. Bei der Deaktivierung

des Implicit-RDPCMs erhoht sich der Speicherverbrauch auf 2941510 Bytes und im Fall

des Explicit-RDPCMs auf 3061187 Bytes, wie in der Grafik veranschaulicht. Durch die

haufigere Bearbeitung der Blocke durch eine interpicture Pradiktion ist es nachvoll-

ziehbar, dass der Explicit-RDPCM einen noch großeren Einfluss auf die Optimierung

hat. Die Variation der Variablen TransformSkipLog2MaxSize hat hingegen nur einen

kleinen Einfluss (lediglich eine Erhohung um 2 auf 2927674 Bytes). Die anderen drei

RExt Erneuerungen minimieren den Speicherbedarf ebenfalls. Ohne den SingleSignifi-

canceMapContext steigt der Wert auf 2937588 Bytes. Der Parameter IntraReferenceS-

moothing erhoht das Ergebnis auf 2927717 Bytes und der GolombRiceParameterAd-

aptation verschlechtert die Kompression auf 2931587 Bytes. Insgesamt kann man gut

erkennen wie wichtig die neuen Moglichkeiten des RExt fur das Kompressionsverhalt-

nis sind. Zur Verdeutlichung wurden alle RExt Parameter deaktiviert und anschließend

komprimiert. Der Bitstream benotigt nun 3112725 Bytes und somit 6, 32 % mehr als die

optimierte Einstellung. In der Abbildung 3.3 und Tabelle 3.14 wurden die Auswertun-

gen graphisch dargestellt. Besonders auffallend ist hierbei die Steigung im Fall 6 (siehe

Tabelle 3.14 und Abbildung 3.3, Abschalten des ExplicitResidualDPCM Parameters).


Tabelle 3.14: RExt Parameter

X-Achse 1 2 3 4 5 6 7 8 9 10

TransformSkipLog2MaxSize 2 3 4 5 2 2 2 2 2 2

ImplicitResidualDPCM 1 1 1 1 0 1 1 1 1 1

ExplicitResidualDPCM 1 1 1 1 1 0 1 1 1 1

ResidualRotation 1 1 1 1 1 1 0 1 1 1

SingleSignificanceMapContext 1 1 1 1 1 1 1 0 1 1

IntraReferenceSmoothing 1 1 1 1 1 1 1 1 0 1

GolombRiceParameterAdaptation 1 1 1 1 1 1 1 1 1 0

2 4 6 8 10

2.95

3

3.05

·106

RExtParameter laut Tabelle 3.8

Byte

sWri

tten

tofile

Abbildung 3.3: Einfluss der RExt Parameter

32

3.2.10 Vergleich der Grundeinstellungen mit dem optimierten

Fall

Nach den einzelnen Schritten zur Verbesserung der Kompressionsperformance wird

nun ein Vergleich mit den Grundeinstellungen gezogen. In der Tabelle 3.15 sind die

Variablen prasentiert, in denen sich die Parameter der Grundeinstellung von den opti-

mierten Werten unterscheiden und einen Einfluss auf die Kompression des Bitstreams

haben. Dabei ist zu erkennen, dass es sich nicht um sehr viele Parameter handelt. Die

Grundeinstellungen verbrauchen einen Speicher von 2933158 Bytes und haben somit

ein Kompressionsverhaltnis von 4, 536. Mit einem Verhaltnis von 4, 544 erreicht die

Optimierung ein vielversprechendes Ergebnis. Absolut betrachtet verringert sich der

Speicheraufwand um 2933158 Bytes − 2927672 Bytes = 5486 Bytes. Es ist zu beach-

ten, dass die fett geschriebenen Parameter keine universellen Losungen sind. Das heißt,

fur diese Variablen haben sich beim Untersuchen der MRT-Aufnahme des Sag-Kopfes

(Anhang A.3) andere Werte als besser erwiesen.

Mit den optimierten Werten fur den MRT-Sag-Kopf benotigt die Kompression nur

828679 Bytes. Durch das Testen mit den Parametern, die bei dem CT-Schadel zur

Optimierung fuhren, erhoht sich der Speicheraufwand auf 828883 Bytes. Die Spei-

chergroße fur den Bitstream steigt somit um 204 Bytes. Fur den Fall, dass man fur

den CT-Schadel die Parametereinstellungen der MRT Aufnahme verwendet, steigt der

Wert um 674 Bytes. Diese Differenzen sind gering. Man konnte eines der beiden als

eine Losung fur andere Sequenzen in Betracht ziehen. Dabei ist aber zu beachten, dass

bei noch großeren Sequenzen die Bytes, die extra zum Speichern notig sind sich wahr-

scheinlich erhohen. Um ein Beispiel zu nennen: Bei einer Differenz von ca. 500 Bytes

zwischen der optimierten Einstellungen (fur die genutzte Sequenz) und die Einstellung,

die ein Optimum im Fall des Schadels erzielt, sind es bei 2000 Sequenzen ungefahr 1

Megabyte mehr Speicherplatz, der benotigt wird.


Tabelle 3.15: Unterschiedliche Parameter

Parameter Grundeinstellung Optimale Werte

QuadtreeTUMaxDepthIntra 3 4

QuadtreeTUMaxDepthInter 3 4

IntraPeriode 32 −1

FastSearch 1 1

SearchRange 64 0

BipredSearchRange 4 1

FEN 1 0

LoopFilterDisable 0 1

SAO 1 0

TransformSkipFast 1 0

PCMEnabledFlag 0 1

PCMLog2MaxSize 5 3

PCMLog2MinSize 3 3

34

3.3 Bittiefe von 12 Bit

3.3.1 Voreinstellungen fur die 12 Bit pro Pixel Sequenzen

Nun werden die Sequenzen mit einer Bittiefe von 12 prasentiert. Die Anfangsparame-

ter sind identisch mit den Testsequenzen mit einer Tiefe von 8 Bit. Die angepassten

Variablen sind die InternalBitDepth und InputBitDepth. Die letzten Parameter, die

sich unterscheiden, sind zum einen die ExtendedPrecision von der RExt Erweiterung

und der PCMInputBitDepthFlag zum anderen. Beide Variablen mussen ausgeschaltet

werden, um die Bilder mit der Bittiefe von 12 Bit ohne eine Fehlerausgabe bearbeiten

zu konnen. Die InputBitDepth wird auf 12 erhoht. Bei den InternalBitDepth Variablen

muss drauf geachtet werden ,dass man nicht irrtumlich auch mit dem Wert 12 arbeitet,

sondern sie auf den Wert 10 setzt.

3.3.2 Optimierung der Parameter

QuadtreeTUMaxDepthIntra und QuadtreeTUMaxDep-

thInter

Die Parameter, die eine Veranderung in der Kompression bewirken, sind die gleichen

wie in den 8 Bit pro Pixel Sequenzen. Zunachst sind es die Parameter QuadtreeTU-

MaxDepthIntra und QuadtreeTUMaxDepthInter, die angepasst werden mussen. Es

wird keine einheitliche Losung fur die drei Sequenzen gefunden. Auch die zwei Herzse-

quenzen haben fur diese Parameter unterschiedlich optimierte Losungen (siehe Tabelle

3.16). Eine Muster wurde hierbei nicht erkannt, diese zwei Parameter scheinen fur jede

Sequenz einzeln optimiert werden zu mussen.


Tabelle 3.16: Optimierte Werte fur die Parameter QuadtreeTUMaxDepthIntra undQuadtreeTUMaxDepthInter

Parameter Kopf Herz063 Herz1 P05

QuadtreeTUMaxDepthInter 5 4 5

QuadtreeTUMaxDepthIntra 1 3 5

3.3.3 Einfluss der Parameter FastSearch, SearchRange und

BipredSearchRange

Bei den 12 Bit pro Pixel Sequenzen wurden die Variablen FastSearch, SearchRange

und BipredSearchRange noch genauer betrachtet, weil sie einen großeren Einfluss auf

die Kompression haben. Hierbei weisen die Herz-Aufnahmen das gleiche Muster auf.

Sie haben das beste Ergebnis fur FastSearch = 0 mit einer kleinen SearchRange (16 fur

Herz1 P05 und 32 fur Herz063). Die MRT-Aufnahme hingegen hat die beste Kompres-

sionsperformance fur FastSearch = 1 und einer SearchRange von 64. Die BipredSear-

chRange scheint fur steigende Werte eine bessere Kompression zu liefern, jedoch ist bei

genauerer Untersuchung aufgefallen, dass eine Erhohung des BipredSearchRange Wer-

tes nicht immer einen kleineren Bitstream zu folge hat. Beim Sprung des Wertes von

55 auf 155 vergroßert sich der Bitstream. Ein weiterer Nachteil ist, dass die Laufzeit

sich erhoht. In der Tabelle 3.17 werden die Unterschiede anhand der Herz063 Sequenz

veranschaulicht.

Wichtig ist, dass man hierbei nicht die Anwendbarkeit in der Praxis vergisst. Mit ei-

ner Anzahl von 10 Frames und einer benotigten Zeit von ca. 25 Minuten (1501, 260

Sekunden) fur die Kompression steht die Relation - gesparte Bytes und Laufzeit - in

keiner guten praktischen Anwendung. Fur die Laufzeit ist die Kombination der drei

Parameter (FastSearch, SearchRange und BipredSearchRange) von Bedeutung. Ein

hoherer Suchradius erhoht die Laufzeit. Dies erkennt man bei der anderen Herztest-

sequenz, die schon bei einem Wert von 14 fur die BipredSearchRange Variable und

einem Suchradius von 32 eine Laufzeit von 6453, 050 Sekunden hat. Bei einem Radi-

36

Tabelle 3.17: Veranderung durch die BipredSearchRange der Sequenz Herz063

BipredSearchRange Bytes Laufzeit in Sekunden Kompressionsverhaltnis

3 1156510 322, 830 4, 5334

5 1156229 330, 170 4, 5345

6 1156232 329, 750 4, 5345

10 1155621 363, 680 4, 5369

12 1155667 388, 220 4, 5367

14 1155489 401, 110 4, 5374

55 1154884 1501, 260 4, 5397

155 1155071 8310, 380 4, 5390

us von 16 fallt die benotigte Zeit auf nahezu die Halfte namlich 3251, 170 Sekunden.

Die Kompression verschlechtert sich von 13807284 Bytes auf 13808868 Bytes. Bei der

MRT-Aufnahme hat die Erhohung der BipredSearchRange nicht solch einen starken

Einfluss auf die Laufzeit. Dies hangt auch davon ab, dass diese Sequenz den schnellen

Suchmodus nutzt. Die Laufzeit erhoht sich lediglich um ungefahr 86 Sekunden beim

Anheben des Wertes von 4 auf 13. Die Große des Wertes wurde so festgelegt, dass die

Weiterverarbeitungszeit, fur jede Sequenz separiert betrachtet, als angemessen angese-

hen wurde. Die Herzsequenzen haben beide in diesem Fall die gleichen Resultate. Das

beste Ergebnis wird bei einer vollstandigen Suche erzielt, aber im Falle von Herz1 P05

erhoht sich die Laufzeit des Coders auf 2289, 960 Sekunden. Das sind ungefahr 38 Mi-

nuten fur eine Sequenz, deswegen ware die Empfehlung die Variable FastSearch = 3 zu

setzten und somit eine erweiterte TZSearch Methode zu nutzten. Hierbei fallt auch auf,

dass ab einer bestimmten Kombination von FastSearch = 3 und BipredSearchRange ei-

ne bessere Kompression gelingt. FastSearch = 3 nutzt einen erweiterten TZSearch, der

eine langer Berechnung benotigt als die einfach Suche, aber deutlich schneller als die

vollstandige Bewegungssuche ist. Die eingesparte Zeit, die durch die Bewegungssuch-

methode gewonnen wird, ermoglicht es, den Wert des BipredSearchRange zu erhohen


Tabelle 3.18: Kombination FastSearch und BipredSearchRange fur die Herz1 P05 Se-quenz

Nummer FastSearch BipredSearchRange Bytes Laufzeit in Sekunden

1 0 6 13819271 2289, 960

2 0 14 13808868 3251, 170

3 3 6 13826121 1349, 930

4 3 8 13823439 1538, 070

5 3 11 13818589 1905, 900

Tabelle 3.19: Kompressionsverhaltnisse erganzend zu 3.18

Nummer 1 2 3 4 5


und somit eine bessere Komprimierung in einer geringerer Laufzeit zu erreichen. Ver-

anschaulicht wird dies am Beispiel der Herz1 P05 Sequenz mit einer SearchRange von

16 in der Tabelle 3.18. In der Tabelle 3.19 ist eine kompakte Ubersicht zu den Kom-

pressionsverhaltnissen fur die Falle, die in der Tabelle 3.18 veranschaulicht wurden.

Wie man sehen kann, hat die zweite Einstellung die beste Kompressionsperformance,

aber mit einer Laufzeit von 54 Minuten und 11 Sekunden ist sie nicht fur die Anwendung

in der Praxis sinnvoll. Mit der Kombination BipredSearchRange = 11 und FastSearch

= 3 unterbietet man die Laufzeit und die benotigten Bytes im Vergleich zum ersten Fall.

Jedoch ist die Laufzeit mit uber 30 Minuten immer noch relativ hoch. Empfehlenswert

fur den zweckmaßigen Gebrauch waren die Reihe 3 oder 4. Eine einheitliche Losung

fur beide Herzsequenzen ist nicht so einfach zu finden, da die zeitliche Sequenz eine

bessere Performance fur den FastSearch = 2 hat als fur FastSearch = 3. Durch langes

Experimentieren konnte man die zeitliche Herzsequenz wahrscheinlich auch mithilfe

der erweiterten TZSearch optimieren.

Hinzu kommt, dass die Parameter fur die Große der PCM Blocke nicht einheitlich fur

die 12 Bit pro Pixel Sequenzen sind. Somit mussen die Großen PCMLog2MaxSize und

38

PCMLog2MinSize fur jeweiligen Fall angepasst werden.

3.3.4 Veranschaulichung der Bedeutung der RExt Parameter

fur jede Sequenz

Nun werden wieder die RExt Parameter naher betrachtet. Eine Uberraschung ist, dass

die Sequenz Herz063 beim Abschalten der Parameter GolombRiceParameterAdapta-

tion oder IntraReferenceSmoothing eine Verbesserung des Kompressionsverhaltnisses

erzielt. Zwar erzielen beide Variablen einzeln eine Verbesserung zur vorherigen Kom-

pression, aber das beste Ergebnis liefert die einzelne Deaktivierung des Parameters

IntraReferenceSmoothing. Im aktiven Zustand hat die RExt Variable ein Kompressi-

onsverhaltnis von 4, 5374, nach dem Deaktivieren steigt der Wert auf 4, 5378, sodass

eine Einsparung von 79 Bytes erfolgt. Ein anderer Unterschied zu den 8 Bit pro Pixel

Sequenzen ist, dass der Parameter TransformSkipLog2MaxSize nur fur den Wert 2 eine

gute Kompression aufweist. Bei einer Tiefe von 8 Bit war der Wert 5 ebenfalls akzepta-

bel, fur 2 wird jedoch eine universelle Losung erhalten. In der raumlichen Darstellung

des Herzens verschlechtert sich der Prozess. Bei der Abschaltung des Parameters In-

traReferenceSmoothing steigt der benotigte Speicherplatz auf 13831743 Bytes und im

Falle der GolombRiceParameterAdaptation Variable auf 13833095 Bytes von vorher

13831176 Bytes. Eine Verbesserung durch Abschalten dieser zwei Parameter scheint

eine Ausnahme zu sein, da bei keiner anderen Sequenz ein solches Resultat eintritt.

In den Tabellen 3.20 und 3.21 konnen die beiden RDPCM Variablen wieder ihren

enormen Einfluss auf die Kompressionsperformance jeder einzelnen Sequenz aufzeigen.

Besonders der Unterschied in den beiden Herzsequenzen ist auffallig. Die raumliche

Herzsequenz verschlechtert sich von dem Kompressionsverhaltnis 4, 833 auf 4, 319,

wenn die Explicit-RDPCM abgeschaltet wird. Absolut betrachtet steigt der benotigte

Speicherplatz um 1648216 Bytes an.

Die Parameter, die nicht naher ausgefuhrt wurden, haben die gleichen idealen Werte

wie in den 8 Bit pro Pixel Datensatzen, die vorher vorgestellt wurden.


Tabelle 3.20: Speicherbedarf Explicit- und Implicit-RDPCM

Kopf Herz063 Herz1 P05

ohne Explicit-RDPCM 4055542 Bytes 1249146 Bytes 15479392 Bytes

ohne Implicit-RDPCM 4060756 Bytes 1172701 Bytes 14026470 Bytes

beide aktiviert 4043250 Bytes 1155464 Bytes 13831176 Bytes

Tabelle 3.21: Kompressionsverhaltnis der Explicit- und Implicit-RDPCM


ohne Explicit-RDPCM 5, 689 4, 197 4, 319

ohne Implicit-RDPCM 5, 680 4, 471 4, 766

beide aktiviert 4, 705 4, 537 4, 833

3.3.5 Ergebnisse des Kompressionsverhaltnisses und des Speicher-

bedarfs

Abschließend wird das Kompressionsverhaltnis veranschaulicht. Die zeitliche Herzse-

quenz verbraucht mit einem optimierten Bitstream einen Speicherplatz von 1155385

Bytes. Unbearbeitet benotigt die Sequenz eine Speichergroße von 5242880 Bytes. Das

Kompressionsverhaltnis betragt somit 4, 538. Die Grundeinstellung hat ein Verhaltnis

von 4, 524. Die gesparten Bytes betragen durch die Optimierung der Parameter 3446

Bytes. Die minimale Erhohung des Kompressionsverhaltnis kann falsch interpretiert

werden, deswegen wurde nochmal der tatsachlich gesparte Speicherplatz veranschau-

licht (Tabelle 3.22). Bei der großeren Sequenz, der raumlichen Darstellung des Herzens,

betragt die Grundgroße 66854576 Bytes. Die Grundeinstellungen fuhren zu einer Kom-

pression mit der Große von 13876770 Bytes. Wegen des zeitlichen Aufwandes, wie

vorher vorgestellt, wird die Einstellung, die dem dritten Fall in der Tabelle 3.18 ent-

spricht, als Richtwert angenommen. Somit haben wir einen verbesserten Bitstream mit

13826121 Bytes. Das Kompressionsverhaltnis steigert sich von 4, 818 auf 4, 835. Durch

die Einsparung von insgesamt 50649 Bytes verdoppelt sich auch die Laufzeit.

40

Tabelle 3.22: Auswertungen des Speicherbedarfs der 12 Bit pro Pixel Sequenzen


Kompression Grundeinstellung (Bytes) 4050325 1158831 13876770

Optimale Kompression (Bytes) 4043250 1155385 13826121

Gesparte Bytes 7075 3446 50649

Kompressionsverhaltnis Grundeinstellung 5, 696 4, 524 4, 818

Optimales Kompressionsverhaltnis 5, 705 4, 538 4, 835

Grundeinstellung Laufzeit (Sekunden) 247, 970 56, 960 787, 630

Optimale Laufzeit (Sekunden) 666, 650 411, 940 1314, 750

In der Tabelle 3.22 sind die Ergebnisse kompakt fur alle drei Sequenzen aufgelistet. Die

Parameter sind in der Tabelle 3.23 aufgefuhrt. Hier wurden die Parameter aufgelistet,

die sich in den drei Sequenzen von den Grundeinstellungen unterscheiden und einen

Einfluss auf das Kompressionsverhaltnis haben.

Ein sehr gutes Kompressionsverhaltnis erreicht die Kompression der

MRT-Kopf-Aufnahme. Prozentual gesehen verbessert sich die raumliche Herzfrequenz

am besten mit den optimierten Ergebnissen (Kompressionsverhaltnis steigt um 0, 014).

Die Laufzeit verlangert sich im Fall der Herz063 am meisten. Sie steigert ihre Laufzeit

um fast das Achtfache auf 411, 940 Sekunden.

3.4 Vergleich mit dem SCC

Der SCC bearbeitet die Chromaformate 4:2:0, 4:2:2 und 4:4:4, deswegen ist zu be-

achten, dass ein zusatzlicher Aufwand zur Umwandlung der medizinischen Datensatze

(Chromaformat 4:0:0) eingeplant werden muss. Durch die Veranderung in das Format

4:2:0 nimmt auch die benotigte Speichergroße der Sequenzen zu (Tabelle 3.24).

Dadurch, dass der SCC hauptsachlich auf diese Chromaformate konzentriert und Vor-

teile in der Farbraum Transformation bietet, lasst sich vermuten, dass keine oder nur

geringe Verbesserungen in der Kompression erzielt werden konnen. Hierbei wird auch

3.4. VERGLEICH MIT DEM SCC 41

Tabelle 3.23: Unterschiedlich optimierte Parameter der 12 Bit pro Pixel Sequenzen

Parameter Grundeinstellung Kopf Herz063 Herz1 P05

QuadtreeTUMaxDepthInter 3 5 4 5

QuadtreeTUMaxDepthIntra 3 1 3 5

IntraPeriod 32 −1 −1 −1

FastSearch 1 1 0 3

SearchRange 64 64 32 16

BipredSearchRange 4 13 14 6

FEN 1 0 0 0

LoopFilterDisable 0 1 1 1

SAO 1 0 0 0

TransformSkipFast 1 0 0 0

PCMEnabledFlag 0 1 1 1

PCMLog2MaxSize 5 5 5 3

PCMLog2MinSize 3 3 3 3

IntraReferenceSmoothing 1 1 0 1

Tabelle 3.24: Speichergroße der Sequenzen im 4:2:0 Chromaformat

Schadel Sag-Kopf Kopf Herz063 Herz1 P05

Speichergroße (Bytes) 19955712 5701632 34603008 7864320 99876864

42

die Kompression verlustfrei komprimiert. Die Einstellungen sind identisch zu den der

RExt Einstellungen, da der SCC nur eine weitere Erweiterung ist. Um einen fairen

Vergleich zwischen der SCC Erweiterung und dem RExt zu gewahrleisten, werden die

Sequenzen in beiden Fallen mit dem Chromaformat 4:2:0 bearbeitet.

In der Bearbeitung mit den Grundeinstellungen erhalten wir unterschiedliche Ergeb-

nisse fur die Sequenzen. Im Fall des CT-Schadels (benotigter Speicherplatz im 4:2:0

Format betragt 19955712 Bytes) erhalt man ein Bitstream der Große 2938222 Bytes,

wenn man den SCC nutzt. Fur die Komprimierung mit dem RExt benotigt man einen

Speicheraufwand von 2935013 Bytes. Das Kompressionsverhaltnis steigt von 6, 792 auf

6, 799 (vergleiche Tabelle 3.25). Die benotigte Bearbeitungszeit ist mit der Nutzung

der SCC Parameter fast drei mal so hoch wie ohne. Das Ergebnis in der Herz1 P05-

Aufnahme wird hingegen verbessert. Der Bitstream, der mithilfe des SCC komprimiert

wurde, benotigt 13867913 Bytes in der Grundeinstellung. Durch die Nutzung der Er-

weiterung spart man sich somit 16810 Bytes. Ein großerer Nachteil hier ist der erhohte

Zeitaufwand. Mit einer Dauer von 3508, 170 Sekunden ist es in der Praxis nicht anwend-

bar. In Tabelle 3.25 sind alle Sequenzen und ihre Ergebnisse in der Grundeinstellung

dargestellt.

Wie erwahnt sind die Ergebnisse sehr unterschiedlich (Tabelle 3.25). Die beiden Herz-

sequenzen schneiden besser ab, aber die restlichen drei Aufnahmen nicht. Ein Problem

bei der verlustefreien Komprimierung mithilfe der SCC Erweiterung ist die verlangerte

Laufzeit, die bei allen Sequenzen steigt. Nach der Untersuchung der Grundeinstel-

lungen wurden die optimierten Einstellungen der RExt und H.265/HEVC Parameter

verwendet. Verwunderlich ist, dass die Laufzeiten bei den optimierten Fallen bei fast

allen Sequenzen abnimmt (Bearbeitung mit dem SCC). Die 12 Bit pro Pixel Kopf-

Aufnahme verschlechtert sich in der Laufzeit und in der Kompression. Der benotigte

Speicher steigt auf 4082899 Bytes, wahrend sich die Laufzeit um fast 400 Sekunden

steigert. Die anderen verarbeiteten Sequenzen verbessern sich im Vergleich zu ihren

Grundeinstellungen in beiden Bereichen.

Auch im optimierten Zustand sind die Ergebnisse sehr unterschiedlich (siehe Tabelle


3.26). Die raumliche Herzsequenz schneidet bei der Kompression mit der SCC Erweite-

rung in diesem Fall schlechter ab als die RExt Verkleinerung. Zuvor hatte es noch einen

verbesserten Effekt. Ein genau entgegengesetzt Resultat liefert die Auswertung der 8

Bit pro Pixel Kopfaufnahme. Der Bitstream, der durch die Verarbeitung mit den SCC

Parametern nur eine Große von 828696 Bytes besitzt, schneidet besser ab (vergleiche

Tabellen 3.25 und 3.26).

44

Tabelle 3.25: Ergebnisse mit den Grundeinstellungen

Sequenzen Benotigte Bytes mit RExt Benotigte Bytes mit SCC

Schadel 2935013 2938222

Sag-Kopf 830685 830726

Kopf 4052382 4080360

Herz063 1159976 1158820

Herz1 P05 13884723 13867913

Kompressionsverhaltnis mit RExt Kompressionsverhaltnis mit SCC

Schadel 6, 799 6, 792

Sag-Kopf 6, 864 6, 863

Kopf 8, 539 8, 480

Herz063 6, 780 6, 786

Herz1 P05 7, 193 7, 202

Benotigte Zeit mit RExt Benotigte Zeit mit SCC

Schadel 248, 930 Sekunden 743, 220 Sekunden

Sag-Kopf 81, 810 Sekunden 272, 120 Sekunden

Kopf 279, 770 Sekunden 729, 860 Sekunden

Herz063 62, 630 Sekunden 236, 230 Sekunden

Herz1 P05 87, 3890 Sekunden 3508, 170 Sekunden


Tabelle 3.26: Ergebnisse mit den optimierten Parametern

Sequenzen Benotigte Bytes mit RExt Benotigte Bytes mit SCC

Schadel 2928588 2928618

Sag-Kopf 829270 828696

Kopf 4044454 4082899

Herz063 1156728 1155935

Herz1 P05 13830773 13831760

Kompressionsverhaltnis mit RExt Kompressionsverhaltnis mit SCC

Schadel 6, 814 6, 814

Sag-Kopf 6, 875 6, 880

Kopf 8, 556 8, 475

Herz063 6, 799 6, 803

Herz1 P05 7, 221 7, 221

Benotigte Zeit mit RExt Benotigte Zeit mit SCC

Schadel 300, 170 Sekunden 352, 030 Sekunden

Sag-Kopf 98, 400 Sekunden 116, 510 Sekunden

Kopf 771, 040 Sekunden 1103, 880 Sekunden

Herz063 418, 530 Sekunden 193, 560 Sekunden

Herz1 P05 1425, 000 Sekunden 1589, 150 Sekunden

KAPITEL 4. ZUSAMMENFASSUNG UND AUSBLICK 47

Kapitel 4

Zusammenfassung und Ausblick

Die Ergebnisse im Kapitel 3 zeigen, dass sich das Kompressionsverhaltnis verbessern

lasst. Meistens erzielt die Optimierung einzelner Parameter nur eine kleine Verbesse-

rung des Kompressionsverhaltnisses (im Bereich einer Dezimalstelle). Je nach Große

der Sequenz ist dabei eine Einsparung im großeren Byte Bereich moglich. Ein Beispiel

ware die Herz1 P05-Sequenz, in der eine Anpassung eine Einsparung im funfstelligen

Byte Bereich ermoglicht. Diese Optimierung wurde bei 50 Sequenzen - bei gleicher

Großenordnung wie im Fall der raumlichen Herz Aufnahme - eine Einsparung von

50649 · 50 = 2532450 Bytes bewirken. Grundsatzlich wurde sich eine Parameteropti-

mierung lohnen, allerdings ware dies durch die Unterscheidungen der einzelnen Varia-

blen sehr zeitaufwandig, auch wenn nur wenige Parameter verandert werden mussten.

Alle RExt Parameter sollten trotz der Ausnahme in der zeitlichen Herz Aufnahme

aktiviert werden. Die Deaktivierung der Variablen GolombRiceParameterAdaptation

oder IntraReferenceSmoothing fuhrt in den anderen Aufnahmen zu einer schlechteren

Verkleinerung. In der Theorie gibt es keinen Hinweis darauf, dass das Ausschalten

dieser Parameter einen Vorteil hat.

Im Bereich der 8 Bit Datensatze sind die Großen fur die PCM Blocke ebenfalls gleich

(siehe Kapitel 3.1). In den 12 Bit Datensatzen ist dies hingegen nicht der Fall, deswe-

gen ware es voreilig zu behaupten, dass bei jeder 8 Bit Sequenz die Variablen PCM-

48

Tabelle 4.1: FastSearch, SearchRange und BipredSearchRange

Schadel Sag-Kopf Kopf Herz063 Herz1 P05

FastSearch 1 3 1 0 3

SearchRange 0 0 64 32 16

BipredSearchRange 1 1 13 14 6

Log2MaxSize und PCMLog2MinSize den Wert 3 als Optimum haben (vergleiche Ta-

belle 3.23). Hierfur musste man noch andere Datensatze auswerten und vergleichen.

Die großte Unstimmigkeit wurde bei den Parametern FastSearch, SearchRange und

BipredSearchRange festgestellt. Nahezu alle Sequenzen weisen dort unterschiedliche

Losungen auf. In der Tabelle 4.1 wird alles kurz dargestellt, welche Werte fur die op-

timale Verarbeitung der jeweiligen Sequenz aufgezeigt werden. Wie in Kapitel 3.3.3

aufgezeigt muss man ebenfalls auf die Laufzeit achten, die nicht zu hoch sein sollte.

Im Fall der 12 Bit pro Pixel Sequenzen ware es moglich, die BipredSearchRange zu

erhohen und eine einheitliche Losung mit den FastSearch zu finden, aber das ware in

der Praxis ein zu großer Aufwand, da dadurch immer eine lange Vorarbeit notig ware.

Ein Losungsvorschlag ware, bei kleinen Datensatzen (kleiner als 10 GB) einen hohen

BipredSearchRange Wert und eine vollstandige Suche (FastSearch = 0) zu nutzen.

Fur großere Datensatze lohnt sich der zeitliche Aufwand nicht mehr, weswegen eine

andere FastSearch Methode gewahlt werden sollte. Vorzugsweise einer der beiden Modi

1 oder 3. Die erweiterte schnelle Suche (FastSearch = 3) zeigt im Fall der raumlichen

Herz-Aufnahme ein gutes Ergebnis, aber in den anderen zwei Sequenzen (MRT-Kopf

und CT-Schadel) ist die einfache TZSearch die bessere Losung. Hierbei konnte weiter

untersucht werden, ob großere Datensatze (> 50 GB) besser komprimiert werden durch

die erweiterte schnelle Suche. Bei dieser Vorgehensweise wurde es sich anbieten, dass

Sequenzen die zwischen 10 GB - 50 GB Speicherplatz benotigen mit der TZSearch

bearbeitet werden (MRT-Kopf- und CT-Schadel-Aufnahme).

In Tabelle 4.2 werden alle optimierten Parameter veranschaulicht, die als universell

gelten und sich von den Grundeinstellungen unterscheiden.

49

Tabelle 4.2: Universelle Parameter

Parameter Optimale Einstellung

IntraPeriode −1

HadamardME 0

FEN 0

FDM 0

LoopFilterDisable 1

SAO 0

TransfromSkipFast 0

PCMEnabledFlag 1

TileUniformSpacing 1

CrossComponentPrediction 1

Viele Parameter waren in ihren Grundeinstellungen schon optimal. Parameter wie

CrossComponentPrediction und TileUniformSpacing haben zwar keinen Einfluss auf

die Kompression, aber wurden wegen der standigen Verwendung in den Tests so beibe-

halten. Als eine Kompromisslosung wurden die Grundeinstellung nur in den universell

geltenden Parametern (Tabelle 4.2) verandert. In Tabelle 4.3 sind die Ergebnisse fur

jede Sequenz veranschaulicht.

Die Kompression verbessert sich in allen Fallen, was zu dem Resultat fuhrt, dass die

Tabelle 4.3: Vergleich der Ergebnisse der Kompromisslosung

Sequenzen Grundeinstellung Optimale Losung Kompromisslosung

Schadel 2933158 Bytes 2927672 Bytes 2928585 Bytes

Sag-Kopf 829962 Bytes 828679 Bytes 829061 Bytes

Kopf 4050325 Bytes 4043250 Bytes 4044592 Bytes

Herz063 1158831 Bytes 1155385 Bytes 1157097 Bytes

Herz1 P05 13876770 Bytes 13826121 Bytes 13842733 Bytes

50

Parameter aus der Tabelle 4.2 bei der Verarbeitung von medizinischen Datensatzen

angepasst werden sollten.

Fur die Kompression mithilfe der SCC Erweiterung wurde Folgendes festgestellt: Ver-

nachlassigt man die 12 Bit pro Pixel Kopf-Aufnahme, dann erkennt man, dass sich

die optimierten Einstellungen nicht so stark unterscheiden (Tabelle 3.26). Ebenfalls

verbessert sich die Laufzeit und nahert sich den RExt Bearbeitungszeiten. Weitere Un-

tersuchung konnten zeigen, dass man mit optimierten Werten fur die SCC Parameter

bessere Kompressionen mit identischer Laufzeit erreicht. Hierbei muss man aber beach-

ten, dass die Umwandlung in das Chromaformat 4:2:0 noch vorher stattfinden muss.

Eine generelle Anwendung des SCC fur medizinische Datensatze, die hauptsachlich aus

Graustufenbildern bestehen, wird ausgeschlossen, weil die Bearbeitung im 4:0:0 Chro-

maformat mit der RExt Erweiterung noch bessere Ergebnisse liefert. Hierbei zahlt die

absolute Ersparnis des Speicheraufwandes und nicht das Kompressionsverhaltnis.

ANHANG A. ANHANG 51

Anhang A

Anhang

A.1 Anhang 1

In Anhang 1 werden die Parameter in ihrer Grundeinstellung fur die 8 Bit pro Pixel

Sequenzen veranschaulicht.

Profile: main-RExt

Tier: main

MaxCUWidth: 64

MaxCUHeight: 64

MaxPartitionDepth: 4

QuadtreeTULog2MaxSize: 5

QuadtreeTULog2MinSize: 2

QuadtreeTUMaxDepthInter: 3

QuadtreeTUMaxDepthIntra: 3

52

IntraPeriod: 32

DecodingRefreshType: 1

GOPSize : 8

FastSearch : 1

SearchRange : 64

BipredSearchRange: 4

HadmardME: 1

FEN: 1

FDM: 1

LoopFilterOffsetInPPS: 1

LoopFilterDisable: 0

LoopFilterBetaOffset div2: 0

LoopFilterTcOffset div2: 0

DeblockingFilterMetric: 0

InternalBitDepth: 8

SAO: 1

AMP: 1

TransformSkip: 1

TransformSkipFast: 1

SAOLcuBoundary: 0

SliceMode: 0

SliceArgument: 1500

LFCCrossSliceBoundaryFlag: 1

A.1. ANHANG 1 53

PCMEnabledFlag: 0

PCMLog2MaxSize: 5

PCMLog2MinSize: 3

PCMInputBitDepthFlag: 1

PCMFilterDisableFlag: 0

TileUniformSpacing: 0

NumTileColumsMinus1: 0

TileColumnWidthArray: 23

NumTileRowsMinus1: 0

TileRowHeightArray: 2

LFCCrossTileBoundaryFlag: 1

WaveFrontSynchro: 0

ScalingList: 0

ScalingListFile: scaling list.txt

TransquantBypassEnableFlag: 1

CUTransquantBypassFlagForce: 1

RateControl: 0

TargetBitrate: 1000000

KeepHierarchicalBit: 2

LCULevelRateControl: 1

RCLCUSeparateModel: 1

InitialQP: 0

RCForceIntraQP: 0

54

ExtendedPrecision: 0

TransformSkipLog2MaxSize: 2

ImplicitResidualDPCM: 1

ExplicitResidualDPCM: 1

ResidualRotation: 1

SingleSignificanceMapContext: 1

IntraReferenceSmoothing: 1

GolombRiceParameterAdaptation: 1

HighPrecisionPredictionWeighting: 1

CrossComponentPrediction: 1

CostMode: lossless

InputChromaFormat: 400

InputBitDepth: 8

A.2 Anhang 2

In Anhang 2 werden die Parameter in ihrer Anfangseinstellungen fur die 8 Bit pro Pixel

Sequenzen veranschaulicht.

Profile: main-RExt

Tier: main

MaxCUWidth: 64

MaxCUHeight: 64

MaxPartitionDepth: 4

QuadtreeTULog2MaxSize: 5

QuadtreeTULog2MinSize: 2

QuadtreeTUMaxDepthInter: 2

QuadtreeTUMaxDepthIntra: 1

A.2. ANHANG 2 55

IntraPeriod: −1

DecodingRefreshType: 1

GOPSize : 8

FastSearch : 1

SearchRange : 64

BipredSearchRange: 4

HadmardME: 0

FEN: 1

FDM: 1

LoopFilterOffsetInPPS: 0

LoopFilterDisable: 0

LoopFilterBetaOffset div2: 4

LoopFilterTcOffset div2: 4

DeblockingFilterMetric: 0

InternalBitDepth: 8

SAO: 1

AMP: 1

TransformSkip: 1

TransformSkipFast: 0

SAOLcuBoundary: 0

SliceMode: 1

SliceArgument: 1000

LFCCrossSliceBoundaryFlag: 1

56

PCMEnabledFlag: 1

PCMLog2MaxSize: 5

PCMLog2MinSize: 3

PCMInputBitDepthFlag: 1

PCMFilterDisableFlag: 0

TileUniformSpacing: 1

NumTileColumsMinus1: 0

TileColumnWidthArray: 23

NumTileRowsMinus1: 0

TileRowHeightArray: 2

LFCCrossTileBoundaryFlag: 1

WaveFrontSynchro: 0

ScalingList: 0

ScalingListFile: scaling list.txt

TransquantBypassEnableFlag: 1

CUTransquantBypassFlagForce: 1

RateControl: 0

TargetBitrate: 1000000

KeepHierarchicalBit: 2

LCULevelRateControl: 1

RCLCUSeparateModel: 1

InitialQP: 0

RCForceIntraQP: 0

A.3. ANHANG 3 57

ExtendedPrecision: 1

TransformSkipLog2MaxSize: 2

ImplicitResidualDPCM: 1

ExplicitResidualDPCM: 1

ResidualRotation: 1

SingleSignificanceMapContext: 1

IntraReferenceSmoothing: 1

GolombRiceParameterAdaptation: 1

HighPrecisionPredictionWeighting: 1

CrossComponentPrediction: 1

CostMode: lossless

InputChromaFormat: 400

InputBitDepth: 8

A.3 Anhang 3

Optimierte Parameter fur die 8 Bit pro Pixel Sag-Kopf-Aufnahme, die sich von dem

CT-Schadel unterscheiden, sind in Tabelle A.1 aufgelistet.

Mit dieser Aufnahme wurden noch andere Parameter getestet, aber es wurde keine

Verbesserung festgestellt. Somit sollten die default Einstellungen beibehalten werden.

Die Werte in der Tabelle fuhren nur zur Verschlechterungen der Kompression. (Tabelle

A.2).

Die Optionen des FENs 2 und 3 verschlechtern ebenfalls die Kompression.

Hier soll kurz die Wirkung der RExt Parameter veranschaulicht werden. Die Parame-

ter werden alle einzeln deaktiviert und rechts steht der neue benotige Speicherbedarf

(optimiertes Ergebnis: 828679 Bytes, Tabelle A.3).

58

Tabelle A.1: Codierstruktur und Einheit definierende Parameter

Parameter Optimale Werte

QuadtreeTUMaxDepthInter 5

FastSearch 3

Tabelle A.2: Getestete Parameter

Getestete Parameter Angepasster Wert

AccessUnitDelimiter 1

ClipForBiPredMEEnabled 1

Rdpenalty 2

Rdpenalty 3

ConstrainedIntraPred 1

FastMEforGenBLowDelayEnabled 0

FastUDIUseMPMEnabled 1

Tabelle A.3: RExt Parameter

RExt Parameter Bytes

ImplicitResidualDPCM 831615

ExplicitResidualDPCM 858805

ResidualRotation 830873

SingleSignificanceMapContext 832227

IntraReferenceSmoothing 829033

GolombRiceParameterAdaptation 829040

HighPrecisionPredictionWeighting 828679

ABBILDUNGSVERZEICHNIS 59

Abbildungsverzeichnis

2.1 Typischer HEVC Video Encoder [3] . . . . . . . . . . . . . . . . . . . . 5

2.2 Unterteilung der CTU [4] . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Links Anzahl der Richtungsmodi im HEVC; [3] Rechts ein Beispiel der

8 Richtungswinkel vom AVC [5] . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Aufteilung eines Bildes mithilfe von Tiles [3] . . . . . . . . . . . . . . . 10

2.5 Wavefront parallele Verarbeitung . . . . . . . . . . . . . . . . . . . . . 11

2.6 Slice [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.7 Encoder mit der SCC Erweiterung [9] . . . . . . . . . . . . . . . . . . . 15

2.8 Palette Beispiel [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 CT-Aufnahme des Herzens . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 CT-Aufnahme des Schadels . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Einfluss der RExt Parameter . . . . . . . . . . . . . . . . . . . . . . . . 32

TABELLENVERZEICHNIS 61

Tabellenverzeichnis

2.1 Die Unterschiede zwischen dem H.264/AVC und seinem Nachfolger [7] . 9

3.1 Daten der Sequenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Die Grundeinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Die Anfangseinstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Unit definierende Parameter . . . . . . . . . . . . . . . . . . . . . . . . 23

3.5 Ergebnis der Verbesserung . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.6 Codierstruktur Parameter . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.7 Bewegungsabschatzungsparameter . . . . . . . . . . . . . . . . . . . . . 26


3.9 Parameter fur die Loopfilter . . . . . . . . . . . . . . . . . . . . . . . . 27


3.11 Slice Parameter und Rate Control . . . . . . . . . . . . . . . . . . . . . 28

3.12 Codier Tool Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.13 Vergleich optimierter Fall und Anfangswert . . . . . . . . . . . . . . . . 30

3.14 RExt Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.15 Unterschiedliche Parameter . . . . . . . . . . . . . . . . . . . . . . . . 33

3.16 Optimierte Werte fur die Parameter QuadtreeTUMaxDepthIntra und

QuadtreeTUMaxDepthInter . . . . . . . . . . . . . . . . . . . . . . . . 35

3.17 Veranderung durch die BipredSearchRange der Sequenz Herz063 . . . . 36

3.18 Kombination FastSearch und BipredSearchRange fur die Herz1 P05 Se-

quenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

62

3.19 Kompressionsverhaltnisse erganzend zu 3.18 . . . . . . . . . . . . . . . 37

3.20 Speicherbedarf Explicit- und Implicit-RDPCM . . . . . . . . . . . . . . 39

3.21 Kompressionsverhaltnis der Explicit- und Implicit-RDPCM . . . . . . . 39

3.22 Auswertungen des Speicherbedarfs der 12 Bit pro Pixel Sequenzen . . . 40

3.23 Unterschiedlich optimierte Parameter der 12 Bit pro Pixel Sequenzen . 41

3.24 Speichergroße der Sequenzen im 4:2:0 Chromaformat . . . . . . . . . . 41

3.25 Ergebnisse mit den Grundeinstellungen . . . . . . . . . . . . . . . . . . 44

3.26 Ergebnisse mit den optimierten Parametern . . . . . . . . . . . . . . . 45

4.1 FastSearch, SearchRange und BipredSearchRange . . . . . . . . . . . . 48

4.2 Universelle Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3 Vergleich der Ergebnisse der Kompromisslosung . . . . . . . . . . . . . 49

A.1 Codierstruktur und Einheit definierende Parameter . . . . . . . . . . . 58

A.2 Getestete Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

A.3 RExt Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

LITERATURVERZEICHNIS 63

Literaturverzeichnis

[1] Chukwumezie Millverton Francis und Ernst Bartels. Bildkompression. Prosemi-

nar, 2005.

[2] https://kompendium.infotip.de/grundlagen videokompression.html.

[3] G. J. Sullivan und J. R. Ohm und W. J. Han und T. Wiegand. Overview of the

high efficiency video coding (hevc) standard. IEEE Transactions on Circuits and

Systems for Video Technology, 22(12):1649–1668, Dez 2012.

[4] https://codesequoia.wordpress.com/2012/10/28/hevc-ctu-cu-ctb-cb-pb-and-tb/.

[5] Mian-Shiuan Li und Mei-Juan Chen und Kuang-Han Tai und Kuen-Liang Sue.

Fast mode decision based on human noticeable luminance difference and rate dis-

tortion cost for h.264/avc. EURASIP Journal on Advances in Signal Processing,

2013.

[6] http://iphome.hhi.de/marpe/cabac.html.

[7] C. H. Tsai und H. T. Wang und C. L. Liu und Y. Li und C. Y. Lee. A 446.6k-

gates 0.55-1.2v h.265/hevc decoder for next generation video applications. In 2013

IEEE Asian Solid-State Circuits Conference (A-SSCC), pages 305–308, Nov 2013.

[8] D. Flynn und D. Marpe und M. Naccari und T. Nguyen und C. Rosewarne und

K. Sharman und J. Sole und J. Xu. Overview of the range extensions for the hevc

standard: Tools, profiles, and performance. IEEE Transactions on Circuits and

Systems for Video Technology, 26(1):4–19, Jan 2016.

64

[9] J. Xu und R. Joshi und R. A. Cohen. Overview of the emerging hevc screen

content coding extension. IEEE Transactions on Circuits and Systems for Video

Technology, 26(1):50–62, Jan 2016.

[10] Frank Bossen und David Flynn und Karl Sharman und Karsten SA14hring. HM

Software Manual. Joint Collaboration Team on Video Coding (JCT-VC) of ITU-T

SG16 WP3 and ISO/IEC JTC1/SC29/WG11, Nov 2016.

Bachelorarbeit Parameteroptimierung des H.265/HEVCs f ur ... · ter des H.265/HEVCs mit der RExt...

Documents

Transcript of Bachelorarbeit Parameteroptimierung des H.265/HEVCs f ur ... · ter des H.265/HEVCs mit der RExt...