La parte di immagine correntemente visualizzata nel browser viene con- tornata con un rettangolo di bordo rosso. L’utente pu`a spostare la selezione con il tasto destro del mouse, e ridimensionare la selezione trascinando il triangolo rosso in basso a destra del rettangolo o utilizzando la rotella del mouse.
Ad ogni cambiamento della porzione di immagine da visualizzare cor- risponde l’emissione di un signal, catturato dal browser. Analogamente il controllo dispone di uno slot per aggiornare la selezione, che riceve i signals emessi dal browser.
Infine, sopra il navigator (Figura 3.6), sono visualizza alcune informazioni relative all’immagine caricata, quali il path locale o remoto dell’immagine, la dimensione e il formato.
Figura 3.6: File info.
3.4
Gestione dei dati
Come visto precedentemente, la toolbar mette a disposizione dell’utente la possibilit`a di caricare un immagine dal disco locale o da un server remoto. Per consentire il caricamento da remoto `e necessario predisporre l’immagine tramite un apposito tool chiamato RtiBuilder.
3.4.1
Gestione dati locali
Il caricamento di un file dal disco locale prevede la letture del file in modo sincrono nel thread principale dell’applicazione.
Il parsing del file PTM differisce a seconda del tipo e del formato, sfrut- tando l’interfaccia del modulo Rti. Una volta caricato il contenuto del file, si esegue il calcolo del mip-mapping e delle normali.
Il mip-mapping `e eseguito sui coefficienti del polinomio e nel caso del formato LRGB anche sulle componenti di colore, e consente di effettuare il rendering su una porzione di immagine di dimensioni simili a quello del browser, evitando di generare un livello di dettaglio troppo fine per essere apprezzato con le attuali condizioni di zoom. Questo consente anche di li- mitare il tempo massimo necessario per la generazione della texture, le cui dimensioni non supereranno mai il doppio di quelle del browser. Praticamen- te si cerca sempre di far lavorare gli algoritmi di applicazione della texture in condizioni di minification, con la limitazione che in un pixel del browser siano mappati al massimo quattro texel. Questo scelta permette anche di evitare la comparsa di difetti visivi, come la sfocatura dell’immagine, al variare dello zoom.
Le normali sono calcolate per ogni livello di mip-mapping, in quanto ge- nerate in funzione dei coefficienti del polinomio, e permettono l’applicazione delle varie tecniche di shading enhancement. Nel caso di RGB-PTM si cal- colano le normali per ogni componente di colore e successivamente si esegue la media.
Durante l’operazione di caricamento viene visualizzata una progress bar, i cui dati sono aggiornati attraverso un meccanismo a callback.
3.4.2
Gestione dati remoti
Per il caricamento remoto `e necessario che l’utente inserisca una url valida, da cui recuperare il risultato dell’elaborazione del tool RtiBuilder. L’unico formato attualmente supportato `e quello LRGB.
3.4 Gestione dei dati 52
Il tool RtiBuilder provvede alla suddivisione dell’immagine in tiles di diverse risoluzione utilizzando il mip-mapping. In particolare il tool, una volta caricato il file, si occupa della creazione di un’immagine di preview di formato JPEG da utilizzare per il navigator, della creazione di un file XML (Listing 3.1) con le informazioni necessarie per allocare in fase di caricamento le opportune strutture dati, e della creazione delle tiles.
Listing 3.1: File XML per il caricamento remoto.
<RTIBuilderInfo>
<Info width="2516" levels="3" height="1646" /> </RTIBuilderInfo>
Ogni tile corrisponde ad una sotto-PTM che contiene i coefficienti e le componenti di colore RGB di una parte della PTM originale. Queste nove componenti vanno a formare lo stream di una immagine JPEG2000 di tipo lossless che viene salvato in formato binario in un file. La compressione JPEG2000 permette di ridurre la quantit`a di dati da scambiare via rete.
Durante la decomposizione, ogni tile `e indicizzata secondo un approccio multi-risoluzione che ne rende pi`u efficiente il recupero. In particolare, il tool prende in input il livello di risoluzione massimo del quadtree che verr`a utilizzato nell’indicizzazione delle tiles.
Lo schema di indicizzazione `e generato secondo un organizzazione spazia- le chiamata z-ordering [PF01] [BKV99], che permette di convertire n indici di una matrice n-dimensionale in un indice monodimensionale. L’utilizzo di questo tipo di indicizzazione presenta diversi vantaggi. Facilita la navigazio- ne non solo tra tiles vicine dello stesso livello, ma anche tra tiles con una relazione di parentela appartenenti a livelli differenti.
In particolare, all’interno del tool, per l’indicizzazione si utilizza una ma- trice bidimensionale chiamata Z-matrix, in cui l’elemento di indici (i, j) con-
tiene il valore associato dallo z-ordering. Poich´e la suddivisione in tiles `e ese- guita a tutti i livelli di mip-mapping vengono generate diverse matrice. Ad esempio, se viene richiesta un’indicizzazione a 3 livelli, il minimo consentito, avremmo la gerarchia di matrici in tabella 3.1.
" 0 1 2 3 # (a) 0 1 4 5 2 3 6 7 8 9 12 13 10 11 14 15 (b) 0 1 4 5 16 17 20 21 2 3 6 7 18 19 22 23 8 9 12 13 24 25 28 29 10 11 14 15 26 27 30 31 32 33 36 37 48 49 52 53 34 35 38 39 50 51 54 55 40 41 44 45 56 57 60 61 42 43 46 47 58 59 62 63 (c)
Tabella 3.1: Matrici di z-ordering a tre livelli di indicizzazione dal livello 1 (a) al livello 3 (c).
Nello specifico l’indicizzazione di livello pi`u alto `e utilizzata per il livello di mip-mapping a risoluzione maggiore, mentre il livello di indicizzazione pi`u basso `e utilizzato per il livello di mip-mapping a risoluzione minore. A questo punto per identificare le differenti tiles si appende al nome del file le informazioni sul livello di indicizzazione da cui `e stata generata e il relativo indice di z-ordering. Le tiles prodotte da questo processo presentano tutte la stessa dimensione in termini di pixel.
In RtiViewer il recupero dell’immagine dal server remota avviene via HTTP attraverso un thread secondario, chiamato HTTPThread. Il thread si aspetta che sul webserver all’url inserita dall’utente corrisponda un folder con i file creati dal tool RtiBuilder. Il HTTPThread comunica con il thread primario utilizzando semplicemente il meccanismo dei signal e degli slot della
3.4 Gestione dei dati 54
libreria Qt. In particolare il processo di recupero si divide in due fasi: la prima con il recupero dell’immagine JPEG di preview e del file XML, la seconda con il recupero delle tiles.
La prima fase prevede che il thread principale della applicazioni attenda in maniera sincrona le risposte alla due richieste inviate al thread secondario, grazie all’utilizzo di un mutex. Qualora si verifichi un errore, questo viene comunicato all’utente e il caricamento remoto interrotto. Se invece le due richieste hanno successo, si allocano le strutture dati partendo dalle informa- zioni contenute nel file XML (dimensioni e massimo livello di indicizzazione utilizzato) e si passa alla fase di recupero delle tiles.
Il caricamento delle tiles avviene in maniera asincrona nel HttpThread. Il thread `e reattivo ai cambiamenti di vista del browser dovuti a navigazione e zoom dell’immagine. L’idea base `e quello di caricare i dati delle tiles corren- temente visualizzate nel browser, incrementando progressivamente il livello di dettaglio e partendo da quelle di livello di risoluzione pi`u basso. Una volta completato un livello si passa al quello successivo. Completato il caricamen- to di tutte le tiles a tutti i livelli di risoluzione che si trovano nella porzione di immagine correntemente visualizzata nel browser, si passa al caricamento delle tiles che si trovano intorno, partendo sempre dal livello pi`u basso. Il processo termina quando tutte le tiles di tutti i livelli sono state recupera- te. La terminazione comporta un aggiornamento dell’interfaccia grafica per mettere a disposizione le tecniche di shading enhancement che non possono essere utilizzate durante il caricamento remoto.
Il thread lavora con una tabella che memorizza per ogni tile di massimo livello di risoluzione una mappa di bit che indica se la tile stessa e le tiles sue parenti di livelli inferiori sono state caricate.
Con questo approccio si riesce a mantenere un buon livello di interatti- vita con l’utente, anche se il caricamento diretto della PTM alla risoluzione massima, facendo attendere l’utente, richiederebbe meno dati.
Qualora durante la richiesta di una tile si verifichi un errore, il thread continua o richiedendo la stessa tile o quella successiva. Nel thread `e imple- mentata una coda di richieste di tiles che consente il rinvio di una richiesta fallita per un numero di volte massimo pari a tre. Se la terza richiesta fallisce, la tile `e considerata irraggiungibile e si passa alla richiesta successiva. Tutto questo non comporta nessuna comunicazione all’utente, in quanto sempli- cemente si verr`a a notare la mancanza di una tile durante il rendering nel browser.