Je connaissais pas MXE. Mais je viens de jeter un œil.
Déjà MXE maintient sa propre liste de paquetage de dépendances. D'une, ça doit être un travail de dingue de les garder à jour et vérifier que chacun compile proprement à chaque nouvelle version; de deux, je suis persuadé qu'il n'est pas à jour sur plein de paquetages à cause du premier point (sauf si l'équipe est vraiment grosse?); de trois, même si l'installation des dépendances reste simplifiée certes par rapport à tout faire à la main, il n'empêche que tu te tapes des dizaines de compilations pour un gros projet.
Quand je compile GIMP par exemple, j'ai pas compté, mais avec les dépendances de dépendances, je pense qu'y a bien une vingtaine au moins de paquets installés. Ben ça se fait en genre une minute. C'est du pré-compilé. Donc c'est rapide, et surtout ça marche tout le temps. Le seul cas où une installation de dépendance foire avec crossroad, c'est si les serveurs Fedora sont down. :-)
MXE, ils compilent tout sur l'ordi de build. Donc c'est lent, et ça peut foirer (car on sait tous que les compilations, c'est pas parce que ça marche bien chez le dév que ça marche chez vous (même si c'est normalement le but recherché). Y a beaucoup plus de paramètres en compte.
Et surtout je ne me charge pas de cette liste de dépendances! Donc j'en ai genre probablement bien plus que MXE sans rien avoir à faire. Crossroad va simplement télécharger la liste des paquets Fedora dès que tu l'invoques et est donc toujours à jour par rapport à la dite liste.
Voici donc la liste complète des dépendances de Crossroad: http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_12.3/noarch/
MXE a ça apparemment: https://github.com/mxe/mxe/tree/master/src
C'est pas mal aussi, et j'ai pas compté précisément pour voir qui a la plus grosse. Mais je préfère de loin ne pas avoir à me préoccuper de cela.
Pareil j'ai l'impression que MXE va jusqu'à lui-même compiler MinGW ou MinGW-w64. Franchement toutes les grosses distrib ont MinGW/MinGW-w64 d'installable pour ton OS. Et si vraiment tu veux une version plus récente, y a des builds nocturnes officiels aussi (en tous cas pour MinGW-w64). Vraiment pourquoi s'embêter à compiler ça?
Tout comme les dépendances, je préfère de loin déléguer.
Pour le reste, si tu regardes le tuto de MXE, ça aide pas beaucoup plus que cela. J'ai l'impression que son point principal, c'est de proposer des Makefile pour diverses dépendances.
Mais ils te demandent toujours de modifier tes variables d'environnement et de taper les configure et cmake à rallonge. C'était justement la partie chiante que je suis content d'avoir automatisé. Après tout, c'est toujours les mêmes options. Pourquoi me faire chier à les taper ou copier-coller à chaque fois plutôt que les automatiser dans un script?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Mon outil configure le projet pour s'installer dans un préfixe donné, ainsi que toutes les dépendances pré-compilées (car on veut pas mélanger des binaires Win avec son OS). Dans la pratique, ça rajoute simplement un --prefix automatique à ton ./configure pour qu'on ait pas à y penser à chaque fois.
Ce crossroad --symlink est juste un petit raccourci de mon outil pour créer un lien (nommé gimp) qui lie l'environnement w64. J'utilise ça pour ma VM Virtualbox qui communique avec mon OS notamment par un dossier partagé. C'est plus simple que d'échanger un zip avec ma VM (ce serait un peu ridicule).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'ai jamais tenté de compiler sous nux avec Wine et MinGW. Mais sous Windows avec MinGW, c'est aussi d'une lenteur effroyable. Je sais pas ce que le compilo fait, mais il le fait pas vite. :-D
Penses-tu que ton outil va me simplifier la vie ? En particulier, est-ce que ça va compiler a une vitesse normale et en utilisant tous les cœurs ?
Je pense oui. Avec la cross-compilation native (pas Wine ou autre environnement bâtard entre deux-OS pour l'exécution. C'est "natif" dans le sens où ça utilise un compilo fait pour tourner sous nux, seulement il compile à destination d'un autre OS), ça va super vite chez moi (tout aussi vite que la compilation nux pour nux).
Est-ce simple d'utiliser une bibliothèque non présente dans le MinGW de Fedora (j'utilise notamment libclaw) ?
Oui. Il suffit de le configurer, compiler et l'installer avant ton projet, pareil que le projet normal. Il sera installé dans le même préfixe que le reste (les libs installées par Fedora en particulier), et donc quand tu configureras ton projet, il trouvera ces dépendances compilées également.
GIMP master par exemple nécessite babl et GEGL master aussi, qui ne sont pas présents dans Fedora aussi, ainsi qu'une version de cairo supérieure à ce que Fedora propose. J'installe donc ces 3 dépendances supplémentaires avant d'installer GIMP. Ça marche nickel.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'ai essayé de retrouver vite fait la licence Win 7 sur le site Microsoft après ton message, mais je tombe que sur Windows 8 partout. Je vais dormir là, mais je chercherai demain à nouveau, sauf si quelqu'un trouve avant et poste le lien ici. :-)
En tous cas, j'avais lu la licence de mon OS exact à l'époque, spécifiquement pour savoir cela, et ce point précis était très clairement marqué dedans (vraiment non-ambigu d'après moi, ou alors de manière très fourbe). Je me souviens qu'il y avait un point précis dans le contrat qui dit qu'on peut l'utiliser dans une VM.
En plus comme j'avais pas de CD Windows (comment souvent maintenant dans les portables, qui te vendent avec une sorte de partition cachée qui permet de réinstaller l'OS), j'ai même demandé au vendeur du portable de me le filer, en disant au support que c'était pour l'utiliser en VM, plutôt qu'en OS principal, car autorisé par le contrat. Et ils m'ont filé un iso officiel sans même poser plus de questions.
Donc oui j'en suis sûr, autant que faire se peut quand on n'est pas juriste. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je vais regarder (avec des vrai(e)s utilisat[eur|rice]s que je connais, moi je suis juste un bricoleur) à faire des mockups de cette implémentation de batch, car c'est un sujet qui passionne tout le monde et sa sœur, et tous ont une idée de ce à quoi ça pourrait ressembler (workflow / interface).
Si t'as des mockups, et des idées plus ou moins ("plus", c'est mieux) clairement spécifiés, etc. tu peux participer au GUI brainstorm: http://gimp-brainstorm.blogspot.co.nz/
C'est un peu mort, parce que notre expert UI s'était éloigné de nous, mais il vient de revenir y a juste une semaine. Donc nos retours UI vont s'améliorer.
Tant qu'on y est, ce qui serait super, ce serait de faciliter l'usage de GIMP pour l'animation, avec une "table lumineuse" qui montre les détours des n calques inférieurs, et permet de "jouer" (juste une commande play / pause / accell < > quoi) qui fait "défiler" l'affichage desdits calques) l'anim. En attendant je triche avec les opacités de layer et l'export GIF et ça marche.
Je suis pas certain de comprendre ta comparaison avec une table lumineuse. Veux-tu simplement dire une timeline où on peut spécifier plusieurs calques par frame (et pas comme actuellement, 1 calque = 1 frame)? Si c'est le cas, sois en joie, car c'est en travaux. Je suis depuis quelques mois le mainteneur officiel du plugin core animation-play qui est fourni avec GIMP. Et je suis justement en train de travailler sur ce dont tu parles. Si tu voyais ma version de dév actuelle, tu verrais que ça n'a déjà plus grand chose à voir avec la 2.8. :-)
J'entends également des critiques sur la gestion interactive (une main sur le clavier, l'autre sur la wacom) des brosses, qui ne me posent personnellement aucun problème (mais je ne pains pas avec aussi).
Oui il paraît que GIMP n'a pas les meilleures brosses. Si je pige bien, MyPaint serait vraiment sympa pour créer des brosses (cad que l'UI serait plus aisée à manipuler). Par contre je crois qu'elles sont plus limitées (les brosses sont toutes formées de cercles comme forme de base, ou un truc du genre). Krita aurait les meilleures brosses à ce qu'on dit. Dans tous les cas, on dit que MyPaint et Krita sont tous deux spécifiquement dédiés aux peintres (c'est comme cela que ces deux projets se présentent). GIMP se veut plus générique. Il fait de tout: du croquis au traitement photo en passant par la peinture. Depuis les derniers Libre Graphics Meeting, les 3 projets GIMP, Krita et MyPaint essaient en fait de collaborer pour partager leurs pinceaux (ou du moins pour que chacun soit capable d'utiliser les pinceaux des 2 autres). Bon je suis pas sûr que le projet avance énormément, mais les bases de la discussion sont posées.
Ensuite pas mal de gens dessinent quand même des trucs très cools avec GIMP et la dessinatrice avec qui je travaille semble apprécier créer des brosses et des dynamiques dans GIMP. Un peu d'auto pub: mon webcomic sur la vie d'une Marmotte aventureuse. Y a pas beaucoup de mises à jour parce qu'on revoit pas mal de trucs en cours de route, mais ça devrait prendre le rythme au bout d'un moment. :-)
l'Amiga (où on avait une chaîne de traitement bitmap hors-pair, de Deluxe Paint et Brillance pour l'anim, à ADPro pour le batch, en passant par TVPaint (mais il fallait une carte graphique) ImageFX et PhotoGenics et je parle même pas de la 3D…
Oui j'entends pas mal parler des supers progs de dessin de l'amiga. Moi à l'époque, mon grand frère a eu un amiga pendant environ 2 ans et on faisait que jouer dessus avant qu'on grille l'alim (oui l'alim, c'est rien, mais nous on y pigeait que dalle et mes parents sont danseurs, ils y pigent encore moins), puis on a pas eu d'ordi pendant pas mal d'années. Je suis loin d'avoir eu une jeunesse de geek, je me demande comment j'ai tourné ainsi! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je m'explique: si vous faites un texte et que vous voulez ajouter une ombre et une rotation, rien de plus facile. > Maintenant, si je veux modifier le texte parce qu'il y a une erreur, je dois me retaper à la main la liste des effets que je lui ai mis… Et sincèrement quand on modifie régulièrement une même image, c'est vraiment ULTRA relou !
Tandis que sous photoshop, le calque original et chaque effet reste entièrement éditable après coup !
C'est ce que j'appelle plus haut l'édition non-destructrice avec les calques d'effets. C'est prévu. C'est peut-être même une des conséquences majeures qu'apportera GEGL. Par contre les chances d'avoir ça pour GIMP 2.10 sont très faibles, car bien que le port GEGL sera alors complet, il n'y aura pas l'UI pour en tirer profit. À moins qu'on ait plus de dév d'ici là, par exemple.
Les actions, aussi
Clairement c'est un des autres gros points manquants. C'est aussi une fonctionnalité qui je pense demandera beaucoup de réflexion et de temps pour la faire bien (on peut la développer à-peu-près relativement rapidement, mais on aime le beau code).
mais là en l'état il n'y a pas de gestion par lots "batch" à proprement parler - heureusement qu'il y a imagemagick
En effet à l'heure actuelle, même s'il y a un mode console pour GIMP (on peut même compiler que le mode console de GIMP, sans UI donc sans dépendance à X si on veut. Pour un serveur par ex), c'est pas l'extase. Je pense même qu'aucun des dévs ne considère cela comme une fonctionnalité majeure de GIMP. ImageMagick est clairement beaucoup plus efficace car fait pour.
Quand des utilisateurs nous parlent de cas d'usage qui est clairement un travail à la chaîne (donc du batch) et se plaint que GIMP est pas efficace pour cela, on leur dit à chaque fois d'aller essayer ImageMagick, clairement adapté à l'usage.
Peut-être qu'un jour, quand on aura plus de dévs, en particulier des dévs qui s'intéressent à ce mode et ces usages, et leur donne un peu d'amour, GIMP y sera bon aussi. Mais pour l'instant, je pense qu'il faut accepter ce fait, ou alors retrousser ses manches et nous aider. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Aussi faut bien voir que travailler directement en CMYK, c'est pas "vraiment" possible. Même si tu stockes en CMYK dans le fichier ou en format interne dans le programme, ton écran lui est toujours RGB. Donc y a forcément des tables de correspondance ou autre truc du genre et par définition, ça ne peut pas être parfait car c'est tout simplement 2 systèmes totalement différents. J'ai pas encore regardé les détails d'implémentation de ce genre de chose donc je veux pas dire trop de bêtise non plus, mais bon faut être bien conscient que c'est pas parce que le fichier est stocké en CMYK que soudainement, ce que tu as à l'écran, c'est comme ton papier. Non l'écran est et reste du RGB. Papier et écran/projecteur, c'est structurellement différent.
Oh et j'oubliais aussi dans mon énumération précédemment des choses à faire si tu veux faire les choses bien! Quand tu calibres ton imprimante, tu dois en fait calibrer (et donc générer un profil) par couple (imprimante, papier). Tu ne calibres pas pour l'imprimante seulement, ça n'a pas de sens, car chaque type de papier (couleur, texture, etc.) est différent. Donc avec la même imprimante, tes couleurs sortiront différemment selon que tu imprimes sur ton papier blanc, fin et mat ou ton autre papier qui tend vers le rose, plus épais et brillant. La gestion des couleurs est vraiment un enfer. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui j'ai regardé un peu la description de GEGL sur Wikipédia, ça a l'air bien sympa :).
Ça l'est! :-)
Je suppose que ça va permettre d'amener des fonctionnalités réclamées comme les profondeurs à plus de 8 bits
Oui et c'est déjà là! Lance ton GIMP master compilé, et regarde le menu Image > Precision.
Y a du 16 et 32-bit, entier, flottant, linéaire, gamma, pour tous les goûts!
C'est pas encore porté sur tous les outils, donc c'est du travail en cours, mais le principal est là.
et le support CMJN (dont personnellement je me moque, mais qui servent probablement au niveau pro).
Ça sert pour ceux qui impriment. Un pro de l'image qui sort pas de l'écran n'en a rien à faire. Mais oui c'est une des fonctionnalités les plus demandées, car beaucoup soit impriment (designers d'affiche, etc.), soit ne comprennent pas à quoi ça sert et comment, mais on leur a dit que le CMYK, c'est pour les pros. :-)
Aussi en vrai avoir un tel support dans ton software de graphisme n'est pas suffisant. La question des couleurs est extrêmement compliquée (pas que sur le sujet CMYK, mais les couleurs en général), et je balbutie moi-même et commence à peine à comprendre certaines choses (mais encore bien trop peu! Donc je dis sûrement beaucoup d'âneries sur le sujet). Et la plupart des gens, c'est pareil. Ils croient qu'il suffit d'avoir un programme avec un bouton "CMYK", ils cliquent dessus, et c'est bon, ils sont des pros ("la preuve! Je clique sur le bouton CMYK!"). En vrai c'est genre 1000 fois plus compliqué. Y a les questions des profils de couleur, pour faire bien tu dois calibrer tes écrans, tes scanners, tes imprimantes (ce qui génère les dits profils). Et pour le faire, y a des outils au tarif décent (comme le colorhug, c'est openhardware, et "seulement" 75 EUR. Je l'ai acheté d'ailleurs!), mais c'est limité. Si tu veux faire vraiment les choses professionnellement, tu dois avoir des outils de calibrations à des tarifs bien plus haut (plusieurs centaines d'euros), un photospectromètre, etc. Et ça sert pas à grand chose (ou moins en tous cas) si t'as un écran pourri, si t'as un ordi portable (sauf si tu le bouges jamais et change jamais l'angle de l'écran), si t'as des fenêtres (ou alors ferme les volets!), si tes murs sont peints en autre chose qu'en gris, etc.
Sans déconner, j'ai entendu dire que les grands studios de cinéma pro ont ce genre de pièce pour aller visionner leurs films correctement.
Je suis persuadé que 90% des gens qui travaillent en CMYK font pas les choses comme il faut (même sans aller dans les extrêmes comme aller travailler dans ta cave peinte en gris!).
Quand Photoshop te dit "on a du support CMYK", c'est surtout très marketing. Voire certains disent que c'est un peu une forme de mensonge. À vrai dire, il semblerait que Adobe même est en train de réfléchir à faire marche arrière sur pas mal de choses au sujet de la gestion de couleurs, alors même qu'ils ont contribué à créer et populariser tout ça. Par exemple, y a eu cet email d'un représentant Adobe dans le CSS working group où il est en train de dire en gros que la gestion des couleurs, c'était peut-être une erreur de leur part depuis le début car bien trop compliqué, et d'autres ont bondi à cette déclaration. Bon je t'avoue que je pige pas tout dans la discussion, mais c'est peut-être justement parce que je pige pas beaucoup dans la gestion des couleurs (en ce sens, cet employé Adobe a raison quand il dit que c'est compliqué!).
Sinon est-ce que GEGL/BABL aideront pour ajouter le support dans GIMP? Je pense en effet que ça pourra aider car on a plus d'abstraction pour travailler sur les formats avec BABL. Malheureusement je crois que personne ne travaille sur le support de CMYK pour le moment (si je ne m'abuse). Je pense que les dévs de GIMP actuel n'ont pas le besoin et ont d'autres priorités (moi de même). Il nous faudrait un dév qui ait ce besoin (ou bien qu'on ait terminé nos autres priorités!).
Dans le Logiciel Libre, même si on travaille ensemble au final, chacun a un peu son propre plan à long terme. :-)
Mais l'une des fonctionnalités majeures que cela va apporter, c'est surtout l'édition non destructrice. Par exemple les effets pourront être appliqués avec des calques d'effet, dont on peut modifier les paramètres, ou supprimer pour retrouver l'image originelle, etc. GEGL est un système de traitement d'images en graphe, où les effets et autres traitements sont des nœuds avec entrée et sortie. Un peu comme le compositing dans Blender avec des nœuds (sauf que nous n'aurons probablement pas une UI en graphe comme Blender. Je pense que ce serait génial perso, mais a priori le designer qui bosse avec nous pense différemment. Mais c'est pas encore sérieusement discuté, donc y a la marge et le temps).
Bon tout ça (édition non destructrice) ne sera certainement pas dans GIMP 2.10. Ce serait GIMP 3.0, voire même après. On aura les fondations dans 2.10, mais pas l'UI. Mais c'est le chemin pour y arriver.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
l'outil d'extraction de premier plan ne fonctionne pas
Il n'est pas encore porté sur GEGL, notre nouveau moteur. Une personne avait commencé le travail, mais n'a jamais terminé et on a un travail à moitié fait.
les ciseaux intelligents semblent avoir disparus (j'espère qu'ils ne comptent pas les enlever !)
Je sais pas pour celui-là, mais c'est peut-être la même chose. En tous cas, le code est toujours là. Quoiqu'il en soit, l'équipe n'a pas pour pratique de retirer des fonctionnalités utilisées. Mais je suis en train de demander sur le canal IRC, au cas où.
et affreusement lent
Oui, comme tu dis, c'est une version de dév. On déconseille fortement de l'utiliser en prod (quasi impossible dans l'état actuel). Et encore, y a quelques mois, c'était 10 fois plus lent. Tu faisais un simple coup de pinceau et tu voyais ton trait apparaître à la vitesse de l'escargot asthmatique. :-D
Comme dit plus haut, on porte entièrement le moteur de GIMP vers GEGL. C'est un travail de fond, peu visible certes dans l'UI, et comme GEGL est encore très jeune, la stabilité a priorité sur les optimisations, qui vont venir avec le temps.
L'outil de déformation en lui même je n'ai pas compris comment il sélectionnait uniquement les parties non transparentes de son calque sur la vidéo: en prenant la même image de Sintel, en la détourant, recadrant et dedimensionnant à peu près comme sur la vidéo (sinon ça râme), à chaque fois que je clique ça met la grille sur toute l'image, et du coup la déformation n'est pas la même. J'ai réussi une fois par accident à avoir la grille de la même manière que sur la vidéo, mais je n'ai pas encore réussi à reproduire ni à comprendre pourquoi. Je ne sais pas si c'est un bogue ou une combinaise de touche que je ne fais pas (les options ont l'air identiques à la vidéo).
Ah et aussi les actions de ce nouvel outil ne sont pas encore ajoutées correctement dans l'historique d'annulation.
J'ai vaguement testé y a quelques semaines. Donc j'en sais pas beaucoup plus que toi. En testant sur une image avec fond transparent, la sélection avait bien marché, si je me souviens. Je crois pas avoir testé avec fond non transparent, par contre. En tous les cas, oui, c'est pas intégrable en l'état.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'aime les logiciels console, et j'utilise ffmpeg à l'occasion pour réencoder des vidéos, par exemple. Mais c'est vrai que des fois, je veux pas me faire chier et j'aime bien cliquer sur un bouton, surtout pour des trucs aussi chiants qu'enregistrer des écrans.
Ceci dit, les GUIs sont pratiques sur d'autres aspects aussi. Par exemple pour pouvoir ajouter un décompte. Tu vas me dire qu'on peut juste couper les premières secondes de vidéo, mais des fois, tu fais une vidéo, et basta. T'as pas envie de retoucher, quand c'est pas pour l'art.
Et ffmpeg permet-il aisément de n'enregistrer qu'une fenêtre sélectionnée (comme dans ma vidéo) ou qu'une zone de l'écran sélectionnée à la souris? Ou faut-il faire un crop dans un NLE après? Ça aussi par exemple, ce sont des détails, mais c'est toujours ça de gagné quand on veut pas se faire chier. Si je fais une vidéo pour montrer un unique programme, j'ai pas vraiment envie de montrer ma barre des tâches, ou bien les évènements du desktop quand on m'envoie un message par IM, etc. Et les GUIs permettent de sélectionner ainsi juste ce qu'on veut montrer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Le terme "pas très intégré" me parait un peu exagéré. A priori on ne peut de toute façon pas "intégrer" une fonctionnalité dans un framework qui n'existe pas encore.
Y a tout de même un framework de plugin. Ce qui n'est pas là, c'est un système de gestion des plugins.
Mais oui ça peut être mieux, c'est sûr. :-)
C'est un peu le problème avec GIMP, on a toujours un peu l'impression de devoir attendre les fonctionnalités arriver ;)
C'est vrai. L'équipe est bien trop petite. Encore une fois, on y peut rien malheureusement.
J'essaie un peu d'accélérer les choses, à mon niveau, mais ça reste très limité bien entendu. Par exemple ces derniers jours, j'essaie de pousser une sortie de correctifs (donc 2.8.8). Y a pas de nouvelles fonctionnalités bien sûr, mais je pense que même les versions mineures, GIMP met trop de temps à les sortir, et j'aimerais accélérer le rythme.
Les versions majeures, j'aimerais aussi qu'on les accélère, mais je pressens que cela ne pourra être fait avant au moins la 3.0, et encore il faudra arriver à convaincre les autres. Car la 2.10 (GEGL) et la 3.0 (GTK+ 3) sont des chantiers trop gros et ne peuvent être fait "partiellement".
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je prévois probablement de travailler sur un système de gestion de plugin. Si le projet va au bout (pas commencé le moindre code, mais j'ai déjà commencé à gribouiller des idées et à regarder à droite à gauche ce que font les autres, comme Mozilla, etc.), on devrait pouvoir installer/désinstaller facilement avec une liste à jour, et surtout les mises-à-jour devraient être automatiques aussi. Comme dans Firefox quoi.
Sauf que ce sera fait de manière générique pour tous les plugins, y aura plus besoin de bidouiller dans ton coin (ce qui est super, mais comme le fait remarquer Julien Jorge, pas très intégré malheureusement).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'en ai essayé pas mal parce qu'y en a beaucoup qui sont dans les dépôts de distribution mais qui ne marchent tout simplement pas.
Si je me plante pas, pour cette vidéo, j'ai utilisé Kazam sur une partie et FDesktopRecorder sur une autre: http://youtu.be/osSiETyae5c
Donc je les recommande. Ils marchent bien.
Par contre RecordMyDesktop, je n'ai jamais réussi à rien en tirer. Déjà la vidéo est en général tout simplement dégueulasse, avec plein d'artefacts. Inutilisable en un mot. Et aussi il crashe tout le temps (j'ai encore la mauvaise expérience d'un atelier dans mon emploi précédent que j'enregistrai, et à la fin de l'atelier, je me suis rendu compte que RecordMyDesktop avait crashé au milieu!).
Par contre la guerre libav/ffmpeg est vraiment un désastre. J'aimerais vraiment qu'ils se décident à clairement renommer l'un des deux parce que ces derniers temps, j'ai croisé et patché des bugs dans plein de logiciels à cause d'incompatibilités.
Le problème est qu'ils ont le même nom, réutilisent même les noms d'outil de l'autre projet (en les disant dépréciés, mais en s'emparant du spot quand même), mais que les uns les autres intègrent de subtiles différences et incompatibilités un peu partout dans l'API.
Maintenant dès qu'un logiciel utilise libav, je me mords les doigts pendant la compilation parce que les chances d'erreur pendant compilation ou link sont démultipliés selon ce que les dévs utilisent eux-même.
Je parle de ça parce que j'ai eu plusieurs problèmes notamment en compilant des logiciels de screencast (par exemple pour compiler FDesktopRecorder sur ma Linux Mint).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
faut que quelqu'un trouve de temps de faire la revue de code, nettoyer, corriger ce qu'il y a à corriger, puis merger. Si personne ne le fait avant moi, c'est dans ma TODO list parce que cet outil m'intéresse aussi pas mal.
Le GSOC, c'est cool, mais cela reste des étudiants. Certains font un bon travail, mais il reste un énorme travail après coup pour finir. Pour tout dire, on a des gsoc de 2011 pas encore intégrés dans la branche principale.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Si les intégristes libristes gimpiens passent par là, j'ai aussi deux mots à leur dire concernant la taille des calques (mais si, le truc qui sert à rien et qui empêche de bosser correctement), et je préviens, je serai méchante è.é ! À ce propos, y'a un petit gars qui se propose de sauver nos vies, aidons le :). C'est ici que ça se passe :). Il propose entre autre l'abolition des ces p… de limites de calques à la c… . J'ose à peine y croire. Nous voilà en plein hs, finissons en là.
C'est moi!
En effet, les calques en dehors des limites desquels on ne peut pas dessiner ennuient beaucoup la graphiste avec laquelle je travaille. Cela pourrait être un des très prochains projets sur lequel je travaillerai si ce crowdfunding marche bien. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Si c'est pour de la photo, t'as essayé les logiciels dits de développement numérique? Genre en libre y a darktable, ou encore RawTherapee qui ont vraiment l'air sympa. Je ne les ai pas utilisés tant que ça parce que je ne fais pas beaucoup de photo, mais je les ai un peu manipulés, et c'est une interface bien plus sympa pour manipuler des dizaines, voire centaines de photos à la fois.
C'est un concept différent. Ça ne fait pas tout ce que GIMP fait, et pour certains trucs, notamment du travail dans le détail, tu auras toujours besoin de GIMP. Mais pour du traitement de masse, des effets, etc. ça a l'air d'être beaucoup plus adapté.
Bien sûr, c'est vraiment plus pour ceux qui travaillent en raw, mais ça marche tout aussi bien si tes photos sont en jpeg ou autre format.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Non. T'as raison en fait. Si on veut faire générique, autant faire en sorte que plein de trucs soient possible, même pour des cas d'usages auxquels on pense pas au début.
La seule chose compliquée est toujours de réfléchir à une archi qui permette tout de même de bien présenter l'outil de base (à savoir ici des axes ou centres de symétrie) de manière agréable, mais pour permettre d'aller plus loin pour les "hardcore gimpers". Faut pas que l'UI ait trop plein d'options inutile à 99% des gens, ni que ce soit rébarbatif de mettre un mode miroir. Le gars qui veut juste un miroir vertical, prêt à être déplacé à la souris et dessiner direct, il doit pouvoir le faire en un/deux clic ou un raccourci.
Et passer par l'API (pas forcément besoin d'être développeur pour ça: il en suffit d'un pour uploader sur http://registry.gimp.org/) est la meilleure solution pour étendre des fonctionnalités sans rendre l'UI imbitable.
Et à vrai dire, j'avais aussi pensé que ça pouvais être intéressant qu'un point soit transformé en plusieurs autres points.
J'y réfléchirai. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Aussi, je vois pas le problème à utiliser deux outils différents pour deux usages différents (un pour l'édition avancé, un autre pour l'édition simple).
Par exemple, la plupart du temps, quand je veux juste tirer du texte simplement d'un fichier, je préfère utiliser grep, éventuellement avec une regexp, ça reste le plus simple d'utilisation. Quand je veux en plus remettre en forme le retour, j'utilise sed. Et il peut m'arriver assez rarement d'utiliser awk pour certains types d'extraction. Et je suis super content qu'on ait plusieurs outils d'extraction de texte, dont un très basique comme grep, parce que j'aimerais pas me manger des syntaxes compliquées juste pour chercher du texte (j'utilise grep des dizaines de fois par jours).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui, toute transformation devrait être simple à ajouter, du moment que tu me donnes une formule avec en entrée les coordonnées du pinceau, et en sortie les coordonnées de la transformation. :-)
A vrai dire, en y réfléchissant bien, on doit même pouvoir faire en sorte de rajouter très facilement des types de transformations (pour ne pas encombrer le système de base de trucs très particuliers, mais tout en laissant ceux avec un besoin particulier en créer facilement et se les échanger sous formes de scripts). Genre on rajoute une méthode dans l'API de libgimp, qui prend en paramètre un handler qui a la forme adéquate (fun: int*int -> int*int en gros), et ça ajoute un type de transfo possible. Donc les gens peuvent ajouter un type de transfo avec un plugin GIMP (C, Python, perl, etc.) en quelques lignes et une formule. Intéressante idée.
Mais t'as un besoin précis pour ce genre de dessins, ou bien tu me dis juste ça parce que ton cerveau bouillonne de transfo mathématiques et que tu te dis que c'est cool, mais en vrai t'utiliserais pas?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
eh beh, tu aurais encore moins aimé être un artiste avant l'avènement de l'informatique alors! ;-) À l'époque, c'était des layers… de peinture les unes sur les autres. :p
Plus sérieusement: les calques-effet sont en projet. Tu as peut-être entendu parler du port vers GEGL qui est en cours, et qui sera pleinement effectif à la sortie de GIMP 2.10 (ou l'inverse: quand on finit, on sort la 2.10 :p). GEGL est une librairie de traitement d'image en arbre (avec des "nodes", qui sont en général des effets, ou du moins un traitement quelconque avec des entrées et des sorties).
Ce port est la première étape. À ce moment, on aura un cœur avec support de l'édition d'image non-destructive, sauf que ce sera toujours destructif dans la réalité, parce qu'on aura pas encore d'UI adéquate.
La seconde étape sera donc pour nous de déterminer une UI efficace, qui impliquera dans une forme ou une autre des calques à effet, pour faire exactement ce que tu dis.
Maintenant, il y a cependant des workflows variés qui impliquent du dessin avec miroir. Ce dont tu parles, j'ai en effet vu et utilisé un peu sur blender. Mais ça permet plus des miroirs parfaits. Pour une œuvre d'art, tu voudras "réparer la perfection", et y rajouter de l'imperfection. Par exemple, si tu fais un visage en dessinant en miroir seulement la moitié, après coup, tu veux arrêter le miroir, et faire les détails en mode normal. Regarde par exemple comment la dessinatrice fait le lapin dans ma vidéo. Or dans ta proposition, un miroir s'appliquerait sur un calque complet. Donc ça rendrait cette manœuvre délicate. Par exemple même sur blender, quand on applique un effet de miroir sur un objet, au bout d'un moment on va l'appliquer et se mettre à travailler dans les détails. Car on ne peut pas garder l'effet tout du long si on veut faire des détails. On perd la donnée "miroir" en effet. Mais c'est la différence entre le dessin industriel et l'art. Dans l'art, on cherche pas à sauver l'info, mais à avoir le meilleur résultat final. Or c'est souvent incompatible.
Bien sûr, tu peux faire les détails dans un autre calque. Mais franchement ce ne serait pas un workflow très cool de devoir faire les bouts de détails du lapin sur un calque séparé (ce serait comme faire un second objet 3D pour faire uniquement les détails non symétriques de ton objet symétrique). Du point de vue du dessinateur, ce serait un horrible design pour la gestion des calques.
Pour tout dire, on a discuté cet exact sujet hier sur le canal IRC, au sujet de la meilleure manière d'implémenter le miroir (parce que comme on a GEGL maintenant, c'est en fait déjà techniquement possible de faire ainsi). :-)
Mais cela reste très intéressant, pour d'autres types de workflow et de dessins par rapport au projet présentés. C'est complémentaire quoi, et ce sera possible quand on aura enfin les calques à effet. Donc à ce moment là, on aura les deux workflow possibles, pour satisfaire tout le monde.
Quand? Ben je sais pas. On manque de mains. Nous aussi on aimerait que tout ça aille plus vite. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Uh? Où c'est que je l'ai critiqué? Je l'ai rencontré, et il avait l'air très sympa. C'est pas insultant de dire que c'est une star locale (locale dans le monde du Libre, j'entends, avec son implication dans divers logiciels Libres: GIMP, MyPaint, Krita, Blender. Et oui si je dis "local", c'est parce qu'il est pas non plus De Vinci, qu'un quidam connaîtra même s'il ne s'intéresse pas au sujet. C'est donc "localisé"). C'est même bien d'être une star locale. Et dans le cas de David Revoy, je pense vraiment que c'est justifié. Si on devait citer un artiste peintre dans le monde du Libre, c'est un des premiers noms qui vient en bouche. Je suis sûr qu'il en est conscient.
Je pense que tu peux chercher les bugs du bugtracker de GIMP où David Revoy intervient. J'en trouve deux. Je crois pas qu'il ait jamais été maltraité. En particulier celui là (l'autre bug, y a pas de réponse): https://bugzilla.gnome.org/show_bug.cgi?id=663582
On peut voir un échange tout à fait cordial entre Alexia, Mitch et David. David rapporte ses problèmes, fait des vidéos, Mitch est d'accord pour dire que ça a vraiment pas l'air terrible, essaie de corriger, pose des questions et propose des patchs à tester. Au final David est plutôt content du résultat, mais le patch reste ouvert parce qu'on est conscient qu'y a encore bien des choses à améliorer.
Donc au lieu de dire qu'on l'a très mal reçu, qu'on aime pas les stars (ce qui n'est pas du tout ce que j'ai dit), et qu'on est des vrais qui font aucun marketing parce que c'est le mal (je pense que la campagne de financement en cours est un bon exemple du contraire), il faudrait un peu se renseigner, ou lire ce que j'écris.
Je sais pas pourquoi y a des gens qui ont toujours besoin de voir des conflits et du mauvais esprit partout. Perso j'ai une dent contre personne, et sûrement pas contre David Revoy, que je connais pas vraiment, mais que je rencontrerai peut-être à nouveau. Et ce jour là, je lui serrerai la main avec plaisir.
Tout ce que je dis, c'est que Krita et GIMP ont une gestion de projet vraiment différente. Y a beaucoup moins de recherche d'image chez GIMP. Et je n'ai jamais dit que c'est bien, ou pas. En tous cas, le résultat est qu'il est clair qu'il est probablement plus avantageux pour un artiste comme David Revoy de s'associer à Krita dans la configuration actuelle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je ne ferai qu'un seul message sur le sujet, car c'est un point extrêmement trollesque, et ça part facilement en vrille. Donc je dirai ce que j'en pense de manière complete.
Déjà il faut savoir qu'il y a quasiment aucune chance que ça revienne comme avant. Sauf si genre tous les développeurs actuels de GIMP meurent ou un truc comme ça. Donc pour avancer, il serait mieux pour toi de t'y faire. :-)
Deuxièmement l'idée est très simple: tu sauves ton travail. Mais tu exportes un "snapshot" de ton travail, à un moment X ou Y. Ton travail complet implique des calques, des groupes de calques, des masques et canaux, des vecteurs (chemins), du texte (pas le texte déjà incrusté dans ton image, mais bien un texte encore modifiable, contenu, font, taille, etc.), et ainsi de suite. Tout ça à la fois, y a que dans le format natif de GIMP qu'on peut le sauver.
L'export, c'est ton snapshot, pour rendu final, pour impression, envoyer sur le web, montrer à tes potes, intégrer dans ta présentation, ouvrir avec un logiciel différent, ou que sais-je encore.
C'est comme dans blender. Tu ne sauves que en .blend, le format natif de blender. Tu ne vas pas sauver dans le format natif d'un autre logiciel, et encore moins dans un format vidéo. Ce sont des exports ou des rendus dans ce cas.
Genre y avait régulièrement des gens qui venaient et modifiaient l'image de leur appareil photo, directement sur la carte SD, puis sauvait par dessus. Genre ils incrustaient un texte, ou pire redimensionnait. Et plus tard, ils venaient pleurer qu'ils ont rouvert le fichier, et le texte peut plus être modifié, ou bien la qualité est amoindrie.
Donc l'un des buts est de bien faire prendre conscience à l'utilisateur que s'il veut vraiment sauver son image, c'est avec ctrl-s que ça se passe, et c'est en XCF, pas en jpeg compressé avec perte et layers mergés.
Et pis franchement est-ce vraiment plus dur de faire ctrl-e plutôt que ctrl-s?
Le seul cas embêtant dans l'affaire est pour les utilisateurs qui vont traiter énormément d'images (genre des centaines) d'affilée et veulent pas sauver par choix, en étant bien conscient de ce que cela implique.
Déjà, pour beaucoup de ceux là, on leur fait souvent remarquer qu'ils se trompent peut-être d'outils. Quand tu veux lancer un filtre ou une série de modifs sur tout un batch de fichier, tu prends un outil fait pour du batch, comme ImageMagick, ou G'Mic. Et dans tous les cas, GIMP est un outil complexe, vraiment bien plus adapté avec des gros travaux de détail. Genre un photographe (qui se respecte) qui va retoucher ses images, gardera l'original intact dans tous les cas, et sauvera son travail en XCF pour pouvoir y revenir ensuite. Un dessinateur de même. Il va certainement pas perdre son travail, parce qu'on sait jamais s'il voudra pas corriger quelques détails (et même avec des formats sans perte comme png, une fois que les layers sont mergés, tu perds beaucoup en flexibilité).
Il y a d'autres outils bien plus adaptés si on veut juste faire un truc simple en mode "je fais, j'oublie".
Enfin l'un des arguments principaux des détracteurs, c'est "attendez, c'est exactement le même dialogue, mais qui fait 2 choses différentes, donc c'est ridicule et déroutant". C'est vrai. Mais c'est pas fait pour durer. C'est uniquement vrai parce qu'avant, ben c'était réellement le même dialogue, et maintenant on les a séparés, mais ils ont la même base historique. Mais le but est justement d'aller plus loin. En particulier, j'envisionne des apports majeurs du dialogue d'export, avec possibilité de faire un redimensionnement avant l'export (mais sans toucher l'original, toujours dans l'optique du travail sans perte), voire des traitements particuliers avec filtres ou autre, et aperçu du rendu en direct avant export (mais toujours sans toucher la version de travail). En gros, un "export for web" ou similaire. Il pourrait aussi y avoir peut-être des options pour exporter des calques séparément, etc. En gros la différenciation est prévu et ça devrait donner des possibilités très intéressantes. Et ça c'est grâce à cette séparation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je regarde pas mal le blog de David Revoy et j'ai l'impression que son utilisation des logiciels libres est plutôt krita pour le dessin et gimp pour la retouche.
Oui, en fait David Revoy a fait (de mémoire) Photoshop ~> GIMP ~> MyPaint ~> Krita. Je me souviens plus exactement de ses problèmes avec GIMP (je lui avais demandé lors du Workshop), mais si je me souviens bien, y avait déjà les brosses (elles étaient soient plus puissantes dans Krita/MyPaint, soit l'interface était mieux à utiliser, je sais plus exactement le reproche); je me rappelle aussi qu'il avait un problème avec la finesse de la bordure de sélection dans GIMP (mais je crois que ce point a été amélioré depuis). Y avait 2/3 trucs comme cela. Bon je dis peut-être des bêtises, mais en gros de mémoire, c'est son parcours logiciel.
Ensuite oui, MyPaint et Krita sont beaucoup plus spécialisés "dessin/peinture" numérique, si je pige bien la philosophie, alors que GIMP se veut générique (comme Photoshop, de ce point de vue là). Certains disent que GIMP est fait pour la retouche d'image, et non le dessin. Selon moi, c'est pas vrai. GIMP s'en sort très bien pour dessiner. Simplement c'est plus générique, ça fait beaucoup plus de choses variées que Krita ou MyPaint, mais sur le point particulier du dessin, il y a en effet fort à parier que Krita/MyPaint soient meilleurs, puisque focalisés sur le sujet. C'est un choix. On peut aimer ou non. C'est le Logiciel Libre, y en a pour tous les goûts.
Par contre, dans l'autre sens, ça veut aussi dire que Krita et MyPaint sont vraiment pas adaptés pour la retouche comparé à GIMP, donc si tu dis que David Revoy continue à utiliser GIMP pour ce cas de figure, cela ne m'étonne pas. Il n'a probablement pas trop le choix, en fait.
C'est d'autant plus vrai que l'équipe de krita est très à l'écoute des retours de david revoy alors que l'équipe de gimp a l'air plus isolé.
On est aussi à l'écoute des utilisateurs. Simplement être à l'écoute ne signifie pas qu'on est à leurs ordres. Il faut voir que l'équipe de GIMP est extrêmement limitée et composée essentiellement de bénévoles, alors que Krita non.
Le mainteneur de Krita s'est lancé dans une entreprise de fondation Krita depuis l'an dernier. Ça veut dire qu'il est lancé dans une optique beaucoup plus marketing, parce que bien que sous le label de "fondation", ils font beaucoup de communication, presse et compagnie depuis lors, ils vendent des produits, du support commercial à travers une autre société, etc. C'est très bien s'il arrive à en vivre, ce qui est son but, je pense.
Et donc une des conséquences, c'est qu'ils écoutent beaucoup plus (et s'associent avec) des stars locales, parce que c'est excellent pour l'image, et clairement David Revoy en est une, depuis sa participation dans les projets Blender.
GIMP? Ben les quelques développeurs font ça dans leur temps libre et clairement ils se fichent de savoir si la personne qui demande une fonctionnalité est une star ou non pour décider si c'est une priorité ou pas. C'est probablement une erreur marketing, mais oui, je crois qu'ils sont en effet très mauvais en marketing.
C'est mon interprétation de la situation. Elle peut être fausse, mais c'est le ressentiment que j'ai eu de l'intérieur. Aussi note que personnellement je suis pour qu'il y ait divers logiciels, avec des forces et des faiblesses, et j'en ai clairement rien à faire des comparaisons malintentionnées et tentatives de donner une mauvaise image à la concurrence. C'est la seule chose qui m'a un peu déçu lors des LGM, avec une attitude un peu agressive par moment de Krita envers GIMP. Moi perso, je trouve ces 3 logiciels très bien. D'ailleurs rien ne dit que je ne mettrai pas à faire des patchs pour Krita ou MyPaint un de ces 4, si on se met à les utiliser. Je suis certainement pas braqué.
Comme tu peux le voir, y a en fait 1 unique gros (énorme) contributeur, Mitch, le mainteneur avec presque 700 commits par ans. Pour comparaison, avec seulement 60 commits en 1 an (plus de 10 fois moins!), je suis devenu le second plus gros contributeur. Krita de son côté a le mainteneur et ses 500 commits, puis 6 autres qui font au moins une centaine, etc. C'est pas du tout le même volume.
Bon c'est en vrai légèrement faussé car énormément du travail de GIMP a été déplacé dans GEGL et babl, donc en vrai pour avoir une vraie idée de l'équipe de GIMP, il faut additionner les contributions des 3 repos (et quand on fait ça, je ne suis plus le second contributeur). Mais ça reste tout de même plus petit que Krita.
J'ai l'impression que GIMP manque de dynamisme, les core développeurs s'en vont les uns après les autres, qu'il manque un dictateur bénévole comme Ton Rossendaal pour Blender. Je trouve ça étonnant vu qu'il y a encore quelques années, il était toujours cité comme un logiciel libre réussi, comparé à photoshop …
Ben honnêtement j'espère qu'il est toujours considéré comme tel! On a vraiment du beau et du lourd en préparation pour la prochaine majeure (GIMP 2.10): images 16 et 32-bit (entier et flottants), OpenCL pour plus de multi-thread et utilisation du GPU, des nouveaux outils sympas, genre le warp tool utilisé dans la vidéo, des factorisations d'outil (genre transformation unifié, et un projet GSOC en cours pour unifier la sélection aussi), pour un workflow plus agréable et moins encombré, etc. etc. Les GSOC en cours sont aussi plutôt sympas (l'un pour un nouveau outil de n-point déformation dont la vidéo de démo était impressionnante, support plus solide du PSD pour échanger avec les Adobiens, etc.).
Sans compter tout ce qui est en pleine gestation, comme le port complet vers GEGL, qui ouvrira la porte à du traitement d'image sans perte, ce qui est un énorme truc, avec vraiment beaucoup de répercussions.
GIMP 3.0 (version majeure suivante) ensuite sera focalisé sur le port vers GTK+ 3.0 (déjà commencé dans une branche à part), qui est beaucoup moins excitant car c'est un peu comme développer pour en revenir au même point. Mais c'est aussi un pas — frustrant certes — mais important, car GTK+2 n'évolue plus. Ça veut dire qu'on peut toujours y corriger des bugs, mais pas apporter de nouvelles fonctionnalités au niveau de l'UI. Un point majeur est le support du hotplug de périphérique dans GTK+3. Genre à l'heure actuelle, si tu oublies de brancher ta tablette graphique avant de lancer GIMP, elle est pas reconnue (t'es bon pour redémarrer GIMP. Et encore au moins maintenant on crashe plus. Pendant des années, GIMP crashait si tu débranchais ta tablette avant de quitter GIMP. Mais j'ai contourné ça dans GTK+2 y a quelques mois). Comme tu le vois, c'est assez décisif pour un logiciel de dessin.
En tous cas, je dirais pas que GIMP est mort. On reste quand même très en avance dans plusieurs points, et on a des vraiment beaux projets. On manque juste de mains pour aller plus vite.
Donc oui, il y a clairement un manque de développeurs. On a clairement un mainteneur fort (Mitch, avec son nombre de commits énorme), mais il ne cherche pas à être plus leader que cela, ce qui peut être apprécié ou non. Il nous manque en effet peut-être un "leader", un mec qui aime l'administration, qui veut faire du marketing. C'est vrai que pour l'instant on a plus des hackers par ici. Moi rien que ces deux jours à peine où j'ai commencé un financement, je suis épuisé, tout en ayant la sensation de rien faire de vraiment "réel". J'ai pas touché une ligne de code depuis ces deux jours, je fais que répondre à des messages. Franchement je ferais pas ça tous les jours!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
oui on m'a aussi dit hier que Krita a bien amélioré le miroir. A priori même y a quelques mois, lors du LGM, on pouvait déjà bouger les axes, mais il paraît que c'était bien caché dans l'UI. Mon but n'est nullement de critiquer Krita. Ça a l'air aussi super ce qu'ils font. Comme je disais, ce fut d'ailleurs la source d'inspiration de mon hack. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Comparatif
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 4.
Je connaissais pas MXE. Mais je viens de jeter un œil.
Déjà MXE maintient sa propre liste de paquetage de dépendances. D'une, ça doit être un travail de dingue de les garder à jour et vérifier que chacun compile proprement à chaque nouvelle version; de deux, je suis persuadé qu'il n'est pas à jour sur plein de paquetages à cause du premier point (sauf si l'équipe est vraiment grosse?); de trois, même si l'installation des dépendances reste simplifiée certes par rapport à tout faire à la main, il n'empêche que tu te tapes des dizaines de compilations pour un gros projet.
Quand je compile GIMP par exemple, j'ai pas compté, mais avec les dépendances de dépendances, je pense qu'y a bien une vingtaine au moins de paquets installés. Ben ça se fait en genre une minute. C'est du pré-compilé. Donc c'est rapide, et surtout ça marche tout le temps. Le seul cas où une installation de dépendance foire avec crossroad, c'est si les serveurs Fedora sont down. :-)
MXE, ils compilent tout sur l'ordi de build. Donc c'est lent, et ça peut foirer (car on sait tous que les compilations, c'est pas parce que ça marche bien chez le dév que ça marche chez vous (même si c'est normalement le but recherché). Y a beaucoup plus de paramètres en compte.
Et surtout je ne me charge pas de cette liste de dépendances! Donc j'en ai genre probablement bien plus que MXE sans rien avoir à faire. Crossroad va simplement télécharger la liste des paquets Fedora dès que tu l'invoques et est donc toujours à jour par rapport à la dite liste.
Voici donc la liste complète des dépendances de Crossroad: http://download.opensuse.org/repositories/windows:/mingw:/win64/openSUSE_12.3/noarch/
MXE a ça apparemment: https://github.com/mxe/mxe/tree/master/src
C'est pas mal aussi, et j'ai pas compté précisément pour voir qui a la plus grosse. Mais je préfère de loin ne pas avoir à me préoccuper de cela.
Pareil j'ai l'impression que MXE va jusqu'à lui-même compiler MinGW ou MinGW-w64. Franchement toutes les grosses distrib ont MinGW/MinGW-w64 d'installable pour ton OS. Et si vraiment tu veux une version plus récente, y a des builds nocturnes officiels aussi (en tous cas pour MinGW-w64). Vraiment pourquoi s'embêter à compiler ça?
Tout comme les dépendances, je préfère de loin déléguer.
Pour le reste, si tu regardes le tuto de MXE, ça aide pas beaucoup plus que cela. J'ai l'impression que son point principal, c'est de proposer des Makefile pour diverses dépendances.
Mais ils te demandent toujours de modifier tes variables d'environnement et de taper les configure et cmake à rallonge. C'était justement la partie chiante que je suis content d'avoir automatisé. Après tout, c'est toujours les mêmes options. Pourquoi me faire chier à les taper ou copier-coller à chaque fois plutôt que les automatiser dans un script?
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 noob
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 2.
Mon outil configure le projet pour s'installer dans un préfixe donné, ainsi que toutes les dépendances pré-compilées (car on veut pas mélanger des binaires Win avec son OS). Dans la pratique, ça rajoute simplement un --prefix automatique à ton ./configure pour qu'on ait pas à y penser à chaque fois.
Ce
crossroad --symlinkest juste un petit raccourci de mon outil pour créer un lien (nommégimp) qui lie l'environnementw64. J'utilise ça pour ma VM Virtualbox qui communique avec mon OS notamment par un dossier partagé. C'est plus simple que d'échanger un zip avec ma VM (ce serait un peu ridicule).Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Par rapport à une compilation via Wine
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 3.
Salut,
J'ai jamais tenté de compiler sous nux avec Wine et MinGW. Mais sous Windows avec MinGW, c'est aussi d'une lenteur effroyable. Je sais pas ce que le compilo fait, mais il le fait pas vite. :-D
Je pense oui. Avec la cross-compilation native (pas Wine ou autre environnement bâtard entre deux-OS pour l'exécution. C'est "natif" dans le sens où ça utilise un compilo fait pour tourner sous nux, seulement il compile à destination d'un autre OS), ça va super vite chez moi (tout aussi vite que la compilation nux pour nux).
Oui. Il suffit de le configurer, compiler et l'installer avant ton projet, pareil que le projet normal. Il sera installé dans le même préfixe que le reste (les libs installées par Fedora en particulier), et donc quand tu configureras ton projet, il trouvera ces dépendances compilées également.
GIMP master par exemple nécessite babl et GEGL master aussi, qui ne sont pas présents dans Fedora aussi, ainsi qu'une version de cairo supérieure à ce que Fedora propose. J'installe donc ces 3 dépendances supplémentaires avant d'installer GIMP. Ça marche nickel.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Licence Windows 7
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche À la Croisée des Chemins: crossroad, environnement de cross-compilation. Évalué à 3.
Salut,
J'ai essayé de retrouver vite fait la licence Win 7 sur le site Microsoft après ton message, mais je tombe que sur Windows 8 partout. Je vais dormir là, mais je chercherai demain à nouveau, sauf si quelqu'un trouve avant et poste le lien ici. :-)
En tous cas, j'avais lu la licence de mon OS exact à l'époque, spécifiquement pour savoir cela, et ce point précis était très clairement marqué dedans (vraiment non-ambigu d'après moi, ou alors de manière très fourbe). Je me souviens qu'il y avait un point précis dans le contrat qui dit qu'on peut l'utiliser dans une VM.
En plus comme j'avais pas de CD Windows (comment souvent maintenant dans les portables, qui te vendent avec une sorte de partition cachée qui permet de réinstaller l'OS), j'ai même demandé au vendeur du portable de me le filer, en disant au support que c'était pour l'utiliser en VM, plutôt qu'en OS principal, car autorisé par le contrat. Et ils m'ont filé un iso officiel sans même poser plus de questions.
Donc oui j'en suis sûr, autant que faire se peut quand on n'est pas juriste. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Le gros moins de GIMP
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GIMP ça déchire. Évalué à 6.
Salut,
Si t'as des mockups, et des idées plus ou moins ("plus", c'est mieux) clairement spécifiés, etc. tu peux participer au GUI brainstorm: http://gimp-brainstorm.blogspot.co.nz/
C'est un peu mort, parce que notre expert UI s'était éloigné de nous, mais il vient de revenir y a juste une semaine. Donc nos retours UI vont s'améliorer.
Je suis pas certain de comprendre ta comparaison avec une table lumineuse. Veux-tu simplement dire une timeline où on peut spécifier plusieurs calques par frame (et pas comme actuellement, 1 calque = 1 frame)? Si c'est le cas, sois en joie, car c'est en travaux. Je suis depuis quelques mois le mainteneur officiel du plugin core animation-play qui est fourni avec GIMP. Et je suis justement en train de travailler sur ce dont tu parles. Si tu voyais ma version de dév actuelle, tu verrais que ça n'a déjà plus grand chose à voir avec la 2.8. :-)
Oui il paraît que GIMP n'a pas les meilleures brosses. Si je pige bien, MyPaint serait vraiment sympa pour créer des brosses (cad que l'UI serait plus aisée à manipuler). Par contre je crois qu'elles sont plus limitées (les brosses sont toutes formées de cercles comme forme de base, ou un truc du genre). Krita aurait les meilleures brosses à ce qu'on dit. Dans tous les cas, on dit que MyPaint et Krita sont tous deux spécifiquement dédiés aux peintres (c'est comme cela que ces deux projets se présentent). GIMP se veut plus générique. Il fait de tout: du croquis au traitement photo en passant par la peinture. Depuis les derniers Libre Graphics Meeting, les 3 projets GIMP, Krita et MyPaint essaient en fait de collaborer pour partager leurs pinceaux (ou du moins pour que chacun soit capable d'utiliser les pinceaux des 2 autres). Bon je suis pas sûr que le projet avance énormément, mais les bases de la discussion sont posées.
Ensuite pas mal de gens dessinent quand même des trucs très cools avec GIMP et la dessinatrice avec qui je travaille semble apprécier créer des brosses et des dynamiques dans GIMP. Un peu d'auto pub: mon webcomic sur la vie d'une Marmotte aventureuse. Y a pas beaucoup de mises à jour parce qu'on revoit pas mal de trucs en cours de route, mais ça devrait prendre le rythme au bout d'un moment. :-)
Oui j'entends pas mal parler des supers progs de dessin de l'amiga. Moi à l'époque, mon grand frère a eu un amiga pendant environ 2 ans et on faisait que jouer dessus avant qu'on grille l'alim (oui l'alim, c'est rien, mais nous on y pigeait que dalle et mes parents sont danseurs, ils y pigent encore moins), puis on a pas eu d'ordi pendant pas mal d'années. Je suis loin d'avoir eu une jeunesse de geek, je me demande comment j'ai tourné ainsi! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Le gros moins de GIMP
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GIMP ça déchire. Évalué à 9.
Réponse aux 2 messages précédents:
C'est ce que j'appelle plus haut l'édition non-destructrice avec les calques d'effets. C'est prévu. C'est peut-être même une des conséquences majeures qu'apportera GEGL. Par contre les chances d'avoir ça pour GIMP 2.10 sont très faibles, car bien que le port GEGL sera alors complet, il n'y aura pas l'UI pour en tirer profit. À moins qu'on ait plus de dév d'ici là, par exemple.
Clairement c'est un des autres gros points manquants. C'est aussi une fonctionnalité qui je pense demandera beaucoup de réflexion et de temps pour la faire bien (on peut la développer à-peu-près relativement rapidement, mais on aime le beau code).
En effet à l'heure actuelle, même s'il y a un mode console pour GIMP (on peut même compiler que le mode console de GIMP, sans UI donc sans dépendance à X si on veut. Pour un serveur par ex), c'est pas l'extase. Je pense même qu'aucun des dévs ne considère cela comme une fonctionnalité majeure de GIMP. ImageMagick est clairement beaucoup plus efficace car fait pour.
Quand des utilisateurs nous parlent de cas d'usage qui est clairement un travail à la chaîne (donc du batch) et se plaint que GIMP est pas efficace pour cela, on leur dit à chaque fois d'aller essayer ImageMagick, clairement adapté à l'usage.
Peut-être qu'un jour, quand on aura plus de dévs, en particulier des dévs qui s'intéressent à ce mode et ces usages, et leur donne un peu d'amour, GIMP y sera bon aussi. Mais pour l'instant, je pense qu'il faut accepter ce fait, ou alors retrousser ses manches et nous aider. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: la déformation à N points
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GIMP ça déchire. Évalué à 8.
Petit addendum à moi-même:
Aussi faut bien voir que travailler directement en CMYK, c'est pas "vraiment" possible. Même si tu stockes en CMYK dans le fichier ou en format interne dans le programme, ton écran lui est toujours RGB. Donc y a forcément des tables de correspondance ou autre truc du genre et par définition, ça ne peut pas être parfait car c'est tout simplement 2 systèmes totalement différents. J'ai pas encore regardé les détails d'implémentation de ce genre de chose donc je veux pas dire trop de bêtise non plus, mais bon faut être bien conscient que c'est pas parce que le fichier est stocké en CMYK que soudainement, ce que tu as à l'écran, c'est comme ton papier. Non l'écran est et reste du RGB. Papier et écran/projecteur, c'est structurellement différent.
Oh et j'oubliais aussi dans mon énumération précédemment des choses à faire si tu veux faire les choses bien! Quand tu calibres ton imprimante, tu dois en fait calibrer (et donc générer un profil) par couple (imprimante, papier). Tu ne calibres pas pour l'imprimante seulement, ça n'a pas de sens, car chaque type de papier (couleur, texture, etc.) est différent. Donc avec la même imprimante, tes couleurs sortiront différemment selon que tu imprimes sur ton papier blanc, fin et mat ou ton autre papier qui tend vers le rose, plus épais et brillant. La gestion des couleurs est vraiment un enfer. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: la déformation à N points
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GIMP ça déchire. Évalué à 10.
Ça l'est! :-)
Oui et c'est déjà là! Lance ton GIMP master compilé, et regarde le menu Image > Precision.
Y a du 16 et 32-bit, entier, flottant, linéaire, gamma, pour tous les goûts!
C'est pas encore porté sur tous les outils, donc c'est du travail en cours, mais le principal est là.
Ça sert pour ceux qui impriment. Un pro de l'image qui sort pas de l'écran n'en a rien à faire. Mais oui c'est une des fonctionnalités les plus demandées, car beaucoup soit impriment (designers d'affiche, etc.), soit ne comprennent pas à quoi ça sert et comment, mais on leur a dit que le CMYK, c'est pour les pros. :-)
Aussi en vrai avoir un tel support dans ton software de graphisme n'est pas suffisant. La question des couleurs est extrêmement compliquée (pas que sur le sujet CMYK, mais les couleurs en général), et je balbutie moi-même et commence à peine à comprendre certaines choses (mais encore bien trop peu! Donc je dis sûrement beaucoup d'âneries sur le sujet). Et la plupart des gens, c'est pareil. Ils croient qu'il suffit d'avoir un programme avec un bouton "CMYK", ils cliquent dessus, et c'est bon, ils sont des pros ("la preuve! Je clique sur le bouton CMYK!"). En vrai c'est genre 1000 fois plus compliqué. Y a les questions des profils de couleur, pour faire bien tu dois calibrer tes écrans, tes scanners, tes imprimantes (ce qui génère les dits profils). Et pour le faire, y a des outils au tarif décent (comme le colorhug, c'est openhardware, et "seulement" 75 EUR. Je l'ai acheté d'ailleurs!), mais c'est limité. Si tu veux faire vraiment les choses professionnellement, tu dois avoir des outils de calibrations à des tarifs bien plus haut (plusieurs centaines d'euros), un photospectromètre, etc. Et ça sert pas à grand chose (ou moins en tous cas) si t'as un écran pourri, si t'as un ordi portable (sauf si tu le bouges jamais et change jamais l'angle de l'écran), si t'as des fenêtres (ou alors ferme les volets!), si tes murs sont peints en autre chose qu'en gris, etc.
Sans déconner, j'ai entendu dire que les grands studios de cinéma pro ont ce genre de pièce pour aller visionner leurs films correctement.
Je suis persuadé que 90% des gens qui travaillent en CMYK font pas les choses comme il faut (même sans aller dans les extrêmes comme aller travailler dans ta cave peinte en gris!).
Quand Photoshop te dit "on a du support CMYK", c'est surtout très marketing. Voire certains disent que c'est un peu une forme de mensonge. À vrai dire, il semblerait que Adobe même est en train de réfléchir à faire marche arrière sur pas mal de choses au sujet de la gestion de couleurs, alors même qu'ils ont contribué à créer et populariser tout ça. Par exemple, y a eu cet email d'un représentant Adobe dans le CSS working group où il est en train de dire en gros que la gestion des couleurs, c'était peut-être une erreur de leur part depuis le début car bien trop compliqué, et d'autres ont bondi à cette déclaration. Bon je t'avoue que je pige pas tout dans la discussion, mais c'est peut-être justement parce que je pige pas beaucoup dans la gestion des couleurs (en ce sens, cet employé Adobe a raison quand il dit que c'est compliqué!).
Sinon est-ce que GEGL/BABL aideront pour ajouter le support dans GIMP? Je pense en effet que ça pourra aider car on a plus d'abstraction pour travailler sur les formats avec BABL. Malheureusement je crois que personne ne travaille sur le support de CMYK pour le moment (si je ne m'abuse). Je pense que les dévs de GIMP actuel n'ont pas le besoin et ont d'autres priorités (moi de même). Il nous faudrait un dév qui ait ce besoin (ou bien qu'on ait terminé nos autres priorités!).
Dans le Logiciel Libre, même si on travaille ensemble au final, chacun a un peu son propre plan à long terme. :-)
Mais l'une des fonctionnalités majeures que cela va apporter, c'est surtout l'édition non destructrice. Par exemple les effets pourront être appliqués avec des calques d'effet, dont on peut modifier les paramètres, ou supprimer pour retrouver l'image originelle, etc. GEGL est un système de traitement d'images en graphe, où les effets et autres traitements sont des nœuds avec entrée et sortie. Un peu comme le compositing dans Blender avec des nœuds (sauf que nous n'aurons probablement pas une UI en graphe comme Blender. Je pense que ce serait génial perso, mais a priori le designer qui bosse avec nous pense différemment. Mais c'est pas encore sérieusement discuté, donc y a la marge et le temps).
Bon tout ça (édition non destructrice) ne sera certainement pas dans GIMP 2.10. Ce serait GIMP 3.0, voire même après. On aura les fondations dans 2.10, mais pas l'UI. Mais c'est le chemin pour y arriver.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: la déformation à N points
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GIMP ça déchire. Évalué à 2.
Salut,
Il n'est pas encore porté sur GEGL, notre nouveau moteur. Une personne avait commencé le travail, mais n'a jamais terminé et on a un travail à moitié fait.
Je sais pas pour celui-là, mais c'est peut-être la même chose. En tous cas, le code est toujours là. Quoiqu'il en soit, l'équipe n'a pas pour pratique de retirer des fonctionnalités utilisées. Mais je suis en train de demander sur le canal IRC, au cas où.
Oui, comme tu dis, c'est une version de dév. On déconseille fortement de l'utiliser en prod (quasi impossible dans l'état actuel). Et encore, y a quelques mois, c'était 10 fois plus lent. Tu faisais un simple coup de pinceau et tu voyais ton trait apparaître à la vitesse de l'escargot asthmatique. :-D
Comme dit plus haut, on porte entièrement le moteur de GIMP vers GEGL. C'est un travail de fond, peu visible certes dans l'UI, et comme GEGL est encore très jeune, la stabilité a priorité sur les optimisations, qui vont venir avec le temps.
J'ai vaguement testé y a quelques semaines. Donc j'en sais pas beaucoup plus que toi. En testant sur une image avec fond transparent, la sélection avait bien marché, si je me souviens. Je crois pas avoir testé avec fond non transparent, par contre. En tous les cas, oui, c'est pas intégrable en l'état.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ça donne envie
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GIMP ça déchire. Évalué à 2.
Salut,
J'aime les logiciels console, et j'utilise ffmpeg à l'occasion pour réencoder des vidéos, par exemple. Mais c'est vrai que des fois, je veux pas me faire chier et j'aime bien cliquer sur un bouton, surtout pour des trucs aussi chiants qu'enregistrer des écrans.
Ceci dit, les GUIs sont pratiques sur d'autres aspects aussi. Par exemple pour pouvoir ajouter un décompte. Tu vas me dire qu'on peut juste couper les premières secondes de vidéo, mais des fois, tu fais une vidéo, et basta. T'as pas envie de retoucher, quand c'est pas pour l'art.
Et ffmpeg permet-il aisément de n'enregistrer qu'une fenêtre sélectionnée (comme dans ma vidéo) ou qu'une zone de l'écran sélectionnée à la souris? Ou faut-il faire un crop dans un NLE après? Ça aussi par exemple, ce sont des détails, mais c'est toujours ça de gagné quand on veut pas se faire chier. Si je fais une vidéo pour montrer un unique programme, j'ai pas vraiment envie de montrer ma barre des tâches, ou bien les évènements du desktop quand on m'envoie un message par IM, etc. Et les GUIs permettent de sélectionner ainsi juste ce qu'on veut montrer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Des beaux plug-ins
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GIMP ça déchire. Évalué à 4.
Y a tout de même un framework de plugin. Ce qui n'est pas là, c'est un système de gestion des plugins.
Mais oui ça peut être mieux, c'est sûr. :-)
C'est vrai. L'équipe est bien trop petite. Encore une fois, on y peut rien malheureusement.
J'essaie un peu d'accélérer les choses, à mon niveau, mais ça reste très limité bien entendu. Par exemple ces derniers jours, j'essaie de pousser une sortie de correctifs (donc 2.8.8). Y a pas de nouvelles fonctionnalités bien sûr, mais je pense que même les versions mineures, GIMP met trop de temps à les sortir, et j'aimerais accélérer le rythme.
Les versions majeures, j'aimerais aussi qu'on les accélère, mais je pressens que cela ne pourra être fait avant au moins la 3.0, et encore il faudra arriver à convaincre les autres. Car la 2.10 (GEGL) et la 3.0 (GTK+ 3) sont des chantiers trop gros et ne peuvent être fait "partiellement".
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Des beaux plug-ins
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GIMP ça déchire. Évalué à 4.
Je prévois probablement de travailler sur un système de gestion de plugin. Si le projet va au bout (pas commencé le moindre code, mais j'ai déjà commencé à gribouiller des idées et à regarder à droite à gauche ce que font les autres, comme Mozilla, etc.), on devrait pouvoir installer/désinstaller facilement avec une liste à jour, et surtout les mises-à-jour devraient être automatiques aussi. Comme dans Firefox quoi.
Sauf que ce sera fait de manière générique pour tous les plugins, y aura plus besoin de bidouiller dans ton coin (ce qui est super, mais comme le fait remarquer Julien Jorge, pas très intégré malheureusement).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Ça donne envie
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GIMP ça déchire. Évalué à 1.
J'en ai essayé pas mal parce qu'y en a beaucoup qui sont dans les dépôts de distribution mais qui ne marchent tout simplement pas.
Si je me plante pas, pour cette vidéo, j'ai utilisé Kazam sur une partie et FDesktopRecorder sur une autre:
http://youtu.be/osSiETyae5c
Donc je les recommande. Ils marchent bien.
Par contre RecordMyDesktop, je n'ai jamais réussi à rien en tirer. Déjà la vidéo est en général tout simplement dégueulasse, avec plein d'artefacts. Inutilisable en un mot. Et aussi il crashe tout le temps (j'ai encore la mauvaise expérience d'un atelier dans mon emploi précédent que j'enregistrai, et à la fin de l'atelier, je me suis rendu compte que RecordMyDesktop avait crashé au milieu!).
Par contre la guerre libav/ffmpeg est vraiment un désastre. J'aimerais vraiment qu'ils se décident à clairement renommer l'un des deux parce que ces derniers temps, j'ai croisé et patché des bugs dans plein de logiciels à cause d'incompatibilités.
Le problème est qu'ils ont le même nom, réutilisent même les noms d'outil de l'autre projet (en les disant dépréciés, mais en s'emparant du spot quand même), mais que les uns les autres intègrent de subtiles différences et incompatibilités un peu partout dans l'API.
Maintenant dès qu'un logiciel utilise libav, je me mords les doigts pendant la compilation parce que les chances d'erreur pendant compilation ou link sont démultipliés selon ce que les dévs utilisent eux-même.
Je parle de ça parce que j'ai eu plusieurs problèmes notamment en compilant des logiciels de screencast (par exemple pour compiler FDesktopRecorder sur ma Linux Mint).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: la déformation à N points
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal GIMP ça déchire. Évalué à 4.
Salut,
faut que quelqu'un trouve de temps de faire la revue de code, nettoyer, corriger ce qu'il y a à corriger, puis merger. Si personne ne le fait avant moi, c'est dans ma TODO list parce que cet outil m'intéresse aussi pas mal.
Le GSOC, c'est cool, mais cela reste des étudiants. Certains font un bon travail, mais il reste un énorme travail après coup pour finir. Pour tout dire, on a des gsoc de 2011 pas encore intégrés dans la branche principale.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Tout est libre, vraiment?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Gobelins cherchent geeks pour koala masqué. Évalué à 1.
Bonjour,
C'est moi!
En effet, les calques en dehors des limites desquels on ne peut pas dessiner ennuient beaucoup la graphiste avec laquelle je travaille. Cela pourrait être un des très prochains projets sur lequel je travaillerai si ce crowdfunding marche bien. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Dynamisme de GIMP
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 2.
Si c'est pour de la photo, t'as essayé les logiciels dits de développement numérique? Genre en libre y a darktable, ou encore RawTherapee qui ont vraiment l'air sympa. Je ne les ai pas utilisés tant que ça parce que je ne fais pas beaucoup de photo, mais je les ai un peu manipulés, et c'est une interface bien plus sympa pour manipuler des dizaines, voire centaines de photos à la fois.
C'est un concept différent. Ça ne fait pas tout ce que GIMP fait, et pour certains trucs, notamment du travail dans le détail, tu auras toujours besoin de GIMP. Mais pour du traitement de masse, des effets, etc. ça a l'air d'être beaucoup plus adapté.
Bien sûr, c'est vraiment plus pour ceux qui travaillent en raw, mais ça marche tout aussi bien si tes photos sont en jpeg ou autre format.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Dessin symétrique
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 4.
Non. T'as raison en fait. Si on veut faire générique, autant faire en sorte que plein de trucs soient possible, même pour des cas d'usages auxquels on pense pas au début.
La seule chose compliquée est toujours de réfléchir à une archi qui permette tout de même de bien présenter l'outil de base (à savoir ici des axes ou centres de symétrie) de manière agréable, mais pour permettre d'aller plus loin pour les "hardcore gimpers". Faut pas que l'UI ait trop plein d'options inutile à 99% des gens, ni que ce soit rébarbatif de mettre un mode miroir. Le gars qui veut juste un miroir vertical, prêt à être déplacé à la souris et dessiner direct, il doit pouvoir le faire en un/deux clic ou un raccourci.
Et passer par l'API (pas forcément besoin d'être développeur pour ça: il en suffit d'un pour uploader sur http://registry.gimp.org/) est la meilleure solution pour étendre des fonctionnalités sans rendre l'UI imbitable.
Et à vrai dire, j'avais aussi pensé que ça pouvais être intéressant qu'un point soit transformé en plusieurs autres points.
J'y réfléchirai. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Dessin symétrique
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 1.
Ok. L'idée que ça m'a donnée reste néanmoins intéressante. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Dynamisme de GIMP
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 2.
Voilà, tout est dit. :-)
Aussi, je vois pas le problème à utiliser deux outils différents pour deux usages différents (un pour l'édition avancé, un autre pour l'édition simple).
Par exemple, la plupart du temps, quand je veux juste tirer du texte simplement d'un fichier, je préfère utiliser grep, éventuellement avec une regexp, ça reste le plus simple d'utilisation. Quand je veux en plus remettre en forme le retour, j'utilise sed. Et il peut m'arriver assez rarement d'utiliser awk pour certains types d'extraction. Et je suis super content qu'on ait plusieurs outils d'extraction de texte, dont un très basique comme grep, parce que j'aimerais pas me manger des syntaxes compliquées juste pour chercher du texte (j'utilise grep des dizaines de fois par jours).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Dessin symétrique
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 4.
Oui, toute transformation devrait être simple à ajouter, du moment que tu me donnes une formule avec en entrée les coordonnées du pinceau, et en sortie les coordonnées de la transformation. :-)
A vrai dire, en y réfléchissant bien, on doit même pouvoir faire en sorte de rajouter très facilement des types de transformations (pour ne pas encombrer le système de base de trucs très particuliers, mais tout en laissant ceux avec un besoin particulier en créer facilement et se les échanger sous formes de scripts). Genre on rajoute une méthode dans l'API de libgimp, qui prend en paramètre un handler qui a la forme adéquate (fun: int*int -> int*int en gros), et ça ajoute un type de transfo possible. Donc les gens peuvent ajouter un type de transfo avec un plugin GIMP (C, Python, perl, etc.) en quelques lignes et une formule. Intéressante idée.
Mais t'as un besoin précis pour ce genre de dessins, ou bien tu me dis juste ça parce que ton cerveau bouillonne de transfo mathématiques et que tu te dis que c'est cool, mais en vrai t'utiliserais pas?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Destructif ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 7.
Salut,
eh beh, tu aurais encore moins aimé être un artiste avant l'avènement de l'informatique alors! ;-) À l'époque, c'était des layers… de peinture les unes sur les autres. :p
Plus sérieusement: les calques-effet sont en projet. Tu as peut-être entendu parler du port vers GEGL qui est en cours, et qui sera pleinement effectif à la sortie de GIMP 2.10 (ou l'inverse: quand on finit, on sort la 2.10 :p). GEGL est une librairie de traitement d'image en arbre (avec des "nodes", qui sont en général des effets, ou du moins un traitement quelconque avec des entrées et des sorties).
Ce port est la première étape. À ce moment, on aura un cœur avec support de l'édition d'image non-destructive, sauf que ce sera toujours destructif dans la réalité, parce qu'on aura pas encore d'UI adéquate.
La seconde étape sera donc pour nous de déterminer une UI efficace, qui impliquera dans une forme ou une autre des calques à effet, pour faire exactement ce que tu dis.
Maintenant, il y a cependant des workflows variés qui impliquent du dessin avec miroir. Ce dont tu parles, j'ai en effet vu et utilisé un peu sur blender. Mais ça permet plus des miroirs parfaits. Pour une œuvre d'art, tu voudras "réparer la perfection", et y rajouter de l'imperfection. Par exemple, si tu fais un visage en dessinant en miroir seulement la moitié, après coup, tu veux arrêter le miroir, et faire les détails en mode normal. Regarde par exemple comment la dessinatrice fait le lapin dans ma vidéo. Or dans ta proposition, un miroir s'appliquerait sur un calque complet. Donc ça rendrait cette manœuvre délicate. Par exemple même sur blender, quand on applique un effet de miroir sur un objet, au bout d'un moment on va l'appliquer et se mettre à travailler dans les détails. Car on ne peut pas garder l'effet tout du long si on veut faire des détails. On perd la donnée "miroir" en effet. Mais c'est la différence entre le dessin industriel et l'art. Dans l'art, on cherche pas à sauver l'info, mais à avoir le meilleur résultat final. Or c'est souvent incompatible.
Bien sûr, tu peux faire les détails dans un autre calque. Mais franchement ce ne serait pas un workflow très cool de devoir faire les bouts de détails du lapin sur un calque séparé (ce serait comme faire un second objet 3D pour faire uniquement les détails non symétriques de ton objet symétrique). Du point de vue du dessinateur, ce serait un horrible design pour la gestion des calques.
Pour tout dire, on a discuté cet exact sujet hier sur le canal IRC, au sujet de la meilleure manière d'implémenter le miroir (parce que comme on a GEGL maintenant, c'est en fait déjà techniquement possible de faire ainsi). :-)
Mais cela reste très intéressant, pour d'autres types de workflow et de dessins par rapport au projet présentés. C'est complémentaire quoi, et ce sera possible quand on aura enfin les calques à effet. Donc à ce moment là, on aura les deux workflow possibles, pour satisfaire tout le monde.
Quand? Ben je sais pas. On manque de mains. Nous aussi on aimerait que tout ça aille plus vite. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Dynamisme de GIMP
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 5.
Uh? Où c'est que je l'ai critiqué? Je l'ai rencontré, et il avait l'air très sympa. C'est pas insultant de dire que c'est une star locale (locale dans le monde du Libre, j'entends, avec son implication dans divers logiciels Libres: GIMP, MyPaint, Krita, Blender. Et oui si je dis "local", c'est parce qu'il est pas non plus De Vinci, qu'un quidam connaîtra même s'il ne s'intéresse pas au sujet. C'est donc "localisé"). C'est même bien d'être une star locale. Et dans le cas de David Revoy, je pense vraiment que c'est justifié. Si on devait citer un artiste peintre dans le monde du Libre, c'est un des premiers noms qui vient en bouche. Je suis sûr qu'il en est conscient.
Je pense que tu peux chercher les bugs du bugtracker de GIMP où David Revoy intervient. J'en trouve deux. Je crois pas qu'il ait jamais été maltraité. En particulier celui là (l'autre bug, y a pas de réponse): https://bugzilla.gnome.org/show_bug.cgi?id=663582
On peut voir un échange tout à fait cordial entre Alexia, Mitch et David. David rapporte ses problèmes, fait des vidéos, Mitch est d'accord pour dire que ça a vraiment pas l'air terrible, essaie de corriger, pose des questions et propose des patchs à tester. Au final David est plutôt content du résultat, mais le patch reste ouvert parce qu'on est conscient qu'y a encore bien des choses à améliorer.
Donc au lieu de dire qu'on l'a très mal reçu, qu'on aime pas les stars (ce qui n'est pas du tout ce que j'ai dit), et qu'on est des vrais qui font aucun marketing parce que c'est le mal (je pense que la campagne de financement en cours est un bon exemple du contraire), il faudrait un peu se renseigner, ou lire ce que j'écris.
Je sais pas pourquoi y a des gens qui ont toujours besoin de voir des conflits et du mauvais esprit partout. Perso j'ai une dent contre personne, et sûrement pas contre David Revoy, que je connais pas vraiment, mais que je rencontrerai peut-être à nouveau. Et ce jour là, je lui serrerai la main avec plaisir.
Tout ce que je dis, c'est que Krita et GIMP ont une gestion de projet vraiment différente. Y a beaucoup moins de recherche d'image chez GIMP. Et je n'ai jamais dit que c'est bien, ou pas. En tous cas, le résultat est qu'il est clair qu'il est probablement plus avantageux pour un artiste comme David Revoy de s'associer à Krita dans la configuration actuelle.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Dynamisme de GIMP
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 10.
Je ne ferai qu'un seul message sur le sujet, car c'est un point extrêmement trollesque, et ça part facilement en vrille. Donc je dirai ce que j'en pense de manière complete.
Déjà il faut savoir qu'il y a quasiment aucune chance que ça revienne comme avant. Sauf si genre tous les développeurs actuels de GIMP meurent ou un truc comme ça. Donc pour avancer, il serait mieux pour toi de t'y faire. :-)
Deuxièmement l'idée est très simple: tu sauves ton travail. Mais tu exportes un "snapshot" de ton travail, à un moment X ou Y. Ton travail complet implique des calques, des groupes de calques, des masques et canaux, des vecteurs (chemins), du texte (pas le texte déjà incrusté dans ton image, mais bien un texte encore modifiable, contenu, font, taille, etc.), et ainsi de suite. Tout ça à la fois, y a que dans le format natif de GIMP qu'on peut le sauver.
L'export, c'est ton snapshot, pour rendu final, pour impression, envoyer sur le web, montrer à tes potes, intégrer dans ta présentation, ouvrir avec un logiciel différent, ou que sais-je encore.
C'est comme dans blender. Tu ne sauves que en .blend, le format natif de blender. Tu ne vas pas sauver dans le format natif d'un autre logiciel, et encore moins dans un format vidéo. Ce sont des exports ou des rendus dans ce cas.
Genre y avait régulièrement des gens qui venaient et modifiaient l'image de leur appareil photo, directement sur la carte SD, puis sauvait par dessus. Genre ils incrustaient un texte, ou pire redimensionnait. Et plus tard, ils venaient pleurer qu'ils ont rouvert le fichier, et le texte peut plus être modifié, ou bien la qualité est amoindrie.
Donc l'un des buts est de bien faire prendre conscience à l'utilisateur que s'il veut vraiment sauver son image, c'est avec ctrl-s que ça se passe, et c'est en XCF, pas en jpeg compressé avec perte et layers mergés.
Et pis franchement est-ce vraiment plus dur de faire ctrl-e plutôt que ctrl-s?
Le seul cas embêtant dans l'affaire est pour les utilisateurs qui vont traiter énormément d'images (genre des centaines) d'affilée et veulent pas sauver par choix, en étant bien conscient de ce que cela implique.
Déjà, pour beaucoup de ceux là, on leur fait souvent remarquer qu'ils se trompent peut-être d'outils. Quand tu veux lancer un filtre ou une série de modifs sur tout un batch de fichier, tu prends un outil fait pour du batch, comme ImageMagick, ou G'Mic. Et dans tous les cas, GIMP est un outil complexe, vraiment bien plus adapté avec des gros travaux de détail. Genre un photographe (qui se respecte) qui va retoucher ses images, gardera l'original intact dans tous les cas, et sauvera son travail en XCF pour pouvoir y revenir ensuite. Un dessinateur de même. Il va certainement pas perdre son travail, parce qu'on sait jamais s'il voudra pas corriger quelques détails (et même avec des formats sans perte comme png, une fois que les layers sont mergés, tu perds beaucoup en flexibilité).
Il y a d'autres outils bien plus adaptés si on veut juste faire un truc simple en mode "je fais, j'oublie".
Enfin l'un des arguments principaux des détracteurs, c'est "attendez, c'est exactement le même dialogue, mais qui fait 2 choses différentes, donc c'est ridicule et déroutant". C'est vrai. Mais c'est pas fait pour durer. C'est uniquement vrai parce qu'avant, ben c'était réellement le même dialogue, et maintenant on les a séparés, mais ils ont la même base historique. Mais le but est justement d'aller plus loin. En particulier, j'envisionne des apports majeurs du dialogue d'export, avec possibilité de faire un redimensionnement avant l'export (mais sans toucher l'original, toujours dans l'optique du travail sans perte), voire des traitements particuliers avec filtres ou autre, et aperçu du rendu en direct avant export (mais toujours sans toucher la version de travail). En gros, un "export for web" ou similaire. Il pourrait aussi y avoir peut-être des options pour exporter des calques séparément, etc. En gros la différenciation est prévu et ça devrait donner des possibilités très intéressantes. Et ça c'est grâce à cette séparation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Dynamisme de GIMP
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 10.
Oui, en fait David Revoy a fait (de mémoire) Photoshop ~> GIMP ~> MyPaint ~> Krita. Je me souviens plus exactement de ses problèmes avec GIMP (je lui avais demandé lors du Workshop), mais si je me souviens bien, y avait déjà les brosses (elles étaient soient plus puissantes dans Krita/MyPaint, soit l'interface était mieux à utiliser, je sais plus exactement le reproche); je me rappelle aussi qu'il avait un problème avec la finesse de la bordure de sélection dans GIMP (mais je crois que ce point a été amélioré depuis). Y avait 2/3 trucs comme cela. Bon je dis peut-être des bêtises, mais en gros de mémoire, c'est son parcours logiciel.
Ensuite oui, MyPaint et Krita sont beaucoup plus spécialisés "dessin/peinture" numérique, si je pige bien la philosophie, alors que GIMP se veut générique (comme Photoshop, de ce point de vue là). Certains disent que GIMP est fait pour la retouche d'image, et non le dessin. Selon moi, c'est pas vrai. GIMP s'en sort très bien pour dessiner. Simplement c'est plus générique, ça fait beaucoup plus de choses variées que Krita ou MyPaint, mais sur le point particulier du dessin, il y a en effet fort à parier que Krita/MyPaint soient meilleurs, puisque focalisés sur le sujet. C'est un choix. On peut aimer ou non. C'est le Logiciel Libre, y en a pour tous les goûts.
Par contre, dans l'autre sens, ça veut aussi dire que Krita et MyPaint sont vraiment pas adaptés pour la retouche comparé à GIMP, donc si tu dis que David Revoy continue à utiliser GIMP pour ce cas de figure, cela ne m'étonne pas. Il n'a probablement pas trop le choix, en fait.
On est aussi à l'écoute des utilisateurs. Simplement être à l'écoute ne signifie pas qu'on est à leurs ordres. Il faut voir que l'équipe de GIMP est extrêmement limitée et composée essentiellement de bénévoles, alors que Krita non.
Le mainteneur de Krita s'est lancé dans une entreprise de fondation Krita depuis l'an dernier. Ça veut dire qu'il est lancé dans une optique beaucoup plus marketing, parce que bien que sous le label de "fondation", ils font beaucoup de communication, presse et compagnie depuis lors, ils vendent des produits, du support commercial à travers une autre société, etc. C'est très bien s'il arrive à en vivre, ce qui est son but, je pense.
Et donc une des conséquences, c'est qu'ils écoutent beaucoup plus (et s'associent avec) des stars locales, parce que c'est excellent pour l'image, et clairement David Revoy en est une, depuis sa participation dans les projets Blender.
GIMP? Ben les quelques développeurs font ça dans leur temps libre et clairement ils se fichent de savoir si la personne qui demande une fonctionnalité est une star ou non pour décider si c'est une priorité ou pas. C'est probablement une erreur marketing, mais oui, je crois qu'ils sont en effet très mauvais en marketing.
C'est mon interprétation de la situation. Elle peut être fausse, mais c'est le ressentiment que j'ai eu de l'intérieur. Aussi note que personnellement je suis pour qu'il y ait divers logiciels, avec des forces et des faiblesses, et j'en ai clairement rien à faire des comparaisons malintentionnées et tentatives de donner une mauvaise image à la concurrence. C'est la seule chose qui m'a un peu déçu lors des LGM, avec une attitude un peu agressive par moment de Krita envers GIMP. Moi perso, je trouve ces 3 logiciels très bien. D'ailleurs rien ne dit que je ne mettrai pas à faire des patchs pour Krita ou MyPaint un de ces 4, si on se met à les utiliser. Je suis certainement pas braqué.
Juste pour appuyer l'info sur la petite équipe de GIMP, car ça paraît peu vraisemblable puisque GIMP est un vieux de la vieille.
Les contributeurs GIMP: https://www.ohloh.net/p/gimp/contributors/summary
Les contributeurs Krita: https://www.ohloh.net/p/krita/contributors/summary
Comme tu peux le voir, y a en fait 1 unique gros (énorme) contributeur, Mitch, le mainteneur avec presque 700 commits par ans. Pour comparaison, avec seulement 60 commits en 1 an (plus de 10 fois moins!), je suis devenu le second plus gros contributeur. Krita de son côté a le mainteneur et ses 500 commits, puis 6 autres qui font au moins une centaine, etc. C'est pas du tout le même volume.
Bon c'est en vrai légèrement faussé car énormément du travail de GIMP a été déplacé dans GEGL et babl, donc en vrai pour avoir une vraie idée de l'équipe de GIMP, il faut additionner les contributions des 3 repos (et quand on fait ça, je ne suis plus le second contributeur). Mais ça reste tout de même plus petit que Krita.
Ben honnêtement j'espère qu'il est toujours considéré comme tel! On a vraiment du beau et du lourd en préparation pour la prochaine majeure (GIMP 2.10): images 16 et 32-bit (entier et flottants), OpenCL pour plus de multi-thread et utilisation du GPU, des nouveaux outils sympas, genre le warp tool utilisé dans la vidéo, des factorisations d'outil (genre transformation unifié, et un projet GSOC en cours pour unifier la sélection aussi), pour un workflow plus agréable et moins encombré, etc. etc. Les GSOC en cours sont aussi plutôt sympas (l'un pour un nouveau outil de n-point déformation dont la vidéo de démo était impressionnante, support plus solide du PSD pour échanger avec les Adobiens, etc.).
Sans compter tout ce qui est en pleine gestation, comme le port complet vers GEGL, qui ouvrira la porte à du traitement d'image sans perte, ce qui est un énorme truc, avec vraiment beaucoup de répercussions.
GIMP 3.0 (version majeure suivante) ensuite sera focalisé sur le port vers GTK+ 3.0 (déjà commencé dans une branche à part), qui est beaucoup moins excitant car c'est un peu comme développer pour en revenir au même point. Mais c'est aussi un pas — frustrant certes — mais important, car GTK+2 n'évolue plus. Ça veut dire qu'on peut toujours y corriger des bugs, mais pas apporter de nouvelles fonctionnalités au niveau de l'UI. Un point majeur est le support du hotplug de périphérique dans GTK+3. Genre à l'heure actuelle, si tu oublies de brancher ta tablette graphique avant de lancer GIMP, elle est pas reconnue (t'es bon pour redémarrer GIMP. Et encore au moins maintenant on crashe plus. Pendant des années, GIMP crashait si tu débranchais ta tablette avant de quitter GIMP. Mais j'ai contourné ça dans GTK+2 y a quelques mois). Comme tu le vois, c'est assez décisif pour un logiciel de dessin.
En tous cas, je dirais pas que GIMP est mort. On reste quand même très en avance dans plusieurs points, et on a des vraiment beaux projets. On manque juste de mains pour aller plus vite.
Donc oui, il y a clairement un manque de développeurs. On a clairement un mainteneur fort (Mitch, avec son nombre de commits énorme), mais il ne cherche pas à être plus leader que cela, ce qui peut être apprécié ou non. Il nous manque en effet peut-être un "leader", un mec qui aime l'administration, qui veut faire du marketing. C'est vrai que pour l'instant on a plus des hackers par ici. Moi rien que ces deux jours à peine où j'ai commencé un financement, je suis épuisé, tout en ayant la sensation de rien faire de vraiment "réel". J'ai pas touché une ligne de code depuis ces deux jours, je fais que répondre à des messages. Franchement je ferais pas ça tous les jours!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: "déjà plus loin que Krita" ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Financement participatif de dessin symétrique dans GIMP. Évalué à 2.
Salut,
oui on m'a aussi dit hier que Krita a bien amélioré le miroir. A priori même y a quelques mois, lors du LGM, on pouvait déjà bouger les axes, mais il paraît que c'était bien caché dans l'UI. Mon but n'est nullement de critiquer Krita. Ça a l'air aussi super ce qu'ils font. Comme je disais, ce fut d'ailleurs la source d'inspiration de mon hack. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]