La statue provient du pont qui est situé à droite dans l'image (on ne le voit donc pas dans le zoom).
L'image d'origine traitée est de résolution supérieure à celle du .gif présenté ici.
Oui c'est exact, en fait le filtre génére effectivement un nouveau calque qui s'ajoute à l'image.
L'exemple ici n'est peut-être pas très bien choisi. En ne gardant que le calque généré avec des paramètres sympas, on peut quand même avoir un fond de type Bokeh (qui fait un peu synthétique mais sympa quand même).
Oui effectivement depuis quelques jours, l'accès à l'API flattr a l'air un peu bloquant.
Du coup je vais l'enlever au moins temporairement (parce que c'est pas pour ce que ça sert…)
C'est juste, mais ma question portait plus sur l'expérience utilisateur.
Avec ton exemple, il va certes attendre 140 minutes au lieu de 160, mais ça reste quand même 140 minutes :)
Un utilisateur non expérimenté risque de faire une drôle de tête si sa machine mets trop de temps à recalculer un rendu alors qu'il a juste changé le paramètre de variance de son flou gaussien, appliqué en tout début de pipeline (qui est un opérateur en soi immédiat à recalculer quand c'est appliqué "à part").
D'où ma question. Ca me parait pas si trivial de rendre fluide le tout.
Dans le futur, est-ce que chaque opérateur de traitement de GIMP sera un noeud GEGL ?
C'est ce qui a l'air d'être préconisé si on écoute les développeurs de GIMP actuellement.
Si c'est le cas, ce genre de problème pourrait rapidement se poser pour les noeuds un peu "lourds" à calculer, et également pour le "preview on canvas".
Est-ce qu'il y aura possibilité pour un noeud de se signaler comme étant gros consommateur de ressources ? Avez vous prévu des méchanismes spéciaux pour gérer ce genre de noeuds ?
Petite question à ce sujet… L'édition non destructrice est intéressante, mais il me semble qu'elle se limite quand même à des filtres de traitement d'images "basiques", rapides à calculer. De même pour la fonctionnalité "preview on canvas" qui est poussée en avant pour les prochaines releases avec GEGL.
On imagine mal en effet devoir attendre 15 minutes (au hasard) le recalcul d'un rendu après avoir changé un paramètre d'un des filtres (parce que le graphe comprend un filtre très long à calculer, qui a été appliqué à la fin). Avez vous prévu quelque chose de spécial dans ce cas ?
Si non, cela veut-il dire que les opérateurs GEGL seront de toute façon limités à des traitements basiques, si on veut les rendre utilisables en pratique ?
Merci.
Je ne sais pas si ça peut aider, mais j'ai écrit deux articles sur la façon dont fonctionne le processus d'extraction avant-plan/arrière plan dans G'MIC, et c'est exactement la même façon de faire que pour la colorisation de comics, sauf qu'au lieu d'avoir deux labels "Avant-plan" et "Arrière-plan", tu as un nombre plus grand de labels, chacun associé à une couleur pour le remplissage. C'est sur mon "début" de blog:
J'ai résolu le problème du git, effectivement ça prenait un peu trop de place.
Les sources seules (sans les fichiers resources, binaires, qui prenaient bcp de place) sont disponibles sur un repo 'minimal' :
Pourtant, pour justifier le choix d’un seul fichier, tu utilises des arguments comme « ça m’évite de lancer un grep ». À minima, évite cet argument car c’est forcément le genre de réponses qu’il amène.
Ce n'est pas un argument que j'ai utilisé pour justifier ce choix. C'est un argument que j'ai utilisé pour contredire Michel: S'y retrouver dans le code d'un gros fichier n'est pas plus difficile que dans pleins de petits, puisqu'au final on peut fait une recherche plutôt qu'un grep. Donc, l'argument "pleins de petits fichiers c'est mieux pour s'y retrouver dans l'organisation d'un code" avancé par Michel, est faux. Au final, ça revient au même. Voilà ce que j'ai dit.
Par contre, quand on dit « ça te coupe de contributeurs potentiels », oui, je pense sérieusement que c’est le cas. J’ai parcouru rapidement le source de CImg, c’est typiquement le genre de code dans lequel je n’ai pas spécialement envie de mettre les mains (bon, après, le fait que le traitement d’image ne soit pas du tout mon domaine n’aide pas non plus)
Ca, je dirais, c'est ton problème. Est-ce que je me suis plaint de pas avoir assez de contributeurs ? Jamais. Faut croire que pas mal de gens sont pas apeurés par la première originalité venue (ou ont assez d'expérience pour se rendre compte que ça n'a aucune incidence sur la qualité du code). Franchement, lire des commentaires du niveau de celui de xcomcmdr (plus haut), c'est à pleurer. A croire qu'il n'a jamais rencontré autre chose qu'un "Hello World" de toute sa vie.
Je crois que si cette architecture de code te convient, c’est que tu n’es pas un être humain normal
Je suis tout à fait normal, et en tant qu'être humain normal, j'essaye de me contrôler et pas crier au loup dès que je vois quelque chose d'un peu différent de ce que j'ai l'habitude de faire par moi-même. Surtout si ça touche un point de vue seulement "technique". J'essaye d'abord de comprendre avant de me faire une opinion. Et ça prend tu temps, oui, mais c'est nécessaire. L'empathie est ce qui nous différencie de pas mal d'animaux (dont certaines moules apparemment).
Je n'interviendrais plus sur ce sujet stérile, mais j'attends bien sûr avec impatience toutes vos contributions pour améliorer le projet G'MIC (la soumission de patchs se fait ici).
En l'occurence, c'est pas du tout l'état d'esprit dans lequel je développe. Je suis prêt à beaucoup me remettre en cause pour améliorer un projet, et je l'ai déjà fait souvent d'ailleurs depuis le début dans G'MIC et CImg. J'accepte bien sûr des patchs quand ils apportent quelque chose de valable.
Quand quelqu'un me soumets un patch, il me détaille : 1. Quel est le problème, 2. Comment résoudre le problème. C'est cartésien, c'est sain. Peut-être que j'attends un peu plus (trop?) de ça aussi dans les commentaires d'une dépêche Linuxfr ? Ceux qui donnent un avis juste pour donner un avis, ça fait avancer personne, surtout quand le ton est désagréable et/ou pédant.
G'MIC peut traiter de la vidéo plus ou moins en temps réel, ça dépend bien sûr de la complexité du filtre à appliquer. Un bon exemple pour voir ça, c'est à travers le logiciel ZArt, une interface qt pour G'MIC dont le but est justement de traiter de la vidéo. Une petite vidéo de démonstration de ZArt qui tourne en temps réel est disponible sur youtube :
Tu as mal compris mon commentaire.
Ce n'est pas une question de mauvais outils, ni de "j'ai pas le temps ou c'est trop tard", ni d'incompétence en programmation. C'est juste que c'est de mon point de vue la meilleure façon de faire. Si toi, tu penses que ce n'est pas la bonne façon de faire, aucun problème, c'est ton droit.
Il faut croire qu'on est pas d'accord. Donc maintenant, de deux choses l'une :
Si tu veux me convaincre que ce n'est pas la bonne façon de faire, aucun problème, ça m'intéresse même.
Par contre, j'attend un peu plus, il faut prouver ce que tu dis de manière un peu rigoureuse et scientifique. Balancer des grosses généralités sur la "bonne" façon de programmer, ça n'avance à rien. Dire que les template n'empêchent pas d'avoir plusieurs fichiers parce que Boost ou la STL ont plusieurs fichiers c'est une évidence. J'ai jamais dis le contraire. Dire qu'une classe avec +1000 lignes c'est absurde, ça commence à ressembler à un gros troll velu. Le mieux serait encore que tu proposes une alternative plus belle et plus fonctionnelle à partir des sources que je fournis gracieusement. Y a pas beaucoup de fichiers C++, donc ça ne devrait pas être un travail énorme :)
Si au contraire, tu ne cherches pas à me convaincre, essaye au moins de respecter mes choix, peut-être même tenter de les comprendre, sans me faire passer pour un neuneu de la programmation (bref, soit un peu ouvert). Je suis loin d'être aussi fermé que ton commentaire le sous-entend, et je n'accepte pas qu'on descende ce projet sous des prétextes fallacieux et des mauvaises interprétations de ta part.
Je ne vais pas changer la structure complète du code, parce que deux ou trois personnes sur Linuxfr m'ont fait remarqué que c'était mal fait. Je suis prêt à écouter tout bon conseil et toute bonne suggestion, mais à un moment donné, il faut prouver ce qu'on dit, et arrêter le déballage d'opinions sans arguments étayés. J'essaye de construire un projet libre qui marche le plus efficacement possible (tu doutes de l'efficacité de l'outil, mais l'as-tu au moins essayé?). Efficacité, à la fois dans l'exécution en elle-même, la généricité du code, la facilité de maintenance, etc.. Et pour le moment, je ne me plains pas de l'efficacité. Je me plains pas de grand chose en l'occurence, j'essaye juste d'avancer.
Prouve moi que tu peux rendre ce projet encore plus efficace et je te suivrais dans tes choix avec plaisir.
Mais sans occulter non plus tous les avantages que procurent la structure actuelle!
(Ce message est aussi valable pour N. Boulay, qui depuis quelques années, à chaque news Linuxfr sur G'MIC en profite sur donner son avis sur la bonne façon de programmer. Depuis le temps, il aurait donc eu le temps de contribuer d'une manière ou d'un autre au projet pour nous remettre dans le "droit chemin", mais on a jamais eu de nouvelles, on attend toujours).
Voilà, ton commentaire est intéressant, parce qu'il illustre parfaitement ce que je disais précédemment, à savoir que tu donnes un avis assez tranché, mais "général", sur la façon de structurer un code (avis d'ailleurs que je peux partager pour du code "classique"), alors même que tu ne connais pas suffisamment les spécificités techniques des projets G'MIC (et CImg surtout) pour comprendre pourquoi j'ai fait comme ça (et c'est parfaitement normal également). Et dans le cas du projet G'MIC en particulier, il s'avère que cette structuration classique ne serait pas forcément la meilleure. Note qu'elle ne serait pas tellement plus mauvaise non plus, mais qu'à mon avis, elle propose légèrement moins d'avantages (et mon point de vue a quand même un poid important sur le résultat final). Ca se joue pas à grand chose, mais c'est comme ça. Et comme ça se joue quand même vraiment sur des détails (purement techniques en plus), ça m'étonne toujours que ça fasse tant parler. Surtout que la plupart des gens qui émettent un avis n'en savent probablement pas suffisamment pour que leur avis soit constructif.
Mais de fait, je maintiens qu'avoir plusieurs fichiers plutôt qu'un seul est un point purement technique, au fond assez anecdotique. La quantité de donnée stockée est quasiment la même dans les deux cas (avec même moins de redondance dans le cas d'un gros fichier). Le point qui te dérange sans doute, c'est de te dire que le compilateur est plus efficace à compiler plusieurs fichiers qu'un seul gros. Et que séparer en plusieurs fichiers, c'est l'assurance de ne pas recompiler des bouts de code déjà compilés.
Tu as raison "en général", mais d'une part, je dirais que ça pourrait presque être vu comme une limitation du compilo. On peut très bien imaginer dans le futur qu'un compilateur puisse déterminer quelles parties d'un gros fichier il doit recompiler, sans recompiler le reste du fichier. Mais bon, Ok c'est pas encore le cas. Par contre, ceci est vrai en général, sauf quand on utilise des bibliothèques de fonctions templates où le type des paramètres template est inconnu à la compilation. Est c'est exactement le cas de CImg, la bibliothèque d'opérateurs de traitement d'images que j'utilise (et que je distribue à part). Ici de toute façon, le compilo va devoir "tout" recompiler (en fait, non pas tout, il est assez malin pour recompiler juste les méthodes utilisées dans le code, avantage No 1 : tu auras pas dans ton code final des blobs binaires de code que tu n'utilises pas) pour les types template instanciés dans par l'utilisateur. C'est du template, c'est le principe.
Dans le cas de G'MIC, le gros du travail de compilation, c'est de compiler les méthodes de CImg qui sont utilisées, donc une fois que ça c'est fait, quasiment tout est fait. Après, dire que CImg est pas modulaire, c'est archi-faux, tout est bien structuré, dans des beaux namespaces, des belles classes, c'est juste que tout ça est défini dans un seul fichier. Pourquoi par plusieurs ? Parce que comme toutes ces belles classes dépendent fortement les une des autres, il faudrait de toute façon inclure tous ces beaux fichiers séparés en même temps, donc d'un point de vue performance de compilation, ça reviendrait exactement au même. A noter que de toute façon, la phase de parsing des fichiers par le compilo dans le temps global de compilation est réellement négligeable par rapport au reste (phase d'optimisation en particulier) donc que le fichier soit gros ou pas, le compilo s'en tape un peu.
Revenons en au temps de compilation. Hé bien non, ça prend pas longtemps, désolé (avec un compilo décent). Peut-être un peu plus longtemps que si j'avais utilisé des fonctions non-template (mais j'aurais perdu en généricité, ce qui serait perdre beaucoup pour gagner peu), mais ça reste très acceptable pour développeur. Actuellement, sans les optimisations, G'MIC complet, avec toutes les dépendances se compile en 1 minute (sur mon portable, avec g++ 4.8). C'est long 1 minute pour un projet comme G'MIC ? Non, carrément pas !
(avec clang++ c'est kif-kif). Alors OK, avec les optims c'est plus long, mais ça c'est quelque chose qu'on fait seulement de temps en temps, pas pour le développement de tous les jours (et au boulot, pareil ça prend 15mn avec make -j… oulala j'ai à peine le temps d'aller prendre un chocolat chaud à la machine avant que ma release soit prête. Pourquoi penses-tu que je peux proposer des pre-releases quasiment journalières sans que ça soit une torture ?).
Après, tu sous-entends que ça favorise pas les contributions extérieures. Mais c'est là encore archi-faux ! Des contributions j'en recois raisonablement, autant pour CImg que pour G'MIC. Et quelle facilité pour maintenir le code ! Une contribution sur un tel code, ça sera forçément très local dans un fichier, ça sera pas du code nouveaux disséminé dans 4 ou 5 fichiers différents, et bien ça c'est très appréciable pour la relecture des patchs, et la mise en adéquation au style de codage du projet. Je conseille à tout le monde d'essayer au moins une fois dans sa vie de maintenir un projet avec 3-4 fichiers maxi. Vous allez voir comme c'est simple !
Découper un projet en pleins de fichiers, c'est pas juste une question de mode ou pas de mode. Il faut le faire quand c'est nécessaire, mais il faut surtout ne pas se forcer à le faire quand ça sert à rien. Dans le cas de G'MIC / CImg, ça sert à rien. Que quelqu'un me prouve le contraire (mais pas juste avec des arguments bateaux), comme je le dis je suis pas fermé. Mais depuis 1999 (année ou j'ai commencé CImg), jamais personne ne m'a convaincu. Je commence quand même à me dire que c'est parce que j'ai choisi une façon de faire qui se défend carrément.
On pourrait dire aussi que si plusieurs personnes travaillent un même gros fichier, la probabilité qu'ils touchent à la même portion de code est plus réduite, donc à priori ça ne posera pas de problème pour le merge non plus (pas de conflits). Quand on y pense, le fait que des données de code source soit dans un même fichier ou séparés en plusieurs fichiers est finalement assez anecdotique, c'est un point purement technique qui ne change rien au fait qu'un code soit bien structuré ou non. Enfin c'est mon avis.
Ok pour ta problématique. A mon avis, un truc qui pourrait marcher pas mal serait simplement de faire une fonction qui génére plusieurs images noir et blanc à partir d'une image couleur, en choisissant différentes formules 'classiques' de conversion (luminance, lightness, value, average,…) et de sélectionner parmi celles-ci celle qui maximise un critère de variance des gradients de valeurs obtenues par exemple.
C'est une idée amusante qui risque de bien marcher, je vais probablement essayer ça un de ces quatres.
Pour le genre d'images (synthétiques) que tu utilises, tu peux en général facilement trouver une façon de calculer le passage couleur -> scalaire avec une fonction plus adaptée à la visualisation que tu recherches. Sur l'image que tu donnes par exemple, au lieu de prendre la luminance, tu prends la Value de l'espace HSV (correspondant au max des valeurs sur RGB), et ça donne quelque chose qui m'a l'air correct, peut-être même plus naturel que ce que propose l'algo color2gray :
$ gmic input.jpg -split c -max -output rgbmax.png
Pour le code, encore une fois tout est question de personnalité de celui qui relit. J'ai moi-même lu pas mal de codes d'autres projets (des bibliothèques de traitement d'image principalement), et je préfère toujours aborder un projet avec peu de fichiers, à priori, je me dis que ça va être plus simple de s'y retrouver et je vais moins devoir chercher dans pleins de fichiers. Si je cherche une fonctionnalité précise, de toute façon, j'ai au moins un mot-clé que je peux utiliser pour chercher dans le fichier (au mieux, le nom de l'algorithme qui va apparaitre dans les commentaires associé au code, ou au pire, un nom de fonction d'une dépendence qui va être forcément utilisé à l'endroit où je cherche, genre appel X11).
Et dans un monde idéal, tes dizaines / centaines de fichiers devraient tous avoir un nom cohérent et une localisation cohérente, mais en vrai, comme tous les projets évoluent en dehors de l'imagination initiale de l'auteur, ça peut souvent finir rangé n'importe comment. Dire que beaucoup de fichiers facilite la lecture du code est pas quelque chose de généralisable (en tout cas, pour moi ça marche pas, je dois pas être le seul). Il m'est arrivé assez souvent de revenir à un bon vieux grep -R pour chercher une fonctionnalité précise dans des projets avec des foultitudes de fichiers. J'aurais honnêtement préféré faire un CTRL+S sous Emacs dans un seul gros fichier :)
Je ne connaissais pas l'algorithme color2gray, donc je ne l'ai pas implémenté, mais ça ne me semble pas trop compliqué. Eventuellement, j'y jeterai un oeil, d'autant qu'ils proposent un pseudo-code Matlab sur leur page qui peut être éventuellement converti en nouvelle commande G'MIC. D'après les résultats que je vois, on peut avoir un type de résultats un peu équivalent en appliquant un algorithme de contraste local après le calcul de la luminance. Donc en G'MIC, tu peux essayer ceci (en ligne de commande) :
$ gmic lena.bmp -luminance -normalize_local 1
Ce n'est pas exactement pareil que color2gray (ça ne marchera pas sur les cas pathologiques présentés dans le papier, comme l'image du 45 pour les daltoniens par exemple), mais pour rehausser le contraste pour les images à mettre dans une publi, c'est pas mal.
En ce qui concerne l'organisation du code, c'est une question réccurente je peux te l'assurer :) Donc j'ai quand même bien réfléchi à la question. Pour ma part, je n'y vois que des avantages (sinon, je pense que j'aurais quand même pensé à le changer depuis le temps), notamment la facilité de maintenance du projet (dans ce contexte précis, où je suis quasiment seul développeur dessus). Toutes les fonctionnalités sont regroupées thématiquement au même endroit (1 fichier pour l'interpréteur, 1 fichier pour les algos de traitement, 1 fichier pour la définition des commandes et des filtres), et j'utilise facilement la recherche de texte sous emacs pour me déplacer à l'intérieur d'un gros fichier. Donc, au contraire, ça serait très pénible pour moi d'avoir 50 fichiers différents. Le fichier gmic_def.h est généré automatiquement, donc à la limite, ne pas le mettre dans le dépôt git serait une meilleure idée. Pour la bibliothèque CImg sous-jacente, la décomposer en plusieurs fichiers n'aurait à priori aucun intérêt "technique", autre que faire plaisir aux gens qui aiment avoir pleins de fichiers :). Ca peut être un peu long à expliquer, et j'ai déjà discuté de ça avec pas mal de personnes en essayant de donner des arguments étayés allant dans ce sens. Mais bon avec le temps, ce que j'ai aussi remarqué, c'est qu'en matière de code, chacun a souvent un avis bien tranché sur la question, et pense toujours connaître les "bonnes pratiques", même en ignorant totalement le contexte du projet et la structure du code. Comme l'auteur d'un logiciel est à priori le mieux renseigné sur la structure de son code, il me semble qu'il faut venir avec des arguments plus que solides pour le convaincre de changer. Je n'ai personnellement rien contre le changement (en tant que chargé de recherche, ça serait un comble), mais personne n'a encore réussi à me convaincre sur ce point là.
Le code de G'MIC est assez court (moins de 100kloc), en regard de ses fonctionnalités, donc refactoriser ce code ne serait pas forcément très long, ni très fastidieux. C'est juste que je ne vois pas de raisons valables de le faire pour ma part, et même pire, je pense que ça deviendrait plus long et plus difficile à maintenir. Si quelqu'un veut se lancer pour prouver le contraire, je l'encourage vivement bien entendu.
A noter que cette fonction de recherche est disponible dans le greffon G'MIC pour Krita par contre.
Quand on confie ça à des gens qui savent mieux coder des interfaces graphiques, ça aide :)
Je viens d'essayer avec clang++, et effectivement le compilateur plante également si les optimisations (au moins -O2) sont activées (je pense que ça fonctionne avec -O1 par contre). On a du mal à compiler le projet sous Mac pour cette raison (on doit utiliser le 'vrai' g++). J'ai déjà posté un rapport de bug sur le forum de LLVM à ce sujet. Il faut simplement espérer que les compilos vont mieux se comporter dans le futur, mais à priori y a pas de raisons.
Je pense que le problème provient de l'activation d'OpenMP.
g++ 4.8.1 plante effectivement à la compilation, alors que g++ 4.8.2 fonctionne.
Pour Clang, je n'ai pas essayé avec OpenMP.
Pour désactiver le support d'OpenMP, essaye ceci :
Oui GraphicsMagick et ImageMagick sont les deux 'mastodontes' du traitement d'image libre, ils existent depuis très longtemps. Pour tout ce qui est conversion de formats d'images, à priori c'est le top.
G'MIC se focalise plus sur le traitement proprement dit, donc je pense qu'il est plus adapté pour appliquer des effets sur des images, d'autant qu'il est plus facile (de mon point de vue) d'écrire des effets personnalisés.
Oui j'ai effectivement pensé à toi, ayant lu tes articles sur la programmation de jeux vidéos, et notamment celui sur la génération de terrains. Pour toutes les textures du type herbe, pierre, mer, sable, ça devrait effectivement marcher pas mal.
Je ne suis probablement pas la meilleure personne (comprendre suffisamment 'neutre') pour répondre à cette question. Ce que je peux te dire, c'est que pour redimensionner une image avec G'MIC, tu as une commande -resize également, qui fonctionne de la façon suivante :
Les commandes de G'MIC se lisent (et s'exécutent de gauche à droite) contrairement aux outils ImageMagick où l'ordre des arguments n'a apparemment pas trop d'importance.
Tu peux obtenir l'aide sur une commande G'MIC de la façon suivante :
$ gmic -h resize
gmic: GREYC's Magic for Image Computing. Version 1.5.9.3, Copyright (c) 2008-2014, David Tschumperle. (http://gmic.sourceforge.net) -resize (*): [image],_interpolation,_boundary,_ax,_ay,_az,_ac | {[image_w] | width>0[%]},_{[image_h] | height>0[%]},_{[image_d] | depth>0[%]}, _{[image_s] | spectrum>0[%]},_interpolation,_boundary,_ax,_ay,_az,_ac | (noargs) Resize selected images with specified geometry. (eq. to '-r'). 'interpolation' can be { -1=none (memory content) | 0=none | 1=nearest | 2=average | 3=linear | 4=grid | 5=bicubic | 6=lanczos }. 'boundary' has different meanings, according to the chosen 'interpolation' mode : . When 'interpolation=={ -1 | 1 | 2 | 4 }', 'boundary' is meaningless. . When 'interpolation==0', 'boundary' can be { 0=dirichlet | 1=neumann | 2=periodic }. . When 'interpolation=={ 3 | 5 | 6 }', 'boundary' can be { 0=none | 1=neumann }. 'ax,ay,az,ac' set the alignment mode along each axis when 'interpolation=0 or 4' (set to '0' by default, must be defined in range [0,1]). (noargs) runs interactive mode (uses the instant window [0] if opened). Default values: 'interpolation=1', 'boundary=0' and 'ax=ay=az=ac=0'.
Example(s): image.jpg (0,1;0,1^0,0;1,1^1,1;1,1) -resize[-1][-2],3 -mul[-2][-1]
image.jpg --resize[-1] 256,128,1,3,2 --resize[-1] 120%,120%,1,3,0,1,0.5,0.5 \
--resize[-1] 120%,120%,1,3,0,0,0.2,0.2 --resize[-1][0],[0],1,3,4
Ce qui te dit ici, que tu utilise un redimensionnement avec une interpolation de type 2=average, qui est bien adaptée pour la réduction.
Dans le greffon, il y a la possibilité d'ajouter des Favoris, avec même un réglage des paramètres personnalisés. A priori, c'est fait pour ça : retrouver ses filtres Favoris le plus rapidement possible.
A la selection d'un filtre, il faut juste appuyer sur le bouton en forme de +.
On peut renommer les favoris après coup, en double-cliquant sur le nom du favori.
[^] # Re: gif d'inpainting
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 4.
La statue provient du pont qui est situé à droite dans l'image (on ne le voit donc pas dans le zoom).
L'image d'origine traitée est de résolution supérieure à celle du .gif présenté ici.
[^] # Re: Une coquille ?
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 3.
Oui c'est exact, en fait le filtre génére effectivement un nouveau calque qui s'ajoute à l'image.
L'exemple ici n'est peut-être pas très bien choisi. En ne gardant que le calque généré avec des paramètres sympas, on peut quand même avoir un fond de type Bokeh (qui fait un peu synthétique mais sympa quand même).
[^] # Re: Chargement site
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.8 : c’est déjà Noël pour les traiteurs d’images !. Évalué à 5.
Oui effectivement depuis quelques jours, l'accès à l'API flattr a l'air un peu bloquant.
Du coup je vais l'enlever au moins temporairement (parce que c'est pas pour ce que ça sert…)
[^] # Re: Question de n00b
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 3.
Ok merci pour ta réponse, du coup ma deuxième question du dessus est inutile :)
[^] # Re: Question de n00b
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 5.
C'est juste, mais ma question portait plus sur l'expérience utilisateur.
Avec ton exemple, il va certes attendre 140 minutes au lieu de 160, mais ça reste quand même 140 minutes :)
Un utilisateur non expérimenté risque de faire une drôle de tête si sa machine mets trop de temps à recalculer un rendu alors qu'il a juste changé le paramètre de variance de son flou gaussien, appliqué en tout début de pipeline (qui est un opérateur en soi immédiat à recalculer quand c'est appliqué "à part").
D'où ma question. Ca me parait pas si trivial de rendre fluide le tout.
Dans le futur, est-ce que chaque opérateur de traitement de GIMP sera un noeud GEGL ?
C'est ce qui a l'air d'être préconisé si on écoute les développeurs de GIMP actuellement.
Si c'est le cas, ce genre de problème pourrait rapidement se poser pour les noeuds un peu "lourds" à calculer, et également pour le "preview on canvas".
Est-ce qu'il y aura possibilité pour un noeud de se signaler comme étant gros consommateur de ressources ? Avez vous prévu des méchanismes spéciaux pour gérer ce genre de noeuds ?
[^] # Re: Question de n00b
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 8.
Petite question à ce sujet… L'édition non destructrice est intéressante, mais il me semble qu'elle se limite quand même à des filtres de traitement d'images "basiques", rapides à calculer. De même pour la fonctionnalité "preview on canvas" qui est poussée en avant pour les prochaines releases avec GEGL.
On imagine mal en effet devoir attendre 15 minutes (au hasard) le recalcul d'un rendu après avoir changé un paramètre d'un des filtres (parce que le graphe comprend un filtre très long à calculer, qui a été appliqué à la fin). Avez vous prévu quelque chose de spécial dans ce cas ?
Si non, cela veut-il dire que les opérateurs GEGL seront de toute façon limités à des traitements basiques, si on veut les rendre utilisables en pratique ?
Merci.
[^] # Re: Colorihttp://opensource.graphics/how-to-code-a-nice-user-guided-foregroundsation d'une animation
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche "ZeMarmot", premier film d'animation réalisé entièrement avec des Logiciels Libres. Évalué à 4.
Je ne sais pas si ça peut aider, mais j'ai écrit deux articles sur la façon dont fonctionne le processus d'extraction avant-plan/arrière plan dans G'MIC, et c'est exactement la même façon de faire que pour la colorisation de comics, sauf qu'au lieu d'avoir deux labels "Avant-plan" et "Arrière-plan", tu as un nombre plus grand de labels, chacun associé à une couleur pour le remplissage. C'est sur mon "début" de blog:
How to code a nice user-guided foreground extraction algorithm?
et
How to code a nice user-guided foreground extraction algorithm? (Addendum)
(ce dernier donne un bout de l'algorithme en C++).
Au cas où…
[^] # Re: color2gray et organisation du code
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 5. Dernière modification le 24 avril 2015 à 09:58.
J'ai résolu le problème du git, effectivement ça prenait un peu trop de place.
Les sources seules (sans les fichiers resources, binaires, qui prenaient bcp de place) sont disponibles sur un repo 'minimal' :
qui fait 4Mo en tout et pour tout.
[^] # Re: color2gray et organisation du code
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 2.
Ce n'est pas un argument que j'ai utilisé pour justifier ce choix. C'est un argument que j'ai utilisé pour contredire Michel: S'y retrouver dans le code d'un gros fichier n'est pas plus difficile que dans pleins de petits, puisqu'au final on peut fait une recherche plutôt qu'un grep. Donc, l'argument "pleins de petits fichiers c'est mieux pour s'y retrouver dans l'organisation d'un code" avancé par Michel, est faux. Au final, ça revient au même. Voilà ce que j'ai dit.
Ca, je dirais, c'est ton problème. Est-ce que je me suis plaint de pas avoir assez de contributeurs ? Jamais. Faut croire que pas mal de gens sont pas apeurés par la première originalité venue (ou ont assez d'expérience pour se rendre compte que ça n'a aucune incidence sur la qualité du code). Franchement, lire des commentaires du niveau de celui de xcomcmdr (plus haut), c'est à pleurer. A croire qu'il n'a jamais rencontré autre chose qu'un "Hello World" de toute sa vie.
Je suis tout à fait normal, et en tant qu'être humain normal, j'essaye de me contrôler et pas crier au loup dès que je vois quelque chose d'un peu différent de ce que j'ai l'habitude de faire par moi-même. Surtout si ça touche un point de vue seulement "technique". J'essaye d'abord de comprendre avant de me faire une opinion. Et ça prend tu temps, oui, mais c'est nécessaire. L'empathie est ce qui nous différencie de pas mal d'animaux (dont certaines moules apparemment).
Je n'interviendrais plus sur ce sujet stérile, mais j'attends bien sûr avec impatience toutes vos contributions pour améliorer le projet G'MIC (la soumission de patchs se fait ici).
[^] # Re: color2gray et organisation du code
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 5.
En l'occurence, c'est pas du tout l'état d'esprit dans lequel je développe. Je suis prêt à beaucoup me remettre en cause pour améliorer un projet, et je l'ai déjà fait souvent d'ailleurs depuis le début dans G'MIC et CImg. J'accepte bien sûr des patchs quand ils apportent quelque chose de valable.
Quand quelqu'un me soumets un patch, il me détaille : 1. Quel est le problème, 2. Comment résoudre le problème. C'est cartésien, c'est sain. Peut-être que j'attends un peu plus (trop?) de ça aussi dans les commentaires d'une dépêche Linuxfr ? Ceux qui donnent un avis juste pour donner un avis, ça fait avancer personne, surtout quand le ton est désagréable et/ou pédant.
[^] # Re: Gmic pour la vidéo
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 5.
G'MIC peut traiter de la vidéo plus ou moins en temps réel, ça dépend bien sûr de la complexité du filtre à appliquer. Un bon exemple pour voir ça, c'est à travers le logiciel ZArt, une interface qt pour G'MIC dont le but est justement de traiter de la vidéo. Une petite vidéo de démonstration de ZArt qui tourne en temps réel est disponible sur youtube :
https://www.youtube.com/watch?v=k1l3RdvwHeM
On voit tourner quelques fitres sur la vidéo provenant d'une webcam dans un premier temps, puis d'un fichier vidéo dans un deuxième temps.
[^] # Re: color2gray et organisation du code
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 9. Dernière modification le 23 avril 2015 à 08:43.
Tu as mal compris mon commentaire.
Ce n'est pas une question de mauvais outils, ni de "j'ai pas le temps ou c'est trop tard", ni d'incompétence en programmation. C'est juste que c'est de mon point de vue la meilleure façon de faire. Si toi, tu penses que ce n'est pas la bonne façon de faire, aucun problème, c'est ton droit.
Il faut croire qu'on est pas d'accord. Donc maintenant, de deux choses l'une :
Si tu veux me convaincre que ce n'est pas la bonne façon de faire, aucun problème, ça m'intéresse même.
Par contre, j'attend un peu plus, il faut prouver ce que tu dis de manière un peu rigoureuse et scientifique. Balancer des grosses généralités sur la "bonne" façon de programmer, ça n'avance à rien. Dire que les template n'empêchent pas d'avoir plusieurs fichiers parce que Boost ou la STL ont plusieurs fichiers c'est une évidence. J'ai jamais dis le contraire. Dire qu'une classe avec +1000 lignes c'est absurde, ça commence à ressembler à un gros troll velu. Le mieux serait encore que tu proposes une alternative plus belle et plus fonctionnelle à partir des sources que je fournis gracieusement. Y a pas beaucoup de fichiers C++, donc ça ne devrait pas être un travail énorme :)
Si au contraire, tu ne cherches pas à me convaincre, essaye au moins de respecter mes choix, peut-être même tenter de les comprendre, sans me faire passer pour un neuneu de la programmation (bref, soit un peu ouvert). Je suis loin d'être aussi fermé que ton commentaire le sous-entend, et je n'accepte pas qu'on descende ce projet sous des prétextes fallacieux et des mauvaises interprétations de ta part.
Je ne vais pas changer la structure complète du code, parce que deux ou trois personnes sur Linuxfr m'ont fait remarqué que c'était mal fait. Je suis prêt à écouter tout bon conseil et toute bonne suggestion, mais à un moment donné, il faut prouver ce qu'on dit, et arrêter le déballage d'opinions sans arguments étayés. J'essaye de construire un projet libre qui marche le plus efficacement possible (tu doutes de l'efficacité de l'outil, mais l'as-tu au moins essayé?). Efficacité, à la fois dans l'exécution en elle-même, la généricité du code, la facilité de maintenance, etc.. Et pour le moment, je ne me plains pas de l'efficacité. Je me plains pas de grand chose en l'occurence, j'essaye juste d'avancer.
Prouve moi que tu peux rendre ce projet encore plus efficace et je te suivrais dans tes choix avec plaisir.
Mais sans occulter non plus tous les avantages que procurent la structure actuelle!
(Ce message est aussi valable pour N. Boulay, qui depuis quelques années, à chaque news Linuxfr sur G'MIC en profite sur donner son avis sur la bonne façon de programmer. Depuis le temps, il aurait donc eu le temps de contribuer d'une manière ou d'un autre au projet pour nous remettre dans le "droit chemin", mais on a jamais eu de nouvelles, on attend toujours).
[^] # Re: color2gray et organisation du code
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 9.
Voilà, ton commentaire est intéressant, parce qu'il illustre parfaitement ce que je disais précédemment, à savoir que tu donnes un avis assez tranché, mais "général", sur la façon de structurer un code (avis d'ailleurs que je peux partager pour du code "classique"), alors même que tu ne connais pas suffisamment les spécificités techniques des projets G'MIC (et CImg surtout) pour comprendre pourquoi j'ai fait comme ça (et c'est parfaitement normal également). Et dans le cas du projet G'MIC en particulier, il s'avère que cette structuration classique ne serait pas forcément la meilleure. Note qu'elle ne serait pas tellement plus mauvaise non plus, mais qu'à mon avis, elle propose légèrement moins d'avantages (et mon point de vue a quand même un poid important sur le résultat final). Ca se joue pas à grand chose, mais c'est comme ça. Et comme ça se joue quand même vraiment sur des détails (purement techniques en plus), ça m'étonne toujours que ça fasse tant parler. Surtout que la plupart des gens qui émettent un avis n'en savent probablement pas suffisamment pour que leur avis soit constructif.
Mais de fait, je maintiens qu'avoir plusieurs fichiers plutôt qu'un seul est un point purement technique, au fond assez anecdotique. La quantité de donnée stockée est quasiment la même dans les deux cas (avec même moins de redondance dans le cas d'un gros fichier). Le point qui te dérange sans doute, c'est de te dire que le compilateur est plus efficace à compiler plusieurs fichiers qu'un seul gros. Et que séparer en plusieurs fichiers, c'est l'assurance de ne pas recompiler des bouts de code déjà compilés.
Tu as raison "en général", mais d'une part, je dirais que ça pourrait presque être vu comme une limitation du compilo. On peut très bien imaginer dans le futur qu'un compilateur puisse déterminer quelles parties d'un gros fichier il doit recompiler, sans recompiler le reste du fichier. Mais bon, Ok c'est pas encore le cas. Par contre, ceci est vrai en général, sauf quand on utilise des bibliothèques de fonctions templates où le type des paramètres template est inconnu à la compilation. Est c'est exactement le cas de CImg, la bibliothèque d'opérateurs de traitement d'images que j'utilise (et que je distribue à part). Ici de toute façon, le compilo va devoir "tout" recompiler (en fait, non pas tout, il est assez malin pour recompiler juste les méthodes utilisées dans le code, avantage No 1 : tu auras pas dans ton code final des blobs binaires de code que tu n'utilises pas) pour les types template instanciés dans par l'utilisateur. C'est du template, c'est le principe.
Dans le cas de G'MIC, le gros du travail de compilation, c'est de compiler les méthodes de CImg qui sont utilisées, donc une fois que ça c'est fait, quasiment tout est fait. Après, dire que CImg est pas modulaire, c'est archi-faux, tout est bien structuré, dans des beaux namespaces, des belles classes, c'est juste que tout ça est défini dans un seul fichier. Pourquoi par plusieurs ? Parce que comme toutes ces belles classes dépendent fortement les une des autres, il faudrait de toute façon inclure tous ces beaux fichiers séparés en même temps, donc d'un point de vue performance de compilation, ça reviendrait exactement au même. A noter que de toute façon, la phase de parsing des fichiers par le compilo dans le temps global de compilation est réellement négligeable par rapport au reste (phase d'optimisation en particulier) donc que le fichier soit gros ou pas, le compilo s'en tape un peu.
Revenons en au temps de compilation. Hé bien non, ça prend pas longtemps, désolé (avec un compilo décent). Peut-être un peu plus longtemps que si j'avais utilisé des fonctions non-template (mais j'aurais perdu en généricité, ce qui serait perdre beaucoup pour gagner peu), mais ça reste très acceptable pour développeur. Actuellement, sans les optimisations, G'MIC complet, avec toutes les dépendances se compile en 1 minute (sur mon portable, avec g++ 4.8). C'est long 1 minute pour un projet comme G'MIC ? Non, carrément pas !
(avec clang++ c'est kif-kif). Alors OK, avec les optims c'est plus long, mais ça c'est quelque chose qu'on fait seulement de temps en temps, pas pour le développement de tous les jours (et au boulot, pareil ça prend 15mn avec make -j… oulala j'ai à peine le temps d'aller prendre un chocolat chaud à la machine avant que ma release soit prête. Pourquoi penses-tu que je peux proposer des pre-releases quasiment journalières sans que ça soit une torture ?).
Après, tu sous-entends que ça favorise pas les contributions extérieures. Mais c'est là encore archi-faux ! Des contributions j'en recois raisonablement, autant pour CImg que pour G'MIC. Et quelle facilité pour maintenir le code ! Une contribution sur un tel code, ça sera forçément très local dans un fichier, ça sera pas du code nouveaux disséminé dans 4 ou 5 fichiers différents, et bien ça c'est très appréciable pour la relecture des patchs, et la mise en adéquation au style de codage du projet. Je conseille à tout le monde d'essayer au moins une fois dans sa vie de maintenir un projet avec 3-4 fichiers maxi. Vous allez voir comme c'est simple !
Découper un projet en pleins de fichiers, c'est pas juste une question de mode ou pas de mode. Il faut le faire quand c'est nécessaire, mais il faut surtout ne pas se forcer à le faire quand ça sert à rien. Dans le cas de G'MIC / CImg, ça sert à rien. Que quelqu'un me prouve le contraire (mais pas juste avec des arguments bateaux), comme je le dis je suis pas fermé. Mais depuis 1999 (année ou j'ai commencé CImg), jamais personne ne m'a convaincu. Je commence quand même à me dire que c'est parce que j'ai choisi une façon de faire qui se défend carrément.
[^] # Re: color2gray et organisation du code
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 6.
On pourrait dire aussi que si plusieurs personnes travaillent un même gros fichier, la probabilité qu'ils touchent à la même portion de code est plus réduite, donc à priori ça ne posera pas de problème pour le merge non plus (pas de conflits). Quand on y pense, le fait que des données de code source soit dans un même fichier ou séparés en plusieurs fichiers est finalement assez anecdotique, c'est un point purement technique qui ne change rien au fait qu'un code soit bien structuré ou non. Enfin c'est mon avis.
[^] # Re: color2gray et organisation du code
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 8.
Ok pour ta problématique. A mon avis, un truc qui pourrait marcher pas mal serait simplement de faire une fonction qui génére plusieurs images noir et blanc à partir d'une image couleur, en choisissant différentes formules 'classiques' de conversion (luminance, lightness, value, average,…) et de sélectionner parmi celles-ci celle qui maximise un critère de variance des gradients de valeurs obtenues par exemple.
C'est une idée amusante qui risque de bien marcher, je vais probablement essayer ça un de ces quatres.
[^] # Re: color2gray et organisation du code
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 7. Dernière modification le 17 avril 2015 à 15:11.
Pour le genre d'images (synthétiques) que tu utilises, tu peux en général facilement trouver une façon de calculer le passage couleur -> scalaire avec une fonction plus adaptée à la visualisation que tu recherches. Sur l'image que tu donnes par exemple, au lieu de prendre la luminance, tu prends la Value de l'espace HSV (correspondant au max des valeurs sur RGB), et ça donne quelque chose qui m'a l'air correct, peut-être même plus naturel que ce que propose l'algo color2gray :
Pour le code, encore une fois tout est question de personnalité de celui qui relit. J'ai moi-même lu pas mal de codes d'autres projets (des bibliothèques de traitement d'image principalement), et je préfère toujours aborder un projet avec peu de fichiers, à priori, je me dis que ça va être plus simple de s'y retrouver et je vais moins devoir chercher dans pleins de fichiers. Si je cherche une fonctionnalité précise, de toute façon, j'ai au moins un mot-clé que je peux utiliser pour chercher dans le fichier (au mieux, le nom de l'algorithme qui va apparaitre dans les commentaires associé au code, ou au pire, un nom de fonction d'une dépendence qui va être forcément utilisé à l'endroit où je cherche, genre appel X11).
Et dans un monde idéal, tes dizaines / centaines de fichiers devraient tous avoir un nom cohérent et une localisation cohérente, mais en vrai, comme tous les projets évoluent en dehors de l'imagination initiale de l'auteur, ça peut souvent finir rangé n'importe comment. Dire que beaucoup de fichiers facilite la lecture du code est pas quelque chose de généralisable (en tout cas, pour moi ça marche pas, je dois pas être le seul). Il m'est arrivé assez souvent de revenir à un bon vieux
grep -Rpour chercher une fonctionnalité précise dans des projets avec des foultitudes de fichiers. J'aurais honnêtement préféré faire un CTRL+S sous Emacs dans un seul gros fichier :)[^] # Re: color2gray et organisation du code
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 10. Dernière modification le 17 avril 2015 à 11:58.
Je ne connaissais pas l'algorithme color2gray, donc je ne l'ai pas implémenté, mais ça ne me semble pas trop compliqué. Eventuellement, j'y jeterai un oeil, d'autant qu'ils proposent un pseudo-code Matlab sur leur page qui peut être éventuellement converti en nouvelle commande G'MIC. D'après les résultats que je vois, on peut avoir un type de résultats un peu équivalent en appliquant un algorithme de contraste local après le calcul de la luminance. Donc en G'MIC, tu peux essayer ceci (en ligne de commande) :
Ce n'est pas exactement pareil que color2gray (ça ne marchera pas sur les cas pathologiques présentés dans le papier, comme l'image du 45 pour les daltoniens par exemple), mais pour rehausser le contraste pour les images à mettre dans une publi, c'est pas mal.
En ce qui concerne l'organisation du code, c'est une question réccurente je peux te l'assurer :) Donc j'ai quand même bien réfléchi à la question. Pour ma part, je n'y vois que des avantages (sinon, je pense que j'aurais quand même pensé à le changer depuis le temps), notamment la facilité de maintenance du projet (dans ce contexte précis, où je suis quasiment seul développeur dessus). Toutes les fonctionnalités sont regroupées thématiquement au même endroit (1 fichier pour l'interpréteur, 1 fichier pour les algos de traitement, 1 fichier pour la définition des commandes et des filtres), et j'utilise facilement la recherche de texte sous emacs pour me déplacer à l'intérieur d'un gros fichier. Donc, au contraire, ça serait très pénible pour moi d'avoir 50 fichiers différents. Le fichier gmic_def.h est généré automatiquement, donc à la limite, ne pas le mettre dans le dépôt git serait une meilleure idée. Pour la bibliothèque CImg sous-jacente, la décomposer en plusieurs fichiers n'aurait à priori aucun intérêt "technique", autre que faire plaisir aux gens qui aiment avoir pleins de fichiers :). Ca peut être un peu long à expliquer, et j'ai déjà discuté de ça avec pas mal de personnes en essayant de donner des arguments étayés allant dans ce sens. Mais bon avec le temps, ce que j'ai aussi remarqué, c'est qu'en matière de code, chacun a souvent un avis bien tranché sur la question, et pense toujours connaître les "bonnes pratiques", même en ignorant totalement le contexte du projet et la structure du code. Comme l'auteur d'un logiciel est à priori le mieux renseigné sur la structure de son code, il me semble qu'il faut venir avec des arguments plus que solides pour le convaincre de changer. Je n'ai personnellement rien contre le changement (en tant que chargé de recherche, ça serait un comble), mais personne n'a encore réussi à me convaincre sur ce point là.
Le code de G'MIC est assez court (moins de 100kloc), en regard de ses fonctionnalités, donc refactoriser ce code ne serait pas forcément très long, ni très fastidieux. C'est juste que je ne vois pas de raisons valables de le faire pour ma part, et même pire, je pense que ça deviendrait plus long et plus difficile à maintenir. Si quelqu'un veut se lancer pour prouver le contraire, je l'encourage vivement bien entendu.
[^] # Re: Bravo !
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G’MIC 1.6.2.0 : Colorisation de BD, transfert de couleurs, aide au détourage et autres réjouissances. Évalué à 8.
A noter que cette fonction de recherche est disponible dans le greffon G'MIC pour Krita par contre.
Quand on confie ça à des gens qui savent mieux coder des interfaces graphiques, ça aide :)
[^] # Re: Tout cela à l'air bien mais ...
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G'MIC 1.5.9.3 : Poisson Blending, Seamcarving, OpenMP, et autres joyeusetés !. Évalué à 3.
Je viens d'essayer avec
clang++, et effectivement le compilateur plante également si les optimisations (au moins-O2) sont activées (je pense que ça fonctionne avec-O1par contre). On a du mal à compiler le projet sous Mac pour cette raison (on doit utiliser le 'vrai' g++). J'ai déjà posté un rapport de bug sur le forum de LLVM à ce sujet. Il faut simplement espérer que les compilos vont mieux se comporter dans le futur, mais à priori y a pas de raisons.[^] # Re: Tout cela à l'air bien mais ...
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G'MIC 1.5.9.3 : Poisson Blending, Seamcarving, OpenMP, et autres joyeusetés !. Évalué à 6.
Je pense que le problème provient de l'activation d'OpenMP.
g++ 4.8.1 plante effectivement à la compilation, alors que g++ 4.8.2 fonctionne.
Pour Clang, je n'ai pas essayé avec OpenMP.
Pour désactiver le support d'OpenMP, essaye ceci :
[^] # Re: GraphicsMagick ou G'MIC
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC 1.5.9.3 : Poisson Blending, Seamcarving, OpenMP, et autres joyeusetés !. Évalué à 4.
Oui GraphicsMagick et ImageMagick sont les deux 'mastodontes' du traitement d'image libre, ils existent depuis très longtemps. Pour tout ce qui est conversion de formats d'images, à priori c'est le top.
G'MIC se focalise plus sur le traitement proprement dit, donc je pense qu'il est plus adapté pour appliquer des effets sur des images, d'autant qu'il est plus facile (de mon point de vue) d'écrire des effets personnalisés.
[^] # Re: Vachement intéressant tout ça !
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche G'MIC 1.5.9.3 : Poisson Blending, Seamcarving, OpenMP, et autres joyeusetés !. Évalué à 10.
Oui à priori, je conseille cette lecture, qui donne des indications sur l'utilisation de l'algorithme d'inpainting dans G'MIC.
[^] # Re: Synthèse de micro-textures
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC 1.5.9.3 : Poisson Blending, Seamcarving, OpenMP, et autres joyeusetés !. Évalué à 4.
Oui j'ai effectivement pensé à toi, ayant lu tes articles sur la programmation de jeux vidéos, et notamment celui sur la génération de terrains. Pour toutes les textures du type herbe, pierre, mer, sable, ça devrait effectivement marcher pas mal.
[^] # Re: GraphicsMagick ou G'MIC
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC 1.5.9.3 : Poisson Blending, Seamcarving, OpenMP, et autres joyeusetés !. Évalué à 5. Dernière modification le 23 juin 2014 à 21:31.
Je ne suis probablement pas la meilleure personne (comprendre suffisamment 'neutre') pour répondre à cette question. Ce que je peux te dire, c'est que pour redimensionner une image avec G'MIC, tu as une commande -resize également, qui fonctionne de la façon suivante :
Les commandes de G'MIC se lisent (et s'exécutent de gauche à droite) contrairement aux outils ImageMagick où l'ordre des arguments n'a apparemment pas trop d'importance.
Tu peux obtenir l'aide sur une commande G'MIC de la façon suivante :
Ce qui te dit ici, que tu utilise un redimensionnement avec une interpolation de type 2=average, qui est bien adaptée pour la réduction.
[^] # Re: idée
Posté par David Tschumperlé (site web personnel) . En réponse au journal G'MIC 1.5.9.3 : Poisson Blending, Seamcarving, OpenMP, et autres joyeusetés !. Évalué à 6.
Dans le greffon, il y a la possibilité d'ajouter des Favoris, avec même un réglage des paramètres personnalisés. A priori, c'est fait pour ça : retrouver ses filtres Favoris le plus rapidement possible.
A la selection d'un filtre, il faut juste appuyer sur le bouton en forme de +.
On peut renommer les favoris après coup, en double-cliquant sur le nom du favori.