30-10-18, 09:44
> Ah ben ça! J'ai suivi ton conseil (exporter en sRGB et en adobe RGB). Quand j'ouvre les 2 photos par le visionneur d'images ubuntu, elles sont semblables.
OK, jusque là tout va bien. Les images sont codées différemment (par exemple, un vert moyen codé en (0, 128, 0) en sRGB sera codé en (36, 128, 5) en AdobeRGB), mais le viewer fait la conversion sRGB/AdobeRGB vers l'espace de l'écran correctement, donc le résultat final est le même (ou presque).
> Mais avec shotwell je retrouve exactement les différences dont j'ai parlé, celle exportée en adobeRGB étant la même que sous DT, celle exportée en sRGB étant beaucoup plus saturée.
Donc a priori shotwell ne gère pas correctement les couleurs. Ce que fait un viewer « de base » c'est qu'il ignore l'espace des couleurs de l'image et envoie directement à l'écran les données de l'image. Donc sur mon exemple ci-dessus, (0, 128, 0) en sRGB (= « le vert le plus saturé que tu saches afficher, en luminance moyenne ») et (36, 128, 5) en AdobeRGB (= « un vert assez saturé, mais mets quand même pas mal de rouge et un peu de bleu dedans pour désaturer »).
Un autre test encore plus flagrant : exporter en espace BRG (attention, uniquement pour les tests, ne SURTOUT pas utiliser ça en vrai). Les images exportées s'afficheront correctement sur les viewers avec gestion de couleurs, mais permutent les canaux R, G et B sinon (= les couleurs s'affichent vraiment n'importe comment !). Un test rapide montre que shotwell ne sait effectivement pas afficher ces images.
=> si tu veux gérer tes couleurs un peu finement, oublie Shotwell.
> celle exportée en adobeRGB étant la même que sous DT
Ça c'est suspect. La plupart des écrans ont un rendu proche de sRGB (pour une certaine définition de « proche », hein ...), donc le sRGB sans gestion des couleurs devrait s'afficher mieux que le AdobeRGB sans gestion des couleurs. Sauf si tu as un écran wide gamut qui couvre correctement AdobeRGB.
> Laquelle est la bonne, ah ah!? Surtout, laquelle voient mes clients?
Ça dépend de qui sont tes clients.
Si tu vises monsieur tout le monde avec un écran lambda pas calibré, alors sRGB est le bon choix. Ça te limite un peu (les couleurs très saturées seront tronquées à l'export), mais ces limitations correspondent en gros aux limitations des écrans de tes clients, donc au final ça n'est pas une vrai limitation. Et si le client regarde l'image avec un viewer non-color-managé (shotwell ...), il aura un résultat correct.
Si ton « client » est un imprimeur pro, alors AdobeRGB a une valeur ajoutée.
Pour te rassurer sur l'(in)utilité d'AdobeRGB dans pas mal de cas, lire par exemple https://kenrockwell.com/tech/adobe-rgb.htm (bon, l'auteur est loin d'avoir raison sur tout et il aime la provoc, ne pas tout prendre pour argent comptant).
OK, jusque là tout va bien. Les images sont codées différemment (par exemple, un vert moyen codé en (0, 128, 0) en sRGB sera codé en (36, 128, 5) en AdobeRGB), mais le viewer fait la conversion sRGB/AdobeRGB vers l'espace de l'écran correctement, donc le résultat final est le même (ou presque).
> Mais avec shotwell je retrouve exactement les différences dont j'ai parlé, celle exportée en adobeRGB étant la même que sous DT, celle exportée en sRGB étant beaucoup plus saturée.
Donc a priori shotwell ne gère pas correctement les couleurs. Ce que fait un viewer « de base » c'est qu'il ignore l'espace des couleurs de l'image et envoie directement à l'écran les données de l'image. Donc sur mon exemple ci-dessus, (0, 128, 0) en sRGB (= « le vert le plus saturé que tu saches afficher, en luminance moyenne ») et (36, 128, 5) en AdobeRGB (= « un vert assez saturé, mais mets quand même pas mal de rouge et un peu de bleu dedans pour désaturer »).
Un autre test encore plus flagrant : exporter en espace BRG (attention, uniquement pour les tests, ne SURTOUT pas utiliser ça en vrai). Les images exportées s'afficheront correctement sur les viewers avec gestion de couleurs, mais permutent les canaux R, G et B sinon (= les couleurs s'affichent vraiment n'importe comment !). Un test rapide montre que shotwell ne sait effectivement pas afficher ces images.
=> si tu veux gérer tes couleurs un peu finement, oublie Shotwell.
> celle exportée en adobeRGB étant la même que sous DT
Ça c'est suspect. La plupart des écrans ont un rendu proche de sRGB (pour une certaine définition de « proche », hein ...), donc le sRGB sans gestion des couleurs devrait s'afficher mieux que le AdobeRGB sans gestion des couleurs. Sauf si tu as un écran wide gamut qui couvre correctement AdobeRGB.
> Laquelle est la bonne, ah ah!? Surtout, laquelle voient mes clients?
Ça dépend de qui sont tes clients.
Si tu vises monsieur tout le monde avec un écran lambda pas calibré, alors sRGB est le bon choix. Ça te limite un peu (les couleurs très saturées seront tronquées à l'export), mais ces limitations correspondent en gros aux limitations des écrans de tes clients, donc au final ça n'est pas une vrai limitation. Et si le client regarde l'image avec un viewer non-color-managé (shotwell ...), il aura un résultat correct.
Si ton « client » est un imprimeur pro, alors AdobeRGB a une valeur ajoutée.
Pour te rassurer sur l'(in)utilité d'AdobeRGB dans pas mal de cas, lire par exemple https://kenrockwell.com/tech/adobe-rgb.htm (bon, l'auteur est loin d'avoir raison sur tout et il aime la provoc, ne pas tout prendre pour argent comptant).