| I N I Z I O T O P I C |
| poalpina |
Posted - 23/02/2009 : 17:33:52
Ciao a tutti
Stò provando l'ultima versione di PTgui. Come annunciato la 8.1 supporta i file raw. E' infatti possibile aggiungere nel progetto direttamente i file in formato RAW (Nef nel mio caso).
Ora la questione è questa: prima dello stitching avrei la neccessità di cambiare alcuni parametri (si tratta in sostanza di variazioni relative a esposizione e alte luci) apro i file in CaptureNX2 faccio le variazioni salvo, ma poi PTgui NON ne tiene conto affatto, (ho verificato anche facendo modifiche esagerate). Se è così i vantaggi non
sono molti, probabilmente sbaglio qualcosa ... cosa?
M.Teo |
| 12 U L T I M E R I S P O S T E (Le più recenti in alto) |
| nonchiedercilaparola |
Posted - 28/03/2012 : 17:59:17
prova ptgui portable. e vedi se ti da lo stesso errore, prova a cancellare i file tmp ed a testare il sw su altra postazione. aiò |
| digeiset |
Posted - 27/03/2012 : 21:44:58
scusate l'OT. Ho dovuto togliere un banco di ram al pc perché rotto. E' possibile che PT gui non funzioni bene allo stesso modo? Ho notato troppi errori di giunzione e tempi allungati di molto, mentre se unisco solo due imamgini non sbaglia un colpo. é scontato che ho appena ricontrollato il punto nodale, ma è difficilissimo che si sposti. |
| Maestrale |
Posted - 27/03/2012 : 18:12:36
Citazione:
Postato da nonchiedercilaparola
Questa possibilità di ptgui la conoscevo. Inizialmente anch'io ho provato a fare tutto in raw.
ecco la discussione sul forum di panoguide:
http://www.panoguide.com/forums/qna/8906/
Già, pur con tutte le sue limitazioni il flusso di lavoro raw to hdri può essere utile per prepararsi velocemente delle mappe d'illuminazione per i rendering 3D, altrimenti non vedo l'utilità di caricare direttamente i raw in PTGui...
Claudio 
|
| nonchiedercilaparola |
Posted - 27/03/2012 : 17:35:06
Questa possibilità di ptgui la conoscevo. Inizialmente anch'io ho provato a fare tutto in raw. Ma ptgui non è molto efficiente nel trovare i cp con gli scatti raw. Utilizzando i rispettivi tif (ottenuti anche impostando i valori per la nitidezza e il rumore) ptgui si comporta decisamente meglio. Trova più control point e i valori trovati hanno una media (calcolata con l'optimizer) decisamente più bassa.
ecco la discussione sul forum di panoguide:
http://www.panoguide.com/forums/qna/8906/ |
| Maestrale |
Posted - 26/03/2012 : 19:48:27
Citazione:
Postato da nonchiedercilaparola
Dalle varie letture che ho fatto si consiglia che in fase raw non si tocchi la nitidezza (operazione da fare successivamente). Mi sono accorto però che nello stitching delle immagini se si passa a PTGui i file tif derivanti dalla conversione raw con la quale si è corretto oltre al bilanciamento bianco, aberrazioni cromatiche anche la nitidezza e il rumore, il risultato è decisamente migliore: da una media di 5-9 si passa ad un media dell'1.5 o anche meno.
Dunque, forse intendi dire che la nitidezza va gestita prima di dare in pasto i tif a PTGui e questo è corretto, si tratta soltanto di scegliere a chi affidare il compito... qui trovi qualche spunto d'indagine, ma passo la parola a chi nel forum è più ferrato di me in materia, soprattutto per quel che riguarda i plugin specifici per lo sharpening...
...
Visto però che dopo tre lunghi anni  , anche se poco attinente alla tua domanda, hai ripescato un topic comunque interessante, mi permetto di ritornarci su:
Citazione:
Postato da andre_
Probabilmente il "meglio" sarebbe un'uscita a 32bit per canale partendo dai RAW
Ehm, PTGui Pro lo fa! vedi le mie sperimentazioni, poi abbandonate ma solo dopo aver risolto l'arcano (negli ultimi post), per uscire in HDRI a 32bit (HDR Radiance) e ritoccare addirittura il nadir, ovviamente a partire dai raw...
Claudio
|
| nonchiedercilaparola |
Posted - 26/03/2012 : 18:23:54
Dalle varie letture che ho fatto si consiglia che in fase raw non si tocchi la nitidezza (operazione da fare successivamente). Mi sono accorto però che nello stitching delle immagini se si passa a PTGui i file tif derivanti dalla conversione raw con la quale si è corretto oltre al bilanciamento bianco, aberrazioni cromatiche anche la nitidezza e il rumore, il risultato è decisamente migliore: da una media di 5-9 si passa ad un media dell'1.5 o anche meno.
vi risulta?
|
| poalpina |
Posted - 24/02/2009 : 16:00:00
Grazie, ho capito come stanno le cose.
La novità è effettivemnte un grosso vantaggio in termini di gestione dei dati, qualità, memoria, tempo, ma effettivamente non è possibile fare dei cambiamenti ai file raw (ovviamente anche con Camera Raw) prima di darli a PTgui ed ora mi è chiara la ragione, questo è oggettivamente un limite alla lavorazione post-scatto e pre-stitching.
Il sugo è ancora lo stesso: bisogna scattare bene e "solo" chi può passare il raw direttamente a PTgui potrà godere dei vantaggi della nuova versione. Bene si ricomincia sempre da lì.
M.Teo |
| andre_ |
Posted - 24/02/2009 : 12:23:55
Citazione:
Postato da toneshForse non hai letto bene: l' output non sarà mai un file raw. PTgui durante la cucitura dei delle varie immagini, provvede a fare la conversione, ed in maniera peggiore di un qualsiasi raw-converter. Quindi i dati colorimetrici e bla bla, inclusi o con sidecar non vengono considerati.
L' unica possibilità di modifica applicata ai file raw di input è il tone-mapping sull' immagine cucita.
Insomma, il principio è che i files raw possono essere solo letti ma non modificati...
No, no. Avevo letto bene.
E d'altronde sarebbe ben difficile avere un'uscita RAW da un software di questo tipo.
Quello che dico è che mi pare un'idea migliore l'unire dei dati RAW, con tutta la loro "leggerezza" e qualità, piuttosto che fare una prima conversione (inevitabilmente non perfetta, nel senso che il blender andrà comunque a ritoccare i toni), darla in pasto a PTGui e magari farne una seconda sul fine finale per adattarla alla stampa.
Qui si tratta di scegliere tra il rinunciare a parte della qualità dei colori (immetto nel software immagini convertite ad 8bit), mantenere una cosa vicina al menglio possibile con un peso incredibile (un'ottantina di MB per ogni foto convertita a 16bit che importo in PTGui - con tutto il lavoro di CPU che ne consegue - per avere un'uscita sempre a 16bit magari da ritoccare ancora una volta) oppure mettere i dati RAW (una dozzina di Mb per foto, con il massimo dell'informazione contenuta) e sistemare colori e livelli solamente sull'immagine in uscita, ovviamente a 16bit (che quindi mantiene il massimo delle info comunque).
Ovviamente non è la panacea, ovviamente se non ho scattato alla mimima sensibilità possibile è necessario un RAW converter che mi gestisca al meglio il rumore, ovviamente posso tranquillamente fregarmene se ho un MacPro con la CPU ad una sessantina di Core....
Ma continua a sembrarmi una buona notizia.
Probabilmente il "meglio" sarebbe un'uscita a 32bit per canale partendo dai RAW, oppure un'integrazione completa con un software specializzato nel RAW converter, insieme a CPU più performanti eccetera.
Non lo nego, e di certo ho dormito benissimo in queste notti non avendo scariche di adrenalina per l'eccitazione dell'evento....
Magari questa novità potrà allettare chi in questo momento preferisce lavorare ad 8bit per canale per velocizzare il tutto (e qualcuno di sicuro c'è).
a_
www.andre-photo.org |
| tonesh |
Posted - 24/02/2009 : 11:32:06
Citazione:
Postato da andre_
Beh, il mantenimento della definizione originale, insieme al trattamento dei dati colorimetrici da RAW (quindi senza conversione e compressione di gamma) non mi sembra affatto cosa da poco!
Forse non hai letto bene: l' output non sarà mai un file raw. PTgui durante la cucitura dei delle varie immagini, provvede a fare la conversione, ed in maniera peggiore di un qualsiasi raw-converter. Quindi i dati colorimetrici e bla bla, inclusi o con sidecar non vengono considerati.
L' unica possibilità di modifica applicata ai file raw di input è il tone-mapping sull' immagine cucita.
Insomma, il principio è che i files raw possono essere solo letti ma non modificati...
toni
studioargento.com
|
| andre_ |
Posted - 23/02/2009 : 21:27:30
Beh, il mantenimento della definizione originale, insieme al trattamento dei dati colorimetrici da RAW (quindi senza conversione e compressione di gamma) non mi sembra affatto cosa da poco!
Chiaramente, pensando ad output "fotografici" (stampe da stitch a grande formato) e non per uso web (quasi sempre compressissimo e senza nemmeno gli 8bit per canale di ordinanza).
Probabilmente per il primo utilizzo la feature è davvero interessante, soprattutto per quanto riguarda l'unica conversione che mantiene i dettagli di colore.
Per una pano a 360°, probabilmente non c'è nmmeno il vantaggio della velocità (perchè non si lavora a risoluzione nativa, spesso).
a_
P.S. Ah, questi non_fotografi.... 
www.andre-photo.org |
| tonesh |
Posted - 23/02/2009 : 19:41:01
Dalla version history di PTgui:
"RAW support is provided through the dcraw executable. Please note that RAW conversion adjustments are limited; for full control over the RAW conversion result a third party raw converter is recommended."
E poi l' equirettangolare non sarà mai un file .nef, o raw.
Ci vorrà sempre un passaggio di "tone mapping".
Mi chiedo anch'io a cosa possa servire, se non a velocizzare le cose...
farò dei test.
a presto
Toni |
| danipen |
Posted - 23/02/2009 : 17:42:21
le modifiche che esegui con i raw converter sono registrate i un database del programa (come per aperture) oppure in un file sidecar (come per Camera Raw) per cui servirebbe che ptgui fosse in grado di accedere a queste impostazioni per tenerne conto...
magari fai una prova con camera raw e vedi che succede.
se non fosse in grado di tenere conto dellle modifiche effettivamente avrebbe poco senso usare direttamente il raw (salvo il risparmi di mb derivante dal non dover creare i tiff da unire)
ciao
daniele |
|
|
