Nec MultiSync EA244WMi

Démarré par M@kro, Février 26, 2015, 13:41:13

« précédent - suivant »
Imprimer
En bas Pages 1 2 3 4 5 6 7 8 9
Actions de l'utilisateur

Verso92

#150
Mars 12, 2015, 20:13:17
Citation de: Alain c le Mars 12, 2015, 20:05:00
Tiens, au hasard d'une recherche sur un catalogage d'écrans orientés photo, via google, devinez sur quoi je tombe ?

Bonne nouvelle Verso, nous sommes d'accord pour dire qu'un écran qui coute le double  "du simple au double, à la louche..." a de fortes chance d'être meilleur.
cf: cette comparaison de prix entre un HP LP2775W et ton NEC:

Ne sois pas inquiet : je vais bien finir par remettre la main sur notre facture...

Julian

#151
Mars 12, 2015, 20:31:31
Citation de: Pat20d le Mars 11, 2015, 21:54:14
+1 c'est la meilleur nouvelle de la soirée ... si c'est vrai  ;D

Super, un pot de départ !

Jean Delmas

#152
Mars 13, 2015, 13:44:36
 [at] Tenmangu81

Vous avez raison, écrêtage de gamut et ravages causés par une résolution tonale trop faible par rapport au gamut ne sont pas directement liés.

L'écrêtage de gamut (c'est-à-dire le remplacement de couleurs très saturées par d'autres qui le sont moins) est une dégradation colorimétrique facile à comprendre. C'est ce qu'on subit quand on développe un fichier RAW dans sRGB : on fait passer à la trappe toutes les couleurs qui sont hors de l'intersection du « grand » espace du capteur avec le « petit » espace sRGB.

En revanche, il est plus difficile de comprendre pourquoi, comme le fait remarquer le très regretté Bouillot, pour une résolution tonale donnée, par exemple 8 bits, la « qualité » de numérisation d'une image diminue quand on la définit dans un espace de plus grand volume.

Un petit dessin au tableau noir permet généralement de faire comprendre cette bizarrerie aux élèves graphistes ou photographes. Essayons ici avec des mots et intéressons nous au coté joignant les deux primaires Vert et Rouge du triangle représentant le gamut d'un espace de travail dans le diagramme xy. 

Ce segment de droite est le lieu de couleurs dont les composantes R et G varient de 0 à 255 pour la première et de 255 à 0 pour la secondes si on les code avec une résolution tonale de 8 bits.

La variation des nombres entiers R et G le long de ce segment de droite permet de coder les couleurs d'un hypothétique dégradé vert-rouge. Si on le code sur 8 bits, ce dégradé sera défini par 256 valeurs successives des composantes R et G. Si la distance colorimétrique entre les deux primaires Verte et Rouge est « petite » (comme dans sRGB) alors, la distance colorimétrique entre deux nuances successives du dégradé sera « petite » et on n'observera pas de rupture dans la continuité du dégradé. En revanche, si la distance entre les deux primaires est « grande » (comme dans ProPhoto RGB), l'écart colorimétrique entre deux nuances successives sera « grand » et un observateur pourra déceler des ruptures dans la continuité du dégradé.

Bien entendu, si on code le dégradé sur 16 bits et qu'on le définit ainsi par 65536 valeurs successives de composantes R et G au lieu de 256, l'écart colorimétrique entre deux valeurs contigües sera alors tellement petit qu'on ne verra jamais la moindre rupture de continuité dans le dégradé, ceci même si la distance entre les primaires Rouge et Vert est « grande » (ProPhoto RGB).

A vrai dire, ce n'est pas tant l'apparition immédiate de ruptures dans les dégradés qu'il faut craindre quand on applique une résolution tonale de 8 bits à un grand espace colorimétrique. Ce qui est à redouter ce sont les artefacts qui vont surgir immanquablement dans l'image quand on lui fera subir des corrections, des optimisations. Les calculs colorimétriques se font sur des nombres entiers et sont extrêmement sensibles aux erreurs générées par la nécessité d'arrondir les résultats. Les opérations d'accentuation, en particulier, font souvent apparaitre d'horribles bizarreries dans les dégradés définis sur 8 bits dans ProPhoto RGB.

Conclusion. Si vous définissez vos images dans un espace colorimétrique de volume supérieur à celui d'Adobe RGB (1998), il FAUT utiliser une résolution tonale de 16 bits. Si vous les définissez dans un espace de volume inférieur à celui d'Adobe RGB (1998), vous pouvez utiliser une résolution tonale de 8 bits. Et si elles sont définies dans Adobe RGB (1998) ? Eh bien, on fait comme on le sent, mais il est bon de vérifier...
bleutchekov

hamacintosh

#153
Mars 13, 2015, 14:24:54
C'est limpide !
Merci.
Quel dommage pour nous que vous n'interveniez pas plus.

parkmar

#154
Mars 13, 2015, 14:32:41
C'est curieux? quand on m'explique les choses de cette façon, je comprends!
J'ai même l'impression de devenir intelligent!

tenmangu81

#155
Mars 13, 2015, 16:24:16
Merci M. Delmas, c'est d'une clarté sans faille, comme dans vos livres !!

dioptre

#156
Mars 13, 2015, 16:30:20
Citation de: hamacintosh le Mars 13, 2015, 14:24:54
C'est limpide !
Merci.
Quel dommage pour nous que vous n'interveniez pas plus.


C'est aussi limpide que dans son bouquin
Mais c'est 512 pages !
Pas évident sur un forum d'intervenir utilement quand ça part dans tous les sens avec toutes les erreurs de raisonnement qu'on y trouve !

Verso92

#157
Mars 13, 2015, 18:16:02
Citation de: Verso92 le Mars 12, 2015, 20:13:17
Ne sois pas inquiet : je vais bien finir par remettre la main sur notre facture...

Moins cher que ce qu'on m'en avait dit à l'époque : très précisément 637,95€ en octobre 2009.

Verso92

#158
Mars 13, 2015, 19:12:39 Dernière édition: Mars 13, 2015, 19:18:57 par Verso92
Citation de: Jean Delmas le Mars 13, 2015, 13:44:36
Conclusion. Si vous définissez vos images dans un espace colorimétrique de volume supérieur à celui d'Adobe RGB (1998), il FAUT utiliser une résolution tonale de 16 bits. Si vous les définissez dans un espace de volume inférieur à celui d'Adobe RGB (1998), vous pouvez utiliser une résolution tonale de 8 bits. Et si elles sont définies dans Adobe RGB (1998) ? Eh bien, on fait comme on le sent, mais il est bon de vérifier...

De toute façon, quand on développe un RAW, c'est forcément dans un espace 16 bits (sauf, de mémoire, avec Photoshop qui permet de le faire en 8 bits*, mais je n'en vois pas trop l'intérêt).
Ensuite, quand on dispose de Photoshop, je ne vois pas non plus l'intérêt de finaliser l'image en se restreignant à une quantification de 8 bits (on voit bien les ravages quand on pousse les curseurs, rien qu'en regardant l'histogramme qui se transforme très vite en peigne si on chahute un peu les niveaux, par exemple).

Ce n'est qu'une fois l'image finalisée (lorsqu'elle a subit toutes les dégradations liées aux différents calculs) qu'on repassera en 8 bits éventuellement (pour une sortie Jpeg, par exemple).
J'ai bon ?

*c'est, curieusement, le paramètre par défaut dans ACR, toujours de mémoire...

Auvergnat63

#159
Mars 13, 2015, 19:23:36
Citation de: Verso92 le Mars 13, 2015, 19:12:39
Ensuite, quand on dispose de Photoshop, je ne vois pas non plus l'intérêt de finaliser l'image en se restreignant à une quantification de 8 bits (on voit bien les ravages quand on pousse les curseurs, rien qu'en regardant l'histogramme qui se transforme très vite en peigne si on chahute un peu les niveaux, par exemple).

Ce n'est qu'une fois l'image finalisée (lorsqu'elle a subit toutes les dégradations liées aux différents calculs) qu'on repassera en 8 bits éventuellement (pour une sortie Jpeg, par exemple).

J'ai bon ?

Je ne sais pas mais je fais comme toi  ;). Heu si si tu as raison...

Jean Delmas

#160
Mars 13, 2015, 19:48:08
Citation de: Verso92 le Mars 13, 2015, 19:12:39
J'ai bon ?
Oui, Verso92, très bon.

Même s'il est vrai qu'Adobe encourage ses clients à développer les fichiers RAW dans ProPhoto RGB avec une résolution tonale de 16 bits, il les laisse tout à fait libres d'opter pour une autre combinaison, y compris calamiteuse comme ProPhoto RGB sous 8 bits.

Quant à l'intérêt d'une résolution tonale de 8 bits (quand on choisit de développer ses fichiers RAW dans Adobe RGB (1998) ou sRGB), il n'y en a qu'un : la division par deux du volume des fichiers. Je sais qu'au prix actuel d'un disque de 3 To, c'est un argument qui peut nous paraitre dérisoire, mais je passe une partie de ma vie à tenter de convaincre des clients de renoncer à cet argument pour adopter un grand espace de définition sous 16 bits. Il est vrai que, dans le cas d'immenses collections d'images patrimoniales (grands musées, bibliothèques ou archives nationales...), on peut comprendre l'hésitation du responsable technique qui, s'il décide d'abandonner Adobe RGB (1998) sous 8 bits au profit de ProPhoto RGB sous 16 bits va devoir proposer à son innocent patron qu'il va falloir faire migrer son gigantesque dispositif de stockage vers un dispositif deux fois plus gigantesque.
bleutchekov

Verso92

#161
Mars 13, 2015, 19:57:02
Citation de: Jean Delmas le Mars 13, 2015, 19:48:08
Oui, Verso92, très bon.

Ouf !

;-)

Citation de: Jean Delmas le Mars 13, 2015, 19:48:08
Même s'il est vrai qu'Adobe encourage ses clients à développer les fichiers RAW dans ProPhoto RGB avec une résolution tonale de 16 bits, il les laisse tout à fait libres d'opter pour une autre combinaison, y compris calamiteuse comme ProPhoto RGB sous 8 bits.

Ce que je ne comprends pas, c'est qu'ACR propose par défaut 8 bits comme quantification en Adobe RVB (au départ, je ne comprenais pas pourquoi mes images étaient en 8 bits, avant de découvrir le pot aux roses...).

MBe

#162
Mars 13, 2015, 22:21:15
Bonjour M Delmas,

Je rebondis sur votre explication :
Citation de: Jean Delmas le Mars 13, 2015, 13:44:36

[...]
A vrai dire, ce n'est pas tant l'apparition immédiate de ruptures dans les dégradés qu'il faut craindre quand on applique une résolution tonale de 8 bits à un grand espace colorimétrique. Ce qui est à redouter ce sont les artefacts qui vont surgir immanquablement dans l'image quand on lui fera subir des corrections, des optimisations. Les calculs colorimétriques se font sur des nombres entiers et sont extrêmement sensibles aux erreurs générées par la nécessité d'arrondir les résultats. Les opérations d'accentuation, en particulier, font souvent apparaitre d'horribles bizarreries dans les dégradés définis sur 8 bits dans ProPhoto RGB.

Conclusion. Si vous définissez vos images dans un espace colorimétrique de volume supérieur à celui d'Adobe RGB (1998), il FAUT utiliser une résolution tonale de 16 bits. Si vous les définissez dans un espace de volume inférieur à celui d'Adobe RGB (1998), vous pouvez utiliser une résolution tonale de 8 bits. Et si elles sont définies dans Adobe RGB (1998) ? Eh bien, on fait comme on le sent, mais il est bon de vérifier...


Ne faut-il pas aussi considérer le rendu (relatif, perceptif, j'oublie les autres qui ont peu d'intérêt en photo), lors des conversions de Prophoto vers un espace plus petit (eciRGB, sRGB...) ainsi que la compensation du point noir? (les conversions sRGB vers Prophoto n'ont aucun intérêt à mon avis) qui interviennent de façon notoire sur les couleurs?

Il est également à noter que Rawtherapee effectue les calculs en 32 bits en virgule flottante, cela incitera peut être d'autres éditeurs de logiciel de dématricage et de traitement d'images à suivre (?)

En prenant l'hypothèse* que Dxo a pour espace de travail Adobe RGB, quel type de rendu est utilisé lors de la conversion du raw qui est dans l'espace de couleur de l'APN vers Adobe RGB (l'espace de travail)? Il est également surprenant qu'il autorise aussi la génération d'un tiff avec un profil Prophoto avec des calculs réalisés dans  l'espace Adobe RGB.

Merci pour votre avis.

*car je n'ai jamais reçu de confirmation de leur part.

asak

#163
Mars 13, 2015, 23:40:43
ACR ou camera raw dont le pendant est Lightroom.
ACR est un modèle de développement qui laisse libre choix à l'utilisateur avancé; ce qui implique connaissances et paramétrages. On est loin de la banalisation. Pour exemple; Photoshop permet de mélanger des fichiers 8 et 16 ou même 32 bites.  Pour moi c'est un très, très mauvais exemple.  ;)

Pat20d

#164
Mars 14, 2015, 07:10:29
Citation de: MBe le Mars 13, 2015, 22:21:15
[..]
Ne faut-il pas aussi considérer le rendu (relatif, perceptif, j'oublie les autres qui ont peu d'intérêt en photo), lors des conversions de Prophoto vers un espace plus petit (eciRGB, sRGB...) [..]
J'ai aussi posé la question dans le cas du dématriçage des données du RAW dans l'espace de travail du dématriceur, il semble que déjà il y ait des conversions à faire puisque l'espace natif des APN serait plus grand que Melissa par exemple pour ACR.
Puis en "sortie" du dématriceur lors de la production du fichier TIFF par exemple et dans un espace tel que Adobe ou sRGB. Pas de réponse à cette heure. Je n'ai jamais lu une quelconque information à ce sujet. (Mais je n'ai pas tout lu)

Citation de: MBe le Mars 13, 2015, 22:21:15
[..]
En prenant l'hypothèse* que Dxo a pour espace de travail Adobe RGB, quel type de rendu est utilisé lors de la conversion du raw qui est dans l'espace de couleur de l'APN vers Adobe RGB (l'espace de travail)? Il est également surprenant qu'il autorise aussi la génération d'un tiff avec un profil Prophoto avec des calculs réalisés dans  l'espace Adobe RGB.
Je suppose que l'on parle de l'espace dans lequel les données du RAW sont dématricées. Cette hypothèse ne me paraît pas très plausible mais seul Dxo connait la réponse.
Par contre je pense qu' il est tout à fait possible de convertir d'un espace vers un autre plus grand. (ex: sRGB vers Adobe ou Adobe vers Prophoto) Chaque pixel prendra une valeur différente pour qu'il garde la même couleur. Dans ce cas aucune conversion source de perte d'information, et pour cause, il n'y a pas de couleurs hors gammut de l'espace cible.
Patrick

Pat20d

#165
Mars 14, 2015, 07:18:25
Citation de: asak le Mars 13, 2015, 23:40:43
[..]
Pour exemple; Photoshop permet de mélanger des fichiers 8 et 16 ou même 32 bites.  Pour moi c'est un très, très mauvais exemple.  ;)

Si j'essaie de faire ça, Photoshop m'informe que je suis en train de faire une bêtise et me laisse décider soit de la faire soit de mettre en cohérence les deux fichiers que ce soit en profondeur d'échantillonnage ou en espace de travail. (Lié au paramétrage de Photoshop pour ce qui concerne les espaces de travail, je ne sais pas pour la profondeur d'échantillonnage )

D'où l'intérêt parfois de convertir un fichier élaboré dans un "petit" espace (SRGB ou Adobe) vers un plus grand, Prophoto par exemple.
Patrick

Jean Delmas

#166
Mars 14, 2015, 09:49:59
Citation de: MBe le Mars 13, 2015, 22:21:15
Ne faut-il pas aussi considérer le rendu...  ainsi que la compensation du point noir?
En prenant l'hypothèse* que Dxo a pour espace de travail Adobe RGB...

Une conversion d'image entre deux espaces de travail (et plus généralement entre deux profils V2 de type matriciel) ne connait qu'un seul mode de rendu, le mode Colorimétrie relative. En effet, seuls les profils basés sur des tables contiennent les données définissant les autres modes de rendu. C'est aussi le cas des versions V4 de certains espaces de travail mais ils sont tout à fait exotiques et mieux vaut aujourd'hui les ignorer. La notion de compensation du point noir a été inventée pour le monde de l'imprimerie afin de compenser des effets produits par "la couleur du noir" produite par un couple papier-encre. Cette option n'a donc pas de sens pour des conversions entre espaces de travail.

Je ne saisis pas bien ce que vous entendez par "espace de travail de DxO". En gros, comme tout logiciel de développement RAW, il prend les valeurs brutes RGB issues du dématriçage, les corrige de plusieurs points de vue (par exemple, il les "linéarise" pour les luminances basses et hautes, zones dans lesquelles le capteur perd un peu les pédales...) et prend ces nombres RGB ainsi corrigés comme des valeurs "définies dans l'espace du capteur" (*). Il lui suffit ensuite d'attribuer au fichier le profil de l'APN puis de convertir le résultat dans l'espace de travail choisi par l'utilisateur (ProPhoto RGB, Adobe RGB (1998), sRGB...).

(*) Un peu hors sujet, mais assez important. Ces nombres RGB bruts issus du dématriçage ne sont donc pas à proprement parler "définis dans l'espace de l'appareil" comme l'exige théoriquement l'ICC et comme on en obtient avec un scanner. Ces nombres résultent, bien sur du comportement du capteur, mais AUSSI du dématriçage (qui n'est pas le produit de l'appareil, mais d'un logiciel...). Ce que l'on caractérise quand on fabrique un profil ICC d'appareil c'est donc la combinaison un peu baroque d'un appareil et d'un logiciel. Or, si l'appareil est immuable (sauf maintenance), le logiciel, lui, est évolutif, se perfectionnant à chaque révision. En toute rigueur, un profil d'APN n'est donc valide que pour le logiciel de développement avec lequel on a développé le fichier de mire. Et il faudrait, en toute rigueur, le reconstruire à chaque mise à jour du logiciel de développement.
bleutchekov

MBe

#167
Mars 14, 2015, 14:39:39 Dernière édition: Mars 14, 2015, 14:46:07 par MBe
Merci pour la réponse.
Oui il est important de faire la distinction entre les profils V2 et V4. Par ailleurs l'ICC.org incite à utiliser la V4 (il faut que je relise l'argumentation).
J'ai compris que les profils icc des espaces de travail, sRGB par exemple était la sous forme de table (Lut) pour les balises TRC, notamment Rawtherapee dans sa documentation, son auteur indique qu'il a crée un profil Rt-sRGB avec 4096 valeurs pour éviter les problèmes de copyright, et signale que le sRGB classique à seulement 1024 valeurs, cela permet également de s'affranchir des effets de "peigne" lors des conversions.
Par "espace de travail de Dxo" je fais référence à l'espace dans lequel sont réalisés les calculs (BB, vibrance, saturation) sur les valeurs RGB des pixels, espace parfaitement défini par exemple dans Lr , RIMM RGB (proche Prophoto avec un gamma de 1).
Dans le cas de Dxo, ou cet espace n'est pas communiqué, je m'interroge toujours sur la qualité (perte de précision) des conversions d'espace vers un autre espace.

Pour la conversion de SrGB vers Prophoto, c'est possible mais les calculs et la gestions des arrondis ne doivent pas être indolores pour la valeur numérique des couleurs (passage de D65 à D50...dans l'espace XYZ), et concrètement je ne vois pas vraiment d'intérêt en photo.

Pat20d

#168
Mars 14, 2015, 14:52:48
Citation de: MBe le Mars 14, 2015, 14:39:39
[..]

Pour la conversion de SrGB vers Prophoto, c'est possible mais les calculs et la gestions des arrondis ne doivent pas être indolores pour la valeur numérique des couleurs (passage de D65 à D50...dans l'espace XYZ), et concrètement je ne vois pas vraiment d'intérêt en photo.

Pas vraiment "d'intérêt", simplement une obligation AMHA quand il s'agit de mettre deux fichiers images l'un en Prophoto l'autre en sRGB dans un même fichier.
Patrick

tenmangu81

#169
Mars 14, 2015, 15:14:44
Citation de: Pat20d le Mars 14, 2015, 14:52:48
Pas vraiment "d'intérêt", simplement une obligation AMHA quand il s'agit de mettre deux fichiers images l'un en Prophoto l'autre en sRGB dans un même fichier.

Il vaut mieux alors faire l'inverse : la conversion de Prophoto vers sRGB doit être moins douloureuse.

Pat20d

#170
Mars 14, 2015, 17:02:31
Citation de: tenmangu81 le Mars 14, 2015, 15:14:44
Il vaut mieux alors faire l'inverse : la conversion de Prophoto vers sRGB doit être moins douloureuse.
Je ne crois pas non.
Patrick

Jean Delmas

#172
Mars 15, 2015, 10:12:46
Bonjour à toutes et à tous.

Citation de: photocor le Mars 14, 2015, 19:31:53
Bonjour,
-1 : ...il semblerait que le rendu des espaces Prophoto et sRVB ont une intention de rendu perceptif, ...Y a t-il plusieurs versions?
-2: la version V4... pourquoi donc qualifiez vous ceux ci d'exotiques (j'ai peut être mal compris...
-3: L'espace eciRGB V2 ICCV4... est basée sur un gamma en L*, plus proche des caractéristiques de la réponse humaine ? Serait ce le poids des habitudes qui fait qu'on ne parle dans ces forums et presses de vulgarisation que des espaces Prophoto, sRGB, Adobe98?

Bonnes questions mais il va être difficile d'y répondre complètement en quelques mots.

1 - Les espaces de travail RGB, sont de type matriciel. Ils ne contiennent donc qu'un seul jeu de données pour définir le comportement de l'appareil hypothétique dont ils décrivent le comportement (et non pas un jeu de données par mode de rendu comme c'est le cas pour les profils basés sur des tables). Avec sa malheureuse matrice des primaires RGB et ses trois « courbes gamma », un profil matriciel définit un seul mode de rendu, « son mode de rendu ». Ce mode est le mode Colorimétrie relative, le seul qui permette de calculer le mode Colorimétrie absolue, indispensable pour les opérations d'épreuvage. Mais, pour des raisons que je n'ai jamais vraiment élucidées, les logiciels d'étalonnages d'écrans et les procédures de fabrication d'espaces de travail, inscrivent souvent dans la métadonnées ad hoc la valeur erronée « Mode perception ».  Il ne faut pas en tenir compte et seules les versions V4 des espaces de travail permettent d'appliquer le mode « Perception ».

2 - L'ICC exige qu'une conversion V4 entre deux espaces de travail s'opère entre DEUX espaces V4. Autrement dit, on ne peut pas faire une conversion RGB-V1 vers RGB-V4 et réciproquement. Cette limitation ainsi que des problèmes de compatibilité avec les logiciels de traitement d'images font, qu'à ma connaissance, les quelques espaces de travail V4 mis sur le marché restent aujourd'hui d'usage tout à fait marginal. Outre eciRGB_v2_ICCv4.icc à la dénomination piégeuse (V2 ? V4 ?) il existe une version V4 de sRGB qui s'appelle désormais, retenez votre souffle, sRGB_ICC_appearance_beta_displayclass.icc, et une de ProPhoto RGB, qui était appelée naguère ISO22028-2_ROMM-RGB.icc mais que je n'ai pas réussi à retrouver sur le site (assez confus) de l'ICC (mais elle doit bien se trouver quelque part). Utiliser un espace de travail V4 aujourd'hui me parait donc dangereux.

3 - Par ailleurs, mais c'est une question différente, l'espace de travail standard préconisé par l'eci, c'est-à-dire l'espace V2 appelé eciRGB_V2.icc et disponible ici http://www.eci.org/_media/downloads/icc_profiles_from_eci/ecirgbv20.zip est une excellente solution, alternative à Adobe RGB (1998) et mieux adaptée que ce dernier aux conversions vers les profils d'impression CMJN des presses offset de notre continent, car leur gamut est un peu plus étendu que celui des presses américaines. Il est anormal que cet espace ne figure pas explicitement dans la liste des profils standards fournie par Adobe avec ses logiciels... Mais on peut évidemment le télécharger à l'adresse ci-dessus et l'installer dans le dossier système ad hoc sur son poste de travail.
bleutchekov

Jean Delmas

#173
Mars 15, 2015, 14:03:43
Merci pour le lien vers ProPhoto RGB V4 que je n'avais pas retrouvé en préparant mon précédent post.

Cette balise a effectivement la valeur "Perceptuel", mais cette valeur est erronée. De même que, quand on caractérise un écran en produisant un profil matriciel, la plupart des logiciels d'étalonnage donnent cette même valeur à cette balise.

La raison en est probablement la suivante. Cette balise s'appelle "Default Rendering Intent" et, comme son nom l'indique, a pour véritable rôle de préciser le mode de rendu par défaut que le logiciel de traitement d'image doit appliquer quand l'utilisateur oublie de le préciser (ou quand l'application oublie de le lui demander). Ce peut être très utile quand on utilise un profil d'impression basé sur un jeu de tables par mode de rendu. Mais on peut imaginer que, ce concept de "mode de rendu par défaut" n'ayant évidemment aucun sens si un seul mode de rendu est disponible, les développeurs aient décidé, à la grosse louche, de lui donner systématiquement la valeur Perceptuel.

Pour ce qui concerne une généralisation des profils V4, je pense que nous en sommes encore loin, sauf pour les profils d'impression CMJN V4 qui constituent un progrès « visible ». Mais pour les espaces de travail et les autres profils RGB, il me semble que la prudence s'impose.

Par curiosité, je suis allé sur le Web « voir ce qu'on en dit en Amérique », et j'ai trouvé ceci sous les plumes du fameux « straight player » digitaldog (Alias Andrew Rodney) et de Schewe en septembre 2014 comme réponse à la question « rester en V2 ou passer en V4 ? » :

Schewe : L'intérêt des profils V4 aujourd'hui ? Aucun. Ils peuvent provoquer plus de dysfonctionnement qu'ils ne résolvent de problèmes. [...] et les espaces de travail V4 ne sont encore qu'au stade "beta".

Digitaldog : Qui sait ce que les ingénieurs en développement de X-Rite ont en tête (ou ce qu'ils fument). Ils ne supportent pas le PRMG [le medium de référence optionnel des nouveaux profils V4]  qui pourrait pourtant rendre utiles leurs profils V4. Restez en V2 !
bleutchekov

MBe

#174
Mars 15, 2015, 15:36:57
Ces échanges sont vraiment très intéressants. J'avais en effet trouvé cet avis d' Andrew Rodney sur luminous landsape. Voici l'avis que je me suis fait par diverses lectures et expériences.

L'objectif essentiel de l'ICC V4 est d'exploiter la vision perceptuelle humaine (mode de rendu perception) et de l'intégrer dans les espaces de travail, mais comme Mr Delmas le mentionne ci-dessus, il y a peu de profil disponible conforme à l'ICC V4 specification.
Ce mode de rendu perception a pour objectif de conserver (au mieux) les « distances » entre les couleurs et correspond à une compression globale, donc de ce fait, une conversion dans ce mode implique un recalcule de toutes les valeurs colorimétriques des pixels d'une image. C'est donc contraire à une reproduction fidèle des couleurs, à l'emploi de profil input icc d'APN, pour toutes les images qui ont des couleurs en dehors et dans le gamut de l'espace de destination.

Au contraire une conversion en mode relatif, pour les couleurs hors gamut de l'espace couleurs de destination sont ramenées sur les limites de l'espace et les valeurs dans le gamut de l'espace de destination sont inchangées.
Aujourd'hui, il n'existe pas de solution parfaite pour reproduire les couleurs (écrans, impression sur papier) qui réponde au gamut de la vision humaine, j'ai essayé de choisir la moins mauvaise qui respecte les couleurs saisie par l'APN.
Donc personnellement, dans la majorité des cas (99%) tous les essais effectués me montrent un avantage réel au mode de rendu relatif, donc je n'ai pas trouvé d'intérêt à utiliser les profils ICC en spécification V4.
Imprimer
En haut Pages 1 2 3 4 5 6 7 8 9
Actions de l'utilisateur