Hébergeur de site web qui prend en charge les espaces couleur ?

[remico]

J'ai retrouvé le ProPhotoRGB.icm de Kodak dans un de leur logiciel DCS Photo desk, il est tout petit 996 octet.

http://www.kodak.com/global/en/professional/support/DCS/dcsRegister/downloadIndex.jhtml

L'Adobe RGB est disponible chez Adobe et pour le XYZ c'est sur le site de l' International Color Consortium dispo en version D50, D55 ou D65.
http://www.color.org/XYZprofiles.xalter

C'est l'option -o qui permet de choisir l'espace couleur de sortie pour dcraw, l'espace de traitement interne étant xyz.

Les éditeurs graphique permettent de choisir l'espace de travail.

Je me suis amusé avec Gimp 2.6 en mode Lab à faire un dégradé sur chaque canal, puis à convertir en SRGB.
Dans les quatre imagettes ci-dessous il n'y a que le dégradé du canal L qui a tourné, les autres canaux n'étant pas modifiés.
Il y a des bizarreries je ne saurais pas dire si cela vient de la conversion, du manque de précision de l'outil dégradé de Gimp, ou des couleurs que le mode Lab supporte mais pas le sRGB.

[juno44]

Ca, ca me dépasse !

[remico]

C'est pas dur pourtant j'explique mal c'est tout, en mode Lab avec Gimp on a aucune notion de couleurs juste des canaux gris. Sur chaque canal gris j'ai appliqué un dégradé qui va du noir(mini) au blanc(maxi).

Avec les deux canaux de teinte  dégradés, on a toutes les couleurs, bleu à droite jaune à gauche, rouge en haut et vert en bas, mais pas toutes les luminances. Donc j'avais fait aussi un dégradé sur le canal L que j'ai fait tourner dans les 4 positions possibles pour avoir toutes les combinaisons.
J'aurais eu un résultat différent en imprimant directement depuis le mode Lab plutôt qu'en convertissant en sRVB.

Je l'ai refait ci-dessous avec un calque blanc pour le canal L au lieu de dégradé.

extrait du pdf de la page précédente :

L'espace CIE-Lab a été créé en 1976 par la CIE. Il a les mêmes propriétés que l'espace X,Y,Z :
espace normalisé indépendant du matériel,

séparation de la luminance (L) et de la chrominance (a,b),

possibilité de représenter toutes les couleurs visibles par addition de 3 composantes L, a, b

Il a été conçu pour ajouter la propriété de conservation de la différence perceptuelle : la distance entre 2 points dans l'espace Lab est proportionnelle à la différence perçue entre les 2 couleurs correspondantes. Cette propriété est particulièrement intéressante lorsqu'on souhaite remplacer une couleur par une couleur proche.

Détail des 3 composantes:

L: luminance varie entre 0 et 100

a : variations sur un axe rouge-vert : varie entre -60 et +60

b : variations sur un axe bleu -jaune : varie entre -60 et +60

Cet espace est le plus utile lorsqu'on veut assurer la fidélité des couleurs, restreindre le gamut au minimum et rester indépendant des matériels et logiciels de la chaîne de traitement.

                             ******************

[OuiOuiPhoto]

Il est 16 bits The GIMP  car si on veut faire un des mires de test style "Granger" ce n'est pas préférable d'être en 16 bits ?

[remico]

Bien vu merci j'ai retrouvé un passage sur wikipedia qui confirme les pertes lors de la conversion en 8bits :
https://en.wikipedia.org/wiki/Lab_color_space
Because Lab space is much larger than the gamut of computer displays, printers, or even human vision, a bitmap image represented as Lab requires more data per pixel to obtain the same precision as an RGB or CMYK bitmap. In the 1990s, when computer hardware and software were limited to storing and manipulating mostly 8-bit/channel bitmaps, converting an RGB image to Lab and back was a very lossy operation. With 16-bit/channel and floating-point support now common, the loss due to quantization is negligible.

Et en 2015 Gimp est toujours en 8bits, sauf pour la version de développement ou la précision monte non seulement à 16bit entier mais à 8,16,32 ou 64bit flottants. En 16bit entier effectivement je n'ai plus de pertes de conversion.

Pour revenir au sujet, il vaut mieux faire la conversion sRGB au dernier moment et faire tous les traitements dans un espace le plus grand possible.

Grâce au mot clef granger (+test chart) que je ne connaisais pas j'ai trouvé  un article ancien de 4 pages qui démontre que dans certains cas on a avantage à utiliser le mode de rendu colorimétrie relative qui peut clipper quelques valeurs hors gamut plutôt que perceptuel généralement retenu qui va tout modifier pour quelques valeurs hors gamut :
http://creativepro.com/out-of-gamut-realizing-good-intentions-with-rendering-intents/

Et pour les imprimantes les explications de certaines dérives :
http://www.brucelindbloom.com/MunsellCalcHelp.html#BluePurple

[juno44]

Bon, j'ai tout converti en sRGB. On peut toujours me contacter pour plus de précisions. Fin de l'histoire.

[restoc]

Je vais parler de la "gestion" du profil par Piwigo (puisque je travaille sur Piwigo).

Pour simplifier, le profil colorimétrique est une métadonnée, c'est à dire une information embarquée dans la photo. Piwigo ne modifie jamais la photo originale que vous lui donnez. Jamais (sauf demande explicite de l'utilisateur). Ensuite Piwigo génère des "tailles multiples" (miniature, S, M, L, XL...) pour l'affichage dans les pages. Au-dessus d'une certaine taille en pixels (configurable), Piwigo garde l'intégralité des métadonnées, donc le profil colorimétrique.

Les visiteurs voient donc s'afficher une image contenant un profil colorimétrique. Si vous n'utilisez pas sRGB, dans 95% des cas, les visiteurs verront des couleurs altérées, car ils n'ont ni le matériel adapté ni la bonne version du bon navigateur web du bon système d'exploitation. Conclusion : si vous voulez que vos visiteurs voient des bonnes couleurs (disons "acceptables"), il faut publier en sRGB, car c'est la norme supportée par tous les navigateurs web. Voilà tout simplement pourquoi pas mal de solutions d'hébergement de photo forcent la conversion en sRGB. Piwigo ne le fait pas, mais on recommande fortement de publier en sRGB.

Ceci étant dit, il est parfaitement légitime de vouloir publier du CMYK ou du adobeRGB ou <mettre ici votre profil colorimétrique favori>. Nous travaillons en ce moment sur une nouvelle fonctionnalité : le multi-format. Une même photo pourra être proposée en plusieurs versions. Par exemple en sRGB, adobeRGB et CMYK (et RAW). Les visiteurs verront dans leur navigateur web la photo de référence (si possible en sRGB, si vous avez suivi le paragraphe précédent) et pourront télécharger les autres formats.

Plegall Le mieux est que Piwigo reste transparent aux profils et se contente de dire que le rendu de la photo vue dépendra de l'espace dans laquelle est calculée la photo ( pas seulement taggée hein !)  et de ce que fait ou ne fait pas son navigateur pour la gestion des couleurs.
Et de recommander srgb pour les utilsateurs  voulant être le plus généralement compatible web et de laisser ceux qui veulent s'échanger en Argb en connaissance de cause avec des écrans adhoc le faire sans intervention du site également.
Sinon ce sera un billard à bandes multiples ingérable au niveau de l'hébergement à mon humble pratique (Voir Googlephoto très interventioniste  du genre catastrophique).

On voit déjà une aproximation dans votre :la confusion entre la metadata, le profil et les datas elles mêmes: selon le workflow logiciel parfois hétéroclite  on peut avoir l'espaceoriginal à lapdv,eventuellement un profil de l'APN en plus, puis l'espace couleur de calcul dans le logiciel, puis profil de sortie simplement taggé  mais  des data qui ont été converties ou pas. !!!

Le standard des metadata actuelles ne retrace pas forcémment la cohérence de ce qui a été fait le long de la chaine. Il vaut donc mieux laisser la responsabilité à l'extèrieur de l'hébergement faute d'informations complètes pour rendre le service de gestion des couleurs.AMHA

[plegall]

 [at] restoc

Alors c'est bien ce que fait Piwigo : aucune conversion de profil colorimétrique. Le seul "soucis" qu'on peut rencontrer c'est s'il y a un profil autre que sRGB, les miniatures (en dessous de ~500x500 pixels) vont mal s'afficher. C'est un paramètre de configuration, il suffit de désactiver ce système de suppression des métadonnées pour les miniatures et le problème disparaît (mais les miniatures vont peser nettement plus lourd).

$conf['derivatives_strip_metadata_threshold'] = 0;

[restoc]

[at] restoc

Alors c'est bien ce que fait Piwigo : aucune conversion de profil colorimétrique. Le seul "soucis" qu'on peut rencontrer c'est s'il y a un profil autre que sRGB, les miniatures (en dessous de ~500x500 pixels) vont mal s'afficher. C'est un paramètre de configuration, il suffit de désactiver ce système de suppression des métadonnées pour les miniatures et le problème disparaît (mais les miniatures vont peser nettement plus lourd).

$conf['derivatives_strip_metadata_threshold'] = 0;

Pourquoi les miniatures auraient elles un comportement différent d'une autre image ? Cà peut être intéressant de comprendre pour ne pas effectivement avoir une miniature avec un rendu et l'image pleine page.

[Verso92]

[at] restoc

Alors c'est bien ce que fait Piwigo : aucune conversion de profil colorimétrique. Le seul "soucis" qu'on peut rencontrer c'est s'il y a un profil autre que sRGB, les miniatures (en dessous de ~500x500 pixels) vont mal s'afficher. C'est un paramètre de configuration, il suffit de désactiver ce système de suppression des métadonnées pour les miniatures et le problème disparaît (mais les miniatures vont peser nettement plus lourd).

$conf['derivatives_strip_metadata_threshold'] = 0;

C'est curieux : j'ai un comportement différent en fonction de la visualisation de l'image, dans la page ou affichée dans une fenêtre...
http://verso.fab.free.fr/picture.php?/3185/category/143

[plegall]

Pourquoi les miniatures auraient elles un comportement différent d'une autre image ? Cà peut être intéressant de comprendre pour ne pas effectivement avoir une miniature avec un rendu et l'image pleine page.

Parce que, comme je l'avais dit dans mon précédent message :

Ensuite Piwigo génère des "tailles multiples" (miniature, S, M, L, XL...) pour l'affichage dans les pages. Au-dessus d'une certaine taille en pixels (configurable), Piwigo garde l'intégralité des métadonnées, donc le profil colorimétrique.

Pour le dire autrement : en dessous d'une certaine taille (par défaut, c'est environ 500x500 pixels), Piwigo supprime les métadonnées pour alléger le fichier. Comme le profil est dans les métadonnées, on perd l'info. Donc l'affichage est altéré. Je répète : cela n'affecte que les utilisateurs qui n'utilisent pas sRGB et cela se modifie dans la configuration.

[plegall]

C'est curieux : j'ai un comportement différent en fonction de la visualisation de l'image, dans la page ou affichée dans une fenêtre...

pwg_high ? Quelle vieille version de Piwigo utilises tu ?!? Là comme ça je ne sais pas quel outil/méthode tu as utilisé pour ajouter cette photo. Mais à un moment, le profil a dû être supprimé de la photo "taille web" (ce terme n'est plus utilisé depuis Piwigo 2.4, sorti en 2012, il y a près de 4 ans).