Impression CMJN

[frmfrm]

Mince, j'ma gourré dans l'adresse , problème de site avec des frames ou apéro trop long :-(

Voila la bonne ... peut être :

http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html

Sinon pour compléter, suivant qu'on utilise l'adaptation chromatique ou pas, on a une intension de rendu absolue ou relative, pis si on a une compression de gamut, une intention de rendu perceptuelle.

[blibli]

Merci pour votre aide.
Je vais essayer de dépatouiller tout ça

[frmfrm]

Merci pour votre aide.
Je vais essayer de dépatouiller tout ça

Pas simple de t'aider, car il faudrait savoir de quel espace tu pars, vers quel espace tu effectues ta conversion, avec quel intention de rendu...

Un truc que tu peux essayer c'est d'effectuer un conversion inverse dans photoshop. Tu pars de ta version CMYK et tu retournes vers un espace RGB. Est que le résultat te montre une dominante.

La seule façon pour avoir une forte dominante avec cette méthode de vérification, c'est d'utiliser le moteur de Microsoft ICM et un mode de rendu Absolu. Là, je me retrouve effectivement avec une forte dominante sepia.

[egtegt²]

Pour faire vite et parce que les chiens attendent pour sortir :-)

Le nombre de bits n'a rien a voir avec ce qui est dans le gamut ou pas.

Pour les profils simples on passe de la valeur RGB 255/1023 a une valeur dans l'intervalle [0,1], puis on passe en linéaire, ensuite on utilise une matrice pour passer dans l'espace XYZ , on applique une matrice d'adaptation chromatique, puis on applique une matrice pour repasser de l'espace XYZ vers l'espace RGB de destination, on applique le gamma qui va bien et on multiplie par 255/1023 pour retomber sur ses pattes.

Quand tu reviens de l'espace XYZ, donc dans l'espace RGB de destination, les valeurs qui sont en dehors de l'intervalle [0,1] sont hors gamut et seront tronquées à 0 ou 1 sans algorithme de compression de gamut.

Tu peux trouver les matrice de différents espaces sur la page suivante, avec la façon de les calculer :

http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html

Merci pour le lien qui est intéressant mais je ne vois pas en quoi ça contredit ce que j'ai écrit, pour moi le RGB permet de décrire une image dans n'importe quel espace colorimétrique en l'utilisant intégralement, quel que soit la profondeur de codage. Là tu me donnes les matrices pour passer d'un système de coordonnées à un autre, soit, mais je ne vois rien qui limite le gamut suivant le système de coordonnées.

Au contraire ça confirme ce que j'ai écrit : en AdobeRGB le rouge primaire a pour coordonnées dans LAB 0,65; 0,33; 0,29 et en sRGB il a pour coordonnées  dans LAB : 0,65; 0,33; 0,22.

Je ne sais pas trop pourquoi il a choisi de donner les coordonnées en CIExyz au lieu de *LAB mais c'est encore un exemple : ces deux systèmes de coordonnées sont totalement équivalents, une simple transformation mathématique permet de passer de l'un à l'autre.

Que ça soit en sRGB ou en AdobeRGB, il s'agit du rouge 255 (si on est en 8 bits) mais ce 255 ne correspond pas au même rouge, il est un peu plus vif en AdobeRGB.

[frmfrm]

Merci pour le lien qui est intéressant mais je ne vois pas en quoi ça contredit ce que j'ai écrit, pour moi le RGB permet de décrire une image dans n'importe quel espace colorimétrique en l'utilisant intégralement, quel que soit la profondeur de codage. Là tu me donnes les matrices pour passer d'un système de coordonnées à un autre, soit, mais je ne vois rien qui limite le gamut suivant le système de coordonnées.

Aller une dernière tentative d'explication.  Après j'arrête, promis. Mais faut faire un peu de calcul pour comprendre.

Si tu prends le vecteur (0,1,0) et que tu le multiplies avec la matrice Profoto to XYZ. Ca te donnera les coordonnées de la primaire verte du profoto dans l'espace XYZ.

Maintenant multiplie le vecteur obtenu par la matrice XYZ to sRGB (  pour obtenir la valeur RGB de la primaire verte du profoto dans l'espace sRGB ... tu suis encore ?  ;-) ). Ben une des valeurs du vecteur RGB obtenu va être en dehors de l'intervalle [0,1], parce que le vert profoto est hors gamut du sRGB.

Maintenant, si tu préfères une simple règle de trois  :

Si tu es dans un système de coordonnées entre 0 et 1, c'est le même principe, ton rouge aura une valeur de 1 en sRGB et il passera en 0,9 en AdobeRGB par exemple.

Okay, si tu prends ton rouge de 1,0 en AdobeRGB, combien sera la valeur correspondante en sRGB et sera-elle dans l'intervalle [0,1] ?

...
Sinon, l'espace Lab est défini à partir de l'espace XYZ, ça ne sert pas à grand chose de passer par le LAB pour passer de profoto à sRGB.

[egtegt²]

Aller une dernière tentative d'explication.  Après j'arrête, promis. Mais faut faire un peu de calcul pour comprendre.

Si tu prends le vecteur (0,1,0) et que tu le multiplies avec la matrice Profoto to XYZ. Ca te donnera les coordonnées de la primaire verte du profoto dans l'espace XYZ.

Maintenant multiplie le vecteur obtenu par la matrice XYZ to sRGB (  pour obtenir la valeur RGB de la primaire verte du profoto dans l'espace sRGB ... tu suis encore ?  ;-) ). Ben une des valeurs du vecteur RGB obtenu va être en dehors de l'intervalle [0,1], parce que le vert profoto est hors gamut du sRGB.

Maintenant, si tu préfères une simple règle de trois  :

Okay, si tu prends ton rouge de 1,0 en AdobeRGB, combien sera la valeur correspondante en sRGB et sera-elle dans l'intervalle [0,1] ?

...
Sinon, l'espace Lab est défini à partir de l'espace XYZ, ça ne sert pas à grand chose de passer par le LAB pour passer de profoto à sRGB.

La je suis d'accord avec toi, les espaces colorimétriques étant différent, quand tu convertis d'un espace large vers un plus étroit, tu perds inévitablement des couleurs. Mais là on parlait de conversion RGB vers CMJN qui ne sont pas des espaces colorimétriques mais des systèmes de coordonnées. Si tu convertis de RGB en CMJN en restant dans le même espace couleur, il n'y a aucune raison que tu aies des modifications de tes couleurs, sauf de petites erreurs d'arrondis si tu es dans une précision limitée, par exemple en 8 bits, normalement quasi invisibles. En 16 bits il ne devrait y avoir aucune différence visible.

Le CMJN intéresse les imprimeurs juste parce qu'il leur permet de le traduire directement en quantité d'encre quand ils impriment en quadrichromie. S'ils impriment avec des imprimantes avec plus de 4 couleurs, il ne sert pas à grand chose.

[Nikojorj]

Mais là on parlait de conversion RGB vers CMJN qui ne sont pas des espaces colorimétriques mais des systèmes de coordonnées.

En pratique, on n'utilise pas RVB ou CMJN comme système de coordonnées, parce qu'il y a XYZ pour ça ; du coup, on ne les utilise qu'en tant qu'espaces.

[egtegt²]

En pratique, on n'utilise pas RVB ou CMJN comme système de coordonnées, parce qu'il y a XYZ pour ça ; du coup, on ne les utilise qu'en tant qu'espaces.

A mon sens tu confonds deux choses qui n'ont rien à voir. Par exemple AdobeRGB et sRGB sont deux espaces colorimétriques définis par défaut en RGB et pourtant ce sont des espaces couleur différents. Et il est impossible d'utiliser RGB sans avoir d'espace couleur associé sinon il te manque la correspondance entre les valeurs extrêmes et des couleurs *LAB.  Si je te dis que j'ai une couleur RGB (255,128,0) tu sais qu'il s'agit d'un Orange tirant sur le brun mais tu ne peux pas me dire quelle teinte exacte d'orange exactement. Pour ça il te faut l'espace colorimétrique qui va définir les valeurs extrêmes et le gamma qui va définir comment on varie entre les extrêmes.

Cette même couleur peut aussi être traduite en (0%,62%,100%,0%) en CMJN mais si l'espace couleur est le même, la couleur est strictement identique.

[asak]

Il faut être dans un espace de travail adéquoit,
qui permet les conventions sans dégâts et  le proofing pour faire les corrections