Les indispensables ...

[tenmangu81]

- dans le cas d'un espace de destination de gamut > au gamut de l'espace de calcul, il n'y a aucun changement sur les couleurs, si il y avait des valeurs de couleurs écrêtées, elles le reste car il n'y a pas d'information qui permettrait de recalculer les valeurs RGB dans ce nouvel espace. (en conclusion, une conversion vers un espace plus grand n'a bien souvent aucune utilité)

Je compléterais en disant, sauf erreur, que les conversions d'un espace vers un autre plus grand sont courantes (c'est le cas d'un document sRGB affiché sur un écran Adobe98, par exemple), mais en effet les couleurs ne changent pas. Seules les valeurs R, G et B sont recalculées pour l'espace plus grand de façon, justement, à ce que les couleurs soient conservées.

[fred94-]

- Même si je ne vois pas trop ce que cette affirmation a de rapport avec cette section du forum,
- Même si je suis loin d'être un spécialiste de la chose (mais alors très loin...)
Je ne vois pas pourquoi ni comment un fabricant d'APN pourrait donner "des infos sur le choix des algorithmes pour dématricer le fichier raw" !

Ce que le fabricant peut "donner", c'est des éléments techniques sur son capteur + matrice :
- comment est calée la matrice de Bayer par rapport aux photosites (elle ne va pas nécessairement jusqu'aux limites du capteur, ou la partie utile n'y va pas et s'étend du photosite x,y au photosite xn,yn).
- quelles sont les caractéristiques physiques de la matrice : pour schématiser, son "rendement" pour chacune des trois couleurs.
- et évidemment la TC à la prise de vue... dans le système de mesure du fabricant.

Après, les algorithmes de dématriçage, ce n'est certainement pas au fabricant de dire à l'éditeur de logiciel ce qu'il doit employer !
Mais bien à chaque éditeur de pondre sa propre méthode - ses propres algorithmes - pour arriver au meilleur résultat !

bonjour,

Alors je suis encore moins dans la confidence de PRO mais je me pose des questions histoire de...
Peut-être as tu raison sur le fait que chaque logiciel utilise des algorithmes maison mais, les fabricants d'APN qui n'ont pas de logiciel "maison" il ne vont pas cacher les éléments qui permettent de sublimer les clichés réalisés avec leurs produits?

Désolé mais cela fait écho avec l'amélioration de la qualité des fichier RAF provenant des capteurs Fuji, en collaboration avec ADOBE pour lightroom. Si ils travaillent ensemble j'imagine qu'il donne des indications précises et donc "peut-être" les algorithme de Fuji....

Je suis surement naïf mais bon

[matopho]

Bonjour,

Non à ma connaissance, son espace de calcul est constant (avec des limites connues et fixes)  (1).

Lorsqu'il y a conversion :
- dans le cas d'un espace de destination de gamut < au gamut de l'espace de calcul, les couleurs en dehors de l'espace de destination seront "recalculées" en fonction du mode : relatif ou perceptif, par exemple en mode relatif, les couleurs sont ramenées aux limites (frontières) de l'espace de destination.

- dans le cas d'un espace de destination de gamut > au gamut de l'espace de calcul, il n'y a aucun changement sur les couleurs, si il y avait des valeurs de couleurs écrêtées, elles le reste car il n'y a pas d'information qui permettrait de recalculer les valeurs RGB dans ce nouvel espace. (en conclusion, une conversion vers un espace plus grand n'a bien souvent aucune utilité)

Dans un espace de calcul, si la couleur calculée dépasse les possibilités de l'espace de calcul, la valeur est écrêtées, d'où l'intérêt d'un espace de calcul suffisamment grand (comme ProStar par exemple), néanmoins, cela est vrai si les calculs sont réalisés avec une profondeur avec au moins 16 bits, si possible en flottant.

(1) Il est possible que son espace de calcul soit dynamique, c'est à dire qu'il choisisse dans une bibliothèque l'espace le mieux adapté à un APN lors du dématricage du raw, mais une fois cet espace sélectionné, il peut être considéré comme constant.

Je compléterais en disant, sauf erreur, que les conversions d'un espace vers un autre plus grand sont courantes (c'est le cas d'un document sRGB affiché sur un écran Adobe98, par exemple), mais en effet les couleurs ne changent pas. Seules les valeurs R, G et B sont recalculées pour l'espace plus grand de façon, justement, à ce que les couleurs soient conservées.

Espace de calcul = espace de travail, selon la terminologie reconnue : d'ac ?

De même, vous parlez bien de conversion dans le logiciel CO et pas d'export de CO et import dans ToLineOuShop ou autre ?

Si oui, alors d'accord avec les citations. Mais ...

Mes essais ont été fait avec un X-pro1 Fuji. L'espace FujiXPro1-Generic.icm correspondant déborde par endroit de AdobeRGB mais est entièrement contenu dans Iridient Lstar. Cela pour donner une idée de sa taille.

Ma première recopie montre une photo avec aucun profil d'épreuve, donc dans l'espace de travail de CO, (selon les conclusions communément admises pour l'instant). Il y a des indications de zones hors profil (si on admet que l'avertisseur de surexposition, le triangle avec !, réglé à 255, montre les zones de l'image hors du profil). Comme l'affichage est dans l'espace de travail, ces zones devraient être "ramenées aux limites (frontières) de l'espace de destination" càd de travail.

Or, quand j'affiche la même photo dans Iridient Lstar (deuxième recopie), les zones en surexpo sont plus petites, voire inexistantes. Les zones ayant précédemment des valeurs à 255 pour certaines couleurs ont maintenant des valeurs inférieures à 255. Donc ces zones ne sont pas écrêtées. Elles gardent leur valeurs d'origines résultant de la conversion des données RAW avec le profil d'entrée et la courbe associée, bien qu'étant hors du profil de CO.

Mon raisonnement est-il valable ? Qu'en pensez-vous ?

Ce raisonnement est une autre façon de poser la question initiale.

Salutations

[tenmangu81]

Bonjour,

Espace de calcul = espace de travail, selon la terminologie reconnue : d'ac ?

De même, vous parlez bien de conversion dans le logiciel CO et pas d'export de CO et import dans ToLineOuShop ou autre ?

Si oui, alors d'accord avec les citations. Mais ...

Mes essais ont été fait avec un X-pro1 Fuji. L'espace FujiXPro1-Generic.icm correspondant déborde par endroit de AdobeRGB mais est entièrement contenu dans Iridient Lstar. Cela pour donner une idée de sa taille.

Ma première recopie montre une photo avec aucun profil d'épreuve, donc dans l'espace de travail de CO, (selon les conclusions communément admises pour l'instant). Il y a des indications de zones hors profil (si on admet que l'avertisseur de surexposition, le triangle avec !, réglé à 255, montre les zones de l'image hors du profil). Comme l'affichage est dans l'espace de travail, ces zones devraient être "ramenées aux limites (frontières) de l'espace de destination" càd de travail.

Or, quand j'affiche la même photo dans Iridient Lstar (deuxième recopie), les zones en surexpo sont plus petites, voire inexistantes. Les zones ayant précédemment des valeurs à 255 pour certaines couleurs ont maintenant des valeurs inférieures à 255. Donc ces zones ne sont pas écrêtées. Elles gardent leur valeurs d'origines résultant de la conversion des données RAW avec le profil d'entrée et la courbe associée, bien qu'étant hors du profil de CO.

Mon raisonnement est-il valable ? Qu'en pensez-vous ?

Ce raisonnement est une autre façon de poser la question initiale.

Salutations

Bon, ça démarre mal   Pour moi, l'espace de calcul de C1 (Iridient LStar ou LStar BigMamma ?) est non paramétrable, et fixé par C1, alors que l'espace de travail est l'espace de simulation ou d'émulation, c'est à dire le "Profil d'épreuve" la plupart du temps. Il est choisi par moi en fonction de l'export auquel la photo est destinée. Non, qu'entends-tu par "conversion dans CO" ?
Pour le reste, ta question est bien reformulée, mais je n'ai pas pour l'instant de réponse....  

Cela étant, je trouve qu'un espace qui déborde par endroits d'Adobe RGB n'est pas très grand pour un profil d'APN, sauf s'il déborde beaucoup. Bon, OK, je n'ai pas testé l'espace de mon APN, ce qu'il faudrait que je fasse.

Edit : je viens de faire la manip et l'espace de mon APN est TRES largement plus grand qu'Adobe RGB 1998. Le problème ne viendrait-il pas de là ?

[MBe]

Bonsoir,

Dans un autre post sur le forum j'ai posé une question sur la,moulinette que chaque APN réalise pendant l'enregistrement du raw. Et cela rejoint un peu votre réponse, les fabricants d APN donne bien des infos sur le choix des algorithmes pour dématricer le fichier raw non?

A ma connaissance non, chaque constructeur  conserve son savoir faire sur le sujet. j'ai fait quelques comparaisons, il y a en effet des écarts bien visibles.

Rawterapee permet de changer cet algorithme il me semble mais si j'ai bien compris un document sur l'étude des différents algorithmes de dematricage, ils ont plus ou moins efficace dans la gestion de ce qui s'apparente à l effet d'escalier par ex dans les jeux vidéos.

Et non au niveaux du choix d'un espace et donc d'un gamut mais ce n'est que ma compréhension.

Oui RT donne le choix à l'utilisateur sur l'algorithme de dématricage (et bien d'autres paramètres dans cette phase du développement).

C'est bien dans cette phase, que les valeurs RVB ou RVVB sont référencées dans un espace couleur ( XYZ peut être, mais les constructeurs sont discrets), que le profil icc input, générique ou personnel est appliqué aux pixels pour construire l'image.

[MBe]

Je compléterais en disant, sauf erreur, que les conversions d'un espace vers un autre plus grand sont courantes (c'est le cas d'un document sRGB affiché sur un écran Adobe98, par exemple), mais en effet les couleurs ne changent pas. Seules les valeurs R, G et B sont recalculées pour l'espace plus grand de façon, justement, à ce que les couleurs soient conservées.

Oui c'est bien cela.

[MBe]

- Même si je ne vois pas trop ce que cette affirmation a de rapport avec cette section du forum,
- Même si je suis loin d'être un spécialiste de la chose (mais alors très loin...)
Je ne vois pas pourquoi ni comment un fabricant d'APN pourrait donner "des infos sur le choix des algorithmes pour dématricer le fichier raw" !

Ce que le fabricant peut "donner", c'est des éléments techniques sur son capteur + matrice :
- comment est calée la matrice de Bayer par rapport aux photosites (elle ne va pas nécessairement jusqu'aux limites du capteur, ou la partie utile n'y va pas et s'étend du photosite x,y au photosite xn,yn).
- quelles sont les caractéristiques physiques de la matrice : pour schématiser, son "rendement" pour chacune des trois couleurs.
- et évidemment la TC à la prise de vue... dans le système de mesure du fabricant.

Après, les algorithmes de dématriçage, ce n'est certainement pas au fabricant de dire à l'éditeur de logiciel ce qu'il doit employer !
Mais bien à chaque éditeur de pondre sa propre méthode - ses propres algorithmes - pour arriver au meilleur résultat !

Oui, cela correspond à la réalité. Maintenant pour une matrice Bayer, il y a un peu de littérature, mais chaque constructeur garde ses "recettes de cuisine".
Oui également pour les données encapsulées dans le raw qui sont plus ou moins communiquées.

[MBe]

Bonjour,

Espace de calcul = espace de travail, selon la terminologie reconnue : d'ac ?

Bonsoir,
Oui espace de travail = espace de calcul, dans C1 il n'est pas officiellement connu,  hormis l'information donnée par Salomé_B
Mais à noter que C1 permet une simulation avec affichage de l'image et de l'histogramme dans une autre espace, choisi par l'opérateur.

De même, vous parlez bien de conversion dans le logiciel CO et pas d'export de CO et import dans ToLineOuShop ou autre ?
Si oui, alors d'accord avec les citations. Mais ...

Je parle plutôt d'une simulation, mais un export donnerait le même résultat (à profil icc équivalent bien sur).
Dans le cas d'une simulation, avec le choix d'un profil icc de simulation,  il y a bien une conversion via le PCS. (+1 conversion pour l'affichage sur écran de l'image)
Dans le cas d'une simulation, sans choix de profil de simulation, je ne suis pas certain qu'il ait une conversion (sauf pour l'affichage sur l'écran), car d'après les informations communiquées par Benaparis, les histogrammes ne changent pas, c'est un point qui suscite interrogation pour moi, en prenant le pire cas ,une conversion via PCS, il n'y a pas de modification des valeurs colorimétriques aux erreurs près des calculs (probablement négligeables) car il n'y a pas de changement d'espace couleur.

Remarque : une simulation sans profil est faisable, mais un export sans profil icc n'est pas possible.
Cas particulier : un export sans profil icc de type tif linéaire destiné à réaliser un profil icc d' APN, mais dans ce cas les valeurs RGB sont définis dans l'espace couleur du capteur.

Mes essais ont été fait avec un X-pro1 Fuji. L'espace FujiXPro1-Generic.icm correspondant déborde par endroit de AdobeRGB mais est entièrement contenu dans Iridient Lstar. Cela pour donner une idée de sa taille.

Je ne suis pas surpris que le gamut du profil gneric du Fuji Xpro1 dépasse celui d'Adobe RGB, cela doit être le cas de nombreux capteur.
Iridient Star étant un profil "wide gamut" couvre probablement l'espace "couleurs" de votre APN. Mais ces comparaison de taille de gamut sont à relativisées, un autre aspect peu discuté,  est le nombre de couleurs distinctes qu'un capteur avec son dématricage (donc avec son profil icc) est capable de produire (la qualité des filtres RVVB, la techno des capteurs, l'électronique de lecture des photosites,  le dématricage de Bayer, les tables des profils et leur résolution /précision participent à la performance globale).
Dans tous les cas un grand espace de travail (calcul) dans la phase de développement (Balance des blancs, réglage des niveau, courbe en S...) permet d'éviter les écrêtages. Néanmoins je ne suis pas certain qu'un espace de travail / calcul "de taille démesurée par rapport au besoin réel" améliore la fidélité des couleurs restituées (Delta E 2000), mon impression première me dit le contraire, mais l'essai pour le montrer n'est pas forcément facile à mettre en œuvre.

Ma première recopie montre une photo avec aucun profil d'épreuve, donc dans l'espace de travail de CO, (selon les conclusions communément admises pour l'instant). Il y a des indications de zones hors profil (si on admet que l'avertisseur de surexposition, le triangle avec !, réglé à 255, montre les zones de l'image hors du profil). Comme l'affichage est dans l'espace de travail, ces zones devraient être "ramenées aux limites (frontières) de l'espace de destination" càd de travail.

Or, quand j'affiche la même photo dans Iridient Lstar (deuxième recopie), les zones en surexpo sont plus petites, voire inexistantes. Les zones ayant précédemment des valeurs à 255 pour certaines couleurs ont maintenant des valeurs inférieures à 255. Donc ces zones ne sont pas écrêtées. Elles gardent leur valeurs d'origines résultant de la conversion des données RAW avec le profil d'entrée et la courbe associée, bien qu'étant hors du profil de CO.

Sous réserve qu'il n'y ait pas un biais (toujours possible car il faut prendre en considération pour une couleur, sa teinte, sa légèreté (sorte de "luminosité) et sa saturation),et en restant au conditionnel du fait de l'absence d'information probante de son fabricant sur l'espace de travail,  cela voudrait dire que l'espace de travail de C1 est plus petit que celui d' Iridient Lstar.

Suggestion : faire le même type de simulation avec une image de ce type http://www.brucelindbloom.com/index.html?RGB16Million.html donnera des informations.
A noter, il est probable que Iridient (comme d'autres espaces) comporte des zone de couleurs imaginaires (non réelles) ou non visibles par la vision humaine.

Mon raisonnement est-il valable ? Qu'en pensez-vous ?

Ce raisonnement est une autre façon de poser la question initiale.

Salutations

j'ai essayé de répondre au mieux à cette discussion, mais je ne reste à l'écoute des autres avis. Les interventions de Jean Delmas me manquent, je souhaite qu'il revienne nous éclairer comme il l'a fait il y a quelques mois.

[matopho]

Bonsoir,

at tenmangu81

Par  "Espace de calcul = espace de travail, selon la terminologie reconnue" je voulais dire que ce vous appeler "espace de calcul" est communément appelé "espace de travail" (page 107 et 108, J. Delmas, Gestion des couleurs, 2012). C'est aussi la terminologie utilisée par Mbe. Pour CO ainsi que DXO il n'est pas connu. Pour LR c'est Melissa. Pour CO on ne peut pas le modifier. Ce que vous appelez  "espace de travail" est en fait l'espace d'affichage, avec épreuve ou non.

Afin d'éviter toute ambiguïté dans le futur, il serait judicieux de se tenir à cette terminologie. Ce n'est qu'une suggestion.

at Mbe

Mon interrogation initiale avait commencé en visualisant un arc en ciel de Granger qui comporterait aussi toute les couleurs possibles.
http://www.chassimages.com/forum/index.php/topic,236053.msg5411979.html#msg5411979
Je vais refaire l'essai avec l'image du lien que vous proposez.

"cela voudrait dire que l'espace de travail de C1 est plus petit que celui d' Iridient Lstar." : c'est ma conclusion
+
Si l'image résultant du dématriçage est plus grande que l'espace de travail de CO, elle n'est pas écrêtée (ie. elle est gardée telle quelle en mémoire) car elle peut être visualisée sans avertissement de surexposition dans un espace plus grand, comme Iridient LStar.

J'attends également les interventions de Jean Delmas.

Salutations

[tenmangu81]

Ce que vous appelez  "espace de travail" est en fait l'espace d'affichage, avec épreuve ou non.

Afin d'éviter toute ambiguïté dans le futur, il serait judicieux de se tenir à cette terminologie. Ce n'est qu'une suggestion.

Aïe !! Pour moi, l'espace d'affichage est celui de mon affichage, donc de mon écran. A noter que le problème ne se pose que pour les logiciels qui permettent de travailler sa photo dans des espaces différents de l'espace de calcul, comme C1.
Dans ce cas, il vaudrait mieux utiliser:
- espace de calcul, ou peut-être espace de travail si on utilise émulation ci-dessous,
- espace de travail, ou, mieux, d'émulation
- espace d'affichage, celui de l'écran

Ce sont des questions de terminologie qui ne se posent pas trop dans le cas d'ACR ou de Lr, puisqu'on travaille dans l'espace de travail ( ) qui est de type Melissa, et que pour travailler dans le profil d'épreuve, il faut vraiment le vouloir et l'afficher comme tel.

[asak]

Je ne penses pas; ACR est comme photoshop il me semble 

[tenmangu81]

Je ne penses pas; ACR est comme photoshop il me semble 

Oui  C'est plutôt que Photoshop utilise ACR comme dématriceur, et point d'entrée, donc. So what ?

[matopho]

Bonjour,

Aïe !! Pour moi, l'espace d'affichage est celui de mon affichage, donc de mon écran. A noter que le problème ne se pose que pour les logiciels qui permettent de travailler sa photo dans des espaces différents de l'espace de calcul, comme C1.
Dans ce cas, il vaudrait mieux utiliser:
- espace de calcul, ou peut-être espace de travail si on utilise émulation ci-dessous,
- espace de travail, ou, mieux, d'émulation
- espace d'affichage, celui de l'écran

Ce sont des questions de terminologie qui ne se posent pas trop dans le cas d'ACR ou de Lr, puisqu'on travaille dans l'espace de travail ( ) qui est de type Melissa, et que pour travailler dans le profil d'épreuve, il faut vraiment le vouloir et l'afficher comme tel.

Je ne cherche pas à redéfinir la terminologie, il vaut mieux se tenir à ce qui est communément définis par ceux qui nous ont précédés. Professionnellement je ne l'ai jamais fait, sauf si c'était moi qui définissait un nouveau référentiel.

Le concept qui me parait important est celui d'espace de travail. C'est l'espace autour duquel tout se fait : la conversion du RAW, la visualisation, l'impression et l'export. A chacune de ces entrées ou sorties est associé un espace ICC.

Un lien pour illustrer :
http://www.profil-couleur.com/tp/204-espace-travail.php

Salutations

[asak]

Oui  C'est plutôt que Photoshop utilise ACR comme dématriceur, et point d'entrée, donc. So what ?

ACR n'est pas avec mélissa il me semble 

[MBe]

ACR n'est pas avec mélissa il me semble 

Oui j'ai compris comme cela aussi, mais peut être qu'il y des changements dans la version CC (cloud)?

[tenmangu81]

ACR n'est pas avec mélissa il me semble  

Oui, Melissa est pour Lr, mais j'avais compris que Lr utilisait peu ou prou le même module qu'ACR (utilisé comme porte d'entrée de Photoshop pour les RAW). Je suis d'accord qu'ACR ouvre des images dont les espaces sont divers, et peut les traiter dans ces différents espaces une fois dématricées. J'ai peut-être mal compris la phrase "ACR est comme Photoshop". Photoshop travaille en bitmap, ne l'oublions pas.

[MBe]

Oui, Melissa est pour Lr, mais j'avais compris que Lr utilisait peu ou prou le même module qu'ACR (utilisé comme porte d'entrée de Photoshop pour les RAW). Je suis d'accord qu'ACR ouvre des images dont les espaces sont divers, et peut les traiter dans ces différents espaces une fois dématricées. J'ai peut-être mal compris la phrase "ACR est comme Photoshop".

Oui tu as raison également, il y a de nombreuses parties communes (dématricage), mais probablement qu'a un moment dans le process pour Lr, il y a une commutation vers Melissa.

[Verso92]

Photoshop travaille en bitmap, ne l'oublions pas.

C'est un peu perturbant, ces terminologies à la noix...
Un RAW, par définition, est une image de type bitmap (les éléments de l'image sont cartographiés par rapport à leurs coordonnées x/y)...

[tenmangu81]

Un RAW, par définition, est une image de type bitmap (les éléments de l'image sont cartographiés par rapport à leurs coordonnées x/y)...

Oui, tu as raison Verso, une matrice est composée de lignes et de colonnes !!

[tenmangu81]

Oui tu as raison également, il y a de nombreuses parties communes (dématricage), mais probablement qu'a un moment dans le process pour Lr, il y a une commutation vers Melissa.

Pour schématiser, Lr est constitué d'ACR limité à l'espace Melissa et de Bridge