12 réponses à “Pkpgcounter: calculer le taux d’encrage”

1. tamere le 17 avril 2008 11:09

   Merci pour cet article. Juste un commentaire pour mettre en garde contre l’utilisation d’une résolution trop importante (‘–resolution 600′ par exemple), qui peut conduire à de très très fortes consommations de ressources CPU et mémoire, pour un gain en précision sans doute relativement faible dans le cas général, c’est pourquoi la résolution par défaut est 72 dpi.

2. FeIZocE le 17 avril 2008 11:54

   C’est noté pour la résolution. Pour ma part, je ne vais jamais si haut pour l’impression. Par contre, à l’inverse je trouve que, s’agissant d’un document destiné à l’impression, la résolution par défaut de 72 dpi est un choix qui se discute: les imprimantes de bureau ont une résolution standard de 150 dpi, et c’est bien là le minimum pour une impression pas trop pourrie.

   Autre question: il me semble que l’encrage total calculé par pkpgcounter ne dépasse pas les 100%. Comment cela se fait-il? Par exemple, un document en C:15 M:30 J:45 N: 60 dépasse allègrement les 100% de taux d’encrage. Certains profils couleur sont même contraints de limiter les % de sortie.

   Et la dernière: avez-vous déjà pensé à une intégration dans Scribus?

   Si tu préfères me répondre par mail… feiz(arobase)calcyum(point)org

3. tamere le 23 avril 2008 20:53

   Le code utilisé est ci-dessous, c’est une traduction en Python du code C original provenant du projet PrintBill:

    - CUT - cyan = magenta = yellow = black = 0 for (r, g, b) in img.getdata() :

    if r == g == b :    black += 255 - r  else :    cyan += 255 - r    magenta += 255 - g    yellow += 255 - b

   return {"C":100.0*(cyan/255.0)/nbpix,

       "M":100.0*(magenta/255.0)/nbpix,     "Y":100.0*(yellow/255.0)/nbpix,     "K":100.0*(black/255.0)/nbpix,     }

   - CUT - Pour ce qui est de l’intégration dans Scribus, je n’ai pas assez de mains pour m’en occuper, mais pkpgcounter est utilisable sous forme de librairie Python donc je pense que ça doit être relativement facile à faire.

4. tamere le 23 avril 2008 20:54

   fais yeche ça apparait de manière dégueu…

5. FeIZocE le 24 avril 2008 9:35

   fais yeche ça apparait de manière dégueu…

   C’est parce que les commentaires sont asujettis à la syntaxe wiki. J’ai repris les balises

   Je suis graphiste, pas codeur, mais comment se fait-il que le pourcentage ne soit pas propre à chaque couleur? J’ai pourtant l’impression que ton script attribue bien une valeur maximale de 100 pour chaque encre CMJN, mais lors de l’utilisation du script, ce pourcentage devient global.

6. tamere le 24 avril 2008 12:53

   Et bien justement moi je ne suis pas graphiste, et le développeur du code original non plus, donc il est possible que l’on aie tout faux avec le calcul ci-dessus. Regarde le fichier pkpgcounter/tests/colors.pdf qui semble correct de mon point de vue, mais peut être que l’on ne mesure pas ce que l’on devrait mesurer.

7. FeIZocE le 24 avril 2008 23:46

   Je crois que je viens de comprendre. Dans ton fichier test, les poucentages dépassent allègrement les 100%, p. ex. les taux de cyan et de jaune pour le recréer le vert sont tous deux de 100%. J’ai refait le test depuis un fichier Postscript généré par Scribus, en créant un vert c:100 j:100. Ce taux de 100% pour chacune des deux encres est respecté si l’alplat couvre toute la feuille. En revanche, si le bloc couleur ne couvre que 30% de la feuille, les deux valeurs cyan et jaune seront aussi de 30%. Le calcul de pkpgcounter tient compte de la surface imprimée.

   La notion de taux d’encrage en imprimerie est différente: il s’agit de la densité d’une couleur. Une couleur dite « quadri » sera composée de divers pourcentages de cmjn, et quelle que soit la surface imprimée, ce taux d’encrage est fixe. Si un noir 95-80-80-90 ne représente que 10% de la feuille, certaines presses produiront un document maculé là où le noir est trop profond car contenant un pourcentage trop élevé de cmjn. D’où l’utilité de connaître en amont le taux d’encrage des couleurs qui composent le document.

   Tu penses qu’il serait possible de passer outre l’élément « couverture de la page », dans votre script? Ou, car il est quand même bien utile, de le compléter par un calcul du taux d’encrage par couleur?

8. tamere le 25 avril 2008 8:40

   Oui effectivement pkpgcounter tient compte de la surface de papier réellement imprimée, car il est principalement utilisé dans mon logiciel de quotas d’impression PyKota pour refacturer la quantité d’encre consommé, pas l’intensité de chaque couleur.

   Il doit être possible de modifier le code ou d’ajouter une option supplémentaire sur la ligne de commande (et dans la librairie) pour faire ce que tu souhaites, encore que je ne sois pas trop sûr de moi : peut être qu’il suffit d’enlever la division par le nombre total de pixels de la page dans le code ci-dessus.

9. FeIZocE le 25 avril 2008 14:24

   C’est à tester donc. Le souci c’est que j’y connais rien. Tu crois que ton codeur pourrait envisager de travailler dessus? N’hésite pas à lui proposer mon mail. Si ça se concrétise, ce serait un élément à inclure dans la gestion de la couleur des logiciels libres.

10. tamere le 29 avril 2008 0:29

    Désolé si ce n’était pas clair : je ne suis pas l’auteur du code original de PrintBill, c’est Daniel Franklin qui est prof dans une université australienne. Par contre je suis bien celui de pkpgcounter, et à ce titre j’ai réalisé le portage C vers Python du code de calcul du taux de couverture d’encre. Malheureusement je n’ai pas trop de temps à consacrer à une telle évolution de pkpgcounter pour l’instant (j’ai deux bugs en attente de correction depuis Décembre 2007), cela dit si pour un ensemble de pixels codés en (R,G,B) (pas vraiment le choix) tu as la formule qui te donne le résulat que tu souhaites je veux bien l’implémenter et ajouter l’option qui va bien…

11. FeIZocE le 29 avril 2008 9:29

    D’accord, je vais creuser ce filon sur LinuxGraphic, ça devrait les intéresser aussi
    Bon courage pour la correction de tes bugs

12. tamere le 30 avril 2008 20:47

    OK, si tu donnes suite merci d’utiliser la liste de diffusion de PyKota à laquelle tu peux t’abonner sur http://cgi.librelogiciel.com/mailman/listinfo/pykota

Déposez un commentaire