Développement pour impression papier

[aurelienpierre]

Ne pas se "prendre la tête" n'implique pas non plus de ne pas réfléchir un peu à ce que l'on fait ... 
Le tirage ne sera jamais exactement comme sur l'écran pour une simple raison : l'un est en lumière émise et l'autre en lumière réfléchie. Cela seul suffit à expliquer certaines différences, notamment de contraste, même lorsque les calibrages sont bons des deux côtés, ce qui n'arrive pas si souvent.

C'est exactement ce que j'ai dit… Néanmoins, il y a des moyens numériques d'ajuster le contraste de l'épreuvage écran de sorte à tenir compte du point noir du papier et de corriger perceptuellement les couleurs en fonctions de l'éclairage ambiant. Reste que ces moyens ne sont pas encore passés des journaux scientifiques aux logiciels.

@Aurélien, je mettrais un bémol pour le gammut. Effectivement faut pas trop se prendre la tête mais si tu ne gères pas correctement alors tu laisses l'algo de rendu faire le boulot qui ne sera pas nécessairement ce que tu vois à l'écran (d'où ma réponse).

Le problème, c'est que le maximum que tu peux faire, c'est afficher une alerte sur les pixels hors-gamut. Parce que, même si tu essaies de simuler le gamut imprimante à l'écran, il y a des chances pour que tu ne voies toujours pas ce que tu vas obtenir sur papier.

Dans tous les cas, la retouche du fichier raw doit être effectuée en considérant que le raw est un « master », c'est à dire un fichier parfait dans un espace de couleur illimité. Les problèmes de remappage de gamut concernent uniquement la fin du pixelpipe, c'est à dire l'exportation vers un medium donné. Affecter le master pour bricoler une exportation bancale n'est pas une bonne pratique à long terme.

Pour info, j'avais commencé, au sein de filmique v.3, un travail sur une méthode de mappage de gamut en passant par l'espace de couleur IPT-HDR, mais j'ai toujours des bugs dans ma conversion Lab <-> IPT-HDR. Je sais que le développeur de Photoflow a fait un truc similaire dans l'espace JzAzBz (on a commencé en même temps, mais il a fini avant moi). Ça devrait permettre d'avoir un résultat plus contrôlé que les 4 intentions de rendu de LittleCMS 2.

Aurélien, il me semble que RawTherapee utilise le CIECAM02 : https://rawpedia.rawtherapee.com/CIECAM02/fr
mais comme il n'y a pas de module d'impression, je sais pas si ça fait avancer !

Encore un truc que RawTherapee fait mieux que dt… Ça devient rageant.