Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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.
IV
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
Sequenz Schadel Sag-Kopf Kopf Herz063 Herz1 P05
Benotigter Speicher (Bytes) 2933158 829962 4050325 1158831 13876770
Kompressionsverhaltnis 4, 536 4, 580 5, 670 4, 524 4, 818
Tabelle 3.3: Die Anfangseinstellungen
Sequenz Schadel Sag-Kopf Kopf Herz063 Herz1 P05
Benotigter Speicher 2933954 830760 4053374 1159822 13883324
Kompressionsverhaltnis 4, 534 4, 575 5, 691 4, 520 4, 816
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
3.2. BITTIEFE VON 8 BIT 23
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
Parameter Anfangswerte Optimale Werte
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.
3.2. BITTIEFE VON 8 BIT 25
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
Tabelle 3.8: Ergebnis der Verbesserung
Speicherbedarf Kompressionsverhaltnis
Vorherige Einstellung 2931439 Bytes 4, 538
Optimierte Einstellung 2928265 Bytes 4, 543
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.
3.2. BITTIEFE VON 8 BIT 27
Tabelle 3.9: Parameter fur die Loopfilter
Parameter Anfangswerte Optimale Werte
LoopFilterOffsetInPPS 0 1
LoopFilterDisable 0 1
LoopFilterBetaOffset div2 4 0
LoopFilterTCOffset div2 4 0
DeblockingFilterMetric 0 0
Tabelle 3.10: Ergebnis der Verbesserung
Speicherbedarf Kompressionsverhaltnis
Vorherige Einstellung 2928265 Bytes 4, 543
Optimierte Einstellung 2927820 Bytes 4, 544
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
Parameter Anfangswerte Optimale Werte
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,
3.2. BITTIEFE VON 8 BIT 29
Tabelle 3.12: Codier Tool Parameter
Parameter Anfangswerte Optimale Werte
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).
3.2. BITTIEFE VON 8 BIT 31
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.
3.2. BITTIEFE VON 8 BIT 33
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.
3.3. BITTIEFE VON 12 BIT 35
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
3.3. BITTIEFE VON 12 BIT 37
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
Kompressionsverhaltnis 4, 838 4, 841 4, 835 4, 836 4, 838
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.
3.3. BITTIEFE VON 12 BIT 39
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
Kopf Herz063 Herz1 P05
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
Kopf Herz063 Herz1 P05
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.4. VERGLEICH MIT DEM SCC 43
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
3.4. VERGLEICH MIT DEM SCC 45
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
46
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
60
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.8 Ergebnis der Verbesserung . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.9 Parameter fur die Loopfilter . . . . . . . . . . . . . . . . . . . . . . . . 27
3.10 Ergebnis der Verbesserung . . . . . . . . . . . . . . . . . . . . . . . . . 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.