WP 2 - nice-software.com · 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

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

http://pngimg.com/


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


R2.2RELAZIONE TEST COMPARATIVO SULLE PERFORMANCE REALI

DEGLI ALGORITMI DI COMPRESSIONE IN CONTESTI OPERATIVI

GENERICI E PER CATEGORIE SPECIFICHE DI CONTENUTO





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 preliminare video composito..........................................................................................31


Conclusioni.....................................................................................................................................40

Test sui codec compound....................................................................................................................41

Codec compound............................................................................................................................41

Setup degli esperimenti..................................................................................................................41

Risultati degli esperimenti..............................................................................................................42

Conclusioni.........................................................................................................................................44

i


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


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


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


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


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


5


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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.


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


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


15,74966524 15,35433476 15,52912589 15,37437053 15,96541917 27,79412303


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


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


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


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


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


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.


25


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


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


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


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



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.


TurboJpeg 52.952 15.374 9.872 25.247


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


30


Per garantire un livello di qualità percepita sempre accettabile è necessario che il bitrate sia contenuto negli estremi indicati nella seguente tabella.



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


15,22715737 16,44491416 16,93326037 17,19088984 19,13022461 30,46492561


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


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


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


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.


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



Per quanto riguarda il tempo di codifica e il livello di compressione otteniamo i risultati riportatinella figura seguente.


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


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


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


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


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



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.


TurboJpeg 20.631 17.190 12.051 29.24


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.



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


39


Volendo garantire una qualità percepita accettabile il bitrate minimo dovrà essere incrementato

come indicato dalla seguente tabella.



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


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


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


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


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


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


R2.3DATASET PER LA VALIDAZIONE DEGLI ALGORITMI DI

COMPRESSIONE





Descrizione dei dataset.........................................................................................................................1

i


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


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


Tabella 1 - Caratteristiche dei video.

Nella seguente figura sono riportati tre frame dei video utilizzati come dataset:

3


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


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





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


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


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


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


• 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


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


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


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


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


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


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


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


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


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


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


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


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

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/white_paper_c11-465436.html


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

ftp://ftp.kfki.hu/pub/packages/security/COAST/netutils/pathchar/msri-talk.pdf


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


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

http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA461170


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


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


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


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


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


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


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


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

Documents

WP 2 - nice-software.com · 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