 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | You are not logged in.
Un petit rappel pour les novices :
Les images sont décrites par une suite de valeurs RVB (Rouge Vert Bleu, RGB en Anglais).
Pour des raisons pratiques R V et B sont stockées sur 8bits chacune
(ou 16 bits - 2xPlus de place).
Prenons le cas simple 8bits : les valeurs vont de 0 à 255.
Une couleur de pixel sera donc décrite par R,V,B : 001,012,248.
Presque pas de rouge ni de vert, beaucoup de bleu.
On comprend assez facilement que 0,0,0 correpond au "noir" écran
et que 255,255,255 est le "blanc" le plus lumineux.
Plus sérieux :
A quoi correpond 128,128,128 , la valeur moyenne ?
1)Les écrans n'ont pas tous la même réponse en luminosité.
2)Le codage n'est pas forcément linéaire.
Pire :
Qu'est-ce que c'est, ce rouge 255,000,000 ?
1)Les écrans n'ont pas tous les mêmes phosphores CRT/filtres LCD
2)Comment afficher correctement le rouge d'un moniteur Trinitron
sur un LCD Dell ?
C'est là qu'intervient le profil ICC.
C'est une série d'informations (concerne moniteurs,images,scanners,imprimantes...).
Le profil ICC existe sous forme de fichier (extension .icc ou .icm).
Cette information se retrouve (ou est absente) dans une zone spécifique
des fichiers images tels que jpeg,tiff,psd,tga etc.
Le profil décrit
1) Le rapport entre la valeur R,V,B et la "luminosité vraie"
(on a vu que ce codage pouvait être non linéaire.
Le plus connu est le codage dit "gamma")
2) La description détaillée de ce que représentent R V et B
Pour simplifier grossièrement on va dire leur "fréquence".
Dans un environnement avec "gestion des couleurs" on a déterminé
avec une sonde le profil de l'écran. Le fichier ICC correpondant
a été déclare à l'OS (Windows, OSX etc). On connaît donc la réponse
en luminosité de l'écran et quel Rouge (V,B) il affiche quand on lui envoie
la couleur 255,000,000 .
Lorsque Photoshop ouvre une image , il lit le profil ICC de cette image.
Quand il veut afficher un pixel du fichier où il lit 011,123,222,
il sait quelle doit être sa luminosité et sa couleur "vraie".
Comme il connait les caractéristiques de l'écran (profil ICC de l'écran)
il va calculer ce qui correspond "au mieux" à l'intention du fichier de
départ. Il enverra au moniteur (par l'intermédiaire de la carte graphique)
une valeur modifiée , par exemple 008,111,207.
Retour à APP.
Trois problèmes :
1) APP ne fait pas suivre les profils quand ils existent ;
exemple : image1.jpg image2.jpg ayant le profil AdobeRGB
Pano.jpg n'aura pas de profil !
On peut s'en sortir en assignant dans Photoshop le profil AdobeRGB à Pano.jpg
soit en utilisant ExifToolGUI qui permet d'extraire un profil (par exemple de image1.jpg)
et de le ré-injecter dans un autre fichier (Pano.jpg).
2) Que fait APP lorsqu'il utilise des fichier RAW en entrée ? Là il n'y a pas
de profil, c'est le dématriceur qui décide. Que faire ?
3) On a vu que suivant le profil le codage couleur n'était pas linéaire
(gamma 2.2 pour sRGB et AdobeRGB ou 1.8 pour ProPhoto)
donc un mélange a 50/50 de 000,000,000 et 255,255,255
ne donne pas 128,128,128 et change suivant le profil !
Comme APP/blend mélange des couleurs, il DOIT connaître
les profils d'entrée pour faire du mélange en espace linéaire.
Pourrais-je avoir des éclaircissements de la part d'APP pour les deux derniers points ?
Merci d'avance.
Offline
SimDC wrote:
Pourrais-je avoir des éclaircissements de la part d'APP pour les deux derniers points ?
Merci d'avance.
J'aurais préféré discuter par mail mais tu n'es pas accessible. Pas grave, ça n'empechera pas Alexandre de te répondre.
SimDC wrote:
3) On a vu que suivant le profil le codage couleur n'était pas linéaire
(gamma 2.2 pour sRGB et AdobeRGB ou 1.8 pour ProPhoto)
donc un mélange a 50/50 de 000,000,000 et 255,255,255
ne donne pas 128,128,128 et change suivant le profil !
Comme APP/blend mélange des couleurs, il DOIT connaître
les profils d'entrée pour faire du mélange en espace linéaire.
Il me semble que ton exemple de mélange à 50/50 de 000,000,000 et 255,255,255 n'est pas un cas où l'utilisation d'un profil autre que sRGB soit réaliste parce que si APP est amené à faire un tel mélange il ne faut pas s'attendre à beaucoup de précision dans les couleurs du résultat.
D'aprés ce que j'ai compris de la gestion des couleurs, la gestion plus subtile et procurant un gamut plus large des profils ICC autres que sRGB n'a de sens que si toutes les photos source ont été exposées de manière identique et avec le même réglage de TC (si elles avaient été enregistrées en RAW elles doivent être développées avec les mêmes valeurs de paramètres.) Dans ce cas il n'est pas souhaitable de laisser APP faire des corrections de couleur et comme Alexandre l'avait indiqué dans une réponse, il suffit d'assigner au panorama le profil de couleur qu'on avait choisi pour les photos (par exemple assigner AdobeRGB au panorama si les photos avaient ce profil.)
Si au contraire les photos ont été exposées de manière différente les unes des autres parce qu'il y avait des écarts de luminosité importants entre les différentes parties du sujet alors il vaut mieux laisser APP compenser ces écarts grâce au mode de correction LDR (quitte à contrôler ce qu'il fait avec les ancres et à jeter un œil sur le résultat avec l'outil Niveaux) Dans ce cas il me semble plus raisonnable de rester en sRGB et de ne pas s'attendre à une précision de couleur qui ne peut correspondre qu'à des conditions d'éclairage bien plus favorables.
Offline
GURL,
quand on mélange des couleurs on doit le faire dans un espace
linéaire en luminosité. Il faut dé-gammatiser les deux valeurs,
les ajouter avec la pondération voulue, puis les re-gammatiser.
0+255 ne donne 128 (127.5 mais ne chipotons pas) qu'en linéaire
(gamma=1.) . En sRGB ou AdobeRGB ou Prophoto, ça ne donne
pas 128 ! De même 100 + 200 ne donnera pas 150 ((100+200)/2.).
APP profite du fait que le mélange de deux images au niveau du pixel
se fait avec des valeurs proches (la même couleur sur les deux images superposables),
111 + 113 donnera probablement 112,
c'est du bonus , mais il vaut mieux le savoir que de constater après coup
que le hasard fait bien les chose.
En ce qui concerne les RAW :
L'indication (sRGB ou AdobeRGB) que l'on détermine sur le boitier
ne sert que pour générer les jpeg crées par l'appareil.
Le dématriceur, lui, peut générer ce qu'on lui demande (Prophoto etc).
Si le dématriceur utilisé par APP utilise l'indication du boitier par
défaut, il suffit de nous le dire.
En fait, APP n'a pas à connaitre l'espace de couleur s'il ne fait que
du compositing. Il lui suffit de connaitre la "gamma" pour mélanger
en toute rigueur (et on a vu que ce n'était même pas nécessaire).
Par contre en HDR il FAUT passer en linéaire
pour mettre bout-à-bout les expositions, puis repasser en non linéaire (log ou autre).
Tout ça pour conclure que je ne comprends pas que APP ne transmette pas
le profil dans le cas ou il est commun à toutes les images...
Merci de ta réponse !
PS: transmission de mail : comment faire ?
Offline
SimDC wrote:
PS: transmission de mail : comment faire ?
Tu cliques sur ton nom (SimDC), ce qui te donne accès à ton profil, tu cliques sur Privacy puis tu choisis l'option Cacher l'adresse mais autoriser les e-mails. It's that easy!
A propos du HDR: utiliser un profil sophistiqué quand on fait du HDR me semble illusoire mais par contre il faut forcément tenir compte du gamma des images source. Le gamma du résultat lui, ben, heu, dans ce cas là...
A propos de la transmission du profil des images source vers le résultat: ça doit pas être très compliqué de recopier le champ EXIF de l'entrée vers la sortie mais faire les calculs correspondant à tout les niveaux où l'espace de couleur intervient risque d'être une autre paires de manches! Je sais qu'il y a des applications HDR qui recopient le profil de l'entrée vers la sortie mais je me demande si elles en tiennent réellement compte dans intervalle...
En gros mon idée serait la suivante: dans un intervalle de luminance étroit, choisir un profil qui permet un large gamut et le respect de nuances subtiles est utile. Quand au contraire l'intervalle des luminances dépasse ce qu'on sait enregistrer avec précision et ce qu'une imprimante peut espérer reproduire sur une feuille de papier (exemple: le cas des panoramas où la source d'éclairage fait partie du sujet) ça perd tout son sens.
Offline
OK , j'ai réglé le pb de mail !
Simple hypothèse :
Un panorama formé uniquement d'images rouge pur (?) ;
APP va faire son boulot, déformer, recadrer,
raccorder les luminosités etc, mais au bout du compte
on obtient une image rouge.
Or le rouge du sRGB est différent de celui de Adobe RGB
ou de celui d'un scanner (exemple : "Scanner N1240U.icc").
Il suffit de ré-assigner le profil de départ (pas de profil = pas de débat)
et la couleur devient OK (dans Photoshop).
La luminosité est secondaire et se règle facilement pour optimiser
le contraste .
Une simple option : "ICC profile pass-trough"
tout ce que je demande ...
Offline
Photoshop ,
menu
"edit" ->"color settings"
et bouton à droite
"more options"
Offline
Toujours rien en vue ?
Offline