On était le stand juste à côté de linuxfr au village du Libre, et ça… c'est cool! :-)
Merci à Linuxfr pour cette photo (postée sur leur compte Twitter) car on n'est vraiment pas doué et on n'a quasiment pas fait de photo (ou alors de très mauvaise qualité sur vieux téléphone).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui bien sûr, je peux répondre. La prochaine sortie est à compter en [bzzz bzzz interférences bzzz bzzz]. ;-)
Plus sérieusement, je n'en ai aucune idée. On peut essayer de pousser mais au final le mainteneur choisit. Aussi GIMP 2.10 est dans une situation très particulière avec le passage à GEGL. Nous avons quelques fonctionnalités "cassées" par ce port, et s'il y a bien une chose que les utilisateurs ont du mal à encaisser, ce sont les régressions.
En tous cas, je suis moi-même complètement "pour" qu'on arrive à accélérer les sorties, comme je le dis dans l'interview. Et j'ai fait rajouter l'item "proposition de passer en mode sortie rapide" pour notre réunion à LGM 2014. Ce qui en est ressorti, c'est que les autres dévs ne sont pas contre, mais cela devra commencer à partir de GIMP 3.0, à cause du passage à GEGL, puis du passage à GTK 3.0. Après ces 2 ports, je pousserai vraiment pour passer à des sorties rapides, et qu'on adapte notre infrastructure de tests et de sortie s'il le faut.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Comme souvent, une question de choix de mots peut avoir des conséquences importantes.
Tu viens d'écrire sauver/exporter alors que je vois enregistrer/exporter dans les menus.
J'utilise la version anglaise, et j'ai juste fait une traduction perso (et mauvaise) de save/export. En VF, enregistrer/exporter ne me choque pas comme étant la bonne trad.
Ensuite de manière générale, ce que tu dis sur les mots est juste. Comme on le dit en général dans le développement d'application (à moitié blague, à moitié sérieux), le plus dur en informatique, c'est de nommer les choses (le code lui-même comme le texte visible d'ailleurs).
Par contre cela ne s'applique qu'à moitié au problème ici, puisqu'il n'est pas spécifique à la VF. Et je doute sincèrement que si on utilisait sauver/exporter, soudainement tous les francophones contre la fonctionnalité disent soudainement "ah ok je comprend mieux, c'est bon alors" (mais je veux bien me tromper). Par contre on aurait soudainement beaucoup de nouveaux en colère parce que "sauver" est un faux-ami et pas la bonne traduction pour "save". On sauve quelqu'un qui est en danger, on ne "sauve" pas du travail.
Tout ça pour dire que j'ai simplement fait une erreur de traduction dans mon commentaire, et je ne pense pas vraiment que rendre mon erreur de trad officielle soit la vraie solution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
À cheval dans la steppe on a la même sensation qu'à moto visiblement, le trot c'est essoufflant, le galop ça plane.
Bon ça c'est une spécificité générique de l'équitation, dans la steppe ou ailleurs, aucune différence. Le trot, c'est toujours inconfortable. Pour être confortable, il faut soit aller au pas, soit au galop (mais là aussi il y a une forme de frayeur). Par contre un cheval ne peut pas non plus galoper trop longtemps (c'est comme si on nous demandait de courir à fond tout le temps, j'imagine). C'est pourquoi en général, voyager à cheval, ça signifie surtout voyager au pas. C'est pas énormément plus rapide qu'à pied (mais moins fatigant).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je me doutais en regardant la photo que c'était la steppe de Mongolie. Ça a du influencer le projet marmotte non ? :).
Dans le sens où y a des Marmottes en Mongolie? Dans ce cas, non, car j'avais déjà ma Marmotte avec moi. Si tu regardes bien sur la photo, tu peux voir une petite peluche sur le guidon: mon copilote la Marmotte! Mais sinon oui, on voit régulièrement des marmottes dans ces coins de l'Asie centrale (pas les mêmes que les européennes).
Dans le sens où le film parle de vagabondage? Dans ce cas, oui forcément, c'est lié. J'aime me balader, donc j'en parle. J'aime les histoires d'aventure, donc c'est ce que j'écris.
n'ai pas encore eu l'occasion de goûter à la marmotte. Est-ce qu'elle est très salée comme le mouton ?
Franchement je ne pense pas avoir jamais mangé de la marmotte (enfin j'espère!). Ensuite j'ai mangé des trucs non identifiés en Mongolie, notamment un jour où j'ai été hébergé dans une yourte après avoir fait chuté la moto en traversant une rivière (donc le moteur était inondé, me forçant à des réparations de fortune).
De manière générale, il me semble que les gens mangent surtout ce qu'ils élèvent. Certaines familles ont des moutons, donc ils mangent surtout du mouton et boivent du lait de brebis. Ceux qui ont des chèvres, pareil. Et ceux qui ont un troupeau de yak pareil. Les chevaux, pareil. Etc.
En tous cas, c'est quasi essentiellement une nourriture à base de viande rouge (pas beaucoup de verdure; jamais non plus de poisson a priori, même s'ils ont des lacs et des rivières; et du lait en boisson, fermenté ou non, plutôt que de l'eau…).
les longs trajets dans la steppe toute plate et ne pas s'endormir au volant comme le chauffeur du film Urga :).
Alors j'ai pas vu ce film, mais en vrai c'est loin d'être de tout repos. Il n'y a pas de route, c'est que du sable à perte de vue. Et dans ce contexte, le sol est loin d'être "plat". Il en a l'air, et il l'est "globalement", mais dans le détail, c'est juste une succession de bosses et de trous, parfois très dangereux. Je devais m'arrêter environ toutes les heures et faire le tour de la moto avec un tournevis pour repérer et revisser les diverses vis qui se dévissait par les vibrations seulement. J'y allais avec toutes mes forces possibles, mais même là, ça se dévissait encore. Et j'en ai perdu quand même pas mal dans le process.
Pour la petite histoire, j'ai dû perdre une bonne vingtaine de vis sur la moto, et le garage où j'ai fait révisé/réparé la moto au Japon a trouvé même quelques vis internes tombées au fond du moteur (j'ai eu de la chance donc que ça me pête pas à la figure; et évidemment ces vis là, je pouvais pas les revisser moi-même).
Quand tu conduis en Mongolie, au Kazakhstan, ou même en Russie, tu as 2 choix: rouler très lentement (40/50 km/h), et dans ce cas, c'est extrêmement inconfortable (tout tremble constamment), mais c'est plus sûr; ou tu vas vite, et à ce moment, il y a un palier (vers les 90 km/h) où tu te mets à "voler" au dessus des trous. Il n'y a plus de tremblement, ni de vibration excessive (enfin si, mais bien plus confortable), tu n'as plus mal. Par contre c'est très effrayant et tu dois garder une concentration très appuyée pendant toute la conduite (tu te prends un trou un peu trop grand que tu n'as pas vu venir dans ces steppes, à l'allure lisse de loin sous le soleil, et c'est fini pour toi. Y aura probablement personne pour te venir en aide).
Très vite, on se met à prendre ce second choix, car conduire des jours en vibrant et en ayant mal partout, c'est peu tenable. Mais alors on fatigue aussi très vite (conduire bien, c'est à dire concentré et avec sérieux, c'est pas reposant!).
Enfin voilà, tout ça pour dire: non tu t'endors pas au volant. Et quand ça arrive, c'est qu'il est l'heure de s'arrêter, faire une pause, voire de sortir le sac de couchage si c'est le soir.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Il aurait être jsute fallu attendre d'avoir la nouvelle UI pour éviter les remarques négatives ;)
En même temps, l'UI est la partie visible de l'iceberg. Il reste que le format XCF suit parfaitement les fonctionnalités de GIMP et donc est le seul format de projet valable pour du travail en cours. La haute précision ou le non-destructif ne sont pas encore là, mais il y a déjà foultitude d'autres fonctionnalités qui nécessite XCF.
Par exemple quel format garde la sélection en cours? (permettant de commencer à travailler sur une sélection complète, la laisser en suspens, sauver le fichier, et y revenir plus tard là où on en était)
Quel format bitmap a aussi des notions (basiques certes, mais existantes) de vectoriel?
Quel format garde aussi des masques de calques?
Quel format garde des calques de texte?
Très peu de format ont même la notion de calque tout court.
Peu de format ont la prise en charge de la transparence (et quand ils l'ont, pas forcément avec la précision de GIMP).
Etc. etc. etc.
Je ne prétends pas connaître tous les formats et certains ont peut-être certaines de ces notions, mais aucun format n'a tout ce que fait GIMP (seul XCF puisqu'il est calqué sur les fonctionnalités).
En fait, je n'étais pas présent dans la période d'avant la séparation sauver/exporter, mais je sais qu'il y avait énormément de personnes qui venaient se plaindre car ils avaient perdus une partie de leur travail en "sauvant" dans un format d'image classique (que ce soit PNG ou jpg).
Par exemple, le classique, ils rajoutent du texte au dessus d'une image, exportent en PNG (car on leur dit "PNG est non destructif"), et — paf! — le texte devient une image non éditable! Après ils viennent se plaindre que le texte ne peut plus être corrigé, qu'ils doivent tout refaire de zéro et ont perdu des heures de travail.
Il faut donc bien comprendre: on sauve son travail en cours, et on exporte un "cliché" à un instant T. Comme on exporterait une vidéo en mpg/avi/whatever, ou encore on compilerait un binaire exécutable à partir d'une source texte. L'export c'est pour l'instantané prêt à la diffusion/utilisation. La sauvegarde, c'est le projet, le travail.
Le changement d'UI sera la cerise sur le gâteau, absolument pas le cœur de la fonctionnalité. Et il faut changer le cœur avant de rajouter la cerise (un peu comme GEGL, la prochaine version aura un nouveau cœur mais l'UI ne le réflètera pas encore, c'est à dire pas d'édition non destructrice visible. Ça arrive forcément après).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Merci à toi, j'espère pouvoir te rendre la pareille, un jour.
De rien. Si vraiment tu veux absolument m'aider et que tu as un peu de sous, contribuer au projet ZeMarmot est le moyen idéal de le faire! :-)
Non seulement il permettra de faire un film d'animation vraiment cool — et en plus Libre! — mais en plus ça me fera utiliser plus de temps pour améliorer GIMP. :-)
Enfin je dis ça… j'dis rien hein! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'ai partagé mon retour d'expérience dans une communauté sur ton provocateur car j'étais "énervé" (très déçu plus exactement) en lisant l'interview car des choses très évoluées sont intégrées à GIMP (ce qui est une bonne chose) mais qu'à côté des détails peuvent "ruiner" (c'est exagéré) l'expérience utilisateur.
Ok. Pas de problème. Je vais donc répondre ce que je voulais dire l'autre jour.
Pour "Sans", il s'agit d'un alias qui était un alias par défaut de fontconfig. Cela permet de choisir la police Sans-serif par défaut de ton installation. Autrement on ne peut pas vraiment savoir quelles polices sont installées sur ton ordi, chaque OS/distribution ayant des différences (mais on sait que chaque OS aura au moins une Sans-serif par défaut et qu'il comprendra l'alias.
De nos jours ceci dit, c'est renommé "Sans-Serif" et "Sans" existe toujours mais est déprécié (j'ai regardé un peu le code de fontconfig et c'est ce que j'ai constaté). Je proposerai donc le changement chez nous aussi.
Le second truc auquel je ne m'étais jamais vraiment penché jusque là, c'est effectivement que ce serait mieux si on pouvait agrandir la liste déroulante. Par contre je regarderai d'abord si c'est déjà faisable sous GTK+3, et si c'est le cas, c'est possible que nous ne passerons pas trop de temps dessus (car on sait que ça marchera pour GIMP 3, ce qui n'est pas pour tout de suite, malheureusement).
En tous cas, j'ai bien pris en compte les remarques. Ensuite c'est toujours mieux et constructif dans une relation aimable entre les êtres humains que nous sommes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Perso, la séparation me convient très bien, et si Gimp poursuit son évolution (images sans pertes, etc.), je comprendrai encore davantage la logique d'avoir deux options, l'une destinée à l'enregistrement et au travail, l'autre à l'utilisation finie d'une image.
Tout à fait!
C'est exactement cela. Les "images" GIMP (XCF) sont à considérer comme des projets en cours. Un format de travail. Ce n'est pas à considérer comme un standard (ce n'en est pas un), cela suit les évolutions logicielles de GIMP même, et ne peut être comparé à un format d'image (PNG, JPG, whatever…).
C'est comme Blender. Enregistrer, c'est du .blend (le format de travail qui suit les logiques logicielles de Blender). Ça n'empêche pas d'exporter en Collada (le standard pour la 3D) ou d'autres formats (souvent proprios).
En effet comme tu le notes, l'édition sans perte est une des énièmes très bonnes raisons: les formats d'image n'ont de concept de calque d'effet. Il faudra donc du XCF (enregistrer en PNG, jpg ou autre impliquera d'appliquer les effets et donc perdront de l'info). De même que la haute précision de couleur (PNG par exemple prend en charge jusqu'à 16 bits. GIMP ira bien plus haut).
Enfin il y a l'UI elle-même. À l'heure actuelle, on s'est contenté d'utiliser la même UI (puisque historiquement c'était la même chose), et donc ça perturbe les utilisateurs qui se disent "ben c'est la même chose". C'est compréhensible. Mais l'idée c'est qu'à l'avenir on aura 2 UIs différentes et adaptées. En fait j'ai même déjà du code stash-é qui commence le travail, mais faut que je trouve le temps de finir.
Par exemple beaucoup de gens demandent une gestion de "l'export pour le web", c'est à dire notamment changer la résolution d'une image très haute rés, appliquer éventuellement quelques filtres, etc. À l'heure actuelle, on doit faire ce genre de choses dans l'image même, puis surtout ne pas oublier de les annuler après export de l'image (pour ne pas engendrer de perte de qualité, surtout quand l'image est aussi destinée pour de la haute résolution). Ben je pense que ce genre de choses devraient être faisable aisément dans une UI séparée qui gère ce genre de choses (comme un graphe d'effet à appliquer seulement dans un mode d'export particulier qu'on peut sauver).
Ce sont des exemples mais on peut en trouver beaucoup d'autres. Sauver et exporter sont vraiment des processus très différents. Simplement nous n'avons pas encore l'UI. C'est la base de cette évolution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
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).
Oui et non. Oui, ça limite l'intérêt, et notamment clairement la prévisualisation en directe pourrait devenir une véritable plaie (bloquant l'UI et empêchant de configurer correctement son filtre si à chaque fois qu'on affleure même un slider, on doit se taper une prévis).
Ensuite non, la non-destructivité est quand même utile (selon moi) pour les filtres longs. Du moment qu'on gère bien toute la partie ennuyante (comme la prévisualisation, en ne l'autorisant pas sur certains filtres), il reste tout de même d'autres avantages bien réels. Par exemple, tu parles de changer le paramètre d'un filtre. Ben dans ce cas là, même avec la méthode destructive (annuler, refaire le filtre), on doit se retaper les 15 minutes de traitement du filtre. Ben au moins avec la méthode non-destructive, on peut le faire n'importe quand, même après plusieurs heures de travail et des centaines d'autres actions faites entretemps; donc revenir sur l'historique — si possible, des fois ça ne l'est même pas — en revient à perdre des heures de travail.
Avez vous prévu quelque chose de spécial dans ce cas ?
Je ne suis pas certain, mais il est clair que nous ne laisserons pas ce genre de problèmes arriver (ou par erreur, et dans ce cas là, ce sera à considérer un bug à corriger). Il faudra les traiter. Je peux imaginer plusieurs choses.
Déjà la détection: on peut ajouter une notion de coût (théorique, comme un paramètre disponible en introspection) à une opération (il me semble me rappeler que cela a d'ailleurs déjà été discuté sur IRC). Ainsi avant même de commencer une opération, on peut avertir l'utilisateur que la prévisualisation risque d'être longue pour certaines opérations (voire même l'interdire pour des opérations qu'on sait vraiment vraiment trop longue), ou bien même pour toute opération si on l'exécute sur une image de vraiment trop grande taille. Ensuite on peut aussi avoir, en plus, un timer qui prend la main quand une prév dure trop longtemps, et donne la possibilité à l'utilisateur de l'interrompre.
Ensuite comment gérer ces ops trop longues?
1/ On peut donc simplement interdire la prév automatique comme je disais.
2/ Mais on peut aussi permettre une prév explicite avec un bouton dans ce cas. C'est à dire que ça ne va pas re-rendre le résultat juste en bougeant un slider d'un micromètre (bon moyen de rendre une UI inutilisable). Par contre, l'utilisateur peut bouger ses boutons et sliders tranquillement, puis cliquer sur un bouton, aller prendre un café et revenir voir le résultat après 15 minutes. Éventuellement refaire des changements, etc. Ou sinon appliquer (ce qui sera instantané puisque tout est déjà calculé).
Cela reste toujours légèrement plus pratique et rapide que d'appliquer, annuler, rouvrir l'UI de plugin, réappliquer, réannuler… Pas énormément différent, hein. Mais un peu, selon moi.
3/ L'utilisateur peut supprimer la visualisation d'un filtre (avec l'icône "œil"). Ça permet de l'appliquer au début, mais ensuite de l'empêcher d'actualiser sans cesse la vue (surtout si on prévoit de peindre sur le calque de base, etc.).
4/ On peut aussi permettre d'appliquer un filtre (ou une liste de filtres) directement sur l'image (c'est à dire en destructif comme maintenant). En fait j'en ai jamais discuté avec les autres, mais personnellement cela me paraît une fonctionnalité évidente.
Il y a toujours des cas où appliquer un filtre est mieux, voire nécessaire. Par exemple si on souhaite peindre directement sur le rendu (et non sur le calque de base, ni sur un autre calque au dessus), il n'y a pas d'autres choix que d'appliquer le filtre pour qu'il ne fasse qu'un avec son calque. Blender par exemple permet de faire cela (on peut mettre des filtres genre miroir sur des objets 3D. Puis ensuite on l'applique, ce qui permet de travailler sur un côté de l'image différemment par exemple).
En tous cas, cela signifie qu'une architecture non-destructive n'oblige absolument pas à travailler non-destructif tout du long. L'utilisateur peut toujours revenir à une méthode de travail destructive.
5/ Enfin, en revenant sur la problématique des prévisualisations, il y a des moyens de les accélérer (en dehors de la solution d'optimiser les opérations elle-même bien sûr), notamment lorsque le viewport ne montre qu'une partie de l'image. Ou à l'inverse quand la vue de l'image est plus petite que la taille réelle du fichier à cause d'un zoom-out. Bon c'est pas moi l'expert, mais voici un email du mainteneur GEGL sur le sujet de l'accélération de la prévisualisation.
Ce sont des choses auxquels les divers développeurs réfléchissent beaucoup.
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 ?
Non puisque comme je disais, on devrait toujours pouvoir les utiliser en destructifs à l'ancienne. C'est juste une question d'UI.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Rapidement, tu peux expliquer tes aventures de vagabondage ? (j'ai vagabondé un peu aussi il y a pas si longtemps que ça, et la photo rappelle des souvenirs… :)
Cette photo, c'était en Mongolie. J'ai vagabondé entre la France et le Japon pendant 6 mois, puis j'ai vécu au Japon, en Corée, en Nouvelle Zélande, où j'ai aussi pas mal bougé.
Et j'imagine que coder ou quoi avec ce que tu as l'air d'avoir sur cette première photo, c'est difficile, voir pas vraiment d'actualité pendant ce genre de voyage/vagabondage.
En effet je code pas, ou presque, quand je suis sur la route.
Comment ça se passe/s'est passé avec tes différents projets/contributions ?
Ben tu mets en pause quand tu sais que de toutes façons, tu n'auras pas vraiment l'opportunité de contribuer. Par exemple à l'époque je contribuais beaucoup dans le monde XMPP. Ben avant de partir, j'ai quitté la XSF (ils ont assez de membres fantômes, pas la peine d'en rajouter un), de la même façon que j'ai démissionné de mon job ou que j'ai donné un préavis pour l'appart que je louais à l'époque. Y a pas vraiment de différence. :-)
Par contre une fois un peu plus posé, même si tu peux rester mobile et déménager tous les mois, rien n'empêche de contribuer avec même un petit portable léger et peu puissant. J'ai codé pendant plusieurs années sur un petit eeepc acheté au Japon. J'ai même codé dans une startup au Japon avec cet eeepc pendant plus d'1 an (avant qu'ils m'achètent un ordi puissant) où j'étais senior developer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Bon j'ai dit que je répondrai pas, mais je marche dedans! J'arrive pas à retenir mes doigts.
sur ce qui ne marche manifestement pas.
Qu'est-ce qui ne marche pas? Qu'un outil n'est pas parfait n'est pas la même chose qu'un outil cassé. L'outil de texte marche très bien. Quand on trouve un bug, je peux t'assurer qu'on n'attend pas longtemps avant de le corriger.
En outre, c'est justement ce petit plus de l'UI parfaite qui prend du temps. Parler c'est beau, mais si tu as la science de l'UI idéale infuse, on les veut bien tes dessins et tes spécs détaillés (c'est à dire qui prend en compte tous les cas, pas juste un yakafokon en 1 ligne) pour rendre l'outil de texte bien meilleur.
Il faut aussi savoir gerer son temps.
Merci de venir nous donner des leçons de vie. Heureusement que les trolls sont là pour nous apprendre comment gérer notre temps (avec ce magnifique exemple justement pour nous le faire perdre! En fait c'est peut-être cela la "gestion" du temps que tu veux nous enseigner?); sans eux, que ferait-on?
Je concluerai par un lien vers notre bugtracker, de la liste des rapports qui sont passés en statut "FIXED" (= corrigé) depuis janvier 2015: 75 bugs à ce jour
Et encore, c'est sans compter les bugs découverts en interne et corrigés sans qu'il y ait eu un rapport de bug. Je compte donc, dans la seule année 2015, 459 commits dans GIMP master, 26 dans babl master, et 218 dans GEGL master. C'est sûr, les développeurs de GIMP n'en font vraiment pas une et "se fout[tent] de l'utilisateur".
D'ailleurs saviez-vous que lorsqu'un utilisateur rapporte un bug, en fait on va se moquer de lui derrière son dos et on rigole bien car on fait exprès de ne jamais corriger les bugs.
Non mais qu'est-ce qu'il faut pas lire!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est pas faux. La gestion du texte est clairement compliquée sous GIMP.
Tout à fait. La gestion du texte est un très gros chantier sur lequel on aimerait tous venir un jour. C'est clairement un outil assez frustrant à de nombreux égards. Je suis le premier à être d'accord, et Aryeom ne dira pas le contraire non plus! Tous les autres dévs en sont conscients aussi car on en parle régulièrement (on en a encore parlé avec le mainteneur y a 2 mois lors de LGM 2015).
De manière général, le commentaire initial du fil liste plusieurs problèmes réels, connus et qu'on veut améliorer.
Par contre j'ai voulu répondre, mais j'ai abandonné. Le commentaire n'a clairement pas été fait pour initier un échange constructif, et je sens que toute réponse (celle-ci comprise probablement) ne m'apportera que des attaques ad-hominem. C'est donc mon premier et dernier message sur ce fil de discussion.
Par contre si y a d'autres questions ou commentaires intéressants, et même des critiques constructives, n'hésitez pas à créer un autre fil.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'imagine que l'utilité du machin doit résider dans l'ergonomie et le fait qu'il n'y a plus besoin de prendre de précautions : quoiqu'il arrive l'image de base sera toujours dispo.
Benoît Sibaud a bien répondu avec des détails. Mais globalement ce que tu dis est juste aussi.
En gros, l'idée est de ne plus travailler avec des filtres temporellement mais avec un graphe (ou au moins une pile) de filtres. Tu ne modifies donc plus l'image avec ça, puis ça, puis ça. Puis tu dois tout annuler pour retirer juste le premier filtre. Tu as juste une image (qui reste toujours clean) et une pile de filtres au dessus. Et tu peux éditer tes filtres, les réordonner, en ajouter un, avant, après ou au milieu des filtres existants, etc.
L'historique n'a plus tellement de sens et n'est plus utile. Cette méthode de travailler est bien plus flexible.
Par contre, il y a certaines choses pour lesquelles l'historique a toujours du sens: tout ce qui est peinture ou assimilé.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En général, les spams sont gérés au niveau du serveur. Roundcube est un client, qui certes s'installe sur un serveur (web), mais qui est à comparer à un client lourd installé sur l'ordi. Bien sûr, les clients lourds ont souvent un antispam (comme Thunderbird), mais ça ne vaut pas un antispam serveur parce que ça marche avec n'importe quel client! Tu lis tes emails depuis Thunderbird? Depuis ton tél? Depuis le webmail parfois? Ça marche toujours pareil. C'est d'autant plus important avec imap (je pense que l'antispam sur le client, c'est d'ailleurs un reliquat d'une époque où on téléchargeait tous les emails avec pop3, toujours sur le même ordi).
En outre avoir un antispam sur le webmail, ça signifierait du traitement antispam fait quand vous vous connectez à votre compte, donc alourdirait l'expérience webmail; alors que direct sur le serveur, le traitement se fait à l'arrivée de chaque email, 1 par 1. C'est beaucoup plus léger comme traitement. Imagine que tu t'es pas connecté sur ton compte email depuis une semaine, t'as reçu des centaines d'emails à traiter d'un seul coup. Maintenant multiplie ça par tes utilisateurs. Ça fait des périodes où y a pas de traitement (la nuit), et soudainement plein (le matin), et tout ça en plus fait par le serveur web (du code PHP — dans le cas de Roundcube — qui tourne au moment d'une requête). Ça pourrait aussi être traité côté client en javascript, mais dans ce cas là se pose le problème de sauver la base de données du filtre (bayésien en général).
Enfin voilà, perso je trouve que c'est bien mieux ainsi.
Par contre il existe plusieurs techniques bien connues pour gérer le spam (envoyer à une adresse email spécifique, simplement déplacer dans un répertoire, etc.) et il pourrait y avoir une option pour mapper un bouton "spam" (ou "not spam" selon contexte) à ces diverses actions, selon technique utilisée. Ça oui, je suis d'accord, ce serait cool et rendrait l'expérience plus transparente aux utilisateurs.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tout est possible. Faut ensuite voir le "coût", que ce soit le coût de développement, c'est à dire la complexité, le temps que cela va nous prendre à avoir une architecture convenable, mais aussi le coût additionnel du traitement, et donc notamment le temps additionnel et la mémoire utilisée, etc. Déjà que beaucoup se plaignent du fait que le non-destructif peut être plus lent (car à chaque changement de l'image ou d'opération, on doit potentiellement recalculer toutes les opérations "au dessus"), et qu'il va rapidement bouffer toute la mémoire, voire swapper, et devenir encore plus lent (cf. commentaire plus haut au sujet de Darktable)… Puis faut voir si ce coût vaut le coup en comparaison du gain.
Surtout qu'au début on parlait d'optimisation, maintenant on veut rendre le traitement encore plus parfait (donc lent en général). :-)
Par exemple, la rotation, bah, tourne réellement la matrice (comme sur ton schéma), ensuite on applique ton filtre, et à la fin on interpole sur une grille 4x4 …
Déjà il faut bien noter que ce n'est commutable qu'avec certains types d'opérations. Par exemple si une opération changeait les pixels en fonction de leur position, cela ne serait pas la même chose de l'appliquer avant ou après rotation (exemple typique: utilisation d'une texture que l'on va mapper au dessus de l'image). C'est un travail assez important de bien cataloguer les opérations. Et l'utilisateur a peut-être choisi exprès d'appliquer telle opération sur les pixels avant ou après une rotation car il voulait tel rendu, ou tel autre. Il faut donc bien faire attention quand on réordonne. Pas tout ne peut l'être.
Mais oui, il y a des moyens d'optimiser un graphe et c'est un travail qui demande du temps pour le faire bien, en utilisant des connaissances mathématiques puis en les appliquant à la réalité de la représentation algorithmique. Et surtout ne pas changer le rendu désiré par l'artiste.
D'accord, mais ta description, c'est carrément un arbre (donc le graphe a bien une forme particulière)
Non, mon exemple est un arbre. Pourquoi en faire une généralité?
On pourrait avoir une opération qui re-rentre dans un autre nœud. Par exemple ci-dessous, op1 rentrerait dans op2 et re-rentrerait dans op3, ce qui est très pratique car cela évite d'avoir à recréer des nœuds qui recalculeraient des opérations que l'on a déjà calculées.
op3
^ ^
op2 ^
^ ^
op1 >>>
On a ce genre de graphes tout le temps dans Blender. Je ne suis pas sûr si GEGL permet plusieurs sorties, mais si ce n'est pas le cas à l'heure actuelle, ce ne serait pas dur à implémenter; ensuite il faut juste adapter l'UI. Dans GIMP, certains semblent ne pas vouloir une UI trop complexe. Ce que je comprends tout à fait pour l'UI de base, du moment qu'on puisse aussi proposer une UI alternative pour gérer des graphes complexes. Enfin on verra cela quand nous commencerons à réfléchir sur une UI pour le non destructif dans GIMP.
Par contre, dans ton modèle, je vois pas comment on peut faire une rotation
Je reprends donc mon exemple. Supposons que l'on ait une rotation comme opération non destructive sur le Layer 2.
puisque c'est pas une opération qui demande deux calques
Une opération n'a pas forcément 2 entrées. Elle peut en avoir 1, 2… et même zéro! (par exemple une opération de chargement d'image n'a pas besoin d'entrée. Elle a juste un paramètre pour indiquer un chemin d'accès au fichier, ou même des opérations qui génèrent de l'aléatoire). De même pour les sorties.
Sinon, encore une question […]
Je ne peux pas vraiment répondre à ce type de questions. Comme je disais, je ne suis pas du tout expert en algorithmique du traitement d'image. J'ai fait des maths à niveau correct et de l'algorithmique à la fac, mais c'était y a des années et je ne lis pas de livres de maths le soir avant de me coucher. Donc oui je comprends comment marchent les divers algorithmes quand je lis du code. Par contre non je ne pourrai pas comparer les algorithmes. Enfin si, peut-être si je me mettais à lire beaucoup sur le sujet, puis à prendre un crayon et difficilement essayer de me remettre à résoudre des problèmes mathématiques, mais je n'en ressens pas le besoin. :P
On a plusieurs dévs qui sont très calés sur ce genre de choses, et je leur fais confiance. De mon côté, je fais d'autres choses peut-être un peu plus terre à terre, mais bon, chacun son truc. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est une question que je me pose vraiment. Quel est l'intérêt d'une levée de fond avec un système de crowd-funding « traditionnel » comme indiegogo plutôt que patreon qui permet d'avoir une paye chaque mois ?
C'est très différent. Et nous avons beaucoup pensé à ce type de financement aussi, mais il ne correspondait pas à notre situation. Par contre, comme Creak le note, rien n'empêche d'utiliser Patreon (ou tout simplement de monter un système de financement mensuel sur le site) après coup, et on le fera peut-être.
Pourquoi Patreon n'était pas adapté? Car ça commence très bas. On dit aux gens qu'on va faire quelque chose et à chaque sortie (ou mois), on récupère le montant sponsorisé à ce jour. Or si c'est pour récupérer 100 € pour 1 mois de travail, autant faire tout bénévolement tout de suite. C'est acceptable quand on fait de la BD (même si 100 € la page par exemple reste faible, c'est moins ridicule que genre 100 € la minute d'animation, ce qui correspond à storyboard + 1440 dessins en HD). On voit bien que ceux dont les financements montent haut, c'est après pas mal de temps et qu'une certaine réputation s'est installée. Cela marche donc OK si on est déjà célèbre ou après beaucoup de temps, et surtout pour une seule personne (si on est 2, 3, 4, ça divise le financement de beaucoup). Et cela ne prend pas en compte le financement initial. Nous voulions voir avant de commencer notre projet si les gens nous suivraient.
Par contre, quand notre financement initial sera terminé, puisque nous avons passé notre premier palier, je pense que cela pourra être intéressant de compléter par un système de type Patreon, en effet.
les youtubers que je sponsorise se font quand même de l'argent avec la pub de Youtube
Franchement nous éviterons autant que possible de mettre de la pub, que ce soit sur les vidéos (sur Youtube ou alors), sur nos sites, etc. Jusqu'alors je n'ai jamais mis la moindre pub sur la moindre de mes créations et je ne m'en porte que mieux. Pour moi cela pollue notre espace visuel. Et un bloqueur de pub, ce n'est pas la réponse selon moi. Ce n'est qu'un contournement. Moi, je rêve d'un monde sans pub, où il n'y a pas besoin de bloqueur de pub (cela n'arrivera probablement jamais, mais je ne souhaite pas être fataliste et contribuer pour autant à ce monde).
J'ai entendu des arguments, même non monétaires, notamment on m'a dit que les vidéos sans pub sur Youtube étaient dépriorisées par Google (une recherche va afficher des vidéos avec pub en haut en priorité). C'est triste, mais je trouve l'expérience des pubs sur Youtube tellement horrible et désagréable que je refuse à ce jour de le faire subir à ceux qui visionneront nos vidéos.
En outre, honnêtement je préfère de loin vivre de l'argent direct par des contributeurs qui veulent nous soutenir explicitement (à ce jour 313 personnes, dont nous ne connaissons pas la grande majorité, nous soutiennent; ça fait chaud au cœur, plus que de recevoir même 3 fois cet argent en échange de zombification publicitaire) que par les conglomérats de la pub qui ne sont que des parasites selon moi.
Et même si je sais que beaucoup de gens n'ont pas l'air d'être plus touchés que cela par la pub, j'espère tout de même au fond de moi que nos contributeurs s'en rendent compte (peut-être certains?) et nous soutiennent même davantage pour cela.
P.S.: c'est aussi un des trucs que j'apprécie sur LinuxFR. Les seuls "bandeaux de pub" qu'ils ont sont choisis et ciblés pour les projets amis et sont davantage du soutien explicite par LinuxFR à ces projets et un peu de mise en avant, non comparable à ces pubs horribles et impersonnelles qu'on a habituellement pour bouffer du "temps de cerveau disponible" en échange d'argent.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En imagerie informatique, les données sont discrètes. Dans la "nature", une image est continue. Elle n'est pas une succession de point. Donc une vraie rotation physique n’abîme pas une image (tu as une photo posée sur la table, tu la tournes, elle ne perd pas en qualité! :P).
Mais dans une représentation bitmap, une image est une matrice limitée de point. Donc à part si tu fais une rotation qui garde une matrice (90°, 180°, 270°…), tes pixels d'origine se retrouvent entre 2 points de la matrice (les nouveaux pixels).
Exemple la matrice de pixels:
1 2
3 4
… après rotation à 45° devient:
1
3 2
4
Ce n'est plus une matrice, et il faut donc calculer les nouveaux pixels qui formeront l'image après rotation, à partir des pixels d'origine. Il y a pour cela divers algorithmes dit d'interpolation (regarde les paramètres de l'outil "rotation" de GIMP, tu peux voir que tu peux choisir le type d'interpolation, ce qui est bien sûr plutôt pour les utilisateurs avancés). Une interpolation possible pourrait être tout simplement de faire la moyenne pondérée entre les pixels qui chevauchent le nouveau pixel (c'est en gros l'interpolation linéaire quoi). Il y a d'autres algorithmes moins naïfs (ce qui ne veut pas dire que celui-ci est mauvais pour autant!), c'était juste pour prendre un exemple simple.
le graphe ressemble à plusieurs listes qui se terminent en un même nœud ?
Dans l'UI, ça ressemble à une liste.
Mais c'est en fait un graphe où à chaque nœud, on a rentré 2 calques, ce qui a produit un résultat, que l'on va "compositer" avec un autre calque.
Ainsi la liste de calque:
"Layer 1" (Normal)
"Layer 2" (Multiply)
"Layer 3"
La différence, c'est que Docker, c'est pour les serveurs, alors que là c'est un système de packaging utilisateur. On veut donc qu'un programme s'intègre à son environnement. Comme j'explique plus haut, on veut notamment lier les formats de fichier à une application (double clique sur un .xcf: ça doit ouvrir GIMP); on veut aussi mettre à jour le menu utilisateur automatiquement; on veut peut-être aussi fournir des infos aux autres logiciels pour interagir entre logiciels; on veut mettre l'icône de l'application accessible aux divers logiciels du bureau qui pourraient en avoir besoin, etc.
La partie sandboxing n'est pas pour moi la fonctionnalité cible. C'est uniquement une nécessité. Puisque ce sont des logiciels qui pourront être téléchargés d'un peu n'importe où, il faut pouvoir protéger un minimum l'utilisateur (même si on ne peut le protéger de lui-même et donc les risques existent toujours) et ses données.
Pareil pour les dépendances. Ce n'est pas à voir comme un but. Je suis certain que les dévs préféreraient ne pas en avoir besoin. Mais sans cela, un paquetage sera lié à une distribution en particulier (puisque chaque distrib a potentiellement des versions de lib différentes).
Le besoin, c'est simplement qu'il est très dur de télécharger un programme pour Linux quand il n'est pas packagé par sa distribution, ou seulement dans une version ancienne/bugguée. Et les rares fois où certains projets proposent quelques choses (en général juste une archive à décompresser quelque part), ça s'intègre absolument pas à votre bureau. Et s'ils proposent un paquetage de distrib, c'est limité à certaines distrib (.rpm, .deb, et encore pas toutes les distribs avec le même système de paquetage ne peuvent installer les mêmes paquets si certains chemins d'accès ou des noms de dépendances diffèrent par exemple…), et on a besoin des droits root pour installer.
C'est dommage qu'il n'existe aucun standard pour cela, et c'est ce qu'ils sont en train de créer.
D'ailleurs plusieurs font la remarque que c'est du GNOME, mais comme je le lis, même si cela vient de dévs GNOME au départ, c'est un projet de standard (XDG) qui devra fonctionner sous tous les environnements de bureau.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
il suffit d'ajouter des types de nœuds spécifiques pour des opérations génériques:
C'est bien ce que je dis. Il faut créer de nouvelles sous-classes de nœud et y mettre tous les nœuds qu'on arrive à identifier d'une certaine catégorie, puis réarchitecturer une bonne partie de la lib pour mettre à profit les propriétés de ces types de nœuds, etc. C'est du boulot, et ce il suffit me chagrine beaucoup. Pourquoi quelqu'un d'extérieur à un projet a souvent cette idée que les choses sont si simples à faire?
Ensuite je le redis: on accueille les bonnes volontés! Si tu penses avoir les idées et les capacités pour optimiser GEGL, on sera tous très heureux.
On remarque (faire un dessin) que map f et move (a,b) g commutent ! Donc on peut se débrouiller pour réordonner les enchaînements « move/map/move/map » et avoir seulement deux nœuds.
La commutation sur pas mal de type de nœud est vraie théoriquement, pas dans la pratique.
Imagine une fonction f() qui transforme un pixel gris entre [0; 0.5[ en noir, et un pixel gris entre [0.5; 1] en blanc (on va travailler sur un canal unique).
Tu as au départ une image de 4 pixels (2x2) avec un pixel sur 2 noir puis blanc:
N B
B N
Applique maintenant f(). L'image est inchangée. Applique maintenant une rotation de 45°. Bon il existe divers algorithmes de rotation, donc on va juste supposer qu'on utilise un algorithme qui fait une moyenne entre les pixels adjacents.
Résultat final: une image totalement grise uniformément.
Commute maintenant les opérations. Fait d'abord la rotation (tous les pixels deviennent gris), puis applique f().
Résultat: tous les pixels sont blancs!
Nous avons 2 images totalement différentes au final. Théoriquement (mathématiquement) tu as raison, on peut réordonner ces opérations. Dans la réalité de l'imagerie informatique, ce n'est plus vrai.
En plus, je parle même pas du cas où f() utiliserait la position du pixel comme donnée d'entrée (par exemple pour effectuer un traitement en mixant avec une image de pattern…), et déplacer les pixels avant ou après modifierait donc complètement le rendu aussi.
Enfin, rien ne peut être optimisé de manière aussi naïve si on a pas l'assurance d'avoir du code sans effet de bord, et je ne sais pas si c'est pertinent pour du traitement d'images …
Ben voilà, tu as compris. On ne peut pas juste optimiser naïvement comme les exemples proposés plus haut. C'est beaucoup plus compliqués que juste des mathématiques (celles ci sont la base, mais il faut ensuite pouvoir les appliquer dans la réalité des représentations informatiques).
Pourquoi est-ce un graphe ? Une liste d'opérations à faire ne serait pas aussi bien ?
Comment tu fais pour du compositing sans graphe? Une liste d'opérations ne permet que de modifier une image, mais dans la réalité, on (= tous ceux qui utilisent ce genre de logiciels de dessin et traitement d'image) mélange des dizaines d'images les unes aux autres. On pourrait même avoir des opérations qui rentre dans un noeud et re-rentre dans un autre nœud, pourquoi pas.
Enfin bon, de toutes façons, même sans aller plus loin, GIMP serait bien triste si on pouvait plus avoir de compositing (= adieu les calques!).
Je sais pas si tu as déjà testé l'éditeur de Node de Blender, mais tu pourrais presque plus rien y faire s'il s'agissait juste d'un système linéaire, et il perdrait soudainement beaucoup de son intérêt (alors qu'à l'inverse, à l'heure actuelle, c'est un des gros points forts de Blender).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Perso j'attends ces technologies avec impatience.
Par contre ce n'est pas du tout fait pour remplacer les systèmes de packaging des distribs Linux (et j'espère sincèrement que personne n'aura cette idée saugrenue).
Sur mon ordi, 99% (doigt mouillé) sont des logiciels installés par le packaging de ma distrib. Par exemple j'en ai rien à faire que Firefox soit un chouille en retard en version. Pareil pour mes lecteurs vidéo/audio, libreoffice, ou de manière générale la plupart des logiciels que j'utilise et qui me conviennent très bien. Par contre il existe 2 cas où ça me gêne:
1/ Certains programmes ont un problème qui me gêne depuis longtemps (voire une régression, bug qui n'existait pas avant et apparu lors d'une mise à jour). Or en cherchant des infos, je me rends compte que ce problème est connu et corrigé par la version stable en download. Franchement dans ce cas, attendre que la distrib mette à jour son paquet, ce qui prend souvent du temps (surtout pour les petits logiciels) me fait chier.
2/ Il existe de rares cas où avoir les dernières fonctionnalités upstream est important, en général c'est en rapport avec ses activités. Typiquement pour moi: Blender, GIMP, Scribus… ont des fonctionnalités qu'on va vraiment utiliser dès qu'on les obtient. Je ne veux pas attendre je-ne-sais-combien de mois non plus.
Or sous GNU/Linux, les téléchargements sur site, c'est en général soit du source-seulement, soit des archives à décompresser, et à mettre quelque part. Un utilisateur de base ne sera pas capable de faire en sorte que les fichiers correspondants lancent la version téléchargée (par exemple, double cliquer sur un .blend -> cela lance Blender installé par la distrib, pas celui téléchargé). Vous n'aurez pas le programme dans le menu (donc la plupart du temps, les utilisateurs gardent le dossier décompressé sur le bureau pour accès "plus ou moins simple et rapide"). Etc. C'est chiant, sale (l'installation) et pas du tout intégré à votre environnement.
Or ce type de solution a pour but d'installer des apps en mode utilisateur mais de manière propre. Vous pourrez cliquer sur des fichiers qui ouvriront votre application (installation des fichiers desktop); vos menus seront mis à jour avec la nouvelle app, sa description et son icône, dans la catégorie adéquate; vous n'avez pas besoin d'encombrer votre bureau de répertoires, etc. Tout comme une app installée par le système de paquetage de votre distrib, intégrée et propre, mais en mode utilisateur et avec une version récente, avec des droits réduits (car installé depuis une source moins sûre) à donner au fur et à mesure à l'application!
Franchement je trouve cela extrêmement gênant que tous les logiciels Libres — si on veut la version upstream — sont finalement bien plus simples à installer sous Win et OSX que sous Linux.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Bien sûr qu'on en est capable techniquement (comme un peu tout). Je parle de GIMP en particulier et j'entendais "ce qu'on pourrait faire", c'était pas une question de savoir si les langages ont cette capacité (quand même, heureusement qu'ils l'ont!).
Aussi ce que je disais, c'est surtout qu'il faut adapter l'architecture du code. À lire certains commentaires, on a l'impression que c'est trop facile, "il suffit d'optimiser" (yakafokon). Alors que pour le permettre, il faut identifier les cas possibles d'optimisation (comme je disais plus haut, des suites d'opérations matricielles, des ops sur des pixels si et seulement si elles ne sont pas dépendantes d'autres pixels de l'image, etc.), puis éventuellement adapter l'architecture du programme pour rendre ces optimisations faisables. Et ainsi de suite.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: plop du jour
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Rencontres Mondiales du Logiciel Libre, du 04 au 10 juillet 2015, à Beauvais. Évalué à 4.
On était le stand juste à côté de linuxfr au village du Libre, et ça… c'est cool! :-)
Merci à Linuxfr pour cette photo (postée sur leur compte Twitter) car on n'est vraiment pas doué et on n'a quasiment pas fait de photo (ou alors de très mauvaise qualité sur vieux téléphone).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP 2.10
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 8.
Oui bien sûr, je peux répondre. La prochaine sortie est à compter en [bzzz bzzz interférences bzzz bzzz]. ;-)
Plus sérieusement, je n'en ai aucune idée. On peut essayer de pousser mais au final le mainteneur choisit. Aussi GIMP 2.10 est dans une situation très particulière avec le passage à GEGL. Nous avons quelques fonctionnalités "cassées" par ce port, et s'il y a bien une chose que les utilisateurs ont du mal à encaisser, ce sont les régressions.
En tous cas, je suis moi-même complètement "pour" qu'on arrive à accélérer les sorties, comme je le dis dans l'interview. Et j'ai fait rajouter l'item "proposition de passer en mode sortie rapide" pour notre réunion à LGM 2014. Ce qui en est ressorti, c'est que les autres dévs ne sont pas contre, mais cela devra commencer à partir de GIMP 3.0, à cause du passage à GEGL, puis du passage à GTK 3.0. Après ces 2 ports, je pousserai vraiment pour passer à des sorties rapides, et qu'on adapte notre infrastructure de tests et de sortie s'il le faut.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: contenu inutile.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 4.
J'utilise la version anglaise, et j'ai juste fait une traduction perso (et mauvaise) de save/export. En VF, enregistrer/exporter ne me choque pas comme étant la bonne trad.
Ensuite de manière générale, ce que tu dis sur les mots est juste. Comme on le dit en général dans le développement d'application (à moitié blague, à moitié sérieux), le plus dur en informatique, c'est de nommer les choses (le code lui-même comme le texte visible d'ailleurs).
Par contre cela ne s'applique qu'à moitié au problème ici, puisqu'il n'est pas spécifique à la VF. Et je doute sincèrement que si on utilisait sauver/exporter, soudainement tous les francophones contre la fonctionnalité disent soudainement "ah ok je comprend mieux, c'est bon alors" (mais je veux bien me tromper). Par contre on aurait soudainement beaucoup de nouveaux en colère parce que "sauver" est un faux-ami et pas la bonne traduction pour "save". On sauve quelqu'un qui est en danger, on ne "sauve" pas du travail.
Tout ça pour dire que j'ai simplement fait une erreur de traduction dans mon commentaire, et je ne pense pas vraiment que rendre mon erreur de trad officielle soit la vraie solution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vagabondage
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 2.
Bon ça c'est une spécificité générique de l'équitation, dans la steppe ou ailleurs, aucune différence. Le trot, c'est toujours inconfortable. Pour être confortable, il faut soit aller au pas, soit au galop (mais là aussi il y a une forme de frayeur). Par contre un cheval ne peut pas non plus galoper trop longtemps (c'est comme si on nous demandait de courir à fond tout le temps, j'imagine). C'est pourquoi en général, voyager à cheval, ça signifie surtout voyager au pas. C'est pas énormément plus rapide qu'à pied (mais moins fatigant).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vagabondage
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 7.
Dans le sens où y a des Marmottes en Mongolie? Dans ce cas, non, car j'avais déjà ma Marmotte avec moi. Si tu regardes bien sur la photo, tu peux voir une petite peluche sur le guidon: mon copilote la Marmotte! Mais sinon oui, on voit régulièrement des marmottes dans ces coins de l'Asie centrale (pas les mêmes que les européennes).
Dans le sens où le film parle de vagabondage? Dans ce cas, oui forcément, c'est lié. J'aime me balader, donc j'en parle. J'aime les histoires d'aventure, donc c'est ce que j'écris.
Franchement je ne pense pas avoir jamais mangé de la marmotte (enfin j'espère!). Ensuite j'ai mangé des trucs non identifiés en Mongolie, notamment un jour où j'ai été hébergé dans une yourte après avoir fait chuté la moto en traversant une rivière (donc le moteur était inondé, me forçant à des réparations de fortune).
De manière générale, il me semble que les gens mangent surtout ce qu'ils élèvent. Certaines familles ont des moutons, donc ils mangent surtout du mouton et boivent du lait de brebis. Ceux qui ont des chèvres, pareil. Et ceux qui ont un troupeau de yak pareil. Les chevaux, pareil. Etc.
En tous cas, c'est quasi essentiellement une nourriture à base de viande rouge (pas beaucoup de verdure; jamais non plus de poisson a priori, même s'ils ont des lacs et des rivières; et du lait en boisson, fermenté ou non, plutôt que de l'eau…).
Alors j'ai pas vu ce film, mais en vrai c'est loin d'être de tout repos. Il n'y a pas de route, c'est que du sable à perte de vue. Et dans ce contexte, le sol est loin d'être "plat". Il en a l'air, et il l'est "globalement", mais dans le détail, c'est juste une succession de bosses et de trous, parfois très dangereux. Je devais m'arrêter environ toutes les heures et faire le tour de la moto avec un tournevis pour repérer et revisser les diverses vis qui se dévissait par les vibrations seulement. J'y allais avec toutes mes forces possibles, mais même là, ça se dévissait encore. Et j'en ai perdu quand même pas mal dans le process.
Pour la petite histoire, j'ai dû perdre une bonne vingtaine de vis sur la moto, et le garage où j'ai fait révisé/réparé la moto au Japon a trouvé même quelques vis internes tombées au fond du moteur (j'ai eu de la chance donc que ça me pête pas à la figure; et évidemment ces vis là, je pouvais pas les revisser moi-même).
Quand tu conduis en Mongolie, au Kazakhstan, ou même en Russie, tu as 2 choix: rouler très lentement (40/50 km/h), et dans ce cas, c'est extrêmement inconfortable (tout tremble constamment), mais c'est plus sûr; ou tu vas vite, et à ce moment, il y a un palier (vers les 90 km/h) où tu te mets à "voler" au dessus des trous. Il n'y a plus de tremblement, ni de vibration excessive (enfin si, mais bien plus confortable), tu n'as plus mal. Par contre c'est très effrayant et tu dois garder une concentration très appuyée pendant toute la conduite (tu te prends un trou un peu trop grand que tu n'as pas vu venir dans ces steppes, à l'allure lisse de loin sous le soleil, et c'est fini pour toi. Y aura probablement personne pour te venir en aide).
Très vite, on se met à prendre ce second choix, car conduire des jours en vibrant et en ayant mal partout, c'est peu tenable. Mais alors on fatigue aussi très vite (conduire bien, c'est à dire concentré et avec sérieux, c'est pas reposant!).
Enfin voilà, tout ça pour dire: non tu t'endors pas au volant. Et quand ça arrive, c'est qu'il est l'heure de s'arrêter, faire une pause, voire de sortir le sac de couchage si c'est le soir.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: contenu inutile.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 7.
En même temps, l'UI est la partie visible de l'iceberg. Il reste que le format XCF suit parfaitement les fonctionnalités de GIMP et donc est le seul format de projet valable pour du travail en cours. La haute précision ou le non-destructif ne sont pas encore là, mais il y a déjà foultitude d'autres fonctionnalités qui nécessite XCF.
Par exemple quel format garde la sélection en cours? (permettant de commencer à travailler sur une sélection complète, la laisser en suspens, sauver le fichier, et y revenir plus tard là où on en était)
Quel format bitmap a aussi des notions (basiques certes, mais existantes) de vectoriel?
Quel format garde aussi des masques de calques?
Quel format garde des calques de texte?
Très peu de format ont même la notion de calque tout court.
Peu de format ont la prise en charge de la transparence (et quand ils l'ont, pas forcément avec la précision de GIMP).
Etc. etc. etc.
Je ne prétends pas connaître tous les formats et certains ont peut-être certaines de ces notions, mais aucun format n'a tout ce que fait GIMP (seul XCF puisqu'il est calqué sur les fonctionnalités).
En fait, je n'étais pas présent dans la période d'avant la séparation sauver/exporter, mais je sais qu'il y avait énormément de personnes qui venaient se plaindre car ils avaient perdus une partie de leur travail en "sauvant" dans un format d'image classique (que ce soit PNG ou jpg).
Par exemple, le classique, ils rajoutent du texte au dessus d'une image, exportent en PNG (car on leur dit "PNG est non destructif"), et — paf! — le texte devient une image non éditable! Après ils viennent se plaindre que le texte ne peut plus être corrigé, qu'ils doivent tout refaire de zéro et ont perdu des heures de travail.
Il faut donc bien comprendre: on sauve son travail en cours, et on exporte un "cliché" à un instant T. Comme on exporterait une vidéo en mpg/avi/whatever, ou encore on compilerait un binaire exécutable à partir d'une source texte. L'export c'est pour l'instantané prêt à la diffusion/utilisation. La sauvegarde, c'est le projet, le travail.
Le changement d'UI sera la cerise sur le gâteau, absolument pas le cœur de la fonctionnalité. Et il faut changer le cœur avant de rajouter la cerise (un peu comme GEGL, la prochaine version aura un nouveau cœur mais l'UI ne le réflètera pas encore, c'est à dire pas d'édition non destructrice visible. Ça arrive forcément après).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 7.
Et on remarque que 13875 / 330 ~= 42 € par personne!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 6.
De rien. Si vraiment tu veux absolument m'aider et que tu as un peu de sous, contribuer au projet ZeMarmot est le moyen idéal de le faire! :-)
Non seulement il permettra de faire un film d'animation vraiment cool — et en plus Libre! — mais en plus ça me fera utiliser plus de temps pour améliorer GIMP. :-)
Enfin je dis ça… j'dis rien hein! :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 10.
Ok. Pas de problème. Je vais donc répondre ce que je voulais dire l'autre jour.
Pour "Sans", il s'agit d'un alias qui était un alias par défaut de fontconfig. Cela permet de choisir la police Sans-serif par défaut de ton installation. Autrement on ne peut pas vraiment savoir quelles polices sont installées sur ton ordi, chaque OS/distribution ayant des différences (mais on sait que chaque OS aura au moins une Sans-serif par défaut et qu'il comprendra l'alias.
De nos jours ceci dit, c'est renommé "Sans-Serif" et "Sans" existe toujours mais est déprécié (j'ai regardé un peu le code de fontconfig et c'est ce que j'ai constaté). Je proposerai donc le changement chez nous aussi.
Le second truc auquel je ne m'étais jamais vraiment penché jusque là, c'est effectivement que ce serait mieux si on pouvait agrandir la liste déroulante. Par contre je regarderai d'abord si c'est déjà faisable sous GTK+3, et si c'est le cas, c'est possible que nous ne passerons pas trop de temps dessus (car on sait que ça marchera pour GIMP 3, ce qui n'est pas pour tout de suite, malheureusement).
En tous cas, j'ai bien pris en compte les remarques. Ensuite c'est toujours mieux et constructif dans une relation aimable entre les êtres humains que nous sommes. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 2. Dernière modification le 30 juin 2015 à 19:37.
De rien! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: contenu inutile.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 9.
Tout à fait!
C'est exactement cela. Les "images" GIMP (XCF) sont à considérer comme des projets en cours. Un format de travail. Ce n'est pas à considérer comme un standard (ce n'en est pas un), cela suit les évolutions logicielles de GIMP même, et ne peut être comparé à un format d'image (PNG, JPG, whatever…).
C'est comme Blender. Enregistrer, c'est du .blend (le format de travail qui suit les logiques logicielles de Blender). Ça n'empêche pas d'exporter en Collada (le standard pour la 3D) ou d'autres formats (souvent proprios).
En effet comme tu le notes, l'édition sans perte est une des énièmes très bonnes raisons: les formats d'image n'ont de concept de calque d'effet. Il faudra donc du XCF (enregistrer en PNG, jpg ou autre impliquera d'appliquer les effets et donc perdront de l'info). De même que la haute précision de couleur (PNG par exemple prend en charge jusqu'à 16 bits. GIMP ira bien plus haut).
Enfin il y a l'UI elle-même. À l'heure actuelle, on s'est contenté d'utiliser la même UI (puisque historiquement c'était la même chose), et donc ça perturbe les utilisateurs qui se disent "ben c'est la même chose". C'est compréhensible. Mais l'idée c'est qu'à l'avenir on aura 2 UIs différentes et adaptées. En fait j'ai même déjà du code
stash-équi commence le travail, mais faut que je trouve le temps de finir.Par exemple beaucoup de gens demandent une gestion de "l'export pour le web", c'est à dire notamment changer la résolution d'une image très haute rés, appliquer éventuellement quelques filtres, etc. À l'heure actuelle, on doit faire ce genre de choses dans l'image même, puis surtout ne pas oublier de les annuler après export de l'image (pour ne pas engendrer de perte de qualité, surtout quand l'image est aussi destinée pour de la haute résolution). Ben je pense que ce genre de choses devraient être faisable aisément dans une UI séparée qui gère ce genre de choses (comme un graphe d'effet à appliquer seulement dans un mode d'export particulier qu'on peut sauver).
Ce sont des exemples mais on peut en trouver beaucoup d'autres. Sauver et exporter sont vraiment des processus très différents. Simplement nous n'avons pas encore l'UI. C'est la base de cette évolution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Question de n00b
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 8.
Oui et non. Oui, ça limite l'intérêt, et notamment clairement la prévisualisation en directe pourrait devenir une véritable plaie (bloquant l'UI et empêchant de configurer correctement son filtre si à chaque fois qu'on affleure même un slider, on doit se taper une prévis).
Ensuite non, la non-destructivité est quand même utile (selon moi) pour les filtres longs. Du moment qu'on gère bien toute la partie ennuyante (comme la prévisualisation, en ne l'autorisant pas sur certains filtres), il reste tout de même d'autres avantages bien réels. Par exemple, tu parles de changer le paramètre d'un filtre. Ben dans ce cas là, même avec la méthode destructive (annuler, refaire le filtre), on doit se retaper les 15 minutes de traitement du filtre. Ben au moins avec la méthode non-destructive, on peut le faire n'importe quand, même après plusieurs heures de travail et des centaines d'autres actions faites entretemps; donc revenir sur l'historique — si possible, des fois ça ne l'est même pas — en revient à perdre des heures de travail.
Je ne suis pas certain, mais il est clair que nous ne laisserons pas ce genre de problèmes arriver (ou par erreur, et dans ce cas là, ce sera à considérer un bug à corriger). Il faudra les traiter. Je peux imaginer plusieurs choses.
Déjà la détection: on peut ajouter une notion de coût (théorique, comme un paramètre disponible en introspection) à une opération (il me semble me rappeler que cela a d'ailleurs déjà été discuté sur IRC). Ainsi avant même de commencer une opération, on peut avertir l'utilisateur que la prévisualisation risque d'être longue pour certaines opérations (voire même l'interdire pour des opérations qu'on sait vraiment vraiment trop longue), ou bien même pour toute opération si on l'exécute sur une image de vraiment trop grande taille. Ensuite on peut aussi avoir, en plus, un timer qui prend la main quand une prév dure trop longtemps, et donne la possibilité à l'utilisateur de l'interrompre.
Ensuite comment gérer ces ops trop longues?
1/ On peut donc simplement interdire la prév automatique comme je disais.
2/ Mais on peut aussi permettre une prév explicite avec un bouton dans ce cas. C'est à dire que ça ne va pas re-rendre le résultat juste en bougeant un slider d'un micromètre (bon moyen de rendre une UI inutilisable). Par contre, l'utilisateur peut bouger ses boutons et sliders tranquillement, puis cliquer sur un bouton, aller prendre un café et revenir voir le résultat après 15 minutes. Éventuellement refaire des changements, etc. Ou sinon appliquer (ce qui sera instantané puisque tout est déjà calculé).
Cela reste toujours légèrement plus pratique et rapide que d'appliquer, annuler, rouvrir l'UI de plugin, réappliquer, réannuler… Pas énormément différent, hein. Mais un peu, selon moi.
3/ L'utilisateur peut supprimer la visualisation d'un filtre (avec l'icône "œil"). Ça permet de l'appliquer au début, mais ensuite de l'empêcher d'actualiser sans cesse la vue (surtout si on prévoit de peindre sur le calque de base, etc.).
4/ On peut aussi permettre d'appliquer un filtre (ou une liste de filtres) directement sur l'image (c'est à dire en destructif comme maintenant). En fait j'en ai jamais discuté avec les autres, mais personnellement cela me paraît une fonctionnalité évidente.
Il y a toujours des cas où appliquer un filtre est mieux, voire nécessaire. Par exemple si on souhaite peindre directement sur le rendu (et non sur le calque de base, ni sur un autre calque au dessus), il n'y a pas d'autres choix que d'appliquer le filtre pour qu'il ne fasse qu'un avec son calque. Blender par exemple permet de faire cela (on peut mettre des filtres genre miroir sur des objets 3D. Puis ensuite on l'applique, ce qui permet de travailler sur un côté de l'image différemment par exemple).
En tous cas, cela signifie qu'une architecture non-destructive n'oblige absolument pas à travailler non-destructif tout du long. L'utilisateur peut toujours revenir à une méthode de travail destructive.
5/ Enfin, en revenant sur la problématique des prévisualisations, il y a des moyens de les accélérer (en dehors de la solution d'optimiser les opérations elle-même bien sûr), notamment lorsque le viewport ne montre qu'une partie de l'image. Ou à l'inverse quand la vue de l'image est plus petite que la taille réelle du fichier à cause d'un zoom-out. Bon c'est pas moi l'expert, mais voici un email du mainteneur GEGL sur le sujet de l'accélération de la prévisualisation.
Ce sont des choses auxquels les divers développeurs réfléchissent beaucoup.
Non puisque comme je disais, on devrait toujours pouvoir les utiliser en destructifs à l'ancienne. C'est juste une question d'UI.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vagabondage
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 10.
Salut,
Cette photo, c'était en Mongolie. J'ai vagabondé entre la France et le Japon pendant 6 mois, puis j'ai vécu au Japon, en Corée, en Nouvelle Zélande, où j'ai aussi pas mal bougé.
En effet je code pas, ou presque, quand je suis sur la route.
Ben tu mets en pause quand tu sais que de toutes façons, tu n'auras pas vraiment l'opportunité de contribuer. Par exemple à l'époque je contribuais beaucoup dans le monde XMPP. Ben avant de partir, j'ai quitté la XSF (ils ont assez de membres fantômes, pas la peine d'en rajouter un), de la même façon que j'ai démissionné de mon job ou que j'ai donné un préavis pour l'appart que je louais à l'époque. Y a pas vraiment de différence. :-)
Par contre une fois un peu plus posé, même si tu peux rester mobile et déménager tous les mois, rien n'empêche de contribuer avec même un petit portable léger et peu puissant. J'ai codé pendant plusieurs années sur un petit eeepc acheté au Japon. J'ai même codé dans une startup au Japon avec cet eeepc pendant plus d'1 an (avant qu'ils m'achètent un ordi puissant) où j'étais senior developer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 10.
Bon j'ai dit que je répondrai pas, mais je marche dedans! J'arrive pas à retenir mes doigts.
Qu'est-ce qui ne marche pas? Qu'un outil n'est pas parfait n'est pas la même chose qu'un outil cassé. L'outil de texte marche très bien. Quand on trouve un bug, je peux t'assurer qu'on n'attend pas longtemps avant de le corriger.
En outre, c'est justement ce petit plus de l'UI parfaite qui prend du temps. Parler c'est beau, mais si tu as la science de l'UI idéale infuse, on les veut bien tes dessins et tes spécs détaillés (c'est à dire qui prend en compte tous les cas, pas juste un yakafokon en 1 ligne) pour rendre l'outil de texte bien meilleur.
Merci de venir nous donner des leçons de vie. Heureusement que les trolls sont là pour nous apprendre comment gérer notre temps (avec ce magnifique exemple justement pour nous le faire perdre! En fait c'est peut-être cela la "gestion" du temps que tu veux nous enseigner?); sans eux, que ferait-on?
Je concluerai par un lien vers notre bugtracker, de la liste des rapports qui sont passés en statut "FIXED" (= corrigé) depuis janvier 2015: 75 bugs à ce jour
Et encore, c'est sans compter les bugs découverts en interne et corrigés sans qu'il y ait eu un rapport de bug. Je compte donc, dans la seule année 2015, 459 commits dans GIMP master, 26 dans babl master, et 218 dans GEGL master. C'est sûr, les développeurs de GIMP n'en font vraiment pas une et "se fout[tent] de l'utilisateur".
D'ailleurs saviez-vous que lorsqu'un utilisateur rapporte un bug, en fait on va se moquer de lui derrière son dos et on rigole bien car on fait exprès de ne jamais corriger les bugs.
Non mais qu'est-ce qu'il faut pas lire!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 10.
Tout à fait. La gestion du texte est un très gros chantier sur lequel on aimerait tous venir un jour. C'est clairement un outil assez frustrant à de nombreux égards. Je suis le premier à être d'accord, et Aryeom ne dira pas le contraire non plus! Tous les autres dévs en sont conscients aussi car on en parle régulièrement (on en a encore parlé avec le mainteneur y a 2 mois lors de LGM 2015).
De manière général, le commentaire initial du fil liste plusieurs problèmes réels, connus et qu'on veut améliorer.
Par contre j'ai voulu répondre, mais j'ai abandonné. Le commentaire n'a clairement pas été fait pour initier un échange constructif, et je sens que toute réponse (celle-ci comprise probablement) ne m'apportera que des attaques ad-hominem. C'est donc mon premier et dernier message sur ce fil de discussion.
Par contre si y a d'autres questions ou commentaires intéressants, et même des critiques constructives, n'hésitez pas à créer un autre fil.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Question de n00b
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 6.
Benoît Sibaud a bien répondu avec des détails. Mais globalement ce que tu dis est juste aussi.
En gros, l'idée est de ne plus travailler avec des filtres temporellement mais avec un graphe (ou au moins une pile) de filtres. Tu ne modifies donc plus l'image avec ça, puis ça, puis ça. Puis tu dois tout annuler pour retirer juste le premier filtre. Tu as juste une image (qui reste toujours clean) et une pile de filtres au dessus. Et tu peux éditer tes filtres, les réordonner, en ajouter un, avant, après ou au milieu des filtres existants, etc.
L'historique n'a plus tellement de sens et n'est plus utile. Cette méthode de travailler est bien plus flexible.
Par contre, il y a certaines choses pour lesquelles l'historique a toujours du sens: tout ce qui est peinture ou assimilé.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Fréquence
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Émissions "Symbiose" de l'APRIL sur "Ici et Maintenant". Évalué à 2.
Oh et pour ceux qui ont une radio, tout simplement, c'est 95.2FM. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Gestion des indésirables ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Appel à financement pour le prochain RoundCube. Évalué à 4.
En général, les spams sont gérés au niveau du serveur. Roundcube est un client, qui certes s'installe sur un serveur (web), mais qui est à comparer à un client lourd installé sur l'ordi. Bien sûr, les clients lourds ont souvent un antispam (comme Thunderbird), mais ça ne vaut pas un antispam serveur parce que ça marche avec n'importe quel client! Tu lis tes emails depuis Thunderbird? Depuis ton tél? Depuis le webmail parfois? Ça marche toujours pareil. C'est d'autant plus important avec imap (je pense que l'antispam sur le client, c'est d'ailleurs un reliquat d'une époque où on téléchargeait tous les emails avec pop3, toujours sur le même ordi).
En outre avoir un antispam sur le webmail, ça signifierait du traitement antispam fait quand vous vous connectez à votre compte, donc alourdirait l'expérience webmail; alors que direct sur le serveur, le traitement se fait à l'arrivée de chaque email, 1 par 1. C'est beaucoup plus léger comme traitement. Imagine que tu t'es pas connecté sur ton compte email depuis une semaine, t'as reçu des centaines d'emails à traiter d'un seul coup. Maintenant multiplie ça par tes utilisateurs. Ça fait des périodes où y a pas de traitement (la nuit), et soudainement plein (le matin), et tout ça en plus fait par le serveur web (du code PHP — dans le cas de Roundcube — qui tourne au moment d'une requête). Ça pourrait aussi être traité côté client en javascript, mais dans ce cas là se pose le problème de sauver la base de données du filtre (bayésien en général).
Enfin voilà, perso je trouve que c'est bien mieux ainsi.
Par contre il existe plusieurs techniques bien connues pour gérer le spam (envoyer à une adresse email spécifique, simplement déplacer dans un répertoire, etc.) et il pourrait y avoir une option pour mapper un bouton "spam" (ou "not spam" selon contexte) à ces diverses actions, selon technique utilisée. Ça oui, je suis d'accord, ce serait cool et rendrait l'expérience plus transparente aux utilisateurs.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: perf ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 3.
Tout est possible. Faut ensuite voir le "coût", que ce soit le coût de développement, c'est à dire la complexité, le temps que cela va nous prendre à avoir une architecture convenable, mais aussi le coût additionnel du traitement, et donc notamment le temps additionnel et la mémoire utilisée, etc. Déjà que beaucoup se plaignent du fait que le non-destructif peut être plus lent (car à chaque changement de l'image ou d'opération, on doit potentiellement recalculer toutes les opérations "au dessus"), et qu'il va rapidement bouffer toute la mémoire, voire swapper, et devenir encore plus lent (cf. commentaire plus haut au sujet de Darktable)… Puis faut voir si ce coût vaut le coup en comparaison du gain.
Surtout qu'au début on parlait d'optimisation, maintenant on veut rendre le traitement encore plus parfait (donc lent en général). :-)
Déjà il faut bien noter que ce n'est commutable qu'avec certains types d'opérations. Par exemple si une opération changeait les pixels en fonction de leur position, cela ne serait pas la même chose de l'appliquer avant ou après rotation (exemple typique: utilisation d'une texture que l'on va mapper au dessus de l'image). C'est un travail assez important de bien cataloguer les opérations. Et l'utilisateur a peut-être choisi exprès d'appliquer telle opération sur les pixels avant ou après une rotation car il voulait tel rendu, ou tel autre. Il faut donc bien faire attention quand on réordonne. Pas tout ne peut l'être.
Mais oui, il y a des moyens d'optimiser un graphe et c'est un travail qui demande du temps pour le faire bien, en utilisant des connaissances mathématiques puis en les appliquant à la réalité de la représentation algorithmique. Et surtout ne pas changer le rendu désiré par l'artiste.
Non, mon exemple est un arbre. Pourquoi en faire une généralité?
On pourrait avoir une opération qui re-rentre dans un autre nœud. Par exemple ci-dessous,
op1rentrerait dansop2et re-rentrerait dansop3, ce qui est très pratique car cela évite d'avoir à recréer des nœuds qui recalculeraient des opérations que l'on a déjà calculées.On a ce genre de graphes tout le temps dans Blender. Je ne suis pas sûr si GEGL permet plusieurs sorties, mais si ce n'est pas le cas à l'heure actuelle, ce ne serait pas dur à implémenter; ensuite il faut juste adapter l'UI. Dans GIMP, certains semblent ne pas vouloir une UI trop complexe. Ce que je comprends tout à fait pour l'UI de base, du moment qu'on puisse aussi proposer une UI alternative pour gérer des graphes complexes. Enfin on verra cela quand nous commencerons à réfléchir sur une UI pour le non destructif dans GIMP.
Je reprends donc mon exemple. Supposons que l'on ait une rotation comme opération non destructive sur le Layer 2.
Et voilà!
Une opération n'a pas forcément 2 entrées. Elle peut en avoir 1, 2… et même zéro! (par exemple une opération de chargement d'image n'a pas besoin d'entrée. Elle a juste un paramètre pour indiquer un chemin d'accès au fichier, ou même des opérations qui génèrent de l'aléatoire). De même pour les sorties.
Je ne peux pas vraiment répondre à ce type de questions. Comme je disais, je ne suis pas du tout expert en algorithmique du traitement d'image. J'ai fait des maths à niveau correct et de l'algorithmique à la fac, mais c'était y a des années et je ne lis pas de livres de maths le soir avant de me coucher. Donc oui je comprends comment marchent les divers algorithmes quand je lis du code. Par contre non je ne pourrai pas comparer les algorithmes. Enfin si, peut-être si je me mettais à lire beaucoup sur le sujet, puis à prendre un crayon et difficilement essayer de me remettre à résoudre des problèmes mathématiques, mais je n'en ressens pas le besoin. :P
On a plusieurs dévs qui sont très calés sur ce genre de choses, et je leur fais confiance. De mon côté, je fais d'autres choses peut-être un peu plus terre à terre, mais bon, chacun son truc. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Il reste 41 heures pour ZeMarmot. Évalué à 2.
C'est très différent. Et nous avons beaucoup pensé à ce type de financement aussi, mais il ne correspondait pas à notre situation. Par contre, comme Creak le note, rien n'empêche d'utiliser Patreon (ou tout simplement de monter un système de financement mensuel sur le site) après coup, et on le fera peut-être.
Pourquoi Patreon n'était pas adapté? Car ça commence très bas. On dit aux gens qu'on va faire quelque chose et à chaque sortie (ou mois), on récupère le montant sponsorisé à ce jour. Or si c'est pour récupérer 100 € pour 1 mois de travail, autant faire tout bénévolement tout de suite. C'est acceptable quand on fait de la BD (même si 100 € la page par exemple reste faible, c'est moins ridicule que genre 100 € la minute d'animation, ce qui correspond à storyboard + 1440 dessins en HD). On voit bien que ceux dont les financements montent haut, c'est après pas mal de temps et qu'une certaine réputation s'est installée. Cela marche donc OK si on est déjà célèbre ou après beaucoup de temps, et surtout pour une seule personne (si on est 2, 3, 4, ça divise le financement de beaucoup). Et cela ne prend pas en compte le financement initial. Nous voulions voir avant de commencer notre projet si les gens nous suivraient.
Par contre, quand notre financement initial sera terminé, puisque nous avons passé notre premier palier, je pense que cela pourra être intéressant de compléter par un système de type Patreon, en effet.
Franchement nous éviterons autant que possible de mettre de la pub, que ce soit sur les vidéos (sur Youtube ou alors), sur nos sites, etc. Jusqu'alors je n'ai jamais mis la moindre pub sur la moindre de mes créations et je ne m'en porte que mieux. Pour moi cela pollue notre espace visuel. Et un bloqueur de pub, ce n'est pas la réponse selon moi. Ce n'est qu'un contournement. Moi, je rêve d'un monde sans pub, où il n'y a pas besoin de bloqueur de pub (cela n'arrivera probablement jamais, mais je ne souhaite pas être fataliste et contribuer pour autant à ce monde).
J'ai entendu des arguments, même non monétaires, notamment on m'a dit que les vidéos sans pub sur Youtube étaient dépriorisées par Google (une recherche va afficher des vidéos avec pub en haut en priorité). C'est triste, mais je trouve l'expérience des pubs sur Youtube tellement horrible et désagréable que je refuse à ce jour de le faire subir à ceux qui visionneront nos vidéos.
En outre, honnêtement je préfère de loin vivre de l'argent direct par des contributeurs qui veulent nous soutenir explicitement (à ce jour 313 personnes, dont nous ne connaissons pas la grande majorité, nous soutiennent; ça fait chaud au cœur, plus que de recevoir même 3 fois cet argent en échange de zombification publicitaire) que par les conglomérats de la pub qui ne sont que des parasites selon moi.
Et même si je sais que beaucoup de gens n'ont pas l'air d'être plus touchés que cela par la pub, j'espère tout de même au fond de moi que nos contributeurs s'en rendent compte (peut-être certains?) et nous soutiennent même davantage pour cela.
P.S.: c'est aussi un des trucs que j'apprécie sur LinuxFR. Les seuls "bandeaux de pub" qu'ils ont sont choisis et ciblés pour les projets amis et sont davantage du soutien explicite par LinuxFR à ces projets et un peu de mise en avant, non comparable à ces pubs horribles et impersonnelles qu'on a habituellement pour bouffer du "temps de cerveau disponible" en échange d'argent.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: perf ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 5.
En imagerie informatique, les données sont discrètes. Dans la "nature", une image est continue. Elle n'est pas une succession de point. Donc une vraie rotation physique n’abîme pas une image (tu as une photo posée sur la table, tu la tournes, elle ne perd pas en qualité! :P).
Mais dans une représentation bitmap, une image est une matrice limitée de point. Donc à part si tu fais une rotation qui garde une matrice (90°, 180°, 270°…), tes pixels d'origine se retrouvent entre 2 points de la matrice (les nouveaux pixels).
Exemple la matrice de pixels:
1 2
3 4
… après rotation à 45° devient:
Ce n'est plus une matrice, et il faut donc calculer les nouveaux pixels qui formeront l'image après rotation, à partir des pixels d'origine. Il y a pour cela divers algorithmes dit d'interpolation (regarde les paramètres de l'outil "rotation" de GIMP, tu peux voir que tu peux choisir le type d'interpolation, ce qui est bien sûr plutôt pour les utilisateurs avancés). Une interpolation possible pourrait être tout simplement de faire la moyenne pondérée entre les pixels qui chevauchent le nouveau pixel (c'est en gros l'interpolation linéaire quoi). Il y a d'autres algorithmes moins naïfs (ce qui ne veut pas dire que celui-ci est mauvais pour autant!), c'était juste pour prendre un exemple simple.
Dans l'UI, ça ressemble à une liste.
Mais c'est en fait un graphe où à chaque nœud, on a rentré 2 calques, ce qui a produit un résultat, que l'on va "compositer" avec un autre calque.
Ainsi la liste de calque:
"Layer 1" (Normal)
"Layer 2" (Multiply)
"Layer 3"
C'est un graphe:
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Docker et snappy
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal XDG apps testable sous Fedora. Évalué à 8.
La différence, c'est que Docker, c'est pour les serveurs, alors que là c'est un système de packaging utilisateur. On veut donc qu'un programme s'intègre à son environnement. Comme j'explique plus haut, on veut notamment lier les formats de fichier à une application (double clique sur un .xcf: ça doit ouvrir GIMP); on veut aussi mettre à jour le menu utilisateur automatiquement; on veut peut-être aussi fournir des infos aux autres logiciels pour interagir entre logiciels; on veut mettre l'icône de l'application accessible aux divers logiciels du bureau qui pourraient en avoir besoin, etc.
La partie sandboxing n'est pas pour moi la fonctionnalité cible. C'est uniquement une nécessité. Puisque ce sont des logiciels qui pourront être téléchargés d'un peu n'importe où, il faut pouvoir protéger un minimum l'utilisateur (même si on ne peut le protéger de lui-même et donc les risques existent toujours) et ses données.
Pareil pour les dépendances. Ce n'est pas à voir comme un but. Je suis certain que les dévs préféreraient ne pas en avoir besoin. Mais sans cela, un paquetage sera lié à une distribution en particulier (puisque chaque distrib a potentiellement des versions de lib différentes).
Le besoin, c'est simplement qu'il est très dur de télécharger un programme pour Linux quand il n'est pas packagé par sa distribution, ou seulement dans une version ancienne/bugguée. Et les rares fois où certains projets proposent quelques choses (en général juste une archive à décompresser quelque part), ça s'intègre absolument pas à votre bureau. Et s'ils proposent un paquetage de distrib, c'est limité à certaines distrib (.rpm, .deb, et encore pas toutes les distribs avec le même système de paquetage ne peuvent installer les mêmes paquets si certains chemins d'accès ou des noms de dépendances diffèrent par exemple…), et on a besoin des droits root pour installer.
C'est dommage qu'il n'existe aucun standard pour cela, et c'est ce qu'ils sont en train de créer.
D'ailleurs plusieurs font la remarque que c'est du GNOME, mais comme je le lis, même si cela vient de dévs GNOME au départ, c'est un projet de standard (XDG) qui devra fonctionner sous tous les environnements de bureau.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: perf ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 6. Dernière modification le 18 juin 2015 à 18:13.
C'est bien ce que je dis. Il faut créer de nouvelles sous-classes de nœud et y mettre tous les nœuds qu'on arrive à identifier d'une certaine catégorie, puis réarchitecturer une bonne partie de la lib pour mettre à profit les propriétés de ces types de nœuds, etc. C'est du boulot, et ce
il suffitme chagrine beaucoup. Pourquoi quelqu'un d'extérieur à un projet a souvent cette idée que les choses sont si simples à faire?Ensuite je le redis: on accueille les bonnes volontés! Si tu penses avoir les idées et les capacités pour optimiser GEGL, on sera tous très heureux.
La commutation sur pas mal de type de nœud est vraie théoriquement, pas dans la pratique.
Imagine une fonction f() qui transforme un pixel gris entre [0; 0.5[ en noir, et un pixel gris entre [0.5; 1] en blanc (on va travailler sur un canal unique).
Tu as au départ une image de 4 pixels (2x2) avec un pixel sur 2 noir puis blanc:
N B
B N
Applique maintenant f(). L'image est inchangée. Applique maintenant une rotation de 45°. Bon il existe divers algorithmes de rotation, donc on va juste supposer qu'on utilise un algorithme qui fait une moyenne entre les pixels adjacents.
Résultat final: une image totalement grise uniformément.
Commute maintenant les opérations. Fait d'abord la rotation (tous les pixels deviennent gris), puis applique f().
Résultat: tous les pixels sont blancs!
Nous avons 2 images totalement différentes au final. Théoriquement (mathématiquement) tu as raison, on peut réordonner ces opérations. Dans la réalité de l'imagerie informatique, ce n'est plus vrai.
En plus, je parle même pas du cas où f() utiliserait la position du pixel comme donnée d'entrée (par exemple pour effectuer un traitement en mixant avec une image de
pattern…), et déplacer les pixels avant ou après modifierait donc complètement le rendu aussi.Ben voilà, tu as compris. On ne peut pas juste optimiser naïvement comme les exemples proposés plus haut. C'est beaucoup plus compliqués que juste des mathématiques (celles ci sont la base, mais il faut ensuite pouvoir les appliquer dans la réalité des représentations informatiques).
Comment tu fais pour du compositing sans graphe? Une liste d'opérations ne permet que de modifier une image, mais dans la réalité, on (= tous ceux qui utilisent ce genre de logiciels de dessin et traitement d'image) mélange des dizaines d'images les unes aux autres. On pourrait même avoir des opérations qui rentre dans un noeud et re-rentre dans un autre nœud, pourquoi pas.
Enfin bon, de toutes façons, même sans aller plus loin, GIMP serait bien triste si on pouvait plus avoir de compositing (= adieu les calques!).
Je sais pas si tu as déjà testé l'éditeur de Node de Blender, mais tu pourrais presque plus rien y faire s'il s'agissait juste d'un système linéaire, et il perdrait soudainement beaucoup de son intérêt (alors qu'à l'inverse, à l'heure actuelle, c'est un des gros points forts de Blender).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Perte des avantage de mutualisation
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal XDG apps testable sous Fedora. Évalué à 10.
Perso j'attends ces technologies avec impatience.
Par contre ce n'est pas du tout fait pour remplacer les systèmes de packaging des distribs Linux (et j'espère sincèrement que personne n'aura cette idée saugrenue).
Sur mon ordi, 99% (doigt mouillé) sont des logiciels installés par le packaging de ma distrib. Par exemple j'en ai rien à faire que Firefox soit un chouille en retard en version. Pareil pour mes lecteurs vidéo/audio, libreoffice, ou de manière générale la plupart des logiciels que j'utilise et qui me conviennent très bien. Par contre il existe 2 cas où ça me gêne:
1/ Certains programmes ont un problème qui me gêne depuis longtemps (voire une régression, bug qui n'existait pas avant et apparu lors d'une mise à jour). Or en cherchant des infos, je me rends compte que ce problème est connu et corrigé par la version stable en download. Franchement dans ce cas, attendre que la distrib mette à jour son paquet, ce qui prend souvent du temps (surtout pour les petits logiciels) me fait chier.
2/ Il existe de rares cas où avoir les dernières fonctionnalités upstream est important, en général c'est en rapport avec ses activités. Typiquement pour moi: Blender, GIMP, Scribus… ont des fonctionnalités qu'on va vraiment utiliser dès qu'on les obtient. Je ne veux pas attendre je-ne-sais-combien de mois non plus.
Or sous GNU/Linux, les téléchargements sur site, c'est en général soit du source-seulement, soit des archives à décompresser, et à mettre quelque part. Un utilisateur de base ne sera pas capable de faire en sorte que les fichiers correspondants lancent la version téléchargée (par exemple, double cliquer sur un .blend -> cela lance Blender installé par la distrib, pas celui téléchargé). Vous n'aurez pas le programme dans le menu (donc la plupart du temps, les utilisateurs gardent le dossier décompressé sur le bureau pour accès "plus ou moins simple et rapide"). Etc. C'est chiant, sale (l'installation) et pas du tout intégré à votre environnement.
Or ce type de solution a pour but d'installer des apps en mode utilisateur mais de manière propre. Vous pourrez cliquer sur des fichiers qui ouvriront votre application (installation des fichiers desktop); vos menus seront mis à jour avec la nouvelle app, sa description et son icône, dans la catégorie adéquate; vous n'avez pas besoin d'encombrer votre bureau de répertoires, etc. Tout comme une app installée par le système de paquetage de votre distrib, intégrée et propre, mais en mode utilisateur et avec une version récente, avec des droits réduits (car installé depuis une source moins sûre) à donner au fur et à mesure à l'application!
Franchement je trouve cela extrêmement gênant que tous les logiciels Libres — si on veut la version upstream — sont finalement bien plus simples à installer sous Win et OSX que sous Linux.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: perf ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 4.
Bien sûr qu'on en est capable techniquement (comme un peu tout). Je parle de GIMP en particulier et j'entendais "ce qu'on pourrait faire", c'était pas une question de savoir si les langages ont cette capacité (quand même, heureusement qu'ils l'ont!).
Aussi ce que je disais, c'est surtout qu'il faut adapter l'architecture du code. À lire certains commentaires, on a l'impression que c'est trop facile, "il suffit d'optimiser" (yakafokon). Alors que pour le permettre, il faut identifier les cas possibles d'optimisation (comme je disais plus haut, des suites d'opérations matricielles, des ops sur des pixels si et seulement si elles ne sont pas dépendantes d'autres pixels de l'image, etc.), puis éventuellement adapter l'architecture du programme pour rendre ces optimisations faisables. Et ainsi de suite.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]