Boaf, le Lab comme espace colorimétrique sur le serveur X, je n'y crois pas trop non plus. Juste pour ceux qui débarquent, une gestion colorimétrique n'est ni plus ni moins qu'un moyen de garantir que les couleurs s'afficheront pareilles d'un périphérique à l'autre (camera, scanner, écran, imprimante, ....).
Je ne pense pas qu'il ait besoin que le serveur X sache gérer le Lab en interne (X sait d'ailleur déjà convertir le Lab => RGB), pour faire une bonne gestion colorimétrique. On peut largement le faire au niveau applicatif.
Genre avant d'afficher une image, l'appli applique un profil d'entrée qui converti le RGB/CMYK en Lab, puis un autre profil de sortie en fonction du périphérique (écran / imprimante), qui convertira le Lab en RGB/CMYK. Ca à l'air beaucoup, mais des libs comme littlecms font ça en 2/3 lignes de code C et en un clin d'oeuil, même sur la dernière des bouses. Avec ça, X n'a absolument pas besoin de gérer le Lab.
Le vrai problème est de générer (ou récupérer) ces foutus profils ET les conditions techniques de leur utilisation (genre pour une imprimante, quel mode d'impression, quelle réduction d'encrage, linéarisation, ...). Changez un paramètre, et vous pouvez regénérer votre profil. Sauf que générer un profil, c'est :
1. Délicat, il faut savoir ce qu'on fait.
2. Il faut du matos qui coute la peau du cul (spectro), en plus de logiciels spécialisés.
Même si dans l'idéal, les constructeurs pourraient fournir ces profils, la plupart du temps, ils sont noyés dans les drivers pour Windows et Mac OS, avec une licence proprio évidemment :-(
Et puis bon, garantir des couleurs identiques entre une imprimante et un écran, je n'y crois pas non plus, tant les gamuts sont différents. Dans ce cas, autant se contenter d'approximation, au lieu de sortir l'artillerie lourde.
[^] # Re: Le flou
Posté par pierthi . En réponse au journal Quel logiciel manque t-il sur Linux ?. Évalué à 2.
Je ne pense pas qu'il ait besoin que le serveur X sache gérer le Lab en interne (X sait d'ailleur déjà convertir le Lab => RGB), pour faire une bonne gestion colorimétrique. On peut largement le faire au niveau applicatif.
Genre avant d'afficher une image, l'appli applique un profil d'entrée qui converti le RGB/CMYK en Lab, puis un autre profil de sortie en fonction du périphérique (écran / imprimante), qui convertira le Lab en RGB/CMYK. Ca à l'air beaucoup, mais des libs comme littlecms font ça en 2/3 lignes de code C et en un clin d'oeuil, même sur la dernière des bouses. Avec ça, X n'a absolument pas besoin de gérer le Lab.
Le vrai problème est de générer (ou récupérer) ces foutus profils ET les conditions techniques de leur utilisation (genre pour une imprimante, quel mode d'impression, quelle réduction d'encrage, linéarisation, ...). Changez un paramètre, et vous pouvez regénérer votre profil. Sauf que générer un profil, c'est :
1. Délicat, il faut savoir ce qu'on fait.
2. Il faut du matos qui coute la peau du cul (spectro), en plus de logiciels spécialisés.
Même si dans l'idéal, les constructeurs pourraient fournir ces profils, la plupart du temps, ils sont noyés dans les drivers pour Windows et Mac OS, avec une licence proprio évidemment :-(
Et puis bon, garantir des couleurs identiques entre une imprimante et un écran, je n'y crois pas non plus, tant les gamuts sont différents. Dans ce cas, autant se contenter d'approximation, au lieu de sortir l'artillerie lourde.