Metti il Turbo alle tue foto panoramiche!
9 Ottobre 2007

Sei il visitatore numero 9429


Premessa

Questo articolo è rivolto in particolar modo a coloro che utilizzano abitualmente le tecniche di stitching (fotografia panoramica, focus stitch, ecc.), siano essi fotoamatori oppure professionisti.
La lettura può tuttavia risultare utile anche a coloro che desiderano incrementare le prestazioni di software foto/audio/video che gestiscono una gran quantità di dati. Photoshop è naturalmente uno di questi.

Aggiornamento del 5 Febbraio 2008: aggiunte alcune considerazioni sui sistemi operativi a 64bit (capitolo "Hardware impiegato") e sui dischi SAS (capitolo "Conclusione").


La fotografia panoramica utilizzata per il test

E' evidente come i tempi di generazione di uno stitch siano strettamente correlati alle sue dimensioni ma, a parità di questo fattore, influiscono in maniera decisiva le prestazione dell'hardware utilizzato.

Il progetto che utizzerò come termine di raffronto per tutti i test di questo articolo ha le seguenti caratteristiche:

Numero di immagini 17
Tecnica di scatto utilizzata Mano libera
Dimensione delle immagini 10 Mpixel
Profondità colore in ingresso 16bit
Profondità colore in uscita 16bit
Dimensione dello stitch (pixel lordi) 124 Mpixel
Dimensione dello stitch (pixel netti) 85 Mpixel
Peso dello stitch (file PSB, lordo) 6,22 Gb
Peso dello stitch (file PSD, netto) 510 Mb

L'anteprima del progetto in PTgui (Panorama editor) è la seguente:



Notare come la posizione scelta del "Center Point" determina una vasta area senza informazioni che purtroppo sarà inclusa nello stitch finale, determinandone un forte incremento delle dimensioni. Le accresciute dimensioni si pagheranno, in termini di tempi di attesa, in fase di elaborazione in Photoshop.

L'immagine finale, raffigurante la testa della Valnontey (Parco Nazionale del Gran Paradiso) e i casolari di Money, è la seguente:


Foto: Enrico Cinalli , 2006
Powered by Zoomify

Il progetto dello stitch è stato elaborato inizialmente con PTGui 7.2 , il quale ha generato un file in formato Photoshop "big" (PSB) contenente l'immagine finale "Blended" (blender interno di PTGui) e le singole 17 immagini opportunamente deformate (warped), disposte su altrettanti livelli.
Questa scelta di output ha un doppio scopo: rendere possibili eventuali correzioni manuali in corrispondenza delle giunture tra fotogrammi (possibili problemi di parallasse) e mantenere la possibilità di utilizzare un blender esterno molto interessante come quello incluso in Photoshop CS3 (AutoBlend).

Nota: tratterò in maniera specifica di Autoblend in uno dei prossimi articoli su Photoactivity.

Il file così ottenuto è davvero molto pesante, oltre 6 Gb, ed il suo calcolo ha richiesto un tempo abbastanza elevato. Tuttavia una fase altrettanto pesante è quella dell'apertura e della lavorazione del documento in Photoshop: affinchè si opera con tutti i layer, i tempi di risposta sono generalmente molto alti.


L'Hardware impiegato

Per fornire un termine di paragone importante, è necessario specificare le principali caratteristiche del computer utilizzato:

Processore Intel Pentium 4
Nuclei fisici 1
Nuclei virtuali 2 (tecnologia Intel HT)
Frequenza clock 3.0 Ghz
Motherboard Asus P4C800
RAM 2 Gb, DDR2 400Mhz
HD dati Maxtor SATA 320Gb 7.2Krpm- 16Mb buffer
HD dedicato per Scratch Maxtor SATA 120Gb 7.2Krpm- 8Mb buffer
RAM disponibile per PS circa 1,4 Gb
Sistema operativo Windows XP SP2


Come si nota si tratta di un hardware non recentissimo, ma le sue prestazioni restano valide anche se confrontate con gli hardware attuali di fascia media.
La corsa ai Ghz si è infatti praticamnete arrestata, ed i nuovi processori puntano molto sull'ottimizzazione della struttura interna e sulla presenza di più nuclei fisici: queste caratteristiche consentono loro di spuntare risultati certamente migliori, ma senza grossi stravolgimenti rispetto a quelli del nostro test.

Come vedremo, oltre alla velocità di calcolo del processore sono fondamentali anche i tempi di accesso e di trasferimento da/verso i dati delle immagini.

La quantità di RAM disponibile è fondamentale specialmente per Photoshop, mentre PTgui utilizza in via preferenziale gli Hard Disk (HD) installati per scrivere i files temporanei.
In effetti Photoshop è un vero e proprio "buco nero" per le risorse di sistema: pensate che durante l'operazione di Autoblend, il file di Scratch (il file temporaneo di PS nel quale vengono scritti tutti i dati che non trovano spazio in RAM) ha raggiunto la ragguardevole dimensione di 22Gb ! Ergo: neppure con 16Gb di RAM installata si sarebbe evitato il ricorso all'uso dell'HD, con conseguente forte rallentamento dell'operazione.

L'installazione di RAM aggiuntiva, in particolare oltre la soglia dei 4Gb, è però molto onerosa, perchè si devono utiilizzare banchi RAM di capienza elevata (2-4Gb ciascuno). Esistono inoltre problematiche di carattere tecnico:

- molte motherboard della precedente generazione non non possono ospitare quantitativi di RAM superiori a 4Gb; le comuni motherboard attuali possono ospitare fino ad 8Gb. Solamente le motherboard "server oriented" come quelle che supportano i processori Xeon possono ospitare fino a 32Gb di RAM.

- moltissime applicazioni professionali (come Photoshop, anche in versione CS3) non sono state ancora riscritte per sfruttare l'indirizzamento della RAM a 64bit, pertanto non sono capaci di gestire direttamente più di 3-3,5Gb.
E' pur vero che Photoshop CS2 e CS3 sono in grado di riconoscere il sistema operativo sul quale sono stati avviati: nel caso risulti essere Windows Vista (versioni 64bit) oppure MacOSX Leopard, Photoshop attiva un flag che permette di demandare la gestione dello "Scratch" al sistema operativo il quale, essendo capace di gestire la RAM oltre i 4Gb, utilizzerà la RAM al posto dell'HD fino ad esaurimento della RAM stessa.
In pratica con i nuovi OS a 64bit è possibile sfruttare la RAM oltre i 4Gb come si trattasse di un "disco virtuale", accelerando in maniera drastica le operazioni di Photoshop sul file di Scratch.

Riassumendo, installare RAM oltre la soglia dei 4Gb ha un costo elevato ed in molti casi (tutti gli OS a 32bit) non si riesce ad ottenere alcun beneficio.
Nel caso si utilizzi un OS a 64bit si può considerare lo sforzo economico per raggiungere gli 8Gb di RAM, ma solo a patto che i 4-5Gb ad uso "disco virtuale" siano sufficienti a contenere il file di Scratch nella grande maggioranza dei lavori in Photoshop.

Attualmente un buon compromesso tra efficienza e costi si trova tra i 2Gb ed i 4 GB di RAM. E' tuttavia importantissimo -come vedremo più avanti- disporre di almeno un HD veloce da riservare al file di Scratch, in modo che, non presentando alcuna frammentazione, possa lavorare sempre al massimo delle sue prestazioni.


Tempi di calcolo con HD "standard"

Nella seguente tabella sono riportati i tempi di calcolo di PTgui e di Photoshop. Per quest'ultimo sono state considerate solo alcuni operazioni basilari che vengono normalmente eseguite: fa eccezione solo Autoblend, che è stato inserito nella sequenza perchè costituisce un dato molto interessante, anche se si tratta di un'operazione non necessaria.

Operazione
Tempo
RIF
PTgui 7.2 - Warping (Lanczos) 28min
100
PTgui 7.2 - Blending (PTgui blender) 18min
100
PTgui 7.2 - Saving PSB format 03min 30sec
100
PTgui 7.2 - Tempo totale 49min 30sec
100
PS CS3 - File/Open 04min 30sec
100
PS CS3 - Edit/Crop 06min 11sec
100
PS CS3 - Edit/Autoblend * 11min 05sec
100
PS CS3 - Layers/Flatten image 02min 10sec
100
PS CS3 - Tempo totale 23min 56sec
100
Tempi di calcolo con files temporanei scitti su HD Maxtor 120Gb
* Operazione opzionale


Bene, questi tempi costituiscono da questo momento il nostro riferimento, percui gli assegnamo un valore di riferimento (RIF) pari a 100.

La domanda da porsi adesso è la seguente: fermo restando il tipo di processore e l'ammontare di RAM presente nel sistema, se e quanto è possibile migliorare queste prestazioni?

La risposta sta nell'analisi del tracciato di utilizzo del processore (cronologia processore), generata dall'utility "Task manager" presente in Windows XP.
Se l'utilizzo medio del processore è molto elevato, il collo di bottiglia è tendenzialmente il sistema processore (CPU)/ motherboard.
Se viceversa l'utilizzo medio del processore è basso, il collo di bottiglia sta nella lentezza di accesso alle risorse, che spesso è dovuta alla lentezza degli HD sui quali vengono scritti i dati temporanei (Scratch) che non trovano posto in RAM.

Bene, analizziamo i tracciati per le singole operazioni ed i relativi commenti:


Operazione
Cronologia CPU
Commento
PTgui 7.2 - Warping
Carico della CPU costantemente elevato.
PTgui 7.2 - Blending
(PTgui blender -1a fase)
La prima fase del blending è quasi completamente a carico della CPU.
PTgui 7.2 - Blending
(PTgui blender -2a fase)
Nella seconda fase del blending, la CPU lavora molto meno (scrittura dati)
PTgui 7.2 - Saving PSB format
Carico di lavoro CPU medio/basso.
PS CS3 - File/Open
Contrariamente alle attese, la CPU ha un discreto carico di lavoro. Il motivo risiede nella generazione dei livelli cache.
PS CS3 - Edit/Crop
A parte i brevi picchi di elaborazione, la CPU è molto scarica (scrittura dati)
PS CS3 - Edit/Autoblend
Nella prima fase il carico CPU è totale, nella seconda fase diviene molto basso (scrittura dati)
PS CS3 - Layers/Flatten image
Carico CPU medio/basso.
Nota: nei sistemi con CPU dual-core (oppure HT), quando gira una applicazione che impegnerebbe al 100% una CPU mono-core, la funzione "Cronologia CPU" indica un impegno processore del 50%.


Si nota che ogni operazione genera un impegno CPU diverso, che dipende dalla complessità dell'algoritmo e dal volume di dati manipolati. Le operazioni che sembrano risentire maggiormente dei tempi di attesa dell'HD sono in particolare:

- la 2a fase del Blending di PTgui
- il Saving di PTgui
- buona parte del Crop di PS
- la seconda fase di Autoblend layers di PS
- il Flatten image di PS

L'operazione di File/Open di PS è invece abbastanza onerosa per la CPU (che deve costruire i livelli di "cache"), contrariamente alla banalità apparente di questa operazione.

Da questo studio si deduce che potendo contare su HD più veloci, soprattutto per i files temporanei, le operazioni elencate potrebbero essere accelerate in maniera sostanziale.



La velocità di un Hard disk

Se cerchiamo HD più veloci di quelli "standard", dobbiamo capire quali sono i parametri con i quali si valuta la velocità.

Essenzialmente i parametri sono due: velocità di trasferimento read/write e velocità di accesso. Se il disco non è frammentato, il primo parametro determina il flusso massimo di Mb trasferibili da/verso il disco, mentre il secondo determina quanto tempo impiegano le testine a posizionarsi all'inizio del dato (settore) richiesto.

Entrambi i parametri sono importanti, il primo nei trasferimenti di grandi blocchi di dati contigui sulla superficie del disco, il secondo nella gestione di piccoli blocchi di dati non contigui.

Ho utilizzato una utility free chiamata HDTune per misuare la velocità del disco Maxtor 120Gb utilizzato nel test precedente:



La curva azzurra rappresenta il "transfer rate" (flusso) espresso in Mb. Si nota come questo valore decresce verso l'interno del disco (zona a minor velocità tangenziale). La media risulta essere di 46,7 Mb/secondo, risultato in linea con i dischi attuali SATA ad alta capacità.

La "nuvola gialla" rappresenta invece una miriade di accessi casuali, dei quali si può leggere sulla destra il tempo relativo in millisecondi (ms). Si nota come anche in questo caso le prestazioni si abbassano sposandos verso l'interno del disco, determinando una media intorno ai 14ms.

Domanda: esiste qualcosa di decisamente più veloce, senza spendere capitali ingenti in dischi SCSI e relativi controller ?

La risposta è "si", come di vede da questo disco Western Digital Raptor 74Gb, accreditato di un regime di rotazione di ben 10krpm:



Niente male, affatto! Il transfer rate medio è salito quasi del 50%, ma soprattutto il tempo medio di accesso si è praticamente dimezzato, passando da 14ms a 8ms.

Utilizzare come unità dedicata allo Scratch un HD come questo rappresenta già un significato balzo in avanti delle prestazioni di PTgui e soprattutto di Photoshop. E' tuttavia possibile ottenere ancor di più, come vediamo nel prossimo paragrafo.


Due immagini del Western Digital Raptor 74Gb. Nella prima è visibile la meccanica interna.



RAID Stripe

Sembra quasi una parolaccia, invece si tratta di un ottimo sistema per far lavorare due HD assieme, ripartendosi il carico sia dei dati in scrittura che in lettura.

Non è questa la sede migliore per approfondire il principio di funzionamento delle connessioni RAID, ciò che ci interessa è che il sistema è molto efficiente ed il controller che supporta due HD è normalmente fornito di serie sulle motherboard di fascia medio/alta. In alternativa è possibile installare una scheda controller apposita, dal costo abbastanza contenuto.

Altra cosa che ci interessa è che, dopo una banale configurazione da BIOS, il sistema considera i due dischi fisici come un'unica unità logica, senza alcuna complicazione di sorta. La dimensione di questa unità logica è pari alla somma delle dimensioni dei due HD collegati in RAID stripe.

Dunque, se si installano sul controller RAID due dischi "gemelli" come ad esempio i WD-Raptor che abbiamo appena visto, cosa accade alle prestazioni del disco logico? Vediamo:


Risultato molto interessante.

Il transfer rate medio è incrementato di quasi il 50% rispetto al WD-Raptor singolo, ma è più che raddoppiato rispetto al Maxtor 120Gb . La prestazione è praticamente costante su tutta la superficie del disco. La sensazione è che, utilizzando un controller più evoluto di quello fornito di serie con la motherboard, il transfer massimo potrebbe migliorare ancora.

Il tempo di accesso è invece rimasto invariato, perchè l'unità logica RAID stripe assume il tempo di accesso dell'HD più lento: in questo caso, essendo i due HD identici, il tempo di accsesso rimane di circa 8ms.



Tempi di calcolo con due WD-Raptor in configurazione RAID stripe

Nella seguente tabella sono riportati i tempi di calcolo di PTgui e di Photoshop, utilizzando lo stesso sistema del test precedente. Unica differenza è l'installazione di un sistema RAID stripe composto da due WD-Raptor 74Gb: sulla relativa unità logica vengono scritti i files temporanei sia di PTgui che di Photoshop.

Operazione
Tempo
RIF
PTgui 7.2 - Warping (Lanczos) 27min 06sec
96
PTgui 7.2 - Blending (PTgui blender) 11min 56sec
66
PTgui 7.2 - Saving PSB format 03min 03sec
87
PTgui 7.2 - Tempo totale 42min 05sec
84
PS CS3 - File/Open 03min 15sec
72
PS CS3 - Edit/Crop 03min 27sec
55
PS CS3 - Edit/Autoblend * 06min 15sec
56
PS CS3 - Layers/Flatten image 01min 06sec
50
PS CS3 - Tempo totale 14min 03sec
58
Tempi di calcolo con files temporanei scitti su disco RAID stripe
* Operazione opzionale

Come si vede dall'abbatimento del parametro RIF, le operazioni che avevamo precedentemente induividuato sono state velocizzate moltissimo, con tempi spesso pari alla metà del sistema con disco Maxtor 120Gb.

Come previsto, è proprio Photoshop che trae i vantaggi maggiori di questa configurazione dei dischi, con un tempo complessivo di tutte le operazioni praticamente dimezzato. E' un risultato importante, ottenuto con un solo aggiornamento, senza sostituire il computer o alcuna sua parte interna!

D'altronde è proprio su Photoshop che è essenziale una spinta come questa, dato che il calcolo di più progetti PTgui può essere avviato anche in Batch, ovvero senza la presenza dell'operatore.



Un nuovo algoritmo di warping per PTgui.

Se PTgui complessivamente non sembra trarre troppi vantaggi dalla configurazione RAID, il motivo è che -come detto- molte delle sue attività sono totalmente a carico della CPU.

Per ottenere tempi di calcolo migliori si può acquistare un computer con CPU più potente, oppure.... oppure si può scaricare il nuovissimo PTgui 7.3, nel quale la sezione di warping è stata riscritta per trarre vantaggio dai sistemi multi-processore e multi-core (anche virtuale, come nel nostro caso).

Di fatto vengono lanciate in warping due immagini alla volta, cosicchè i processori che supportano nativamente il multi-threading reagiscono in maniera molto più veloce dei processori classici. Ecco la progress bar di PTgui 7.3 durante il warping:

Durante questa (lunga) fase, il Pentium 4 HT è spremuto al massimo, con i due core virtuali utilizzati quasi al 100%:


Cronologia CPU durante PTgui 7.3 - warping

La fase di blending, sempre giudicando dalla cronologia processore, non sembra essere stata riscritta. La funzione indica un utilizzo di circa il 50%:


Cronologia CPU durante PTgui 7.3 - blending

Vediamo sei il test dei tempi di esecuzione, eseguito sullo stesso progetto, conferma queste indicazioni:

Operazione
Tempo
RIF
PTgui 7.2 - Warping (Lanczos) 19min 50sec
73
PTgui 7.2 - Blending (PTgui blender) 11min 46sec
65
PTgui 7.2 - Saving PSB format 03min 05sec
87
PTgui 7.2 - Tempo totale 34min 41sec
69
Tempi di calcolo con files temporanei scitti su disco RAID stripe, con PTgui 7.3


Tutto confermato, dunque. Il warping è stato accelerato di circa il 30%, mentre le altre operazioni impiegano praticamente lo stesso tempo.

Di fatto utilizando due HD Raptor in configurazione RAID in combinazione al nuovo PTgui7.3, abbiamo ridotto di oltre il 30% i tempi di calcolo di questo progetto. Un ottimo risultato.

Con harware più recenti, in particolare con processori dual-core oppure quad-core, questo dato potrebbe portarsi intorno a -50%, ovvero circa 24min di calcolo. Eccellente, vista la pesantezza del progetto.



.... e PhotoMerge CS3 ?

Chi esegue Stitching in maniera "professionale", sa benissimo che Photomerge non è uno strumento di lavoro adatto.

Tuttavia qualche "compitino" facile-facile riesce ad assolverlo bene, e soprattutto molto velocemente.

Per il test ho utilizzato il sistema con i due dischi in configurazione RAID stripe.
Diciamo subito che il nostro Stitch da 17 immagini (disposto 4 su righe di 4 immagini, più una ulteriore immagine) non è stato digerito da Photomerge CS3, neanche dopo aver ridotto ad 8bit/canale tutte le immagini.
Il processo di "AutoAlign" va in stallo (CPU occupata fissa al 50%) dopo qualche minuto di attività. Da ciò ho dedotto che il miti non sta nel peso totale delle immagini, piuttosto nella loro disposizione: oltre le tre righe il processo si blocca. Se qualcuno ha ottenuto risultati diversi (magari nella versione per OSX), ci farebbe piacere una sua testimonianza nel nostro forum.

Eliminando una riga dal progetto, ho ottenuto un totale di 12 immagini.
Stavolta il risultato non si è fatto attendere, nel vero senso della parola: processo completato (AutoAlign +AutoBlend) in appena 12 minuti !!

Risultato davvero interessante, tenuto presente l'immagine finale da circa 65 Mpixel a 16bit/colore.

Peccato per la scarsa flessibilità di Photomerge, davvero misera rispetto a mostri sacri come PTgui. Vabbè, in realtà anche il blender di CS3 ha la sua "magagna", ma la scopriremo nel prossimo articolo.



Conclusione

Il lato economico: un disco WD-raptor 74Gb costa attorno ai 140euro (IVA esclusa), cifra abbastanza elevata rispetto alla capienza, ma ovviamente si tratta di una ottimizzazione senza compromessi sulla velocità. Con 280euro si compone un RAID a due dischi, controller escluso (spesso è integrato nella motherboard).

Le prestazioni del sistema, come abbiamo visto, aumentano in misura evidente, specialmente lavorando immagini molto pesanti -come gli stitch multi layer- all'interno di Photoshop.

Consiglio questa soluzione a chi realizza frequentemente immagini Stitch, ed in particolar modo a chi realizza fotografie panoramiche ad alta risoluzione.

Per chi volesse puntare al massimo, segnalo la possibilità di utilizzare i dischi con interfaccia SAS (Serial Attached SCSI) e regime di rotazione pari a 15krpm.
Il costo di questi HD è superiore a quello dei SATA Raptor (confrontando HD di pari capacità) ed è possibile reperire schede RAID che supportano l'interfaccia SAS a prezzi ragionevoli. Si deve tuttavia porre attenzione al fatto che la grande maggioranza delle attuali motherboard (quella del Mac Pro rappresenta una delle eccezioni) non dispongono di interfaccia SAS, pertanto i dischi SAS possono essere utilizzati solo attraverso schede di espansione (siano esse RAID o meno).



 Se vuoi parlare con noi di questo articolo vieni a trovarci sul FORUM

E' vietata la riproduzione anche parziale di questo articolo senza il consenso dell'autore.