| inviato il 27 Luglio 2015 ore 22:43
Sì ma se lo fai passare, tramite PS o tramite utility, appraverso ProPhoto ed il suo gamma tutto quello che ne viene fuori è normale. Non c'è nulla di strano in quello che descrivi, quindi non capisco!
“ Come si vede il valore di L* è 60,69 quindi il gradiente grigio ha già raggiunto e superato il punto mediano di L* 50 in cui i nostri sensi percepiscono una chiarezza media.
La percezione che abbiamo di questo gradiente è schiacciata sulle ombre e il punto di chiarezza media è spostato verso sinistra.
Il punto in cui L* arriva a 50 è circa a RGB 100.100.100 infatti :
„
e allora? Cosa c'è di anomalo?  |
| inviato il 27 Luglio 2015 ore 23:13
Non capisco bene quello che non capisci... che casino
Spe che ti rimetto insieme i passaggi.. :
Allora, creiamo un gradiente untagged, esso sarà costituito da una sequenza da 0.0.0 a 255.255.255. A metà ci sarà la coordinata 128.128.128; il gradiente è lineare quindi questa coordinata si trova a metà esatta.
Ora facciamo passare la coordinata 128.128.128 in forward su ProPhoto:
“ 128 128 128
128.000000 128.000000 128.000000 [RGB] -> MatrixFwd -> 0.278850 0.289203 0.238565 [XYZ] „
Quindi passiamo da RGB a PCS, la CHAD è nulla per il ProPhoto.
Ora facciamo passare le coordinate XYZ in backward sul profilo monitor, ipotizzando che questo è calibrato sempre in gamma 1,8.
“ 0.278850 0.289203 0.238565
0.278850 0.289203 0.238565 [XYZ] -> MatrixBwd -> 127.999973 128.000139 128.000057 [RGB] „
Otteniamo sempre 128.128.128 (al netto degli errori). Questa sarà la coordinata mandata a monitor.
Ma a quanto equivale questa coordinata in L* per questo monitor calibrato a 1,8?
Basta interrogare il profilo monitor in forward e farci dare il valore in LAB, la CHAD è sempre nulla perché nell'esempio il monitor è calibrato in D50.
“ 128 128 128
128.000000 128.000000 128.000000 [RGB] -> MatrixFwd -> 60.711192 0.000000 0.000000 [Lab] „
E scopriamo che a metà del gradiente non c'è la metà della luminanza percepita.
La conclusione è che un sistema composto da una gamma codificante e decodificante entrambe a 1,8 non restituisce i gradienti in modo coerente con la nostra percezione.
Questo era il punto. |
| inviato il 27 Luglio 2015 ore 23:28
E allora avevo capito bene, e non poteva essere altrimenti perché ti ei spiegato bene
La domanda che ti faccio è: perché mai a metà gradiente dovrebbe esserci la metà della chiarezza? |
| inviato il 27 Luglio 2015 ore 23:40
Perché se vuoi percepire un gradiente lineare esso deve avere a metà il valore di L=50.
Per questo usiamo calibrare i monitor a gamme che sono L* o sue approssimazioni.
Il ProPhoto in questa catena è un elemento strano, ormai piuttosto alieno.
Lo si usa senza apparenti problemi perché non è mai lo spazio di lavoro sorgente per una foto. Quando esportiamo da CameraRAW a Photoshop usando ProPhoto, eseguiamo una conversione e le coordinate RGB vengono alterate per adattarsi alla gamma 1,8.
Esportare direttamente in uno spazio colore con TRC a L*, usando un monitor calibrato a L*, è più lineare. |
| inviato il 27 Luglio 2015 ore 23:49
“ Perché se vuoi percepire un gradiente lineare esso deve avere a metà il valore di L=50. „ questo per definizione
Quel gradiente con valori RGB lineari non è percettivamente lineare in ProPhoto... ed è giusto che sia così!!!!!
Se vuoi ottenere valori RGB in ProPhoto di un gradiente che sia percettivamente lineare il metodo più semplice è quello di crearlo in Lab (che per definizione è percettivamente lineare...) e poi convertirlo in ProPhoto o in qualsiasi spazio colore. |
| inviato il 27 Luglio 2015 ore 23:54
“ Quel gradiente con valori RGB lineari non è percettivamente lineare in ProPhoto... ed è giusto che sia così!!!!! „
Lo so... ma non è che mi aspettassi diversamente
Il topic era creato per spiegare come si dipanava la questione della gamma nella catena colorimetrica. |
| inviato il 28 Luglio 2015 ore 0:03
Tento di seguire ..... 
|
| inviato il 28 Luglio 2015 ore 1:08
Penso che il problema stia qua: “ Con questo comando interroghiamo il profilo ProPhoto in forward, cioè RGB -> XYZ „
E' con questo passaggio che hai "creato" il neutro con chiarezza inaspettata, poiché lo hai ufficializzato, reso reale, con questo passaggio e poi lo hai soltanto convertito nello spazio colore del monitor.
Il punto è che la TRC del monitor entra in campo soltanto se si ha a che fare con applicazioni che non gestiscono il colore (a patto di aver profilato il monitor a gamma già scelto), ed in quel caso sì che avere L* come TRC potrebbe essere un vantaggio. Dico potrebbe perché lo sarebbe nel caso in cui chi ha scritto l'applicazione ipotizzava intuitivamente di voler avere una chiarezza del 50% per valori RGB di 127. Ma L* è difficilmente disponibile e quasi sempre sui portatili si ha a disposizione al massimo una correzione di gamma del tipo esponenziale.
Se volevi mettere in evidenza l'utilità di una TRC pari all'inversa di L*, in caso di applicazioni che NON gestiscono il colore, allora dovevi evitare quel passaggio attraverso ProPhoto->XYZ e sparare il valore 127 direttamente alla scheda video (per comprendere una eventuale correzione di gamma), e allora il solo fatto di avere L* come TRC del monitor bastava.
Avere un profilo di lavoro/archiviazione con gamma pari a quella di L* non porta a nessun beneficio se il colore viene gestito correttamente dall'applicazione.
|
| inviato il 28 Luglio 2015 ore 1:17
“ Il punto è che la TRC del monitor entra in campo soltanto se si ha a che fare con applicazioni che non gestiscono il colore „
Non capisco bene cosa intendi.
La TRC del monitor è la somma della TRC nativa del pannello + le correzioni LUT; ed è sempre attiva.
Le applicazioni che gestiscono il colore devono interpretare il profilo associato nell'immagine + il profilo del monitor. |
| inviato il 28 Luglio 2015 ore 1:30
Se l'applicazione non gestisce il colore (ovvero se questa invia direttamente dati RGB alla sceda video (anzi al s.o.) senza nessuna velleità colorimetrica, ovvero senza conversioni in spazi colore), in questo caso sì che il TRC influenza la visualizzazione, perché avremo risultati diversi a secondo del TRC utilizzato.
Ma se invece l'applicazione gestisce i colori, trasforma valori RGB in "colori reali" in uno spazio di riferimento e questi verranno riprodotti in maniera più o meno fedele dal monitor al di là della TRC impostata, perché si ipotizza che il profilo del monitor sia stato creato appositamente per riprodurre fedelmente i colori... Infatti con questa ipotesi l'applicazione manderà alla scheda video valori RGB tali da rirodurre quei colori già disponibili nello spazio XYZ passando attraverso il profilo del monitor.
Non c'è bisogno di fare delle prove!
Nell'esempio che hai fatto potevi fermarti già nello spazio XYZ, si vedeva già che il valore di luminanza era più altro del 18%, e quindi era già lì l'errore. Il monitor si limiterà a riprodurre quel colore che gli è stato chiesto di riprodurre.
|
| inviato il 28 Luglio 2015 ore 1:36
La TRC del monitor è sempre attiva.
Se alla scheda video arriva una certa coordinata RGB essa sarà alterata dalla TRC del monitor, a prescindere dal fatto che l'applicazione gestisca o meno il colore. |
| inviato il 28 Luglio 2015 ore 1:40
Sì ma il profilo del monitor tiene in considerazione il gamma del monitor (più o meno nativo, vedi monitor LCD) e della correzione di gamma della scheda video, la TRC appunto. No? :) |
| inviato il 28 Luglio 2015 ore 1:55
Sì... il profilo monitor contiene le informazioni sulla TRC complessiva del pannello (tag TRC) e, eventualmente, della correzione da caricare nelle LUT (tag vcgt).
Questa informazione serve al motore CMS per compensare il segnale prima di inviarlo alla scheda video.
Ma la TRC del monitor è sempre lì.... |
| inviato il 28 Luglio 2015 ore 2:02
è sempre lì, ma TRC diverse portano a risultati visivamente diversi se e solo se l'applicazione non gestisce il colore!
Quindi nel caso generico di ogni giorno una TRC vale l'altra*, a patto di avere creato un profilo monitor ad-hoc dopo averne scelta una (gamma e correzione gamma quindi), un profilo che compensi tale scelta, dunque.
Il caso che hai simulato tu è di una applicazione che invece GESTISCE il colore, infatti hai effettuato conversioni tra spazi e non hai inviato quella terna direttamente alla scheda video.
Ciò che hai fatto è di assegnare ad un gradiente numericamente lineare uno spazio colore che non è lineare e quindi a monitor verrà fuori un gradiente con chiarezza non lineare, indipendentemente dal monitor, dal profilo, dalla TRC ecc..... Quell'RGB 128 128 128 aveva chiarezza maggiore del 50% già quando hai deciso di interpretarlo come valore ProPhoto. I valori XYZ li hai scritti tu stesso. Sei d'accordo o no su questo, e quindi su tutto?
Vista l'ora sto cominciando a perdere formalità per sbrigarmi prima :) |
| inviato il 28 Luglio 2015 ore 5:31
Da fotografo:
Ma di che utilità pratica è stata aprire una discussione simile?
Chi si mette a rifare le curve di risposta di monitors costruiti appositamente per fotoritocco e grafica, monitors specialistici, che tanti ingegneri di sicuro NON completamente impreparati hanno con tanta cura messo a punto in decenni di lavoro e di progresso tecnologico?
A parer mio, si dovrebbe restare coi piedi per terra e rispettare il lavoro altrui.
Mettersi a tentare di riprogettare la ruota, l'acqua calda, le scarpe, la salsiccia, il cacciavite e tutto il resto, sperando di farlo meglio di altri che, oltretutto specialisti, hanno già fatto ed ottimizzato in decenni di lavoro dedicato, investendoci tempo e soldi in abbondanza, io non lo vedo per nulla "smart", ma proprio nulla.
|
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 251000 iscritti, c'è spazio per tutti, dal principiante al professionista. |
Metti la tua pubblicità su JuzaPhoto (info) |
JuzaPhoto contiene link affiliati Amazon ed Ebay e riceve una commissione in caso di acquisto attraverso link affiliati.
