JuzaPhoto utilizza cookies tecnici e cookies di terze parti per ottimizzare la navigazione e per rendere possibile il funzionamento della maggior parte delle pagine; ad esempio, è necessario l'utilizzo dei cookie per registarsi e fare il login (maggiori informazioni).
Proseguendo nella navigazione confermi di aver letto e accettato i Termini di utilizzo e Privacy e preso visione delle opzioni per la gestione dei cookie.
Puoi gestire in qualsiasi momento le tue preferenze cookie dalla pagina Preferenze Cookie, raggiugibile da qualsiasi pagina del sito tramite il link a fondo pagina, o direttamente tramite da qui:
Ok, basta euforia paradossa.... parliamo del nuovo parapapparappà... Workflow, a New Way:
Sarà un articolo lunghetto e tedioso, ma spero che qualcuno regga fino alla fine... stavolta la prendiamo larga...
Iniziamo dal RAW; ogni buon workflow fotografico inizia da qui. Quando portiamo a casa i RAW abbiamo a che fare con dati device dipendent, cioè riferiti a quella periferica. Per essere usati ai fini fotografici dobbiamo passare le canoniche fasi che ho già descritto nell'articolo sulla gestione colore.
Per fare questo il nostro RAW converter deve poter interpretare i dati del RAW e soprattutto possedere uno o più profili di caratterizzazione colorimetrici, con i quali potrà dare significato alle coordinate grezze. CameraRAW e Lightroom usano due profili interni, in standard proprietario, e riferiti a due illuminanti standard 2856 K e 6504 K. I profili usati per altre temperature del bianco sono ottenuti per interpolazione. CaptureOne invece usa profili di caratterizzazione in standard ICC, ne può avere uno solo o più di uno.
Nel nostro nuovo workflow prenderemo in esame quest'ultimo. Vediamo adesso il perché e il percome.
CaptureOne è smart:
CaptureOne caratterizza i dati RAW tramite un profilo ICC standard; se per una fotocamera ne sono presenti più di uno possiamo scegliere, anche in questo caso il programma ricava per interpolazione gli illuminanti mancanti. Per semplicità mi riferirò alla D810 che posseggo; CaptureOne per questa fotocamera propone un singolo profilo ICC.
Il nome del profilo è: NikonD810-Generic.icm (appunto generico)
Vediamone la struttura:
E' un profilo a tabella di classe input v. 2.1 con PCS a LABD50 (è sempre un D50 nello standard ICC)
Come si nota è presente solo la tabella di conversione verso il PCS A2B0, quindi, come tutti i profili input, è unidirezionale. Il tag wtpt indica il media white point che è sempre un D50, quindi il profilo è valido per questo illuminante; per gli altri si procede con interpolazione.
Una volta fatta la caratterizzazione CaptureOne 8 non passa a uno spazio ROMM; vale a dire lo spazio di lavoro dell'immagine diviene il profilo di caratterizzazione stesso. Questa cosa ha interessanti implicazioni; la più importante di esse è che in questo modo evitiamo possibili clipping.
Questo è un raffronto tra ProPhoto e il gamut ricavato direttamente dal profilo di caratterizzazione della D810:
Come si nota persino il ProPhoto presenta un seppur minimo clipping; questo grafico è realistico però solo nel caso che il bianco della foto sia lo stesso del profilo. Nel caso il programma debba interpolare questo clipping potrebbe aumentare o annullarsi.
Quindi CaptureOne è furbo, evita il problema lavorando sul profilo stesso della fotocamera. Al momento di esportare la versione possiamo decidere di convertire verso uno spazio diverso o mantenere il profilo originale.
Verso nuovi lidi:
Al momento dell'esportazione possiamo scegliere i classici AbodeRGB, sRGB, ProPhoto ... Ma.... ogni spazio colore ha i suoi pro e contro; scartiamo a priori sRGB che è totalmente inadatto e iniziamo a introdurre alcuni concetti chiave.
Un buon spazio teorico deve avere certe caratteristiche; una delle più importanti, se non la più importante, è la capacità di contenere le coordinate colorimetriche che ci interessano. In parole povere deve essere abbastanza grande da non clippare i dati che gli passiamo dal RAW converter.
Fin qui tutto bene; quindi la scelta più logica sarebbe senza dubbio il ProPhoto. Ma cosa significa veramente il volume del gamut? La risposta spiccia è che più è grande il volume e più colori contiene. Ma non è una risposta esaustiva. Se ci chiedessimo che differenza c'è tra sRGB e ProPhoto in termini di quantizzazione RGB la risposta sarebbe... nessuna.
Infatti il numero possibile delle permutazioni RGB non dipende dallo spazio di riferimento, ma solo dalla profondità in bit. sRGB, come ProPhoto, può essere scandito da 2^24 (i famosi 16 milioni di colori) permutazioni nel caso di un file a 8bit; la differenza sta nella appartenenza di queste coordinate del modo colore RGB al riferimento colorimetrico.
Nel caso dei profili che descrivono spazi teorici il PCS è XYZ; un profilo con gamut più elevato quindi copre distanze colorimetriche maggiori. Siccome però la quantizzazione del modo RGB è sempre la stessa è evidente che un gamut più esteso è codificato con una precisione inferiore, mentre un gamut più piccolo può essere diviso in step digitali più piccoli.
Quindi abbiamo due esigenze che puntano in direzioni opposte:
L'esigenza di non clippare le coordinate che ci interessano portano a gamut ampi.
L'esigenza di una quantizzazione discreta e con il minimo errore ci porta a gamut piccoli.
Quindi che fare? sRGB è scartato a priori, AdobeRGB è sempre piccolo.... e ProPhoto? ProPhoto è enorme, una garanzia per il clipping, ma ha i suoi svantaggi, vediamoli:
I tristimoli di ProPhoto sono :
Color CIEx CIEy red 0.7347 0.2653 green 0.1596 0.8404 blue 0.0366 0.0001 white 0.3457 0.3585
Con bianco D50 e gamma 1,8
Il plot in Yxy ci fa vedere come il tristimolo blu sia addirittura fuori del locus umano; questo è dovuto al fatto che ProPhoto è un matrix RGB e la sua forma, anche se appare un poco irregolare, è sostanzialmente un triangolo; triangolo che per includere quanta area più possibile deve per forza estendere i suoi vertici.
ProPhoto realizza il fatto di, virtualmente, non incappare mai nel clipping; ma lo fa a caro prezzo. Specialmente per la scelta del gamma 1,8. Infatti il gamma, seppur non modificando la morfologia del gamut, ne descrive la distribuzione dei dati al suo interno. Sfortunatamente la gamma 1,8 non è l'ideale.
La gamma perfetta, come prodotto esponente, non esiste. Calcolandola si ottiene che il valore ideale per minimizzare l'errore di picco è 2,17 mentre se vogliamo contenere l'RMS allora si sale a 2,32.
Quindi ProPhoto pecca sulla gamma e su confini fin troppo estesi; AdobeRGB ha la gamma giusta, ma è troppo stretto. Che fare?
Il genio talpoide all'opera:
Pensa che ti ripensa alla fine ho inventato un nuovo spazio RGB teorico...
Mhhuahahaha
Definiamo la nuova creatura:
Profilo del modo RGB classe monitor matrix v.2.3 con PCS a XYZ
Bianco D50
Tristimoli:
Color CIEx CIEy red 0.68799 0.311195 green 0.095261 0.860239 blue 0.126512 0.035005 white 0.3457 0.3585
Gamma L*
Volume gamut DeltaE 2.177.260
Vediamolo:
la creatura in scala di colori e in giallo ProPhoto, come si nota il nuovo gamut è più piccolo di ProPhoto, non ha sconfinamenti oltre il locus umano.
La cosa buona del nuovo RaamielRGB è che soddisfa le esigenze di ampiezza, riuscendo a non clippare praticamente in nessuna situazione, e al tempo stesso aumenta la precisione della sua quantizzazione. La gamma L* inoltre distribuisce al meglio i dati al suo interno; nel caso il monitor sia calibrato anch'esso su L* questo garantisce anche una compensazione a monitor più semplice e lineare.
Vista in wireframe:
A chi volesse usare il nuovo spazio RGB posso fornire le coordinate del mio conto cifrato alle Cayman
“ Posso farti una domanda da approccio inverso? Perchè nessuno si è mai fatto uno spazio colore? Questione di standard? Fatica? O mi sfugge qualcosa? „
Non lo so francamente, credo che a parte l'oggettiva difficoltà, la cosa che più scoraggia è il fatto che il nuovo spazio colore non sarebbe uno standard riconosciuto. Anche se una volta abbinato a una immagine esso sarà interpretato correttamente da qualsiasi applicazione che supporta lo standard ICC.
Se qualcuno vuole provare il RaamielRGB mi può contattare in PM, mi accontento di semi e lupini
Scherzi a parte, visto che non mi è mai stato del tutto chiaro e che forse interessa anche agli altri, puoi fare una dimostrazione grafica delle pecche del gamma, ovvero del perchè è meglio attorno a 2.2 che a 1.8?
Allora... in un sistema di archiviazione dati la gamma non ha senso. Se il file immagine fosse una sequenza di dati e non qualcosa da mostrare ai nostri sensi visivi la gamma non esisterebbe proprio.
La relazione tra luminanza e chiarezza è la curva L*
Un monitor ideale ha la TRC identica a L*; in questo modo noi vediamo un gradiente grigio in modo uniforme.
Se il file immagine ha un profilo a gamma diversa da quella del monitor allora si deve fornire una compensazione. Qui vedi la curva di correzione necessaria per sRGB, AdobeRGB, ProPhoto e RaamielRGB necessaria per uniformarsi a L*:
Il RaamielRGB non necessita di alcuna correzione della TRC nel caso il monitor sia calibrato sempre a L*.
Ottimo come sempre Raamiel, e bene che il "tuo spazio" non necessiti di compensazione. Ma in realtà fino a qui in qualche modo c'ero.
Quel che cercavo, che di solito non trovi in giro e per cui chiedevo a te, è la rappresentazione dell'effetto "peggiorativo" di una curva da 1.8 rispetto a quella a 2.2
Perchè, essendo compensazione, agli occhi dovrebbe essere impercettibile.
Io ad esempio sono ipermetrope, e per vedere normalmente compenso. Il che mi fa vedere bene, ma alla lunga stanca. La rappresentazione di questo effetto peggiorativo sarebbe una curva "stanchezza" che si impenna più di quella di una persona dalla vista normale. Come si rappresenta invece il "difetto" del gamma a 1.8?
Non so se sono riuscito a spiegare il mio dubbio, mettici un pò di fantasia...
Per vedere in modo corretto tramite i nostri sensi abbiamo bisogno che la TRC del monitor sia L*, oppure qualcosa di vicino. Gli esponenti gamma che più si avvicinano a quella curva sono 2,17 per il picco e 2,32 per l'RMS. In ogni caso L* non è esprimibile con una gamma esponenziale.
Ora veniamo ai dati nel file. Prova a creare un immagine nuova in Photoshop con uno spazio colore che abbia la TRC in L*, ci metti sopra un gradiente grigio e poi provi a visualizzarla con e senza gestione colore attiva. Noterai che non cambia nulla, se il tuo monitor è calibrato per L*.
Questo succede perché i dati grezzi sono già ordinati nella TRC "giusta", cioè quella che più si confà alla percezione umana. La gestione colore in quel caso non deve adeguare la TRC dei dati e la compensazione a monitor è molto più lineare piuttosto che partire da una gamma 1,8.
Tutto più chiaro. (e non parlo di chiarezza a caso ahahahaha)
Che cosa ne pensi di questo argomento?
Vuoi dire la tua? Per partecipare alla discussione iscriviti a JuzaPhoto, è semplice e gratuito!
Non solo: iscrivendoti potrai creare una tua pagina personale, pubblicare foto, ricevere commenti e sfruttare tutte le funzionalità di JuzaPhoto. Con oltre 243000 iscritti, c'è spazio per tutti, dal principiante al professionista.
JuzaPhoto contiene link affiliati Amazon ed Ebay e riceve una commissione in caso di acquisto attraverso link affiliati.
