| Autore |
 Topic  |
|
mxa
Advanced Member
Germany
533 Posts |
 Postato - 15/04/2006 : 01:07:26
|
In questo thread metto un po' di dati che ho ricavato dall'uso di PTGui.
1. Lo stitching piu' grosso finora e' un 70,000x7,500 a 8 bit, circa 1.6GB, da un composito di 86 scatti (Canon 20D). Output era TIF.
2. Lo stesso stitching ma a 16 bit e' morto di morte violenta dopo circa tre ore. Immagino che a questi livelli si debba usare PSB.
3. In generale il lavorare a 16 bit rallenta il processing in modo molto sensibile.
4. Se la sequenza di immagini e' relativamente corta (sei, sette) e lineare il panorama che risulta dopo aver fatto calcolare i control points e' centrato e tutte le immagini sono allineate sul fondo (se i fotogrammi erano verticali, per esempio).
5. Se c'e' una striscia sola ma ci sono molte immagini o ci sono almeno due righe di fotogrammi ed il numero di questi e' notevole (tipo una ventina o piu') il panorama risultante richiede sempre un pesante intervento manuale di yaw/pitch/roll. Questo in se' non e' un grosso problema, l'unico inconveniente e' che diventa molto difficile capire se il panorama risultante e' effettivamente orizzontale o se e' leggermente inclinato verso sinistra o destra. E' vero che si puo' correggere in Photoshop, ma quando uno gira con la testa autolivellante piu' la testa pano proprio per assicurare la panoramica orizzontale non vorrebbe che il software introducesse lui una pendenza a destra o sinistra che non esisteva nell'originale. Questo e' un po'seccante.
6. L'interfaccia innervosisce un po', perche' non e' consistente. Aprendo PTGui la condizione di default dentro al tab optimizer e' "Minimize lens distortion=heavy" quando quella "recommended" e' medium. Uno si aspetterebbe che il default sia appunto "medium". Nel "Create Panorama" uno si aspetterebbe come default di "set optimum size" quello "maximum", invece si ha come default una dimensione che non so esattamente da dove venga. Se la mia ultima selezione nello stesso campo e' stata per il file format "TIF", quando esco e rientro in PTGui mi aspetterei di trovare quella che ho lasciato l'ultima volta, cioe' "TIF". Invece mi trovo "JPG"
7. Ci sono cose che mi lasciano perplesso nei control points. Per esempio, se la tabella mi mostra che due control points distano 6 pixel e vado a controllare, spesso non trovo sei pixel di distanza, ma magari due. Sposto uno dei due pixel per metterlo nello stesso posto, vado a ricontrollare la tabella, nulla e' cambiato. Oppure la distanza e' aumentata! Quando mi sono intestardito, per provare il software, a ridurre la distanza tra due control points spostando uno dei due non sono mai riuscito a ridurre la distanza per piu' di un pixel. Portare la distanza da sei a cinque ci sono riuscito spesso, ma metti da sei a due mai. Magari c'e' qualcosa che non capisco nel concetto di "distanza". Io facevo riferimento a forme e linee nell'immagine per portare i due pixel nello stesso punto nei due fotogrammi.
8. In generale il tool e' molto potente e intelligente, il pattern matching funziona proprio bene anche in mosaici di fotogrammi disposti in ordine molto confuso.
9. Ci sono tanti piccoli appunti da fare sulla interfaccia su cose che andrebbero migliorate ma sono secondari nel senso che ci sono workarounds non fastidiosi.
10. Quando la stessa persona compare in due fotogrammi diversi (perche' durante il panning camminava, per esempio) il default e' che viene cancellata in uno dei fotogrammi cosi' che non compare due volte in due posti diversi. Per lo meno cosi' e' quello che ha fatto PTGui in uno dei miei panorami. Il problema e' che la cancellazione si vede, nel senso che rimane una macchia. Avrei preferito che il default fosse che la persona viene lasciata li' e poi ci penso io in Photoshop a cancellarla. Quindi apprezzo l'intelligenza del software che si avvede di un pattern complesso che ricompare in un altro fotogramma e so dall'articolo di Enrico che ci sono modi per gestire il problema della presenza multipla di persone o oggetti in movimento. Dico solo che nel caso banale, cioe' quello in cui uno usa il software in modo totalmente automatico, avrei preferito che non ci fossero interventi come la cancellazione di cose o persone ma quello che viene viene. Immagino che altri la possano pensare diversamente. Il risultato pero' e' che dato che la cancellazione non e' fatta a regola d'arte mi trovo costretto comunque ad intervenire in Photoshop, quindi tanto valeva ... hmmmmm
Marco |
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 15/04/2006 : 09:24:26
|
Marco,
la tua più che una esperenzia è praticamente una recensione! Ottimo.
Tu sei andato veramente a fondo, io normalmente non costruisco stitch così... immensi!
Uso sempre 16bit/colore, spesso in formato multi-layer, perchè in PS voglio essere libero di "smanettare" liberamente, e non ho mai avuto problemi con PTGui. E' però verò che non sono mai andato oltre i 14 fotogrammi, 7x2righe...
Per i tuoi super-stitch (hai raggiunto 0,5 Gp !!) probabilmente ci vuole un bel po' di RAM (2Gb, ad esempio) e probabilmente è bene impostare più di una cartella per i files temporanei. Prova anche ad impostare il formato PSB.
Sul punto 5 mi fido di ciò che dici, non ho neppure materiale sufficiente per fare prove! 
La cosa tuttavia mi stupisce un po', perchè a giro per il web si vedono immagini Gigapixel fatte con PTGui, stento a credere che sono stati costruiti manualmente agendo su Yaw/Pitch/Roll....
Sarebbe un problema per te girarmi il progetto ed i files incriminati (jpg ridotti, ovviamente)? Garantisco al 100% sui diritti di copyright!
Punto 6: siamo d'accordissimo, come ti dicevo l'interfaccia non è il punto forte di PTGui, e alcune cosette potrebbero essere sistemate con poco sforzo.
Sul punto 7 si può discutere molto, secondo me il valore di "distanza" si riferisce alla posizione dei due control points dopo l'ottimizzazione: in condizioni ideali è zero (i due CP coincidono), mentre di norma il valore è maggiore di zero perchè la ricostruzione del fotogramma (vincolata da tutti i CP presenti) non riesce a far sovrapporre la coppia di CP. Sono in pratica gli errori di parallasse e la non ottimale individuazione della distorsione che determinano questi errori.
Sul patternmatching sono d'accordo, è molto efficiente, anche se in presenza di soggetti in movimento preferisco sempre lavorare in multi-layer, che mi fornisce la massima libertà in fase di post-processing.
Infine una curiosità: cosa pensi di forne dei tuoi super-stitch? Pensi di stamparli? Sono curioso....
Ciao
Enrico |
 |
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 15/04/2006 : 11:26:00
|
Confermo,
per quelle dimensioni del file è obbligatorio il formato PSB, in quanto il PSD è limitato a max. 30.000 pixel di lato e 4gb di dimensioni (PS CS2, mentr per CS solo 2Gb)
Ciao
Enrico |
|
|
|
mxa
Advanced Member
Germany
533 Posts |
Postato - 15/04/2006 : 19:00:47
|
Qualche aggiornamento.
1. Ho preso un grosso stitch e ridotto le dimensioni di tutti i fotogrammi di un fattore 2 (area ridotta di un fattore 4). Ho poi convertito tutto in jpg e fatto i seguenti passi:
a) Aperto PTGui
b) Caricato tutte le immagini come venivano
c) Selezionato nel 'Panorama Settings' Cylindrical invece che Rectilinear
d) Cliccato su 'Generate Control Points'
e) Fatto questo, controllato con Optimizer che tutto fosse OK, Optimizer mi ha detto 'very good'.
f) Creato il panorama
Il risultato, in dimensioni accessibili via rete, e' in
www.resonantlink.com/minipano.jpg
(Enrico, pensavo di mandarti questo settimana prossima --- in versione originale TIF.)
Il comportamento e' identico a quello dello stitching con immagini TIF16 e formato originale, quindi il comportamento di PTGui non e' dato da problemi di codifica in TIF o da dimensioni per qualche motivo troppo grosse, perche' anche nel molto piu' piccolo jpg si comporta nella stessa maniera. Questo non e' il comportamento piu' estremo, in altri casi fa un wrap-around della immagine. Questa parte dal centro, continua sulla destra fino a raggiungere il limite estremo destro e ricomincia ('wrap around', appunto) dal lato sinistro. Usando in questo caso il comando di yaw si trasla l'immagine e la si centra correttamente.
Due punti sulle tue osservazioni, Enrico.
1. I control points continuano a confondermi. Mi e' successa la seguente cosa
a) Optimizer mi dice che errore medio e' 4.5 (metti)
b) Tolgo dalla tabella le coppie di control points peggiori
c) Optimizer mi dice che errore medio e' 4 (ok)
d) Aggiungo tre o quattro coppie di control points a mano, ovviamente posizionandoli accuratamente
e) Giro optimizer, mi dice che l'errore medio e' 4.8, quindi peggio che in (a)
f) Controllo la tabella, le coppie di control points che ho messo io a mano sono le peggiori di tutti.
[?????]
2. Mi chiedi cosa penso di fare per la stampa. Come forse sai sono rientrato da qualche mese dall'estero e non ho ancora una stampante. Prima di partire stampavo i miei panorami, piu' piccoli, su una Epson 1280 con la carta a rullo matte con i Lyson Quad per il bianco e nero (molto contento). Per il colore usavo una Epson 2000P, sempre carta Epson a rullo semi-gloss, metamerismo micidiale, una schifezza.
Adesso penso di prendere una 4800 ed usare sempre la carta in rullo. Certi panorami sono gia' alti circa 25 pollici pero', quindi una 7800 sarebbe meglio. Ma e' tutto un problema di soldi, tanto per cambiare ...
Ciao
Mxa |
|
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 15/04/2006 : 20:14:15
|
Bene Marco,
a questo punto devo dirti che non vedo l'ora di mettere le "mani" su un tuo stitch, perchè davvero non capisco cosa accade.
Mandami pure lo stitch che hai postato, cercherò di capire per qule motivo PTGui non rispetta la tua indicazione circa la "anchor image".
Circa la tua domanda sui CP,
il comportamento dell'optimizer può essere poco chiaro, ma secondo la mia esperienza i dati sono giusti.
In base al numero e alla posizione dei CP immessi, optimizer calcola yaw/pitch/roll e valori di distorsione che meglio soddisfano tutte le condizioni imposte. Se tu cancelli dei CP, lui ricalcola nuovi valori sulla base di un MINOR numero di vincoli, dunque è molto facile che l'errore medio si abbassi..... ma questo abbassamento è dovuto solo al minor numero di vincoli!!
Quando torni ad aggiungere CP, i vincoli aumentano e il ricalcolo dei paramentri torna a determinare scostamenti maggiori, dunque l'errore medio torna ad alzarsi.
Ergo: avendo disposto bene i CP (e in numero sufficiente), non ha senso fare una "battaglia" per abbassare l'errore medio...
Tieni presente che un errore di 4-5 su files come i tuoi è molto buono, infatti PTGui dice "very good". Il blender va a nozze con questi valori...
Se scarti tutti i CP che cadono in primo piano, vedrai che l'errore diminuisce perchè in pratica ottimizzi l'area di sfondo, escludendo gli errori di parallasse. Questo però genererà un stitch migliore solo nell'area ottimizata, mentre in p.p salteranno fuori i disallineamenti.
Come dice Andrea "Papàrazzo", spero di essermi capito!
Sul punto 2, beh la mia era pura curiosità!
In effetti con 7500px sulla verticale puoi permetterti un bell'A0 in rullo, mantenendo la bellezza 240dpi !!! Il pensierino lo farei anche sulla 9800, cash permettendo!
Io ho stampato un mio stitch da 50Mp su formato 85x40 cm con una 4800, devo dire che è un vero spettacolo! Mamma mia, roba da banco ottico, non so se 4x5" o superiore....
Resto in attesa dei files.
Ciao
Enrico |
|
|
|
mxa
Advanced Member
Germany
533 Posts |
Postato - 17/04/2006 : 00:02:01
|
Altri dati su un nuovo stitch che ho fatto apposta con testa panoramica e tantissima cura per vedere quanto si possa spingere il software. PC con 2GB memoria, processore Pentium 4 2.8GHz vecchio circa di due anni.
1. 148 fotogrammi 8bit TIF da una Rebel XT
2. Stitch risultante 48862x12126, file size (PSB) 4.4GB
3. Run-time. 8:41pm-inizio del run | 10:10pm-fine control points | 11:29pm-fine blending | 11:37pm-fine del run.
4. Immagine di 180 gradi fatta con testa panoramica a tre gradi di liberta', obiettivo 95mm focale (circa 150mm equivalente, 1/50 f/16, ISO 100), punto nodale obiettivo allineato con centro di rotatione testa pano, quattro strisce di 37 fotogrammi ciascuna. Striscia #1: inclinazione -15 gradi (verso l'alto), striscia #2 inclinazione -5 gradi, striscia #3 inclinazione +5 gradi, striscia #4 inclinazione +15 gradi (verso il basso).
5. Apertura file risultante con Photoshop circa 4 minuti
6. 38 GB di disco usato per file tmp.
Ci sono alcuni comportamenti strani su cui sto indagando, ma in generale il panorama guardato a 100% e' praticamente perfetto.
Mxa |
|
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 17/04/2006 : 10:39:58
|
Marco,
le tue sono perle di stitching, stai raggiungendo livelli per me impensabili!
I tempi possono sembrare lunghi, ma secondo me non lo sono affatto rispetto al "cubaggio" dello stitch! 0,6 Gigapixel !!
Se devo fare una osservazione sui tempi, mi pare proporzionalmente alto il tempo di ricerca dei CP, specie se confrontato col tempo di creazione della pano (blending compreso).
Credo che tu sia uno dei tester di PTGui più accaniti di tutto il continente, sarà estremamente interessante conoscere gli sviluppi delle tue ricerche.....
... e sarebbe ancor più interessante vedere stampato il tuo stitch in dimensioni ragguardevoli!
PS: con questo stitch hai avuto gli stessi problemi all'interno del pano-editor?
PS2: sarebbe interessante ripetere il test a 16/bit-colore, anche se temo ci vorrà molto più tempo.
Ciao
Enrico |
|
|
|
mxa
Advanced Member
Germany
533 Posts |
Postato - 17/04/2006 : 15:11:23
|
Citazione:
Postato da Enrico
Marco,
PS: con questo stitch hai avuto gli stessi problemi all'interno del pano-editor?
PS2: sarebbe interessante ripetere il test a 16/bit-colore, anche se temo ci vorrà molto più tempo.
Ciao
Enrico
Risposta a PS 1: assolutamemte si, nel senso che il pano risultante nell'editor era il solito arco un po' sinuoso (con componenti sia di pitch che di roll, insomma)
Risposta a PS2. Se ho tempo ci provo, ma ho paura che mi vaporizzi la memoria e/o i dischi...
Ho avuto dei problemi strani, che mi richiedono troppo tempo per documentare qui o spiegare con testo. Mi riprometto di tornarci sopra nei prossimi giorni e se il comportamento rimane non ovvio e misterioso, allora metto insieme un altro messaggio.
Di stampare questo stitch specifico non se ne parla nemmeno...la vista dal balcone di casa in montagna ! Pero' ci sono case con un sacco di linee in primo piano e montagne sullo sfondo quindi e' un utile test.
Mxa
|
|
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 17/04/2006 : 16:00:30
|
Circa il PS1,
il fatto che si formi un arco sinuoso è normale scattando su treppiede in bolla (si risolve con "straighten panorama" oppure con qualche CP orizzontale t2), io mi riferivo al fatto del mancato rispetto della "anchor image" al centro del panorama.
Ciao
Enrico |
|
|
|
mxa
Advanced Member
Germany
533 Posts |
Postato - 21/04/2006 : 21:21:25
|
Continuano i miei esperimenti con PTGui, che mi permette di provare delle nuove cose. Riporto un esperimento tuttora in corso che mi sembra promettente.
Allora, tutti i sacri testi delle foto panoramiche fatte con stitching dicono di settare la macchina in manuale con diaframma e tempi prefissati. Il risultato di questo e' --- per la natura stessa del panorama, che abbraccia campi molto ampi --- di avere primi piani correttamente esposti e cieli orrendamente slavati oppure cieli belli dinamici o drammatici e primi piano buio pece. Che fare?
Una possibilita' e' di usare il classico filtro degradante. Se la panoramica e' una singola striscia con la macchina in verticale questo e' banale. Se la panoramica e' composta da piu' di una striscia si puo' adoperare il filtro degradante nella striscia piu' in alto, dove c'e' il cielo, e toglierlo quando si scende. Con un po' di pratica e qualche precauzione ulteriore (si parte dall'alto e non dal basso, per esempio) funziona.
Un'altra possibilita' e' piu' ambiziosa ed estrema, ma anche piu' entusiasmante. Essenzialmente consiste nel rompere le regole e non fotografare in manuale ma in esposizione a diaframma fisso. Quindi la macchina (rigorosamente in bolla, testa panoramica e cavalletto, beninteso) cambiera' i tempi sulla base di quello che la matrice di sensori gli dice. Il diaframma ovviamente deve rimanere lo stesso perche' la prodondita' di campo non deve cambiare da fotogramma a fotogramma.
Orrore! Eresia!... ma qui si inserisce il secondo trucco, cioe' una quantita' di fotogrammi spaventosa e con forti sovrapposizioni. Per cui si fanno panoramiche con obiettivi da lunghezze focali da 200mm in su e con cento, duecento fotogrammi da mettere insieme per panoramiche impegnative. L'intuizione in tutto questo e' che cambiando la base dei tempi da un fotogramma all'altro la esposizione sara' si diversa, ma il livello di sovrapposizione ed il numero di fotogrammi (oltre all'algoritmo di blending del software) compenseranno.
Questo approccio permetterebbe di avere dei bei cieli saturi e dei primi piani correttamente esposti, con risultati superiori a quelli ottenibili dall'uso del filtro degradante.
Sto facendo un sacco di esperimenti sul livello di sovrapposizione e sulla quantita' di fotogrammi, vedremo. Come dicono i buoni amici americani "The devil's in the details". Ci si ritrova per esempio a fare un sacco di stiching tra nuvole, e se c'e' vento, dato che intercorre anche un minuto tra fotogrammi in strisce diverse ... insomma avete capito.
Sembra pero' essere promettente. E' evidente che se funziona (premetto un "se") funziona solo con pesanti sovrapposizioni tra fotogrammi adiacenti. Quindi con un gran numero di fotogrammi.
Mxa |
|
|
|
mxa
Advanced Member
Germany
533 Posts |
Postato - 24/04/2006 : 00:45:39
|
Allora, ho concluso un esperimento mettendo insieme circa 360 immagini prese con una Rebel XT. L'esperimento voleva provare la teoria del fare le foto mantenendo fisso il diaframma e lasciando la macchina variare i tempi, ma mettendo i fotogrammi molto vicini l'uno all'altro. Ho usato una focale (questo e' importante) di 135mm che con il fattore 1.6 della Rebel XT diventa un 216mm. Il risultato (croppato) lo potete vedere in www.resonantlink.com/lpano.jpg
Dal punto di vista del compensare il cielo e il primo piano mi sembra molto riuscito, nel senso che il cielo non e' tutto slavato ed il primo piano non e' buio. C'e' un bell'equilibrio tra i due. Sto lavorando su un panorama piu' piccolo in cui i due metodi (cioe' tutto manuale e priorita' dei diaframmi) sono messi a confronto, vedremo.
Qualche numero:
1. Immagine finale (8 bit TIF non compresso): 9.7 GB (ma leggi sotto)
2. Memoria virtuale necessaria 92 GB.
3. Tempo di generazione del panorama circa 9 ore.
4. Tempo di generazione dei control points circa 3 ore
5. Altre tre ore per aggiustare manualmente fotogrammi orfani assegnando control points manualmente.
6. Un pezzo di cielo e' stato impossibile da collegare con il resto perche' non c'erano profili nuvolosi distinti abbastanza (o tutto azzurro o tutto grigio piatto)
Per quanto riguarda 1 sto combattendo sempre con un fastidiosissimo problema che non capisco se sia un bug in PTGui o io che non lo so usare. Quando entro in editor e raddrizzo il panorama con yaw/pitch/roll la striscia di fotogrammi piu' in basso e' allineata con la mezzeria della finestra nera e non c'e' verso di farla scendere. Vedi
www.resonantlink.com/PTGuieditorwhat.jpg
Quando genero il panorama l'immagine che viene generata contiene anche questa parte nera inferiore che quasi raddoppia le dimensioni dell'immagine e mi tocca dopo entrare in Photoshop e fare il crop. Capirete che quando invece di 4 GB di immagine se ne generano 9.7 GB per colpa della stupida banda nera la cosa non e' di poco conto. Questo problema l'ho sempre avuto sin dall'inizio. Mentre usando yaw riesco a spostare l'immagine a destra o a sinistra a piacimento dentro all'editor, questo non mi e' possibile in senso verticale. Giocando con i vari tastini dell'editor non sortisce nessun effetto ("fit panorama vertically", "center panorama vertically", "straighten panorama", tutto inutile).
Il problema piu' grave e' comunque uno stranissimo comportamente della Rebel XT che non sono riuscito a domare. In pratica piccoli spostamenti della camera risultano --- in RARI CASI --- in grandi spostamenti QUALITATIVI dell'esposizione. Questo manda a pallino tutto il discorso di ottenere transizioni soft tra un fotogramma ed il precedente. Non capisco quale sia il problema francamente. L'esposizione che ho usato era a matrice, cioe' evaluative, pensavo che fosse OK, ma magari devo adoperare, vista la natura della focale (tele abbastanza spinto) il center-weighted. Ho controllato dieci volte che non fosse spot (questo spiegherebbe...) ma non lo e'. Vedi le due foto
www.resonantlink.com/left.jpg
e
www.resonantlink.com/right.jpg
che sono state prese a distanza di meno di due secondi l'una dall'altra nella stessa situazione di illuminazione. Guardando all'EXIF si vede che la prima e' presa a 1/50 la seconda a 1/60, ovviamente stesso diaframma. La differenza di esposizione non e' cosi' grande (20%) ma l'erba in left.jpg appare molto piu' brillante che in right.jpg , molto piu' che la differenza tra 1/50 e 1/60 direi, no? Il blending di PTGui (poverino) non puo' compensare un salto cosi' brusco ed infatti la transizione fastidiosa e' presente anche nel panorama finale. Ci sono altri due o tre posti nel panorama dove succede, di nuovo con l'erba nel centro del panorama e si vede infatti in quello finale una specie di banda verde piu' chiara. 
Qualcuno sa darmi qualche indizio? E' possibile che premendo il flessibile troppo in fretta talvolta non dia il tempo al sistema esposimetrico di fare il suo dovere? Ma questo vorrebbe dire che la macchina ha memorizzato 1/50 nell'exif di left.jpg ma infatti ha scattato a, metti, 1/30? Faccio fatica a crederlo.
L'Optimizer mi e' morto una volta con un messaggio "run out of memory". Ho semplicemente salvato il progetto, fatto un reboot della macchina, riaperto il progetto in PTGui e ho potuto rilanciare l'Optimizer senza problemi. Ci potrebbe essere da qualche parte un problema di memory leak a questi livelli di memoria virtuale/reale, chissa'.
Il tempo di generazione del panorama e' completamente inaffidabile: per poter dare in pasto al software 90 GB di spazio disco ho collegato un hard disk esterno pulito, ma tutto il traffico sul disco e' passato attraverso una USB 2.0, quindi le nove ore potrebbero diventare facilmente la meta' se il traffico fosse verso un disco SATA.
Il punto 6 e' una scocciatura, perche' la fetta di cielo non si puo' collegare alla striscia inferiore in quanto ora che si arrivati li' e passato piu' di un minuto e le nuvole sono cambiate di forma in modo tale da rendere impossibile identificare somiglianze. Lo si puo' fare pur sempre a mano comunque.
C'e' un bug nell'editor. Quando si entra nell'editor e si clicca la icona in basso a sinistra si apre una fila di finestrelle in alto che contengono la numerazione dei vari fotogrammi. Quando il cursore sovrappone un fotogramma nell'editor si evidenzia nella fila di finestrelle il numero del fotogramma. Bene, questa numerazione procede da 0 in su, ma quando arriva a 99 non passa a 100 ma impazzisce: ricomincia con 10 e continua con 10 per un po' poi passa a 20 e sta a 20 per un po', insomma c'e' un problema.
La avventura continua ...
Mxa |
|
|
|
AlbertoM
Moderatore
Italy
4742 Posts |
Postato - 24/04/2006 : 01:56:28
|
Complimenti per la tua ricerca!
Volevo chiederti se avevi pensato (o anche provato) un altro approccio al problema che mi era venuto in mente tempo fa e che non ho ancora avuto il tempo di provare
Ovvero quello di utilizzare il tool di Photoshop "Merge to HDR" per aumentare la gamma dinamica di un panorama.
Ho provato qualche volta questo tool, però su di un'immagine singola, ed effettivamente mi ha tirato fuori un sacco di dettagli sia nelle luci che nelle ombre. L'impressione generale, però, è stata di basso contrasto, e mi sono ritrovato ad usare curve e livelli per rendere più contrastata l'immagine, perdendo tanti dei dettagli recuperati con il tool.
Per questo "Merge to HDR" mi sembra più adatto proprio all'esecuzione di panorami con PTGUI.
In pratica si tratterebbe di scegliere un'esposizione media per il panorama (ad es 1/125 f/11) e di scattare ogni fotogramma in breacketing a +/- 4 stop. Infatti questo tool funziona bene se si usa un passo grande, ovvero di almeno 4 stop, altrimenti non ci sono evidenti benefici.
Il bello è che si può scattare anche in RAW, e si possono usare sovrapposizioni normali nei fotogrammi.
Quello che non so è se l'esposizione media dei fotogrammi rimane circa costante, se cioè non servono salti mortali al programmino di blending per rimettere in squadra l'esposizione complessiva.
In pratica, in questo modo, si sposterebbe un bel po' di lavoro prima dell'uso di PTGUI, ma i dettagli dovrebbero comunque saltare fuori. Poi si potrebbe comunque intervenire localmente con curve e livelli per aumentare il contrasto e mantenere leggibilità dei dettagli.
Mi hai messo una pulce nell'orecchio.
Domani voglio fare una prova.
Non con 360 scatti, però 
AlbertoM |
|
|
|
mxa
Advanced Member
Germany
533 Posts |
Postato - 24/04/2006 : 07:42:44
|
Ci ho pensato, ma sono ancora fermo a CS. Interessante l'informazione che per funzionare HDR vuole un bracketing cosi' sostanzioso. Senza sapere nulla io avrei fatto +/- 2 al massimo.
Se tu vuoi usare HDR su ciascuna tripletta prima di usare PTGui allora condivido le tue preoccupazioni, e' importante che HDR si comporti 'con coerenza' con tutte le triplette altrimenti o tu o il blending (si spera il blending...) dovete sudare.
L'alternativa sarebbe di usare HDR sui tre panorami fatti a 0, +4 e -4. Questo eliminerebbe il problema dalla consistenza, ma ne introdurebbe altri:
(1) PTGui non riesce a fare lo stitching di molte zone a -4 perche' ... non ci vede un acca e non riesce a fare lo stiching di zone a +4 perche' ... abbagliato. Quindi di ritrovi in mano tre panorami a cui mancano pezzi. Per quanto tu riesca faticosamente a completarli a mano le tre foto non saranno allineate al pixel, ma ci potrebbero essere spostamenti significativi.
(2) Se anche (1) non si presenta i tre panorami non saranno comunque allineati al pixel, anche se hai testa panoramica di buona fattura. Magari con il crop riesci ad allinearli al pixel, magari no. Come si comporta HDR quando i tre fotogrammi non sono _perfettamente_ allineati?
Facci sapere!
Mxa
P.S. Una curiosita': la Noblex a obiettivo rotante ha un optional che quando installato modifica l'esposizione durante la rotazione dell'obiettivo. Solo che in questo caso l'esposizione cambia solo sull'asse orizzontale, per intendersi, mentre nel nostro caso la cambiamo sui due assi, mooooooolto piu' potente |
|
|
|
mxa
Advanced Member
Germany
533 Posts |
Postato - 24/04/2006 : 16:22:13
|
Dunque l'idea funziona!
L'abbazia di Novacella fatta con i due metodi
www.resonantlink.com/pano1.jpg
e
www.resonantlink.com/pano2.jpg
Il numero di fotogrammi e' 96, piccolino per i miei standard 
L'unico intervento in Photoshop e' stato di croppare il fondo per togliere i tetti di alcune automobili.
Il metodo a priorita' dei diaframmi e' ovviamente quello dove il cielo si vede. Quello 'canonico' impostazione tutta manuale 'media' quello con il cielo slavato.
Una analisi accurata dei due jpg fa vedere che non e' semplicemente uno con il cielo piu' scuro dell'altro, le differenze di esposizione sono piu' complesse ed interessanti...
Basta, adesso devo lasciar riposare il PC 
Mxa
|
|
|
|
nikarlo
Advanced Member
Italy
826 Posts |
Postato - 24/04/2006 : 22:51:44
|
nella prima le differenze di esposizione si notano....e se invece si fanno due panorami identici con diverse esposizioni o diversi "svliuppi" di camera raw e poi si mascherano con photoshop?
Carlo. |
|
|
|
mxa
Advanced Member
Germany
533 Posts |
Postato - 25/04/2006 : 01:36:53
|
Citazione:
Postato da nikarlo
nella prima le differenze di esposizione si notano....e se invece si fanno due panorami identici con diverse esposizioni o diversi "svliuppi" di camera raw e poi si mascherano con photoshop?
Carlo.
Quando il cielo e' sovraesposto di cinque o sei stop non c'e' metodo miracoloso in raw di tirarlo fuori senza degli artefatti orribili (contrasto innaturale per esempio), almeno nella mia esperienza.
Due esposizioni diverse e poi una mascheratura in photoshop. Sicuramente crea problemi con il genere di grandi panorami che faccio io per problemi di mancanza di potenza e memoria di PC. Potrebbe funzionare per panorami piu' piccoli, ma date le imperfezioni di allineamento delle teste panoramiche 'abbordabili' ed il fatto che il cielo (e le foglie ed il mare...) si muovono, cosa vuol dire in realta' "panorami identici"?
Comunque varrebbe la pena di fare qualche esperimento. Ma il recupero dell'informazione da due diversi sviluppi del raw quello non mi sembra una strada percorribile.
Ciao
Mxa |
|
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 25/04/2006 : 10:22:52
|
Ciao a tutti.
La gamma dinamica da tenere sotto controllo negli stitch è un problema complesso.
Per non complicarsi troppo la vita, la cosa migliore è esporre in manuale sfruttando al 100% l'istogramma sulle luci, e poi sfruttare le grandi capacità di recupero di dettaglio sulle ombre caratteristico delle digitali.
Bisogna lavorare alla sensibilità nominale, perchè tutte le altre comportano una riduzione della latitudine di posa.
Se questo metodo non è sufficiente (vale a dire che nella scena ci sono più di 7 stop di contrasto) si entra nel mondo delle complicazioni!
Generalmente è il cielo molto luminoso che crea problemi, dunque secondo me bisogna fare uno stitch esposto per la terra e uno (o due) esposti per il cielo.
Per fare ciò consiglio di impostare in manuale la coppia tempo/diaframma per la terra, e impostare un bracketing di -1 e/o -2 stop (quel che serve). Ciascun fotogramma dello stitch verrà ripreso N volte con esposizioni diverse: usare la raffica più veloce disponibile in modo da ottenere fotogrammi virtualmente identici. Ovviamente NECESSITA il cavalletto con testa pano.
Il progetto PTGui si crea su quello esposto per la terra, dato che l'allineamento del panorama deve essere fatto nelle zone con dettaglio riconoscibile.
Una volta completato il calcolo e l'immagine finale, si chiude PTGui, si sostitiuscono i file originali con quelli esposti a -X, si raipre lo stesso progetto PTGui e si crea un nuovo stitch SENZA ottimizzare (così i parametri rimangono identici).
Dai due/tre stitch ottenuti in questo modo, si arriva a quello finale importandoli in PS e lavorando sulle maschere di livello per selezionare le aree esposte correttamente.
NON è una cosa semplice, le risorse PC necessarie possono risultare imponenti, dato che PS dovrà gestire N stitch contemporaneamente, prima del "flatten image" finale.
PS per Marco: ho ricevuto i tuoi CD, ma negli ultimi giorni sono stato molto impegnato: mi riprometto di lavorarci su entro la settimana corrente.
Ciao
Enrico |
|
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 25/04/2006 : 11:28:36
|
Citazione:
Postato da mxa
Qualcuno sa darmi qualche indizio? E' possibile che premendo il flessibile troppo in fretta talvolta non dia il tempo al sistema esposimetrico di fare il suo dovere? Ma questo vorrebbe dire che la macchina ha memorizzato 1/50 nell'exif di left.jpg ma infatti ha scattato a, metti, 1/30? Faccio fatica a crederlo.
La cosa si può spiegare solo con una scarsa ripetibilità del diaframma, ovvero la chiusura al valore f/ impostato talvolta non è precisa. Non è difficile riscontrare errori anche nell'ordine di 1/2 stop, se il meccanismo non è perfettamente efficiente.
Per quanto riguarda il sistema esposimetrico, usa pure quello che preferisci per determinare la corretta esposizione, ma poi scatta sempre e comunque in manuale con una coppia tempo/diaframma prefissata. Magari usa il bracketing come suggerivo nel post precedente.
Ciao
Enrico |
|
|
|
mxa
Advanced Member
Germany
533 Posts |
Postato - 25/04/2006 : 12:12:14
|
Provero' a fare quello che dici.
Ho giocato con vari tipi di livelli di blending dentro PTGui e ho pure scaricato enblend ma non c'e' niente da fare, c'e' un problema di aloni attorno al soggetto contro il cielo e c'e' un problema di bande dentro il cielo quando un pezzo del fotogramma contiene qualcosa di diverso dal cielo (una collina, un pezzo di edificio).
Insomma l'idea dell'esposizione a priorita' dei diaframmi era buona ma non funziona. Con panorami dove il cielo e' minimo potrebbe servire a tira fuori in modo non innaturale dei particolari dei soggetti in primo piano. Forse spingendo ancora di piu' sulla focale, ma a questo punto uno si limita ad angoli di campo abbastanza stretti, anche un matto come me non puo' mettersi a fare migliaia di fotogrammi e gestirseli pure.
Ritengo il progetto 'priorita' dei diaframmi' terminato con fallimento.  Be' finche' uno non prova... continuero' con la tua idea del bracketing
Mi consolo con un po' di surfing'...
http://www.gigapxl.org
http://infovis.cs.vt.edu/gigapixel
http://www.cliffordross.com/R1/gigapixel.html
Mxa
|
|
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 25/04/2006 : 15:21:57
|
Marco,
ho appena concluso i test sul mega-stitch che mi ha spedito su CD (per la cronaca, ben sei!).
Dunque, questi i dati e le impressioni:
- software: PTGui 5.8.1 appena rilasciato
- immagini TIF sorgenti: 148, (37 x 4 righe) - 8bit/colore
- stitch finale: circa 45.000 x 11.000 pixel
- caricamento immagini in PTGui: lento, ma solo apparentemente, visti i 3,4 Gb di files TIFF da leggere...
Nota: i nomi dei files erano molto scomodi, bisognerebbe assegnargli doppia cifra (rowA01 e non rowA1) e numerarli da sx verso dx, in modo da rintracciare facilmente i fotogrammi adiacenti.
- tipo propsettiva: cilindrica
- ricerca automatica CP: in meno di 30 minuti sono stati trovati i CP, con alcune eccezioni: mancavano il fotogramma in alto a sx e i tre in basso a sx.
Nel primo caso ho risolto aggiungendo manualmente i CP, mentre nel secondo caso era difficile rilevare CP dato che i fotogrammi sono scuri e senza dettagli.
PS: i tab con il numero immagine appaiono mal disposti, provvederò a segnalarlo a Joost.
- ottimizzazione: ho escluso i tre fotogrammi senza CP e l'ottimizzazione è andata a fine con "very good", generando un'immagine ben composta e rispettando la "anchor image" impostata (n.45)
- in pano editor l'immagine si presentava inarcata (è normale), ed è stato sufficente spostare più in alto il "center point" per addirizzarla.
- ho poi cercato di riposizionare le tre immagini senza CP, assegnando valori "credibili" di yaw/pitch/roll (non ci ho perso molto tempo, e si vede!)
- la preview mi è sembrata buona, dunque ho avviato la generazione del .PSB finale, che è in corso... mancano ancora un paio di orette abbondanti! Ti dirò le impressioni finali in serata.
Ciao
Enrico |
|
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 25/04/2006 : 15:29:55
|
Citazione:
Postato da mxa
Ritengo il progetto 'priorita' dei diaframmi' terminato con fallimento. Be' finche' uno non prova... continuero' con la tua idea del bracketing
Mi consolo con un po' di surfing'...
Si,
penso che il bracketing sia la strada giusta, anche se non semplicissima da affrontare.
PS: quel Clifford Ross è alla tua portata, anzi l'hai già sopravanzato! 
Adesso ti manca solo una bella Epson9800, oppure una Canon caricata con i "Lucia", vero Alberto?
Ciao
Enrico |
|
|
|
mxa
Advanced Member
Germany
533 Posts |
Postato - 25/04/2006 : 15:42:28
|
Enrico,
tu mi dovresti aiutare a risolvere questo problema, visto che sembra che io ce l'ho (sempre!) ma tu no. Una volta che ho raddrizzato l'immagine nel PTGui editor con pitch e roll e centrata orizzontalmente con yaw, ottengo quello che vedi in
www.resonantlink.com/PTGuieditorwhat.jpg
Come faccio a generare un panorama che contiene SOLO la foto e non la foto piu' tutto il nero sotto???? Mentre ho modo di centrare la foto orizzontalmente e ridurre le bande nere ai lati con il yaw, non ho finora trovato il modo per eliminare la banda nera sotto CHE MI RADDOPPIA LA MEMORIA VIRTUALE NECESSARIA e che poi mi genera una immagine grande il doppio che mi tocca aprire in Photoshop e croppare per togliere tutta la schifezza sotto.
Grazie
Ciao
Mxa/Marco
|
|
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 25/04/2006 : 15:50:09
|
Eheh,
purtroppo il problema non l'ho risolto, è ancora lì perchè PTGui non permette il crop finale prima del calcolo.
E' nella lista delle cose che devo chiedere a Joost, anche se credo che qualcuno glielo abbia già suggerito....
Come puoi vedere dal panorama editor
io il nero non cel'ho perchè lo stitch è centrato sia come yaw che come pitch, mentre nel tuo caso l'immagine sta tutta (o quasi) dall'orizzonte in su, dunque devi sorbirti la "metà gemella" di quadro nero.
Spero che pongano presto rimedio, gli olandesi!
Ciao
Enrico |
|
|
|
mxa
Advanced Member
Germany
533 Posts |
Postato - 25/04/2006 : 16:11:01
|
Perfetto, e' quello che immaginavo, visto che la prima striscia di fotogrammi che faccio in molti pano e' ad 'alzo zero'.
Ok, finche' e' una mancanza del programma e non un mio non capire come usarlo va bene cosi'. Certo che dovresti si segnalarlo agli amici di PTGui perche' --- senza assolutamente farlo di proposito --- degli otto panorami che ho fatto in questa settimana uno solo, quello che ti ho mandato, ha strisce di fotogrammi ad angolazioni negative, per intendersi. Andando a riguardarmi pano fatti nel passato la stragrande maggioranza vanno da 0 gradi in su.
Grazie ancora
Ciao
Mxa/Marco
|
|
|
|
AlbertoM
Moderatore
Italy
4742 Posts |
Postato - 25/04/2006 : 16:29:50
|
Ciao a tutti
Ho fatto quel test sul tool di PhotoShop "Merge to HDR" e PTGUI.
Dunque, non ho scelto l'immagine migliore per il test, ma era l'unico panorama che la mia finestra poteva offrire...
Allora:
- Occorre per forza usare il cavalletto perchè il tool di Photoshop non riallinea fotogrammi non perfettamente sovrapposti come fa PTGUI, per cui il modo migliore è scattare in breacketing
- Forse avevo esagerato: bastano anche meno di 4 stop, dipende dalla gamma dinamica della scena (nell'esempio seguente ho utilizzato 0 +/-2)
- Non è possibile dare in pasto 2 o più panorami già creati con PTGUI al tool di Photoshop, perchè vuole i dati sull'esposizione, che trova nei raw o nei jpeg generati dalla macchina
- Merge to HDR ha un' interfaccia (per fortuna) a basso livello, per cui permette di "fissare" un'esposizione per tutti i fotogrammi da generare per lo stitch
- Occorre preventivamente fissare anche i parametri di camera raw per l'apertura di tutti i fotogrammi: basta aprirne uno esposto correttamente, e successivamente assegnare queste impostazioni memorizzate nel file .xmp a tutti gli altri fotogrammi con Adobe Bridge
Come avevo già riscontrato altre volte, il risultato è un'immagine a basso contrasto rispetto al panorama creato con i "soli" (tre) fotogrammi esposti correttamente:
I dettagli però saltano fuori:
Come dicevo prima, questo cielo pallido non è il massimo per mettere in evidenza il guadagno ottenuto con questa tecnica, però già si vede qualcosa.
Il problema ora è ristabilire un buon contrasto senza perdere i dettagli recuperati con Merge to HDR.
Forse è meglio utilizzare il metodo suggerito da Enrico.
Comunque fino a qui funziona...
AlbertoM |
|
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 25/04/2006 : 20:47:22
|
Uhm,
questo HDR proprio non mi soddisfa, uccide il contrasto anche dove è ottimale.
D'altra parte è anche vero che gestire le transizioni con le maschere di livello in PS non è cosa sempre così semplice. Però alla fine i risultati li trovo sempre migliori di HDR.
Ciao
Enrico |
|
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 25/04/2006 : 20:56:59
|
Risultati definitivi (riconteggi compresi!!! )
Dimensioni del file PSB: 1,5 Gb
Dimensioni in pixel: circa 500 Megapixel
Tempo di calcolo (8 bit/canale): 5h 12min
(ho usato un HD esterno per i tmp, con un HD interno forse si risparmia una mezzoretta! )
Tempo di apertura del file in PS: circa 9min
Operazione compiuta, dunque. Nessun problema riscontrato, il blender ha fatto benissimo il suo lavoro e il file ha un livello di dettaglio semplicemente inaudito!
Pensare che il calcolo è stato fatto a 8bit e non 16bit, pensare inoltre che con il mio PC ci vogliono ben 9 minuti solo per APRIRE il file, figuriamoci fare qualche elaborazione!!
Ho preso nota di un paio di migliorie apportabili a PtGui nella gestione di stitch enormi come questo, mi farò carico di farle presenti a Joost.
Nel frattempo ringrazio Marco per avermi fornito il materiale necessario per realizzare questi test.
Ciao
Enrico |
|
|
|
AlbertoM
Moderatore
Italy
4742 Posts |
Postato - 25/04/2006 : 22:06:55
|
Sì, credo anch'io che Merge to HDR sia un po' difficile da gestire.
Comunque, quello che è certo, è che nei panorami realizzati su cavalletto conviene sempre scattare in breacketing (per quello che costa in digitale), e poi decidere a posteriori se utilizzare una tecnica o l'altra (o nessuna) per aumentare la gamma dinamica.
Se le zone sovra/sotto esposte sono ben separate, allora è sicuramente migliore la tecnica di Enrico, se invece ci sono sovrapposizioni frastagliate fra le varie zone, allora forse è più conveniente lasciare lavorare Photoshop ed il suo tool.
Ciao
AlbertoM |
|
|
|
Rapick
Junior Member
Italy
24 Posts |
Postato - 04/05/2006 : 18:00:15
|
Perbacco, questo sì è un bel 'thread' sullo 'stitching', e su PTGUI in particolare.
Come appassionato, o 'panomaniaco', mi spiace di non essere intervenuto prima: purtroppo sono stato inchiodato a un letto d'ospedale tutto il mese di Aprile... be' adesso va meglio!
Allora, ecco qualche considerazione in risposta al punto 10 di Marco: 'spettri', 'gemelli' e simili.
1) Chi se ne prende cura è il'blender', un .exe chiamato dall stitcher al termine del lavoro di 'deformazione' (warping) necessario per far 'combaciare' le varie immagini. Il blender fa anche altre cose: equalizza le tonalità e i colori tra le immagini e crea tra esse una transizione 'soft'.
2) Non tutti i blenders sono uguali: ecco una dimostrazione:SMARTBLEND (PTGUI)[a sinistra] a confronto con Autopano Pro (uno stitcher piuttosto costoso e che riscuote parecchio apprezzamento!)[a destra].
C'è anche da dire che le prestazioni dello stesso blender possono differire molto in funzione delle caratteristiche del panorama da assemblare.
3) PTGUI offre in opzione 3 blenders diversi: a) il proprio blender 'standard' (entrocontenuto) - b) ENBLEND - c) SMARTBLEND.
b) e c) sono programmi 'freeware' che si scaricano da Internet e si installano come 'plugin' in PTGUI.
4) Dalla mia esperienza, SMARTBLEND è il 'meglio' in assoluto per la capacità di sopprimere spettri e 'doppi' - ENBLEND è secondo (però forse ha una resa generalmente migliore nel 'blending' vero e proprio) - IL blender PTGUI 'nativo' ha il vantaggio di essere veloce (ma non molto accurato).
5) Tuttavia neppure il blender più 'affidabile' è a prova di errore; qualche volta l'effetto può essere divertente: ecco 2 gemelle a spasso per Piazza Duomo a Trento ...
6) Però ci sono casi in cui salvare il 'panorama' come 'blended + layers', e poi rotoccare la 'maschera' (più facile a farsi che a dirsi!) è l'unica via percorribile.
7) Esempio: l'orrendo riflesso interno scompare semplicemente andando a selezionare la 'maschera di livello' del fotogramma 'fallito' e ripassando l'area con pennello (brush) di colore BIANCo (come ben spiegato nel 'tutorial' di PTGUI).
8) Questo è il link al panorama completo (9 fotogrammi, ciascuno 8 MP, dimensioni 'utili' dell'originale c.a 14000x2100 pixel):
http://www.pbase.com/rapick/image/40856037
Ciao a tutti.
Rapick |
|
|
|
Enrico
Moderatore
Italy
2010 Posts |
Postato - 05/05/2006 : 22:32:15
|
In effetti non sono ancora entrato nel merito della qualità dei vari blender, per non rendere ancor più tracimanti gli articoli di quanto già lo sono!
Io alle volte uso Enblend (ultima release) al posto del blender integrato in PTGui, ma solo se vedo comportamenti anomali (raramente, tuttavia).
D'altro canto, siccome sono un vero "zozzone della fotografia" , uso raramente il cavalletto anche nei miei stitch (80% panorami), pertanto la cosa migliore da fare è ottimizzare il risultato per lo sfondo e "ricucire" manualmente gli inevitabili strappi sul primo piano, usando l'uscita multi-layer.
Finora nessuno si è mai accorto dei miei rammendi!
Ciao
Enrico |
|
|
|
mxa
Advanced Member
Germany
533 Posts |
Postato - 27/07/2006 : 23:17:31
|
Continuo le mie note di uso di PTGui.
Ho dovuto nelle ultime settimane rinunciare qualche volta a portarmi in giro l'equipaggiamento standard, cioe' cavalletto e testa pano (leggi: scalate abbastanza impegnative in montagna). Dato che alcuni del forum lavorano a mano libera con PTGui ho provato anch'io.
I risultati non sono stati esaltanti. Premetto che non ho mai fatto stitching di due o tre fotogrammi, ma quasi sempre almeno di una decina. Come sapete per me questo e' pero' effettivamente essere parco e morigerato
Ho cercato di ruotare il corpo attorno, etc etc.
In sostanza la mia esperienza e' stata la seguente:
1. Nella Control Table ottengo errori anche significativi, tipo 40 o 50. PTGui non e' molto soddisfatto ma non scalcia ("not bad", dice lui). Quando vado a cercare di correggere questi errori mi accorgo che in realta' i punti "sotto accusa" nelle due foto sono perfettamente nello stesso punto o quasi, quindi questi 50 pixel di differenza non so da cosa vengano, ed e' quindi difficile per me porvi rimedio perche' materialmente non so cosa fare. Tenete conto che i valori peggiori che ottengo nei miei panorami giganti con il cavalletto e la testa pano e tutto in bolla blah blah blah sono attorno a 4 o 5, quindi un ordine di grandezza in meno.
2. Quello che e' peggio e' che strani artefatti vengono inseriti nella foto, cosa che non succede MAI nei miei panoramoni con il cavalletto. Potrebbe essere infatti lo stesso problema, ovviamente. In particolare PTGui mi fa due scherzi: il primo, che e' comune a Panavue, e' un blurring pesante --- quasi un tremolio --- che viene imposto in aree della foto dove evidentemente non e' riuscito a far combaciare le immagini come voleva. Dato che la stessa identica cosa con lo stesso identico effetto visivo succedeva con Panavue, ipotizzo che ci sia da qualche parte un algoritmo comune di stitching che esauriti un numero di iterazioni e non raggiunta una cifra di merito accettabile introduce un bel blur e ... pace vobis. Il secondo problema e' l'aggiunta di artefatti dovuti alla povera sovrapposizione. Questo lo vedete nelle rocce in www.resonantlink.com/photoact/PTGuiproblem.jpg Sulla sinistra e' un particolare della foto creata da PTGui, sulla destra il fotogramma di partenza. Le frecce rosse aiutano a capire cio' di cui sto parlando. L'esempio in questione viene da un composito di 16 fotogrammi in due strisce (8 in alto e 8 in basso). Lo stitching comunque --- cosi' come e', se non si riesce a sistemare il problema --- e' da buttare perche' una attenta ispezione della stampa rivelerebbe il problema (la zona in questione e' molto piccola, quindi la stampa vista da una distanza normale e senza molta attenzione potrebbe sembrare OK).
Morale della favola: in mancanza di contromisure veloci, che non mi costringono a passare ore davanti al PC a far combaciare i control points, preferisco portarmi dietro il cavalletto e la testa sempre o rinunciare.
Immagino che fare lo stitching di tre o quattro fotogrammi presi a mano libera non sia un problema, invece. Questo rende PTGui comunque molto utile perche' a tutti gli effetti per soggetti immobili triplica o quadruplica la risoluzione della digitale.
|
|
|
|
Topic |
|
|
|
Esperienza con PTGui
