Progetto 3DCloudViz
NICE -DIEE
WP 2
Algoritmi e sistemi per la visualizzazione
remota anche su reti a banda limitata ed
elevata latenza
Deliverable D2
R.2.1 Stato dell'arte sugli algoritmi di compressione
e metriche per la comparazione degli algoritmi di
compressione
R.2.2 Relazione test comparativo sulle performance
reali degli algoritmi di compressione in contesti
operativi generici e per categorie specifiche di
contenuto (es. testo, grafica, fotografie )
R.2.3 Dataset per la validazione degli algoritmi di
compressione
R.2.4 Modello architetturale di un sistema di
compressione adattativa, sistema di decisione per
la selezione dinamica dell'algoritmo di
compressione e protocollo di comunicazione tra
client e server
Pattern Recognition and Applications LabDIEE - Università di Cagliari
R2.1STATO DELL'ARTE SUGLI ALGORITMI DI COMPRESSIONE EMETRICHE PER LA COMPARAZIONE DEGLI ALGORITMI DI
COMPRESSIONE
Progetto 3D CloudWiz
Progetto 3D CloudWiz | ATI NICE - DIEE
SommarioSommario..............................................................................................................................................i
Obiettivo del documento......................................................................................................................1
Compressione lossless di immagini in real-time..................................................................................2
Algortimi di compressione dati........................................................................................................3
Codici di Huffman........................................................................................................................4
Codifica aritmetica.......................................................................................................................5
LZ77 – LZ78................................................................................................................................5
LZW(Lempel-Ziv-Welch)............................................................................................................6
RLE – Run Length Encoding.......................................................................................................7
Deflate..........................................................................................................................................7
Algoritmi di compressione lossless per immagini............................................................................8
Lossless JPEG e JPEG-LS............................................................................................................8
JPEG2000 – lossless...................................................................................................................10
JPEG XR.....................................................................................................................................11
Confronti tra i tre algoritmi precedentemente descritti..............................................................12
GIF..............................................................................................................................................13
PNG............................................................................................................................................13
Implementazioni multithread di diverso tipo.................................................................................15
ImageZero...................................................................................................................................15
LZ4.............................................................................................................................................17
Algoritmi di compressione proposti in letteratura..........................................................................17
A Lossless Image Compression Technique using Location Based Approach............................18
Context-based Dictionary Image Compression..........................................................................19
A new Algorithm for Lossless Compression applied to two-dimensional Static Images...........21
Fast Lossless Color Image Compressing Method Using Neural Network.................................22
Conclusioni.....................................................................................................................................24
Bibliografia.....................................................................................................................................25
Compressione di immagini generiche a contenuto eterogeneo (compound images).........................29
Metodi di segmentazione delle componenti di un'immagine.........................................................30
Approccio ad oggetti..................................................................................................................30
Approccio a layer.......................................................................................................................30
Approccio a blocchi....................................................................................................................32
i
Progetto 3D CloudWiz | ATI NICE - DIEE
Approccio ibrido.........................................................................................................................33
Algoritmi proposti in letteratura.....................................................................................................34
Metodi a blocchi.............................................................................................................................34
Metodi a layer.............................................................................................................................39
Metodi ibridi...............................................................................................................................41
Conclusioni.....................................................................................................................................44
Bibliografia.....................................................................................................................................44
Metriche per il confronto fra algoritmi di compressione di immagini...............................................47
Compression ratio...........................................................................................................................47
Tempo di compressione e decompressione....................................................................................47
Mean Squared Error – MSE...........................................................................................................48
Peak Signal to Noise Ratio – PSNR...............................................................................................48
Structural Similarity Index – SSIM................................................................................................49
Bibliografia.....................................................................................................................................50
ii
Progetto 3D CloudWiz | ATI NICE - DIEE
Obiettivo del documentoScopo di questo documento l’identificazione degli algoritmi più promettenti, tra quelli emergenti,
per la compressione delle informazioni e la definizione di un insieme di metriche che consentano
un efficace confronto dei diversi algoritmi sia nell'utilizzo in contesti generici che nell'applicazione
a particolari categorie di informazioni e di pesare opportunamente la possibilità di modulare dei
parametri di configurazione in modo da poterne modificare dinamicamente il funzionamento in
funzione di contesti operativi (differenti condizioni di banda e latenza).
Il documento è organizzato in diverse sezioni e coprirà i seguenti argomenti:
Compressione lossless di immagini in real-time;
Compressione di immagini generiche a contenuto eterogeneo (compound images);
Metriche per il confronto fra algoritmi di compressione di immagini.
1
Progetto 3D CloudWiz | ATI NICE - DIEE
Compressione lossless di immagini in real-timeIn questa sezione del documento si andrà ad analizzare lo stato dell'arte relativo alla codifica e alla
decodifica delle immagini 2D nello specifico caso di algoritmi di tipo lossless, quindi senza perdita
d'informazione, che possano essere utilizzati in un contesto nel quale sia necessaria la loro
applicazione in real time (RT) o near real time.
In letteratura vengono presentati un elevato numero di algoritmi di compressione di tipo lossy,
specialmente facenti uso di DCT (Discrete Cosine Transform) o di DWT (Discrete Wavelet
Transform) e/o loro combinazioni, mentre gli algoritmi di tipo lossless, presenti in numero più
limitato, rimandano a tecniche di compressione più generiche ed universali per tutti i tipi di dati.
All'interno di quest'insieme di algoritmi risulta ancora più complesso andare ad identificare
tecniche che agiscano in real time o near real time.
L'evoluzione degli studi sugli algoritmi di compressione d'immagini viene inoltre condizionata dalla
presenza sul mercato di alcuni algoritmi di COdifica e DECodifica (CODEC) ormai ritenuti degli
standard (ad esempio i vati PNG, JPEG ecc): essi raggiungono dei risultati tali che risulta complessa
la realizzazione di metodologie che possano migliorarne le performance.
In relazione alle specificità richieste, algoritmi di tipo lossless e funzionanti in real time o near real
time, vengono presentate in questo documento tre categorie di algoritmi di compressione:
algoritmi generici di compressione dati;
algoritmi di compressione immagini considerati standard;
algoritmi di compressione immagini proposti nella ricerca.
Per gli algoritmi generici di compressione dati verrà presentato un riepilogo delle tecniche di
compressione dati più comuni (es. codici di Huffman, LZ77, RLE ecc) con una breve descrizione
dell'algoritmo che esse implementano.
Per quanto riguarda gli algoritmi di compressione immagini considerati standard verranno
presentate, anche con tabelle di confronto, quelle metodologie di compressione più diffuse nel
mercato oggetto di studi specialmente nel settore di sviluppo di tipo industriale (es. JPEG-XR, PNG
2
Progetto 3D CloudWiz | ATI NICE - DIEE
ecc).
Per quanto riguarda gli altri algoritmi allo stato dell'arte proposti nella letteratura verrà presentato
un resoconto delle tecniche che appaiono più interessanti dal punto di vista delle performance
promesse.
Algortimi di compressione dati
In questo paragrafo andiamo ad analizzare le tecniche di compressione dei dati senza perdite, o
lossless, che avviene attraverso l'utilizzo di codici, quindi definendo delle corrispondenze tra
simboli d'ingresso e simboli d'uscita. Tali codici agiscono sui dati in ingresso, che possono essere
sequenze di simboli e/o dati, in virtù di un modello statistico della sorgente che genera gli stessi
simboli.
Il modello al quale si fa riferimento può essere adattativo, quindi costruito e/o perfezionato
contestualmente alla codifica dei simboli, oppure sussistere o essere dato a priori, quindi costruito
sui dati stessi in modo globale ad esempio con una pre analisi delle statistiche dei simboli che
occorre codificare.
L'output di queste tecniche sarà quello di generare un bit-stream dal quale è possibile, mediante
l'operazione inversa di decodifica, risalire perfettamente e senza nessuna alterazione o perdita
d'informazione ai dati originali.
Le principali tecniche di compressione dati presenti in letteratura risultano essere:
codici di Huffman;
codifica aritmetica [1];
LZ77 – LZ78;
LZW(Lempel-Ziv-Welch);
RLE – Run Length Encoding.
Altri algoritmi di compressione dati spesso utilizzati sono:
trasformata di Burrows-Wheeler (BWT) [2];
Prediction by Partial Matching (PPM) [3];
3
Progetto 3D CloudWiz | ATI NICE - DIEE
Deflate [4].
Queste compressioni lossless sono assolutamente generiche, adattabili quindi a qualunque
formato dati, ma al variare della tipologia di dati in ingresso esse offrono prestazioni notevolmente
differenti le une dalle altre.
Combinazioni di queste tecniche, o parti di esse sono già utilizzati all'interno di comuni codec per
immagini. Abbiamo ad esempio che LZW viene utilizzato per le immagini GIF, una variante di
Deflate è stata implementata per PNG, mentre LZW e RLE sono utilizzate direttamente nel formato
TIFF.
Codici di Huffman
I codici di Huffman sono tra i primi algoritmi di compressione dell'informazione. Nel 1952 David A.
Huffman pubblicò un articolo [5] in cui mostrava un metodo per la costruzione di codici con criteri
di minima ridondanza, questo metodo si mostra quindi particolarmente adatto alla compressione
lossless dei dati in differenti contesti.
Si può definire il processo di definizione dei codici come segue:
1) si crea una lista ordinata di simboli in base alle occorrenze degli stessi nel messaggio originale;
2) si ripetono i passi 2a, 2b e 2c tante volte finché all'interno della lista non rimane un unico
simbolo;
a) si determinano i due elementi meno frequenti all'interno della lista. Si crea un nodo
“genitore” dell'albero di Huffman avente come nodi “figli” questi due elementi;
b) si assegna la somma delle frequenze dei nodi “figli” al nodo “genitore” e lo si reinserisce
nella lista ordinata;
c) si cancellano i figli dalla lista ordinata;
3) si assegna infine una parola codice ad ogni elemento basandosi sulla sua posizione a partire
dalla radice: in questo modo i simboli più frequenti saranno codificati con parole più corte e
viceversa quelli più rari con parole più lunghe.
4
Progetto 3D CloudWiz | ATI NICE - DIEE
Questo algoritmo di compressione è stato poi adattato e migliorato in differenti modi. I più
conosciuti, qui non presentati, sono:
Codifica adattativa di Huffman [6];
Algoritmo di Huffman con template;
Codifica di Huffman a base n [7];
Codifica con costi per lettera diseguali [8].
Codifica aritmetica
Negli anni '80 sono stati introdotti nuovi tipi di algoritmi statistici che hanno ovviato ad alcuni
problemi che si presentavano con l'algoritmo di Huffman: i codici aritmetici [12].
Il codice di Huffman associa un valore intero ad ogni elemento della sorgente, il che porta ad un
dispendio eccessivo in termini di memoria e proporzionale al numero di simboli all'interno della
sorgente.
I codici aritmetici codificano invece simboli, o gruppi di simboli, con numeri decimali, e permettono
quindi di adoperare per la codifica dei numeri frazionari di bits.
Se esaminiamo un solo simbolo, ovviamente, i risultati ottenuti con le due diverse tecniche
saranno molto simili; ma una volta che esaminiamo una sequenza lunga di dati d'ingresso, la
somma degli arrotondamenti (tali si possono considerare i bits adoperati dalla codifica di Huffman
rispetto a quelli dei codici aritmetici) per la codifica dei singoli simboli porta ad una differenza
netta tra i risultati ottenuti con i codici aritmetici e il codice di Huffman.
LZ77 – LZ78
Altre tipologie di codifica sono quelle descritte dagli algoritmi Lempel-Ziv: di queste esistono
differenti implementazioni.
Nella prima versione (LZ77) [13] la codifica/compressione avviene mediante la sostituzione di parti
di dati già processate. Si utilizza una finestra di scorrimento dei dati avente dimensione fissa:
quando la finestra incontra un dato ripetuto allora tale dato viene sostituito da una coppia
“lunghezza-distanza” che indica l'esigenza di dover copiare una certa porzione di dati, avente una
certa “lunghezza”, da una determinata “distanza”.
5
Progetto 3D CloudWiz | ATI NICE - DIEE
Con questa tipologia di compressione la possibilità di trovare una corrispondenza nel “dizionario”
per la stringa di dati esaminata è quindi dipendente unicamente dai dati contenuti nella finestra di
scorrimento in quell'istante e non si tiene invece conto dei record precedenti.
Per superare questi inconvenienti e aumentare l'efficacia della codifica Lempel e Ziv, un anno dopo,
svilupparono la codifica LZ78 [14]: si costruisce un dizionario dei dati già incontrati e si
sostituiscono le occorrenze dei dati presenti nella finestra con un riferimento ai dati del dizionario.
La decodifica è analoga alla codifica, all'inizio il dizionario contiene solo la stringa vuota e mentre
viene riempito viene anche restituita la codifica originale.
La differenza con il precedente algoritmo è il ridotto numero di confronti tra stringhe di dati e
quindi una maggiore velocità, riguardo al coefficiente di compressione non ci sono rilevanti
differenze.
Anche a questi algoritmi sono stati applicati diversi adattamenti: da essi, ad esempio, derivano
LZW, LZMA(Lempel Ziv Markov chain) [15] e LZSS [16].
LZW(Lempel-Ziv-Welch)
Nel 1984 Terry Welch rivisitò l'algoritmo LZ78 [17] cercando di migliorarlo dal punto di vista della
velocità adottando un dizionario base non vuoto.
L’algoritmo LZW si basa sulla creazione di un dizionario di stringhe ricorrenti in un determinato
insieme di dati utilizzando un dizionario di base che di norma è costituito dai 255 caratteri
derivanti dalla codifica ASCII.
Leggendo un unico carattere alla volta si aggiorna il dizionario mantenendo la sequenza codificata
più lunga incontrata sino a quel momento. La velocità di questo algoritmo, rispetto a LZ78, è tale
che l'ha portato da essere stato scelto e utilizzato in sistemi come:
l'utility UNIX compress/uncompress.
formato grafico TIFF.
formato grafico GIF.
standard V.42 bis per la trasmissione dati.
6
Progetto 3D CloudWiz | ATI NICE - DIEE
Il prezzo da pagare per un incremento di performance in termini di velocità è un fattore di
compressione che risulta non essere elevato.
RLE – Run Length Encoding
L'algoritmo RLE è una forma molto semplice di codifica per la compressione dati.
Esso è basato sul fatto che in ogni flusso di dati sono presenti diversi dati simili, i valori ripetuti
vengono definiti “run”, questi dati ridondanti saranno sostituiti con un contatore e il valore ad esso
associato.
Questo tipo d’algoritmo intuitivo funziona bene con tipologie di dati in cui in cui sono presenti un
largo numero di occorrenze consecutive dello stesso byte pattern: da questo deriva il suo largo
impiego nel settore legato alla compressione di immagini. Ad esempio RLE si presta bene per la
compressione di formati grafici come BMP, PCX, TIFF (basandosi sulla ridondanza spaziale delle
immagini) e viene anche utilizzato in alcune implementazione di formati editoriali come PDF o
nella tecnologia per l'invio di FAX.
Possiamo trovare diverse implementazioni di quest’algoritmo:
RLE a livello di bit: ogni byte codifica sequenze di bit uguali;
RLE a livello di byte: ogni run è codificato da due byte;
RLE a livello di byte misto: si utilizza il concetto di byte di lunghezza, ossia un byte in cui il
bit più indicativo denota il tipo di run (1 = compresso, 0 = non compresso).
Deflate
L'algoritmo Deflate è un algoritmo per la compressione dei dati introdotto dal programma PKZIP, e
quindi formalizzato nella RFC 1951 [18]. Esso utilizza una combinazione dei metodi di
compressione LZ77 e la codifica di Huffman.
Deflate comprime i dati del flusso d'ingresso in blocchi di byte di lunghezza arbitraria massima di
64KB. Ognuno di questi blocchi è compresso separatamente mediante una combinazione di LZ77 e
Huffman secondo il seguente criterio:
gli alberi di Huffman usati per un blocco sono indipendenti da quelli utilizzati per blocchi
precedenti o successivi;
7
Progetto 3D CloudWiz | ATI NICE - DIEE
LZ77 può utilizzare un riferimento a una stringa duplicata vista in precedenza nella
sequenza di input.
La decisione relativa alla modalità di suddivisione in blocchi viene demandata all'utilizzatore finale
in base alle proprie esigenze e in base alla tipologia di dato da andare a comprimere.
Algoritmi di compressione lossless per immagini
In questa sezione vengono presentati i principali algoritmi di compressione e decompressione delle
immagini considerati degli standard.
In particolare si farà riferimento alle alla famiglia di codec lossless appartenenti allo standard JPEG
(Lossless Jpeg / Jpeg-LS, Jpeg2000 e JpegXR), il formato GIF e il formato PNG.
Vengono inoltre presentati ImageZero e LZ4 che, pur non rappresentando una novità in termini di
tecniche di compressione, rappresenta una novità in quanto aggiunge la parallelizzazione delle
operazioni rispetto alle implementazioni dei codec tradizionali al fine di garantire una notevole
velocità di codifica.
Lossless JPEG e JPEG-LS
A partire dal 1993, in seguito al successo della serie degli standard JPEG lossy, la commissione JPEG
(Joint Photographic Experts Group) valutò che fosse necessario adottare una modalità di
compressione lossless nello standard JPEG.
La prima versione del "lossless" JPEG codificava la differenza tra ogni pixel ed il valore "predetto"
per quel pixel. Il valore "predetto" è il risultato di una funzione che usa come parametri i valori dei
pixel che si trovano sopra, sopra a sinistra e immediatamente alla sinistra del pixel in esame. Tale
codifica viene anche chiamata Pulse Code Modulation (DPCM) e veniva utilizzata al posto della
comune DCT utilizzata nel lossy JPEG.
La sequenza di dati ottenuta veniva poi codificata con il metodo di Huffman o con altre codifiche
aritmetiche.
La ricerca di un sostituto che garantisse minore complessità computazionale e aumentasse le
performance in termini di efficienza di compressione portò all'analisi di algoritmi che
continuassero a non utilizzare la DCT – o le trasformazioni tra spazi di colore – ma che altresì
8
Progetto 3D CloudWiz | ATI NICE - DIEE
portassero ad una compressione lossless o quasi lossless. Il risultato di tale ricerca è stato poi
standardizzato in ISO-14495-1/ITU-T.87 con il nome di JPEG-LS.
Il core del JPEG - LS è basato sull'algoritmo LOCO -I [19]di HP che si contraddistingue in quanto la
fase di codifica viene preceduta da due fasi: quella di predizione e quella di modellazione degli
errori.
La bassa complessità di questa tecnica deriva da due fattori:
il fatto che la previsione residuale segue quella che viene chiamata “Discrete Laplace Distribution”;
l'utilizzo, in fase di codifica, di codici come quelli di Golomb-Rice, noti per essere ideali per le
distribuzioni geometriche.
Di seguito una tabella comparativa che illustra i risultati di compressione per un test set di
immagini con l'utilizzo di differenti algoritmi candidati ad appartenere allo standard JPEG-LS
espressi in bits/sample [20]:
Image LOCO-I JPEG-LS FELICS LossLessJPEGHuffman
LossLessJPEGArithm
CALICArithm
LOCO-A PNG
Bike 3.59 3.63 4.06 4.34 3.92 3.50 3.54 4.06
cafe 4.80 4.83 5.31 5.74 5.35 4.69 4.75 5.28
woman 4.17 4.20 4.58 4.86 4.47 4.05 4.11 4.68
tools 5.07 5.08 5.42 5.71 5.47 4.95 5.01 5.38
bike3 4.37 4.38 4.67 5.18 4.78 4.23 4.33 4.84
cats 2.59 2.61 3.32 3.73 2.74 2.51 2.54 2.82
water 1.79 1.81 2.36 2.63 1.87 1.74 1.75 1.89
finger 5.63 5.66 6.11 5.95 5.85 5.47 5.50 5.81
us 2.67 2.63 3.28 3.77 2.52 2.34 2.45 2.84
chart 1.33 1.32 2.14 2.41 1.45 1.28 1.18 1.40
chart s 2.74 2.77 3.44 4.06 3.07 2.66 2.65 3.21
compound1 1.3 1.27 2.39 2.75 1.50 1.24 1.21 1.37
compound2 1.35 1.33 2.40 2.71 1.54 1.24 1.25 1.46
9
Progetto 3D CloudWiz | ATI NICE - DIEE
aerial2 4.01 4.11 4.49 5.13 4.14 3.83 3.58 4.44
faxballs 0.97 0.90 1.74 1.73 0.84 0.75 0.64 0.96
gold 3.92 3.91 4.10 4.33 4.13 3.83 3.85 4.15
hotel 3.78 3.80 4.06 4.39 4.15 3.71 3.72 4.22
Media 3.18 3.19 3.76 4.08 3.40 3.06 3.06 3.46
JPEG2000 – lossless
Si tratta del successore designato del JPEG, già ufficializzato come standard ISO/ITU che va sotto il
nome di JPEG2000 [21].
La versione completa delle specifiche relative a questo formato è scaricabile dalla pagina web del
JPEG.org [22].
JPEG2000 è completamente diverso dal suo predecessore JPEG: propone prima di tutto il fatto che
uno stesso algoritmo possa essere adatto sia alla codifica lossy che a quella lossless.
La differenza tra i due standard è sostanziale e possiamo brevemente identificarle come segue:
durante la prima trasformazione, quella che in JPEG veniva svolta tramite l'utilizzo di una
DCT (Discrete Cosine Transform), in JPEG2000 si utilizza la DWT (Discrete Wavelet
Transform);
la fase di quantizzazione dei valori è opzionale in JPEG2000 se l'utente desidera ottenere
una compressione senza perdita d'informazione.
JPEG utilizza una versione avanzata della codifica di Huffman, JPEG2000 utilizza un metodo
chiamato Embedded Block Coding with Optimized Truncation (EBCOT) [23].
Queste non sono però le uniche differenze apportate rispetto allo standard JPEG: a causa di questo
i programmi attuali più diffusi (software di grafica, viewer e browser) e l'hardware (ad esempio le
fotocamere digitali) non supportano nativamente il nuovo formato dello standard.
Questo fatto non gioca a favore di JPEG2000 vista l'ampissima diffusione del formato JPEG (oltre
l'80% delle immagini è codificato con lo standard JPEG) per cui il futuro di questo nuovo formato è
ancora molto incerto nonostante le potenzialità che offre.
10
Progetto 3D CloudWiz | ATI NICE - DIEE
Questi i passaggi per la codifica con JPEG2000 lossless:
Passo 1) Preprocessing
Se stiamo comprimendo un'immagine a colori occorre trasformare l'immagine nello spazio
YCbCr e, per ogni canale, sottraiamo 127 ad ogni valore “unsigned” contenuto in esso. In
questo modo avremo una “centratura” dei valori sullo 0.
Passo 2) Trasformazione
Uno dei principali cambiamenti nello standard JPEG2000 è l'uso della Trasformazione
Wavelet Discreta (DWT) invece della DCT. Il risultato di quest’operazione è la decorrelazione
tra le informazioni di bassa e alta frequenza contenute nell’immagine.
La DWT si applica poi ricorsivamente, solitamente 2/3 volte, alla componente delle basse
frequenze. Il risultato finale di tutta l'operazione è che l'intero contenuto informativo
dell'immagine originale è stato segmentato in una serie di trasformazioni successive, che
potranno poi essere compresse in un minimo spazio e poi decompresse in modo
reversibile.
Alla DWT vengono applicati dei filtri per la compressione, nel caso lossless solitamente il
filtro LeGall53 o W5x3. Nel caso lossy i filtri applicati sono differenti.
C'è da fare presente che la complessità della DWT dipende dalla dimensione dei filtri
applicati e dal tipo di filtro. Solitamente essa è computazionalmente più complessa della
DCT e richiede anche una maggiore memoria.
Passo 3) Quantizzazione
Nel caso di codifica lossless non si applica alcun tipo di quantizzazione.
Passo 4) Encoding
Per la compressione senza perdita di dati, usiamo semplicemente la metodologia EBCOT
[24]per codificare gli elementi della trasformazione wavelet.
JPEG XR
JPEG XR [25], precedentemente conosciuto come HD Photo [26], è un formato per la compressione
11
Progetto 3D CloudWiz | ATI NICE - DIEE
delle immagini sviluppato da Microsoft e studiato per superare la limitazione degli 8 bit per canale
del formato JPEG estendendo la profondità del colore a 16 bit o più, supportare un numero
maggiore di di spazi di colore e garantire la possibilità di gestire porzioni di immagine senza dover
decodificare l’intera immagine.
La qualità dell'immagine, percettivamente comparabile a quella del JPEG2000, ha un carico
computazionale più vicino a quello del JPEG offrendo però una compressione superiore anche in
caso di compressione lossless.
L'algoritmo di compressione è molto simile a quello JPEG:
avviene una trasformazione in un differente spazio di colore;
ogni piano di colore viene suddiviso in blocchi di dimensione fissa;
i blocchi vengono trasformati sotto il dominio della frequenza e gli viene applicata una
codifica entropica.
Essendo la trasformazione da RGB a YCbCr leggermente lossy (introduce infatti dei piccoli errori in
fase di arrotondamento), il nuovo standard JPEG XR propone l'adozione della trasformazione dallo
spazio RGB a quello YUV.
La fase di trasformazione nel campo della frequenza avviene su blocchi di dimensioni inferiori e
senza l'utilizzo della trasformata DCT bensì utilizzando, come nel JPEG2000, la DWT (Discrete
Wavelet Transform) utilizzando l'algoritmo con schema “lifting” [27]: esso è un metodo alternativo
per il calcolo dei coefficienti delle wavelet avente un minore costo computazionale e un minore
utilizzo di memoria.
Il vantaggio di questa codifica rispetto a JPEG2000 è il fatto che questa è già supportata dalla gran
parte dei software che utilizzano immagini.
Confronti tra i tre algoritmi precedentemente descritti
In letteratura sono già presenti [28] dei test comparativi tra i tre algoritmi fin'ora trattatati. A puro
titolo d'esempio di seguito vengono riportati brevemente i risultati d'interesse riferiti alle immagini
Lena.bmp, Peppers.bmp, Couple.bmp e Sailboat on Lake.bmp (in alcuni casi si parte da formati
.ppm o .pnm) presenti all'indirizzo http://sipi.usc.edu/database ed utilizzati per avere un PSNR pari
12
Progetto 3D CloudWiz | ATI NICE - DIEE
a 40db (valori in tabella in bpp)
TEST JPEG-2000 JPEG-XR JPEG-LS
Lena.bmp 5 4.2 5.5
Peppers.bmp 6.6 6 5.5
Couple.bmp 3.4 3 4.5
Sailboat on Lake.bmp 8 7 6.7
GIF
Il formato GIF (Graphic Interchange Format), diffuso alla fine degli anni 80, usa una forma di
compressione LZW che mantiene inalterata la qualità dell'immagine.
La profondità dei colori delle immagini GIF è di 8 bit, che consente di usare una tavolozza di
massimo 256 colori. Consente inoltre di inserire la trasparenza ad uno dei colori individuati.
Lo schema di compressione LZW è più adatto a comprimere immagini con grossi campi di colore
omogeneo ed è meno efficiente nella compressione di immagini complesse con molti colori e
grane/finiture complesse.
Tale formato è stato superato a partire dal 1995 a causa dello sviluppo del PNG.
PNG
Il formato di codifica PNG [29] (Portable Network Graphics) è un formato grafico di tipo raster
(bitmap) basato sulla compressione deflate. È stato elaborato nel 1995 per fornire un'alternativa
libera al formato GIF per la quale era stato improvvisamente richiesto il pagamento delle royality di
utilizzo.
La compressione proposta con questo formato è una compressione senza perdita (lossless
compression) da 5 a 25% migliore della compressione GIF.
PNG può supportare colori fino a 32 bit. Il formato PNG-8, il primo nato, presenta effettivamente
molte analogie con il formato GIF. Il formato PNG-24 è invece più “simile” a un JPEG e può
supportare la trasparenza anche su più livelli di colore.
Esso possiede solitamente una funzione di intreccio che permette di visualizzare progressivamente
l'immagine.
13
Progetto 3D CloudWiz | ATI NICE - DIEE
La struttura dei file PNG è composta come segue:
una firma in esadecimale del file che identifica il tipo PNG
una serie di chunks dell'immagine
I chunks dell'immagine contengono il contenuto informativo dell'immagine stessa. I più importanti
sono quelli definiti “critical”:
IHDR Image header
PLTE Palette
IDAT Image data
IEND Image trailer
Oltre a questi chunks principali sono poi presenti chunks “accessori”.
I chunks possono essere presenti nel file in qualsiasi ordine ma devono cominciare dal segmento di
titolo (IHDR chunk) e finire dal segmento finale (IEND chunk).
I chunks a loro volta sono suddivisi in quattro parti:
dimensione del chunk, un numero intero di 4 byte
tipo del chunk, un codice di 4 byte di caratteri ASCII alfanumerici che identificano la
tipologia del chunk
i dati del chunk
il CRC (cyclic redundancy check), un codice correttore di 4 byte che permette di verificare
l'integrità del segmento
Di seguito una tabella riepilogativa relativa alla conversione di un'immagine campione che
evidenzia le differenze di compressione tra PNG e le varie compressioni legate al JPEG impostando
la qualità di output pari al 100%.
TEST BMP JPEG (Qualità 100%) JPEG-XR (Qualità 100%) PNG
Butterfly.bmp 668 KB 201 KB 251 KB 267 KB
Questi valori sono stati ottenuti utilizzando il tool di grafica Gimp sulla seguente immagine
14
Progetto 3D CloudWiz | ATI NICE - DIEE
d'esempio avente dimensioni 485x353 reperita gratuitamente sul sito http://pngimg.com/:
Implementazioni multithread di diverso tipo
Come già specificato in fase introduttiva vengono qui di seguito presentati due differenti tools di
compressione, uno specifico per le immagini (ImageZero) e uno più generico (LZ4) che pongono il
loro punto di forza sulla velocità d’esecuzione dell’algoritmo di compressione e decompressione
piuttosto che sui livelli di compressione raggiunti.
Tali performance vengono perseguite adattando gli algoritmi di compressione alle potenze di
calcolo offerte dai moderni processori: in particolare si fa un forte utilizzo del multithreading.
ImageZero
ImageZero [30] nasce nel 2012 da un progetto di Chistoph Feck, sviluppatore di KDE, che ricercava
un codec estremamente veloce, che fosse di tipologia lossless e che offrisse un discreto rapporto di
compressione.
Non avendo trovato quello che cercava ha stabilito di realizzarlo lui stesso. Le piattaforme di
benchmark indipendenti per la valutazione delle prestazioni relative alle procedure di codifica e
decodifica lossless documentano la velocità e la qualità del suo codec [31] [32].
Il codice è attualmente al primo stadio di sviluppo ma è estremamente promettente: rispetto al
PNG comprime un'immagine PPM a 24 bit circa 20 volte più velocemente e la decomprime 2 volte
più velocemente. Il tasso di compressione è estremamente prossimo a quello del PNG.
L'algoritmo utilizzato è molto semplice: la compressione e la decompressione viene realizzata “per
pixel”, senza branches (ad eccezione di un unico branch nel bit coder), in modo che sulle moderne
CPU possa essere eseguito molto velocemente e in parallelo.
Questo tipo di codifica non è adatta per grafici o per immagini in scala di grigi.
15
Progetto 3D CloudWiz | ATI NICE - DIEE
Andando ad utilizzare come immagine campione quella presente all'indirizzo seguente:
http://www.flickr.com/photos/anirudhkoul/3499471010/sizes/o/in/photostream/
questi sono i risultati ottenuti per le varie tipologie di codifica e decodifica:
Metodo Dimensione del File (KB) Tempo di Compressione (s) Tempo di Decompressione (s)
Originale 46380 - -
JPEG-LS 14984 6,6 7,3
PNG 16256 42,4 2,4
ImageZero 15496 1,2 1,3
Alcuni interessanti risultati compresi nel “LossLess Photo Compression Benchmark” mostrano i
risultati dei tempi di compressione e decompressione dei sistemi di compressione lossless applicati
su un database di circa 3.46 GB.
Quello che viene evidenziato è che il formato ImageZero, rilasciato con licenza BSD, così come il
codice al quale fa riferimento, è nettamente il codec più veloce e garantisce una notevole velocità
sia di compressione che di decompressione. La tabella seguente fornisce un riepilogo di quanto
emerge.
Software / Codec Licenza Dimensione (%) Compressione (s) Decompressione (s)
Originale - 100 - -
bzip2 -1 bzip2 License 56,3 476 218
PNG libpng License 42,5 844 72
ImageZero BSD 41,3 23 21
JPEG-LS HP License 37,4 107 92
lossless WebP BSD 35,6 7525 110
Flic Proprietario 30,0 210 231
Gralic Proprietario 28,1 1734 1897
16
Progetto 3D CloudWiz | ATI NICE - DIEE
LZ4
LZ4 [33] è un algoritmo di compressione di dati generici, derivante dal filone dei codec LZ77,
particolarmente orientato ad aumentare notevolmente le velocità di compressione e
decompressione.
Attualmente è un progetto presente su google-code [34] e sta avendo un notevole successo in
quanto riesce a garantire velocità di 400MB/s per ogni core dedicato alla compressione.
L'algoritmo è inoltre scalabile con le CPU multi core. I tempi di decompressione ottenuti sono
nell'ordine dei GB/s e raggiungono, nei sistemi multi core, il limite di velocità della ram.
Di seguito, in Tabella 6, viene riportato uno schema comparativo con le performance registrate da
LZ4 rispetto ad altri algoritmi/tools di compressione
Tool Ratio Comp. Speed (MB/s) Decomp. Speed (MB/s)
LZ4 (r101) 2,084 422 1820
LZO 2.06 2,106 414 600
QuickLZ (1.5.1b6) 2,237 373 420
Snappy 1.1.0 2,091 323 1070
LZF 2,077 270 570
Zlib 1.2.8 -6 3,099 21 300
Algoritmi di compressione proposti in letteratura
Di seguito vengono messi in risalto quelli che sembrano essere gli algoritmi di compressione per
immagini più promettenti presenti in letteratura. Il vincolo della ricerca di compressioni lossless (o
near lossless), real time (o near real time) e applicabili a immagini con un contenuto generico ha
portato a un'elevata scrematura dell'offerta scientifica disponibile.
La gran parte degli articoli analizzati è risultata essere non idonea allo scopo del presente
documento. Molte delle pubblicazioni fanno inoltre riferimento a dataset di test non pubblici e/o
comunque di difficile reperibilità o aventi un contenuto molto limitato d'immagini pregiudicando
l'eventuale ripetibilità dei test presentati.
Gli approcci mostrati sono quindi unicamente quelli che presentano delle misure di prestazioni
relative a un dataset di dimensione sufficiente o relative a set di immagini standard.
17
Progetto 3D CloudWiz | ATI NICE - DIEE
A Lossless Image Compression Technique using Location Based Approach
A Lossless Image Compression Technique using Location Based Approach [32] è una tecnica per la
compressione lossless d'immagini basata sulla divisione in blocchi 4x4 dell'immagine originale e in
una loro successiva compressione.
L'algoritmo in oggetto si basa essenzialmente su pochi semplici passi:
1) scomporre l'immagine in blocchi 4x4 non sovrapposti
2) per ogni blocco poi
a) convertire il blocco in un array di 16 elementi con un approccio “da sinistra a destra e
dall'alto in basso”
b) individuare il valore più frequente all'interno dell'array (MFP) e eliminarlo
c) scrivere il valore dell'MFP sul bit stream d'uscita susseguito da 4 bit che indicano il numero
di occorrenze (la frequenza) dell'MFP
d) individuare la frequenza del secondo valore più frequente all'interno dell'array (SMFP): se
occorrono k bit per rappresentare questa frequenza, scrivere k nei successivi 4 bit nel bit
stream d'uscita
e) scrivere quindi il valore dell'SMFP in 8 bit
f) scrivere il numero di occorrenze dell'SMFP
g) scrivere tutte le posizioni delle sue occorrenze in k bit
h) ripetere i passi da e) a g) per tutti i distinti valori di pixel rimasti nell'array
3) ripetere per ogni blocco
per un'immagine a colori occorre ovviamente ripetere l'intero algoritmo per ogni componente di
colore.
Una tabella comparativa dei risultati di compressione, in termini di dimensione dell'immagine in
bit, riportata nell'articolo viene di seguito proposta:
TEST Non compressa GIF TIFF PNG LICTLBA
18
Progetto 3D CloudWiz | ATI NICE - DIEE
Lena 2097152 443187 521830 387482 252082
Baboon 2097152 654541 535107 501350 196608
Iris 2097152 901120 802816 630784 201583
L'articolo presentato propone un metodo di compressione che sembra dare buoni risultati ma
risulta anomalo il numero ridotto di campioni su cui vengono eseguiti i test. Inoltre esso sembra
presentare dei limiti, ad esempio, il caso in cui tutti i pixel siano diversi comporterebbe un aggravio
in termini di dimensioni dell'immagine, si avrebbero infatti per un singolo blocco 4x4 di un singolo
canale di un'immagine:
8 bit per MFP
bit per la frequenza MFP
4 bit per la rappresentazione di K
8 bit per SMFP
1 bit per la frequenza di SMFP
4 bit per la posizione di SMFP
(8 + 1 + 4)*14 = 182 bit per i restanti valori dei pixel
per un totale di 211 bit di un blocco compresso contro 128 bit del blocco non compresso. L'articolo
stesso specifica però che nei blocchi di test 4x4 analizzati, circa 100.000, solo in una piccola parte
di questi, 79, si è verificato il caso peggiore precedentemente indicato.
Context-based Dictionary Image Compression
Il Context-based Dictionary Image Compression (CDIC) [33] è un algoritmo proposto nel 2012 e che
propone l'applicazione di tecniche di compressione di dati testuali anche nel campo delle
immagini.
In particolare la tecnica di compressione da applicare alle immagini è quella proposta da Nakano e
altri [34] nel 1994, il Classifying to Sub-Dictionaries (CSD), che propone l'idea di combinare
tecniche di compressione basate su dizionari a tecniche di compressione basate sul contesto dei
19
Progetto 3D CloudWiz | ATI NICE - DIEE
dati: in particolare combinando la compressione Lempel-Ziv-Welch (LZW) con lo schema Prediction
by Partial Matching (PPM).
L'algoritmo in questione utilizza un numero elevato di sottodizionari che sono inizialmente presi in
considerazione con tutti i possibili singoli caratteri.
Ogni stringa da codificare viene codificata in base all'ultimo simbolo presente nella precedente
sotto stringa che viene associato al dizionario secondario da utilizzare. Una volta individuato il
dizionario, si utilizza l'algoritmo LZW per la compressione dei dati.
Utilizzando sempre l'ultimo elemento per la codifica di una stringa successiva, viene considerato
[35] come uno schema PPM del primo ordine.
L'applicazione del CSD alle immagini bidimensionali è stata testata e confrontata con le prestazioni
offerte dalla semplice compressione LZW. Per completezza di analisi, per la predizione del corretto
sotto dizionario da andare a utilizzare, sono stati effettuati due differenti test: in un caso veniva
sfruttato il valore del pixel a sinistra, mentre in un secondo caso il valore del pixel superiore.
Quello che viene evidenziato dai test condotti su 9 immagini standard è che mediamente la
codifica LZW riduce lo spazio occupato del 14%, mentre con la codifica CSD si può arrivare fino al
17%. I risultati pubblicati non sono entusiasmanti in termini di compressione anche perché, come
nella maggior parte dei casi, non vengono riportati i tempi di codifica e decodifica delle immagini.
Nella tabella a seguire vengono riportati i risultati ottenuti dai test svolti da El-Sakka dove i valori
sono da intendersi in byte.
TEST Non Compressa LZW CSD (Pixel sinistro) CSD (Pixel Superiore)
Boats 103680 91183 87215 88816
Camera 65536 54720 51106 52325
Columbia 57600 52350 49666 50845
Crowd 262144 196955 188488 190171
Lake 262144 243225 235806 237016
20
Progetto 3D CloudWiz | ATI NICE - DIEE
Man 262144 227473 220547 212930
Milkdrop 65536 55368 54290 53992
Peppers 65536 64423 63008 62515
Plane 65536 56218 53928 54840
A new Algorithm for Lossless Compression applied to two-dimensional Static Images
A new Algorithm for Lossless Compression applied to two-dimensional Static Images (ALCSI) [36] è
stato proposto nel 2012 e prevede l'utilizzo di una tecnica ibrida per la compressione delle
immagini che sfrutta i concetti introdotti dall'algoritmo INA [37] per la parallelizzazione del
processo.
I risultati sperimentali del metodo INA, dello stesso autore, evidenziano come il metodo indicato
abbia performance superiori alla codifica di Huffman e al JPEG-LS, di seguito un breve schema
riassuntivo nella tabella seguente relativo alla compressione di un'immagine 2048x2048 in cui la
compressione, per il metodo INA è stata ottenuta in 0.105 secondi:
METHODS COMPRESSION RATIOS
Huffman Coding 4%
Prediction 27%
JPEG-LS (Standard) 54%
INA 58%
Il metodo si compone di tre fasi: una prima fase di segmentazione dell'immagine, una seconda fase
di compressione e una terza di codifica.
Nella prima fase, l'intera immagine viene suddivisa in blocchi di dimensione fissa: ogni blocco
genera due gruppi distinti. Un primo gruppo che identifica la sequenza dei pixel del blocco ordinati
in ordine crescente e l'altro che rappresenta una sequenza formata da pixel organizzati in gruppi di
coppie ordinate. I vantaggi apportati dalla segmentazione dell'immagine, tipicamente in blocchi di
21
Progetto 3D CloudWiz | ATI NICE - DIEE
dimensione 4x4, sono essenzialmente riconducibili all'aumento in termini di velocità, alla riduzione
della memoria richiesta e all'adattamento dei dati stessi per l'utilizzo nell'albero binario.
La seconda fase, quella di compressione, è la novità apportata da questo metodo e si riferisce
all'esecuzione parallela della compressione dei due gruppi ottenuti nella prima fase di
segmentazione tramite l'utilizzo di un albero binario e uno schema di predizione.
Nella terza ed ultima fase viene applicato un codificatore per la generazione del bit stream d'uscita.
I risultati sperimentali pubblicati nella tabella seguente legati a questo metodo sono stati dei lievi
miglioramenti nelle misure del rapporto di compressione e dei bit per punto rispetto al JPEG-LS.
METHODS COMPRESSION RATIOS BPP
Methods based on Substitution models 1,03 7,79
Methods based on Arithmetic models 1,11 7,21
Methods based on Dictionary models 1,23 6,53
Methods based on Predictive models 1,57 5,09
Methods based on Transformed models 1,76 4,54
JPEG-LS Standard 1,75 4,57
ALCSI 1,77 4,52
Fast Lossless Color Image Compressing Method Using Neural Network
L'approccio mostrato nel 2002 con la pubblicazione “Fast Lossless Color Image Compressing
Method Using Neural Network” [38] mira a rinunciare alle prestazioni in termini di compressione
per andare invece a migliorare i tempi di compressione dei dati dell'immagine.
Gli autori propongono un algoritmo di tipo predittivo che consta di tre fasi.
Nella prima fase si procede a una trasformazione dello spazio di colore: seguendo gli esempi di
JPEG-LS e JPEG2000 gli autori propongono un loro nuovo spazio di colore. Partendo dalle
componenti originali (denominate genericamente A1, A2 e A3) si ottengono le nuove componenti
secondo queste equazioni:
A1' = floor (0.25A1 + 0.5A2 + 0.25A3)
22
Progetto 3D CloudWiz | ATI NICE - DIEE
A2' = A1 - A2
A3' = A3 - A2
la trasformazione è ovviamente reversibile.
Nella seconda fase si applica invece un modello predittivo: il valore del pixel è predetto pesando i
valori dei quattro pixel in direzione in alto a sinistra. Se il pixel d'interesse è nella prima o
nell'ultima colonna o se è nella prima riga, si utilizza un valore di default per il pixel vicino
mancante. Il pixel k-simo in posizione (i,j) sarà calcolato come:
Pk(i,j) = w1Pk(i,j-1) + w2Pk(i-1,j-1) + w3Pk(i-1,j) +w4Pk(i-1,j+1)
dove i generici w inizialmente assumeranno il valore 0.25.
Nella terza fase viene invece utilizzato una correzione adattativa dei singoli pesi in base
all'algoritmo riportato in [39] attraverso l'utilizzo di una rete neurale a due livelli.
I risultati ottenuti da questo metodo indicano che con questo metodo è possibile ottenere una
compressione nettamente superiore che con il solo utilizzo dei metodi di Huffman o Lzw. Si ottiene
inoltre un rapporto di compressione un po' peggiore rispetto a JPEG-LS ma si riesce, con l'utilizzo
della metodologia proposta, a migliorare i tempi di compressione dell'immagine stessa.
Di seguito sono mostrate due tabelle che riassumono tali prestazioni. Nella prima si fa riferimento
al numero medio di bits per codificare ogni pixel, nella seconda vengono indicati i tempi di
compressione ottenuti per le immagini di test.
I risultati di compressione vengono proposti in termini di bits/pixel:
Image Huffman LZW JPEG-LS Proposed
Scenery1 2,92 5,01 2,13 2,20
Scenery2 2,27 4,20 1,83 1,89
Aerial 2,65 3,92 1,90 2,22
Computer's 2,47 3,08 2,21 2,55
Peppers 4,67 5,84 3,88 4,28
23
Progetto 3D CloudWiz | ATI NICE - DIEE
Lena 5,12 6,78 4,52 4,76
I tempi di compressione, in termini di secondi, vengono riportati nella seguente tabella:
Image Huffman LZW JPEG-LS Proposed
Scenery1 6,88 9,87 6,21 5,10
Scenery2 9,35 13,32 8,68 7,27
Aerial 6,83 7,90 6,62 5,55
Computer's 5,24 8,68 4,46 3,89
Peppers 1,18 3,12 0,60 0,51
Lena 2,87 3,89 1,05 0,90
Conclusioni
La letteratura scientifica, in relazione a codec lossless o near lossless che possano essere utilizzati
in real time o in near real time, risulta essere limitata.
Negli ultimi anni la comunità scientifica si è concentrata infatti ad affrontare le problematiche
relative alla compressione e decompressione d'immagini seguendo gli andamenti del mercato: si è
manifestata infatti una proliferazione di studi su specifiche tipologie d'immagine a discapito di
studi legati a immagini generiche (in formato RGB o BGR).
Ad esempio si riscontrano un numero elevato di studi legati alle immagini realizzate secondo il
criterio Bayer CFA [40-42], specifico in particolare per immagini fotografiche ad elevata risoluzione
e dipendente dai filtri implementati nelle fotocamere, come mostrato dagli studi in corso anche in
aziende come Microsoft [43]; si ha anche la ricerca di nuove tecniche di codifica legato a immagini
di tipo medicale [44,45], legato alle immagini astronomiche [46] o più genericamente alle
24
Progetto 3D CloudWiz | ATI NICE - DIEE
tematiche del compound image compression [47,48].
Quello che viene evidenziato è che gli algoritmi e i formati di compressione già presenti sul
mercato (JPEG XR, PNG ecc) sono attualmente considerati stabili e affidabili. Le prestazioni che essi
offrono vengono valutate sufficienti per l'esigenza attualmente manifestata dal mercato: essi
risultano offrire rapporti di compressione molto buoni, superati solo minimamente dai nuovi
algoritmi presentati in letteratura, e tempi di compressione ragionevoli per le più diffuse
applicazioni.
Quello che si evidenzia è inoltre la presenza di una serie di studi e implementazioni che mirano ad
utilizzare le codifiche dati ritenute standard (Huffman, LZ78 ecc) parallelizzandone però il processo
ed adattando quindi queste tecniche al multi threading offerto dai processori oppure andando ad
implementare i medesimi algoritmi al fine di utilizzare la potenza di calcolo presente nella GPU del
sistema.
Ovviamente tali soluzioni non migliorano il rapporto di compressione offerto dagli algoritmi ma si
limitano a migliorare i tempi legati alla compressione e decompressione dei dati.
Bibliografia
1. «http://math.unipa.it/~epifanio/tecnologie/compr07_08.pdf,» [Online].
2. M. Burrows e D. Wheeler, «A block sorting lossless data compression algorithm».
3. «http://compressions.sourceforge.net/PPM.html,» [Online].
4. «http://tools.ietf.org/html/rfc1951,» [Online].
5. D. Huffman, «A method for the construction of minumum-redundancy codes».
6. P. E. Black, «Adaptive Huffman coding,» in Dictionary of Algorithms and Data Structures.
7. P. E. Black, «K-ary Huffman coding,» in Dictionary of Algorithms and Data Structures.
8. M. Golin, C. Kenyon e N. Y. Young, «Huffman Coding with Unequal Letter Costs».
9. I. Witten, R. Neal e J. Cleary, «Arithmetic Coding for Data Compression».
10. J. Ziv e A. Lempel, «A Universal Algorithm for Sequential Data Compression».
11. J. Ziv e A. Lempel, «Compression of Individual Sequences via Variable-Rate Coding».
25
Progetto 3D CloudWiz | ATI NICE - DIEE
12. D. Salomon, «Data Compression: The Complete Reference».
13. J. Storer e T. Szymansky, «Data Compression via Textual Substituion».
14. T. Welch, «A Technique for High-Performance Data Compression».
15. «http://tools.ietf.org/html/rfc1951,» [Online].
16. M. Weinberger, G. Seroussi e G. Sapiro, «The LOCO-I Lossless Image Compression
Algorithm: Principles and Standardization into JPEG-LS».
17. «http://www.hpl.hp.com/research/info_theory/loco/HPL-98-193R1.pdf,» [Online].
18. M. Charrier, D. Santa Cruz e M. Larsson, «JPEG2000, the Next Millenium Compression
Standard for Still Images».
19. «http://www.jpeg.org/jpeg2000/,» [Online].
20. D. Taubman e M. Marcelin, «JPEG2000: Image Compression Fundamentals, Standards and
Practice».
21. AA.VV., «http://www.hpl.hp.com/techreports/2001/HPL-2001-35.pdf,» [Online].
22. AA.VV., «Recommendation T.832 /03/2009, updated 12/2009: Information Technology –
JPEG XR image coding system – Part 2: Image coding specification».
23. AA.VV., «HD Photo: a New Image Coding Technology for Digital Photography».
24. «http://www.dsi.unifi.it/~berretti/download/jpeg-2000.pdf,» [Online].
25. A. Solanki, «Implementation and performance analysis of JPEG2000, JPEG, JPEG-LS, JPEG-
XR and H.264/AVC Intra frame coding,» [Online].
26. «http://www.ietf.org/rfc/rfc2083.txt?number=2083,» [Online].
27. «http://imagezero.maxiom.de/,» [Online].
28. http://www.squeezechart.com/bitmap.html. [Online].
29. «http://www.imagecompression.info/gralic/LPCB.html,» [Online].
30. «http://fastcompression.blogspot.it/2011/05/lz4-explained.html,» [Online].
31. «https://code.google.com/p/lz4,» [Online].
26
Progetto 3D CloudWiz | ATI NICE - DIEE
32. M. Hasan e K. M. Nur, «A Lossless Image Compression Technique using Location Based
Approach».
33. M. El-Sakka, «Context-based Dictionary Image Compression».
34. AA.VV., «Highly efficient universal coding with classifying to subdictionaries for text
compression».
35. J. Cleary e W. Teahan, «Unbounded length contexts for PPM».
36. J. Larrauri, «A new Algorithm for Lossless Compression applied to two-dimensional Static
Images».
37. J. Larrauri e E. Kahoraho, «A new Method for Real Time Lossless Image Compression
Applied to Artificial Vision».
38. K. Jia, S. Fang e S. Dun, «Fast Lossless Color Image Compressing Method Using Neural
Network».
39. J. Zurada, «Introduction to Artificial Neural System».
40. «http://www.google.it/patents/US3971065,» [Online].
41. K. Chung e Y. Chan, «A Lossless Compression Scheme for Bayer Color Filter Array Images».
42. C. Koh, J. Mukherjee e S. Mitra, «New Efficient Methods of Image Compression in Digital
Cameras with Color Filter Array».
43. H. Malvar e G. Sullivan, «Progressive-to-Lossless Compression of Color-Filter-Array Images
using Macropixel Spectral-Spatial Transformation».
44. C. Flint, «Determining optimal medical image compression: psycometric and image
distortion analysis».
45. J. Janet, D. Mohandass e S. Meenalosini, «Lossless Compression Techniques for Medical
Images in Telemedicine».
46. AA.VV., «Astronomical Image Compression Based on Noise Suppression».
47. T. Lin e P. Hao, «Compound Image Compression for Real-Time Computer Screen Image
Transmission».
27
Progetto 3D CloudWiz | ATI NICE - DIEE
48. AA.VV., «Block-based Fast Compression for Compound Images».
49. C. Taskin e S. Sarikoz, «An Overview of Image Compression Approaches».
50. H. Cai e J. Li, «Lossless Image Compression with Tree Coding of Magnitude Levels».
51. B. Aiazzi, S. Baronti e L. Alparone, «Near Lossless Image Compression By Relaxation Labeled
Prediction».
52. B. Aiazzi, S. Baronti e L. Alparone, «Lossless Image Compression Based on a Fuzzy-Clustered
Prediction».
53. S. Qian, A. Hollinger e Y. Hamiaux, «Study of Real Time Lossless Data Compression for
Hyperspectral Imagery».
54. M. Ciavarella e A. Moffat, «Lossless Image Compression Using Pixel Reordering».
55. AA.VV., «Lossless Image Compression».
56. M. Bhammar e K. Mehta, «Survey of Various Image Compression Techniques».
57. M. Groach e A. Garg, «DCSPIHT: Image Compression Algorithm».
58. M. Ashok e T. Reddy, «Color image compression based on Luminance and Chrominance
using Binary Wavelet Transform and Binary Plane Technique».
59. N. Salam e R. Nair, «An Optimized Real Time Image Codec for Image Data Transmission and
Storage».
60. A. Kaushik e M. Gupta, «Analysis of Image Compression Algorithms».
61. M. Allam e E. Abdel-Ghaffar, «JPEG2000 Performance Evaluation».
28
Progetto 3D CloudWiz | ATI NICE - DIEE
Compressione di immagini generiche a contenuto eterogeneo (compound images)
Gli algoritmi di compressione illustrati finora applicano lo stesso algoritmo di compressione su
tutto il dato. Questi però, non sono ottimali però nell'applicazione verso le compound image.
Queste ultime sono immagini a contenuto eterogeneo ovvero possono essere composte da diverse
aree contenenti testo, immagini grafiche o fotografie naturali. Due tipici esempi di compound
image sono l'immagine visualizzata nello schermo di un computer ed il sito web di un giornale,
nella figura seguente viene mostrato un semplice esempio.
La compressione di una compound image si basa sul fatto che vengano individuate le varie
29
Progetto 3D CloudWiz | ATI NICE - DIEE
componenti/classi che compongono l'immagine, le quali verranno codificate separatamente
tramite un apposito algoritmo di compressione, differente per ciascuna componente/classe.
Nella prossima sezione verranno presentati i principali approcci proposti in letteratura per
compiere la segmentazione delle compound image.
Metodi di segmentazione delle componenti di un'immagine
Come accennato poco sopra, il primo step da effettuare nella compressione delle compound
image è la classificazione dell'immagine, ovvero l'individuazione di tutte le componenti che
costituiscono la compound image. In relazione a tale classificazione esistono numerosi approcci di
cui i più utilizzati sono i seguenti:
Approccio a oggetti
Approccio a layer
Approccio a blocchi
Approccio ibrido
Approccio ad oggetti
L’approccio a oggetti si propone di suddividere l’immagine in regioni, a loro volta divisibili in oggetti
caratterizzati da bordi perfettamente definiti. Gli oggetti possono essere lettere, fotografie o
elementi grafici. Questo approccio dovrebbe offrire un ottimo rapporto di compressione, in quanto
una volta selezionato correttamente l’oggetto, esso può essere compresso con l’esatto algoritmo
adatto al caso, senza considerare casi in cui la segmentazione non avvenga correttamente. In
pratica la codifica dei bordi delle oggetti risulta essere piuttosto complessa, rendendo poco
vantaggioso questo metodo in quanto fortemente dipendente dallo stato dell'arte attuale delle
tecniche di segmentazione automatica.
Approccio a layer
In questo approccio l'immagine composita viene suddivisa in piani contenenti delle porzioni
dell'immagine di partenza. La ricostruzione avviene attraverso degli layer specifici detti maschere.
Dal punto di vista teorico l'immagine composita può essere suddivisa in un numero di layer che
può dipendere dalla specifica applicazione. Uno dei metodi più diffusi è quello del Mixed raster
30
Progetto 3D CloudWiz | ATI NICE - DIEE
content (MRC) [1] nel quale l'immagine di partenza viene suddivisa nei seguenti layer:
1) Foreground
2) Mask
3) Background
Un semplice esempio può chiarire come viene suddivisa l'immagine composita e come viene
ricostruita nella figura successiva, dove abbiamo un'immagine contenente una porzione di testo di
colore rosa e un'immagine pittorica nella fattispecie un fiore bianco.
Queste tipologie di contenuto sono inserite in uno sfondo azzurro, secondo l'approccio MRC
l'immagine viene suddivisa in tre piani: il primo strato di foreground è costituito da un piano di
colore rosa che quindi conserva l'informazione relativa al colore delle parti di testo.
Esempio di approccio MRC
La maschera è costituita invece da un piano di sfondo bianco con un testo di colore nero che quindi
conserva l'informazione relativa al testo contenuto nell'immagine di partenza. Infine lo strato dello
sfondo è costituito da un piano di colore azzurro nel quale è inserita la componente pittorica, di
conseguenza tale strato conserva l'informazione relativa alla parte pittorica e allo sfondo.
I tre layer ottenuti possono essere quindi compressi separatamente e la ricostruzione può essere
effettuata attraverso la seguente relazione:
I(i, j) = Msk(i, j)FG(i, j) + (1 − Msk(i, j))BG(i, j)
Dove Msk è la maschera contenente il testo mentre FG e BG sono rispettivamente il background e
il foreground.
31
Progetto 3D CloudWiz | ATI NICE - DIEE
La particolare scelta di assimilare l'informazione del colore dello sfondo con la componente
derivante dalle immagini pittoriche deriva dal fatto che la compressione di tali tipologie di
contenuto può avvenire impiegando un singolo compressore.
E' importante soffermarsi su questo aspetto in quanto l'adattamento tra la tipologia di contenuto
del singolo strato ed il metodo di compressione da utilizzare per codificarlo risulta fondamentale in
questo metodo.. In particolare lo scarso adattamento tra metodo di compressione e tipo di dato
gestito può comprometterne l'efficacia, infatti a seconda della stratificazione adottata può capitare
che oggetti di tipo diverso possano risiedere nel medesimo strato che viene compresso attraverso
un singolo metodo di compressione che di fatto risulterà efficace sulla gestione di un solo tipo di
contenuto.
Risulta quindi importante scomporre l'immagine in tipologie di contenuto aventi caratteristiche tali
da sfruttare al meglio le peculiarità dei diversi algoritmi di compressione a disposizione, senza
dimenticare che abbiamo un grado di libertà derivante dalla possibilità di adottare una
stratificazione più o meno profonda. Tale stratificazione ci consente di gestire il giusto contenuto
col giusto metodo di compressione ma va comunque considerato che una suddivisione
dell'immagine di partenza in un numero eccessivo di layer incrementa la complessità e acuisce un
altro aspetto derivante dal fatto che aumentare a dismisura il numero di layer aumenta anche la
ridondanza derivante dalla presenza simultanea di componenti dell'immagine originale in layer
diversi .
Approccio a blocchi
Nella classificazione a blocchi l'immagine di partenza viene analizzata in blocchi di dimensioni
prefissata. Ciascun blocco componente conterrà al suo interno dei punti appartenenti a: testo,
immagini e componenti grafiche.
Quindi ciascun blocco subisce un processo di classificazione nel quale ciascun pixel viene assegnato
ad una tipologia specifica di contenuto. Tale metodo di classificazione ha quindi l'obbiettivo di
identificare le diverse regioni che costituiscono l'immagine composita.
In figura viene mostrato un semplice esempio nel quale si vede chiaramente come l'obbiettivo
della segmentazione sia quello di identificare e separare le regioni dell'immagine di partenza in
32
Progetto 3D CloudWiz | ATI NICE - DIEE
base al contenuto.
Esempio di approccio a blocchi
La conseguenza diretta di tale classificazione è la possibilità di comprimere ciascun tipo di
contenuto con un metodo di compressione specifico consentendo una buona conservazione del
contenuto informativo di partenza. In modo più specifico la classificazione a blocchi ha il vantaggio
di presentare dei metodi di segmentazione tipicamente poco complessi e un buon adattamento tra
metodo di compressione e contenuto gestito.
Lo svantaggio fondamentale risiede nella decomposizione dell'immagine di partenza in blocchi che
non presentano una forma rettangolare e che di conseguenza non consento l'utilizzo di metodi
compressione standard, che tipicamente sono studiati per gestire immagini rettangolari, a meno di
apportare delle modifiche per questo metodo specifico.
Il metodo di classificazione a blocchi rappresenta una buona scelta quando si vogliano costruire dei
compressori, per immagini composite, a bassa complessità.
Approccio ibrido
I metodi di classificazione basati sull'uso congiunto del metodo a blocchi e di quello a layer
risultano relativamente recenti.
Un esempio di approccio ibrido è quello proposto in [2]. Il metodo consiste in un primo passo di
classificazione dell'immagine secondo l'approccio a blocchi, in particolare i blocchi vengono
classificati in:
Sfondo
33
Progetto 3D CloudWiz | ATI NICE - DIEE
Testo
Grafica
Immagini pittoriche
Contenuto misto (overlap)
I blocchi con contenuto misto subiscono un processamento secondo il modello a layer. La sfida
maggiore è ovviamente quella derivante dal blocco di sovrapposizione per il fatto che contiene
contenuti differenti e, quindi, risulta più complessa la gestione in fase di compressione. In
definitiva, tale metodo accomuna le caratteristiche salienti dei metodi di classificazione che lo
compongono e di fatto può rappresentare un miglioramento rispetto a singoli approcci.
Algoritmi proposti in letteratura
In questa sezione verranno mostrate delle applicazioni in relazione ai metodi di segmentazione
analizzati nella precedente sezione, in particolare si cercherà di dare una valutazione di ciascun
metodo in modo da collocarlo in uno specifico ambito applicativo.
Metodi a blocchi
Per prima cosa analizzeremo i metodi proposti in [3], [4] e [5] nei quali viene applicata la
classificazione a blocchi. L’approccio consiste nella suddivisione dell’immagine in un elevato
numero di blocchi rettangolari, i quali verranno quindi singolarmente valutati e classificati come
blocchi di testo, blocchi grafici o blocchi contenenti un’immagine naturale. Il processo di
classificazione dei blocchi viene generalmente svolto utilizzando tre metodi:
Conteggio dei colori
DCT (Discrete cosine transform)
Istogramma
Shape primitive extraction and coding
L'approccio proposto nel 2005 da Tony Lin et al. [3] sfrutta l'analisi a blocchi ed un nuovo
algoritmo chiamato SPEC (Shape primitive extraction and coding). In particolar modo il sistema
ottiene una segmentazione iniziale effettuando il conteggio dei colori in blocchi di 16x16 pixel, e
classificando preliminarmente i blocchi come blocchi di testo o grafici nel caso in cui il numero dei
34
Progetto 3D CloudWiz | ATI NICE - DIEE
colori sia minore di una soglia T1 (gli autori utilizzano 32 come soglia), in caso contrario, il blocco
verrà classificato come blocco fotografico. Viene quindi generato un indice di un byte che viene
associato ai blocchi di testo o grafici. Questa classificazione preliminare risulta essere
estremamente rapida, nonostante alcuni blocchi pittorici siano talvolta catalogati come blocchi
grafici e viceversa. Per questo motivo viene effettuata una seconda segmentazione di rifinitura, in
cui verranno separati i blocchi testuali o grafici erroneamente classificati come blocchi pittorici.
Non viene effettuata la rifinitura per blocchi pittorici classificati come testi, poiché essi non sono
normalmente numerosi, e si tratterebbe solo di una perdita di prezioso tempo computazionale. I
blocchi di tipo testuale/grafico vengono quindi analizzati tramite lo SPEC, algoritmo che consente
di rilevare forme caratterizzate dallo stesso colore. Queste forme verranno analizzate in termini di
grandezza e colore per rilevare possibili elementi testuali o grafici e spostarli quindi fra i blocchi
appositi.
Il seguente schema a blocchi riassume il funzionamento dell’algoritmo SPEC.
35
Progetto 3D CloudWiz | ATI NICE - DIEE
I risultati ottenuti da questo algoritmo sono interessanti, sia in termini di tempo impiegato a
comprimere e decomprimere le immagini, sia in termini di grandezza del file compresso e di
qualità secondo quanto riportato nell’articolo. Due tabelle sono riportate per illustrare i risultati
ottenuti su dieci “Compound Image”.
Per dimostrare la qualità visiva ottenuta dall’algoritmo SPEC viene inoltre riportato nella prossima
figura un paragone fra un’immagine compressa tramite lo SPEC e diversi altri algoritmi.
36
Progetto 3D CloudWiz | ATI NICE - DIEE
Porzione dell'immagine originale (a), compressa tramite JPEG (b), JPEG-2000 (c), DjVu (d), SPEC (e). [3]
Improved block based segmentation and compression techniques for Compound Images
L'approccio presentato in [4] esegue un'analisi a blocchi basata sulla DCT. In particolare una volta
divisa l’immagine in blocchi, viene effettuata la trasformata su ogni blocco singolarmente, e viene
calcolata una variabile chiamata energia dei coefficienti AC (alternate current) nel seguente modo:
37
Progetto 3D CloudWiz | ATI NICE - DIEE
Dove Ys,i è il coefficiente AC del blocco i-esimo. Una volta calcolato tale valore, se esso dovesse
essere minore di una certa soglia, il blocco viene classificato come blocco “regolare”, ovvero un
blocco in cui è presente lo sfondo dell’immagine. Viceversa, il blocco sarà considerato “non
regolare”, e tramite un seguente procedimento di clustering può essere classificato come blocco di
testo/grafico o blocco immagine.
Block-based fast compression for Compound Images
Un metodo, basato su istogramma, è stato proposto da WenpengDing et al. [5] e viene definito BFC
(Block-based fast compression). Anche in questo metodo l’immagine viene suddivisa in blocchi da
16x16 pixel, i quali vengono poi processati per fornire un istogramma raffigurante il gradiente dei
pixel del blocco. In particolar modo, i gradienti vengono suddivisi in base al loro modulo fra “low-
gradient”, “mid-gradient” e “high-gradient”.
Un esempio è illustrato nella seguente figura:
Esempio di istogramma di blocco di testo[sinistra], blocco immagine [centro] e blocco ibrido [destra].
Una volta calcolati gli istogrammi, i blocchi potranno essere suddivisi in quattro categorie: blocchi
“regolari”, blocchi di testo, blocchi immagine e blocchi ibridi. Nel caso dei blocchi “regolari”,
l’istogramma sarà caratterizzato principalmente da “low-gradient”. I blocchi di testo avranno dei
picchi nel “low-gradient” e nel “high-gradient”, quelli immagine avranno alti valori di “medium-
gradient” e “low-gradient”, mentre i blocchi ibridi avranno entrambe le caratteristiche dei blocchi
di testo e dei blocchi immagine. Una volta classificati i blocchi, essi vengono compressi tramite un
algoritmo specifico asseconda del tipo di blocco. Per quanto riguarda i blocchi “regolari”, essi sono
caratterizzati normalmente da un colore che compare con maggior frequenza, il quale viene
38
Progetto 3D CloudWiz | ATI NICE - DIEE
codificato aritmeticamente, e che riempirà il blocco. Nei blocchi di testo vengono invece rilevati i
quattro colori più frequenti, ed allo stesso modo vengono codificati aritmeticamente, riportando
gli altri pixel con simile colore ad essi. I blocchi immagine vengono compressi tramite JPEG, mentre
quelli ibridi richiedono un algoritmo specifico basato sulla wavelet di Haar, i cui coefficienti
vengono poi compressi algoritmicamente. I rapporti di compressione ottenuti da questo metodo
sono molto elevati, e decisamente migliori di altri algoritmi tradizionali, non adatti alle “Compound
image”. Nella seguente tabella sono riportati i risultati ottenuti dagli autori in termini di fattore di
compressione.
Paragone fra il metodo proposto ed altri metodi di compressione tradizionali. [5]
Metodi a layer
Il metodo proposto in [6], A Layer-based Segmentation Method for Compound Images , si basa
sull'applicazione di filtri per immagini e di operatori morfologici con lo scopo di estrarre il testo
contenuto in immagini composite, in particolare il metodo è concepito per estrarre il testo da
scansioni o riviste.
A tale scopo viene impiegato il metodo MRC (MixedContentRaster), descritto nei paragrafi
introduttivi di questa relazione, che estrae il testo contenuto nell'immagine di partenza
separandola in tre layer: background, foreground e text mask.
I passaggi essenziali effettuati dal metodo per estrarre i tre layer sono i seguenti:
1. L'immagine di partenza viene convertita in scala di grigi.
2. Viene applicato un filtro di Wiener per eliminare rumore di fondo (caso tipico delle
scansioni).
3. Applicazione all'immagine di partenza del binarizzatore di Sauvola che mette in risalto il
39
Progetto 3D CloudWiz | ATI NICE - DIEE
testo.
4. Applicazione all'immagine di partenza dell'operatore di Prewitt che cattura i bordi delle
lettere per ottenere le regioni in cui si trova il testo.
5. Viene applicata un'operazione di dilatazione per aumentare le dimensioni delle aree nel
quale è situato il testo.
6. Vengono applicate delle regole tese ad eliminare aree erroneamente classificate come
testo.
7. Si svolge un'operazione di AND tra l'immagine al punto 3 e quella al punto 6 per estrarre
la maschera di testo.
8. L'immagine ottenuta al punto 7 subisce una closing.
9. L'immagine al punto 8 subisce un ulteriore processo di filtraggio analogo a quello eseguito
al punto 6.
10. L'immagine al punto 9 viene posta in AND con quella del punto 3 per riestrarre il testo.
11. Viene infine applicato un algoritmo di riempimento.
In viene mostrato lo schema di principio dell'algoritmo.
Le capacità di classificazione dell’algoritmo sono state valutate in [6] in termini di recall e precision:
Il primo indice (recall rate) rappresenta il tasso di testo rilevato correttamente fra quello presente
40
Progetto 3D CloudWiz | ATI NICE - DIEE
nelle immagine. Il secondo indice (precision rate) invece rappresenta il tasso di testo rilevato
correttamente fra tutto il testo identificato dall’algoritmo . In tabella viene mostrato un estratto
delle prestazioni dell'algoritmo proposto comparato col metodo DjVu in relazione agli indici
qualitativi.
L'algoritmo mostra delle prestazioni paragonabili al metodo allo stato dell'arte DjVu. Il metodo
proposto può essere collocato probabilmente in ambiti applicativi dove non risulta stringente la
specifica sulla velocità di calcolo e dove possa comunque essere gestita una complessità
computazionale elevata derivante dai numerosi passi che l'algoritmo compie per effettuare la
classificazione.
Metodi ibridi
Come esempio di metodo imbrido viene di seguito riportato l'approccio proposto in [2]: Enhanced
Hybrid Compound Image Compression Algorithm Combining Block and Layerbased segmentation.
Il metodo può essere descritto in due passi fondamentali. Nel primo passo i blocchi di immagini
vengono classificati in cinque classi fondamentali secondo l'approccio a blocchi.
Le cinque classi sono le seguenti:
Sfondo
Testo
Grafica
Immagini pittoriche
Contenuto misto (overlap)
Lo schema di segmentazione può essere rappresentato attraverso il seguente schema a blocchi.
41
Progetto 3D CloudWiz | ATI NICE - DIEE
Il blocco di overlap che presenta caratteristiche ibride, ossia contiene testo e immagini che la
segmentazione non ha separato, viene a sua volta processato attraverso il metodo di
classificazione a layer impiegando lo schema classico a tre livelli proposto in [1].
Lo schema di segmentazione applicato per i blocchi di overlap può essere rappresentato dal
seguente schema.
Il metodo ibrido è stato valutato in base alle seguenti metriche di prestazione:
Rapporto di compressione
Tempo di compressione /decompressione
Rapporto segnale rumore di picco
Di seguito mostriamo un estratto dei risultati ottenuti dall'algoritmo proposto.
Nella prima tabella viene mostrata la prestazione in termini di rapporto di compressione.
42
Progetto 3D CloudWiz | ATI NICE - DIEE
Si nota come il metodo proposto (Model 2) abbia prestazioni paragonabili se non superiori agli altri
metodi.
Nella seguente tabella viene mostrata la prestazione del metodo in relazione al rapporto segnale
rumore di picco. I valori ottenuti sono decisamente in linea con quelli degli altri algoritmi.
Nella seguente tabella viene mostrata la valutazione dell'algoritmo in termini di tempi di
compressione e decompressione. E' evidente che il metodo di compressione proposto presenta dei
tempi di compressione/decompressione paragonabili agli altri metodi presi in considerazione.
Tali valori vanno analizzati in relazione alla qualità visiva e in particolare possiamo notare che a
parità di tempi di calcolo il metodo proposto produce dei buoni risultati soprattutto in termini di
rapporto segnale rumore di picco.
43
Progetto 3D CloudWiz | ATI NICE - DIEE
In definitiva possiamo dire che il metodo presenta delle prestazioni significative che gli consentono
di essere impiegata efficacemente nell'ambito della compressione delle immagini composite.
Conclusioni
In questa sezione sono stati analizzati i principali metodi presenti in letteratura inerenti la
compressione delle compound image.
Risulta impossibile effettuare una comparativa accurata di tutti i metodi dato che ogni
implementazione è stata testata dai rispettivi autori su piattaforme di calcolo diverse e su dataset
non omogenei, nonostante ciò si possono fare alcune considerazioni.
I metodi basati sulla classificazione a blocchi presentano probabilmente le prestazioni migliori in
termini di velocità di calcolo e di flessibilità in relazione all'utilizzo di svariati schemi di codifica.
I metodi basati sulla classificazione a layer presentano buone prestazioni dal punto
di vista della qualità complessiva dell'immagine compressa ma soffrono di un'elevata complessità e
dello scarso adattamento tra metodo di compressione e tipo di contenuto gestito.
I metodi ibridi rappresentano un valido compromesso dei due approcci appena descritti.
Bibliografia
1. de Queiroz, R., Buckley, R., Xu, M., “Mixed Raster Content (MRC) model for compound
image compression”, Corporate Research& Technology, Xerox Corp., 1999.
2. Maheswari, D., Radha, V., “Enhanced Hybrid Compound Image Compression algorithm
44
Progetto 3D CloudWiz | ATI NICE - DIEE
combining block and layer-basedsegmentation”, Springer, 2011.
3. Lin, T., Hao, P., “Compound Image compression for real-time computer screen image
transmission”, IEEE Transactions on Image Processing, Vol. 14, No. 8, 2005.
4. Maheswari, D., Radha, V., “Improved block based segmentation and compression
techniques for Compound Images”, International Journal of Computer Science &Engineering
Technology, 2010.
5. Ding, W., Liu, D., He, Y., Wu, F.,“Block-based fast compression for Compound Images”, IEEE
International Conference on Multimedia and Expo, 2006.
6. Mtimet, J., Amiri, H., “A layer-based segmentation method for compound images”, IEEE
10th International Multi-Conference on Systems, Signals&Devices (SSD), 2013.
7. Yang, H., Fang, Y., Yuan, Y., Lin W., “Subjective quality evaluation of compressed digital
compound images”,Elsevier, 2014.
8. Wang, Z., Bovik, A., C., Sheikh, H., R., Simoncelli, E., P., “Image quality assessment: from
error visibility to structural similarity”, IEEE Transactions on Image Processing, Vol. 13, No.
4, 2004.
9. Said, A. (2004) Compression of compound images and video for enabling rich media in
embedded systems, PIE/IS&T Visual Communications and Image Processing Conference,
SPIE Proc. Vol. 5308, Pp. 69-82. (2004).
10. Wong, T.S., Bouman, C.A. and Pollak, I. Improved JPEG decompression of document images
based on image segmentation, Proceedings of the 2007 IEEE/SP 14th Workshop on
Statistical Signal Processing, IEEE Computer Society, Pp. 488-492. (2007)
11. Li, X. and Lei, S Block-based segmentation and adaptive coding for visually lossless
compression of scanned documents, Proc. ICIP, VOL. III, PP. 450-453 (2001).
12. Amir Said and Alex Drukarev, Simplified Segmentation for Compound Image Compression,
1999
13. Ricardo L. de Queiroz, Zhigang Fan, and Trac D. Tran, Optimizing Block-Thresholding
Segmentation for Multilayer Compression of Compound Images,IEEE TRANSACTIONS ON
45
Progetto 3D CloudWiz | ATI NICE - DIEE
IMAGE PROCESSING, VOL. 9, NO. 9, SEPTEMBER 2000
14. Wenpeng Ding,Yan Lu Feng Wu, ENABLE EFFICIENT COMPOUND IMAGE COMPRESSION IN
H.264/AVC INTRA CODING, IEEE 2007
15. Alexandre Zaghetto and Ricardo L. de Queiroz, Segmentation-Driven Compound Document
Coding Based on H.264/AVC-INTRA, IEEE TRANSACTIONS ON IMAGE PROCESSING, VOL. 16,
NO. 7, JULY 2007
16. Amir Said, Compression of Compound Images and Video for Enabling Rich Media in
Embedded Systems, Hewlett-Packard Laboratories, 2004
17. B.-F. Wu, C.-C. Chiu and Y.-L. Chen, Algorithms for compressing compound document
images with large text/background overlap, IEE Proc.-Vis. Image Signal Process., Vol. 151,
No. 6, 2004
18. Masashi Nakao, Masaki Kita, Haifeng Chen, Masayuki Miyama, An 8 ms Delay Real-time
Image Transmission System for Remote Desktop, SID 2008
19. D.Maheswari , V.Radha, Comparison of Layer and Block Based Classification in Compound
Image Compression, (IJCSIT) International Journal of Computer Science and Information
Technologies, Vol. 2 (2) , 2011, 888-890
20. V.Radha, D.Maheswari, Secured Compound Image Compression Using Encryption
Techniques, Proceedings of the World Congress on Engineering and Computer Science 2011
Vol I, WCECS 2011, October 19-21, 2011
46
Progetto 3D CloudWiz | ATI NICE - DIEE
Metriche per il confronto fra algoritmi di compressione di immaginiPer valutare in maniera adeguata gli algoritmi di compressione che saranno analizzati si farà
riferimento ad alcuni parametri specifici.
In letteratura sono presenti alcuni parametri universalmente riconosciuti ed accettati che sono:
• rapporto di compressione (Compression Ratio);
• tempo di compressione e decompressione (Compression and Decompression Time);
• errore quadratico medio (Mean Squared Error – MSE);
• picco del rapporto tra segnale e rumore (Peak Signal to Noise Ratio – PSNR);
• indice di similarità strutturale (Structural Similarity Index – SSIM).
Non tutti questi parametri sono universalmente applicabili: in particolare MSE, PSNR e SSIM
misurando l’alterazione apportata all’immagine originale dall’algoritmo di compressione sono
ovviamente utilizzati unicamente per le codifiche di tipo lossy o near lossless, mentre non hanno
applicabilità per le codifiche di tipo puramente lossless.
Compression ratio
Il rapporto di compressione misura la quantità (dimensione) dei dati compressi rispetto alla
quantità (dimensione) dei dati originali. Viene quindi definito come:
Compression Ratio = Lunghezza dei dati originali / Lunghezza dei dati compressi
come ovvio dalla formula precedente si può notare che il rapporto di compressione aumenta alla
riduzione dei dati compressi.
Tempo di compressione e decompressione
I tempi di compressione e decompressione dell'informazione (solitamente misurati in secondi)
sono l'unità di misura e confronto base al fine di valutare un sistema di compressione
dell'immagine. Questi parametri mettono in evidenza il tempo richiesto dall'algoritmo / algoritmi
implementati in un sistema per effettuare le operazioni di codifica e decodifica delle immagini in
ingresso.
47
Progetto 3D CloudWiz | ATI NICE - DIEE
Mean Squared Error – MSE
L'MSE viene definito in statistica come la misura che indica la discrepanza quadratica media fra i
valori dei dati osservati ed i valori dei dati stimati. Questo concetto viene declinato all'analisi delle
immagini come la misura della differenza quadratica media, pixel per pixel, di due immagini di
medesime dimensioni. Siano I e K due immagini di pari dimensioni, M x N, l'MSE tra le due
immagini può essere definito come:
Peak Signal to Noise Ratio – PSNR
Il PSNR viene utilizzato per valutare la qualità dell'immagine compressa rispetto all'originale, per
questo viene solitamente preso in considerazione prevalentemente per la misurazione delle
prestazioni di algoritmi di compressione di tipo lossy (es. JPG).
Esso, espresso in scala logaritmica di decibel, viene definito come il rapporto tra la massima
potenza di un segnale e la potenza di rumore che può invalidare la fedeltà della sua
rappresentazione compressa: è quindi la misura della distorsione introdotta comprimendo
l'immagine originale.
All'aumentare del valore di PSNR si aumenta il grado di somiglianza percepito, dal livello visivo
umano, rispetto all'immagine originale.
Tenendo in considerazione la formulazione dell'MSE precedentemente descritta, possiamo definire
il PSNR di un'immagine come segue:
Dove abbiamo indicato con R il massimo valore rappresentabile del pixel dell'immagine. Per
un'immagine binaria il numeratore varrà sempre 1, per un'immagine in scala di grigi il numeratore
assumerà invece il valore 255. Per immagini a colori tale definizione vale per un'unica componente.
48
Progetto 3D CloudWiz | ATI NICE - DIEE
Si può quindi estendere la formulazione del PSNR ad immagini a colori come segue:
Structural Similarity Index – SSIM
Lo Structural Similarity Index (SSIM) è un indice utilizzato per misurare la somiglianza tra
l'immagine originale e quella compressa. Viene spesso utilizzato al posto del PSNR o del MSE in
quanto questi ultimi due non tengono strettamente conto della percezione dell'occhio umano.
La differenza sta nel fatto che mentre PSNR e MSE stimano errori di tipo “fisico”, la brutale
differenza tra i pixel delle due immagini, il SSIM valuta la degradazione dell'immagine dal punto di
vista delle informazioni strutturali nel senso delle interdipendenze presenti tra pixel spazialmente
vicini.
SSIM viene calcolato per aree quadrate di un'immagine ed è possibile definirla, date due aree X e Y,
come:
dove abbiamo che σ2 è la varianza delle aree, μ è la media dei valori, σxy è la covarianza tra i valori
delle due aree ed infine C1 e C2 sono due variabili utilizzate per evitare forme indeterminate della
funzione quando gli altri valori (μ2 e σ2) sono prossimi allo 0. In particolare essi sono definiti come:
C1=(K1L)2 C2=(K2L)2
dove abbiamo che K1 e K2 sono due variabili avente valore molto minore di 1, tipicamente si ha il
caso di K1 = 0.01 e K2 = 0.03, mentre L è il valore massimo che possono assumere i pixel (es. 255
per un'immagine in scala di grigi a 8 bit) ed è definibile quindi come:
L = 2Numero di bit per pixel – 1
49
Progetto 3D CloudWiz | ATI NICE - DIEE
Bibliografia
1. A. Mood, F. Graybill e D. Boes, Introduction to the Theory of Statistics.
2. Q. Huynh-Thu e M. Ghanbari, «Scope of validity of PSNR in image/video quality
assessment».
3. AA.VV., «Image Quality Assessment: From Error Visibility to Structural Similarity».
50
Pattern Recognition and Applications LabDIEE - Università di Cagliari
R2.2RELAZIONE TEST COMPARATIVO SULLE PERFORMANCE REALI
DEGLI ALGORITMI DI COMPRESSIONE IN CONTESTI OPERATIVI
GENERICI E PER CATEGORIE SPECIFICHE DI CONTENUTO
Progetto 3D CloudWiz
Progetto 3D CloudWiz | ATI NICE - DIEE
SommarioSommario..............................................................................................................................................i
Obiettivo del documento......................................................................................................................1
Descrizione dell'organizzazione dei test...............................................................................................1
Test sui codec lossless..........................................................................................................................3
Codec lossless utilizzati....................................................................................................................3
Risultati degli esperimenti................................................................................................................4
Conclusioni.......................................................................................................................................9
Test sui codec lossy............................................................................................................................10
Codec lossy utilizzati......................................................................................................................10
Risultati degli esperimenti..............................................................................................................10
Analisi preliminare video con testo............................................................................................11
Analisi comparativa....................................................................................................................13
Analisi preliminare video con immagini naturali.......................................................................21
Analisi comparativa....................................................................................................................23
Analisi preliminare video composito..........................................................................................31
Analisi comparativa....................................................................................................................33
Conclusioni.....................................................................................................................................40
Test sui codec compound....................................................................................................................41
Codec compound............................................................................................................................41
Setup degli esperimenti..................................................................................................................41
Risultati degli esperimenti..............................................................................................................42
Conclusioni.........................................................................................................................................44
i
Progetto 3D CloudWiz | ATI NICE - DIEE
Obiettivo del documentoIn questo documento si illustrano i test comparativi degli algoritmi di compressione. Si partirà dairisultati del R2.1 selezionando alcune codifiche risultate maggiormente interessanti per il casooggetto del progetto e verranno anche aggiunti anche una serie di codec lossy in quanto le realicondizioni operative, soprattutto in termini di banda, richiedono una riduzione maggiore dei byteinviabili attraverso la rete per frame inviato.
In particolare come “classificatori” verranno testate le metodologie delle compound imagedescritte in R.2.1. Sono stati effettuati ulteriori test utilizzando classificatori specifici per la textdetection oppure per l'individuazione di specifiche caratteristiche dell'imamgine con tecnichemutuate dalla scene analysis per guidare la scelta del codec a seconda del contenuto delframe/immagine. Si è scelto di non utilizzare poi questi approcci nei test estensivi riportati inquesto documento in quanto le tempistiche di questi algoritmi non consentirebbero larealizzazione di un sistema il più vicino possibile al real-time dato che andrebbero ad introdurre unritardo significativo che andrebbe ad aggiungersi alle tempistiche che saranno riportate di seguito.
I test sono stati condotti esplorando la configurabilità degli algoritmi di compressione ed il lorocomportamento in termini delle misure di qualità individuate nel R2.1 al variare del contestooperativo testato.
1
Progetto 3D CloudWiz | ATI NICE - DIEE
Descrizione dell'organizzazione dei testSono stati effettuati test indipendenti sulle seguenti tipologie di codec:
Codec lossy
Codec lossless
Codec compound
Gli aspetti principali considerati per la valutazione dei codec e dei metodi compositi sono:
Qualità di codifica in termini di : MSSIM e PSNR
Tempo di codifica, decodifica e totale
Capacità di compressione
I codec lossless e lossy sono stati testati sulle seguenti tipologie di contenuti:
Video contenenti soltanto testo
Video contenenti soltanto immagini
Video compositi contenenti sia testo che immagini
La valutazione dei metodi compositi è stata condotta soltanto col video composito.
Le immagini impiegate per effettuare i test sono nel formato a tre canali BGR.
In alcuni casi particolari è stato necessario convertire tale formato per assecondare lecaratteristiche intrinseche di specifici codec.
Setup degli esperimentiTutti i metodi di codifica descritti nella precedente sezione sono stati testati su video con le
seguenti caratteristiche tecniche (report R.2.3 per ulteriori dettagli):
Video Testo Video Immagini Video Composito
Numero Frames 700 700 700
Grandezza Frame 1366 x 682 1366 x 682 1366 x 682
Tabella 1: Caratteristiche tecniche dei video
Come indicato nella sezione introduttiva i fattori considerati per la valutazione sono:
Tempo di codifica, decodifica e totale misurato come media sui fotogrammi checompongono ciascun video.
Capacità di compressione o numero medio di volte in cui viene compressa l'immagine.
Per quest'ultimo fattore si è tenuto conto della presenza di fotogrammi completamente neri
1
Progetto 3D CloudWiz | ATI NICE - DIEE
derivanti da transizioni nei video. Tale caratteristica può rendere i risultati non veritieri e pertantosi è tenuto conto di ciò eliminandoli dai risultati.
Tutti i test sono stati svolti in parallelo, avviando tre simulazioni per volta, su una macchina nondedicata, fornita di un processore Intel Core i7-3517U, su macchina virtuale Debian 7.
2
Progetto 3D CloudWiz | ATI NICE - DIEE
Test sui codec losslessIn questa sezione si descriveranno le prestazioni dei codec in grado di effettuare codifica senza
perdita. L'analisi sarà incentrata sulla valutazione dei tempi di codifica, decodifica e totali nonchèsulla capacità di compressione. Verrà invece omessa la valutazione rispetto alla qualità di codificadata la natura dei codec in esame.
Codec lossless utilizzatiI codec lossless testati sono i seguenti:
• Jpeg_LS: Lo schema di compressione dello standard JpegLS si basa su quello di JpegLossless. La compressione in tal caso viene effettuata essenzialmente tramite un primopasso di predizione basato sulla codifica DPCM e da un passo costituito da una codificaentropica. In particolare lo scopo di Jpeg_LS è quella di ridurre la complessità della codificaentropica attraverso l'impiego dell'algoritmo LOCO-I .
• Jpeg 2000: Jpeg2000 è un sistema di codifica lossless e lossy basato sulla tecnologiawavelet. Attualmente lo standard è composto da 14 punti. Il codec viene principalmenteimpiegato nella compressione di immagini e video nonchè per la compressione diinformazioni volumetriche come definito nel punto 10 dello standard.
• Jpeg XR: Il codec JpegXR (abbreviazione di Jpeg extendedrange) è un codec che permette dieffettuare la compressione di immagini con codifica lossless o lossy. Introdotto nel 2006dalla Microsoft, la codifica JpegXR si basa completamente sulla codifica Jpeg, ma con alcunimiglioramenti quali: compressione lossless, supporto alla codifica per tile, supporto delcanale trasparenza.
• LZO: Il codec LZO (Lempel – Ziv – Oberhumer), non si tratta di un codec per immagini, ma diun codec di compressione dati che permette di ottenere bassi livelli di compressione intempi estremamente ridotti. La compressione avviene a blocchi, i quali vengono compressigrazie ad un dizionario scorrevole, utilizzando un algoritmo simile a quello della “slidingwindow”. Verrà utilizzato per valutare la capacità di un algoritmo pensato solo per lacompressione dati in un contesto di compressione lossless di immagini.
• Zrle: Il codec Zrle è un codec lossless basato sul principio di RLE (run length encoding),ovvero la compressione di sequenze di dati simili fra loro e sull’algoritmo di compressione“deflate”. La fase di compressione RLE si basa sull’individuazione di sequenze di pixelidentici fra loro, che possono quindi essere compressi come il numero di pixel consecutivied il colore degli stessi. Per aumentare la compressione viene quindi applicato un algoritmocostituito dalla combinazione dell’algoritmo LZ77 e della codifica di Huffman.
• RLE_LZO: Il codec RLE_LZO integra i codec RLE e LZO con lo scopo di migliorare la capacitacomplessiva di compressione.
• WebP: Il codec è basato su un sistema predittivo con caratteristiche analoghe a quellautilizzata dal codec VP8 per codificare i fotogrammi chiave nei video. In fase dicompressione il codec condivide alcune caratteristiche dell'algoritmo di compressione
3
Progetto 3D CloudWiz | ATI NICE - DIEE
LZ77.
Si è deciso di non includere i risultati del codec VP9 per i seguenti motivi:
In seguito alla perdita di conversione introdotta dalla trasformazione dal formato BGR aquello YUV e viceversa, non è stato possibile riscontrare la caratteristica lossless tramite lamisura delle metriche di qualità.
Il codec non ha mostrato dei vantaggi rispetto ai concorrenti e pertanto non si sarebbeottenuta alcuna indicazione significativa dall'introduzione della sua valutazione.
Risultati degli esperimenti
I risultati sperimentali verranno mostrati in forma tabellare, indicando i parametri di valutazionedescritti nelle sezioni precedenti.
Nel ambito del progetto è stato scelto di impostare la qualità di codifica di ciascun codeccostruendo una mappatura (relativa) su una scala che varia da 0 a 100 come mostrato di seguito:
Mappatura 0 ... ... 100Qualità Minima ... ... Massima
Ad ogni modo a parità di valore di mappatura i codec non mostrano la medesima qualitàrispetto alle metriche MSSIM e PSNR, in quanto la variazione del parametro di qualità non èomogenea fra tutti i codec.
Per i codec in esame la mappatura di qualità assume il seguente significato:
• I codec: Jpeg_LS, Jpeg2000, JpegXR e WebP sono in grado in grado di effettuare sia codificalossy che lossless. In questa sezione tali codec sono stati settati con la mappatura 100 cheidentifica la codifica senza perdita.
• I codec: LZO, RLE_LZO e Zrle possono eseguire, ovviamente, soltanto codifiche lossless. Inquesto caso è possibile esprimere un grado di compressione da 0 a 100 che segue ha unsignificato diverso a seconda dell'algoritmo di compressione usato:
LZOMappatura 0 50 100
Compressione Minima Intermedia Massima
ZipMappatura 0 20 40 60 80 100
Compressione Massima ... ... ... ... Minima
Consideriamo in primo luogo i risultati relativi al test sul video contenente soltanto testo.
La quarta colonna della tabella 2 indica il livello di compressione valutato rimuovendo i dati sullivello di compressione introdotto dai fotogrammi di transizione contenuti nel video in modo taleda avere dei valori medi di compressione più realistici. In grigio vengono indicati i codec conperformance migliori, in verde le prestazioni migliori e in rosso le peggiori riscontrate.
4
Progetto 3D CloudWiz | ATI NICE - DIEE
TestoEncode
(ms)Decode
(ms)Total_tim
e (ms)
No TransitionsCompression
ratio
Compressratiomean
Codec_Jpeg_LS_100 156,897 144,4842 301,3812 2,386901 2,372665codec_Jpeg2000_100 2030,661 1478,033 3508,694 4,489849 4,466364codec_JpegXR_100 237,0315 209,7319 446,7634 3,907942 3,892301codec_LZO_000 5,83376 4,446056 10,27982 6,20584 6,202875codec_LZO_050 6,350296 4,399927 10,75022 6,336709 6,335569codec_LZO_100 480,7578 3,891319 484,6491 8,216147 8,223243codec_RLE_LZO_000 12,55072 5,148521 17,69924 6,594978 6,592389codec_RLE_LZO_050 13,41644 5,711399 19,12784 7,081695 7,06701codec_RLE_LZO_100 286,7269 5,786614 292,5136 9,742093 9,69826codec_Webp_100 3429,253 23,88109 3453,134 16,49622 16,48757codec_Zrle_000 181,8607 8,683911 190,5447 9,934391 9,88897codec_Zrle_020 83,73205 8,874047 92,60609 9,881994 9,835799codec_Zrle_040 54,82203 8,910395 63,73242 9,771124 9,722819codec_Zrle_060 46,90518 8,981062 55,88624 9,628881 9,582114codec_Zrle_080 36,04393 9,179927 45,22385 9,760488 9,730503codec_Zrle_100 33,34371 9,101639 42,44535 9,556155 9,531419
Tabella 2: Tabella riassuntiva codec lossles video testo
Il codec più performante dal punto di vista del tempo totale di codifica/decodifica èrappresentato da: codec_LZO_000
Come è naturale attendersi il codec LZO ottiene le sue migliori prestazioni dal punto di vista deltempo di codifica/decodifica imponendo il valore minimo di compressione essendo ottimizzato perla compressione dati e non facendo alcuna analisi sull'immagine stessa.
In generale richiedere un livello di compressione maggiore comporta un aumento del tempoimpiegato per effettuarla.
Per quanto riguarda il codec LZO non risulta vantaggioso imporre il massimo livello dicompressione dato che questo comporta un lieve miglioramento della compressione stessa afronte di un aumento di un ordine di grandezza del tempo speso per effettuarla. Considerando larisoluzione del video e supponendo di inviare 25 fotogrammi al secondo sarebbe necessaria unarisorsa di banda pari a circa:
BW= 90Mbit/sec
Il codec che ha mostrato le migliori prestazioni in termini di capacità di compressione é:
codec_Webp_100
col livello di compressione misurato si potrebbe inviare il video con una banda pari a:
BW=33.87 Mbit/sec
quindi circa 1/3 di quella richiesta dal codec LZO.
6
Progetto 3D CloudWiz | ATI NICE - DIEE
A fronte di tale capacità di compressione si riscontra un tempo totale di codifica/decodifica moltoelevato e secondo solo a quello del codec Jpeg2000. Considerando che il tempo di decodificamostrato da WebP è abbastanza contenuto esso si può collocare tra i codec adatti ad effettuarecodifiche "offline" e che di fatto spostano la complessità della catena dicompressione/decompressione verso il fornitore del servizio di streaming.
Per concludere si può dire che l'integrazione di algoritmi Run Lenght Encoding con altri algoritmidi compressione non apportano migliorie significative in termini di compressione e tempo spesoper effettuarla se non nel caso della combinazione codec_Zrle_100 per il quale si ha un livello dicompressione maggiore di LZO_000 con tempi totali di codifica/decodifica abbastanza contenuti.
Consideriamo i risultati relativi al test sul video contenente soltanto immagini naturali.
Nella seguente tabella sono riportati i dati principali.
VideoEncode
(ms)Decode
(ms)Total_time
(ms)
No transitionsCompression
ratio
Compressratiomean
codec_CharLS_100 115,654 100,6059 216,2599 2,302684 69,69423codec_Jpeg2000_100 1096,165 860,3662 1956,531 10,97189 368,1858codec_JpegXR_100 275,6238 213,5992 489,223 8,249279 142,7041codec_LZO_000 7,537492 5,670801 13,20829 3,697706 43,99502codec_LZO_050 8,025755 5,78367 13,80942 3,851162 44,1122codec_LZO_100 342,4183 7,751754 350,1701 6,671999 44,57947codec_RLE_LZO_000 13,12161 5,09813 18,21974 5,013473 968,51codec_RLE_LZO_050 13,90665 5,544662 19,45131 5,258637 966,848codec_RLE_LZO_100 236,1612 8,626229 244,7874 7,598651 1101,923codec_Webp_100 2433,795 49,33965 2483,135 15,59999 1412,437codec_Zrle_000 99,19528 14,32377 113,519 8,815354 1524,555codec_Zrle_020 88,24164 13,5882 101,8298 8,747914 1479,565codec_Zrle_040 79,67845 13,62247 93,30093 8,536808 1299,074codec_Zrle_060 71,85119 13,79136 85,64255 8,21431 1073,56codec_Zrle_080 57,80858 14,22535 72,03393 7,656403 774,5377codec_Zrle_100 57,42856 14,75461 72,18317 7,503815 738,5948
Tabella 3: Riassunto prestazioni test immagini naturali
Il codec più performante dal punto di vista del tempo totale di codifica/decodifica èrappresentato da:
codec_LZO_000
Come nel caso precedente il codec LZO ottiene le sue migliori prestazioni dal punto di vista deltempo di codifica/decodifica imponendo il valore minimo di compressione. Analogamente imporreil massimo livello di compressione comporta un tempo totale di codifica/decodifica piuttostoelevato e pari a circa: 350 msec.
Considerando la risoluzione del video e supponendo di inviare 25 fotogrammi al secondosarebbe necessaria mediamente una risorsa di banda pari a :
7
Progetto 3D CloudWiz | ATI NICE - DIEE
BW= 151 Mbit/sec
Quindi il codec LZO comprime meno se il contenuto del video è caratterizzato da transizionipoco nette tipiche dei video privi di testo.
Come per la compressione del video con solo testo il miglior codec in termini di capacità dicompressione è :
Webp_100
in tal caso si otterrebbe un'occupazione di banda pari a:
BW= 36 Mbit/sec
valore decisamente inferiore rispetto a quello mostrato da LZO seppur piuttosto elevato.
Analogamente al caso descritto precedentemente WebP impiega molto tempo per effettuare lacodifica rispetto alla decodifica, ma in tal caso mostra anche un tempo di decodifica nonpropriamente limitato. Anche in questo caso l'integrazione di differenti metodi di compressionenon ha portato vantaggi significativi. Per concludere è necessario evidenziare come la capacità dicompressione media valutata con e senza le transizioni sia decisamente diversa come indicatodalle ultime due colonne della Tabella 3.
Consideriamo infine i risultati relativi al test sul video composito, in Tabella 4 sono stateriportate le informazioni principali.
CompoundEncode
(ms)Decode
(ms)Total_tim
e (ms)No transitions
Compression ratio
Compressratiomean
codec_CharLS_100 151,2023 136,598 287,8003 1,918267 1,922266codec_Jpeg2000_100 1828,029 1353,497 3181,526 5,906544 5,860537codec_JpegXR_100 257,3069 212,7063 470,0131 5,20892 5,16017codec_LZO_000 5,966675 4,410306 10,37698 4,81994 4,848007codec_LZO_050 6,353451 4,575433 10,92888 4,94203 4,969573codec_LZO_100 370,0537 4,795172 374,8489 6,138201 6,180175codec_RLE_LZO_000 12,41577 4,654704 17,07048 4,985602 5,031443codec_RLE_LZO_050 13,44856 5,232057 18,68062 5,248601 5,296671codec_RLE_LZO_100 178,511 6,386386 184,8974 6,729704 6,79717codec_Webp_100 4543,755 44,97143 4588,726 13,1683 13,17223codec_Zrle_000 84,73863 10,39744 95,13608 7,227404 7,29423codec_Zrle_020 69,09967 10,33161 79,43128 7,219542 7,285679codec_Zrle_040 60,05692 10,36764 70,42457 7,186295 7,25013codec_Zrle_060 51,92939 10,22724 62,15664 7,119092 7,179905codec_Zrle_080 43,29128 10,69557 53,98685 7,030804 7,082596codec_Zrle_100 41,65115 10,70906 52,3602 6,95526 7,003254
Tabella 4: Dati riassuntivi video composito
Ancora una volta la combinazione LZO_000 rappresenta la migliore soluzione per quantoriguarda il tempo totale di codifica/decodifica. Il livello di compressione medio misurato si attesta
8
Progetto 3D CloudWiz | ATI NICE - DIEE
su un valore intermedio rispetto a quelli misurati nei casi precedenti. L'occupazione di bandarisulta piuttosto elevato in seguito alla bassa compressione introdotta:
BW= 116 Mbit/sec
Il codec WebP come nei casi precedenti mostra la migliore capacità di compressione checomporterebbe un'occupazione di banda pari a:
BW= 42.4 Mbit/sec
in tal caso si ottiene un valore più elevato rispetto al caso di video con solo testo o solo immagini.
Conclusioni
Come atteso, i codec lossless sono caratterizzati da livelli di compressione poco elevati. I codecche mostrano la migliore capacità di compressione spesso sono caratterizzati da tempi complessividi codifica/decodifica molto elevati. In relazione ai contenuti testati non è emersa la possibilità diselezionare configurazioni particolari dato che per i tre casi considerati i codec migliori sonorisultati sempre WebP e LZO.
9
Progetto 3D CloudWiz | ATI NICE - DIEE
Test sui codec lossyIn questa sezione si descriveranno le prestazioni dei codec che effettuano codifiche con perdita.
Alcuni di essi sono anche in grado di effettuare codifiche lossless. L'analisi sarà incentrata sullavalutazione dei tempi di codifica, decodifica e totali nonchè sulla capacità di compressione. Sivaluterà inoltre la qualità di codifica in relazione alle metriche PSNR e MSSIM.
Codec lossy utilizzatiI codec lossy testati sono i seguenti:
• Jpeg_LS, Jpeg 2000, Jpeg XR e WebP descritti nella sezione lossless.
• H264: L'H.264/MPEG-4 Part 10 o AVC (da Advanced Video Coding, termine inglese chetradotto letteralmente significa "codifica video avanzata"), designazione formale ISO/IEC14496-10 o ITU-T H.264, è un formato standard di compressione video digitale con perditacreato dal Moving Picture Experts Group. Nel maggio 2003 è stata completata la stesurafinale della prima versione dello standard, mentre nelle edizioni successive sono stateaggiunte varie estensioni alle sue funzionalità.
• TurboJpeg: è un’implementazione del codec Jpeg pensata per effettuare codifica edecodifica in tempi più rapidi, mantenendo le caratteristiche del Jpeg-lossy.
• Vp8: Il 19 maggio 2010 Google, che ha acquistato On2 nel 2010, ha rilasciato VP8 comecodec open source (sotto una licenza BSD-like) durante la conferenza Google I/O. Questo hareso VP8 il secondo prodotto di On2 Technologies ad essere donato alla comunità delsoftware libero dopo che nel 2002 rilasciò il codec VP3 (sempre sotto licenza BSD) allaXiph.Org Foundation come codec Theora; la richiesta che ha sollecitato di più Google arilasciare il codice sorgente di VP8 è venuta dalla Free Software Foundation, che il 12 marzo2010 ha pubblicato una lettera aperta chiedendo a Google di rimpiazzare gradualmentel'uso di Adobe Flash Player e H.264 su YouTube con HTML5 e VP8.
• Vp9: Conosciuto in precedenza come Next Gen Open Video (NGOV) o VP-Next è unostandard di compressione video aperto e libero da royalty in sviluppo da Google. Ideatocome il successore di VP8, è in competizione con il codec HEVC (o anche H.265) delconsorzio MPEG (parzialmente con royalty).
Risultati degli esperimentiNella presente sezione si analizzeranno i risultati degli esperimenti relativi ai codec lossy. Per
ciascun tipo di video descritto nel setup degli esperimenti verrà condotta:
Un'analisi preliminare: volta a dare una rappresentazione d'insieme delle prestazioniassolute di ciascun codec in relazione ai fattori di valutazione indicati nella sezioneintroduttiva;
Un'analisi comparativa: volta ad indicare quali codec mostrano le migliori prestazioni intermini di capacità di compressione e tempo totale di codifica/decodifica.
10
Progetto 3D CloudWiz | ATI NICE - DIEE
Si cercherà anche di dare un'indicazione delle prestazioni in termini di occupazione di banda.
Nella sezione conclusiva viene elaborata una valutazione complessiva dei codeccontestualmente al contenuto di ciascun video testato.
La qualità di codifica verrà espressa in due modi differenti:
1. Metriche di qualità: MSSIM, PSNR;
2. Mappatura della qualità .
Nel ambito del progetto è stato scelto di impostare la qualità di codifica di ciascun codeccostruendo una mappatura su una scala che varia da 0 a 100 come mostrato di seguito:
Mappatura 0 ... ... 100
Qualità Minima ... ... Massima
Ad ogni modo a parità di valore di mappatura i codec non mostrano la medesima qualitàrispetto alle metriche MSSIM e PSNR, quindi la mappatura indicata al punto 2 fornisce delleinformazioni su come regolare ciascun codificatore per ottenere certe prestazioni, ma nonconsente di effettuare delle comparazioni in termini di prestazioni dal punto di vista della qualitàvisiva. In tal senso è necessario impiegare le metriche di qualità indicate al punto 1.
Tutti i codec sono valutati al variare della qualità di codifica espressa attraverso la scala appenadescritta. La qualità di codifica così configurata è stata impostata con un passo di 20 ottenendoquindi 6 campioni. Per quanto riguarda JpegLS nei grafici e nelle tabelle viene indicato col nomeCharLS in riferimento all'implementazione utilizzata.
Analisi preliminare video con testoSi consideri come punto di partenza l'analisi dei codec rispetto alle prestazioni migliori e
peggiori in termini di: tempo di codifica, decodifica e totale, PSNR, MSSIM, capacità dicompressione in funzione della mappatura di qualità indicata nella sezione introduttiva.
La tabella seguente mostra un quadro riassuntivo.
11
Progetto 3D CloudWiz | ATI NICE - DIEE
TESTO Q=0 Q=20 Q=40 Q=60 Q=80 Q=100
WORST_ENC_TIME [msec] Vp9 Vp9 Vp9 Vp9 Vp9 WebP
4866,197468 4910,889399 5008,5984 4937,385036 3565,457496 3429,25319
BEST_ENC_TIME [msec] TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg
15,46341917 16,86053934 18,4164263 19,60868813 20,8637897 34,85969099
WORST_DEC_TIME [msec] Jpeg2000 Jpeg2000 Jpeg2000 Jpeg2000 Jpeg2000 Jpeg2000
572,571372 677,0910572 795,357588 832,5779013 1018,379933 1478,032734
BEST_DEC_TIME [msec] TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg WebP
9,740526466 11,14854793 12,5223906 13,42586409 14,41834764 23,88109299
BEST_PSNR (dB) CharLS CharLS Jpeg2000 Jpeg2000 JpegXR WebP
34,13907686 35,67017253 40,0025075 45,83970795 51,7316392 99
WORST_PSNR (dB) TurboJpeg TurboJpeg TurboJpeg TurboJpeg Openh264 Openh264
19,2155304 24,80058591 28,101319 30,81686116 34,33945173 35,51106391
BEST_MSSIM Openh264 Openh264 Jpeg2000 Jpeg2000 JpegXR WebP
0,983138498 0,983138498 0,99250614 0,997370143 0,999201624 1
WORST_MSSIM TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg Openh264
0,743321721 0,898443585 0,94084579 0,96095406 0,980998609 0,990455471
BEST_COMP_RATE WebP Vp8 Vp8 WebP Openh264 Openh264
99,40040071 51,90428284 30,842491 26,28594018 24,36084954 22,02074147
WORST_COMP_RATE CharLS CharLS CharLS CharLS CharLS CharLS
8,828946343 8,005624283 6,71234348 5,655961289 4,193758036 2,372665328
WORST_TOTAL_TIME Vp9 Vp9 Vp9 Vp9 Vp9 Jpeg2000
4998,078751 5043,258524 5160,63894 5097,612516 3672,841376 3508,693979
BEST_TOTAL_TIME TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg
25,20394564 28,00908727 30,9388169 33,03455222 35,28213734 60,73680687Tabella 5: Tabella analisi preliminare video testo
Alcuni codec come indicato nella penultima riga della tabella sono caratterizzati da tempi dicodifica/decodifica estremamente elevati e dell'ordine delle migliaia di msec.
I codec che mostrano tali caratteristiche sono:
Vp9: Il codec è progettato per spostare la complessità computazionale verso il fornitore delservizio di streaming e di fatto mostra una velocità di decodifica molto maggiore rispetto aquella di codifica.
Jpeg2000: Il codec mostra in generale dei tempi di codifica e decodifica molto altiprobabilmente imputabili all'implementazione OpenJpeg.
Il codec WebP mostra dei tempi dei codifica e decodifica in linea con quella degli altri codec.Però impostando il massimo livello di qualità si misurano tempi di codifica elevati accompagnati datempi di decodifica contenuti. Tale comportamento non stupisce se si considera che WebP èstrettamente imparentato col codec video Vp8 e che in generale tali soluzioni tendono aprediligere la velocità in decodifica piuttosto che quella in codifica.
12
Progetto 3D CloudWiz | ATI NICE - DIEE
I seguenti grafici pongono in evidenza le considerazioni preliminari appena fatte, si nota che icodec Vp9 e Jpeg2000 non possono essere inseriti agevolmente all'interno dei grafici dato i tempielevati di codifica e decodifica.
Anche il codec JpegXR mostra dei tempi elevati che si attestano in valori intermedi tra i codecpiù lenti descritti in precedenza e i restanti codec.
Figura 1: Tempo di codifica e di decodifica
Figura 2: Tempo complessivo di codifica/decodifica
Analisi comparativaPer definire quale soluzione può risultare più performante rispetto ad uno specifico ambito di
utilizzo è necessario definire la prestazione congiunta in relazione alla qualità di codifica, lacapacità di compressione e il tempo totale di codifica/decodifica.
Si considera come qualità visiva accettabile quella contraddistinta da valori di MSSIM pari osuperiori a 0,85.
Consideriamo come primo elemento di valutazione la capacità di compressione. La figura 3rappresenta la qualità di codifica misurata tramite la metrica MSSIM in funzione dellacompressione.
13
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 3: MSSIM in funzione della compressione
La prima considerazione evidente è che tutti i codec tranne TurboJpeg sono caratterizzati da unaqualità di codifica sempre accettabile. Risulta inoltre che la qualità di codifica cresce al decresceredella compressione, inoltre dal punto di vista puramente qualitativo risulta che alcuni codec comeTurboJpeg e JpegLS avrebbero la necessità di inviare un volume di informazione maggiore a paritàdi qualità di codifca rispetto agli altri codec. Un altro aspetto strettamente legato alla capacità dicompressione è il tempo speso per effettuarla. Tipicamente maggiore è il tempo di codifica emaggiore risulta il livello di compressione ottenuto. Tale assunzione non è sempre valida e possonoverificarsi comportamenti singolari. In figura 4 viene riportato il tempo di codifica in funzionedella compressione.
14
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 4: Tempo di codifica e compressione
In particolare i codec Vp9, Jpeg2000 mostrano dei livelli di compressione in linea con gli altricodec ma con tempi di codifica molto elevati risultando poco efficienti sotto questo aspetto.Risulta inoltre molto evidente la massima capacità di compressione del codec WebP.
Per rimarcare che non sempre un elevato livello di compressione coincide con elevati tempi dicompressione si consideri il seguente grafico che mostra i codec in grado di mantenere il tempocomplessivo di codifica sotto i 350 msec.
Figura 5: Tempo di codifica/decodifica sotto i 150 msec
15
Progetto 3D CloudWiz | ATI NICE - DIEE
Il codec H264 è caratterizzato da un tempo di codifica limitato associato ad una capacità dicompressione interessante in relazione agli altri codec.
La capacità di compressione massima di TurboJpeg seppur superiore a quella di H264 nongarantisce un'adeguata qualità di codifica (perchè ottenuta alla qualità minima) e perciònonostante rappresenti la migliore soluzione in termini di tempo totale di codifica/decodifca nongarantisce le stesse prestazioni di H264 in relazione al livello di compressione associato ad unaqualità visiva accettabile.
Dal grafico precedente spicca infine il basso livello di compressione del codificatore JpegLS (nelgrafico è indicato il nome dell'implementazione CharLS).
In linea generale si è constatato un certo bilanciamento tra i tempi di codifica e decodifica,risulta tuttavia in alcuni codec recenti come Vp9 che il tempo di codifica sia nettamente superioreal tempo di decodifica. Tale caratteristica è volta a sbilanciare il carico computazionale verso ilfornitore del servizio di streaming. Tale considerazioni risultano più evidenti grazie alla figura 7 incui Vp9 mostra un tempo di decodifica di un ordine di grandezza inferiore rispetto a quello dicodifica mostrato in figura 4. Per comodità il grafico del codec Jpeg2000 non è stato inserito datoche per esso si rileva un tempo di decodifica sopra i 350 msec.
Figura 6:Tempo di decodifica
Si consideri ora come fattore di valutazione il Tempo complessivo di codifica/decodifica infunzione della qualità di codifica espressa con la metrica MSSIM e rispetto alla capacità dicompressione.
Consideriamo in primo luogo la metrica MSSIM in funzione del tempo complessivo.
16
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 7: MSSIM in funzione del tempo complessivo
Il grafico pone in evidenza l'elevato tempo complessivo dei codec: Jpeg2000, Vp9 e WebP allamassima qualità indicando quindi che il bilancio tra tempo di codifica e decodifica li rende pocoefficienti a parità di qualità rispetto agli altri codec.
Spicca inoltre la buona prestazione dei codec TurboJpeg e H264. Il codec TurboJpeg vacomunque tarato opportunamente per evitare di essere impiegato sotto la soglia di 0.85 dellametrica MSSIM.
L'analisi del tempo complessivo di codifica/decodifica in funzione della compressione non portaalcuna indicazione ulteriore rispetto a quelle ottenute dall'analisi dei tempi di codifica e decodificastudiati indipendentemente. In figura viene comunque riportato il tempo complessivo dicodifica/decodifica in funzione della compressione
17
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 8: Tempo complessivo in funzione della compressione
Per identificare quali codec consentano il miglior compromesso in termini di compressione etempo complessivo di codifica/decodifica si è scelto di analizzare i dati considerando quelleimpostazioni dei codec che consentono di avere una qualità di codifica sempre accettabile.
In tal senso per semplificare l'analisi i dati riportati nella tabella 6 si riferiscono ai valori: 60,80 e100 della mappatura di qualità.
In verde si indica la prestazione migliore, in giallo la seconda migliore prestazione e in rosso lapeggiore tutte valutate al medesimo livello qualitativo impostato in ingresso.
La prima considerazione che risulta evidente è che tutti i codec codificano con un livello diqualità più che accettabile e ciò deriva dal fatto che sono stati selezionati i dati relativi a settaggidella qualità di codifica medio alti.
18
Progetto 3D CloudWiz | ATI NICE - DIEE
CODEC MSSIM COMPRESSION T_enc (msec) T_dec (msec) Total_time (msec)WebP 0,988276011 26,43783405 287,483691 34,06504864 321,5487396
0,992711963 21,69090183 296,3066881 38,21110014 334,5177883 1 16,49622481 3429,25319 23,88109299 3453,134283
Jpeg_LS 0,979449333 5,68915664 134,577887 78,53231474 213,1102017 0,993013031 4,222444622 169,3775122 100,4376981 269,8152103 1 2,386900564 156,8970143 144,4842203 301,3812346
Turbo_Jpeg 0,96095406 15,48237537 19,60868813 13,42586409 33,03455222 0,980998609 11,41161849 20,8637897 14,41834764 35,28213734 0,999738575 3,349650985 34,85969099 25,87711588 60,73680687
Jpeg_2000 0,997370143 9,333726264 1752,139099 832,5779013 2584,717 0,999067921 6,386746736 1741,090072 1018,379933 2759,470004 1 4,489849363 2030,661245 1478,032734 3508,693979
H264 0,987807024 24,46221517 46,06544778 54,34180973 100,4072575 0,987807024 24,46221517 46,87347496 54,82239485 101,6958698 0,990455471 22,10713679 46,65348498 54,78134335 101,4348283
Jpeg_XR 0,996610609 8,650114298 350,7531559 285,0714306 635,8245866 0,999201624 5,409043506 383,0818455 316,0900644 699,1719099 1 3,907941942 237,0314664 209,7319413 446,7634077
Vp8 0,989731445 23,76972032 117,5140544 57,85012303 175,3641774 0,994232086 19,54269948 119,6816123 60,80127754 180,4828898 0,99864824 11,05812993 183,2582947 106,0947296 289,3530243
Vp9 0,996348166 19,4338347 4937,385036 160,2274807 5097,612516 0,997994029 15,0409803 3565,457496 107,3838798 3672,841376 0,999200104 9,060775479 1529,878196 94,62571102 1624,503907
Tabella 6: Riassunto prestazioni
Analizzando i dati il miglior livello di compressione misurato è ottenuto dal codec:
WebP
Un livello di compressione analogo si ottiene col codec H264 che risulta più vantaggioso datoche mostra un tempo totale di codifica e decodifica nettamente inferiore.
In tabella si riporta il confronto tra il codec WebP e H264.
Codec Compressione T_enc (msec) T_dec (msec) T_tot (msec)
WebP 26.4378 287.4836 34.0650 321.548
H264 24.462 46.065 54.341 100.407Tabella 7: Comparativa WebP, H264
WebP risulta più prestazionale rispetto a H264 soltanto per il tempo di decodifica macomplessivamente H264 è più veloce e mostra dei livelli di compressione e di qualità percepita inlinea con WebP.
19
Progetto 3D CloudWiz | ATI NICE - DIEE
Il codec più prestazionale dal punto di vista del tempo di codifica/decodifica è:
TurboJpeg
Il secondo codec più veloce è H264 che risulta comunque tre volte più lento rispetto aTurboJpeg.
In tabella si riporta un breve confronto tra i due codec.
Codec Compressione T_enc (msec) T_dec (msec) T_tot (msec)
TurboJpeg 15.482 19.608 13.425 33.04
H264 24.464 46.065 54.341 100.407Tabella 8: Comparativa TurboJpeg, H264
TurboJpeg risulta più vantaggioso se si predilige una maggiore velocità di codifica/decodifica. Illivello di compressione medio seppur inferiore a quello mostrato da H264 risulta comunqueinteressante. Dal punto di vista della qualità percepita entrambi i codec mostrano un MSSIM ben aldi sopra di 0.85 al quale corrisponde una qualità visiva più che soddisfacente.
Per completare l'analisi si considerino i valori medi minimi e massimi del bitrate di ciascuncodec mediati su tutti i possibili valori di qualità impostabili.
La tabella seguente riassume i risultati ottenuti.
CodecBitrate_min(Mbit/sec)
Bitrate_max(Mbit/sec)
Bitrate_mean(Mbit/sec)
WebP 5,56482226 33,88455276 14,34863827Jpeg_LS 62,72643029 234,181184 93,07028927
Turbo_Jpeg 9,244235956 166,8732661 24,48116847Jpeg_2000 12,81654758 124,495758 32,65835467
H264 20,58411649 25,28446833 21,99253125Jpeg_XR 20,58804006 143,03365 44,76339511
Vp8 10,68014459 50,54807669 17,64293967Vp9 13,31146339 61,69087859 21,72860718
Tabella 9: Stima dell'occupazione di banda per tutte le qualità impostabili
La tabella da un'indicazione generale dell'allocazione di banda per ciascun codec in esame.
Ad ogni modo dato che per questa analisi si stanno considerando tutti i possibili valori di qualitàimpostabili risulta che tali valori si riferiscono anche a qualità di codifica percepite non accettabili.
Per qualità percepite che vanno da livelli accettabili al massimo disponibile otteniamo i seguentirisultati:
20
Progetto 3D CloudWiz | ATI NICE - DIEE
CodecBitrate_min(Mbit/sec)
Bitrate_max(Mbit/sec)
Bitrate_mean(Mbit/sec)
WebP 18,46260308 33,88455276 23,56011118Jpeg_LS 82,7641117 234,181184 117,3546373
Turbo_Jpeg 29,19617288 166,8732661 45,27070492Jpeg_2000 36,97539988 124,495758 63,28958429
H264 20,58411649 25,28446833 22,77157418Jpeg_XR 43,08464106 143,03365 72,26279965
Vp8 18,00298697 50,54807669 26,17526987Vp9 20,83270081 61,69087859 31,77447069
Tabella 10: Stima dell'occupazione di banda per qualità di codifica medio alte
Come si nota i valori minimi sono aumentati è ciò sta ad indicare che per ottenere una qualitàpercepita sufficiente è necessario spedire una quantità maggiore di informazione.
In definitiva se lo scopo è ottenere dei forti valori di compressione è consigliabile l'utilizzo delcodec H264, se invece è necessario codificare e decodificare un video ad elevata velocità èconsigliabile l'utilizzo del codec TurboJpeg.
Analisi preliminare video con immagini naturaliSi considerino i dati preliminari mostrati nella seguente tabella riassuntiva.
I medesimi codec, che nel caso di codifica di video con testo hanno mostrato tempi dicodifica/decodifica elevati , mostrano lo stesso comportamento anche per il contenuto video conimmagini naturali.
VIDEO Q=0 Q=20 Q=40 Q=60 Q=80 Q=100
WORST_ENC_TIME [msec] Vp9 Vp9 Vp9 Vp9 Vp9 Vp9
2672,641185 3007,92423 3346,342851 3751,653657 4142,033323 3195,400976
BEST_ENC_TIME [msec] TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg
15,74966524 15,35433476 15,52912589 15,37437053 15,96541917 27,79412303
WORST_DEC_TIME [msec] Jpeg2000 Jpeg2000 Jpeg2000 Jpeg2000 Jpeg2000 Jpeg2000
399,9048541 408,9278441 430,8044592 496,686289 614,1991574 860,3661831
BEST_DEC_TIME [msec] TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg
9,367221745 9,394606581 9,757404864 9,872788269 10,49788841 17,73095708
BEST_PSNR (dB) Openh264 Openh264 Vp9 JpegXR JpegXR WebP
43,6484677 43,6484677 46,02464432 51,96718945 56,75624662 99
WORST_PSNR (dB) Jpeg2000 Jpeg2000 Jpeg2000 CharLS Openh264 Openh264
23,44511458 30,20765771 37,15785421 40,31535894 44,89831222 45,4600948
BEST_MSSIM Openh264 JpegXR JpegXR JpegXR JpegXR WebP
0,958276824 0,963646627 0,980521771 0,991885608 0,996723066 1
WORST_MSSIM Jpeg2000 CharLS CharLS CharLS CharLS Openh264
0,615877452 0,726387179 0,771552977 0,823444509 0,929148383 0,972007908
BEST_COMP_RATE Jpeg2000 Jpeg2000 Jpeg2000 Jpeg2000 Jpeg2000 WebP
11643,67248 7140,652411 4571,602682 3735,00235 2772,697849 1412,437439
21
Progetto 3D CloudWiz | ATI NICE - DIEE
WORST_COMP_RATE TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg
102,8933092 82,77233872 72,32501731 65,17482235 54,62475047 27,29451626
WORST_TOTAL_TIME Vp9 Vp9 Vp9 Vp9 Vp9 Vp9
2747,966906 3095,228422 3439,849584 3849,857227 4250,259044 3367,759897
BEST_TOTAL_TIME TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg
25,11688698 24,74894134 25,28653076 25,2471588 26,46330758 45,52508011Tabella 11: Tabella analisi preliminare video immagini naturali
Analogamente al caso considerato nella sezione precedente i codec Vp9 e Jpeg2000 risultanodifficili da inserire nei grafici relativi al tempo di codifica e decodifica come mostrato dalle figure 9e 10. Anche il codec JpegXR mostra dei tempi di codifica e decodifica elevati che si attestano invalori intermedi tra i codec più lenti appena descritti e i restanti codec. Il codec WebP mostra deitempi di codifica/decodifica molto elevati e paragonabili a quelli di vp9 e Jpeg2000 quando siimposta la massima qualità di codifica.
Figura 9: Tempo di codifica e decodifica
22
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 10: Tempo complessivo di codifica/decodifica
Analisi comparativa
Per definire quale soluzione può risultare più performante rispetto ad uno specifico ambito diutilizzo è necessario definire la prestazione congiunta in relazione alla qualità di codifica, lacapacità di compressione e il tempo totale di codifica/decodifica. Si considera come qualità visivaaccettabile quella contraddistinta da valori di MSSIM pari o superiori a 0.85.
Consideriamo come primo elemento di valutazione la capacità di compressione. Il seguentegrafico rappresenta la qualità di codifica misurata tramite la metrica MSSIM in funzione dellacompressione.
23
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 11: MSSIM e Compressione
Risulta piuttosto evidente che per il contenuto video con immagini naturali Jpeg2000 mostrauna capacità di compressione molto alta rispetto agli altri codec per il quale non risulta agevole lavisualizzazione. Per un analisi più semplice si può considerare il seguente grafico che riporta unaporzione del grafico precedente.
Un altra informazione che risulta evidente dalla figura 11 è data dal fatto che alcuni codecmostrano una qualità di codifica non sempre accettabile.
I codec con tale caratteristica sono : Jpeg2000, Turbojpeg, e JpegLS. Nel caso di compressione divideo con testo soltanto TurboJpeg mostrava un MSSIM sotto la soglia di 0,85.
24
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 12: Compressione[0-600] & MSSIM [0.85-1]
In generale l'andamento qualitativo dei codec mostrati è molto simile. Soltanto JpegLS eTurboJpeg mostrano a parità di MSSIM rispetto agli altri codec un capacità di compressioneinferiore. Un altro aspetto strettamente legato alla capacità di compressione è il tempo speso adeffettuarla. In figura viene riportato il livello di compressione in funzione del tempo di codifica.
Figura 13: Tempo di codifica e compressione
25
Progetto 3D CloudWiz | ATI NICE - DIEE
L'analisi risulta più agevole considerando i codec più veloci riportati nella seguente figura.
Figura 14: Tempo di codifica [0-350 msec] & Compressione [0-600]
I codec H264 e Vp8 sono caratterizzati da un tempo di codifica limitato, se paragonato ad altricodec, ma sono in grado di comprimere in maniera significativa. Sia il codec Vp8 che H264comprimono maggiormente rispetto a TurboJpeg sia dal punto di vista della compressione mediasia dal punto di vista della compressione massima. Tale risultato non è stato riscontrato colcontenuto video con testo nel quale TurboJpeg alla qualità minima comprimeva in misurasuperiore rispetto ad H264. Spicca anche per il contenuto video con immagini naturali la scarsacapacità di compressione del codec JpegLS.
In linea generale si è constatato un certo bilanciamento tra i tempi di codifica e decodifica,risulta tuttavia in alcuni codec come Vp9 che il tempo di codifica sia nettamente superiore altempo di decodifica. Tale considerazioni risultano più evidenti grazie alla figura15 in cui il codecVp9 mostra un tempo di decodifica di un ordine di grandezza inferiore rispetto al tempo di codifica.Per comodità il grafico non riporta il codec Jpeg2000 dato che per esso si rileva un tempo didecodifica sopra i 350 msec.
26
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 15: Tempo di decodifica
Si consideri ora come fattore di valutazione il Tempo complessivo di codifica/decodifica infunzione della qualità di codifica espressa con la metrica MSSIM e rispetto alla capacità dicompressione.
Consideriamo in primo luogo la metrica MSSIM in funzione del tempo complessivo.
Figura 16: Tempo complessivo in funzione del MSSIM
27
Progetto 3D CloudWiz | ATI NICE - DIEE
Il grafico pone in evidenza l'elevato tempo complessivo dei codec: Jpeg2000, Vp9 e WebP allamassima qualità indicando quindi che il bilancio tra tempo di codifica e decodifica li rende pocoefficienti a parità di qualità rispetto agli altri codec.
Spicca inoltre la buona prestazione dei codec TurboJpeg e H264. Il codec TurboJpeg vacomunque regolato opportunamente per evitare di codificare con una qualità visiva nonaccettabile.
L'analisi del tempo complessivo di codifica/decodifica in funzione della compressione non portaalcuna indicazione ulteriore rispetto a quelle ottenute dall'analisi dei tempi di codifica e decodificastudiati indipendentemente. In figura 18 viene comunque riportato il tempo complessivo dicodifica/decodifica in funzione della compressione.
Figura 17:Tempo complessivo in funzione della compressione
Per identificare quali codec consentano il miglior compromesso in termini di compressione etempo complessivo di codifica/decodifica si è scelto di analizzare i dati considerando quelleimpostazioni dei codec che consentono di avere una qualità di codifica sempre accettabile.
In tal senso per semplificare l'analisi i dati riportati nella tabella 12 si riferiscono ai valori: 60,80e 100 della mappatura di qualità. In verde si indica la prestazione migliore, in giallo la secondamigliore prestazione e in rosso la peggiore tutte valutate al medesimo livello qualitativo impostatoin ingresso. La prima considerazione che risulta evidente è che tutti i codec codificano con unlivello di qualità più che accettabile e ciò deriva dal fatto che sono stati selezionati i dati relativi asettaggi della qualità di codifica medio alti.
28
Progetto 3D CloudWiz | ATI NICE - DIEE
CODEC MSSIM COMPRESSION T_enc (msec) T_dec (msec) Total_time(msec)WebP 0,969428811 240,042572 200,6831731 18,85086266 219,5340358
0,977946285 172,2829443 217,4238798 20,84014306 238,26402291 15,59999377 2433,795332 49,33964807 2483,13498
Jpeg_LS 0,823444509 14,11480207 147,5273591 79,74548069 227,27283980,929148383 5,061866524 165,8584678 90,06125894 255,9197268
1 2,302683955 115,6539757 100,605877 216,2598526
TurboJpeg
0,978931843 52,95227304 15,37437053 9,872788269 25,24715880,988691991 39,45889184 15,96541917 10,49788841 26,463307580,997888046 8,74276877 27,79412303 17,73095708 45,52508011
Jpeg2000
0,926083172 436,7932399 1138,917382 496,686289 1635,6036710,986520629 104,858828 1152,880263 614,1991574 1767,079421
1 10,97188575 1096,165106 860,3661831 1956,531289H264 0,966607142 223,7185104 35,03406724 46,96930472 82,00337196
0,966607142 223,7185104 36,63472103 47,95190844 84,586629470,972007908 193,141088 33,44926323 46,17413162 79,62339485
JpegXR
0,991885608 80,21428136 274,6776738 191,964133 466,64180690,996723066 29,39326674 301,285681 218,4234363 519,7091173
1 8,249279081 275,6238026 213,5992446 489,2230472Vp8 0,97018269 208,3921707 95,77055937 42,24031044 138,0108698
0,977893429 147,1105031 93,5961774 43,5302804 137,12645780,992740937 34,53414559 102,0817396 51,76111588 153,8428555
Vp9 0,985859923 190,1418479 3751,653657 98,20357082 3849,8572270,990487099 94,56274684 4142,033323 108,225721 4250,2590440,996725629 19,72864439 3195,400976 172,3589213 3367,759897
Tabella 12: Riassunto prestazioni video immagini naturali
il miglior livello di compressione misurato è ottenuto dal codec:
Jpeg2000
La seconda migliore prestazione si riscontra col codec WebP, mentre il codec che comprimemeno risulta essere Jpeg_LS. Come indicato nell'analisi preliminare il codec Jpeg2000 risulta esseretroppo lento sia in fase di codifica che di decodifica.
In base a tali considerazioni si possono considerare altri codec che comprimono in misurainferiore, ma che possono garantire una migliore prestazione dal punto di vista del tempo dicodifica decodifica.
I codec che più si avvicinano in termini di capacità di compressione a WebP e Jpeg2000 sono:
H264 e Vp8
I due codec e le rispettive capacità di compressione sono indicati in grigio nella tabella 14.
Nella seguente tabella si riportano le prestazioni dei codec WebP, H264 e Vp8.
29
Progetto 3D CloudWiz | ATI NICE - DIEE
Codec Compressione T_enc (msec) T_dec (msec) T_tot (msec)
Webp 240.042 200.683 18.850 227.272
H264 223.718 35.034 46.969 82.003
Vp8 208.39 95.770 42.240 138.010Tabella 13: Comparativa WebP,H264 e Vp8
Risulta evidente come H264 sia il compromesso migliore tra capacità di compressione e tempototale di codifica/decodifica. Ancora una volta WebP mostra un tempo di decodifica moltocontenuto se paragonato a quello di codifica. Dal punto di vista della compressione tutti i codecmostrati nella precedente tabella sono comunque caratterizzati da livelli simili.
Per quanto riguarda il tempo complessivo di codifica/decodifica il codec più prestazionale è:
TurboJpeg
La seconda prestazione è relativa al codec H264 come indicato dalla seguente tabella riassuntiva.
Codec Compressione T_enc (msec) T_dec (msec) T_tot (msec)
TurboJpeg 52.952 15.374 9.872 25.247
H264 223.718 35.034 46.969 82.003Tabella 14: Comparativa TurboJpeg, H264
Il codec TurboJpeg è complessivamente più veloce rispetto ad H264 ma comprime molto menoe con un divario maggiore rispetto a quello riscontrato sul video con testo indicando quindi cheH264 rappresenta una buona soluzione per comprimere efficacemente immagini naturali.
Per completare i risultati ottenuti consideriamo i valori medi minimi e massimi del bitrate diciascun codec mediati su tutti i possibili valori di qualità impostabili. La tabella riassume i risultatiottenuti considerando di inviare il filmato di prova con una frequenza di 25 fotogrammi al secondo.
Codec Bitrate_min(Mbit/sec) Bitrate_max(Mbit/sec) Bitrate_mean(Mbit/sec)WebP 0,814354676 35,83124509 1,87755913
Jpeg_LS 5,9842365 242,7459482 16,14733677Turbo_Jpeg 5,484011784 63,93480312 9,843200368Jpeg_2000 0,062812793 50,94540837 0,234057724
H264 2,153215433 2,894087456 2,362885518Jpeg_XR 1,558889132 67,75952111 3,812251763
Vp8 1,130930742 16,18592817 1,980661352Vp9 0,713086437 28,33277284 1,485962905
Tabella 15: Stima dell'occupazione di banda per tutte le qualità impostabili
30
Progetto 3D CloudWiz | ATI NICE - DIEE
Per garantire un livello di qualità percepita sempre accettabile è necessario che il bitrate sia contenuto negli estremi indicati nella seguente tabella.
Codec Bitrate_min(Mbit/sec) Bitrate_max(Mbit/sec) Bitrate_mean(Mbit/sec)WebP 1,915761278 35,83124509 3,106674695
Jpeg_LS 15,93481422 242,7459482 39,53251598Turbo_Jpeg 9,008722642 63,93480312 13,70007027Jpeg_2000 0,399618459 50,94540837 1,145790776
H264 2,153215433 2,894087456 2,483816769Jpeg_XR 3,29094402 67,75952111 7,771341321
Vp8 1,776025178 16,18592817 3,172497469Vp9 1,452556168 28,33277284 3,243918022
Tabella 16: Stima dell'occupazione di banda per qualità medio alte
Risulta in definitiva che il codec H264 rappresenta il miglior compromesso nel caso in cuil'obbiettivo della codifica sia comprimere a livelli elevati. Se invece l'obbiettivo finale dellacompressione è mantenere il tempo totale di codifica/decodifica a livelli contenuti è consigliabilel'impiego del codec TurboJpeg.
Analisi preliminare video compositoL'analisi preliminare suggerisce le medesime indicazioni ottenute nelle sezioni precedenti, i
codec Vp9 e Jpeg2000 mostrano tempi di codifica/decodifica inoltre il codec WebP , come nel casodi video contenente solo testo, registra il tempo di codifica più elevato.
COMPOUND Q=0 Q=20 Q=40 Q=60 Q=80 Q=100
WORST_ENC_TIME [msec] Vp9 Vp9 Vp9 Vp9 Vp9 WebP
4164,203934 4152,475207 4404,46671 4626,886681 4151,385994 4543,754564
BEST_ENC_TIME [msec] TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg
15,22715737 16,44491416 16,93326037 17,19088984 19,13022461 30,46492561
WORST_DEC_TIME [msec] Jpeg2000 Jpeg2000 Jpeg2000 Jpeg2000 Jpeg2000 Jpeg2000
478,7967797 585,3875894 707,9317253 725,8288798 874,1931674 1353,496748
BEST_DEC_TIME [msec] TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg
9,507157368 10,84386409 11,45883405 12,05192704 13,6654907 22,29439771
BEST_PSNR (dB) Openh264 JpegXR JpegXR JpegXR JpegXR WebP
34,26231436 35,84257248 39,27740487 45,26520834 52,13435601 99
WORST_PSNR (dB) TurboJpeg TurboJpeg TurboJpeg TurboJpeg Openh264 Openh264
20,82187696 27,36776404 30,7273999 33,28083371 35,63908562 36,89740004
BEST_MSSIM Openh264 JpegXR JpegXR JpegXR JpegXR WebP
0,94216124 0,963396159 0,978483511 0,993709823 0,998286612 1
WORST_MSSIM TurboJpeg CharLS CharLS CharLS Openh264 Openh264
0,707071259 0,850154133 0,886638542 0,930836129 0,952847515 0,970806456
BEST_COMP_RATE WebP Vp8 Vp8 WebP Openh264 Openh264
164,6118849 87,9713508 51,75419733 43,55505855 42,22227124 37,6143176
31
Progetto 3D CloudWiz | ATI NICE - DIEE
WORST_COMP_RATE CharLS CharLS CharLS CharLS CharLS CharLS
5,479461607 4,999615256 4,364925185 3,724219648 3,016232186 1,922265907
WORST_TOTAL_TIME Vp9 Vp9 Vp9 Vp9 Vp9 WebP
4277,341393 4266,763754 4524,229979 4762,119122 4269,475076 4588,725991
BEST_TOTAL_TIME TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg TurboJpeg
24,73431474 27,28877825 28,39209442 29,24281688 32,79571531 52,75932332Tabella 17: Tabella analisi preliminare video composito
Le considerazioni preliminari risultano efficacemente espresse dai seguenti grafici riassuntivi.
Figura 18: Tempo di codifca e decodifica
Figura 19: Tempo complessivo di codifica e decodifica
32
Progetto 3D CloudWiz | ATI NICE - DIEE
Analisi comparativaPer definire quale soluzione può risultare più performante rispetto ad uno specifico ambito di
utilizzo è necessario definire la prestazione congiunta in relazione alla qualità di codifica, lacapacità di compressione e il tempo totale di codifica/decodifica. Si considera come qualità visivaaccettabile quella contraddistinta da valori di MSSIM pari o superiori a 0.85. Consideriamo comeprimo elemento di valutazione la capacità di compressione. Il seguente grafico rappresenta laqualità di codifica misurata tramite la metrica MSSIM in funzione della compressione.
Figura 20: MSSIM e Compressione
Il primo aspetto evidente è che qualitativamente si rileva un comportamento dei codec che puòattestarsi in una via di mezzo tra ciò che è stato riscontrato con il video contenente testo e quelloriscontrato con immagini naturali. Risulta evidente inoltre come Jpeg2000 a causa della presenza ditesto comprime in misura nettamente inferiore a ciò che si è riscontrato con le immagini naturali.
Per quanto riguarda invece JpegLS e TurboJpeg si riscontra ancora una capacità di compressioneinferiore a parità di qualità di codifica rispetto agli altri codec. Tale considerazione risultamaggiormente chiara analizzando il grafico seguente.
33
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 21: MSSIM e Compressione
Per quanto riguarda il tempo di codifica e il livello di compressione otteniamo i risultati riportatinella figura seguente.
Figura 22: Tempo di codifica e compressione
Le indicazioni generali che si ottengono sono in buona sostanza le medesime ottenute con glialtri contenuti video. Ancora una volta Vp9 e Jpeg2000 registrano i tempi di codifica più alti e aparità di compressione risultano svantaggiosi rispetto agli altri codec. I codec più veloci sonoriportati nella seguente figura.
34
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 23: Tempo di codifica in funzione del livello di compressione
Risulta come nei casi precedenti che TurboJpeg e H264 rappresentano un ottimo compromessoin termini di capacità di compressione in funzione del tempo speso per effettuarla. Per quantoriguarda il tempo di decodifica non si riscontrano risultati significativi rispetto ai contenuti videogià analizzati e continua a risultare che Vp9 mostra un forte sbilanciamento del tempo di codificarispetto a quello di decodifica. Nella figura seguente è riportato il tempo di decodifica in funzionedella compressione e per comodità non viene riportato il risultato conseguito da Jpeg2000 datol'elevato tempo di decompressione.
Figura 24: Tempo di decodifica e compressione
Di seguito si riporta il tempo complessivo di codifica/decodifica che comunque non fornisceindicazioni aggiuntive rispetto ai contenuti video già analizzati.
35
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 25: Tempo complessivo e compressione
Si consideri ora come fattore di valutazione il Tempo complessivo di codifica/decodifica infunzione della qualità di codifica espressa con la metrica MSSIM e rispetto alla capacità dicompressione. Consideriamo in primo luogo la metrica MSSIM in funzione del tempo complessivo.
Figura 26: Tempo complessivo in funzione del MSSIM
Ancora una volta risulta evidente la forte separazione in termini di tempo complessivo traVp9,Jpeg2000 e WebP alla qualità massima e gli altri codec.
Emerge anche che TurboJpeg,WebP e JpegLS non sempre mostrano una qualità di codificaaccettabile. Questa caratteristica è imputabile alla presenza di variazioni continue di colore tipichedelle immagini naturali, infatti tale comportamento non è stato riscontrato con il video contenente
36
Progetto 3D CloudWiz | ATI NICE - DIEE
soltanto testo. Ad ogni modo risulta evidente il vantaggio nell'impiegare TurboJpeg e H264 quandosi voglia che la catena di compressione/decompressione venga eseguita velocemente.
Quindi regolando opportunamente la qualità di codifica soprattutto di TurboJpeg è possibileottenere dei tempi complessivi molto contenuti. Per H264 invece non è stato possibile configurareuna mappatura della qualità come risulta evidente dalla figura 26. Tale caratteristica può risultarepiù naturale considerando che è un codec specifico per la compressione di video, per il quale lacaratteristica fondamentale è la capacità di compressione (o il bitrate).
L'analisi del tempo complessivo di codifica/decodifica in funzione della compressione non portaalcuna indicazione ulteriore rispetto a quelle ottenute dall'analisi dei tempi di codifica e decodificastudiati indipendentemente. In figura viene comunque riportato il tempo complessivo dicodifica/decodifica in funzione della compressione.
Figura 27: Tempo complessivo in funzione della compressione
37
Progetto 3D CloudWiz | ATI NICE - DIEE
Per identificare quali codec consentano il miglior compromesso in termini di compressione etempo complessivo di codifica/decodifica si è scelto di analizzare i dati considerando quelleimpostazioni dei codec che consentono di avere una qualità di codifica sempre accettabile. In talsenso per semplificare l'analisi i dati riportati nella tabella 18 si riferiscono ai valori: 60,80 e 100della mappatura di qualità. In verde si indica la prestazione migliore, in giallo la seconda miglioreprestazione e in rosso la peggiore tutte valutate al medesimo livello qualitativo impostato iningresso. La prima considerazione che risulta evidente è che tutti i codec codificano con un livellodi qualità più che accettabile e ciò deriva dal fatto che sono stati selezionati i dati relativi a settaggidella qualità di codifica medio alti.
CODEC MSSIM COMPRESSION T_enc (msec) T_dec (msec) Total_time(msec)WebP 0,95365333 44,38240201 245,2928655 26,42888412 271,7217496
0,960627767 35,43517951 253,6789056 29,16226896 282,8411745 1 13,16830143 4543,754564 44,97142775 4588,725991
Jpeg_LS 0,930836129 3,713455073 204,8634506 116,3462604 321,209711 0,974149372 3,008407257 215,0426037 122,361475 337,4040787 1 1,918267165 151,202309 136,5979742 287,8002833
Turbo_Jpeg 0,962127674 20,63188285 17,19088984 12,05192704 29,24281688 0,979514539 15,29219481 19,13022461 13,6654907 32,79571531 0,999074867 4,582414483 30,46492561 22,29439771 52,75932332
Jpeg_2000 0,991932326 15,50323449 1610,779399 725,8288798 2336,608279 0,996797602 9,615098861 1553,037102 874,1931674 2427,230269 1 5,906544444 1828,029428 1353,496748 3181,526176
H264 0,952847515 43,03029573 42,22667096 51,14334621 93,37001717 0,952847515 43,03029573 42,0497897 50,64510443 92,69489413 0,970806456 38,32297274 41,99806152 51,13049499 93,12855651
Jpeg_XR 0,993709823 13,79115296 314,5512518 239,8181989 554,3694506 0,998286612 8,064184996 345,3601531 271,3197783 616,6799313 1 5,208919753 257,3068555 212,706289 470,0131445
Vp8 0,948732562 39,16167566 107,2364521 50,40015451 157,6366066 0,969351887 31,53971388 113,3128326 53,59950358 166,9123362 0,996088258 15,16684625 153,2143877 83,07090272 236,2852904
Vp9 0,987610462 32,70041026 4626,886681 135,2324406 4762,119122 0,994470619 23,750875 4151,385994 118,0890815 4269,475076 0,998396223 11,76980364 2105,564564 111,1083648 2216,672928
Tabella 18: riassunto delle prestazioni
Il miglior livello di compressione misurato è ottenuto dal codec:
WebP
La seconda prestazione migliore appartiene al codec H264 e analogamente ai casi visti inprecedenza Jpeg_LS è il codec che comprime meno.
La tabella seguente riassume le prestazioni dei codec H264 e WebP.
38
Progetto 3D CloudWiz | ATI NICE - DIEE
Codec Compressione T_enc (msec) T_dec (msec) T_tot (msec)
WebP 44.382 245.292 26.428 271.721
H264 43.030 42.226 51.143 93.370Tabella 19: Comparativa WebP, H264
In questo caso risulta facile asserire che H264 risulta maggiormente vantaggioso rispetto aWebP dato che mostra un livello di compressione praticamente identico ma con un tempocomplessivo di codifica/decodifica nettamente migliore. Risulta ad ogni modo che WebP mostra ilmiglior tempo in fase di decodifica.
Il codec più prestazionale dal punto di vista del tempo complessivo di codifica/decodifica è:
TurboJpeg
Mentre il secondo codec più veloce è H264, la tabella seguente pone in relazione le prestazionidei due codec.
Codec Compressione T_enc (msec) T_dec (msec) T_tot (msec)
TurboJpeg 20.631 17.190 12.051 29.24
H264 43.030 42.226 51.143 93.37Tabella 20: Comparativa TurboJpeg, H264
Il codec H264 comprime all'incirca il doppio rispetto a TurboJpeg ma con un tempo complessivodi codifica/decodifica circa tre volte maggiore rispetto a TurboJpeg.
Per concludere l'analisi si considerino i risultati rispetto ai valori medi minimi e massimi delbitrate di ciascun codec mediati su tutti i possibili valori di qualità impostabili. La tabella riassume irisultati ottenuti considerando di inviare il filmato di prova con una frequenza di 25 fotogrammi alsecondo.
Codec Bitrate_min(Mbit/sec) Bitrate_max(Mbit/sec) Bitrate_mean(Mbit/sec)WebP 3,335725628 42,44793475 8,837537099
Jpeg_LS 102,4783621 291,3917364 143,1859957Turbo_Jpeg 7,870063785 121,9809343 19,5651484Jpeg_2000 5,535648095 94,63523136 16,45643864
H264 11,58491283 14,58569521 12,46154058Jpeg_XR 12,38217829 107,3096201 27,59269454
Vp8 6,234323006 36,85454384 10,54931118Vp9 7,248075994 47,49163342 12,41248096
Tabella 19: Stima dell'occupazione di banda per tutte le qualità impostabili
39
Progetto 3D CloudWiz | ATI NICE - DIEE
Volendo garantire una qualità percepita accettabile il bitrate minimo dovrà essere incrementato
come indicato dalla seguente tabella.
Codec Bitrate_min(Mbit/sec) Bitrate_max(Mbit/sec) Bitrate_mean(Mbit/sec)WebP 10,79589286 42,44793475 15,44515802
Jpeg_LS 128,5089574 291,3917364 172,1254155Turbo_Jpeg 22,17953321 121,9809343 34,02712295Jpeg_2000 21,3831863 94,63523136 39,1122888
H264 11,58491283 14,58569521 12,95156145Jpeg_XR 26,33815531 107,3096201 46,30376706
Vp8 10,60070151 36,85454384 16,1321004Vp9 11,70951066 47,49163342 19,28183546
Tabella 20: Stima dell'occupazione di banda per qualità medio alte
In definitiva il codec H264 è la soluzione migliore in termini di compressione mentre TurboJpegrisulta il codec migliore per quanto riguarda il tempo complessivo impiegato per la codifica edecodifica.
ConclusioniPer tutti i contenuti video testati è emerso che i codec con performance migliori sono:
TurboJpeg e H264. Il primo garantisce la migliore prestazione in termini di tempo dicodifica/decodifica complessivi mostrando ad ogni modo dei livelli di compressione comunque inlinea con gli altri codec. Il secondo rappresenta certamente il miglior compromesso tra tempototale di codifica/decodifica e capacità di compressione.
40
Progetto 3D CloudWiz | ATI NICE - DIEE
Test sui codec compoundIn questa sezione si descriveranno le prestazioni dei metodi di compressione compositi. L'analisi
sarà incentrata sulla valutazione dei tempi di codifica, decodifica e totali nonché sulla capacità dicompressione. Si valuterà inoltre la qualità di codifica in relazione alle metriche PSNR e MSSIM.
Codec compound
I tre metodi di classificazione e codifica per compound image utilizzati sono i seguenti:
Metodo a blocchi
Metodo a strati
Metodo ibrido
Si rimanda al documento di descrizione dei suddetti metodi per la descrizione delle fasi diclassificazione, mentre i codec singoli utilizzati per le aree di testo e di immagini sono i seguenti:
CharLS
H.264
Jpeg2000
JpegXR
LZO
RLE + LZO
TurboJpeg
Vp8
Vp9
WebP
Zrle
Alcuni di questi codec sono stati scartati a priori dopo essere stati testati singolarmente, poichénon adatti al caso studiato. In particolar modo CharLS, Jpeg2000, JpegXR, Vp9 e WebP non sonocodec pensati per effettuare codifica e decodifica di immagini in real time, e presentano quinditempi di elaborazione eccessivamente elevati. I codec rimanenti sono stati selezionati in base airisultati ottenuti testando le performance dei singoli codec su immagini di tipo composito,immagini contenenti prevalentemente testo o immagini naturali.
Setup degli esperimentiAl fine di valutare i metodi compound è stato utilizzato un video composto da zone di immagini
naturali e zone di testo. Per una descrizione più dettagliata del video si rimanda al documentospecifico in cui viene descritto il dataset utilizzato negli esperimenti. I test sono stati svolti inparallelo, avviando tre simulazioni per volta, su una macchina non dedicata, fornita di un
41
Progetto 3D CloudWiz | ATI NICE - DIEE
processore Intel Core i7-3517U, su macchina virtuale Debian 7.
Risultati degli esperimenti
Al fine di gestire i risultati, è stato necessario compiere una prima scrematura, eliminando irisultati non accettabili. Sono stati quindi tracciati due grafici scatter dei risultati ottenuti sul videocomposito, che è il caso più significativo,riducendo gli assi del tempo e della qualità a valorisignificativi per il caso d'uso definito nel progetto. In questo modo, i metodi che impiegano untempo totale di codifica e decodifica eccessivo, oppure che mostrano una qualità troppo bassa,non vengono neanche considerati. Nella figura seguente sono riportati i grafici:
Il primo grafico indica il rapporto di compressione ottenuto al variare del tempo totale dicodifica e decodifica dei metodi compound, mentre nel secondo è indicata la qualità visivamisurata tramite l’MSSIM. Poiché i due assi del tempo coincidono, è possibile notare che i risultatidi uno stesso codec risultano allineati. I casi più interessanti sono stati evidenziati.
Il metodo che ottiene il rapporto di compressione maggiore è evidenziato in rosso, e indica ilmetodo a strati applicato utilizzando Zrle come codec per le aree di testo e H264 per le aree diimmagini. Questo metodo permette di codificare in maniera lossless le zone di testo, chetipicamente sono le zone in cui è richiesta una qualità maggiore, mantenendo comunque alta laqualità su immagini naturali e zone a gradiente continuo grazie al codec H264, il quale permetteoltretutto di comprimere notevolmente l’immagine composita. Tali risultati si accompagnano peròad un tempo di compressione e decompressione di circa 180 ms, troppo elevato per
42
Figura 28: Capacità di compressione, MSSIM e tempo totale di codifica/decodifica
Progetto 3D CloudWiz | ATI NICE - DIEE
un’applicazione di remote desktop.
In verde è indicato il metodo ibrido applicato usando il codec H264 per il testo e TurboJpeg perle immagini. Questo metodo ottiene dei tempi meno elevati del metodo precedentementedescritto grazie alle prestazioni del codec TurboJpeg, ed una qualità superiore, al prezzo di unanotevole riduzione del rapporto di compressione.
Sono invece evidenziate in giallo diverse combinazioni di qualità del metodo a blocchi applicatoutilizzando LZO per le aree di testo e TurboJpeg per le aree contenenti immagini. Come nel casoprecedente, le aree di testo vengono codificate in maniera lossless, mentre le aree a gradiente piùcontinuo sono codificate tramite il TurboJpeg. Questo metodo, sebbene offra un tempo di codificae decodifica estremamente rapido e una qualità altissima, non permette di comprimeresufficientemente l’immagine. Questo metodo è quindi adatto a situazioni in cui la bandadisponibile è estremamente elevata.
Infine in verde è indicato il metodo che offre il compromesso migliore: ovvero il metodo a stratiche utilizza i codec Zrle e TurboJpeg. Questo metodo offre una qualità nettamente inferiore aglialtri metodi, seppur sufficiente dal punto di vista percettivo, ma permette di ottenere un buonrapporto di compressione in un tempo accettabile di compressione e decompressione.
43
Progetto 3D CloudWiz | ATI NICE - DIEE
ConclusioniIn conclusione, può essere detto che i metodi compound offrono la possibilità di comprimere
selettivamente determinate aree di un’immagine, permettendo quindi l’utilizzo di un codec rapidoper le zone in cui la qualità visiva risulta essere meno importante, e un codec più preciso in zone incui è determinante mantenere alta la qualità. Essi vanno però paragonati con i risultati ottenutidall’analisi dei codec singoli. Nella seguente figura sono riportati due grafici contenenti alcunirisultati ottenuti dai codec standard sul medesimo video in cui sono stati testati i metodicompound.
44
Figura 29: Capacità di compressione, MSSIM e tempo totale di codifica/decodifica
Progetto 3D CloudWiz | ATI NICE - DIEE
Nei grafici sono indicati il rapporto di compressione e la qualità misurata tramite l’MSSIMrispetto al tempo impiegato per compiere la codifica e decodifica. Sono riportati solo i codec cherientrano in un tempo minore di 100 msec che consentono di ottenere un parametro di qualitàmaggiore dell’80% se misurato tramite MSSIM.
Si può notare che i codec TurboJpeg e H264 presentano delle performance generalmentemigliori dei metodi compound. Il codec H264 permette infatti di effettuare una codifica edecodifica in tempi minori di 100 ms, mantenendo un livello di compressione fra le 40 e 50 volteed una qualità elevata, corrispondente a un risultato di 95% di MSSIM. Il codec TurboJpeg invecepermette di ottenere dei tempi di compressione e decompressione estremamente rapidi e unaqualità elevata al prezzo di una minore capacità di compressione.
Utilizzare un metodo di classificazione e compressione compound porta conseguentemente aiseguenti svantaggi:
Tempi di codifica e decodifica appesantiti a causa del tempo di classificazione ed eventualericostruzione dell’immagine
Rapporto di compressione diminuito a causa della necessità di effettuare diversecompressioni per aree contenenti testo ed aree contenenti immagini naturali
45
Pattern Recognition and Applications LabDIEE - Università di Cagliari
R2.3DATASET PER LA VALIDAZIONE DEGLI ALGORITMI DI
COMPRESSIONE
Progetto 3D CloudWiz
Progetto 3D CloudWiz | ATI NICE - DIEE
SommarioSommario..............................................................................................................................................i
Obiettivo del documento......................................................................................................................1
Descrizione dei dataset.........................................................................................................................1
i
Progetto 3D CloudWiz | ATI NICE - DIEE
Obiettivo del documentoIn questo documento verranno descritti i dataset che sono stati generati per rappresentare il
contesto operativo e che sono stati utilizzati nella fase di test degli algoritmi.
Descrizione dei datasetPer testare le performance dei codec e dei metodi di compressione specifici per immagini
composite è stato realizzato un dataset composto da video diversi fra loro rappresentanti contesti
operativi differenti.
I contesti operativi individuati rappresentano una possibile modalità di interazione di un utente
durante una sessione desktop e sono stati suddivisi in tre categorie per ciascuna delle quali è stato
creato un video specifico:
• Testo: In questo caso il contesto operativo è quello di un utilizzo del sistema principalmente
per text editing e/o lettura di documenti prettamente testuale;
• Immagini: In questo caso il contesto operativo è quello di visualizzazione di immagini
naturali;
• Compound: In questo caso il contesto operativo è quello di un utilizzo del sistema nel quale
vengono visualizzati sia immagini/video che documenti testuali.
Il primo video mostra due documenti di testo. La motivazione della creazione di un simile video è
la necessità di valutare i singoli codec ed i metodi compound su immagini composte
prevalentemente da testo. Nel caso in cui i risultati forniti evidenziassero la presenza di un codec o
un metodo performante in maniera eccezionale su immagini simili, sarebbe possibile effettuare un
controllo della percentuale dello schermo occupata da testo, e nel caso in cui essa fosse maggiore
di una certa soglia, si potrebbe utilizzare direttamente il suddetto codec o metodo. Nel video,
inoltre, i due documenti di testo vengono rapidamente scorsi al fine di testare le capacità dei codec
su testi in movimento, che presentano quindi sfocature temporanee.
Il secondo video realizzato è invece composto nella sua totalità da immagini naturali, trattandosi di
un trailer cinematografico. Tale video è stato utilizzato per testare le capacità dei codec su
1
Progetto 3D CloudWiz | ATI NICE - DIEE
immagini composte da un gran numero di colori a variazione prevalentemente continua. I risultati
ottenuti dai codec su questo filmato possono essere utilizzati per definire il codec di scelta per le
sezioni contenenti immagini naturali in un’immagine composita.
A differenza dei primi due video, il terzo presenta sia aree di testo che aree contenenti immagini
naturali o immagini grafiche, ovvero un video composito. Il video composito utilizzato è suddiviso
principalmente in tre aree:
• una zona in cui viene riprodotto un video;
• una zona dove è presente un editor di testo;
• una zona dove è presente un terminale dei comandi nel quale viene simulato l'inserimento
di comandi e viene effettuato lo scroll in modo da testare la codifica di testi in movimento
come nel caso del primo video.
Ciò permetterà principalmente di testare i metodi compound su delle immagini molto vicine al
caso di studio richiesto in base ai tempi, il rapporto di compressione e la qualità dell’immagine in
uscita, ma anche sul tempo necessario affinché avvenga la classificazione dei blocchi o degli strati e
sulla precisione stessa della classificazione, misurabile grazie ad un’immagine precedentemente
etichettata. Tali risultati sono riportati nella sezione in cui vengono descritti i metodi compound
applicati.
In conclusione, i risultati ottenuti dai primi due video sono particolarmente utili al fine di
selezionare i codec più adatti a codificare aree contenenti una tipologia specifica di immagini,
mentre il terzo video permette di testare più a fondo i metodi compound, su immagini tipiche del
caso di studio.
Nella seguente tabella sono riportate le caratteristiche dei video utilizzati:
Video Testo Video Immagini Video Composito
Numero Frames 700 700 700
Grandezza Frame 1366 x 682 1366 x 682 1366 x 682
2
Progetto 3D CloudWiz | ATI NICE - DIEE
Tabella 1 - Caratteristiche dei video.
Nella seguente figura sono riportati tre frame dei video utilizzati come dataset:
3
Progetto 3D CloudWiz | ATI NICE - DIEE
Figura 1 - In alto una snapshot del video contenente testo, al centro una snapshot del video contenente immagininaturali e in basso una snapshot del video composito.
4
Pattern Recognition and Applications LabDIEE - Università di Cagliari
R2.4MODELLO ARCHITETTURALE DI UN SISTEMA DI
COMPRESSIONE ADATTATIVA, SISTEMA DI DECISIONE PER
LA SELEZIONE DINAMICA DELL'ALGORITMO DI
COMPRESSIONE E PROTOCOLLO DI COMUNICAZIONE TRA
CLIENT E SERVER
Progetto 3D CloudWiz
Progetto 3D CloudWiz | ATI NICE - DIEE
SommarioSommario..............................................................................................................................................i
Obiettivo del documento......................................................................................................................1
Stato dell'arte sulla stima della banda disponibile in una connessione punto-punto............................2
Alcune definizioni fondamentali......................................................................................................3
Un secondo più accurato modello del sistema di trasmissione........................................................4
Alcune considerazioni preliminari e nuove definizioni....................................................................6
Capacità........................................................................................................................................7
Banda disponibile.......................................................................................................................10
Tipologie di traffico sulla rete....................................................................................................12
Tecniche di stima della banda.........................................................................................................12
Tecniche attive............................................................................................................................13
Tools...............................................................................................................................................24
Tool per la stima della capacità degli hop..................................................................................24
Tool per la stima della capacità di un collegamento punto-punto..............................................25
Tool per la stima della banda disponibile...................................................................................25
Qualche25 confronto..................................................................................................................26
Conclusioni.....................................................................................................................................28
Appendice A: Problematiche legate alle reti wireless....................................................................28
Rilevamento delle collisioni (CSMA/CD vs CSMA/CA)..........................................................28
MAC layer retries.......................................................................................................................30
Algoritmi di controllo della frequenza.......................................................................................30
Bibliografia.....................................................................................................................................31
Progettazione dell'architettura del sistema adattativo.........................................................................38
Specifiche implementative.............................................................................................................40
i
Progetto 3D CloudWiz | ATI NICE - DIEE
Obiettivo del documentoScopo di questo documento è quello di delineare un modello architetturale di un sistema di
compressione adattativa, ovvero un sistema di decisione per la selezione dinamica dell'algoritmo di
compressione e protocollo di comunicazione tra client e server.
Per fare questo nel documento si procederà da prima ad illustrare lo stato dell'arte relativo alla
stima della banda disponibile in una connessione punto-punto. In base all'analisi di questo stato
dell'arte ed ai risultati illustrati nella relazione R2.2 si procederà alla progettazione di un sistema di
decisione adattativo che consenta di adattarsi al contesto operativo anche in funzione di un
protocollo di comunicazione fra client e server.
1
Progetto 3D CloudWiz | ATI NICE - DIEE
Stato dell'arte sulla stima della banda disponibile in una connessione punto-punto
Le reti a commutazione di pacchetto1 (Packet Switching Networks), sono strutture molto complesse e
raramente sono interamente sotto il controllo di un'unica organizzazione; più spesso sono
costituite dall'insieme di tante sottoreti gestite da organizzazioni ed aziende diverse2. Per
mascherare e rendere gestibile tale complessità vengono spesso caratterizzate attraverso pochi
indicatori, i più comuni dei quali sono banda, latenza e capacità di trasmissione (throughput).
Sin dalla loro nascita si è sentita l'esigenza di misurare la velocità di trasferimento delle
informazioni da un punto ad un altro della rete e di stimare i limiti della rete in tal senso imposti
dagli apparati fisici e/o dalle condizioni operative.
Da un lato gli utenti (intesi come sviluppatori software) sentivano l'esigenza di poter stimare la
banda disponibile per ottimizzare il trasferimento dei dati, dall'altro i gestori delle reti sentivano
tale esigenza per poter ottimizzare l'organizzazione del traffico sulla rete (network routing planning) e
migliorare la qualità del servizio offerto ai propri clienti. Ed anche in ambito di ricerca questa
esigenza era ed è fortemente sentita sia da parte degli ingegneri che devono progettare i protocolli
di comunicazione (network protocols design), sia da quelli che devono progettare e dimensionare gli
apparati fisici che costituiscono le reti (capacity planning).
Questa varietà di soggetti si traduce in una molteplicità di obiettivi e di approcci al problema,
ognuno con un proprio punto di vista e spesso con un gergo specifico che porta ad un'ambiguità
nel linguaggio utilizzato per descriverne le carattersitiche.
Consideriamo ad esempio il termine banda :
• se riferito ad apparati fisici prende il suo significato dall'elettromagnetismo ed indica un
intervallo di frequenze nello spettro elettromagnetico;
• se riferito alla teoria dell'informazione diventa sinonimo di bitrate, ed indica il numero di bit
che un canale può trasportare per unità di tempo;
• se riferito alle reti a commutazione di pacchetto indica la capacità di trasferire senza
1Delle quali Internet è la più nota.2Ad esempio un Internet Service Provider.
2
Progetto 3D CloudWiz | ATI NICE - DIEE
alterazioni una determinata quantità di dati per unità di tempo3.
E' dunque fondamentale definire con precisione
• il punto di vista da cui si osserva il problema;
• l'obiettivo che ci si prefigge;
• ed il significato che si attribuisce ai termini di utilizzo comune:
in questo documento si analizzerà il problema della stima della banda disponibile
dal punto di vista di un utilizzatore della rete che vede la rete come una scatola nera,
che non ha accesso ai dettagli, alle configurazioni e ai protocolli presenti negli apparati interni,
e che può solo osservarne il comportamento ai morsetti d'ingresso e di uscita.
Nella prima parte del documento, attraverso l'illustrazione di alcuni semplici modelli teorici,
verranno definiti con buona precisione i significati dei termini che verranno utilizzati, e verranno
illustrati alcuni assunti di base necessari per capire il funzionamento degli tecniche presentate.
Verranno tuttavia omesse tutte le tecniche che prevedono interventi sugli apparati fisici4,
modifiche ai protocolli esistenti5, l'introduzione di nuovi protocolli o modifiche all'organizzazione
della infrastruttura di distribuzione (Internet Service Provider) perché risulterebbero al di fuori delle
possibilità di intervento dell'utente finale.
Come anticipato cerchiamo di dare una definizione più precisa ed utile di alcuni termini come
connessione, canale, capacità, banda disponibile e via dicendo.
Per farlo partiremo da un modello teorico molto semplice che ci consentirà di introdurre
facilmente ed in maniera intuitiva alcune importanti nozioni, successivamente usemo un modello
lievemente più complesso per poter essere più precisi in alcune definizioni.
Alcune definizioni fondamentaliIn prima approssimazione possiamo rappresentare una connessione punto-punto come un sistema
composto da tre elementi
3Spesso indicato anche come bitrate, ovvero numero di bit al secondo.4Ad esempio sull'organizzazione delle antenne di una rete wireless, o su particolari soluzioni hardware da installarenegli apparati di un internet service provider o sulle schede di rete di un dispositivo.5Ad esempio l'introduzione di nuovi campi negli header di un protocollo, o di nuovi messaggi in un protocollo esistenteo delle variazioni nella sequenza e nella frequenza con cui due host si scambiano dei messaggi sia a livello fisico che diprotocollo (es. modifiche dello standard IEEE 82.11 WiFi ).
3
Progetto 3D CloudWiz | ATI NICE - DIEE
• una sorgente che trasmette dei dati
• un canale che li trasporta
• una destinazione che li riceve
La semplicità di questo modello ci consente di concentrarci sulla definizione di alcuni concetti
fondamentali come il concetto di canale e di alcune delle sue principali caratteristiche.
Nella teoria dell'informazione, e nella conseguente teoria delle telecomunicazioni, con canale6 si
indica un mezzo di trasmissione in grado di far propagare delle onde di energia da un punto dello spazio ad
un altro punto7.
Ogni canale è caratterizzato da una certa capacità, che indica il limite superiore alla quantità di
informazioni che possono essere trasmesse su di esso e che, in base alla teoria dell'informazione, può
anche definirsi come il numero di bit che possono essere trasmessi per unità di tempo.
Nel seguito del documento ci atterremo a questa seconda definizione e indicheremo la banda
disponibile come la differenza tra la capacità del canale e la banda occupata in un dato istante , ovvero il
numero ulteriore di bit che possono essere trasmessi sul canale per unità di tempo senza saturarne la
capacità.
Fatte queste precisazioni possiamo definire con più esattezza l'obiettivo di questo documento
dicendo che stimare la banda disponibile significa stimare la quantità di ulteriori informazioni che si
possono trasmettere efficacemente sul canale senza degradare le comunicazioni esistenti.
Un secondo più accurato modello del sistema di trasmissioneIn realtà possiamo rilassare alcuni assunti sul modello adottato e considerare il canale non come
ad una black-box ma come ad una gray-box, ovvero una scatola all'interno della quale possiamo
sbirciare per vedere alcune componenti (ma non tutte).6Secondo questo modello e secondo il punto di vista adottato, il canale rappresenta infatti la connessione punto-puntotra client e server, ovvero l'intera infrastruttura hardware e software che inizia nell'interfaccia di rete del server e finiscesull'interfaccia di rete del client (internet compresa).7Nel caso di onde elettromagnetiche, anche il vuoto (ovvero l'assenza di un mezzo fisico) consente la propagazione delleonde e dunque costituisce un canale valido.
4
Progetto 3D CloudWiz | ATI NICE - DIEE
Sappiamo infatti che la gray-box è una rete a commutazione di pacchetto quindi, pur non potendo
alterarne la struttura e/o le impostazioni, possiamo definire meglio il modello di riferimento ed
essere più precisi nella definizione dei concetti fondamentali.
Questo
La prima osservazione che si può fare è legata alla suddivisione dell'infrastruttura di networking in
diversi livelli funzionali (layer), ognuno dei quali con compiti e scopi ben precisi.
Gli obiettivi di questo documento ci consentono di concentrarci sui livelli8 più bassi di questa
infrastruttura, ed in particolare :
• il livello 1 (physical layer) in cui troviamo i mezzi fisici di connessione tra apparati, e che
comprende inoltre tutte le procedure ed i protocolli necessari a garantire che un
segnale elettromagnetico possa arrivare da un apparato ad un altro;
• il livello 2 (data-link layer) che aggiunge al precedente tutti i sistemi di controllo del
flusso di segnale e di correzione dell'errore necessari a garantire una connessione
affidabile; la connessione è indicata con il termine di link, i suoi capi prendono il nome
di nodi;
• il livello 3 (network layer) che introduce il concetto di rete come insieme di nodi
interconnessi da mezzi fisici, fornisce ad ogni nodo un indirizzo univoco e tutte le
funzionalità necessarie per trovare il percorso migliore9 (routing) per arrivare da un
nodo all'altro e per trasferire sequenze di dati di lunghezza variabile (datagrams); a
questo livello il trasporto dei dati è considerato ancora inaffidabile;
• il livello 4 (transport layer) che introduce i principali protocolli di trasporto10 che
definiscono le regole per un trasporto affidabile dei pacchetti da un nodo ad un altro.
Sfruttando questa suddivisione in livelli e focalizzando l'attenzione sul livello 3, possiamo pensare
ad una connessione punto-punto come ad una sequenza di nodi collegati tra loro, in cui ogni
8Nella numerazione dei livelli si farà riferimento al modello ISO/OSI perché suddivide i livelli in base ad allefunzionalità logiche. Tuttavia nella pratica si fa spesso riferimento al modello detto TCP/IP (che deve il suo nome aiprincipali protocolli utilizzati) perché suddivide i livelli in base alle funzionalità implementative. I due modelli sono difatto equivalenti.9Il protocollo IP (Internet Protocol).10I due principali protocolli di trasporto sono il TCP (Transmission Control Protocol) che instaura una connessionestabile tra i due capi (connection-oriented) e l'UDP (User Datagram Protocol) che invece non necessita di unaconnessione stabile (connectionless).
5
Progetto 3D CloudWiz | ATI NICE - DIEE
collegamento viene indicato con il termine hop e rappresenta un collegamento logico, ovvero un
numero arbitrario di link tra apparati di livello 2.
Alcune considerazioni preliminari e nuove definizioniPer definizione nelle reti a commutazione di pacchetto i dati non vengono inviati come un unico
blocco monolitico, bensì che vengano suddivisi in piccoli blocchi inviati singolarmente11 e solo a
destinazione questi vengono ricombinati per ricostruire i dati originali.
Nel suo percorso ciascun pacchetto deve inoltre attraversare i livelli logici illustrati
precedentemente, dall'alto verso il basso in uscita dalla sorgente e dal basso verso l'alto in ingresso
verso la destinazione. Ad ogni passaggio di livello verso il basso ai dati provenienti dal livello
superiore viene aggiunto un header all'inizio e, opzionalmente, un footer in coda contenenti
informazioni necessarie al protocollo in uso e per l'adempimento delle funzionalità previste dal
livello che si sta attraversando.
Ad esempio al livello 3 verranno aggiunti gli indirizzi IP della macchina sorgente e di quella di
destinazione mentre al livello 2 i MAC-Address delle schede di rete e i codici per il controllo
dell'errore. Tali informazioni verranno utilizzate dall'infrastruttura di network (la gray-box) per
poter instradare e consegnare il pacchetto a destinazione, dove verranno estratte durante la
risalita dei livelli consegnando all'applicazione di destinazione i soli dati inviati dalla sorgente.
11Ogni pacchetto può seguire un percorso diverso da quello degli altri.
6
Node Node NodeHOP
Link
Progetto 3D CloudWiz | ATI NICE - DIEE
Questo processo di incapsulamento dei pacchetti è quello che garantisce la grande flessibilità delle
reti a commutazione di pacchetto ma ha delle conseguenze dirette su alcune delle grandezze di
interesse per il problema in esame.
CapacitàLa banda di un link (livello 1) è legata alla capacità tipica del mezzo fisico che lo costituisce (cavi in
rame, fibre ottiche, aria, vuoto, ....) e/o alle caratteristiche hardware dei trasmettitori/ricevitori
elettronici o ottici e come tale non può essre modificata.
Il processo di incapsulamento prevede, ad ogni attraversamento di livello, l'aggiunta di un header e
di un footer ai dati provenienti dai livelli superiori; riportiamo di seguito la struttura degli header IP
ed Ethernet II aggiunti rispettivamente nell'attraversamento dei livelli 3 e 2:
E' quindi naturale che, essendo fissato il numero massimo di bit per secondo che può attraversare
link fisico, l'aggiunta di nuovi bit si traduca in una riduzione del numero di bit utili12 per secondo che
possono attraversare il link e della banda apparente vista dai livelli superiori.
12I bit di interesse per l'applicazione e l'utente.
7
Illustrazione 1: Incapsulamento al livello 3 - Header IP
Illustrazione 2: Incaspsulamento al livello 2: Header Ethernet II
Progetto 3D CloudWiz | ATI NICE - DIEE
Dunque, salendo di un livello logico13, la banda di un hop risulta inferiore rispetto a quella
nominale dei link che lo compongono. Inoltre le dimensioni degli header e dei footer sono
determinate dai particolari protocolli in uso e dunque fuori dal controllo di un utente che vede
l'infrastruttura di rete come una gray-box.
Proviamo a stimare la differenza di capacità percepita al livello 3 rispetto alla capacità nominale di
un link fisico dovuta all'utilizzo dell'incapsulamento di tipico del frame Ethernet II.
Se indichiamo con
• L3 la lunghezza di un pacchetto proveniente dal livello 3;
• H 2 la dimensione dell'header introdotto al livello 2;
• C2 la capacità al livello 2
possiamo stimare che il tempo necessario per trasmettere il pacchetto proveniente dal livello 3
tenuto conto dell'overhead dovuto all'incapsulamento sarà:
T L3=LL3+H L2
C L2
e dunque la capacità percepita al livello 3 sarà :
CL3=C L21
1+H L2
LL3
che evidenzia come la “riduzione” di capacità sia proporzionale al rapporto tra la dimensione
dell'header e la dimensione dei dati provenienti dal livello superiore( nel nostro caso la lunghezza14
del pacchetto IP).
Facciamo qualche esempio numerico.
L'overhead del framing di tipo Ethernet II è di 26 byte. Se consideriamo un link da 10 Mb/sec e
pacchetti IP di dimensione di 100 bytes otteniamo :
13Al livello 2 un blocco di dati viene indicato con il termine frame mentre al livello 3 si usa il termine packet.14Tale lunghezza non è fissata a priori da nessuno standard, ma viene solitamente concordata tra gli apparati perottimizzare l'utilizzo del link. Il protocollo IP ha un parametro, detto maximum transmission unit o MTU chedefinisce la dimensione massima dei pacchetti che possono essere inviati in un dato link. Il valore minimo di questovalore è intorno ai 100 byte, mentre il valore massimo dipende dal tipo di mezzo che costituisce il link fisico, il valoredi default di questo valore è pari a 1500 bytes.
8
Progetto 3D CloudWiz | ATI NICE - DIEE
C100b=10∗1
1+26100
Mb / s=7,94Mb/ s
con una perdita netta superiore al 20%; tuttavia utilizzando il valore tipico della dimensione dei
pacchetti IP pari a 1500 bytes, otteniamo
C1500b=10∗1
1+261500
Mb/ s=9,83Mb / s
con una riduzione della capacità inferiore al 2%.
Sulla base di queste osservazioni possiamo dare una definizione operativa della capacità C di un
hop come
il bit-rate, misurato al livello IP15, con cui un hop
può trasferire dei pacchetti IP di dimensione pari al MTU.
In una connessione punto-punto ogni hop avrà una sua capacità Ci , dunque l'hop con la
capacità minima costituirà un collo di bottiglia e determinerà la capacità dell'intera connessione :
C path= mini=1,… ,H
Ci
In altri termini
stimare la capacità di una connessione punto-punto significa
stimare la capacità dell'hop che opera da collo di bottiglia,
ovvero quello a capacità minima.
15E' importante ricordarsi che questa misura è fatta a livello IP e dunque tiene conto solo dell'overhead del framingEthernet II (o comunque di livello 2), salendo di un ulteriore livello logico (ad esempio a livello TCP) dovremmoconsiderare anche l'overhead legato all'incapsulamento di protocollo IP.
9
Progetto 3D CloudWiz | ATI NICE - DIEE
Banda disponibileInizialmente abbiamo definito la banda disponibile come la misura della porzione di capacità di un link
non ancora utilizzata. Una prima conseguenza di questa definizione è che la banda disponibile
dipende dalla quantità di pacchetti che attraversano il link istante per istante e dunque è un
parametro che varia nel tempo.
Per illustrare meglio questo aspetto facciamo alcune osservazioni assiomatiche.
Oss. 1: Il link è un mezzo fisico.
E' bene ricordare che un link è un mezzo fisico (filo di rame, fibra ottica, aria) che collega due
apparati e come tale in ogni istante può trovarsi solo in uno di due stati (che per praticità possiamo
modellare con i valori binari 0 e 1 ):
• inattivo : nessun segnale fisico lo attraversa;
• in trasmissione : un segnalo lo attraversa alla massima velocità possibile consentita dalla
natura del mezzo.
In altri termini, a livello fisico e in un particolare istante, la banda disponibile è pari alla capacità del
mezzo fisico oppure è nulla.
E' naturale che senza ulteriori precisazioni la banda disponibile risulta un parametro di scarso
interesse; per renderla più interessante ed utile occorre ragionare in termini statistici e
considerarla
la differenza tra la capacità e l'utilizzo medio del canale in un intervallo di tempo significativo:
u(t−τ ,t ) =1τ ∫t−τ
tu(x )dx
Ad esempio, facendo riferimento al grafico a
lato che riporta un utilizzo ipotetico per un
intervallo T pari a 20 istanti di tempo, il
calcolo del tempo medio di utilizzo risulta
ui=0.4 → BD=1−0.4=0.6
10
0
0,2
0,4
0,6
0,8
1
1,2
Utilizzo di un link in un periodo T
Tempo
Util
izzo
Progetto 3D CloudWiz | ATI NICE - DIEE
Estendendo questo ragionamento ad un Hop (sequenza di link) e ad un collegamento (sequenza di
Hop) avremo che la banda disponibile per l'intero collegamento sarà determinata dal link con
banda disponibile minore (ovvero il collo di bottiglia dell'intero collegamento)
BDi=(1−ui)C i → BD path= min1, … , H
BDi
Oss. 2: il collo di bottiglia di un collegamento può variare istante per istante
Ovvero, poiché la banda disponibile su ciascun link dipende dal traffico presente in un dato
periodo sul link stesso e poiché tale traffico non è costante, anche la posizione del collo di bottiglia
sul collegamento può variare nel tempo16.
Per illustrare meglio questo concetto possiamo paragonare il collegamento punto-punto ad una
sequenza di tubi di una condotta idrica:
Questa estrema variabilità renderebbe il problema della stima della banda disponibile
impraticabile, per tale ragione tutti gli algoritmi partono dall'assunto che
il traffico si mantenga stazionario sui singoli link/hop almeno per tutta la durata della misura.
Dunque l'attendibilità della stima fornita dai vari algoritmi sarà tanto maggiore quanto minore sarà
il tempo di stima. L'ipotesi di stazionarietà del traffico è infatti ragionevole per brevi intervalli di
tempo (nell'ordine di qualche secondo) ma perde progressivamente di validità all'estendersi
dell'intervallo di osservazione.
16In linea teorica il link che costituisce il collo di bottiglia di un collegamento potrebbe variare ad ogni intervallo T.
11
Disegno 1: Capacità Nominale e Banda Disponibile: Non esiste una correlazione diretta tra queste due grandezze,bensì la banda disponibile è una quantità che varia nel tempo in funzione del traffico sui singoli hop. Nel grafico il
tratto 1 è quello a capacità nominale minore, ma il collo di bottiglia corrisponde al tratto 3 a causa del maggiortraffico che lo attraversa.
C1 C3A1C2 A2 A3
Progetto 3D CloudWiz | ATI NICE - DIEE
Tipologie di traffico sulla reteE' importante suddividere il traffico presente sulla rete in diverse tipologie perché, come vedremo
in seguito, alcune tipologie di traffico possono avere un impatto diretto e significativo sulle misure
e quindi sull'affidabilità delle tecniche che verranno illustrate.
In particolare sono tre le principali tipologie di traffico di interesse per la stima della banda
disponibile:
• probing traffic : i pacchetti inviati sulla connessione per stimarne le caratteristiche
fondamentali;
• crossing traffic : i pacchetti che attraversano uno o più link nella stessa direzione del probing
traffic;
• contending traffic : i pacchetti che attraversano uno o più link in direzione opposta a quella
del probing traffic.
Queste tipologie di traffico sono illustrate nella figura seguente
Tecniche di stima della bandaLe tecniche attualmente disponibili per la stima della banda sono tutte accomunate dal fatto di
inviare sulla rete dei pacchetti di dati nella rete per sondarne le caratteristiche.
Tuttavia l'avvento delle reti wireless ha evidenziato alcuni limiti di queste tecniche e del modello su
cui si basavano ed ha dato vita ad un nuovo filone di ricerca.
Questo a sua volta ha portato ad una prima suddivisione logica delle teorie di misura in due grandi
famiglie:
• le tecniche attive, caratterizzate dall'immissione di pacchetti nel collegamento e basate
su un modello teorico creato per le reti cablate (e che si sta cercando di adattare alle
12
Progetto 3D CloudWiz | ATI NICE - DIEE
reti wireless e mobile);
• le tecniche passive, che si limitano a monitorare il traffico in ingresso/uscita su uno o
più nodi e che sono alla ricerca di un nuovo modello che ben si adatti anche alle nuove
tipologie di rete .
Al momento, la ricerca sulle tecniche passive di misura non è ancora arrivata al punto di avere un
unico ed efficace modello di riferimento e, conseguentemente, ad avere almeno un algoritmo di
riferimento. Sono diverse le idee promettenti legate, ad esempio, a modifiche sull'infrastruttura
fisica, a modifiche dei protocolli esistenti e/o all'introduzione di nuovi protocolli; ma nessuna ha
ancora raggiunto una maturità ed un'affidabilità tale da diventare un punto di riferimento17.
Quindi non essendo disponibili soluzioni passive implementabili ed utilizzabili dall'utente finale,
concentreremo la nostra attenzione sulle tecniche attive di misura.
Tecniche attiveLe tecniche attive si basano sull'invio di pacchetti da un estremo all'altro del collegamento e si
differenziano tra loro sia per il numero di pacchetti che per la modalità con cui questi vengono
inviati.
Le prime tecniche attive sono nate con la nascita di internet e si sono evolute in simbiosi con
l'evoluzione degli apparati fisici che ne costituivano l'infrastruttura. E' accaduto spesso che le
misure evidenziate da una tecnica suggerissero migliorie sull'hardware o sui protocolli e che,
successivamente, l'attuazione di tali migliorie abbia richiesto un'evoluzione delle tecniche di
misura o l'introduzione di una nuove tipologie di misura.
Per tale ragione nel proporre le principali tecniche cercheremo di seguire un'ordine
logico/cronologico che evidenzi le evoluzioni che ciascuna di esse ha introdotto.
Ricordiamo che alla base di tutte le tecniche c'è l'assunto che:
17La maggior parte di esse è stata sviluppata solo attraverso simulazioni teoriche ma non è stata testata su apparati realio su larga scala, ad esempio una di esse (iBE = intelligent Bandwidth Estimation) si basa sulla coppia di messaggiRTS/CTS (Ready to Send, Clear To Send) previsti dallo standard IEEE 802.11. Secondo quanto previsto ciascunapparato prima di mandare un pacchetto dovrebbe segnalare la sua intenzione con un messaggio RTS, cui deve seguireuna conferma da parte della destinazione attraverso il messaggio CTS. Nel frattempo tutti gli altri dispositividovrebbero interrompere le trasmissioni per evitare conflitti. Tuttavia è stato dimostrato che l'uso di questi messaggidegrada le performance dell'intero sistema e dunque sono stati declassati a “configurazione opzionale” e disabilitati perdefault in tutti i dispositivi. Questo rende di fatto inutilizzabile l'algoritmo citato. In un altro caso l'algoritmo si basa suuna modifica ad un driver open-source per una scheda di rete wireless il cui utilizzo e funzionamento non mai andatooltre il semplice test effettuato per la pubblicazione esaminata.
13
Progetto 3D CloudWiz | ATI NICE - DIEE
durante il tempo di misura la capacità fisica, il traffico (e dunque la banda disponibile)
in tutti i link del collegamento si mantengano costanti.
Invio di pacchetti di lunghezza variabile (VPS)
Questa fu una delle prime tecniche18 per la misura della capacità e della latenza di ogni hop lungo
tutto il collegamento. Sfruttando una profonda conoscenza dei protocolli, utilizza in modo originale
il campo TTL (Time To Live) dell'header di un pacchetto IP per acquisire le informazioni desiderate.
Il campo TTL indica il numero massimo di hop che un pacchetto può attraversare e ad ogni
attraversamento viene decrementato, quando raggiunge lo zero il pacchetto viene scartato19. Il
protocollo IP prevede che il router che scarta un pacchetto deve segnalare l'evento al mittente
inviando un messaggio di notifica (ICMP Time-Exceeded).
L'idea è quella di calcolare il RTT (Round Trip Time) forzando questo meccanismo attraverso l'invio
nella rete di pacchetti con un TTL crescente (da 1 a N); in questo modo l'n-esimo router nel
percorso sarà costretto a scartare il pacchetto e ad indentificarsi mandando il messaggio di
notifica.
Le principali componenti temporali del RTT (in entrambe le direzioni) sono tre:
• il tempo di serializzazione, cioé il tempo richiesto per trasferire un pacchetto di
lunghezza L da un link di capacità C e può essere indicato con L/C;
• il tempo di propagazione, è il tempo richiesto ad ogni bit del pacchetto per attraversare
il link ed è indipendente dalle dimensioni del pacchetto;
• il tempo di attesa in coda, misura il tempo che un pacchetto può restare fermo in un
buffer di un router o di uno switch.
Per stimare questi parametri ad ogni dispositivo di livello 3 (router) lungo il percorso vengono
inviati più pacchetti della stessa dimensione assumendo che almeno uno di essi20 non subisca alcun
ritardo dovuto a problemi di accodamento.
Con questo assunto nel minimo degli RTT misurati si potranno considerare solo le due componenti18Uno tra i primi a proporre questa tecnica ed una sua implementazione (pathchar) fu Van Jacobson autore, tra le altrecose, della prima versione del tool traceroute,ancora oggi disponibile su tutti i sistemi linux/unix e Windows.19Questo campo è stato introdotto nell'header dei pacchetti IP per evitare che se in una rete si dovesse creare un loop unpacchetto possa restare indefinitamente in circolo, ad esempio per un guasto o un errore di configurazione.sovraccaricando gli apparati e degradando le performance generali.20Si assume inoltre che il pacchetto ICMP di risposta, essendo molto più piccolo degli altri, non subisca alcun ritardodovuto a code nel percorso di ritorno.
14
Progetto 3D CloudWiz | ATI NICE - DIEE
di propagazione e serializzazione; di cui
• la prima indipendente dalla dimensione del pacchetto e legata solo alla velocità di
propagazione dei segnali nei vari link
• e la seconda proporzionale alla lunghezza del pacchetto e dovuta alla serializzazione
dello stesso nei vari link.
In formule il minimo RTT per un pacchetto di dimensione L all'hop i-esimo può essere espresso
dalla formula:
T i (L) = α+∑k=1
i LC k
= α+βi L
dove
• C k è la capacità del k-esimo hop
• α è la componente di ritardo fino all'hop i-esimo che non dipende dalla dimensione
del pacchetto
• βi è la pendenza all'i-esimo hop del rapporto tra il minimo RTT e la dimensione del
pacchetto (vedi figura).
Dunque la misura del minimo RTT per ogni dimensione del pacchetto stima il termine βi per
tutti gli hop, da cui si può stimare la capacità dell'i-esimo hop attraverso la formula
C i =1
βi−βi−1
Questa tecnica può significativamente sottostimare la capacità del collegamento se lungo il
15
Progetto 3D CloudWiz | ATI NICE - DIEE
percorso i pacchetti devono attraversare dispositivi di tipo store-and-forward21 (ad esempio switch).
Dispersione di coppie/treni di pacchetti (PPTD)
Per superare i limiti legati all'invio di un solo pacchetto, si è passati all'invio di una coppia di
pacchetti, composta da due pacchetti di uguale dimensione leggermente distanziati nel tempo, con
l'obiettivo di misurare la variazione (tra sorgente e destinazione) della distanza temporale tra i due
pacchetti. E successivamente si è passati da una coppia pacchetti ad una serie di pacchetti, detta
treno di pacchetti.
L'idea alla base di questa tecnica è che tale variazione della distanza tra i due pacchetti sia
proporzionale alla capacità del tratto di percorso che opera come collo di bottiglia nel
collegamento. Questo concetto è illustrato qualitativamente nella figura seguente:
in cui l'asse orizzontale rappresenta il tempo e quello verticale la banda. Nel complesso è
raffigurato un collegamento composto da tre hop, in cui quello centrale ha una banda molto
inferiore agli altri due.
Ogni rettangolo in grigio rappresenta un pacchetto, la cui area (pari al numero di bit) non può
cambiare lungo l'intero percorso.
Durante l'attraversamento dell'hop centrale a banda stretta il pacchetto subirà uno
“schiacciamento” lungo l'asse verticale (banda) e quindi dovrà allargarsi orizzontalmente (nel
tempo) e, dualmente, arrivando nuovamente ad un hop a banda larga verrà “stirato” verticalmente
21La metodologia store-and-forward è una metologia di instradamento dei pacchetti che prevede che il primo bit di unpacchetto venga inviato solo dopo che l'ultimo bit sia stato ricevuto. In particolare se il dispositivo è uno switch questatecnica prevede che al frame conservato nel buffer venga applicata una verifica d'integrità, cosa che introduce in ognicaso una latenza che altera le stime VPS. Inoltre se tale verifica fallisce il frame viene scartato e lo switch (essendo undispositivo di livello 2) non genera il messaggio di notifica ICMP danneggiando ulteriormente le stime. Perapprofondimenti http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/white_paper_c11-465436.html
16
Illustrazione 3: Dispersione di una coppia di pacchetti che attraversa un collo di bottiglia
Progetto 3D CloudWiz | ATI NICE - DIEE
e subirà una compressione lungo l'asse orizzontale.
La spaziatura Pb tra i due pacchetti creata nel link a banda più stretta (collo di bottiglia) rimane
invariata22 anche quando i pacchetti raggiungono i link a banda più elevata, perciò la spaziatura tra
i pacchetti in ricezione sarà pari alla distanza nel link a banda più stretta: P r=Pb .
Possiamo schematizzare ciò che accade in ogni apparato in questo modo
ed indicare la dispersione tra due pacchetti di lunghezza L al termine di un link con capacità C
come
Δout = max(Δin ,LCi )
sotto l'assunto che in quel periodo temporale non ci sia altro traffico sul link.
In definitiva la dispersione della coppia di pacchetti al termine del collegamento sarà:
ΔR = maxi=0,…, H( L
C i) =L
mini=0,… ,H
Ci
=LC
→ C =LΔR
Tuttavia l'ipotesi di assenza di altro traffico sull'intero collegamento è piuttosto irrealistica e risulta
particolarmente rilevante la presenza di cross traffic che può condurre a:
• sottostimare la capacità, se i pacchetti estranei ritardano il secondo pacchetto e non il
primo, aumentando la dispersione di un valore superiore a L/C;
• sovrastimare la capacità, se i pacchetti estranei ritardano la propagazione, sul link
successivo al collo di bottiglia, del primo pacchetto e non quella del secondo.
22E' stato dimostrato che in questa situazione la rete “satura” e si comporta in maniera equivalente ad un sistema store-and-forward, ovvero non invia un pacchetto fino a che non sia stato completamente ricevuto.
17
Progetto 3D CloudWiz | ATI NICE - DIEE
Per cercare di limitare questi errori sono state proposte varie metodologie accessorie:
• l'uso di parametri statistici come la media o la mediana;
• l'uso di pacchetti di dimensione variabile;
• l'uso di distanze variabili tra pacchetti;
• l'uso della varianza tra i ritardi di diverse coppie di pacchetti;
• l'uso dei valori di picco della distanza tra pacchetti.
Treni di pacchetti
Una delle più naturali estensioni all'uso di una coppia di pacchetti è l'uso di un treno di pacchetti23, la
cui dispersione è definita come
la distanza temporale tra l'ultimo bit del primo pacchetto e l'ultimo bit dell'ultimo pacchetto.
Misurando la dispersione ΔR(N ) di un treno di N pacchetti di lunghezza L, si può stimare la
banda con la seguente equazione:
B =(N−1)LΔR(N )
che se non ci fosse cross traffic coinciderebbe con la capacità del canale.
In generale l'uso di un treno di pacchetti dovrebbe rendere più robusta la misura, tuttavia al
crescere della lunghezza del treno di pacchetti aumenta la probabilità che sia presente del cross
traffic durante la misura e quindi la probabilità di sottostima (anche significativa) della capacità del
collegamento.
Per avere una stima più precisa della banda utilizzando un treno di pacchetti è stato introdotto
l'operatore ADR (Asymptotic Dispersion Rate) che nel caso di un collegamento con un singolo hop
P {C 0 ,C 1} , C 0>C 1 , assume la seguente forma:
ADR Δ=
C 1
1−RC
C 0
⩽ C 1
23Un treno di pacchetti consente misure statistiche più accurate e si rende addirittura necessario se nel collegamentosono presenti dei multi-channel link, ovvero quando più link fisici sono accorpati per formare un unico link logico conuna banda maggiore.
18
Progetto 3D CloudWiz | ATI NICE - DIEE
dove C 0 , C1 sono le capacità dei due hop e RC è la quantità di cross-traffic che arriva sul
secondo link. Si possono notare alcune caratteristiche:
• la lunghezza del treno di pacchetti non influenza l'ADR (tuttavia ne limita la varianza);
• se RC>0 → ADR < C
• l'ADR non è legata alla banda disponibile ed anzi è più ampia: ADR > A = C 1−RC
Purtroppo l'ADR richiede la conoscenza del cross-traffic presente su tutti i link.
Stream Periodici (SloPS)
Questa tecnica nasce dall'osservazione che inviando un treno di K pacchetti di lunghezza L con una
frequenza R superiore alla banda disponibile A, a destinazione la distanza tra due pacchetti consecutivi di
uno stesso treno crescerà in maniera lineare.
Osservando la figura seguente possiamo notare facilmente che fintanto che R<A il ritardo rilevato
si mantiene quasi costante, mentre quando R>A i pacchetti continueranno ad accumularsi nella
coda del link a banda più stretta ed il ritardo misurato a destinazione aumenterà
proporzionalmente.
Per trovare il valore R=A per cui i pacchetti iniziano ad accodarsi l'algoritmo prevede che la
sorgente invii alla destinazione diversi treni di pacchetti a frequenze diverse, aumentando o
diminuendo la frequenza in base alle stime effettuate dal ricevente secondo lo schema di una
ricerca binaria.
19
Illustrazione 4: Andamento del ritardo rilevato nei casi in cui R<A o R>A
Progetto 3D CloudWiz | ATI NICE - DIEE
Treni di coppie di pacchetti (TOPP)
Questa tecnica è simile alla SloPS e differisce principalmente per le analisi statistiche sulle misure
raccolte. La tecnica TOPP prevede di inviare delle coppie di pacchetti dalla sorgente alla
destinazione, incrementando progressivamente la frequenza con cui le coppie vengono inviate.
Se la frequenza di invio R0 dei pacchetti è tale da non saturare la banda disponibile A allora la
frequenza di arrivo, misurata a destinazione, Rm , sarà uguale a quella di invio. Tuttavia, non
appena R0> A → Rm<R0 .
Consideriamo un percorso di capacità C e banda disponibile A, in presenza di cross-traffic pari a
RC=C−A , se tracciamo l'andamento del rapporto tra frequenza di ricezione e frequenza di
invio R0/Rm al crescere della frequenza di invio, avremo un andamento orizzontale fino ad un
certo valore di R0 e poi una crescita lineare dovuta all'effetto dell'accodamento dei pacchetti. Il
punto in cui cambia la pendenza coincide con la banda disponibile:
Per capire meglio come funziona osserviamo che non appena R0 supera la banda disponibile la
frequenza misurata non sarà più pari a R0 ma
Rm =R0
R0+RC
C →R0
Rm
=R0+RC
C
TOPP stima la banda disponibile come il valore massimo di R0 per il quale Rm ≈ R0 .
L'ultima relazione ci consente di stimare la capacità in funzione della pendenza del rapporto
R0/Rm , inoltre nel caso di collegamenti con più link è possibile che la curva R0/Rm presenti
diverse pendenze dovute alla saturazione di diversi link24 24Questo è vero se e solo se i link che hanno via via una banda disponibile superiore si trovano prima del precedente
20
Progetto 3D CloudWiz | ATI NICE - DIEE
Sequenze di coppie di pacchetti e Kalman Filters
Un'altra tecnica simile a TOPP e SloPS prevede l'uso di filtri di Kalman per la stima della banda
disponibile e si basa sulla definizione di una nuova misura: la deformazione della distanza tra due
pacchetti. Vediamo di darne una definizione precisa.
Consideriamo la i-esima coppia di pacchetti di una sequenza ed indichiamo:
• con τ i1 , τi2 i tempi di arrivo dei due pacchetti ad un generico hop;
• con τ i1* , τi2
* i loro tempi di arrivo all'hop successivo.
Non siamo interessati tanto al loro valore assoluto quanto alla differenza del tempo di arrivo tra i
due pacchetti
ti = τ i2 −τ i1
ti* = τ i2
* −τ i1*
e alla differenza tra questi due valori
δ = t i* −t i
che ci consente di definire la deformazione della distanza tra due pacchetti come
1+εi =t i
*
t i
→ εi =δi
t i
Indicando infatti
• con s la dimensione dei pacchetti;
• con u=st i
la frequenza di invio dei pacchetti;
• e con r=s
t i* quella di ricezione;
possiamo ricavare la relazione
collo di bottiglia (altrimenti non potrebbero giungere a saturazione).
21
Progetto 3D CloudWiz | ATI NICE - DIEE
ur
=s / t i
s / t i* =
t i*
t i
= 1+εi
La deviazione di questo rapporto dall'unità è pari alla deviazione di ε dallo zero.
Tracciando il grafico di ε in funzione della frequenza di invio dei pacchetti si nota subito
l'analogia con la tecnica TOPP:
L'idea è dunque quella di utilizzare i filtri di Kalman per stimare a quale frequenza di invio ε inizia
a discostarsi dallo zero.
Per farlo si considera il collegamento come una black-box descritta da un vettore di stato x, si
indica con u la frequenza di invio dei pacchetti, con z la deformazione della distanza tra i pacchetti,
con w il rumore presente nel sistema e con v il rumore di misura. In questo modo si possono
indicare l'evoluzione nel tempo del sistema e delle misure rispettivamente con
x k+1 = g (xk , uk , wk ) = x+w
z k = f (x k , uk , vk ) = v + {0 (u⩽B)αu+β (u>B)}
Un filtro è una procedura che prende in ingresso uk , zk ed una stima dello stato del sistema
x k e produce una stima del prossimo stato x k+1 . Ottenendo delle stime α ,β è possibile
stimare la banda con la relazione B=−βα
.
Dunque a partire da una stima iniziale il modello viene via via aggiornato e dopo un tempo iniziale
di convergenza è in grado di fornire una stima in tempo reale della banda disponibile.
22
Progetto 3D CloudWiz | ATI NICE - DIEE
Treni di pacchetti esponenzialmente distanziati (chirp)
L'ultima variante al treno di pacchetti prevede l'uso di pacchetti con spaziatura esponenzialmente
decrescente (denominati chirp):
In maniera simile a TOPP, l'idea è di raggiungere progressivamente la saturazione della rete e
verificare a quale frequenza di invio dei pacchetti la distanza di ricezione di discosta da quella in
invio. Tuttavia in questo caso si può sfruttare la spaziatura esponenziale per ottenere lo stesso
risultato con un numero molto inferiore di pacchetti, riducendo così sia l'intrusività dell'algoritmo
che i tempi di convergenza.
La sorgente invia m treni di pacchetti (chirp) composti ognuno da N pacchetti di dimensione P. I
pacchetti hanno tutti la stessa dimensione e la stessa spaziatura all'interno dei vari chirp, per cui i
valori associati ad ogni pacchetto sono calcolati come media dei valori rilevati sugli m chirp
ricevuti. Possiamo indicare
• con γ il fattore di distanza tra pacchetti;
• con qk quello dovuto alle code per il pacchetto k-esimo;
• con Δk la distanza temporale tra pacchetto consecutivi;
• con Rk =PΔk
la frequenza istantanea del chirp al pacchetto k-esimo.
Assumendo che il cross-traffic sia stazionario abbiamo che
23
Progetto 3D CloudWiz | ATI NICE - DIEE
qk=0 se Rk⩽Bqk>qk−10 se Rk>B
da cui si può stimare la banda disponibile B=Rk * dove k * è il pacchetto in cui inizia la
crescita del fattore di accodamento.
Osservando l'illustrazione 3 si può notare come ad un certo punto il fattore di accodamento cresca
per un breve periodo per poi ritornare allo zero; questo fenomeno, detto escursione, è legato
all'insorgere in un link del collegamento di un traffico extra di tipo burst (cioè intenso ma di breve
durata). Tuttavia essendo ancora il rate di invio inferiore alla banda disponibile, dopo un breve
periodo le code si svuotano e i valori di accodamento ritornano alla normalità.
Per individuare la banda disponibile il client tiene dunque conto di questa eventualità e non si
limita a considerare il primo valore per cui qk<qk−1 (che potrebbe corrispondere ad una
escursione) ma cerca quel valore di k a partire dal quale il valore di qk non decresce più.
ToolsOriginariamente ad ogni tecnica corrispondeva un tool che la implementava tale e quale.
Con il passare del tempo sempre più spesso sono stati sviluppati tool che implementavano più di
una delle tecniche disponibili e/o le fondevano assieme per cercare di superare i limiti di ciascuna.
Riportiamo di seguito un breve resoconto dei principali tool disponibili per la stima della banda
disponibile attraverso tecniche attive.
Tool per la stima della capacità degli hopSono sostanzialmente tool che utilizzano la tecnica VPS. Il primo tool ad implementarla fu
pathchar, scritto dallo stesso Van Jacobson (ideatore di questa tecnica) nel 1997. Altri tool ad
implementare questa tecnica sono Clink e Pchar che tuttavia non introdussero sostanziali
24
Illustrazione 5: Tipica traccia dei ritardi di accodamentodei pacchetti di un chirp
Progetto 3D CloudWiz | ATI NICE - DIEE
innovazioni.
Tool per la stima della capacità di un collegamento punto-puntoQuesti tool tentano di stimare la capacità del collo di bottiglia dell'intero collegamento; la maggior
parte di essi utilizza la dispersione di una coppia di pacchetti.
Bprobe usa coppie di pacchetti di dimensione variabile per cercare di aumentare la precisione e
applica dei filtri per cercare di rigettare i pacchetti le cui misure presentano un'elevata probabilità
di esser state influenzate da cross-traffic.
Nettimer utilizza una sofisticata tecnica statistica, denominata kernel density estimation, per
stimare il modo dominante nella distribuzione delle misure dei pacchetti e cercare di superare i
limiti tipici delle tecniche basate su istogrammi.
Pathrate usa diverse misure, ottenute mediante coppie di pacchetti di diversa dimensione, per
stimare tutti i modi locali (uno dei quali corrisponde alla capacità del collegamento).
Successivamente utilizza dei lunghi treni di pacchetti per stimare la frequenza media di dispersione
(Average Dispersion Rate ADR) che risulta sempre inferiore o uguale alla capacità e quindi può
essere considerato un limite inferiore della capacità del collegamento.
Sprobe sfrutta le caratteristiche del protocollo TCP per stimare la banda. La sorgente invia alcune
coppie di pacchetti TCP SYN (cui aggiunge un payload superiore al MTU, per aumentare la
probabilità di accodamento). Il protocollo TCP prevede che la destinazione che risponda ai
pacchetti SYN con dei pacchetti TCP RST (che occupano 40 bytes ed hanno una bassa probabilità di
essere accodati nel cammino di rientro). In questo modo la sorgente riesce a stimare la dispersione
sul collegamento e dunque la capacità. In alcuni casi può stimare anche la banda in direzione
inversa (dalla destinazione alla sorgente) attraverso l'invio di un piccolo file.
AdHoc Probe è una variante del tool CapProbe (vedi sotto) orientato alla stima della massima
velocità di trasferimento in un collegamento punto-punto che includa componenti wireless, ma in
assenza di competing-traffic. A differenza di CapProbe è unidirezionale e i pacchetti vengono inviati
dalla sorgente alla destinazione e qui vengono effettuate le stime.
Tool per la stima della banda disponibileIl primo tool a cercare di stimare la banda disponibile è stato Cprobe che utilizza un treno di 8
pacchetti di dimensione pari al MTU. Tuttavia è stato dimostrato che questo approccio misura la
25
Progetto 3D CloudWiz | ATI NICE - DIEE
frequenza di dispersione che è diversa dalla banda disponibile in quanto la prima dipende
dall'intero collegamento e dalla frequenza iniziale del treno di pacchetti, mentre la banda
disponibile è legata solo al link più “stretto”.
CapProbe utilizza delle coppie di pacchetti inviati dalla sorgente alla destinazione e poi rimandati
indietro (round-trip), ma oltre a considerare la dispersione dei pacchetti utilizza anche i ritardi
complessivi per identificare (e scartare) i pacchetti che sono stati influenzati da cross-traffic.
Pathload invece utilizza la tecnica SloPS e restituisce un intervallo di valori, il cui centro indica il
valor medio della banda disponibile durante l'intervallo di misura, mentre gli estremi danno una
stima della variabilità di questa misura.
Altri tool come IGI, che usa la tecnica TOPP, o pathchirp, che usa sequenze di chirp, hanno cercato
di modificare la tipologia di pacchetti e la modalità di invio per ottenere la stessa precisione di
Pathload ma con un numero minore di pacchetti e/o un tempo di convergenza inferiore.
BART fa uso dei filtri di Kalman per fornire una stima in tempo reale della banda disponibile sul
collo di bottiglia del collegamento; esiste anche una sua variante, denominata Multi-rate Bart o
MR-BART, che varia la frequenza di invio delle coppie di pacchetti anche all'interno di una stessa
sequenza per aumentare la precisione della stima.
WBest, è un algoritmo suddiviso in due fasi ed ottimizzato per massimizzare l'accuratezza
minimizzando il tempo di convergenza e l'intrusività (cioè il numero di pacchetti da inviare sul
canale). Nella prima fase vengono inviate N coppie di pacchetti per stimare la capacità del canale,
successivamente viene inviato un treno di pacchetti alla massima velocità stimata per calcolare il
trhoughput reale e la banda disponibile.
Qualche25 confrontoPer completare il panorama dei tool presentati riportiamo in alcune tabelle alcuni valori di
confronto tra le stime dei principali algoritmi in diverse condizioni operative.
I valori riportati sono tratti da alcuni degli articoli riportati in bibliografia, in quanto non sarebbe
stato possibile effettuare tutte le necessarie simulazioni (sia per la non disponibilità degli eseguibili
25Non per tutti gli algoritmi erano disponibili dati utili per un confronto perché in molti casi le pubblicazioni riportavanorisultati di simulazioni effettuate per verificare la capacità di un dato algoritmo di stimare la banda in un ambientesimulato ma quest'ultimo non veniva testato in un contesto reale e/o confrontato con altri algoritmi che potessero forniredei riferimenti. Abbiamo dunque riportato i dati disponibili sugli algoritmi che abbiamo ritenuto più interessanti (perchécitati come modello o termine di paragone in molte pubblicazioni).
26
Progetto 3D CloudWiz | ATI NICE - DIEE
di molti dei tool citati, sia per la difficoltà oggettiva di ricreare un'infrastruttura di test in grado di
riprodurre tutte le condizioni operative richieste per evidenziare le diverse criticità di
funzionamento).
Precisione della stima
Riportiamo di seguito alcuni test effettuati26 di diversi algoritmi, in condizioni operative diverse
(canale libero, cross-traffic, contending-traffic (UDP/TCP) ), su uno stesso collegamento composto
da reti cablate ed avente come ultimo hop un collegamento wireless. Tutti i valori riportati sono
corrispondono al valor medio su 30 misure.
Banda Reale IGI/PTR PathLoad PatChirp WBest
1 Idle channel 28.94 8.11 6.78 30.15 28.47
2 Cross traffic 24.39 8.74 6.81 28.89 23.24
3 Contending traffic
20.52 10.06 6.91 27.59 15.76
4 Saturated 0.0 1.92 1.95 5.00 1.01
5 Rate adapation 15.26 5.99 6.47 16.79 13.99
Intrusività e tempo di convergenza
Riportiamo di seguito i tempi di convergenza (in secondi) e l'intrusività (rapporto tra pacchetti di
misura e pacchetti utili inviati) relativi agli esempi precedenti
IGI/PTR PathLoad PatChirp WBest
intrus. tempo intrus. tempo intrus. tempo intrus. tempo
1 0.56 1.55 1.18 14.88 0.45 17.43 0.13 0.41
2 0.56 1.42 1.55 20.22 0.45 17.58 0.13 0.42
3 0.47 1.29 1.53 17.04 0.45 17.62 0.13 0.42
4 2.54 17.21 1.22 42.06 0.46 17.24 0.13 0.67
5 0.66 1.86 1.66 23.73 0.45 17.48 0.13 0.42
26Un algoritmo interessante e promettente era BART (soprattutto nella sua variante MR-BART), purtroppo nellepubblicazioni di presentazione degli algoritmi non erano presenti test comparativi che consentissero un facile confrontocon altri algoritmi e non si è trovata un'implementazione da testare per stimarne il reale comportamento.
27
Progetto 3D CloudWiz | ATI NICE - DIEE
ConclusioniOsservando i dati in tabella si nota subito come sia IGI/PTR che Pathload sottostimino
significativamente l'ampiezza di banda in caso di canale libero, mentre sia Patchirp che Wbest
rescono a dare una stima piuttosto accurata.
Una possibile ragione di questo può essere che l'overhead dovuto all'invio di pacchetti di test su
reti wireless è maggiore rispetto a quello che si ha in reti cablate (a testimonianza delle
problematiche introdotte da questo tipo di reti su algoritmi basati sul modello teorico studiato per
reti cablate); inoltre la dimensione dei pacchetti usata da questi tool è piccola rispetto al MTU (500
bytes IGI, 200 bytes Pathload).
Osservando la seconda tabella si può notare che PathChirp e PathLoad hanno tempi di
convergenza piuttosto lunghi. Questo può causare dei problemi in situazioni come il caso 5 di
banda variabile (ad esempio per disturbi sulla rete wireless). In questo caso Pathchirp tende a
sovrastimare la banda disponibile ed anche se la differenza in valore assoluto è simile a quella di
Wbest l'errore è più grave perché potrebbe portare ad una saturazione del collegamento e ad un
crollo della Quality Of Services.
In base a queste osservazioni, considerando la minore intrusività, i bassi tempi di convergenza e la
disponibilità del codice sorgente riteniamo che Wbest sia il miglior candidato tra i tool disponibili
per l'implementazione di un sistema network-aware con monitoraggio attivo della banda
disponibile.
Appendice A: Problematiche legate alle reti wirelessLe reti wireless hanno un'infrastruttura ed un funzionamento più complessi rispetto alle
tradizionali reti cablate, per cui molte delle idee che costituiscono il fondamento delle tecniche
precedenti possono risultare inadeguate se applicate direttamente, senza opportuni accorgimenti.
Vediamo alcuni problemi legati all'applicazione di queste tecniche alle reti wireless.
Rilevamento delle collisioni (CSMA/CD vs CSMA/CA)Una generica interfaccia di rete (cablata o wireless) prima di inviare un frame si mette in ascolto sul
canale di trasmissione per capire se questo è libero o meno. Se c'è una trasmissione in corso si
mette in attesa e non appena il canale si libera inizia l'invio del proprio frame.
Questa fase viene indicata dalle lettere CS (Carrier Sense) degli acronimi precedenti ed è comune
28
Progetto 3D CloudWiz | ATI NICE - DIEE
ad entrambe le tipologie di rete.
In una rete complessa dove ci sono più di due macchine collegate è possibile (anzi probabile) che
più dispositivi possano inviare frame e pacchetti sullo stesso canale (MA = Multiple Access).
Questa condizione può dare origine a delle collisioni, infatti quando un'interfaccia di rete, dopo
aver atteso che il canale si liberasse, inizia a trasmettere il proprio frame c'è il rischio che un'altra
interfaccia abbia seguito lo stesso iter ed inizi a sua volta una trasmissione27.
Quando questo accade si ha una collisione, ovvero i due segnali (elettrici, ottici, elettromagnetici)
si sovrappongono sul mezzo fisico distruggendo le informazioni portate da entrambe i segnali e i
frame andranno ritrasmessi.
Qui le due tipologie di rete si differenziano.
Nelle reti cablate l'interfaccia di rete può mettersi in ascolto sul canale anche durante la
trasmissione, accorgersi di una collisione (che si manifesta con dei picchi di segnale) e intervenire
immediatamente28 (CD = Collision Detection).
In una rete wireless la scheda di rete non è in grado di mettersi in ascolto durante la trasmissione e
quindi non potendo accorgersi di una eventuale collisione può solo cercare di evitarla29 (CA =
Collision Avoidance).
Questo limite diventa ancora più significativo se si considera che nelle reti cablate il canale è un filo
elettrico isolato dal resto del sistema e quindi le possibilità di collisione sono dovute
esclusivamente ad una trasmissione concorrente; di contro in una rete wireless il canale è
condiviso e conteso da altre reti ed altri sistemi, dunque la probabilità di collisioni dovute anche ad
27Per minimizzare la probabilità di collisioni lo standard 802.11 prevede l'uso di una coppia di messaggi RTS/CTS(Ready-To-Send / Clear-To-Send). Quando un terminale è pronto ad inviare sul canale un frame, invia preventivametneal router un pacchetto RTS. Il router seleziona (in caso di più RTS) un dispositivo e invia una risposta CTS in broadcasta tutti i dispositivi indicando quale dispositivo è abilitato all'invio. Il dispositivo selezionato invierà il frame mentre glialtri attenderanno che il canale torni libero. Tuttavia è stato dimostrato che in molti casi l'overhead imposto da questoprotocollo ha un effetto negativo sulle performance del sistema e di conseguenza questo meccanismo è quasi sempredisabilitato.28Il protocollo prevede che venga inviato un segnale con una codifica particolare, detto JAM signal, per avvisare tutte lereti in ascolto dell'avvenuta collisione. A seguito di un segnale di JA tutte le interfacce di rete iniziano un periodobackoff (silenzio) la cui durata è determinata casualmente da ogni scheda per minimizzare il rischio di ulterioricollisioni.29In questo caso il protocollo prevede che il ricevente dopo aver ricevuto e verificato il frame invii un segnale di ACK(acknowledgment) al mittente. In caso di mancato ricevimento dell'ACK il mittente suppone che vi sia stata unacollisione, inizia un periodo di backoff preventivo (la cui durata è stabilita casualmente nell'intervallo [0..CW), CW =Contention Window ed è una stima del livello di contesa sul canale) e poi reinvia il frame. In caso di collisionisuccessive il valore di CW viene raddoppiato e dunque anche la durata del backoff ha una crescita esponenziale.
29
Progetto 3D CloudWiz | ATI NICE - DIEE
interferenze esterne è molto più elevata30.
MAC layer retriesPer mascherare parzialmente questa fragilità delle reti wireless lo standard 802.11 definisce un
meccanismo denominato MAC layer retries che prevede che sia l'hardware stesso ad effettuare un
certo numero di tentativi di ritrasmissione dei frame prima di notificare ai layer superiori il
fallimento dell'invio.
Questo da un lato minimizza il numero di frame persi aumentando l'affidabilità della rete, ma
dall'altro aumenta la varianza associata al ritardo di trasmissione, avvicinando questa grandezza ad
una variabile aleatoria, e rischia di rendere inconsistenti le misure della dispersione su coppie di
pacchetti.
Infatti la dispersione in una coppia di pacchetti, a causa di questo fenomeno, può essere contratta
od espansa durante l'attraversamento di un link wireless anche in assenza di congestione sulla rete
(ad esempio per la presenza momentanea di contending traffic).
Algoritmi di controllo della frequenzaUn ulteriore elemento di aleatorietà delle reti wireless è dovuto al fatto che lo standard 802.11
prevede che i dispositivi siano in grado di negoziare automaticamente la velocità di trasmissione (e
dunque la capacità di un collegamento) tuttavia non definisce un algoritmo RCA (Rate Control
Algorithm), ovvero non specifica le misure (ad esempio la potenza di segnale, il numero di
ritrasmissioni, il numero di errori di trasmissione o altro) e le regole con cui variarla, lasciando ogni
costruttore libero di implementare il proprio algoritmo31.
Questo aumenta l'aleatorietà delle stime perché non si sa a priori quale algoritmo stia operando e
soprattutto perché viola il presupposto che la capacità del canale rimanga costante per tutto il
30Le possibili cause di interferenza e disturbo di una rete wireless sono innumerevoli, a partire dal movimento di undispositivo (router o PC) che aumentando la distanza può ridurre la potenza del segnale e di conseguenza la capacità delcanale, o equivalentemente al passaggio di persone od oggetti che possono frapporsi tra il trasmittente ed il ricevemente,all'attivazione di altri router nelle vicinanze che pur appartenendo a reti diverse occupano la stessa porzione dellospettro elettromagnetico, all'attivazione di oggetti che pur non essendo specificamente pensati per l'invio/ricezione disegnali sono in grado di generare interferenze elettromagnetiche, e via dicendo. La maggior parte di questi “disturbi”non sono sotto il nostro controllo e sono pertanto assolutamente imprevedibili.31Uno dei più diffusi algoritmi commerciali è l'ARF (Auto Rate Fallback) che in condizioni normali è in grado dimigliorare notevolmente le performance rispetto ad una installazione 802.11 a banda fissa, tuttavia è stato dimostratoche in caso di link congestionati questo algoritmo ha un impatto negativo sulle performance complessive. Un altroalgoritmo è lo RBAR (Receiver Based Auto Rate) che però si basa sulla coppia di messaggi RTS/CTS e quindiraramente è applicabile.
30
Progetto 3D CloudWiz | ATI NICE - DIEE
periodo della stima.
Bibliografia1. V. Jacobson, “Congestion Avoidance And Control”, in SIGCOMM Computer Communication
Review, ACM, 1988
2. K.Bala, I.Cidon, K.Sohraby, “Congestion control for high speed packet switched networks” in
IEEE Proceedings, 9 Annual Conference of the IEEE Computer and Communication Societies
(INFOCOM), 1990
3. S.Shenker, “A theoretical analysis of feedback flow control”, in Proceedings of the ACM
Symposium on Communications Architectures & Protocols (SIGCOMM), 1990
4. S.Keshav, “A control theoretic approach to flow control” in SIGCOMM Computer
Communication Review, ACM, 1991
5. S.Floyd, V.Jacobson, “On Traffic Phase Effects in Packet-switched Gateways”, in
Internetworking Research and Experience, vol.3 pages 115-126, 1992
6. JC Bolot, “Characterizing End-to-End Packet Delay and Loss in the Internet” in Journal of
High Speed Networks, IOS Press, 1993
7. I. Cidom, A. Khamisy, M.Sidi, “Analysis of Packet Loss Processes in High-speed Networks”, in
IEEE Transactions on Information Theory, vol. 39, no.1, 1993
8. V.Paxson, “Empirically derived analytic models of wide-area TCP connections”, IEEE/ACM
Transactions on Networking (TON) vol.2, issue 4, pages 316-336, 1994
9. R.L. Carter, M.E.Crovella, “Measuring bottleneck link speed in packet-switched networks” in
Performance Evaluation Vol 27–28, Pages 297–318, 1996
10. B.P. Crow, “IEEE 802.11 Wireless Local Area Networks” in IEEE Communications Magazine,
vol.35 iss. 9 pag.116, 1997
11. V. Paxson, “Measurements and Analysis of an end-to-end Internet Dynamics”, Phd Thesis in
Computer Science Division of University of California, Berkeley, 1997
12. V. Paxson, “End to End Internet Packet Dynamics”, in SIGCOMM Computer Communication
Review, ACM, 1997
13. V. Jacobson, “Pathchar A Tool to Estimate Internet Link Characteristics”, slides, link, 1997
31
Progetto 3D CloudWiz | ATI NICE - DIEE
14. K.Lai, M.Baker, “Measuring Bandwidth” in Proceedings of IEEE INFOCOM, pages 235-245,
1999
15. R.Rejaie, M.Handley, D. Estrin, “RAP - And end to end Rate-based Congestion Control
Mechanism for Realtime Streams in Internet” in Proceedings of IEEE INFOCOM, vol. 3,
pages 1337-1345, 1999
16. M.Allan, V. Paxson, “On Estimating end-to-end Network Path Characteristics” in ACM
SIGCOMM Computer Communication Review, vol 29, issue 4, 1999
17. K.Lai, M.Baker, “Measuring Link Bandwidth using a Deterministic Model of Packet Delay” in
Proceedings of ACM SIGCOMM, pages 283-294, 2000
18. A.B.Downey, “Using Patchar to estimate Internet Link Characteristics”, in SIGCOMM
Computer Communication Review, ACM, 2000
19. B.Melander, M.Bjorkman, P.Gunningber, “A new end-to-end probing and analysis method
for estimating bandwidth bottlenecks” in Global Internet Symposium, 2000
20. S.Banerjee, A.K.Agrawala, “Estimating available capacity of a network connection” in
Proceedings of IEEE International Conference on Networks(ICON), 2000
21. Y.Zhang, N.Duffield, V.Paxson, S.Shenker, “On the Constancy of Internet Path Properties” in
Proceedings of the ACM SIGCOMM Workshop on Internet Measurement, pages 197-211,
2001
22. K.Lai, M.Baker, “Nettimer: A tool for measuring bottleneck link bandwidth” in Proceedings
of the 3rd USENIX Symposium on Internet Technologies and Systems, 2001
23. S. Alouf, P. Nain, and D. Towsley, “Inferring Network Characteristics via Moment-Based
Estimators” in Proceedings of IEEE INFOCOM, 2001
24. C.Dovrolis, P. Ramanathan, “What Do Packet Dispersion Techniques Measure?” in
Proceedings of IEEE INFOCOM, pages 905-914, 2001
25. M.Jain, C.Dovrolis, “End To End Available Bandwidth: Measurements, Metodology,
Dynamics and Realtion with TCP Throughput” in SIGCOMM Computer Communication
Review, ACM, 2002
26. A. Pasztor, D. Veitch, “The Packet size dependece of packet pair like methods” in IEEE
32
Progetto 3D CloudWiz | ATI NICE - DIEE
International Workshop of Quality Of Service (IWQoS), 2002
27. A.Pasztor, D.Veitch, "On the Scope of End-to-end Probing Methods" in IEEE
Communications Letters, vol.6, issue 11, pages 509-511, 2002
28. B. Melander, M. Bjorkman, and P. Gunningberg, “Regression-Based Available Bandwidth
Measurements,” in International Symposium on Performance Evaluation of Computer and
Telecommunication Systems, 2002
29. M. Jain, C. Dovrolis, “Pathload: A Measurement tool for end-to-end available bandwidth” in
Proceedings of Passive and Active Measurements (PAM) Workshop, pages 14-25, 2002
30. N. Hu, P. Steenkiste, “Estimating available bandwidth using packet pair probing”, [Online],
link, 2002
31. N. Hu, P. Steenkiste, “Evaluation and Characterizaion of Available Bandwidth Probing
Techniques”, in IEEE Journal on Selected Areas In Communications, vol. 21, no.6, 2003
32. R.S.Prasad, C.Dovrolis, B.A.Mah, “The effect of layer-2 store-and-forward devices on per-
hop capacity estimation” in IEEE Annual Joint Conference of the IEEE Computer and
Communications (INFOCOM), vol.3, pages 2090-2100, 2003
33. K. Harfoush, A. Bestavros, J. Byers, “Measuring Bottleneck Bandwidth of Targeted Path
Segments” in Proceedings of IEEE INFOCOM, 2003
34. V. Ribeiro et al., “pathChirp: Efficient Available Bandwidth Estimation for Network Paths” in
Proceedings of Passive and Active Measurements (PAM) Workshop, 2003
35. R.S.Prasad, M.Murray, C.Dovrolis, K. Claffy, “Bandwidth estimation: metrics, measurement
techniques, and tools,” in IEEE Network,vol. 17, pp. 27–35, 2003
36. J. Strauss, D. Katabi, F. Kaashoek, "A Measurement Study of Available Bandwidth Estimation
Tools" in Proceedings of ACM SIGCOMM Conference on Internet Measurement, 2003
37. J.Navratil, "ABwE: A Practical Approach to Available Bandwidth Estimation" In Proceedings
of the PAM, 2003
38. S.Shah, "�Available bandwidth estimation in IEEE 802.11-based wireless networks"� in Final
Report of Bandwidth Estimation ISMA Workshop, 2003
39. S. R. Kang, X. Liu, M. Dai, D. Loguinov, “Packet-pair bandwidth estimation: Stochastic
33
Progetto 3D CloudWiz | ATI NICE - DIEE
analysis of a single congested node,” in Proceedings of IEEE International Conference on
Network Protocols(ICNP), pp. 316–325, 2004
40. M.Jain, C.Dovrolis, “Ten fallacies and pitfalls on end-to-end available bandwidth
estimation,” in Proceedings of the 4th ACM SIGCOMM conference on Internet
measurement, 2004
41. C. Dovrolis, P. Ramanathan, D. Moore, “Packet-dispersion techniques and a capacity-
estimation methodology” in IEEE/ACMTransactions on Networking, vol. 12, no. 6, pp. 963–
977, 2004
42. X. Liu, K. Ravindran, D. Loguinov, “Evaluating the potential of bandwidth estimators,” in 4th
New York Metro Area Networking Workshop (NYMAN), 2004
43. K.Lakshminarayanan, V.N. Padmanabhan, J. Padhye, “Bandwidth estimation in broadband
access networks.,” in Proceedings of IMC 2004, 2004
44. R.Kapoor, L.J. Chen, Li Lao, M. Gerla, M. Y. Sanadidi, “Capprobe: a simple and accurate
capacity estimation technique,” in SIGCOMM Computer Communication Review, ACM, vol.
34, no. 4, pp. 67–78, 2004
45. D. Kiwior, J. Kingston, A. Spratt, “PATHMON, A Methodology for determining Available
Bandwidth over an Unknown Network,” in IEEE Sarnoff Symposium on Advances in Wired
and Wireless Communications, pp. 27-30, 2004
46. S. Ekelin, M. Nilsson, "Continuous monitoring of available bandwidth over a network path”
in Proceedings of Swedish National Computer Networking Workshop (SNCNW), 2004
47. D.Aguayo, J.P.Bicket, S.Biswas, G.Judd, R.Morris, "Link-level measurements from an 802.11b
mesh network" in ACM/SIGCOMM Computer Communication Review, 2004
48. L.J. Chen, T. Sun, G. Yang, M. Y. Sanadidi, M. Gerla, “Adhoc probe: Path capacity probing in
ad hoc networks”, in International Conference on Wireless Internet, pages 156–163, 2005
49. L.J. Chen, T. Sun, G. Yang, M. Y. Sanadidi, M. Gerla, “End-to-end asymmetric link capacity
estimation” in IFIP Networking, pages 780–791, 2005
50. M. Jain, C. Dovrolis, “End-to-End Estimation of the Available Bandwidth Variation Range,” in
Proceedings of ACM SIGMETRICS International Conference on Measurement and Codeling
34
Progetto 3D CloudWiz | ATI NICE - DIEE
of Computer Systems, pages 265-276, 2005
51. A. Johnsson, B. Melander, and M. Bjorkman, “Bandwidth measurement in wireless
networks” in Proceedings of Mediterranean Ad Hoc Networking Workshop, 2005
52. A. Shriram, M. Murray, Y. Hyun, N. Brownlee, A. Broido, M.Fomenkov, K. Claffy,
“Comparison of public end-to-end bandwidth estimation tools on high-speed links,” in
Proceedings of Passive and Active Measurement Workshop (PAM), 2005
53. Y.Yang, R.Kravets, “Contention Aware Admission Control for Ad Hoc Network” in IEEE
Transactions on Mobile Computing, vol.4, issue 4, pages 363-377, 2005
54. S.Ekelin, M.Nilsson, E. Hartikainen, A. Johnsson, J-E.Mangs, B. Melander, M.Bjorkman,
“Real-Time Measurement of End-to-End Available Bandwidth using Kalman Filtering” in
Proceedings of 10th IEEE/IFIP Network Operations and Management Symposium, NOMS,
pp. 73–84, 2006
55. M. Li, M. Claypool, R. Kinicki, “Modeling and simulating packet dispersion in wireless 802.11
networks,” Technical Report of Computer Science Department at Worcester Polytechnic
Institute, 2006
56. M.Li, M.Claypool, R.Kinicki, “Packet Dispersion in IEEE 802.11 Wireless Networks,” in
Proceedings of Performance and Management of Wireless and Mobile Networks (P2MNet),
2006.
57. I.Rhee, L.Xu, “Limitations of Equation-based Congestion Control” in IEEE/ACM Transactions
on Computer Networking , pages852–865, 2007
58. F.Li, M.Li, R.Lu, H.Wu, M.Claypool, R.Kinicki, “Measuring Queue Capacities of IEEE 802.11
Wireless Access Points,” in Proceedings of the Fourth IEEE International Conference on
Broadband Communications, Networks and Systems (BROADNETS), 2007
59. X. Liu, K. Ravindran, D. Loguinov, “A queuing-theoretic foundation of available bandwidth
estimation: single-hop analysis” IEEE/ACM Transactions on Networking, vol.15, no. 6, pp.
918-931, 2007
60. A.Shriram, J.Kaur, "Empirical Evaluation of Techniques for Measuring Available Bandwidth"
in Proceedings of IEEE International Conference on Computer Communications INFOCOM,
35
Progetto 3D CloudWiz | ATI NICE - DIEE
pp. 2162–2170, 2007
61. J. Liebeherr, M. Fidler, S. Valaee, "Min-plus system interpretation of bandwidth estimation"
in IEEE International Conference on Computer Communications(INFOCOM), 2007
62. M.Sedighizad, B.Seyfe, K.Navaie, “MR-BART: multi-rate available bandwidth estimation in
real-time” in Proceedings of the 3nd ACM workshop on Performance monitoring and
measurement of heterogeneous wireless and wired networks, pp. 1–8, 2008
63. C.Sarr, C.Chaudet, G. Chelius, I.G. Lassous, “Bandwidth Estimation for IEEE 802.11 based Ad
Hoc Networks”, in IEEE Transactions on Mobile Computing vol. 7, no 10, 2008
64. L.J.Chen, T.Sun, B.C.Wang, M.Y. Sanadidi, M.Gerla, “PBProbe: A Capacity Estimation Tool for
High Speed Networks,” in SIGCOMM Computer Communication Review, ACM, vol. 31, no.
17, pp. 3883–3893, 2008
65. M.Li, M.Claypool, R.Kinicki, “WBest: A Bandwidth Estimation Tool for IEEE 802.11 Wireless
Networks”, in IEEE Conference on Local Computer Networks (LCN), 2008
66. T. Nadeem, “Network-aware applications in wireless networks,” in Proceedings of
Workshop on Research Directions in Situational-aware Self-managed Proactive Computing
in Wireless Adhoc Networks, 2009
67. D. Gupta, D. Wu, P. Mohapatra, C.N. Chuah, “Experimental comparison of bandwidth
estimation tools for wireless mesh networks,” in Proceedings of IEEE Conference on
Computer Communications (INFOCOM ’09), pp. 2891–2895, 2009
68. J. Liebeherr, M.Fidler, S. Valaee, “A system theoretic approach to bandwidth estimation” in
IEEE/ACM Transactions on Networking, 2010
69. F.Chen, H.Zhai, Y.Fang, “Available Bandwidth in Multirate and Multihop Wireless adHoc
Networks” in IEEE Journal on Selected Areas in Communications, vol 28, no. 3, 2010
70. C.Guerrero, M.Labrador, "Traceband: A fast, low overhead and accurate tool for available
bandwidth estimation and monitoring" in Computer Networks, vol 54, issue 6, pages 977-
990, 2010
71. M.F.Ibrahim, M.Jamal, S.Yahya, M.N.Taib “Available Bandwidth Estimation in Network-
Aware Applications for Wireless Campus e-Learning System” in Journal of Computer
36
Progetto 3D CloudWiz | ATI NICE - DIEE
Networks and Communications, 2010
72. R.Hou, S.Qu, H.Zeng, KS.Lui, J.Li, “Coding and interference aware path bandwidth
estimation in multi-hop wireless networks” in IEEE Global Telecommunications Conference
(GLOBECOM), p. 1-5, 2011
73. H.Liu, L. Cheng, “Available Bandwidth Estimation Strategy Based on the Network Allocation
Vector” in Journal of Networks, vol.7, no.12, 2012
74. Z.Yuan, H.Venkataraman, and G.M. Muntean, "MBE:Model-based Bandwidth Estimation for
IEEE 802.11 DataTransmissions" in IEEE Transactions on Vehicular Technology, vol. 61, no. 5,
pp. 2158-2171, 2012
75. J.Guerin, S. Glass, P.Hu, W.L.Tan, M. Portmann, “Time-based and low-cost bandwidth
estimation for IEEE 802.11 links” in International Wireless Communications and Mobile
Computing Conference (IWCMC), 2012
76. D.S.Kayange, R.Sinde, A. San, “Available Bandwidth Estimation Techniques (ABETS) For An
Efficient Telemedicine Content Transport Network” in International Journal of Engineering
Research & Technology (IJERT), vol.2, issue 7, 2013
77. P.Zhao X.Yang, W.Yub, C.Dong, S.Yang, S.Bhattarai, “Toward Efficient Estimation Of Available
Bandwidth for IEEE 802.11- based Wireless Networks” in Journal of Network and Computer
Applications, 2013
78. R.Lubben, M.Fidler, J.Liebeherr, “Stochastic Bandwidth Estimation in Networks With
Random Service” in IEEE/ACM Transactions on Networking, vol.22 , issue.2, 2014
37
Progetto 3D CloudWiz | ATI NICE - DIEE
Progettazione dell'architettura del sistema adattativoIl sistema adattativo è composto da tre moduli principali: un server, un client ed un monitor per la
misurazione della network performance.
Ognuno dei moduli implementa dei comportamenti specifici e ben definiti del sistema adattativo.
Il Server si occuperà di:
• Catturare il flusso video dell'applicazione da remotizzare (nel caso attuale, l'intero desktop);
• Selezionare il codec più adatto allo stato della rete per ottenere la qualità migliore (in base
all'input del network performance monitor);
• Scambiare col client informazioni sui codec da utilizzare;
• Comprimere ciascun frame in base al codec selezionato;
• Inviare al client i frame catturati.
38
Progetto 3D CloudWiz | ATI NICE - DIEE
Il Client si occuperà di:
• Decodificare i dati in arrivo dal server per la loro visualizzazione;
• Visualizzare i frame decodificati;
• Inviare al server eventuali informazioni sulla perdita di frame inviati.
Il Network Performance Monitor si occuperà di:
• Monitorare periodicamente lo stato della rete;
• Comunicare al server lo stato della rete affinché venga selezionato il codec più adatto.
A seconda della tipologia del monitor che verrà selezionata in fase di realizzazione potrebbero
essere previste interazioni più o meno implicite oltre che col server anche col client.
Come indicato in precedenza il monitor potrà effettuare la verifica della banda con cadenza
39
Grabber
Encoder selector
Codec-1
Codec-2
Codec-N
SocketNetwork
performance monitor
Viewer
Decoder selector
Codec-1
Codec-2
Codec-N
Socket
Selected codec ID
Selected codec ID
Server Client
Progetto 3D CloudWiz | ATI NICE - DIEE
prefissata in modo da evitare di aggiungere un overhead continuo alla trasmissione dati, dovuto
alle operazioni di misurazione. Questa frequenza di verifica dipende sia dalla rete a disposizione
(es. una rete in fibra potrebbe permettere anche una misurazione puntuale dello status della rete)
che dall'algoritmo utilizzato per la realizzazione del monitor.
Ipotizzando che il monitoraggio venga effettuato ogni N frame inviati, quello che segue è lo schema
della sequenza di interazione fra i tre moduli.
Specifiche implementative
Dal punto di vista implementativo, possiamo già proporre una probabile struttura delle classi del
sistema adattativo:
• CloudVizServer: incapsula tutte le operazioni eseguite dal server. Attende una nuova
connessione. All'arrivo della connessione inizia il ciclo di grabbing, codifica ed invio dei dati
codificati in maniera sincrona. La selezione del codec sarà eseguita tramite il CodecSelector
40
Progetto 3D CloudWiz | ATI NICE - DIEE
sulla base della banda disponibile individuata tramite un NetMonitor. Il controllo della
banda non sarà eseguito ad ogni frame ma periodicamente (es. all'avvio e/o una volta al
secondo). Il ciclo di cattura dovrà garantire un flusso di video con frame rate non superiore
a 25 fps. Il ciclo di cattura del server sarà terminato alla disconnesisone del client. Il server a
quel punto ritornerà nello stato di attesa per una nuova connessione.
• CloudVizClient: incapsula tutte le operazioni eseguite dal client. Si connette al server
(indicato tramite Ip e Porta) ed attende i dati da visualizzare. Alla ricezione dei dati il client
procederà alla loro decodifica tramite il codec opportuno (identificato dall'ID ricevuto
insieme ai dati) ed alla visualizzazione. Il ciclo di ricezione/visualizzazione terminerà alla
disconnessione del server o alla pressione di un tasto. La visualizzazione dei frame
decodificati avverrà alla massima velocità possibile aggiungendo in sovrimpressione
eventuali informazioni come FPS e codec utilizzato.
• XGrabberSHM: si occupa di catturare lo schermo restituendo il frame corrispondente al
Server.
• CodecSelector: sulla di un del bitrate disponibile restituirà un ID univoco associato al codec
(e configurazione) da utilizzare. La codifica da utilizzare sarà fissata in modo preventivo per
diversi intervalli di bitrate. I codec preconfigurati saranno archiviati in un vettore di codec
indicizzato tramite l'id.
• NetMonitor: fornisce le interfacce per recuperare lo stato della rete.
• SocketServer e SocketClient: si occupano di gestire la comunicazione tramite semplici
comandi di lettura e scrittura di buffer.
41