Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Thread Contributor: guytounet34Développement pour impression papier
#1
Bonjour
Ayant redécouvert la "photo papier" je me suis mis à réaliser des livres photos que je fais imprimer en ligne.
Je les fait tirer par un site pro - en l’occurrence MonAlbumPhotos.fr - qui me renvoie des documents de bonne qualité.
Mais bien évidemment ce qui revient ne correspond pas exactement à ce qui était affiché sur mon écran et manque un peu de "peps".
J'ai demandé quel pouvait être le profil de leur imprimante mais je n'ai pas eu de réponse.
D'où ma question : comment optimiser un développement pour un tirage papier ?
Je connais les formats, résolutions et dimensions nécessaires mais c'est au niveau du rendu final qu'est mon problème. Faut-il augmenter la saturation et sur quelles couleurs, le contraste local ?...

Je n'ai pas trouvé de réponse ni dans le blog ni dans le forum.
Merci d'avance
Répondre
#2
C'est une question complexe!

La première chose est de choisir un bon imprimeur. Je ne pense pas que MonAlbumPhotos.fr soit top en qualité, c'est plutôt du grand publique à prix compétitif. Le papier je ne sais pas et s'il ne propose pas de profil...

De mon coté j'ai testé Photoweb qui avait eu une très bonne note "qualité" dans un article Chasseur d'Images qui comparait les différents services. Je pense aussi que Blurb est d'un très bon niveau.

Pour le rendu identique, avec un profil éditeur et du softproofing c'est déjà ça, mais pas de miracle même dans ce cas tu auras des différences car il y a beaucoup de paramètre, comme l'éclairage de développement et celui de visualisation papier. Il faut aussi bien vérifier que toutes les couleurs sont bien dans le gammut.

J'ai une imprimante Edpson 3880 et tout est calibré... Mais même dans un environnement local et bien contrôlé je ne suis jamais arrivé à un résultat 100% identique papier et écran. Je ne suis pas un labo professionnel tout simplement Smile Mes sorties sont OK pour moi, c'est déjà pas mal.

Voilà quelques éléments de réponse, mais rien n'est simple lorsqu"il s'agit d'impression.
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre
#3
Merci pour la réponse, je vais explorer les propositions commerciales de ces 2 sites. J'ai vu que Blurb donnait le profil ICC de ses imprimantes, comment l’utiliser avec DT ?
J'ai lu "quelque part mais je ne sais plus où" que pour des fichiers à imprimer il fallait "pousser" la saturation globale ?
Est-il utile et efficace de les garder en TIF dans le montage du livre (pour un projet bâti en PDF avec Scribus (format A4 ou similaire) ?
Répondre
#4
> J'ai vu que Blurb donnait le profil ICC de ses imprimantes,

Photoweb aussi.

> comment l’utiliser avec DT ?

C'est expliqué là:
https://darktable.gitlab.io/doc/fr/darkr...#softproof

> J'ai lu "quelque part mais je ne sais plus où" que pour des fichiers à imprimer il fallait "pousser" la saturation globale ?

Non.

> Est-il utile et efficace de les garder en TIF dans le montage du livre (pour un projet bâti en PDF avec Scribus (format A4 ou similaire) ?

Non.
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre
#5
Avant toute chose, il faut savoir que les moyens de simulation du tirage papier sur l'écran (= épreuvage écran, ou softproofing en anglais) sont loin d'être parfaits et sont très impactés par l'éclairage ambiant. C'est un sujet de recherche encore actif, et les corrections mathématiques les plus précises dont on dispose actuellement (CIECAM02 et suivants) pour faire cette simulation ne sont pas disponibles sur Linux ni dans darktable (ça se trouve dans Mac OS et Windows 10).

Donc, même avec un écran étalonné et un profil d'imprimante, on ne fera pas de miracle. L'écran ne sera jamais exactement le tirage.

Normalement, il n'y a pas besoin de faire de correction spéciale pour le tirage. Le principe même de l'étalonnage écran et imprimante repose sur l'objectif d'avoir le même rendu peu importe le medium de sortie, du moment que c'est étalonné/calibré correctement, et que le résultat de l'étalonnage est enregistré dans un profil correct et correctement utilisé dans les logiciels de la pile graphique (éditeur photo, pilote de carte graphique).

Quand on passe d'une sortie à une autre (écran, imprimante), ce qu'il faut vérifier, c'est la façon dont la conversion de couleur tient compte du redimensionnement du gamut, pour les espaces de couleur plus réduits. Encore là, beaucoup de gens, y compris ici, se prennent la tête pour rien en essayant d'éviter les dépassement de gamut en désaturant dans le logiciel. C'est inutile. LittleCMS se charge de faire ce boulot en utilisant différentes intentions de rendu (perceptuel, relatif, saturation ou absolu) qui permettent de gérer ce redimensionnement de gamut en priorisant la conservation de la couleur, de la luminosité ou des écarts relatifs entre couleurs.

Donc a priori, rien ne sert de s'alarmer. Active LittleCMS, fait ta retouche normalement, et exporte avec le bon profil, ça suffit.

Par contre, comme je le répète souvent, il faut impérativement avoir une interface graphique gris 50 à 75 % (minimum), car l'interface par défaut (sombre) de dt créée des illusions d'optique qui peuvent conduire à mal évaluer la luminosité, le contraste et la saturation de l'image, et à se retrouver avec de mauvaises surprises au tirage, qui n'est pas rétro-éclairé, et souvent affiché dans un passe-partout clair.
Aurélien, photographe portraitiste sur Nancy-Metz
Développeur de filmique.
Dérive de couleur ? Désactivez courbe de base.
Halos clairs ? Désactivez ombres & hautes lumières.
Répondre
#6
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 !
Répondre
#7
@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). Et surtout ne pas oublier que parmi les 4 rendu, uniquement deux sont utilisables en photo (perceptif et colorimétrie relative). L'algo colorimétrie absolu n'est pas normalisé et fortement déconseillé pour les photographes, je ne parle pas de l'algo saturation qui lui conserve la saturation (comme le nom l'indique) mais pas la teinte!
--
Pascal - GNU/Debian (sid) - version darktable git/master
http://photos.obry.net
Répondre
#8
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.
Le softproofing est nécessaire précisément pour vérifier les effets des intentions de rendu et à choisir celle qui convient le mieux à l'image même si lcms fait très bien son travail. Au fait, lcms ou lcms 2 ?
En mode softproofing, certains logiciels affichent un fond blanc autour de l'image pour une meilleure représentation visuelle.

Pour ceux qui ne seraient pas vraiment au fait de ce que font les deux intentions de rendu indiquées par Pascal (les deux autres sont à oublier définitivement pour la photo ...) :
Le mode colorimétrie relative fait glisser les couleurs hors gamut vers leurs valeurs max dans le gamut (donc imprimables) sans toucher aux autres couleurs reproductibles par l'imprimante. Le mode perception fait glisser l'ensemble des couleurs dans le gamut du papier. Cela peut donner une légère désaturation de l'ensemble de l'image. En fait dans ce mode, aucune couleur n'est reproduite à l'identique même celles qui pourraient l'être.

D'où l'importance de pouvoir le vérifier si, par exemple, l'image comporte beaucoup de nuances hors gamut.
Windows 10 Pro 1903 - dt 2.7 dev
Répondre
#9
(07-05-19, 09:57)pascalG a écrit : 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.

(06-05-19, 19:30)pascal a écrit : @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.

(06-05-19, 19:04)jpg54 a écrit : 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.
Aurélien, photographe portraitiste sur Nancy-Metz
Développeur de filmique.
Dérive de couleur ? Désactivez courbe de base.
Halos clairs ? Désactivez ombres & hautes lumières.
Répondre
#10
(07-05-19, 10:49)aurelienpierre a écrit : jpg54Aurélien, il me semble que RawTherapee utilise le CIECAM02 : https://rawpedia.rawtherapee.com/CIECAM02/fr
[quote pid='32622' dateline='1557165895']
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.
[/quote]

Et c'est pas la seule chose qui fait rager. Comme je l'ai dit par ailleurs :  on peut regarder dans l'assiette du voisin. Je ne changerais pas pour RawTherapee mais je suis toujours ce qui y est fait notamment la branche non officielle LocalLab basée sur les U-Points.
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)