EidosLab: una modello per lo sviluppo di sistemi per l ...eidos.di.unito.it/Software/eidoslab/tesi.pdf · base quali gestione della memoria, gestione di thread e servizi remoti, attivando

Università degli Studi di TorinoFacoltà di Scienze MM.FF.NN.

Corso di Laurea Specialistica in Realtà Virtuale e Multimedialità

EidosLab: un laboratorio per losviluppo di procedure perl'elaborazione di immagini

Relatore: Nello Balossino

CoRelatore: Davide Cavagnino

Candidato: Sergio Rabellino

dedicato a Chiara

EidosLab: un laboratorio per lo sviluppo di procedure per l'elaborazione di immagini

INDICE GENERALE

1 Introduzione............................................................................................................ 5 2 L'ambiente di Sviluppo .NET............................................................................... 6

2.1 L'architettura di .NET Framework.............................................................. 6 2.2 Funzionalità di Common Language Runtime............................................ 8 2.3 Libreria di classi .NET Framework........................................................... 10 2.4 Sviluppo di applicazioni client.................................................................... 12 2.5 Il Common Language Runtime................................................................ 13 2.6 Cenni preliminari sugli assembly................................................................ 17 2.7 Convenzioni di denominazione................................................................. 19 2.8 Spazio dei nomi System............................................................................... 20 2.9 Spazio dei nomi System.Windows.Forms................................................ 22 2.10 Le Classi .NET OpenSource in linguaggio C#................................... 25

3 Lo standard XML................................................................................................. 28 3.1 Origine e obiettivi ....................................................................................... 28 3.2 Struttura logica del linguaggio XML ....................................................... 33 3.3 Prologo di un Documento XML.............................................................. 33 3.4 L’elemento Document............................................................................... 34 3.5 Apertura e chiusura dei tag........................................................................ 35 3.6 Il Tag di Elemento vuoto........................................................................... 36 3.7 Attributi....................................................................................................... 36 3.8 Documenti XML validi e ben formati..................................................... 37 3.9 L' XML Document di una TaskList EidosLab....................................... 38

4 L'Elaborazione nel dominio trasformato: la Trasformata di Fourier............ 42 4.1 Rappresentazione delle trasformate di Fourier....................................... 45 4.2 Confronto tra il contenuto informativo dell’ampiezza e della fase......48 4.3 Proprietà della Trasformata di Fourier.................................................... 49 4.4 Contributi di frequenza.............................................................................. 53 4.5 Proprietà delle componenti reale ed immaginaria.................................. 55

5 Tecniche di filtraggio nel dominio delle frequenze........................................... 58 5.1 Contesti di applicabilità.............................................................................. 60 5.2 Filtri passa-basso......................................................................................... 62

6 L'architettura dell'applicazione............................................................................ 70 6.1 Il modello..................................................................................................... 70 6.2 L'interfaccia PluginInterface...................................................................... 73 6.3 Il motore di esecuzione: la TaskList......................................................... 77 6.4 L'interfaccia principale di EidosLab......................................................... 80

7 Gli algoritmi sviluppati: i Plugin di base............................................................. 83

3


7.1 Load/Save Image........................................................................................ 83 7.2 Discrete Fourier Transform...................................................................... 84 7.3 Fast Fourier Transform.............................................................................. 87 7.4 Discrete Cosine Transform....................................................................... 87 7.5 Frequency Filters......................................................................................... 89 7.6 Convolution Spatial filter........................................................................... 90 7.7 Color Conversion........................................................................................ 90 7.8 Image Aritmetics......................................................................................... 92 7.9 Border Detection Filters............................................................................ 93 7.10 Export Pdf Format.................................................................................. 93

8 Sviluppi futuri......................................................................................................... 969 Ringraziamenti....................................................................................................... 97

4


1 INTRODUZIONE

Eidos Lab è un modello innovativo per l'elaborazione di immagini che

consente lo sviluppo di procedure ripetibili e documentate delle funzioni

applicate nello sviluppo di una specifica elaborazione.

Eidos Lab facilita lo sviluppo di nuove funzioni che possono essere

incluse nell'applicazione semplicemente sfruttando un template di

programmazione che segue il modello di programmazione a plugin..

Il proof-of-concept del modello è realizzato tramite una applicazione

host che fornisce le funzionalità di base e la capacità di inglobare i plugin

sviluppati secondo le specifiche di interfacciamento.

L'applicazione delle funzioni consente di realizzare una precisa

elaborazione che può essere descritta secondo i parametri delle funzioni

applicate e le funzioni stesse espresse in termini di plugin utilizzati.

Si ottiene pertanto una rappresentazione unica dell'elaborazione che

risulta facilmente riapplicabile a diverse immagini di partenza, in una specie di

pattern di elaborazione.

L'uso pervasivo di XML per la descrizione delle attività di EidosLab

permette l'interoperabilità con diverse applicazioni e la conduzione delle

elaborazioni stesse al di fuori del contesto proprio dell'applicazione.

Nel capitolo 2 è descritto l'ambiente di sviluppo .NET scelto per la

realizzazione dell'applicazione; nel capitolo 3 viene affrontato lo standard XML

e le sue peculiarità; nei capitoli 4 e 5 sono riportati dei cenni sulle trasformate

di Fourier e le sue proprietà ed applicazioni nel campo delle elaborazione

dell'immagine; nei capitoli 6 e 7 l'applicazione è descritta nelle sue parti

componenti riportando alcuni stralci di codice ritenuti di particolare interesse.

5


2 L'AMBIENTE DI SVILUPPO .NET

Per lo sviluppo dell'applicazione è stato scelto il .NET Framework

recentemente sviluppato dalla Microsoft.

.NET Framework è un componente integrante di Windows che supporta

la generazione e l'esecuzione di applicazioni di nuova generazione e servizi

Web XML in cui il linguaggio di programmazione di riferimento è il nuovo

linguaggio C# (Csharp).

2.1 L'ARCHITETTURA DI .NET FRAMEWORK

.NET Framework è progettato per ottenere gli obiettivi indicati di

seguito:

• fornire un ambiente di programmazione orientato agli oggetti coerente,

sia che il codice degli oggetti sia memorizzato ed eseguito localmente, sia

che venga eseguito localmente ma distribuito su Internet oppure eseguito

in modalità remota.

• fornire un ambiente di esecuzione del codice che minimizzi la

distribuzione del software e i conflitti di versioni, che permetta una

esecuzione sicura anche dei codici creati da produttori sconosciuti o

semi-trusted e che elimini i problemi di prestazioni degli ambienti basati

su script o interpretati.

• rendere coerente l'esperienza dello sviluppatore attraverso tipi molto vari

di applicazioni, quali applicazioni basate su Windows e applicazioni

basate sul Web.

6


• generare tutte le comunicazioni in base agli standard industriali per

assicurare che il codice possa integrarsi con qualsiasi altro codice.

.NET Framework è composto da due componenti principali:

• il Common Language Runtime (CLR)• la libreria di classi.

Il CLR rappresenta la base del framework e può essere considerato

come un agente che gestisce il codice in fase di esecuzione, fornendo servizi di

base quali gestione della memoria, gestione di thread e servizi remoti, attivando

al contempo una rigida indipendenza dei tipi e altre forme di accuratezza del

codice che permettano protezione ed efficienza.

Il codice destinato al runtime è definito codice gestito (ManagedCode), mentre quello non destinato al runtime è definito codice non gestito

(Unmanaged Code). La libreria di classi è un insieme completo orientato agli oggetti di tipi

riutilizzabili che possono essere impiegati nello sviluppo delle applicazioni, da

quelle tradizionali della riga di comando o con interfaccia utente grafica (GUI,

Graphical User Interface) a quelle basate sulle più recenti innovazioni fornite

da ASP.NET, quali Web Form e servizi Web XML.

Nella seguente illustrazione viene illustrata la relazione di Common

Language Runtime e libreria di classi con le applicazioni e con l'intero sistema.

Nelle sezioni che seguono vengono descritti più dettagliatamente i

principali componenti e le principali funzionalità di .NET Framework.

7


2.2 FUNZIONALITÀ DI COMMON LANGUAGE RUNTIME

Common Language Runtime gestisce la memoria, l'esecuzione di thread,

l'esecuzione del codice, la verifica della protezione del codice, la compilazione

e altri servizi di sistema. Queste funzionalità sono intrinseche al codice gestito

che viene eseguito sul Common Language Runtime.

Per quanto riguarda la protezione, ai componenti gestiti vengono

assegnati vari gradi di attendibilità in base a diversi fattori fra cui l'origine, ad

esempio Internet, una rete aziendale o un computer locale. Un componente

gestito quindi può essere o non essere in grado di eseguire operazioni di

accesso a file, o al registro di sistema o altre funzioni riservate anche se

utilizzato nella stessa applicazione attiva.

Gli utenti possono ad esempio consentire a un eseguibile incorporato in

una pagina Web di eseguire un'animazione sullo schermo o una canzone, ma

non di accedere ai propri dati personali, al file system o alla rete. Le

funzionalità di protezione del runtime consentono un controllo del software

distribuito su Internet.

L'efficienza del codice è inoltre attivata dal runtime mediante

8


l'implementazione di una rigida infrastruttura di verifica di tipi e codice

denominata CTS (Common Type System).Il CTS assicura che tutto il codice gestito sia auto descrittivo. I vari

compilatori di linguaggio di Microsoft e di altri produttori generano codice

gestito conforme a CTS, consentendo a tale codice di utilizzare altri tipi e

istanze, pur mantenendo una rigida fedeltà e indipendenza dei tipi.

L'ambiente gestito di runtime elimina molti problemi comuni di

software. Nel runtime vengono ad esempio automaticamente gestiti il layout di

oggetti e i riferimenti a oggetti, i quali vengono rilasciati quando non sono più

utilizzati. Questa gestione automatica della memoria, detta GarbageCollection (GC) risolve i due errori più comuni delle applicazioni, ossia le

perdite di memoria e i riferimenti a memoria non validi.

Grazie al runtime inoltre la produttività dello sviluppatore viene

aumentata. I programmatori possono ad esempio scrivere applicazioni nel

linguaggio di sviluppo scelto e sfruttare tutti i vantaggi del runtime, della

libreria di classi e dei componenti scritti in altri linguaggi da altri sviluppatori.

Questo risultato può essere raggiunto da qualsiasi fornitore di compilatori che

sceglie di utilizzare il runtime. I compilatori di linguaggio destinati a .NET

Framework rendono disponibili le funzionalità di .NET Framework al codice

esistente scritto in tale linguaggio, facilitando notevolmente il processo di

migrazione delle applicazioni esistenti.

Benché il runtime sia progettato per i programmi software futuri,

supporta anche quelli attualmente disponibili e meno recenti. L'interoperabilità

tra codice gestito e non gestito consente agli sviluppatori di continuare a

utilizzare i componenti COM e le DLL che risultano necessari.

Il runtime è inoltre progettato per migliorare le prestazioni. Sebbene

Common Language Runtime fornisca molti servizi runtime standard, il codice

gestito non viene mai interpretato. Una funzionalità denominata compilazione

9


JIT (Just In Time) consente a tutto il codice gestito di essere eseguito nel

linguaggio macchina nativo del sistema su cui è in esecuzione.

Contemporaneamente, il gestore di memoria impedisce la frammentazione

della memoria e aumenta la rintracciabilità dei riferimenti della memoria per

migliorare ulteriormente le prestazioni.

Runtime può essere infine contenuto da applicazioni lato server a elevate

prestazioni quali Microsoft® SQL Server™ e Internet Information Services

(IIS). Questa infrastruttura consente di utilizzare il codice gestito per scrivere

logica aziendale personalizzata, continuando a sfruttare le prestazioni superiori

dei migliori server aziendali del settore che supportano l'hosting del runtime.

2.3 LIBRERIA DI CLASSI .NET FRAMEWORK

La libreria di classi .NET Framework è un insieme di tipi riutilizzabili che

si integrano strettamente con Common Language Runtime. La libreria di classi

è orientata agli oggetti e fornisce tipi dai quali il codice gestito può derivare le

funzionalità. In questo modo non solo viene semplificato l'utilizzo dei tipi ma

viene anche ridotto il tempo necessario all'apprendimento delle nuove

funzionalità. È inoltre possibile integrare uniformemente i componenti di altri

produttori nelle classi standard di libreria.

I tipi rappresentano gli elementi fondamentali per la generazione di

applicazioni, componenti e controlli. In .NET sono inclusi tipi che consentono

di svolgere le seguenti funzioni:

• Rappresentare tipi di dati ed eccezioni di base.

• Incapsulare strutture di dati.

• Eseguire I/O.

• Accedere a informazioni su tipi caricati.

• Richiamare i controlli di protezione di .NET Framework.

10


Il Framework offre una vasta gamma di interfacce, nonché di classi

astratte e concrete (non astratte). È possibile utilizzare le classi concrete così

come sono oppure, in molti casi, derivare da esse classi personalizzate. Per

avvalersi delle funzionalità di un'interfaccia è possibile creare, oppure derivare

da una delle classi di libreria, una classe che consenta di implementare

l'interfaccia.

Ad esempio, le classi di 'insiemi' realizzano un insieme di interfacce che

possono essere utilizzate per sviluppare classi di insiemi personalizzate. Le

classi di insiemi così costruite si mescoleranno in modo uniforme alle classi

native.

Come ci si aspetta da una libreria di classi orientata agli oggetti, i tipi

consentono di effettuare una gamma di attività comuni di programmazione,

incluse operazioni quali la gestione di stringhe, la raccolta di dati, la

connettività al database e l'accesso a file.

Oltre a queste attività comuni, la libreria di classi include tipi che

supportano vari scenari di sviluppo specializzati.

È ad esempio possibile utilizzare .NET Framework per sviluppare i

seguenti tipi di applicazioni e servizi:

• applicazioni console

• applicazioni GUI Windows (Windows Form)

• applicazioni ASP.NET

• servizi Web XML

• servizi Windows.

Le classi Windows Form ad esempio sono un insieme completo di tipi

riutilizzabili che semplificano ampiamente lo sviluppo di GUI Windows.

11


2.4 SVILUPPO DI APPLICAZIONI CLIENT

Le applicazioni client sono le più vicine allo stile tradizionale delle

applicazioni nella programmazione basata su Windows. Si tratta di tipi di

applicazioni che visualizzano finestre o form sul desktop, consentendo

all'utente di eseguire un'attività.

Le applicazioni client includono elaboratori di testi e fogli di calcolo,

nonché applicazioni aziendali personalizzate quali strumenti di immissione dati,

di generazione di report e così via. Le applicazioni client generalmente

utilizzano finestre, menu, pulsanti e altri elementi GUI e accedono a risorse

locali quali file system e periferiche quali stampanti.

Un altro tipo di applicazione client è il tradizionale controllo ActiveX,

ora sostituito dal controllo Windows Form gestito, distribuito su Internet come

pagina Web. Questa applicazione è molto simile ad altre applicazioni client:

viene eseguita in modo nativo, ha accesso alle risorse locali e include elementi

grafici.

In passato gli sviluppatori creavano tali applicazioni utilizzando C/C++

insieme a MFC (Microsoft Foundation Classes) o a un ambiente RAD (Rapid

Application Development) quale Microsoft® Visual Basic®. Il nuovo

ambiente incorpora aspetti di questi prodotti esistenti in un solo ambiente di

sviluppo coerente che semplifica enormemente lo sviluppo delle applicazioni

client.

Le classi Windows Form sono progettate per essere utilizzate nello

sviluppo di GUI. È possibile creare facilmente finestre di comando, pulsanti,

barre degli strumenti e altri elementi dello schermo con la flessibilità necessaria

per soddisfare le mutevoli esigenze aziendali.

In .NET sono ad esempio disponibili proprietà semplici per regolare gli

attributi visuali associati ai form. In alcuni casi il sistema operativo sottostante

non supporta la modifica diretta di questi attributi, quindi .NET ricrea

12


automaticamente i form. Si tratta di uno dei molti modi in cui il framework

integra l'interfaccia dello sviluppatore, rendendo la codifica più semplice e

coerente.

A differenza dei controlli ActiveX, i controlli Windows Form

dispongono di un accesso semi-trusted al computer dell'utente. Il codice

eseguito in modo binario o nativo può quindi accedere ad alcune risorse del

sistema dell'utente, ad esempio elementi GUI e limitato accesso ai file, ma non

è in grado di accedere ad altre o di comprometterle.

Grazie ai meccanismi di protezione dell'accesso del codice, molte

applicazioni che precedentemente era necessario installare sul sistema

dell'utente possono ora essere distribuite sul Web. È possibile implementare le

funzionalità di un'applicazione locale nelle proprie applicazioni, benché

distribuite come una pagina Web.

2.5 IL COMMON LANGUAGE RUNTIME

I compilatori e gli strumenti dei linguaggi espongono le funzionalità di

Common Language Runtime e consentono di scrivere codice che sfrutta i

vantaggi di tale ambiente di esecuzione gestita.

Il codice sviluppato tramite un compilatore di linguaggio basato su

Common Language Runtime viene definito codice gestito e si avvantaggia di

funzionalità quali l'integrazione tra i linguaggi, la gestione delle eccezioni con

linguaggi diversi, la protezione avanzata, il supporto per il controllo delle

versioni e la distribuzione, un modello semplificato per l'interazione tra

componenti e servizi di debug e di profiling.

Per consentire all'ambiente di esecuzione di fornire servizi al codice

gestito, è necessario che i compilatori di linguaggio generino metadati che

descrivono i tipi, i membri e i riferimenti presenti nel codice.

13


I metadati sono memorizzati con il codice: ogni file eseguibile

trasportabile (PE, Portable Executable) caricabile in Common Language

Runtime contiene metadati. I metadati vengono utilizzati nell'ambiente di

esecuzione per individuare e caricare classi, disporre istanze in memoria,

risolvere chiamate di metodo, generare codice nativo, garantire protezione e

impostare limiti di contesto per la fase di esecuzione.

Il layout degli oggetti e i riferimenti agli oggetti vengono gestiti

automaticamente: quando non sono più in uso, gli oggetti vengono rilasciati.

Gli oggetti la cui durata viene amministrata con queste modalità vengono

denominati dati gestiti. La procedura di Garbage Collection consente di

eliminare il rischio di perdite di memoria e di altri errori comuni di

programmazione.

Se si impiega codice gestito, è possibile utilizzare nell'applicazione .NET

Framework sia dati gestiti sia dati non gestiti, anche simultaneamente. Dal

momento che i compilatori di linguaggio forniscono autonomamente tipi, quali

i tipi primitivi, è possibile che non sempre lo sviluppatore sappia, o abbia

l'esigenza di sapere, se i dati che utilizza sono gestiti.

Common Language Runtime facilita la progettazione di componenti e

applicazioni i cui oggetti interagiscano in contesti di linguaggi diversi. Oggetti

scritti in linguaggi differenti possono infatti interagire e funzionare in modo

strettamente integrato. Una volta definita una classe, ad esempio, è possibile

utilizzare un linguaggio differente per derivarne un'altra classe o per chiamarvi

un metodo.

È anche possibile passare l'istanza di una classe al metodo di una classe

scritta in un linguaggio differente.

Questa integrazione tra linguaggi è possibile perché i compilatori e gli

strumenti dei linguaggi destinati alla fase di esecuzione utilizzano il sistema di

tipi Common Type System, definito dall'ambiente di esecuzione, e seguono le

14


regole di tale ambiente per la definizione di nuovi tipi, oltre che per la

creazione, l'utilizzo, il mantenimento e l'associazione a tipi.

In quanto parte dei rispettivi metadati, tutti i componenti gestiti

contengono informazioni sui componenti e le risorse in base ai quali sono stati

generati. Il runtime utilizza tali informazioni per garantire la disponibilità delle

versioni specificate del software necessario al funzionamento del componente

o dell'applicazione, riducendo così il rischio di interruzioni del codice dovute

all'irreperibilità di alcune dipendenze.

Le informazioni di registrazione e i dati dello stato non vengono più

memorizzati nel Registro di sistema, in cui poteva essere difficile individuarli e

gestirli. Le informazioni sui tipi definiti e sulle relative dipendenze vengono

invece memorizzate con il codice in forma di metadati, semplificando di gran

lunga le attività di replica e rimozione di componenti.

I compilatori e gli strumenti dei linguaggi sono progettati per esporre le

funzionalità del runtime secondo modalità utili e intuitive per gli sviluppatori.

Alcune di queste funzionalità potrebbero quindi essere più evidenti in un

ambiente operativo anziché in un altro.

Il modo di percepire il funzionamento dell'ambiente di esecuzione

dipende dai compilatori o dagli strumenti dei linguaggi utilizzati. Lo

sviluppatore in Visual Basic, ad esempio, potrà rilevare in questo linguaggio

una maggiore presenza di funzionalità orientate agli oggetti, conferitagli da

Common Language Runtime.

Di seguito sono riportati alcuni dei vantaggi del runtime:

• I miglioramenti delle prestazioni.

• La possibilità di utilizzare con facilità componenti sviluppati in altri

linguaggi.

• La disponibilità dei tipi estensibili forniti da una libreria di classi.

15


• Nuove funzionalità di linguaggio: l'ereditarietà, le interfacce e

l'overload, di cui può avvantaggiarsi la programmazione ad oggetti;

il supporto per il threading Free esplicito, che consente la

creazione di applicazioni multithread e scalabili; infine, il supporto

per la gestione strutturata delle eccezioni e gli attributi

personalizzati.

Se si utilizza Microsoft® Visual C++® .NET, è possibile scrivere codice

gestito utilizzando le estensioni gestite per C++, che consentono di sfruttare i

vantaggi di un ambiente di esecuzione gestita continuando ad accedere alle

potenti funzionalità e agli efficaci tipi di dati già noti. Altre funzionalità del

runtime sono:

• L'integrazione tra linguaggi, in particolare l'ereditarietà tra

linguaggi.

• Procedura di Garbage Collection, che consente di gestire la durata

degli oggetti rendendo superfluo il conteggio dei riferimenti.

• Gli oggetti autodescrittivi, che rendono superfluo l'utilizzo del

linguaggio di definizione dell'interfaccia (IDL, Interface Definition

Language).

• La possibilità di compilare il codice una sola volta e di eseguirlo su

qualsiasi CPU e sistema operativo che supporta Common

Language Runtime.

È anche possibile scrivere codice gestito utilizzando il linguaggio C#,

con i seguenti vantaggi:

• Progettazione completamente orientata ad oggetti.

• Efficiente controllo dei tipi.

• Efficace combinazione tra la semplicità di Visual Basic e la

16


potenza di C++.

• Garbage Collection.

• Sintassi e parole chiave analoghe a quelle utilizzate in C e C++.

• Utilizzo dei delegati invece dei puntatori a funzioni con

conseguente miglioramento del controllo e della protezione dei

tipi.

I puntatori a funzione sono disponibili mediante l'utilizzo della parola

chiave di C# unsafe e dell'opzione del compilatore C# (Csc.exe) /unsafe

per il codice e i dati non gestiti.

2.6 CENNI PRELIMINARI SUGLI ASSEMBLY

Gli assembly rivestono un ruolo fondamentale nella programmazione

all'interno del framework.

Un assembly svolge le seguenti funzioni:

• Contiene codice che viene eseguito da Common Language

Runtime. Il codice Microsoft Intermediate Language (MSIL)

contenuto in un file eseguibile portabile (PE, Portable

Executable) non verrà eseguito se ad esso non è associato il

manifesto di un assembly. Si noti che ciascun assembly può

avere un solo punto di ingresso (DllMain, WinMain o Main).

• Costituisce un limite di protezione. Un assembly è l'unità che

riceve e accoglie le richieste di autorizzazione.

• E' un limite per i tipi. L'identità di ogni tipo include il nome

dell'assembly in cui il tipo risiede. Un tipo denominato MyType

caricato nell'ambito di un assembly si distingue da un tipo

denominato MyType caricato nell'ambito di un assembly

17


diverso.

• E' un limite per l'ambito dei riferimenti. Il manifesto

dell'assembly contiene i metadati dell'assembly, che vengono

utilizzati per la risoluzione dei tipi e per soddisfare le richieste di

risorse. Essi specificano i tipi e le risorse che sono esposte

all'esterno dell'assembly. Inoltre, il manifesto enumera altri

assembly da cui dipende.

• Costituisce un limite di versione. L'assembly è la più piccola

unità aggiornabile di Common Language Runtime. Le versioni

di tutti i tipi e di tutte le risorse appartenenti allo stesso

assembly vengono aggiornate in blocco. Il manifesto

dell'assembly descrive le dipendenze di versione che lo

sviluppatore specifica per ciascun assembly dipendente.

• Costituisce un'unità di distribuzione. All'avvio di

un'applicazione, gli unici assembly la cui presenza è

indispensabile sono quelli chiamati dall'applicazione in quel

momento. Gli altri assembly, quali quelli delle risorse di

localizzazione o quelli contenenti classi di utilità, possono

essere recuperati su richiesta. In questo modo è possibile

ottenere applicazioni che al primo download siano semplici e

leggere.

• Costituisce l'unità minima per cui è supportata l'esecuzione

contemporanea di diverse versioni.

Gli assembly possono essere statici o dinamici. Gli assembly statici

possono includere tipi .NET Framework (interfacce e classi), così come risorse

per l'assembly (immagini bitmap, file JPEG, file di risorse e così via). Gli

assembly statici vengono memorizzati sul disco in file eseguibili portabili (PE,

18


Portable Executable).

È anche possibile utilizzare .NET Framework per creare assembly

dinamici che vengono eseguiti direttamente dalla memoria e non richiedono il

preventivo salvataggio su disco. È anche possibile salvare gli assembly dinamici

sul disco dopo averli eseguiti.

Gli assembly possono essere creati in più modi. È possibile utilizzare

strumenti di sviluppo, come Visual Studio .NET, già impiegati per la

generazione di file DLL o EXE.

In alternativa, è possibile utilizzare gli strumenti forniti con .NET

Framework SDK per generare assembly con moduli creati in altri ambienti di

sviluppo. Infine, è possibile creare assembly dinamici utilizzando librerie API

di CLR come Reflection.Emit.

2.7 CONVENZIONI DI DENOMINAZIONE

Nei tipi di .NET Framework è utilizzato uno schema di denominazione

con sintassi a punti che definisce una gerarchia.

Secondo questa tecnica i tipi correlati vengono raggruppati in spazi dei

nomi, in modo da semplificarne le ricerche e i riferimenti. La prima parte del

nome completo, fino al primo punto da destra, è il nome dello spazio dei

nomi.

L'ultima parte del nome è il nome del tipo

System.Collections.ArrayList, ad esempio, rappresenta il tipo ArrayList,appartenente allo spazio dei nomi System.Collections. I tipi di

System.Collections possono essere utilizzati per manipolare insiemi di

oggetti.

Questo schema di denominazione è vantaggioso per gli sviluppatori di

librerie che desiderano estendere .NET Framework poiché consente di creare

19


gruppi gerarchici di tipi e denominarli in modo coerente utilizzando nomi di

immediata comprensione. Nella denominazione degli spazi dei nomi è

opportuno che gli sviluppatori di librerie rispettino il seguente schema:

NomeSocietà.NomeTecnologia

Lo spazio dei nomi Microsoft.Word, ad esempio, è conforme a questa

convenzione.

Il ricorso a schemi di denominazione per raggruppare dei tipi correlati

all'interno di spazi dei nomi è un metodo estremamente utile per generare e

documentare librerie di classi.

Questo schema di denominazione non ha tuttavia alcun effetto sulla

visibilità, sull'accesso ai membri, sull'ereditarietà, sulla sicurezza o

sull'associazione.

Gli spazi dei nomi possono essere ripartiti tra più assembly e un singolo

assembly può contenere tipi provenienti da spazi dei nomi differenti.

L'assembly fornisce la struttura formale per la creazione di versioni

successive, la distribuzione, la protezione, il caricamento e la visibilità in

Common Language Runtime.

2.8 SPAZIO DEI NOMI SYSTEM

Lo spazio dei nomi System è lo spazio dei nomi di primo livello per i tipi

fondamentali di .NET Framework.

Questo spazio dei nomi include classi che rappresentano i tipi di dati di

base utilizzati da tutte le applicazioni: Object (il primo livello nella gerarchia

dell'ereditarietà), Byte, Char, Array, Int32, String e così via. Molti di questi tipi corrispondono ai tipi di dati primitivi utilizzati dal

20


linguaggio di programmazione. Quando si scrive il codice utilizzando tipi del

Framework è possibile utilizzare la corrispondente parola chiave del linguaggio

utilizzato dove è previsto un tipo di dati di base di .NET Framework.

Nella tabella che segue sono elencati alcuni dei tipi di valori forniti dal

Framework; per ogni tipo viene fornita una breve descrizione e viene indicato

il tipo corrispondente in Visual Basic, in C# e nelle estensioni gestite per C++.

La tabella include anche voci relative alle classi Object e String, per le quali

sono disponibili parole chiave corrispondenti in numerosi linguaggi.

Categoria Nome di classe Descrizione Tipo di dati di C#Integer Byte Un valore integer senza segno a 8 bit. byte

SByteUn valore integer con segno a 8 bit.

Non compatibile con CLS.sbyte

Int16 Un valore integer con segno a 16 bit. shortInt32 Un valore integer con segno a 32 bit. intInt64 Un valore integer con segno a 64 bit. long

UInt16Un valore integer senza segno a 16 bit.

Non compatibile con CLS.ushort


Non compatibile con CLS.uint


Non compatibile con CLS.ulong

A virgola mobile SingleUn numero a virgola mobile e precisione

singola a 32 bit.float

DoubleUn numero a virgola mobile e precisione

doppia a 64 bit.double

Logica Boolean Un valore Boolean (true o false). boolAltro Char Un carattere Unicode (a 16 bit). char

Decimal Un valore decimale a 96 bit. decimal

IntPtr

Un numero intero con segno la cui

dimensione dipende dalla piattaforma

sottostante (un valore a 32 bit su una

piattaforma a 32 bit e un valore a 64 bit su

una piattaforma a 64 bit).

IntPtr

Nessun tipo specifico

fornito dal linguaggio.

UIntPtr

Un numero intero senza segno la cui

dimensione dipende dalla piattaforma

sottostante (un valore a 32 bit su una

piattaforma a 32 bit e un valore a 64 bit su

una piattaforma a 64 bit).

Non compatibile con CLS.

UIntPtr

Nessun tipo specifico

fornito dal linguaggio.

Oggetti Class Object Il primo livello della gerarchia di oggetti. object

21


StringUna stringa di caratteri Unicode immutabile

e a lunghezza fissa.string

Oltre ai tipi di dati di base, lo spazio dei nomi System contiene quasi 100

classi, da quelle che gestiscono le eccezioni a quelle correlate a concetti

fondamentali della fase di esecuzione, quali i domini di applicazione e Garbage

Collector.

Lo spazio dei nomi System contiene inoltre numerosi spazi dei nomi di

secondo livello.

2.9 SPAZIO DEI NOMI SYSTEM.WINDOWS.FORMS

Lo spazio dei nomi System.Windows.Forms contiene classi per la

creazione di applicazioni Windows che sfruttano le notevoli funzioni

dell'interfaccia utente disponibili nel sistema operativo Microsoft Windows.

Le classi di questo spazio dei nomi possono essere raggruppate nelle

seguenti categorie:

• Controllo, controllo utente e controlli del form. La maggior parte delle classi all'interno dello spazio dei

nomi System.Windows.Forms deriva dalla classe Control. La

classe Control fornisce la funzionalità base per tutti i controlli

visualizzati su un Form.

La classe Form rappresenta una finestra all'interno di

un'applicazione. Questa classe comprende finestre di dialogo,

finestre non modali e finestre client e padri MDI (Multiple

Document Interface).

Per creare un controllo personalizzato composto da altri

controlli, utilizzare la classe UserControl.• Controlli.

22


Lo spazio dei nomi System.Windows.Forms fornisce una

serie di classi di controlli che consentono la creazione di interfacce

utente complesse. Alcuni controlli sono progettati per

l'inserimento dei dati all'interno dell'applicazione, come i controlli

TextBox e ComboBox. In altri controlli sono visualizzati i dati testuali e tabellari

dell'applicazione, come Label e ListView.

Windows Forms fornisce anche controlli per la chiamata di

comandi all'interno dell'applicazione, come Button e ToolBar.Inoltre, il controllo PropertyGrid può essere utilizzato per creare

una finestra di progettazione Windows Form personalizzata in cui

vengono visualizzate le proprietà dei controlli visibili in tale

finestra.

• Components. Oltre ai controlli, lo spazio dei nomi

System.Windows.Forms fornisce altre classi non derivate dalla

classe Control ma che forniscono funzionalità visive per

un'applicazione basata su Windows. Alcune classi, come ToolTipe ErrorProvider, estendono le funzionalità o forniscono

informazioni all'utente. Altre classi, come Menu, MenuItem e

ContextMenu, consentono di visualizzare menu per il richiamo di

comandi nell'applicazione. Le classi Help e HelpProviderconsentono la visualizzazione di informazioni della guida per gli

utenti delle applicazioni.

• Common Dialog Boxes.

In Windows viene fornita una serie di finestre di dialogo

comuni che è possibile utilizzare per dotare l'applicazione di

un'interfaccia utente uniforme quando si eseguono attività come

23


l'apertura e il salvataggio dei file, la modifica dei caratteri o del

colore del testo oppure la stampa.

Le classi OpenFileDialog e SaveFileDialog consentono

di visualizzare una finestra di dialogo che permette la ricerca e

l'immissione del nome del file da aprire o da salvare.

La classe FontDialog consente la visualizzazione di una

finestra di dialogo per la modifica degli elementi dell'oggetto Fontutilizzato dall'applicazione.

Le classi PageSetupDialog, PrintPreviewDialog e

PrintDialog consentono la visualizzazione di finestre di dialogo

con le quali è possibile controllare l'aspetto dei documenti da

stampare.

Oltre alle finestre di dialogo comuni, lo spazio dei nomi

System.Windows.Forms fornisce la classe MessageBox per

l'apertura di una finestra di messaggio in cui vengono visualizzati e

richiesti dati da immettere.

Nello spazio dei nomi System.Windows.Forms è

disponibile una serie di classi che fornisce supporto alle classi

descritte nel riepilogo precedente.

Esempi di classi di supporto sono le enumerazioni, le classi

di argomenti dell'evento e i delegati utilizzati dagli eventi nei

controlli e nei componenti.

24


2.10 LE CLASSI .NET OPENSOURCE IN LINGUAGGIO C#Per facilitare lo sviluppo dell'applicazione, sono state reperite delle classi

attingendo alle librerie di codice OpenSource presenti sul sito

www.codeproject.com.

Queste classi integrano la libreria di sistema, consentendo funzionalità

più avanzate e un aspetto grafico più gradevole ed attuale. Alcune peculiarità

nell'uso del Framework sono state utili per comprendere ed usare ancor meglio

il linguaggio e le capacità espressive del nuovo ambiente.

• LISTVIEWEX

La classe è principalmente utilizzata per la gestione della TaskList e

realizza una ListView classica in cui è possibile inserire in ciascuna riga

dei controlli quali bottoni o immagini.

La classe originale è stata modificata per consentire la rimozione a caldo

degli oggetti singoli ed è stata aggiunta la capacità di associare un oggetto

a ciascuna riga della ListView.

• IPLUGININTERFACE

E' sicuramente il progetto più importante da cui sono state attinte

informazioni e tecniche sull'uso effettivo della Reflection in ambiente .

NET. Dalla implementazione originale sono state presi i punti cardine

sulla definizione di interfacce e sui metodi per effettuare il Late Binding

di assembly a Run-Time, di cui sono riportati nei capitoli successivi

alcuni stralci di codice.

• NICEMENU

Il menu standard fornito dall'ambiente di sviluppo è risultato inefficace

per gli scopi dell'applicazione, in quanto l'handler dei menu è

generalmente fissato in fase di disegno; ciò non è pensabile in una

25


applicazione che ha come punto di forza la scalabilità e l'uso di plugin,

che impone invece una ridefinizione dei menu e delle relative azioni in

fase di esecuzione del programma.

E' stato perciò necessario reperire un diverso tipo di menu derivato che

consenta di associare a ciascun item di menu un oggetto, o meglio nel

nostro caso, un tipo di oggetto che rappresenta il plugin richiesto.

Il menu NiceMenu presenta questa particolarità ed ha oltretutto un

aspetto in linea con le nuove interfacce grafiche, per cui l'utilizzo è stato

preferito al menu standard di .NET.

• SPLASH

Non c'è applicazione che si rispetti che non presenti uno schermo di

apertura, detto splash screen, che in qualche modo riassume in una sorta

di marchio la filosofia del programma.

Per realizzare lo splash screen di EidosLab sono state utilizzate come

modello alcune classi di esempio che fanno uso di alcune tecniche

grafiche, quali l'opacità di una form, per rendere accativante lo startup

del programma.

• EXOCORTEX.DSPQuesto ottimo esempio di libreria è servito da base per lo sviluppo dei

buffer nel campo complesso, in quanto i numeri complessi non sono

parte nativa del linguaggio C#.

La libreria offre già la trasformate FAST di Fourier ed è stata integrata

con la trasformata classica DFT e la trasformata DCT.

• SHARPPDFQuesta classe è la base per lo sviluppo del plugin di salvataggio in PDF

delle immagini, anche questa libreria è stata integrata con alcune

26


modifiche per renderla più aderente alle necessità di EidosLab

Molte altre idee e suggerimenti sono stati presi da un numero altissimo di

progetti il cui codice è messo a disposizione su vari siti, ma alle volte sono

piccoli indirizzi e alle volte grandi chiarimenti sull'uso di uno strumento nuovo

e ancora oscuro, quale .NET e C#.

L'uso di software opensource spinge naturalmente a rendere anche

EidosLab uno strumento opensource tramite la creazione di un sito apposito

su cui condividere il sorgente elaborato.

27


3 LO STANDARD XML

L’XML è un linguaggio di markup aperto e basato su testo che fornisce

informazioni di tipo strutturale e semantico relative ai dati veri e propri.

Questi "dati sui dati", o metadati, offrono un contesto aggiuntivo

all’applicazione che utilizza i dati e consente un nuovo livello di gestione e

manipolazione delle informazioni basate su Web.

3.1 ORIGINE E OBIETTIVI L’Extensible Markup Language (XML) è un metalinguaggio che

permette di creare dei linguaggi personalizzati di markup; nasce dall’esigenza di

portare nel World Wide Web lo Standard Generalized Markup Language

(SGML), lo standard internazionale per la descrizione della struttura e del

contenuto di documenti elettronici di qualsiasi tipo; ne contiene quindi tutta la

potenza, ma non tutte le complesse funzioni raramente utilizzate. Si

caratterizza per la semplicità con cui è possibile scrivere documenti,

condividerli e trasmetterli nel Web.

L’utilizzo di XML permette di superare il grosso limite attuale del Web,

che è quello della dipendenza da un tipo di documento HTML, singolo e non

estensibile. Questo linguaggio è nato per permettere agli utenti del World Wide

Web di condividere le informazioni su sistemi differenti; il presupposto era che

quelle informazioni fossero testo con al più alcune immagini e collegamenti

ipertestuali..

Attualmente però, le informazioni sul World Wide Web sono database

di testo, immagini, suoni, video, audio. Quindi l’HTML è stato chiamato

28


sempre più di frequente a fornire soluzioni a problemi che non aveva lo scopo

di risolvere, come dover descrivere tipi differenti e specifici di informazioni,

definire relazioni complesse di collegamenti fra documenti, trasmettere

informazioni in diversi formati.

Per superare questi problemi, sono state create delle estensioni

dell’HTML, spesso fra loro incompatibili.

L’XML permette a gruppi di persone o ad organizzazioni di creare il

proprio linguaggio di markup, specifico per il tipo di informazione che

trattano; per molte applicazioni e per diversi settori, gli esperti hanno già creato

linguaggi di markup specifici, come ad esempio il Channel Definition Format,

il Mathematical Markup Language ed altri

XML è stato sviluppato dall' XML Working Group (originariamente

noto come SGML Editorial Review Board) costituitosi sotto gli auspici del

World Wide Web Consortium (W3C) nel 1996. Esso era presieduto da Jon

Bosak della Sun Microsystems con la partecipazione attiva dell’XML Special

Interest Group (precedentemente noto come SGML Working Group)

29


anch’esso organizzato dal W3C.

L’obiettivo di questo gruppo di lavoro era di portare il linguaggio SGML

nel Web. L’SGML è un linguaggio per la specifica dei linguaggi di markup ed è

il genitore del ben noto HTML.

La progettazione dell’XML venne eseguita esaminando i punti di forza e

di debolezza dell’SGML. Il risultato è uno standard per i linguaggi di markup

che contiene tutta la potenza dell’SGML ma non tutte le funzioni complesse e

raramente utilizzate. L’XML venne mostrato per la prima volta al pubblico

quando l’SGML celebrò il suo decimo anno.

Gli obiettivi progettuali di XML sono riassumibili in:

• XML deve essere utilizzabile in modo semplice su Internet: in

primo luogo, l’XML deve operare in maniera efficiente su Internet

e soddisfare le esigenze delle applicazioni eseguite in un ambiente

di rete distribuito.

• XML deve supportare un gran numero di applicazioni: deve essere

possibile utilizzare l’XML con un’ampia gamma di applicazioni, tra

cui strumenti di creazione, motori per la visualizzazione di

contenuti, strumenti di traduzione e applicazioni di database.

• XML deve essere compatibile con SGML: questo obiettivo è stato

definito sulla base del presupposto che un documento XML valido

debba anche essere un documento SGML valido, in modo tale che

gli strumenti SGML esistenti possano essere utilizzati con l’XML e

siano in grado di analizzare il codice XML.

• Deve essere facile lo sviluppo di programmi che elaborino

documenti XML: l’adozione del linguaggio è proporzionale alla

disponibilità di strumenti e la proliferazione di questi è la

dimostrazione che questo obiettivo è stato raggiunto.

• Il numero di caratteristiche opzionali deve essere mantenuto al

30


minimo possibile: al contrario dell’SGML, l’XML elimina le

opzioni, in tal modo qualsiasi elaboratore potrà pertanto analizzare

qualunque documento XML, indipendentemente dai dati e dalla

struttura contenuti nel documento.

• I documenti XML dovrebbero essere leggibili da un utente e

ragionevolmente chiari: poiché utilizza il testo normale per

descrivere i dati e le relazioni tra i dati, l’XML è più semplice da

utilizzare e da leggere del formato binario che esegue la stessa

operazione; inoltre poiché il codice è formattato in modo diretto, è

utile che l’XML sia facilmente leggibile da parte sia degli utenti sia

dei computer.

• La progettazione di XML dovrebbe essere rapida: l’XML è stato

sviluppato per soddisfare l’esigenza di un linguaggio estensibile per

il Web. Questo obiettivo è stato definito dopo aver considerato

l’eventualità che se l’XML non fosse stato reso disponibile

rapidamente come metodo per estendere l’HTML, altre

organizzazioni avrebbero potuto provvedere a fornire una

soluzione proprietaria, binaria o entrambe.

• La progettazione di XML deve essere formale e concisa: questo

obiettivo deriva dall’esigenza di rendere il linguaggio il più

possibile conciso, formalizzando la formulazione della specifica.

• I documenti XML devono essere facili da creare: i documenti

XML possono essere creati facendo ricorso a strumenti di

semplice utilizzo, quali editor di testo normale.

Non è di nessuna importanza l’economicità nel markup XML:

nell’SGML e nell’HTML la presenza di un tag di apertura è sufficiente per

segnalare che l’elemento precedente deve essere chiuso.

31


Benché così sia possibile ridurre il lavoro degli autori, questa soluzione

potrebbe essere fonte di confusione per i lettori, nell’XML la chiarezza ha in

ogni caso la precedenza sulla concisione.

L’XML può essere utilizzato come piattaforma per lo scambio di dati tra

le applicazioni, come mostra la figura seguente; ciò è reso possibile perché il

linguaggio è orientato alla descrizione dei dati.

Poniamo il caso che si voglia scambiare le informazioni di database su

Internet.

Si immagini di utilizzare un browser per rinviare al server le

informazioni su un questionario compilato dagli utenti.

Questo processo, come molti altri, richiede un formato che possa essere

personalizzato per un utilizzo specifico e che sia una soluzione aperta non

proprietaria.

L’XML è in grado di fornire una sola piattaforma per lo scambio di dati

tra le applicazioni.

E' sempre stato difficile trovare un formato di interscambio che potesse

essere utilizzato per il trasferimento di dati tra database di fornitori differenti e

sistemi operativi diversi. Quel tipo di interscambio è ora diventato una delle

applicazioni principali dell’XML.

32


3.2 STRUTTURA LOGICA DEL LINGUAGGIO XML La struttura logica fa riferimento all’organizzazione delle parti di un

documento: in altre parole, indica il modo in cui viene creato un documento in

contrapposizione al contenuto del documento stesso.

Un documento XML è costituito da dichiarazioni, elementi, istruzioni di

elaborazione e commenti. Alcuni componenti sono opzionali, altri sono

necessari.

3.3 PROLOGO DI UN DOCUMENTO XMLIl primo elemento strutturale di un documento XML è un prologo

opzionale, costituito da due componenti principali anch’essi opzionali: la

dichiarazione XML e la dichiarazione del tipo di documento.

• Dichiarazione XMLLa dichiarazione XML identifica la versione delle specifiche XML a cui è

conforme il documento. Sebbene la dichiarazione XML sia un elemento

opzionale, deve sempre essere inserita in documento XML. Il documento

inizia con una dichiarazione XML di base:

<?xml version="1.0"?>

Una dichiarazione XML può inoltre contenere una dichiarazione di

codifica (encoding) e una dichiarazione di documento autonomo (standalone).

La dichiarazione di codifica identifica lo schema di codifica dei caratteri, ad

esempio UTF-8 o EUC-JP. Schemi di codifica diversi assegnano formati di

caratteri o linguaggi diversi. La dichiarazione di documento autonomo

identifica l’esistenza delle dichiarazioni di markup esterne al documento.

33


Questo tipo di dichiarazione può assumere valore yes o no.

• Dichiarazione di tipo di Documento La dichiarazione del tipo di documento è costituita da codice di markup

che indica le regole grammaticali o la definizione del tipo di documento DTD

per una particolare classe di documenti. Questa dichiarazione può anche essere

diretta a un file esterno che contiene tutta o parte della DTD e deve essere

visualizzata dopo la dichiarazione XML e prima dell’elemento Document.

Queste stringhe di codice aggiungono una dichiarazione del tipo di documento

all’esempio:


<!DOCTYPE Wildflowers SYSTEM "Wldflr.dtd">

3.4 L’ELEMENTO DOCUMENT

L’elemento Document contiene tutti i dati di un documento XML inclusi

tutti i sottoelementi nidificati e le entità esterne. Può essere considerato simile

all’unità C: del computer. Tutti i dati del computer sono memorizzati in questa

singola unità in cui le cartelle e le sottocartelle contengono le singole parti di

dati in una struttura logica e di semplice gestione. Queste stringhe di codice

aggiungono un elemento Document, in questo caso l’elemento Plant

all’esempio:<?xml version="1.0"?>


<PLANT>

<COMMON>Columbine</COMMON>

<BOTANICAL>Aquilegia canadensis</BOTANICAL>

</PLANT>

34


La nidificazione è il processo che consente di incorporare un oggetto o

un costrutto l’uno all’interno dell’altro. Un documento XML può ad esempio

contenere elementi nidificati e altri documenti. Ogni elemento secondario, cioè

un elemento diverso dall’elemento Document risiede interamente all’interno

del relativo elemento principale:<DOCUMENT>

<PARENT1>

<CHILD1></CHILD1>

<CHILD2></CHILD2>

</PARENT1>

</DOCUMENT>

3.5 APERTURA E CHIUSURA DEI TAG

Nel codice HTML un elemento contiene in genere sia tag di apertura che

di chiusura. A differenza dell’HTML, l’XML richiede che un tag di chiusura

venga utilizzato per ogni elemento.

Si consideri ad esempio l’elemento HTML Paragraph che dovrebbe in

genere includere un tag di apertura, il contenuto e un tag di chiusura come

mostrato di seguito:

<P>Questo è un elemento HTML Paragraph.</P>

Non sempre viene utilizzato un tag di chiusura in questo contesto.

Questo avviene perché l’HTML e il linguaggio di origine SGML consentono di

omettere i tag di chiusura senza invalidare il codice.

Poiché un paragrafo in HTML non può essere annidato all’interno di un

35


altro paragrafo, l’elaboratore è in grado di leggere il tag di apertura del

paragrafo e di presumere che indichi anche la fine del paragrafo precedente.

Queste tecniche di minimizzazione non sono consentite nel linguaggio XML.

Questa caratteristica costituisce la differenza sintattica più evidente tra i due

linguaggi.

3.6 IL TAG DI ELEMENTO VUOTO

Il linguaggio XML supporta un collegamento per elementi vuoti, il tag di

elemento vuoto. Questo tag unisce i tag di apertura e di chiusura per un

elemento senza alcun contenuto. Viene utilizzato un formato speciale:

<NOMETAG/>. In questo caso la barra segue il nome del tag, il che non è

possibile nel linguaggio HTML.

3.7 ATTRIBUTI

Gli attributi consentono di associare valori a un elemento senza che

siano considerati parte del contenuto dell’elemento stesso. Ad esempio

osserviamo un comune elemento HTML e l’utilizzo di un attributo:

<A HREF = "http://www.microsoft.com">MS HomePage</A>

In questo caso l’elemento Anchor indicato dal tag <A> contiene un

attributo denominato HREF.

Il valore dell’attributo è http://www.microsoft.com.

Mentre il valore non viene mai visualizzato dall’utente, l’attributo

contiene importanti informazioni relative all’elemento e fornisce la

destinazione dell’ancoraggio. Questo formato del nome e del valore mostra il

modo in cui sono utilizzati gli attributi nel linguaggio XML.

36


Questo esempio aggiunge un attributo a uno degli elementi del

documento:<?xml version="1.0"?>


<PLANT ZONE=3>

<COMMON>Columbine</COMMON>

<BOTANICAL>Aquilegia canadensis</BOTANICAL>

</PLANT>

L’attributo ZONE del tag di apertura <PLANT> segue il formato del

nome e del valore.

3.8 DOCUMENTI XML VALIDI E BEN FORMATI

Il linguaggio XML possiede due caratteristiche fondamentali, la capacità

di fornire una struttura ai documenti e di rendere i dati autodescrittivi. Queste

caratteristiche non sarebbero di alcuna utilità se non si potessero far rispettare

le regole strutturali e grammaticali.

• Documenti validiLa definizione del tipo di documento DTD specificata nel prologo

delinea tutte le regole relative a un documento. Un documento XML valido

segue tutte queste regole rigidamente.

Un documento valido è conforme anche a tutti i limiti di validità

identificati dalle specifiche relative all’XML.

L’elaboratore dovrà comprendere i limiti di validità delle specifiche XML

e verificare possibili violazioni all’interno del documento. Se l’elaboratore trova

un errore, deve comunicarlo all’applicazione XML.

Dovrà inoltre leggere la DTD, convalidare il documento e riportare

qualsiasi violazione all’applicazione XML. Dato che questi controlli possono

37


richiedere tempo e occupare larghezza di banda e poiché la convalida non

sempre è necessaria, il linguaggio XML supporta la nozione di documento ben

formato.

• Documenti ben formati Anche se ben formato significa che è necessario seguire alcune regole,

non è richiesta la stessa rigidità dei limiti di validità. Il concetto di documento

ben formato è relativamente nuovo in XML.

Un documento XML ben formato è più facile da leggere per un

programma ed è pronto per la distribuzione in rete. Più specificatamente, i

documenti ben formati hanno queste caratteristiche:

• tutti i tag di apertura e di chiusura corrispondono.

• i tag vuoti utilizzano una sintassi XML speciale.

• tutti i valori degli attributi sono racchiusi tra virgolette.

• tutte le entità sono dichiarate.

Quindi, un documento XML valido rispetta i tag e le norme di

nidificazione impostate nel DTD del documento, mentre un documento XML

ben formato viene strutturato in modo appropriato per l’utilizzo da parte di un

computer.

3.9 L' XML DOCUMENT DI UNA TASKLIST EIDOSLAB

EidosLab prevede la definizione dell'elenco delle operazioni che

descrivono un processo di elaborazione delle immagini. Le operazioni inserite

nell'elenco sono successivamente eseguite dall'applicazione per realizzare

concretamente il processo di elaborazione voluto.

38


All'interno di EidosLab è possibile salvare, richiamare e interagire con

l'elenco delle operazioni, chiamata TaskList, al fine di realizzare gli schemi di

elaborazione delle immagini partendo dalle funzionalità presenti

nell'applicazione stessa.

Per poter garantire il massimo della interoperabilità tra EidosLab e altre

applicazioni, la TaskList è salvata in formato XML.

Questa scelta ha il pregio di consentire all'utente un utilizzo della

TaskList all'interno di pubblicazioni, unendo alla definizione XML una

trasformazione XSL della TaskList, rendendola così leggibile e comprensibile.

Nell'esempio seguente è descritta una TaskList che carica una immagine

in un buffer e ne produce la trasformata di Fourier diretta ed inversa.<?xml version="1.0"?>



<EIDOSLAB TaskListType="XmlFile" Release="1.0">

<ACTIONS>

<ACTION PluginName="File.LoadImage" PluginVersion="1.0.0" Iteration="1">

<?xml version="1.0" encoding="utf-16"?>

<LoadImage xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<_conf_path>C:\Documents and Settings\rabser\Documenti\Visual Studio

Projects\EidosDevel\immagini\camera.jpg</_conf_path>

<_conf_bufferName>camera.jpg</_conf_bufferName>

<_conf_configured>true</_conf_configured>

</LoadImage>

</ACTION>

<ACTION PluginName="Transform.DirectFFT" PluginVersion="1.0.1" Iteration="1">


<DirectFFT xmlns:xsd="http://www.w3.org/2001/XMLSchema"



<_conf_createNewBuffer>true</_conf_createNewBuffer>

<_conf_bufferToProcess>camera.jpg</_conf_bufferToProcess>

39


</DirectFFT>

</ACTION>

<ACTION PluginName="Transform.InverseFFT" PluginVersion="1.0.1" Iteration="1">


<InverseFFT xmlns:xsd="http://www.w3.org/2001/XMLSchema"



<_conf_createNewBuffer>true</_conf_createNewBuffer>

<_conf_bufferToProcess>Transform.DirectFFT(camera.jpg)

</_conf_bufferToProcess></InverseFFT>

</ACTION>

</ACTIONS>

</EIDOSLAB>

Il documento XML è well-formed e presenta sempre un elemento di

root denominato EIDOSLAB che identifica il tipo di file e la versione

dell'applicazione che lo ha generato.

I nodi all'interno sono elementi ACTION che fanno parte di un unico

elemento ACTIONS che raggruppa quindi tutte le operazioni che

compongono il processo di elaborazione.

Ogni ACTION rappresenta una singola funzionalità e presenta un

insieme di parametri che la identificano.

Una ACTION è identificata dal nome del plugin che realizza la funzione

richiesta e dalla versione del plugin stesso; per ogni azione è inoltre definito il

numero di volte che deve essere eseguito con l'attributo iteration.La parte di testo interna ad ogni singolo nodo ACTION è la

serializzazione dell'istanza della classe del plugin secondo gli schemi XML di .

NET ; al momento del caricamento della TaskList sarà reistanziato l'oggetto

della classe del plugin richiesto utilizzando i metodi nativi di de-serializzazione.

Vista la semplicità della struttura XML della TaskList risulta immediata la

40


possibilità di modificare, prelevare e strutturare le informazioni in essa

contenute, al fine di creare serie di esperimenti da eseguire in batch oppure per

estrarre le informazioni di elaborazione relative ad un esperimento risultato

particolarmente efficace.

41


4 L'ELABORAZIONE NEL DOMINIOTRASFORMATO: LA TRASFORMATA DI FOURIER

Come noto l'elaborazione di immagini può avvenire sia nel dominio

spaziale, in cui un'immagine è considerata come distribuzione di livelli di

luminanza, sia in quello delle frequenze in cui si studia lo spettro di frequenza

che caratterizza la ripetizione dei valori dei pixel.

Lo spettro di frequenza può essere facilmente elaborato selezionando gli

intervalli di frequenza in modo da ottenere filtri che taglino le basse o le alte

frequenze in forma selettiva.

In questo modo sono permesse alcune elaborazioni non ottenibili nel

dominio spaziale, mentre altre risultano più facili e precise.

Va detto comunque che i due domini si integrano nel senso che alcuni

problemi devono essere affrontati nel dominio spaziale (si pensi alle LUT e agli

pseudocolori), mentre altri necessitano di quello trasformato (la separazione

della trama di un tessuto dall'impronta).

Il classico dominio trasformato è quello di Fourier, per cui è a questo che

si farà riferimento nel seguito.

La Trasformata di Fourier bi-dimensionale discreta si esprime come segue:

La funzione a due variabili f(x,y) si può considerare, a tutti gli effetti,

discretizzata su di una matrice fx,y di dimensione NxM. Le variabili u e v

42

( ) ( )1-M ... 0,1 = 1-N ... 0,1 =

con ,,1,1

0

21

0 vu

eyxfNM

vuFN

x

Mvy

NuxiM

y∑∑

−

=

+−−

==

π


rappresentano gli indici relativi agli assi delle frequenze discretizzati, mentre M

e N sono le dimensioni in pixel dell’immagine.

Quindi il campionamento della f(x,y) ha luogo nei punti di una griglia

bidimensionale con passi ∆x e ∆y. La relazione tra gli intervalli di

campionamento, a questo punto, è la seguente: ∆u = 1/(M∆x) e ∆v=1/(N∆y).

Come intuibile gli intervalli spaziali di campionamento risultano

tipicamente unitari.

L’Antitrasformata di Fourier bi-dimensionale discreta si può esprimere

come segue:

Nella trasformata di Fourier, tutti i valori della funzione (immagine) di

partenza f(x,y) contribuiscono alla costruzione di ciascuno dei campioni della

trasformata F(u,v).

Per converso, tutti i campioni della trasformata contribuiscono, nell’anti-

43

( ) ( )1-M ... 0,1 = 1-N ... 0,1 =

con ,,,1

0

21

0 yx

evuFyxfN

u

Mvy

NuxiM

v∑ ∑

−

=

+−

=

=π


trasformazione, alla ricostruzione di ciascuno dei valori della funzione

(immagine) di partenza.

Questo implica che se nel processo di anti-trasformazione si trascurano

arbitrariamente dei campioni associati alle frequenze che apparentemente

apportano minor contributo all’immagine, si riduce il contenuto informativo

dell’immagine di partenza, incidendo fortemente sulla fedeltà dell’immagine

stessa.

L’immagine di partenza, in questi casi risulta alterata, ad esempio può

risultare sfocata se si trascurano i contributi delle alte frequenze, o viceversa

apparire nei suoi contorni più marcati qualora si trascurino le basse frequenze.

Questo aspetto, così rilevante per le valutazioni di tipo numerico sulla

trasformata, è il principio alla base del quale operano i filtri di taglio sulle

frequenze.

Nel dominio di Fourier, un’immagine è ottenuta attraverso la

composizione di immagini di base e delle relative componenti reali e

immaginarie. Le componenti reali danno luogo ad immagini cosinusoidali pari

mentre le componenti immaginarie danno luogo ad immagini sinusoidali

dispari.

Le immagini sinusoidali e cosinusoidali espresse in frequenze diverse e

opportunamente pesate attraverso idonei coefficienti, sommate tra loro

rappresentano l’immagine originale scomposta nei suoi contributi di frequenza.

44


Le componenti cosinusoidali, essendo immagini pari, contribuiranno alla

componente reale dello spettro. Le componenti sinusoidali, essendo immagini

dispari, contribuiranno alla componente immaginaria dello spettro.

4.1 RAPPRESENTAZIONE DELLE TRASFORMATE DI FOURIER

Uno dei problemi più significativi nel trattamento delle trasformate è

quello della loro rappresentazione.

In generale è troppo gravoso un esame diretto delle matrici

bidimensionali di numeri complessi e di notevoli dimensioni per cui una

possibilità consiste nel rappresentare le matrici numeriche delle trasformate

come immagini.

Dal punto di vista analitico, la grandezza alla quale si presta maggiore

attenzione è lo spettro di Fourier (valore assoluto della trasformata) o lo

spettro di energia (il quadrato dello spettro di Fourier).

Entrambe le grandezze mostrano come l’intensità luminosa (o meglio

45


l’energia) venga ripartita sulle diverse frequenze.

A titolo esemplificativo si riporta un’immagine con i relativi spettri di

ampiezza e fase.

Nella rappresentazione riportata, l’immagine di partenza ha dimensione

M=N=256 pixel e quantizzazione pari a 256 livelli di grigio. Lo spettro di

ampiezza non è lineare ma è rappresentato da una versione compressa

logaritmicamente.

Nella rappresentazione grafica degli spettri uno dei problemi ricorrenti è

costituito dal fatto che tali grandezze presentano solitamente valori molto

elevati concentrati attorno all’origine degli assi (basse frequenze), mentre i

valori decrescono rapidamente con il progressivo allontanamento dall’origine

degli assi (alte frequenze).

Lo spettro di Fourier manifesta una dinamica di valori molto più elevata

di quella riproducibile attraverso le scale di colore comunemente disponibili sui

viewport (ad esempio la scala ad 8 bit di colore corrispondenti a 256 livelli di

luminanza) per cui, effettuando le debite normalizzazioni di scala, solo un

numero limitato di dettagli dello spettro risultano visibili.

Nell’immagine rappresentata, ad esempio, lo spettro dell’immagine varia

da 0 a 6.47x106.

Le soluzioni adottate per questo tipo di problematica sono tipicamente

46


due. La prima consiste nel moltiplicare i valori dello spettro per la loro distanza

dall’origine degli assi, espressa dall’espressione seguente:

Un secondo modo di procedere è quello di operare una trasformazione

logaritmica sull’immagine dello spettro, del tipo:

Questa trasformazione presenta il duplice vantaggio di conservare gli zeri

della funzione |F(u,v)|, evidenziando, contemporaneamente i valori minori

dello spettro rispetto a quelli maggiori, permettendo, in molti casi, di

rappresentare una dinamica decisamente più ampia di valori su di uno stesso

spettro.

L’esaltazione dei valori più bassi rispetto a quelli più alti è controllata dal

fattore di scala z: quanto maggiore è il rapporto tra il valore massimo e quello

minimo nello spettro, tanto più grande deve essere il valore assunto dal fattore

di scala z. Lo spettro modificato risulta una compressione logaritmica dello

spettro originale.

In generale, una trasformazione come la DFT altera il dominio in cui è

rappresentata l'immagine ed il relativo sistema di coordinate .

Poiché il dominio delle frequenze è un dominio complesso, un oggetto

matematico come la trasformata di Fourier può essere descritto attraverso

molteplici rappresentazioni, ciascuna delle quali evidenzia aspetti particolari del

medesimo contenuto informativo o di porzioni di esso.

47

22 vud +=

( ) ( )( )vuFzvuD ,1log, +=


4.2 CONFRONTO TRA IL CONTENUTO INFORMATIVO DELL’AMPIEZZA E

DELLA FASE

La trasformazione di una immagine mantiene inalterato il contenuto

informativo; è pertanto possibile ricostruire l’immagine originale mediante una

trasformazione inversa.

È come se nello spazio di Fourier l’immagine fosse osservata da un

differente punto di vista: ogni punto del dominio trasformato contiene due

componenti: una relativa all’ampiezza ed una relativa alla fase cioè alla

posizione relativa di una struttura periodica.

Per quanto detto risulta naturale domandarsi se ampiezza e fase abbiano

un contenuto informativo di importanza paragonabile o quale dei due si debba

considerare prevalente.

La fase contiene l’informazione relativa alla struttura geometrica

dell’immagine paragonabile alla distribuzione spaziale degli oggetti

nell’immagine.

L'ampiezza contiene l’informazione relativa alla distribuzione

dell’energia luminosa dell’immagine sulle varie frequenze componenti.

E' possibile verificare sperimentalmente queste affermazioni con una

semplice sequenza di operazioni:

• la prima operazione consiste nell’eseguire la DFT-2D di un’immagine,

estraendo e separando il contenuto informativo dello spettro di

ampiezza e dello spettro di fase.

• successivamente eseguire la IDFT-2D utilizzando, in un caso solo lo

spettro di ampiezza e, in un caso, solo lo spettro di fase.

Quanto esposto, si traduce graficamente nelle seguenti

rappresentazioni:

48


Come apprezzabile dalle immagini riportate, per poter ricostruire

correttamente l’immagine di partenza sono indispensabili tanto la fase quanto

l’ampiezza.

4.3 PROPRIETÀ DELLA TRASFORMATA DI FOURIER

PROPRIETÀ DI SEPARABILITÀ

La trasformata di Fourier bi-dimensionale è separabile. Dal punto di

vista analitico questo significa che i termini sotto il doppio segno di

sommatoria possono essere separati e riscritti come segue:

49

( ) ( )

−=−=

= ∑∑−

=

−−

=

−

1,...,1,01,...,1,0

con ,,1,1

0

21

0

2

NvMu

eyxfeN

vuFN

y

NvyiM

x

Muxi ππ


Il principale vantaggio delle proprietà di separabilità è che la trasformata

bi-dimensionale F(u,v) può essere ottenuta applicando in due passi successivi la

trasformata mono-dimensionale, come risulta evidente dalla formulazione

sotto riportata:

Per ogni valore di x, l’espressione F(x,v) è una trasformata mono-

dimensionale nel dominio di v (per v = 0,1, …, N-1). Questo significa che la

funzione bidimensionale F(x,v) può essere ottenuta effettuando una

trasformata lungo ogni riga della f(x,y) e moltiplicando il risultato per N. La

funzione bi-dimensionale F(u,v), a questo punto, può essere calcolata

effettuando una trasformata mono-dimensionale lungo ogni colonna di F(x,v).

Riassumendo graficamente il processo di calcolo della trasformata si

ottiene il seguente diagramma:

Lo stesso risultato può essere ottenuto trasformando prima per colonne

50

( ) ( ) ( ) ( )

== ∑∑

−

=

−−

=

− 1

0

21

0

2

,1, dove ,1,N

y

NvyiM

x

Muxi

eyxFN

NvxFevxFN

vuFππ


e poi per righe. La proprietà di separabilità illustrata vale anche per la

trasformata inversa e, data la semplificazione del calcolo che introduce,

rappresenta dal punto di vista applicativo una delle proprietà più significative.

PROPRIETÀ DI TRASLAZIONE

Per semplicità di esposizione, si supponga di esaminare un’immagine

discretizzata su di una matrice quadrata per cui M=N. La trasformata di

Fourier assume la forma seguente:

La proprietà di traslazione della trasformazione di Fourier è illustrata

dalla seguente relazione:

In generale, moltiplicando f(x,y) per l’esponenziale complesso indicato

ed eseguendo la trasformata del prodotto, si ottiene una traslazione del piano

delle frequenze nel punto (u0,v0). Analogamente, moltiplicando F(u,v) per

l’esponenziale complesso indicato ed eseguendo l’antitrasformata del prodotto,

si ottiene uno spostamento dell’origine del piano spaziale nel punto (x0,y0).

51

( ) ( ) 1...1,0,per ,,1,1

0

1

0

2−== ∑∑

−

=

−

=

+−

NvueyxfN

vuFN

x

N

y

Nyvxui π

( ) ( )

( )

+

−

+

⇔−−

−−⇔

Nyvxui

Nyvxui

evuFyyxxf

vvuuFeyxf00

00

2

00

00

2

,),(

,,π

π


Tipicamente, quando si sta trattando una matrice quadrata di dimensioni

N (ma questo vale anche per immagini rettangolari MxN) si pone u0=v0=N/2

in modo tale da provocare uno spostamento dell’origine dello spettro di

Fourier, che viene portata al centro dello spettro stesso. Per u0=v0=N/2 si ha

infatti:

Quindi la trasformata di Fourier può essere riferita al centro del piano

delle frequenze, semplicemente moltiplicando la f(x,y) per −1x y prima

della trasformazione.

Si rileva inoltre che lo spostamento di f(x,y) di una quantità (x0,y0) non

influenza lo spettro (modulo della trasformata), in quanto il valore assoluto

dell’esponenziale complesso è pari all’unità.

52

( ) ( )

( ) ( ) ( )2,21,

:cui da1

002

NvNuFyxf

ee

yx

yxyxiNyvxui

−−⇔−

−==

+

++

+

ππ


Come visualizzato nell’immagine riportata a seguito, una trasformazione

di Fourier (priva di operazioni supplementari) produce uno spettro non

traslato.

4.4 CONTRIBUTI DI FREQUENZA

Una delle caratteristiche della trasformata di Fourier, rilevabile anche a

vista su di uno spettro di ampiezza centrato, è quella di rappresentare

un’immagine attraverso l’indicazione dei contributi armonici e delle relative

frequenze necessari alla sua ricostruzione.

Questo si traduce nello spettro di ampiezza, con la presenza di corone

circolari, centrate sullo spettro stesso, indicanti come l’energia luminosa

dell’immagine si distribuisce ai vari livelli di frequenza.

Ne segue che, sui cerchi più prossimi al centro dello spettro si rilevano i

contributi di energia relativi alle basse frequenze mentre sui cerchi più distanti

dal centro si rilevano i contributi di energia relativi alle alte frequenze.

Nello spettro di ampiezza della trasformata di Fourier, ogni punto, del

dominio delle frequenze corrisponde ad una composizione (combinazione

lineare) di immagine di base (sinusoidi o cosinusoidi bi-dimensionali) del

dominio spaziale.

Al valore [0,0] corrisponde l’immagine di base a frequenza zero del

dominio spaziale. Ad ogni generico punto dello spettro, corrisponde

un’immagine con la propria frequenza caratteristica.

E’ opportuno ricordare che una sinusoide (funzione di base) mono-

53

( ) ( )vuFevuF Nvyuxi

,,002

=

+− π


dimensionale può essere completamente caratterizzata da frequenza, fase e

ampiezza.

Le sinusoidi bi-dimensionali (immagini di base) devono essere

necessariamente caratterizzate anche da una direzione. Frequenza e direzione

di ogni sinusoide bi-dimensionale è determinata dalla posizione di ogni punto

nel dominio delle frequenze, riferito all’origine dello spettro.

Nell’immagine sotto riportata, sono stati campionati alcuni punti

caratteristici dello spettro e, su di essi è stata rilevata la frequenza delle

corrispondenti immagini di base. Per ciascun punto è stata anche rilevata la

direzione (cioè l’orientamento della sinusoide sul piano) attraverso un vettore

con origine al centro dello spettro (u=0,v=0) e destinazione nel punto

campionato.

In questo modo è stato possibile tracciare, di volta in volta,

sull’immagine originale, i contributi di frequenza rilevati dal punto campionato

sullo spettro di ampiezza.

Le immagini di sintesi ottenute, non rappresentano, in concreto, la

struttura delle immagini di base relative al KERNEL della trasformata, ma

evidenziano in modo significativo come le frequenza della trasformata

risultano distribuite sullo spettro.

54


Come atteso, le sinusoidi ad alta frequenza risultano addensarsi nella

periferia dello spettro, mentre le sinusoidi a bassa frequenza tendono ad

addensarsi al centro dello spettro.

4.5 PROPRIETÀ DELLE COMPONENTI REALE ED IMMAGINARIA

Le informazioni memorizzate nella parte reale e nella parte immaginaria

di una trasformata, sono entrambe fondamentali al fine di una corretta

ricostruzione dell’immagine originale.

L’assenza di una o dell’altra informazione influisce profondamente sulla

ricostruzione di un’immagine ma in modo differente.

Nel prosieguo vedremo gli effetti di una ricostruzione d’immagine a

partire da una trasformata di Fourier dalla quale sono state eliminate prima le

55


sole informazioni riguardanti la parte reale e dopo le sole informazioni

riguardanti la parte immaginaria.

Nella figura è stata calcolata la DFT di un’immagine (a valori reali

positivi) eliminando dalla trasformata tutte le informazioni relative alla

componente reale (lo spettro risulta puramente immaginario).

La ricostruzione dell’immagine attraverso l’antitrasformata produce

un’immagine di output antisimmetrica (si osservi in proposito l’angolo in alto a

destra e l’angolo in basso a sinistra).

Nello specifico l’immagine di output presenta valori positivi, in

corrispondenza delle componenti strutturali dell’immagine originale e valori

negativi in corrispondenza delle componenti strutturali dell’immagine

antisimmetrica.

Le componenti strutturali sovrapposte risultano annullate.

La stessa operazione è stata calcolata eliminando le informazioni sulla

parte immaginaria.

56


Nella figura si è eseguita la DFT di un’immagine (a valori reali positivi)

eliminando dalla trasformata tutte le informazioni relative alla componente

immaginaria (lo spettro risulta puramente reale).

La ricostruzione dell’immagine attraverso l’antitrasformata produce,

anche in questo caso, un’immagine di output antisimmetrica.

La differenza rispetto alla ricostruzione precedente, eseguita a partire

dalla sola componente immaginaria, consiste nel fatto che l’immagine di output

presenta elusivamente valori reali positivi a differenti livelli di luminanza (Le

componenti strutturali sovrapposte presentano il livello di luminanza più

elevato. L’immagine originale e l’immagine antisimmetrica presentano il

medesimo valore di luminanza.)

57


5 TECNICHE DI FILTRAGGIO NEL DOMINIODELLE FREQUENZE

Il filtraggio numerico nel dominio delle frequenze si pone come

obiettivo la determinazione di algoritmi che, applicati alle frequenze

componenti dell'immagine, determinino una evidenziazione di peculiarità

dell'immagine.

Prima di operare l’elaborazione di un’immagine dovrà essere eseguita la

trasformata discreta di Fourier e, al termine dell’elaborazione dovrà essere

eseguita la trasformata inversa per ottenere i risultati dell’elaborazione nel

dominio spaziale.

L’elaborazione nel dominio delle frequenze, può essere sinteticamente

espressa dall’equazione sotto riportata:

L’equazione evidenzia come nel dominio delle frequenze, la relazione tra

la trasformata dell’immagine filtrata O(u,v) e la trasformata dell’immagine di

partenza I(u,v) sia data da una semplice moltiplicazione con una funzione filtro

(o semplicemente filtro dalla teoria dei sistemi) H(u,v) che rappresenta la

trasformata di Fourier di una maschera di convoluzione h(u,v).

Come intuibile, l’immagine filtrata o(x,y) si ottiene operando la

trasformazione inversa di Fourier sulla O(u,v).

Un’esemplificazione del concetto appena esposto è riprodotta

nell’immagine presentata a seguito:

58

( ) ( ) ( )vuIvuHvuO ,,, ⇔


La scelta delle funzioni filtro, il significato delle stesse nel dominio

spaziale e gli effetti prodotti dalla moltiplicazione di una trasformata per una

funzione filtro varieranno in base alle specifiche necessità di elaborazione.

59


5.1 CONTESTI DI APPLICABILITÀ

Le tecniche di elaborazione numerica delle immagini che si basano

sull’utilizzo di funzioni filtro che operano nel dominio delle frequenze,

possono essere classificate in vari modi.

Il metodo più comune è quello di distinguere tra tecniche di filtraggio

lineari e non lineari. La peculiarità delle tecniche di filtraggio lineari è quella di essere spazio-

invarianti, cioè possono essere realizzate sia nel dominio spaziale che in quello

di Fourier, sulla base delle proprietà di linearità della trasformata.

Una classificazione più pertinente all’elaborazione delle immagini,

raggruppa le tecniche di filtraggio sulla base degli effetti prodotti sulle

immagini.

Questa seconda classificazione prevede, quindi, tecniche di

regolarizzazione delle immagini (image smoothing) e tecniche di accentuazione

delle irregolarità (image sharpening).

Un’ulteriore classificazione delle tecniche di filtraggio è basata sulla

natura del filtraggio operato, cioè sulla banda delle frequenze interessate dal

filtro.

In base alla classificazione dei filtri, tesa a promuovere l’operatività dei

filtri stessi su particolari insiemi di frequenze, si possono distinguere filtri

cosiddetti “passa-basso” che operano attenuando o tagliando le alte frequenze,

lasciando pressoché inalterate le basse frequenze e filtri “passa-alto” che

operano attenuazioni e tagli sulle basse frequenze, lasciando inalterate le alte

frequenze.

In generale i filtri passa-basso sono utilizzati per ridurre gli effetti del

rumore nelle immagini e, dato l’effetto di sfocamento introdotto dalla tipologia

di filtraggio, anche per regolarizzare le immagini che presentano il fenomeno

dei falsi contorni cioè una separazione evidente tra i livelli di luminanza sulla

60


superficie dell’immagine, dovuta ad una quantizzazione operata con un

numero insufficiente di livelli di colore.

I filtri passa-alto sono utilizzati invece per evidenziare bordi e contorni

di un'immagine ed accentuare le frontiere che separano i cluster di luminanza.

Il significato dei filtri passa-basso e passa-alto risulta più chiaro

riflettendo sulle caratteristiche del dominio sul quale operano. Considerando

un generico spettro di ampiezza centrato nell’origine, il dominio delle

frequenze di Fourier risulta organizzato in modo del tutto particolare.

La distribuzione dell’energia luminosa associata alle basse frequenze

risulta concentrata nelle corone circolari, concentriche all’origine dello spettro,

e ad esso più prossime.

La distribuzione dell’energia luminosa associata alle alte frequenze

risulta invece concentrata nelle corone circolari, concentriche all’origine dello

spettro, ma ad esso più distanti.

Cercando un nesso esplicativo tra dominio spaziale e spettro di

ampiezza si può ben intuire come le frequenze più basse (relative a funzioni di

base costanti o funzioni di base con un ridotto numero di oscillazioni

nell’intervallo di periodicità) possono essere associate alla ricostruzione di

contenuti informativi spaziali a luminosità poco variabile quali sfondi o zone

dell’immagine uniformemente campite.

Le frequenze più alte (relative a funzioni di base con un numero anche

elevato di oscillazioni nell’intervallo di periodicità) possono essere associate alla

ricostruzione di contenuti informativi spaziali quali oggetti, dettagli, bordi,

contorni e, in generale, a zone con grande variabilità di luminanza nella

campitura.

La figura a seguito riportata esemplifica in modo esaustivo i concetti

appena esposti.

61


Questa interpretazione è assolutamente in linea con tutte le definizioni

formulate nel dominio delle frequenze, infatti, anche nella banale ricostruzione

di una funzione mono-dimensionale, con i contributi armonici di bassa

frequenza si ottiene l’andamento generale della funzione ma occorrono i

contributi armonici di elevata frequenza per raggiungere approssimazioni

fedeli, soprattutto nei dettagli delle funzioni rappresentati da spigoli o punti di

discontinuità.

Riflettendo su quando esposto risulta evidente come eliminando la

banda delle alte frequenze, si eliminino nel dominio spaziale, i dettagli

dell’immagine, introducendo un generale effetto di sfuocamento ed è

altrettanto evidente come eliminando la banda delle basse frequenze si

eliminino nel dominio spaziale gli elementi di sfondo, lasciando in evidenza i

dettagli ed i contorni.

5.2 FILTRI PASSA-BASSO

FILTRO PASSA-BASSO IDEALE Il filtro passa-basso ideale elimina completamente tutte le frequenze al

di sopra di una data soglia detta frequenza di taglio.

62


La funzione che lo rappresenta, nel dominio di Fourier è la seguente:

con

in cui r0 indica la “frequenza di taglio”. Il grafico del filtro ideale è

riportato nella figura sottostante:

Il valore della frequenza di taglio è molto importante poiché determina la

quantità di energia che viene conservata nelle operazioni di filtraggio. In

concreto rappresenta la lunghezza del raggio che puntato con un vertice al

centro dello spettro di ampiezza, può estendersi sino al bordo dello spettro

stesso, indicando l’ampiezza di banda delle basse frequenze che si intende

conservare.

Dal punto di vista qualitativo, la frequenza di taglio è quindi

strettamente legata al grado di sfuocamento che si introduce nell’immagine

filtrata.

63

( ) ( )( )

>≤

=0

0

, se0, se1

,rvurrvur

vuH

( ) 22, vuvur +=


FILTRO PASSA-BASSO BUTTERWORTH Il filtro passa-basso ideale, elimina completamente tutte le frequenze al

di sopra della frequenza di taglio, ma pone in essere questa operazione in una

modalità non sempre efficace da un punto di vista qualitativo.

La problematica è connessa al fatto che in corrispondenza della

frequenza di taglio, il filtro ideale introduce una discontinuità, nella quale il

limite sinistro vale 1 ed il limite destro vale 0.

Questo cambio repentino di valori si riflette sull’immagine filtrata

introducendo le irregolarità precedentemente discusse.

Per ovviare a questo problema, si utilizzano spesso dei filtri di struttura

più complessa capaci però di non eseguire un taglio netto delle frequenze ma

semplicemente un’attenuazione progressiva.

Uno di questi filtri è denominato Butterworth e, nella sua forma più

generale, è definito dalla seguente relazione:

con

In cui i coefficienti r e s permettono di parametrizzare la forma della

curva nelle modalità spiegate a seguito.

Il grafico assonometrico del filtro Butterworth è riportato nella figura

sottostante:

64

( )( ) s

rvur

vuH

+

=,1

1,

( ) 22, vuvur +=


I parametri r e s permettono di caratterizzare l’andamento della curva del

filtro.

In particolare, il parametro r determina la posizione radiale del punto di

flesso della curva e svolge la medesima funzione deputata al raggio nel filtro

ideale, cioè quella di indicare l’ampiezza di banda delle basse frequenze che si

intende conservare.

Dal punto di vista del filtraggio, anche se impropriamente, il parametro

r può essere assimilato ad una frequenza di taglio, infatti il cambiamento di

concavità della curva determina il punto in cui il filtro applica una maggiore

attenuazione delle alte frequenze (schiacciamento).

Il parametro s determina invece il grado di schiacciamento

intervenendo sull’altezza della curva, per questo il parametro s è considerato un

parametro di “attenuazione” della curva. Tipicamente s è definito come s=2n

con n=0,1, …

Aumentando il parametro s, il filtro Butterworth tende, sempre più ad

approssimare il filtro passa-basso ideale. I vari andamenti assunti dalla curva

del filtro Butterworth al variare dei parametri r ed s sono esemplificati nella

figura sottostante:

65


Dal punto di vista della qualità dell’immagine filtrata, il filtro Butterworth

risolve i problemi introdotti dalla discontinuità del filtro ideale, limitando

l’effetto di sfocatura ma riducendo, al contempo, il contributo delle alte

frequenze.

È importante rilevare che il filtro Butterworth non esegue un taglio delle

alte frequenze ma solo un’attenuazione. Per questo motivo, pur non parlando

di frequenza di taglio in senso stretto, si è soliti definire la frequenza di taglio

dei filtri ad attenuazione come la frequenza alla quale il valore della funzione H

raggiunge una predeterminata frazione del suo valore massimo.

FILTRO PASSA-BASSO ESPONENZIALE Il filtro esponenziale, molto simile al filtro butterworth, si differenzia

soprattutto per la rapidità di abbattimento delle alte frequenze. L’espressione

analitica del filtro è riportata a seguito:

66

( )( ) s

rvur

e

vuH

=,

1,


con

I coefficienti r e s permettono di parametrizzare la forma della curva con

modalità equivalenti a quelle espresse per il filtro Butterworth.

Grafico e struttura del filtro esponenziale sono riportati nell’immagine

seguente:

Come nel caso del filtro Butterworth, la frequenza di taglio è definita

come la frequenza alla quale la funzione H è ridotta alla frazione p del suo

valore massimo.

FILTRO PASSA-BASSO TRAPEZOIDALE Il filtro trapezoidale rappresenta una sorta di compromesso tra i filtri

Butterworth ed esponenziale ed il filtro ideale, sia per il comportamento

qualitativo del filtro, sia per la struttura analitica dello sesso. L’espressione

analitica del filtro trapezoidale è la seguente:

con

67

( ) 22, vuvur +=

( )( )

( ) ( )( )

>

≤≤−

−<

=

1

1010

1

0

vu,rper0

vu,rper,vu,rper1

,

r

rrrrrvur

r

vuH


Il parametro r0 indica la frequenza di inizio attenuazione mentre il

parametro r1 indica la frequenza di inizio taglio.

L’intervallo di frequenze tra r0 e r1 è sottoposto ad un filtraggio con

variazione lineare. Grafico e struttura del filtro trapezoidale sono riportati

nell’immagine seguente:

Le due frequenze che identificano l’area di attenuazione lineare,

consentono un filtraggio dagli effetti meno marcati rispetto al filtro passa-basso

ideale, evitando una brusca discontinuità sulle frequenze.

Si nota comunque, che in corrispondenza delle frequenze r0 e r1 il

cambiamento di pendenza della funzione lineare tende comunque a

determinare la comparsa, nel dominio spaziale dell’immagine filtrata, di

strutture ad anello. Questo fenomeno è tanto più evidente quanto maggiore è

la pendenza della rampa del filtro trapezoidale.

68

( ) 22, vuvur +=


6 L'ARCHITETTURA DELL'APPLICAZIONE

6.1 IL MODELLO

Introdotti i concetti di base che sono stati sfruttati nello sviluppo

dell'applicazione, arriviamo ora alla descrizione in termini di sviluppo vero e

proprio di EidosLab.

L'applicazione è progettata per fornire una piattaforma di sviluppo RAD

(Rapid Application Development) di algoritmi orientati alla elaborazione di

segnali digitali multidimensionali.

EidosLab fornisce un ambiente di sviluppo in cui è possibile allocare un

numero teoricamente illimitato di buffer aventi dimensioni qualsiasi,

caratterizzati dal tipo di valore secondo cui può essere espresso ogni singolo

pixel delle immagini.

I tipi disponibili in EidosLab sono i seguenti:

• rgbByte: 24 bit suddivisi in 8bit per ogni componente RGB

• rgbInt: 96 bit suddivisi in 32bit per ogni componente RGB in

aritmetica intera

• rgbFloat: 96 bit suddivisi in 32bit per ogni componente RGB in

floating-point

• bwByte: 8 bit per valori di luminanza

• bwInt: 32 bit per valori di luminanza in aritmetica intera

• bwFloat: 32 bit per valori di luminanza in aritmetica floating-point

• ComplexF: 64 bit per ciascun valore nel campo complesso

• Complex: 96 bit per ciascun valore nel campo complesso

I buffer sono gestiti all'interno dello spazio di memoria del framework e

69


possono essere disallocati su richiesta dell'utente; la memoria allocata per

ciascun buffer sarà poi recuperata dal garbage collector di .NET per garantire

la disponibilità delle risorse di sistema per le successive elaborazioni.

EidosLab provvede automaticamente alla visualizzazione del buffer

all'interno dello spazio grafico dell'applicazione, fornendo all'utente la

possibilità di scegliere fra un insieme di possibili variazioni nella

visualizzazione, dalla classica inversione dei livelli di colore/luminanza, alla

scala logaritmica rapportata alle possibilità grafiche del sistema.

Gli algoritmi non hanno quindi l'esigenza di occuparsi di come i dati

dovranno essere presentati, semplificando enormemente la scrittura degli

algoritmi che possono essere sviluppati focalizzando maggiormente

sull'algoritmo stesso, piuttosto che sulle complessità al contorno legate al

sistema su cui si sviluppano le soluzioni di elaborazione delle immagini.

Ciascun tipo 'base' definito per i buffer prevede uno specifico viewport

in grado di fornire le visualizzazioni e le informazioni fondamentali relative ad

ogni tipo di buffer, come ad esempio i range dinamici del buffer,e l'istogramma

dei livelli di luminanza o delle singole componenti RGB.

70


Esempi di viewport sono i seguenti:

Nelle figure sono riportati rispettivamente una immagine in toni di grigio

ed il suo spettro di energia ottenuto tramite la trasformata di Fourier nel

campo complesso e utilizzando la forma logaritmica del modulo per rendere

visibile all'occhio umano lo spettro di frequenze componenti l'immagine.

Sostanzialmente EidosLab non espleta alcuna funzionalità relativamente

alla elaborazione delle immagini, poiché tutte le operazioni sono realizzate dai

plugin forniti a corredo del framework.

Durante l'avvio dell'applicazione la directory plugins viene scandita alla

ricerca di assembly sotto forma di Dinamic Link Library (DLL), in cui sia

implementata l'interfaccia definita per i plugin e provvede alla integrazione

dello spazio delle classi .NET dell'ambiente di esecuzione.

Ogni singolo plugin viene inserito all'interno del menu principale

dell'ambiente, secondo la gerarchia dei nomi definita nel framework.

71


6.2 L'INTERFACCIA PLUGININTERFACE

Per consentire una corretta interazione tra i plugin ed il framework

chiamante, è stata definita una interfaccia a cui l'applicazione host e i plugin

devono uniformarsi.

L'interfaccia è così definita:

public enum PluginStatus { Success, Fail, Running, Idle };

public interface IPlugin

{

// Link the host to know who are calling me

IPluginHost host {get;set;}

// Plugin properties

string name {get;}

string description {get;}

string author {get;}

string version {get;}

PluginStatus status {get;}

// The configuration Form for this plugin

System.Windows.Forms.Form configurationForm {get;}

// MAIN Methods for the plugin

void Initialize();

void Execute(int iteration);

void PrintConfig();

void Dispose();

}

public interface IPluginHost

{

int CountBuffers ();

ArrayList ListBuffers();

72


ArrayList ListBuffers(int x, int y,ImageBuffer.DataType t);

ArrayList ListBuffers(int x, int y);

ArrayList ListBuffers(ImageBuffer.DataType t);

ArrayList ListBuffers(ArrayList t);

Form MainForm();

ImageBuffer NewImage(int x, int y, ImageBuffer.DataType t, string s);

ImageBuffer GetImageBuffer(string s);

bool DeleteImageBuffer(Form f);

void LogMessage(string who,string msg,int type);

}

Il framework implementa l'interfaccia IPluginHost, fornendo quindi i

metodi per accedere ai buffer ed interagire con essi, oltre a fornire un metodo

per inviare messaggi sulla console di logging dell'ambiente.

Il framework provvede inoltre all'organizzazione ed alla esecuzione dei

plugin, tramite la creazione delle istanze di ciascun plugin e alla

memorizzazione delle attività che l'utente richiede.

Nella parte di codice che segue, sono riportate le parti salienti per

effettuare il Late-Binding delle classi definite all'interno dei plugin:

// Add a plugin found to the tree

private void AddPlugin(string FileName)

{

//Create a new assembly from the plugin file we're adding..

Assembly pluginAssembly = Assembly.LoadFrom(FileName);

//Next we'll loop through all the Types found in the assembly

foreach (Type pluginType in pluginAssembly.GetTypes())

{

if (pluginType.IsPublic) //Only look at public types

{

if (!pluginType.IsAbstract) //Only look at non-abstract types

73


{

//Gets a type object of the interface we need the plugins to match

Type typeInterface = pluginType.GetInterface("PluginInterface.IPlugin", true);

//Make sure the interface we want to use actually exists

if (typeInterface != null)

{

//Create a new available plugin since the type implements the IPlugin interface

IPlugin newPlugin = null;

newPlugin=(IPlugin)Act ivator.CreateInstance(pluginAssembly .GetType

(pluginType.ToString()));

// Save the plugin info in the list of plugins loaded

Types.AvailablePlugin p = new Types.AvailablePlugin();

p.name = newPlugin.name;

p.description = newPlugin.description;

p.version = newPlugin.version;

p.assemblyPath = FileName;

p.author = newPlugin.author;

p.assembly = pluginAssembly;

p.type = newPlugin.GetType();

// Add this Plugin to the list

_pluginList.Add(p);

//CleanUp

newPlugin.Dispose();

newPlugin = null;

}

//CleanUp

typeInterface = null;

}

}

}

//CleanUp

pluginAssembly = null;

74


}

Le DLL presenti nella directory plugins sono scandite alla ricerca delle

classi che implementano l'interfaccia Iplugin, interfaccia che identifica la classe

come appartenente all'insieme dei plugin del Framework.

Il tipo è successivamente integrato con lo spazio delle classi

dell'ambiente di esecuzione, istanziando il relativo oggetto.

Le informazioni salienti ed il tipo sono successivamente memorizzate in

una lista globale dell'ambiente, in cui sarà possibile successivamente reperire le

informazioni principali riguardanti il plugin caricato.

L'oggetto viene poi lasciato al Garbage Collector per il riuso delle risorse

di memoria utilizzate nella fase di inizializzazione dei plugin.

L'interfaccia Iplugin prevede :

• la definizione delle informazioni statiche che descrivono il plugin,

quali il nome della funzionalità, la sua descrizione, la versione del

plugin e l'identificativo dell' autore del plugin.

• la realizzazione di 4 metodi la cui semantica è la seguente:

• Initialize(): inizializza il plugin e permette di configurare i

parametri di esecuzione del plugin stesso • Execute(int iteration): esegue la funzionalità espressa dal

plugin, a patto che sia stato precedentemente configurato

• PrintConfig(): visualizza sulla console di log i parametri di

esecuzione impostati

• Dispose(): segnala al plugin la sua dismissione e consente

pertanto la disallocazione di eventuali risorse utilizzate

Utilizzando i metodi presenti nell'interfaccia è possibile per l'applicazione

host eseguire le azioni previste da ogni singolo plugin e per il plugin è possibile

75


interagire con l'applicazione host richiedendo servizi legati alla elaborazione dei

segnali.

6.3 IL MOTORE DI ESECUZIONE: LA TASKLIST

Come descritto in precedenza, l'obiettivo principale di EidosLab è la

creazione di un elenco di azioni atte a produrre una particolare elaborazione di

segnali multidimensionali.

L'elenco è gestito tramite la TaskList, in cui sono memorizzate le azioni

richieste dall'utente.

Ogni azione della TaskList ha un insieme di pulsanti associati che

consentono di variare la funzionalità richiesta, secondo le possibilità fornite dal

plugin.

Un esempio di TaskList e' visualizzato nella figura seguente:

76


La TaskList si presenta divisa in due parti principali, la lista di esecuzione

ed i pulsanti di gestione della TaskList.

Nella lista di esecuzione ad ogni plugin è riservata una riga numerata che

identifica la sequenza con cui verranno eseguite le operazioni; ogni azione ha 6

pulsanti il cui significato (da sinistra a destra) è il seguente:

1. Configura il plugin: attiva la form di configurazione del plugin,

permettendo quindi la modifica delle impostazioni dell'azione.

2. Aggiunge una iterazione

3. Rimuove una iterazione

4. Elimina l'azione dall'elenco

5. Richiede al plugin la configurazione corrente che verrà visualizzata

nella finestra di log.

6. Esegue una volta l'azione, aumentando di una unità le iterazioni

dell'azione.

Nel caso riportato si può notare come l'azione alla riga 1 abbia un

indicatore di iterazione con valore 3, e quindi sarà eseguita 3 volte nel

momento in cui l'utente ne richiederà l'applicazione.

Nella seconda parte della TaskList sono presenti 5 pulsanti il cui

significato (da sinistra a destra) è il seguente:

1. Salva su file l'elenco di esecuzione

2. Carica da file l'elenco di esecuzione e lo accoda alle azioni esistenti

3. Esegue l'azione selezionata nell'elenco

4. Esegue l'elenco completo

5. Cancella l'elenco di esecuzione e tutti i buffer creati

Nel codice che segue è possibile analizzare la funzione di salvataggio

della TaskList con il modello DOM fornito dall'ambiente .NET :

77


// Create a new file

XmlTextWriter textWriter = new XmlTextWriter(saveTask.FileName, null);

// Opens the document

textWriter.WriteStartDocument();

// Write comments

textWriter.WriteComment("EidosLab Execution TaskList ");

// Write first element

textWriter.WriteStartElement("EIDOSLAB");

textWriter.WriteAttributeString("TaskListType","XmlFile");

textWriter.WriteAttributeString("Release","1.0");

// Write first element

textWriter.WriteStartElement("ACTIONS");

for ( int i = 0; i<taskListView.Items.Count; ++i )

{

textWriter.WriteStartElement("ACTION");

// Set Plugin name as node attribute

textWriter.WriteAttributeString("PluginName",taskListView.GetPluginHolder(i).name);

textWriter.WriteAttributeString("PluginVersion",taskListView.GetPluginHolder(i).

version);

textWriter.WriteAttributeString("Iteration",taskListView.GetPluginHolder(i).

iteration.ToString());

// Get Plugin conf

StringWriter st = new StringWriter();

try

{

XmlSerializer serializer = new XmlSerializer((taskListView.GetPluginHolder(i).

instance).GetType());

serializer.Serialize(st,taskListView.GetPluginHolder(i).instance);

}

// Serialize this object

textWriter.WriteString(st.ToString());

// END ACTION

78


textWriter.WriteEndElement();

}

// END EIDOSLAB


// END ACTIONS


// END DOC

textWriter.WriteEndDocument();

textWriter.Close();

Da notare il punto centrale in cui si fa uso del metodo XmlSerializer

applicato agli oggetti Plugin al fine di ottenere la serializzazione dell'oggetto nel

linguaggio XML.

In forma duale, nella funzione di caricamento di una TaskList, è

utilizzato il metodo DeSerialize applicato allo stream XML, al fine di

ricostruire l'oggetto Plugin che potrà successivamente essere utilizzato per la

realizzazione dell'elaborazione richiesta.

6.4 L'INTERFACCIA PRINCIPALE DI EIDOSLAB

Abbiamo fino ad ora analizzato alcuni aspetti del framework, al fine di

comprendere come sia strutturata l'applicazione e quali siano le peculiarità

soprattutto in relazione alla visione innovativa nella realizzazione di procedure

di elaborazione di segnali.

Passiamo dunque a descrivere l'interfaccia utente che consente all'utente

di costruire, partendo da semplici gesti, procedure di elaborazione delle

immagini.

L'applicazione si presenta all'utente come una Form Multiple Document

Interface (MDI) in cui ogni videoBuffer risulta figlia della Form principale, con

un menu nella finestra principale che contiene tutte le funzionalità espresse dai

79


plugin e da una TaskBar che riporta alcune delle azioni volte alla gestione

dell'interfaccia e dell'applicazione.

Nella figura che segue è possibile vedere come si presenta EidosLab:

Nella parte alta il menù contiene i plugin registrati all'avvio dell'ambiente,

ciascuno dei quali sarà presente nella categoria di appartenenza, ovvero

relativamente a funzionalità:

• Point: orientate al trattamento globale dell'immagine

• Transform: domini trasformati e relativi filtraggi

• Aritmetic: operazioni aritmetiche sui buffer

• Convolution: operatori di convoluzione

• Border: rilevamento dei bordi

• Color: gestione dei colori/luminanza

• Window: funzionalità orientate alla gestione dei videoBuffer

• Help: aiuto e crediti.

80


La costruzione della TaskList prevederà quindi che l'utente interagisca

con il menu, scegliendo tra gli strumenti disponibili quelli che ritiene utili per la

specifica elaborazione in divenire.

Nella parte centrale della Form principale sono invece disposti i

videoBuffer allocati per ogni buffer e, data la gestione MDI delle form, i

videoBuffer saranno vincolati all'interno dello spazio di visualizzazione della

form principale.

Ogni videoBuffer presenta funzionalità specifiche del buffer

rappresentato, per cui sarà possibile richiedere l'istogramma dei livelli di

luminanza se il buffer appartiene alla classe dei buffer 'a livelli di grigio', oppure

ottenere indicazioni sul range di valori presenti, qualora il buffer sia composto

da valori complessi.

In tutti i videoBuffer è possibile operare sulla funzione di Zoom, al fine

di evidenziare dei particolari di interesse per l'analisi dell'immagine da parte

dell'utente.

L'interfaccia è poi completata dalla TaskList e e dalla console di log, le

quali sono allocate al di fuori del modello MDI ed hanno la caratteristica

saliente di essere poste al di sopra dell'applicazione, come una plancia di

comando da cui gestire e controllare l'attività sottostante.

81


7 GLI ALGORITMI SVILUPPATI: I PLUGIN DI BASE

7.1 LOAD/SAVE IMAGE

I due plugin consentono di caricare e salvare le immagini nei formati più

conosciuti, quali GIF/JPEG/PNG/TIFF/BMP e nel formato nativo della

versione precedente di Eidos, il formato PIC.

La codifica e decodifica dei formati avviene attraverso le funzionalità

fornite da GDI+ di .NET.

I plugin consentono il salvataggio degli spettri di Fourier nel campo

complesso, sia esso formato da double che da float, al fine di consentire una

analisi dei risultati delle elaborazioni nel campo delle frequenze.

Il salvataggio avviene all'interno di un file in formato XML, che consente

un immediato utilizzo anche al di fuori del contesto dell'applicazione; un

esempio di spettro è il seguente:




<ComplexBuffer DataType="float" Width="256"

Height="256"><?xml version="1.0" encoding="utf-16"?>

<ArrayOfComplexF xmlns:xsd="http://www.w3.org/2001/XMLSchema"


<ComplexF>

<Re>-3.5078125</Re>

<Im>0</Im>

</ComplexF>

...... omissis ......

<ComplexF>

82


<Re>2.27264786</Re>

<Im>-1.44906569</Im>

</ComplexF>

</ArrayOfComplexF></ComplexBuffer>

Il buffer complesso è pertanto serializzato ed inserito all'interno di un

nodo che identifica il tipo di buffer, se complesso basato su float o su double.

Non si può certo parlare di compressione nella fase di salvataggio, ma si

è preferito mantenere un formato leggibile, piuttosto che un formato binario di

difficile interpretazione, tanto più che ormai lo spazio su disco non è un

vincolo forte.

7.2 DISCRETE FOURIER TRANSFORM

I plugin DFT e IDFT consentono l'applicazione della trasformata

classica di Fourier su immagini di dimensioni qualsiasi.

E' quindi possibile condurre analisi di Fourier su qualsiasi immagine a

livelli di grigio, pagando il prezzo di una computazione avente una alta

complessità legata al calcolo impiegato per ottenere l'immagine nel dominio

trasformato.

L'esecuzione su un Pentium IV a 1.8Ghz della DFT di una immagine di

300x200 pixel necessita di circa 150 secondi di tempo macchina per ottenere il

risultato. L'algoritmo utilizzato è stato ottimizzato solo nella dislocazione delle

operazioni, lasciando però il codice comprensibile, con l'obiettivo di fornire un

riferimento leggibile dell'implementazione usata, forse a scapito delle possibili

ulteriori ottimizzazioni.

Il codice saliente del plugin è il seguente:public static void DFT2( Complex[] data,int width, int height)

{

83


double omega;

long offset, accumulator,tetafi;

double arg;

double cosarg,sinarg;

Complex[] buf = new Complex[data.Length];

omega=2.0 * Math.PI/width;

for (int y=0;y<height; y++)

{

offset = y*width;

for (int u=0;u<width;u++)

{

arg = omega * u;

accumulator = u+offset;

buf[accumulator].Re = 0;

buf[accumulator].Im = 0;

for (int x=0;x<width;x++)

{

tetafi = x+offset;

cosarg = Math.Cos(x * arg);

sinarg = Math.Sin(x * arg);

buf[accumulator].Re += (float)(data[tetafi].Re * cosarg + data[tetafi].Im *

sinarg);

buf[accumulator].Im += (float)(data[tetafi].Im * cosarg - data[tetafi].Re * sinarg);

}

buf[accumulator] /= width;

}

}

// Change row to col

for ( int x=0; x<width; ++x)

for (int y=0;y<height;++y)

data[x*height+y]=buf[x+y*width];

84


// Compute FT on the columns

omega=2.0 * Math.PI/height;

for (int y=0;y<width; y++)

{

offset = y*height;

for (int u=0;u<height;u++)

{

arg = omega * u;

accumulator = u+offset;

buf[accumulator].Re = 0;

buf[accumulator].Im = 0;

for (int x=0;x<height;x++)

{

tetafi = x+offset;

cosarg = Math.Cos(x * arg);

sinarg = Math.Sin(x * arg);

buf[accumulator].Re += (float)(data[tetafi].Re * cosarg + data[tetafi].Im *

sinarg);

buf[accumulator].Im += (float)(data[tetafi].Im * cosarg - data[tetafi].Re * sinarg);

}

}

}

// Reorder the columns

for (int y=0;y<height;++y)

for ( int x=0; x<width; ++x)

data[x+y*width]=buf[x*height+y];

}

Sono presenti sia la trasformata diretta che la trasformata inversa, al fine

di consentire il ritorno al dominio spaziale, dopo una analisi condotta nel

85


campo delle frequenze.

7.3 FAST FOURIER TRANSFORM

Qualora le immagini abbiano le caratteristiche necessarie, dimensioni

quadrate e dimensione 2n con n= 1,2, ... è possibile applicare algoritmi con

complessità decisamente inferiore per il calcolo dell'immagine nel dominio

trasformato.

Si ottiene così un ampio guadagno in termini di tempo, ma vista la

particolare natura delle immagini da trattare, non sempre è applicabile.

Anche per questo plugin è presente la trasformata inversa.

7.4 DISCRETE COSINE TRANSFORM

Un'altra trasformata classica, avente un Kernel separabile, e quindi

semplice da trattare è la trasformata al coseno discreto, usata ampiamente

nell'ambito della compressione delle immagini (Formati MPEG/JPEG).

E' presente in EidosLab con scopi principalmente didattici, in quanto

per le applicazioni nell'ambito della elaborazione delle immagini non è

particolarmente interessante.

Il codice saliente della DCT è il seguente:public static void DCT2( float[,] data,int width, int height)

{

float[,] buf = new float[width,height];

// 1D DCT ROWS Transform

float Sqrt2SuN = (float)Math.Sqrt(2f/width);

float Sqrt1SuN = (float)Math.Sqrt(1f/width);

float PiOver2N = (float)(Math.PI/(2f*width));

for (int y=0;y<height; y++)

{

86



{

buf[u,y]= 0f;

for (int x=0;x<width;x++)

{

double cosarg = (2f*x+1f)*(u*PiOver2N);

buf[u,y] += (float)( data[x,y] * (float)Math.Cos(cosarg));

}

if (u == 0)

buf[u,y] *= Sqrt1SuN;

else

buf[u,y] *= Sqrt2SuN;

}

}

// 1D DCT COLUMNS Transform

Sqrt2SuN = (float)Math.Sqrt(2f/height);

Sqrt1SuN = (float)Math.Sqrt(1f/height);

PiOver2N = (float)(Math.PI/(2f*height));


{

for (int v=0;v<height;v++)

{

data[u,v]= 0f;

for (int y=0;y<height;y++)

{

double cosarg = (2f*y+1f)*(v*PiOver2N);

data[u,v] += (float)( buf[u,y] * (float)Math.Cos(cosarg));

}

if (v == 0)

data[u,v] *= Sqrt1SuN;

else

87


data[u,v] *= Sqrt2SuN;

}

}

}

Anche in questo caso è stata sviluppato il corrispettivo plugin che

realizza la trasformata inversa.

7.5 FREQUENCY FILTERS

Le elaborazioni nel dominio delle frequenze si concretizzano nei 4 plugin

realizzati e che forniscono gli strumenti per attuare un filtraggio passa-alto e

passa-basso, applicabili a immagini di qualsiasi dimensione nello spazio delle

frequenze.

Il modello classico delle elaborazioni presentato nell'ambito teorico del

filtraggio è stato generalizzato per consentire il trattamento di immagini aventi

dimensioni non quadrate, prevedendo perciò non più un luogo dei punti

avente forma circolare, bensì ellittico, al fine di compensare la diversa

distribuzione delle frequenze lungo gli assi aventi differenti dimensioni.

Il calcolo del luogo dei punti ellittico si basa sulle seguenti osservazioni:

88

X0,Y0

(Xe,Ye)

(X,Y)


Per ogni punto (X,Y) componente l'immagine viene calcolata la distanza

dal centro dell'immagine (X0,Y0) avendo definito

Calcolando l'intersezione tra la retta passante per il centro degli assi e

l'ellisse inscritta nel rettangolo, si ottiene la distanza tra il centro dell'ellisse e il

punto più vicino al punto in osservazione.

Moltiplicando tale distanza per il fattore di scala che varia da 0 a 1, si

ottengono tutti i possibili luoghi geometrici ellittici aventi il rapporto M/N tra

gli assi, che è il rapporto tra gli assi dell'immagine in esame.

Si ottiene pertanto la determinazione della funzione H da applicare a

scelta sui valori reali o sui valori immaginari o ad entrambi, valutando la

distanza dal centro dello spazio delle frequenze, dando luogo ai classici filtri

Ideale, Butterworth, Esponenziale e Trapezoidale.

7.6 CONVOLUTION SPATIAL FILTER

Una tipica applicazione nel dominio spaziale è la convoluzione, qui

presentata nella forma di matrice 3x3, in cui è possibile impostare i valori da

applicare nella maschera e il relativo quoziente e offset, applicati a ciascun

punto componente l'immagine, a meno del perimetro dell'immagine.

Per ogni pixel vengono pesati i pixel adiacenti, mediati dividendone la

somma per il quoziente e sommato l'offset.

Questa applicazione classica dell'elaborazione delle immagini si può

applicare a immagini di qualsiasi tipo e dimensione nel campo dei numeri reali.

7.7 COLOR CONVERSION

I plugin realizzati consentono di ottenere il negativo di una immagine,

89

X0=M2,Y0=N

2


oppure di realizzare l'equalizzazione dell'istogramma dei livelli di luminanza, sia

per immagini in scala di grigi che per immagini a colori.

Particolare attenzione è stata rivolta a quest'ultima applicazione, in

quanto non è possibile semplicemente applicare l'algoritmo di equalizzazione

ad ogni singolo canale, poiché si otterrebbe un viraggio di colore, dovuto alla

indipendenza del trattamento, indipendenza che si traduce successivamente in

un errore di riscalamento dei colori componenti.

E' pertanto necessario convertire lo spazio dei colori da RGB ad uno

degli spazi in cui venga espresso ogni pixel in termini di la luminanza e di

crominanza, quali lo spazio YIQ o lo spazio YUV.

In uno qualsiasi dei due spazi menzionati è possibile calcolare

l'equalizzazione dell'istogramma, con il relativo riscalamento dei colori, per cui

è lasciata all'utente la scelta dello spazio in cui operare con il plugin.

Le equazioni di riferimento per la conversione tra lo spazio RGB e lo

spazio YUV sono le seguenti:

Y = ( .299 * R + .587 * G + .114 * B)

U = ( - .169 * R - .332 * G + .500 * B) + 128

V = ( .500 * R - .419 * G - .081 * B) +128

e la corrispondente inversa

R = Y + 1.4075 * (V-128)

G = Y - .3455 * (U-128) - .714 * (V-128)

B = Y + 1.770 * (U-128)

Le equazioni di riferimento per la conversione tra lo spazio RGB e lo

spazio YIQ sono le seguenti:

Y = ( .299 * R + .587 * G + .114 * B)

I = ( .596 * R - .275 * G + .321 * B)

Q = ( .212 * R - .523 * G + .311 * B)

90


e la corrispondente inversa

R = Y + .956 * I + .620 * Q

G = Y - .272 * I - .647 * Q

B = Y – 1.108 * I + 1.705 * Q

Una volta ottenuta l'informazione di luminanza, è possibile applicare ad

essa l'algoritmo classico e riscalare i livelli in modo da ottenere l'equalizzazione

desiderata.

Unendo questa informazione all'informazione di crominanza è possibile

ricostruire l'immagine senza alterare i bilanciamenti di colore all'interno

dell'immagine.

Ovviamente i due spazi non sono del tutto equivalenti, soprattutto nella

resa cromatica legata al differente peso delle informazioni di crominanza nelle

equazioni utilizzate e nella necessaria approssimazione con cui vengono

compiuti i calcoli; sarà pertanto cura dell'utente valutare quale dei due spazi sia

ottimale nell'ambito della specifica esecuzione.

7.8 IMAGE ARITMETICS

Questi plugin consentono le classiche operazioni aritmetiche tra buffer,

quali l'addizione, la moltiplicazione e la sottrazione, operatori utili soprattutto

per l'analisi differenziale dei risultati di una elaborazione.

La semantica varia a seconda degli operandi, potendo avere buffer di

tipo diverso.

Qualora non abbia senso l'operazione, poiché i tipi sono troppo

differenti, allora il plugin ritorna un errore di 'buffer non supportato' e

l'immagine risultante è di colore nero.

Da notare che gli operandi devono avere necessariamente le stesse

91


dimensioni.

7.9 BORDER DETECTION FILTERS

Nella classe delle operazioni di convoluzione, di differenziano i filtri di

convoluzione orientati alla evidenziazione dei bordi, i modelli realizzati sono i

classici Prewitt, Kirsh e Sobel

7.10 EXPORT PDF FORMAT

Questo plugin consente di esportare un buffer in un documento Portable

Document Format (PDF), le cui caratteristiche variano a seconda del tipo di

buffer che si desidera esportare.

Il PDF 1.5 consente di esprimere immagini fino a 16 bit di profondità

per componente, il cui rendering dipenderà dalla periferica su cui è visualizzato

o stampato.

Questa funzione consente pertanto di utilizzare differenti hardware

aventi differenti capacità di rendering per l'analisi visiva delle immagini.

La libreria utilizzata per la creazione del PDF non presentava la

possibilità di esprimere immagini in qualsiasi profondità di colore, per cui la

libreria è stata integrata, basandosi sulla PDF 1.5 Reference Guide,

introducendo la possibilità di immettere in un documento pdf immagini a

1,2,4,8 e 16 bit per componente di colore/luminanza.

La parte di codice più importante è la seguente:

/// <summary>

/// Method that returns the PDF codes to write the image reference in the document.

/// </summary>

/// <returns>String that contains PDF codes</returns>

public string getText()

92


{

StringBuilder resultImage = new StringBuilder();

resultImage.Append(_ObjectID.ToString() + " 0 obj" + ToChar(13) + ToChar(10));

resultImage.Append("<<" + ToChar(13) + ToChar(10));

resultImage.Append("/Type /XObject" + ToChar(13) + ToChar(10));

resultImage.Append("/Subtype /Image" + ToChar(13) + ToChar(10));

resultImage.Append("/Name /I" + _ObjectID.ToString() + ToChar(13) + ToChar

(10));

switch ( _type )

{

case Enumerators.imageType.jpegData:

resultImage.Append("/Filter /DCTDecode" + ToChar(13) + ToChar(10));

break;

default:

break;

}

resultImage.Append("/Width " + _width.ToString() + ToChar(13) + ToChar(10));

resultImage.Append("/Height " + _height.ToString() + ToChar(13) + ToChar(10));

if ( _interpolate )

resultImage.Append("/Interpolate true" + ToChar(13) + ToChar(10));

else

resultImage.Append("/Interpolate false" + ToChar(13) + ToChar(10));

switch ( _type )

{

case Enumerators.imageType.rawRGB1bit:

resultImage.Append("/BitsPerComponent 1" + ToChar(13) + ToChar(10));

resultImage.Append("/ColorSpace /DeviceRGB" + ToChar(13) + ToChar

(10));

break;

case Enumerators.imageType.rawRGB2bit:

resultImage.Append("/BitsPerComponent 2" + ToChar(13) + ToChar(10));

93


resultImage.Append("/ColorSpace /DeviceRGB" + ToChar(13) + ToChar

(10));

break;

..... omissis....

}

resultImage.Append("/Length " + _content.Length.ToString() + ToChar(13) + ToChar

(10));

resultImage.Append(">>" + ToChar(13) + ToChar(10));

return resultImage.ToString();

In cui è possibile notare come sia possibile scegliere il tipo di

rappresentazione da utilizzare tramite il tipo enumerato ImageType avente i

seguenti valori: rawRGB1bit, rawRGB2bit, rawRGB4bit, rawRGB8bit,

rawRGB16bit, rawGray1bit, rawGray2bit, rawGray4bit, rawGray8bit,

rawGray16bit, jpegData.

L'array di byte che rappresenta l'immagine sarà la linearizzazione

dell'immagine per righe, in cui ogni pixel a colori potrà essere rappresentato

con la sequenza RGB dei colori componenti.

I modelli di colore CMYK e LAB sono stati al momento non

considerati, viste le esigenze di sviluppo orientate più alla visualizzazione su

supporto elettronico rispetto a quello cartaceo.

94


8 SVILUPPI FUTURI

La forte scalabilità del progetto presuppone la possibilità di sviluppare

ulteriori funzionalità e plugin con estrema semplicità, potenzialmente anche

all'interno dei corsi di laurea, laddove la focalizzazione sul problema è

importante e con EidosLab lo studente può realizzare semplicemente la

propria funzione senza doversi preoccupare di molte delle attività al contorno,

non specificatamente legate alla tematica da trattare.

Un'altro possibile sviluppo è l'estrazione del motore di esecuzione di

EidosLab, creando una applicazione di tipo CONSOLE che possa essere

eseguita in modalità batch, al fine di mettere in esecuzione batterie di

esperimenti. Al termine delle elaborazioni sarà solamente necessario verificare i

risultati, semplificando ulteriormente le attività di ricerca che hanno aspetti di

tipo fortemente ripetitivo.

Il linguaggio della TaskList può essere reso più complesso, prevedendo

l'introduzione del concetto di 'condizione', rendendo così la tasklist un

linguaggio di programmazione di immagini più completo.

Queste possibili direzioni di sviluppo confermano ulteriormente la bontà

delle scelte progettuali e affermano la capacità di EidosLab di proporsi come

applicazione di riferimento per il gruppo di ricerca del Dipartimento di

Informatica di Torino.

95


9 RINGRAZIAMENTI

Desidero ringraziare chi ha condiviso con me questa avventura, in primo

luogo il dott. Davide Cavagnino*, sapiente e corretto nei suoi consigli.

Il prof. Balossino Nello per la comprensione e la fiducia nei miei

confronti, spero adeguatamente ripagata.

I proff. Sirovich Franco, Werbrouck Albert, la prof.ssa Ardissono

Liliana, la dott.ssa Petrone Giovanna e Griffin Jeanne per non avermi chiesto

troppo al momento della verifica.

I miei colleghi d'ufficio che, volenti o nolenti, sono stati invischiati nelle

tematiche dello sviluppo del codice e degli algoritmi, Bruno Graziano, Paolo

Pasteris, Simone -simon- Donetti, Alex -acalasia- Cordero, Mauro -topogigio-

Giraudo e skywalker.

Un ringraziamento particolare deve essere fatto anche a Paola Gatti per

la dedizione che mette nel lavoro e che troppe volte non è riconosciuta come

invece merita.

Pensierino della sera:

se ripenso a quando ho iniziato

l'università e dicevo “chissà se

riuscirò a laurearmi ?” e adesso mi

ritrovo addirittura con due

lauree...

* il dott.. Cavagnino appare per gentile concessione del prof. Bergadano

96


BIBLIOGRAFIA

Programming Microsoft Windows with C#Charles Petzold – Microsoft Press, 2002

Digital Image ProcessingWilliam K. Pratt., John Wiley & Sons, 1978

Digital picture processingAzriel Rosenfeld, Avinash C. Kak., Academic Press 1976

Digital Image ProcessingR. Gonzales, R. Woods – Addison Wesley, 2002

Digital Coding of WaveformsJayant, Noll – Prentice Hall, 1984

Eidos: un sistema di elaborazione di immagini basato suPCTesi di Laurea – Corso di Laurea in Informatica – AA

1989/1990 Alberto Chiavazza

Sviluppo di algoritmi per il ripristino di immaginiTesi di Laurea – Corso di Laurea in Informatica – AA

1993/1994 Enrico Mingrino

Eidos: un sistema amichevole per l'elaborazione diimmagini in ambiente windowsTesi di Laurea – Corso di Laurea in Informatica – AA

1996/1997 Glauco Salvador

Sviluppo di un sistema di ripristino di qualità nel dominiotrasformato Tesi di Laurea – Corso di Laurea in Informatica – AA

97


2003/2004 Daniele Occhetti

Inside C#Tom Archer – Microsoft Press, 2001

Microsoft Developer Networkhttp://msdn.microsoft.com

CodeProject Web Sitehttp://www.codeproject.com

98