David Tschumperlé a écrit 337 commentaires

Ce repository git est effectivement reservé pour mes propres développements, donc le problème de collaboration ne se pose pas. Je ne compte pas spécialement avoir de contributeurs sur ce repo là en particulier, pour diverses raisons (que je n'ai pas le temps de détailler, mais qui sont bien réelles).
Nous avons par contre mis en place le repo https://github.com/dtschump/gmic-community où les contributeurs extérieurs sont actifs, et postent des messages de commit clairs et précis.

Je vais regarder ça au plus vite. Merci.

Je n'utilise effectivement pas les messages de commit de git pour stocker des infos sur les changements de code du projet, sauf cas exceptionnel, car je préfère éditer un Changelog détaillé qui s'étoffe petit à petit sur le forum du projet (comme celui-ci, démarré pour la version 2.0.1 par exemple). Je trouve ça personnellement plus commode car :

• Je vais de toute façon implémenter une fonctionnalité en la répartissant sur plusieurs commits successifs (commit de base + corrections éventuelles du code de base, par exemple).
• Dans le Changelog, je peut décrire la modification avec plus de place, sans me concentrer forcément sur la partie purement technique, et aussi associer des images pour l'illustrer.
• Je peut avoir des discussions directes avec les gens qui suivent les modifications de ce Changelog, en utilisant la possibilité de discussion du forum.
• Et de temps en temps, je fusionne tous ces Changelogs comme base pour écrire une dépêche qui résume tout ça, bien plus facilement que si je devais éplucher l'ensemble des commits que je réalise sur le code, car j'ai déjà pu tout bien rangé par catégories (New features, Improvements, Bug fixes ).

J'ai aussi une tendance naturelle à commiter très souvent, même à des fins de sauvegarde de mon travail en cours, donc aussi quand je n'ai pas forcément fini de mettre une nouvelle fonctionnalité en place. Ca me permet de récupérer très vite du code en cours que j'ai développé au labo, et me remettre au travail dessus le soir à la maison (oui, malgré mon status de fonctionnaire, je ne m'arrête pas de travailler sur G'MIC à 18h :) ).

Donc point de flemme dans tout ça, mais plutôt une organisation du travail qui me parait efficace, au moins pour ma façon de développer.

Le problème de cette approche, c'est que ça rajouterait encore un panneau supplémentaire vertical aux 3 panneaux déjà existants (fenêtre de prévisu, liste des filtres et paramètres de filtres). Par expérience, ce que les utilisateurs recherchent c'est plutôt de maximiser la taille des deux autres panneaux, à savoir : la fenêtre de prévisualisation, et la fenêtre des paramètres. Et comme le greffon est déjà plus large que haut, ça ne me semble pas super adapté de le rendre encore plus large.

De plus, la plupart des utilisateurs utilisent en pratique les favoris pour accéder rapidement à leurs filtres habituels, donc ils n'explorent pas si souvent que ça toutes les catégories disponibles, et laissent les catégories fermées le plus souvent. Si on rajoute en plus la possibilité d'utiliser maintenant le moteur de recherche de filtres, il devient vraiment rare d'aller accéder aux filtres directement dans chaque catégorie.

Oui j'ai vu passer tes récents commit à ce sujet, c'est une très bonne idée effectivement.
On a effectivement des problème récurrents avec les .dll sous Windows, notamment pour les utilisateurs qui utilisent encore des vieilles versions de GIMP, et malheureusement on ne peut pas faire grand chose à ce sujet. On attend donc GIMP 2.10 avec impatience :)

Je vois vraiment pas ce qui pourrait détrôner une bonne raclette, plat fin et équilibré par excellence (et potentiellement très varié).

Si, ça m'a effaré quand j'ai lu par exemple ceci :

Béhé: Le recul il est là : la concurrence est telle que les auteurs réussissent à foutre en l’air le seul outil qui leur permettait de faire respecter quelques droits.

Boulet: Et on se tue aussi à vous le répéter, Béhé et moi: on ne reproche strictement RIEN à cet auteur, juste à Glénat qui ne fait que plumer un pigeon.

Je serais à la place de David Revoy, je n'apprécierais pas trop d'être traité de la sorte (ni de naïf, ou autre, comme c'est fait dans d'autres commentaires plus loin).

David Revoy a fait un choix de licence libre assumé dès le départ (il y a plusieurs années maintenant), il savait très bien ce qu'il faisait, et ce que ces licences impliquaient. La licence autorise Glénat à publier sans reverser de royalties, point barre. C'est pas comme si David pensait que ça ne pouvait pas arriver un jour. Soit on respecte le choix de l'auteur (et dans ce cas, on respecte aussi le fait que Glénat se conforme à cette licence, et fait même un peu plus dans ce cas). Ou alors on ne respecte pas le choix de l'auteur, et on assume aussi (ce qu'ils ne font pas dans leurs commentaires), mais alors ça me fait penser un peu aux anti "mariage pour tous" qui veulent se mêler de la vie des autres, alors qu'en réalité ça n'a aucune conséquence dans leur vie à eux.
Au contraire, il faudrait juste saluer le courage de son "expérimentation" et le succès qui va avec !

Le logiciel libre n'a pas tué le logiciel propriétaire, la musique libre n'a pas tué la vente de CDs, et la BD libre ne va surement pas détruire les auteurs de BDs qui passent par le circuit plus classique des éditeurs. La réaction de peur qu'ils montrent ici est à mon sens grotesque.

Enfin un autre auteur de BD qui me parait sain d'esprit, et qui comprend la démarche de David Revoy :

http://bellaminettes.com/blog/?p=6050

C'est effarant de lire les réactions de Béhé et Boulet sur les autres liens. A croire qu'ils ne se sont jamais renseignés sur la façon dont le libre fonctionne aussi dans les autres domaines de la création (logiciels, musique,…).

La route est encore vraiment longue…

Tiens oui, en passant je peux signaluer qu'il y aussi le filtre Artistic / Engrave qu'est pas mal pour convertir une image en style plus ou moins cartoon. Par exemple :

Et la vidéo tutoriel : https://www.youtube.com/watch?v=YUWqTRS9_zk

Je vois plutôt G'MIC comme un "compagnon" à ImageMagick.
Je ne suis pas spécialiste de ImageMagick du tout, mais j'ai l'impression que G'MIC est moins à l'aise que ImageMagick pour tout ce qui est conversion entre différents formats d'images, mais plus flexible pour tout ce qui est filtrage et création d'effets personnalisés. C'est aussi les retours que j'ai eu d'utilisateurs des deux logiciels. Je serais super intéressé par une comparaison exhaustive des fonctionnalités en fait.

Oui, comme je le dis dans la dépêche, ça peut être un problème super difficile à résoudre, suivant la complexité de la texture d'entrée. Si la texture ne présente pas beaucoup d'auto-similarité, y a peu de chances que ça fonctionne de manière satisfaisante. Dans les dépêches, j'essaye toujours de mettre des exemples qui marchent bien pour illustrer l'algo, mais il est bien entendu que tous les algos présentés ne marchent pas toujours aussi bien avec toutes les images. On est bien loin de l'efficacité des Experts : Miami :)

Oui là ça devient un peu compliqué effectivement. Je vais réfléchir à la question :)

Pour le code de simulation du daltonisme, je te l'ai mis là : http://pastebin.com/UTN2vxvC
Attention, c'est écrit en langage G'MIC (le langage de script avec lequel la majorité des filtres est écrit). Tu peux voir les coefs des différentes matrices de transformation colorimétriques utilisées qui apparaissent clairement dans le code.

C'est le genre d'applications qui m'intéresse fortement effectivement. Je vais regarder le papier en détails.

Oui c'est le but. J'avoue que je n'ai pas encore essayé, je ne maitrise pas du tout Blender.

Effectivement, bonne suggestion. Je vais rajouter ce lien sur la page du plug-in.

Du coup j'en parlerai dans la prochaine dépêche :)

Bon, j'ai eu un peu de temps hier soir, j'ai fait un premier essai de filtre (disponible dans le plug-in ce matin) pour rendre une texture "répétitive".
Voilà ce que ça donne : https://plus.google.com/+GMIC_software/posts/T5NpTigcVco

Ca se base aussi sur l'algo Patchmatch bien entendu. Surement encore à améliorer, mais déjà pas si mal !

Vois la chose du bon côté : c'est en testant des trucs avec mémé Julia, qu'on peut au final utiliser ces trucs pour faire de l'inpainting, de la re-synthèse de texture et pleins de bonnes choses à venir.

Bon, tu extrapoles un peu… J'ai jamais dit que je trouvais finalement que GEGL était bien foutu hein :)
J'ai jamais été un grand fan de GEGL, mais puisqu'il faut l'utiliser pour s'interfacer avec GIMP, alors on le fait sans discuter. Mais honnêtement, je suis pas sûr que vouloir l'imposer comme norme pour les autres logiciels de graphisme ou de rendu soit une très bonne idée. Ce n'est pas une bibliothèque encore assez générique à mon goût.

C'est un peu Mitch qui m'a rassuré, et qui m'a aiguillé sur comment faire pour utiliser les buffers GEGL à partir du plug-in (mais par contre non, on a pas encore un noeud GEGL :) ).
Ca se fera peut-être un jour cela dit.

Si on trouve un moyen de financer le déplacement, oui c'est tout à fait possible effectivement.

De quelles images parlent tu ?

Je pense avoir toujours cherché mes images (autres que Lena et Scarlett) avec des moteurs de recherche donnant un choix dans la licence de réutilisation, en l'occurence "Flickr Creative Commons Search" et "Google Image", avec choix d'une licence permissive. Mais il est possible que ces moteurs m'aient renvoyé des images non autorisées à un moment donnée.

Si une photo en particulier pose problème, je peux probablement re-générer un exemple avec d'autres photos "autorisées" si besoin est.

Ce que tu affirmes est complètement faux :

• On a pas dit que CImg était une bibliothèque juste "bas-niveau", mais plus "bas-niveau" que la libgmic ce qui est quand même assez différent. Mais bon, passons…

• CImg est une bibliothèque très customisable, et peut effectivement utliser tout pleins de bibliothèques externes additionnelles comme libjpeg, libtiff, etc.. pour gérer ses entrées-sorties (possibilité qui est utilisée dans G'MIC). Aucune bibliothèque sérieuse de traitement d'image existante ne ré-implemente ce genre d'opérations de toute façon (je parle bien de bibliothèques de "traitement", pas juste de gestion d'un format d'image). Mais de toute façon, CImg peut aussi se compiler avec un minimum de dépendances si besoin est (avec juste libm et libc, c'est assez "bas-niveau" ça va ? :) ) pour permettre de travailler juste avec des buffers de données en entrées-sorties comme tu le suggères. D'ailleurs c'est ce qui est fait dans la configuration par défaut de CImg, aucune dépendance autre n'est nécessaire, il faut au contraire les activer de manière explicite pour en profiter. Donc je ne sais pas d'ou tu tiens ton affirmation. Va voir le Makefile des exemples de CImg, tu verras qu'on peut activer/désactiver chaque dépendance de manière très fine.

Oui, en fait générer une texture tuilable peut être vu comme un problème d'inpainting des bords, avec des conditions aux bords périodiques. Ca peut se faire dans G'MIC effectivement, c'est une bonne idée pour faire un filtre "Make Seamless Texture". Je vais essayer de bidouiller ça quand j'aurais un moment.