David Tschumperlé a écrit 337 commentaires

De mon point de vue, ce ne sont pas les logiciels qui sont professionnels, mais les personnes.

Tellement vrai!

Corrolaire : Les personnes affirmant qu'un logiciel n'est pas "professionnel" s'avèrent souvent être des amateurs peu compétents dans leur domaine.

Cet argument de logiciel "non-professionnel" est malheureusement très fréquemment brandi par les partisans du logiciel non libre, quand on fréquente les forums généralistes en graphisme ou photographie.

Bonjour,

J'ai eu des besoins similaires il y a de cela quelques années (22 ans pour être précis…), et j'avais alors commencé l'écriture d'une "petite" bibliothèque C++ pour le traitement des images : CImg, qui a l'air de pouvoir faire ce que vous proposez (et même un peu plus ☺, mais depuis le temps, ce n'est pas forcément étonnant).
Cette bibliothèque existe encore et je continue d'ailleurs à la maintenir activement.
N'hésitez pas à y jeter un œil, peut-être vous y trouverez un intérêt ? (la version 2.9.9 vient justement de sortir il y a quelques heures).

Ce qui est amusant, c'est que faire exactement l'inverse de tes recettes est sans doute la voie la plus rapide pour devenir homme ou femme politique.

Aux dernières nouvelles, les plug-ins tiers de GIMP ne fonctionnent pas sous Glimpse.
J'imagine qu'ils ont aussi dû renommer les fonctions de l'API de plug-in de GIMP pour mettre du '_glimpse' un peu partout, et que ça a pêté la compatibilité ?

En tout cas, pas de plug-in G'MIC dans Glimpse, et ça enlève aussi beaucoup de son intérêt :)

Je tiens encore à remercier l'équipe de LinuxFR pour cette sympathique attention. J'essaierai d'écrire une dépêche plus courte la prochaine fois, pour faciliter le travail de relecture :)

(désolé pour mon commentaire un peu "bateau", mais néanmoins sincère).

Pour être plus précis sur ce point.
Formellement, il est faux d'affirmer que le CNRS finance Jehan pour travailler sur GIMP ou sur ZeMarmot.
(en particulier, Jehan ne reçoit pas de sous du CNRS via ses campagnes de dons Tipee ou via l'association LILA!).

Jehan est sous contrat d'ingénieur de développement au laboratoire GREYC (UMR CNRS 6072), situé à Caen. C'est un CDD d'un an fourni par l'institut INS2I du CNRS, en réponse à l'appel à manifestation "Soutien Plateformes" de 2018.

J'ai réussi à obtenir ce financement pour l'aide au développement du projet G'MIC, logiciel open source de traitement d'images développé au sein du GREYC/CNRS par moi-même et un collègue du laboratoire.

Il s'avère que nous avons des besoins pour le projet G'MIC qui sont compatibles avec le fait d'améliorer GIMP, ce qui est tout à fait satisfaisant pour nous (Jehan et moi-même), mais ça serait un raccourci un peu hasardeux d'affirmer que le CNRS finance volontairement le développement de GIMP. Le fait que G'MIC propose un greffon a priori très utilisé pour GIMP fait qu'on a clairement des intérêts communs à ces deux développements libres.

Quant à regretter l'utilisation faite de vos impôts, c'est encore autre chose, mais je peux au moins affirmer que le projet G'MIC n'existerait pas en tant que tel sans le CNRS (et vos impôts), car si on a pu se permettre de le développer (depuis plus de 10 ans maintenant) et de le distribuer sous licence libre, c'est aussi grâce au CNRS (et sa délégation Normandie, que je salue au passage).

Sur ce, j'arrête de répondre sur cette news. J'ai un peu l'impression de trop l'accaparer en hors-sujet là, alors que c'est censé parler de ce super logiciel qu'est G'Mic. :-)

Qui sera bientôt très facile à installer dans GIMP apparemment, grâce au nouveau gestionnaire d'extensions :)

Comme je le disais, G'MIC a doit beaucoup à GIMP (et Krita), donc avoir des infos directs de la source, c'est plutôt sympa.

OK, alors mauvaise nouvelle : on a jamais réussi à faire tourner le greffon G'MIC-Qt pour GIMP 2.10 installé avec flatpak.
Pour ma part, je fais mes tests avec une install de GIMP 2.10 fourni sous Ubuntu avec ce PPA, et le greffon G'MIC-Qt fonctionne bien avec GIMP 2.10 (mais j'avoue aussi que je le recompile moi-même sur ma machine).
Donc on sait que ça fonctionne pour GIMP 2.10 sous Linux (et Windows également).

Mais avec une install Flatpak de GIMP, on ne sait pas ce qui se passe, il y a des soucis au niveau des bibliothèques. C'est embêtant car on sait qu'il y a pleins de personnes qui ont installés GIMP 2.10 avec Flatpak, du fait que la version 2.10 n'est pas disponible dans les dépôts des distributions en général.

Donc pour le moment, j'ai pas de solutions, j'en suis bien désolé !

Ha oui, je crois que c'était le seul lien cassé, merci de l'avoir remarqué :). Ca devrait être corrigé maintenant !

Pour la traduction, on essaye effectivement d'avoir une version anglaise de l'article pour publication sur le site de nos amis de Pixls.us. Toute aide est plus que bienvenue !

Une des nouveautés que je préfère dans GIMP 2.10 est l'aperçu des filtres directement sur le canvas. Est-ce que cela est possible avec les filtres de G'MIC ?

Non ce n'est pas possible. Le greffon possède déjà une grande fenêtre de prévisualisation, donc on ne voit pas trop la valeur ajoutée d'autoriser l'aperçu on-canvas (on peut déjà agrandir la fenêtre de prévisualisation et/ou zoomer l'image dans celle-ci si besoin est).
Au contraire, la prévisualisation on-canvas n'est clairement pas adaptée pour les filtres de traitements un peu complexes, qui nécessitent pas mal de calculs, car cela nuit in fine à l'interactivité générale. Il vaut mieux dans ce cas pouvoir effectuer les traitements plutôt sur de petites portions d'images pour prévisualiser le résultat.

Pour ma part, je trouve donc que l'idée d'adopter systématiquement une prévisualisation on-canvas n'est pas excellente. Je préfère avoir un widget de prévisualisation dédié à cette tâche, de taille réglable, qui permet bien plus de flexibilité.

Quid des calques d'effets et de l'édition non destructive qui devraient arriver un jour ?

L'édition non-destructive aura a priori le même genre de limitations. Tant qu'on restera sur des effets "simples", peu coûteux en temps de calcul (genre mixeur de canaux couleurs ou déformations simples), alors ça va pouvoir se gérer. Mais pour des traitements d'images complexes ("inpainting", débruitage d'images avec des algos avancés, etc.), on va surement pas trop avoir envie de proposer ça en non-destructif, où je me dis que l'expérience utilisateur deviendra catastrophique : attendre 5-10 minutes qu'un calque non-destructif se remettre à jour est surement pas quelque chose qu'un utilisateur est prêt à supporter :)

Je me demande s'il est possible d'exporter le model de la main en 3D (facettes) ? pour une réutilisation dans blender par exemple.

On peut a priori juste sauver une triangulation réalisée par G'MIC sous la forme d'un fichier .off. Après, importer ça sous Blender je ne sais pas si c'est facile, j'avoue que je n'ai jamais essayé.

Faire du pixel art à partir d'un dessin ou d'une photo ? C'est assez différent.
Dans les deux cas, les propriétés de ce genre de rendu, c'est une résolution basse et peu de couleurs, ce qui est fait par le filtre actuel '8bits'.

J'ai moi même siégé au CNU 27 (en tant que suppléant nommé) lors de l'investiture précédente, et cette impression de sous-évaluation de la production logicielle vient aussi en partie de cette expérience :) Tu le dis toi même :

Ils (les logiciels) peuvent compter comme de la production scientifique au même titre qu'un brevet (déposer son logiciel à l'APP peut être une bonne idée dans ce cas), mais pas tout à fait au même niveau qu'une publication

Alors, combien de temps pour écrire une publi considérée comme aboutie, from scratch ? En général, en informatique, moins de 6 mois, tout compris. Combien de gens ça touche (lecteurs potentiels) ? Quelques dizaines, au mieux quelques centaines (et dans ce cas faut vraiment faire un très bon papier!).
Maintenant, combien de temps pour écrire un logiciel considéré comme abouti ? Quelques années ! Combien de gens ça touche (utilisateurs potentiels) ? Quelques milliers !
On nous bassine pour l'évaluation avec des métrique d'"impact factor" ici, de "H-index" là, et on continue à entendre qu'un logiciel largement diffusé et utilisé, ça compte moins qu'une publi !! C'est à pleurer.

Alors oui, ça va pas être forcément le même public concerné (d'un côté des scientifiques purs, de l'autre côté, le grand-public), mais il me semble qu'au niveau "mission service public" c'est quand même pas inutile de faire un logiciel largement diffusé, c'est surement même plus utile que d'écrire un n-ième papier que 8-10 personnes tout au plus vont lire. Et qu'on me dise pas que développer un logiciel c'est pas de la recherche mais de l'ingénierie…

La publication scientifique a trop longtemps été le critère majeur d'évaluation de l'activité des chercheurs, et on voit ce que ça a donné : sur-multiplication des conférences et des publications (une même idée, publiée 10 fois de suite, un grand classique), création de métriques à la mords-moi-le-noeud, ranking des conférences et des journaux (ces deux liens sont très très connus des gens de la CNU27, c'est même ce qu'on apprend en premier quand on relit nos premiers dossiers :)). Les grands gagnants : les éditeurs. Bref on peut pas parler de grande réussite morale.

Je n'ai évidemment pas de recette miracle pour évaluer l'activité des chercheurs, mais je vois quand même que la tendance c'est de prendre de plus en plus en compte les activités "autres" que la publication pure et dure d'articles scientifiques (en tout cas, ça semble être le cas au CNRS, section 07). Je crois néanmoins que la production de logiciels est encore sous-évalué par rapport à : 1. l'effort que ça demande, et 2. le rayonnement que ça peut apporter à un labo. J'espère juste que ça va évoluer dans le bon sens. Mais clairement aujourd'hui, pour sa carrière, mieux vaut écrire 10 publis sur 10 ans plutôt qu'un logiciel.

Oui effectivement, à l'époque c'était carrément courageux de te lancer là dedans :)
Aujourd'hui les choses devraient être un peu plus simple je pense (mais non triviales quand même), du fait des améliorations significatives qu'a connu l'évaluateur d'expression mathématiques intégré.
Faudrait peut-être que je m'y replonge quand j'aurais un moment (autant dire que c'est pas gagné :) ).

Je n'ai pas regardé le code/la taille générale des bibliothèques, est-ce lourd à embarquer ?

Tout dépend de ce qu'on appelle "lourd", mais pour info, la libgmic compilée fait moins de 6.5 Mio, ce qui semble raisonnable pour une utilisation sur application mobile. Cette bibliothèque comprends l'ensemble des implémentation des filtres de G'MIC (mais rien concernant l'interface graphique).
Un exemple d'utilisation de l'API C++ est dispo ici : http://gmic.eu/libgmic.shtml

D'autre part je me demandais si ça pouvait être utilisé pour générer un Diaporama vidéo (par exemple en donnant un effet photo papier, ou vieux film) ?

Oui tout à fait. Ca semble adapté pour ce genre de choses.

La doc "collaborative" est ici : https://github.com/dtschump/gmic-community/wiki
Il y a déjà 2 articles sur l'explication de filtres dans le plug-in, l'idéal serait d'enrichir cette doc avec des pages explications certains filtres intéressants ?

Merci Jérôme pour ces gentillesses.
En ce qui concerne le développement d'un logiciel libre au sein d'un labo de recherche public, je ne peux parler que de mon expérience personnelle, qui n'est pas franchement négative : Après presque 10 ans de développement, on a atteint un stade où on se sent quand même très soutenu moralement par la direction du laboratoire, et par les collègues.
On peut quand même mentionner quelques petits points noirs qui pourraient s'améliorer (et qui vont le faire avec le temps, j'en suis persuadé) :

1 - Les possibilités d'obtenir des aides financières spécifiquement pour le développement de logiciels libres ne semblent pas encore très variées, si on les compare avec les instruments qui existent pour financer la recherche en général (RIN, ANR et consorts).
2 - En parallèle, il est difficile de mettre légalement en place des systèmes de dons ou de campagnes de financements participatifs pour aider au développement (achat de matériel, stage…). Ce n'est pas quelque chose qui apparemment se fait très souvent pour un labo de recherche.

Donc les points 1 + 2 font qu'on peut pas vraiment obtenir de source de financement pour le développement du logiciel, et cela même si on avait des centaines/milliers d'utilisateurs prêts à donner un peu de sous (sur une plateforme de type Patreon/Liberapay par exemple). Je ne dis pas que c'est le cas hein, juste que de toute façon ça semble pas possible.

3 - Par ailleurs, on a la forte impression que l'activité de développement de logiciels (libres en particulier) n'est que très peu valorisé lors de l'évaluation de notre activité de recherche par nos pairs. Si encore le logiciel générait des revenus (vente de licence d'exploitation à une entreprise par ex), alors ça serait surement mieux perçu. Mais pour du logiciel libre… J'entends souvent dire qu' "un logiciel compte comme une publication", ce qui fait un peu mal au coeur, car si on compare le temps passé à écrire une publi, et à développer/s'occuper d'un logiciel (comprenant la maintenance et toute l'activité autour)…
Mieux vaudrait s'empêcher d'écrire du logiciel libre pour bien réussir sa carrière!

1. De manière plus anecdotique : j'ai pu entendre deux trois remarques que je qualifierais d'étranges (pour rester poli), mais c'est surement du classique du genre : "mais si vous avez des milliers d'utilisateurs, pourquoi vous les faites pas payer 1 euro par téléchargement ?", ou encore "y a pas de différences fondamentales entre la CeCILL et la CeCILL-B" (venant d'un prétendu spécialiste des licences logicielles). (Pour ceux qui connaissent pas trop les licences CeCILL, ça revient à dire que les licenses GPL et BSD c'est la même soupe).

Voilà, mais à part ça, rien de bien grave. On fait avec ce qu'on a, et on continue quand même :)

Oui, la doc est encore incomplète. J'avoue que j'ai du mal à m'y mettre, en plus de développer de nouveaux filtres, d'améliorer le code existant, de répondre aux questions des forums, sans compter que j'ai aussi un travail à assurer en journée :)
Mais toute aide est bienvenue !

Oui je me rappelle que l'an dernier j'étais en conf sur les même dates. Et cette année, j'essaye de limiter mes déplacements au maximum, pour diverses raisons.
Je pense toujours que j'aurais plus de temps l'an prochain (et ça se vérifie jamais en fait).

Auriez-vous des conseils, déjà pour bricoler un prototype, et puis pour optimiser la vitesse de rendu (en limitant les interprétations redondantes de script, les allocations et copies de buffers, les conversions d'images…) ?

Oui, surement des idées. Un petit mail pour amorcer la discussion ? :)
Il faudrait déjà regarder si vous préférez utiliser l'API C++ (libgmic) ou C (libcgmic).
Après, pour limiter les allocations/copies de buffer, il n'y a pas trop de miracle possible, sauf si vos buffers images utilisent exactement le même format que celui de G'MIC (et c'est peu probable!).
Je peux en tout cas déjà conseiller des choses à tenter (ou pas!).

…dont le nom apparaissait dans cette affaire relayée par Me Eolas :

http://www.maitre-eolas.fr/post/2010/12/26/Lrsquo%3Baffaire-ldquo%3Bla-carte-et-le-territoirerdquo%3B

Ah d'accord, c'est parce que tu prononçais mon prénom "géant", donc forcément avec la bonne prononciation, je pouvais pas comprendre cette blague phonologique!

Ha OK merci pour la précision, je pensais qu'on pouvait le prononcer comme si il y avait un accent.
D'ailleurs, d'après la page wikipedia, la version avec accent sur le 'e' existe également (mais ce n'est pas une excuse, je ne l'ai vue qu'après ;)).

Ahahah! C'est gentil, mais je suis pas vraiment connu! Quant à un "Hall of Fame", on verra. Y a même pas Mitch dans ton lien, pourtant le mainteneur actuel, contributeur GIMP depuis 20 ans cette année, qui a lui seul a écrit presque le tiers de GIMP, alors avant de m'y voir moi (sans compter l'injustice si j'y étais pour représenter GIMP quand il n'y est pas)

Oui clairement Mitch devrait y figurer aussi, pas de doutes là dessus ;)

à l'époque j'étais encore plein d'espoir et je pensais que ça monterait plus vite… avant d'être désillusionné rapidement) avec la 2.10 si ZeMarmot avait eu le financement pour qu'Aryeom et moi bossions à temps plein sur le projet (même juste 2 SMICs) puisque c'était mon second projet majeur sur GIMP core, à côté du plug-in d'animation.

Oui, c'est aussi pour ça que je trouve remarquable que tu continues à prendre autant de ton temps pour contribuer à un logiciel open-source, alors que ceux qui te suivent savent très bien que c'est un peu au détriment de ton niveau de "salaire". Je pourrais dire la même chose pour Boud, le mainteneur principal de Krita qui abat un boulot phénoménal sans avoir un minimum salarial décent. Faut vraiment que vous soyez passionnés, c'est admirable/épatant.
Vous avez tout mon respect.

Salut Jehan (de l'open source!).

J'ai essayé de comprendre si y avait une blague, mais je trouve pas. Bon je suis au réveil et j'ai le cerveau un peu embrouillé! ;-)

Oui c'est parce que j'ai un humour spécial (que j'assume parfaitement d'ailleurs :)), donc il fallait comprendre 'Géant de l'open source'. Et surement aussi parce que je considère que les contributeurs (comme toi) de logiciels majeurs de l'open-source (tels que GIMP) sont des personnes notables qui marquent l'Histoire informatique à leur manière. Donc 'Géant' ça me parait pas complètement usurpé.

D'ailleurs, à ce propos, as-tu vu cette page : Faces of Open-Source ?
C'est une sorte de Hall of Fame de tous ces géants/pionniers de l'open-source, tu y figureras peut-être un de ces quatres ? ;)

Tu es sûr que tu as regardé mes vidéos? :P

J'avoue, j'ai regardé vite fait, donc j'ai du rater quelques détails. Merci pour tes réponses précises, le plug-in d'animation a l'air vraiment alléchant. Ca sera intégré dans GIMP 2.10 ou tu veux garder ça comme plug-in 'externe' ?

Donc ça converge, oui. Et c'est normal, selon moi, sauf à vouloir artificiellement se créer soi-même des limitations pour répondre absolument à une "vision du projet".

Je suis plutôt d'accord. Je pense qu'à l'époque où cette vision de projet pour Krita a été décidée, ils voulaient vraiment essayer de se démarquer, peut-être en partie pour justifier leurs campagnes de crow-funding, mais surement aussi pour d'autres raisons. Le fait est que ça me semble avoir plutôt bien marché en termes de 'communication' (d'ailleurs Krita 3.2 sort aujourd'hui, soit dit en passant).
Mais c'est vrai que d'un point de vue purement 'technique', les fonctionnalités entre les deux programmes ont l'air d'être de plus en plus proches (support du 16bits, outils d'animations).

Salut Jehan (de l'open source!).
Quelques petites questions de curieux en passant :

1. En regardant vite fait les copies d'écrans et les videos que tu fournis, j'ai l'impression que chaque frame de ton animation peut etre composée d'un layer d'arrière plan (toujours le même à priori) + un layer d'avant-plan (qui contient les objets en mouvement). Est-ce que c'est une limitation ou juste une impression ? Je ne m'y connais pas en techniques d'animation mais penses-tu qu'il peut être utile de considérer potentiellement chaque frame comme un groupe de calque, et est-ce que ton plug-in gère ces cas génériques ? On peut imaginer par exemple avoir un fond qui bouge (défilement par exemple), avec une animation en avant-plan. J'imagine que tu as déjà pensé à tout ça.

2. Krita s'est récemment doté d'outils similaires pour gérer des animations, est-ce que c'est quelque chose qui t'a inspiré ou avais-tu commencé ton travail sur le plug-in d'animation avant cela ? Suis-tu les développements de Krita à ce sujet pour te donner des idées supplémentaires ? N'as tu pas l'impression que Krita et GIMP convergent de plus en plus vers deux logiciels similaires ?

Bravo pour le gros travail en tout cas (code, mais aussi tout ce qu'il y a à côté).

Merci pour le rappel de la conférence RMLL, très instructive.
Et encore bravo à toute l'équipe pour votre travail quotidien!