Perso, la séparation me convient très bien, et si Gimp poursuit son évolution (images sans pertes, etc.), je comprendrai encore davantage la logique d'avoir deux options, l'une destinée à l'enregistrement et au travail, l'autre à l'utilisation finie d'une image.
Tout à fait!
C'est exactement cela. Les "images" GIMP (XCF) sont à considérer comme des projets en cours. Un format de travail. Ce n'est pas à considérer comme un standard (ce n'en est pas un), cela suit les évolutions logicielles de GIMP même, et ne peut être comparé à un format d'image (PNG, JPG, whatever…).
C'est comme Blender. Enregistrer, c'est du .blend (le format de travail qui suit les logiques logicielles de Blender). Ça n'empêche pas d'exporter en Collada (le standard pour la 3D) ou d'autres formats (souvent proprios).
En effet comme tu le notes, l'édition sans perte est une des énièmes très bonnes raisons: les formats d'image n'ont de concept de calque d'effet. Il faudra donc du XCF (enregistrer en PNG, jpg ou autre impliquera d'appliquer les effets et donc perdront de l'info). De même que la haute précision de couleur (PNG par exemple prend en charge jusqu'à 16 bits. GIMP ira bien plus haut).
Enfin il y a l'UI elle-même. À l'heure actuelle, on s'est contenté d'utiliser la même UI (puisque historiquement c'était la même chose), et donc ça perturbe les utilisateurs qui se disent "ben c'est la même chose". C'est compréhensible. Mais l'idée c'est qu'à l'avenir on aura 2 UIs différentes et adaptées. En fait j'ai même déjà du code stash-é qui commence le travail, mais faut que je trouve le temps de finir.
Par exemple beaucoup de gens demandent une gestion de "l'export pour le web", c'est à dire notamment changer la résolution d'une image très haute rés, appliquer éventuellement quelques filtres, etc. À l'heure actuelle, on doit faire ce genre de choses dans l'image même, puis surtout ne pas oublier de les annuler après export de l'image (pour ne pas engendrer de perte de qualité, surtout quand l'image est aussi destinée pour de la haute résolution). Ben je pense que ce genre de choses devraient être faisable aisément dans une UI séparée qui gère ce genre de choses (comme un graphe d'effet à appliquer seulement dans un mode d'export particulier qu'on peut sauver).
Ce sont des exemples mais on peut en trouver beaucoup d'autres. Sauver et exporter sont vraiment des processus très différents. Simplement nous n'avons pas encore l'UI. C'est la base de cette évolution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Petite question à ce sujet… L'édition non destructrice est intéressante, mais il me semble qu'elle se limite quand même à des filtres de traitement d'images "basiques", rapides à calculer. De même pour la fonctionnalité "preview on canvas" qui est poussée en avant pour les prochaines releases avec GEGL.
On imagine mal en effet devoir attendre 15 minutes (au hasard) le recalcul d'un rendu après avoir changé un paramètre d'un des filtres (parce que le graphe comprend un filtre très long à calculer, qui a été appliqué à la fin).
Oui et non. Oui, ça limite l'intérêt, et notamment clairement la prévisualisation en directe pourrait devenir une véritable plaie (bloquant l'UI et empêchant de configurer correctement son filtre si à chaque fois qu'on affleure même un slider, on doit se taper une prévis).
Ensuite non, la non-destructivité est quand même utile (selon moi) pour les filtres longs. Du moment qu'on gère bien toute la partie ennuyante (comme la prévisualisation, en ne l'autorisant pas sur certains filtres), il reste tout de même d'autres avantages bien réels. Par exemple, tu parles de changer le paramètre d'un filtre. Ben dans ce cas là, même avec la méthode destructive (annuler, refaire le filtre), on doit se retaper les 15 minutes de traitement du filtre. Ben au moins avec la méthode non-destructive, on peut le faire n'importe quand, même après plusieurs heures de travail et des centaines d'autres actions faites entretemps; donc revenir sur l'historique — si possible, des fois ça ne l'est même pas — en revient à perdre des heures de travail.
Avez vous prévu quelque chose de spécial dans ce cas ?
Je ne suis pas certain, mais il est clair que nous ne laisserons pas ce genre de problèmes arriver (ou par erreur, et dans ce cas là, ce sera à considérer un bug à corriger). Il faudra les traiter. Je peux imaginer plusieurs choses.
Déjà la détection: on peut ajouter une notion de coût (théorique, comme un paramètre disponible en introspection) à une opération (il me semble me rappeler que cela a d'ailleurs déjà été discuté sur IRC). Ainsi avant même de commencer une opération, on peut avertir l'utilisateur que la prévisualisation risque d'être longue pour certaines opérations (voire même l'interdire pour des opérations qu'on sait vraiment vraiment trop longue), ou bien même pour toute opération si on l'exécute sur une image de vraiment trop grande taille. Ensuite on peut aussi avoir, en plus, un timer qui prend la main quand une prév dure trop longtemps, et donne la possibilité à l'utilisateur de l'interrompre.
Ensuite comment gérer ces ops trop longues?
1/ On peut donc simplement interdire la prév automatique comme je disais.
2/ Mais on peut aussi permettre une prév explicite avec un bouton dans ce cas. C'est à dire que ça ne va pas re-rendre le résultat juste en bougeant un slider d'un micromètre (bon moyen de rendre une UI inutilisable). Par contre, l'utilisateur peut bouger ses boutons et sliders tranquillement, puis cliquer sur un bouton, aller prendre un café et revenir voir le résultat après 15 minutes. Éventuellement refaire des changements, etc. Ou sinon appliquer (ce qui sera instantané puisque tout est déjà calculé).
Cela reste toujours légèrement plus pratique et rapide que d'appliquer, annuler, rouvrir l'UI de plugin, réappliquer, réannuler… Pas énormément différent, hein. Mais un peu, selon moi.
3/ L'utilisateur peut supprimer la visualisation d'un filtre (avec l'icône "œil"). Ça permet de l'appliquer au début, mais ensuite de l'empêcher d'actualiser sans cesse la vue (surtout si on prévoit de peindre sur le calque de base, etc.).
4/ On peut aussi permettre d'appliquer un filtre (ou une liste de filtres) directement sur l'image (c'est à dire en destructif comme maintenant). En fait j'en ai jamais discuté avec les autres, mais personnellement cela me paraît une fonctionnalité évidente.
Il y a toujours des cas où appliquer un filtre est mieux, voire nécessaire. Par exemple si on souhaite peindre directement sur le rendu (et non sur le calque de base, ni sur un autre calque au dessus), il n'y a pas d'autres choix que d'appliquer le filtre pour qu'il ne fasse qu'un avec son calque. Blender par exemple permet de faire cela (on peut mettre des filtres genre miroir sur des objets 3D. Puis ensuite on l'applique, ce qui permet de travailler sur un côté de l'image différemment par exemple).
En tous cas, cela signifie qu'une architecture non-destructive n'oblige absolument pas à travailler non-destructif tout du long. L'utilisateur peut toujours revenir à une méthode de travail destructive.
5/ Enfin, en revenant sur la problématique des prévisualisations, il y a des moyens de les accélérer (en dehors de la solution d'optimiser les opérations elle-même bien sûr), notamment lorsque le viewport ne montre qu'une partie de l'image. Ou à l'inverse quand la vue de l'image est plus petite que la taille réelle du fichier à cause d'un zoom-out. Bon c'est pas moi l'expert, mais voici un email du mainteneur GEGL sur le sujet de l'accélération de la prévisualisation.
Ce sont des choses auxquels les divers développeurs réfléchissent beaucoup.
Si non, cela veut-il dire que les opérateurs GEGL seront de toute façon limités à des traitements basiques, si on veut les rendre utilisables en pratique ?
Non puisque comme je disais, on devrait toujours pouvoir les utiliser en destructifs à l'ancienne. C'est juste une question d'UI.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Rapidement, tu peux expliquer tes aventures de vagabondage ? (j'ai vagabondé un peu aussi il y a pas si longtemps que ça, et la photo rappelle des souvenirs… :)
Cette photo, c'était en Mongolie. J'ai vagabondé entre la France et le Japon pendant 6 mois, puis j'ai vécu au Japon, en Corée, en Nouvelle Zélande, où j'ai aussi pas mal bougé.
Et j'imagine que coder ou quoi avec ce que tu as l'air d'avoir sur cette première photo, c'est difficile, voir pas vraiment d'actualité pendant ce genre de voyage/vagabondage.
En effet je code pas, ou presque, quand je suis sur la route.
Comment ça se passe/s'est passé avec tes différents projets/contributions ?
Ben tu mets en pause quand tu sais que de toutes façons, tu n'auras pas vraiment l'opportunité de contribuer. Par exemple à l'époque je contribuais beaucoup dans le monde XMPP. Ben avant de partir, j'ai quitté la XSF (ils ont assez de membres fantômes, pas la peine d'en rajouter un), de la même façon que j'ai démissionné de mon job ou que j'ai donné un préavis pour l'appart que je louais à l'époque. Y a pas vraiment de différence. :-)
Par contre une fois un peu plus posé, même si tu peux rester mobile et déménager tous les mois, rien n'empêche de contribuer avec même un petit portable léger et peu puissant. J'ai codé pendant plusieurs années sur un petit eeepc acheté au Japon. J'ai même codé dans une startup au Japon avec cet eeepc pendant plus d'1 an (avant qu'ils m'achètent un ordi puissant) où j'étais senior developer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Bon j'ai dit que je répondrai pas, mais je marche dedans! J'arrive pas à retenir mes doigts.
sur ce qui ne marche manifestement pas.
Qu'est-ce qui ne marche pas? Qu'un outil n'est pas parfait n'est pas la même chose qu'un outil cassé. L'outil de texte marche très bien. Quand on trouve un bug, je peux t'assurer qu'on n'attend pas longtemps avant de le corriger.
En outre, c'est justement ce petit plus de l'UI parfaite qui prend du temps. Parler c'est beau, mais si tu as la science de l'UI idéale infuse, on les veut bien tes dessins et tes spécs détaillés (c'est à dire qui prend en compte tous les cas, pas juste un yakafokon en 1 ligne) pour rendre l'outil de texte bien meilleur.
Il faut aussi savoir gerer son temps.
Merci de venir nous donner des leçons de vie. Heureusement que les trolls sont là pour nous apprendre comment gérer notre temps (avec ce magnifique exemple justement pour nous le faire perdre! En fait c'est peut-être cela la "gestion" du temps que tu veux nous enseigner?); sans eux, que ferait-on?
Je concluerai par un lien vers notre bugtracker, de la liste des rapports qui sont passés en statut "FIXED" (= corrigé) depuis janvier 2015: 75 bugs à ce jour
Et encore, c'est sans compter les bugs découverts en interne et corrigés sans qu'il y ait eu un rapport de bug. Je compte donc, dans la seule année 2015, 459 commits dans GIMP master, 26 dans babl master, et 218 dans GEGL master. C'est sûr, les développeurs de GIMP n'en font vraiment pas une et "se fout[tent] de l'utilisateur".
D'ailleurs saviez-vous que lorsqu'un utilisateur rapporte un bug, en fait on va se moquer de lui derrière son dos et on rigole bien car on fait exprès de ne jamais corriger les bugs.
Non mais qu'est-ce qu'il faut pas lire!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est pas faux. La gestion du texte est clairement compliquée sous GIMP.
Tout à fait. La gestion du texte est un très gros chantier sur lequel on aimerait tous venir un jour. C'est clairement un outil assez frustrant à de nombreux égards. Je suis le premier à être d'accord, et Aryeom ne dira pas le contraire non plus! Tous les autres dévs en sont conscients aussi car on en parle régulièrement (on en a encore parlé avec le mainteneur y a 2 mois lors de LGM 2015).
De manière général, le commentaire initial du fil liste plusieurs problèmes réels, connus et qu'on veut améliorer.
Par contre j'ai voulu répondre, mais j'ai abandonné. Le commentaire n'a clairement pas été fait pour initier un échange constructif, et je sens que toute réponse (celle-ci comprise probablement) ne m'apportera que des attaques ad-hominem. C'est donc mon premier et dernier message sur ce fil de discussion.
Par contre si y a d'autres questions ou commentaires intéressants, et même des critiques constructives, n'hésitez pas à créer un autre fil.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'imagine que l'utilité du machin doit résider dans l'ergonomie et le fait qu'il n'y a plus besoin de prendre de précautions : quoiqu'il arrive l'image de base sera toujours dispo.
Benoît Sibaud a bien répondu avec des détails. Mais globalement ce que tu dis est juste aussi.
En gros, l'idée est de ne plus travailler avec des filtres temporellement mais avec un graphe (ou au moins une pile) de filtres. Tu ne modifies donc plus l'image avec ça, puis ça, puis ça. Puis tu dois tout annuler pour retirer juste le premier filtre. Tu as juste une image (qui reste toujours clean) et une pile de filtres au dessus. Et tu peux éditer tes filtres, les réordonner, en ajouter un, avant, après ou au milieu des filtres existants, etc.
L'historique n'a plus tellement de sens et n'est plus utile. Cette méthode de travailler est bien plus flexible.
Par contre, il y a certaines choses pour lesquelles l'historique a toujours du sens: tout ce qui est peinture ou assimilé.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En général, les spams sont gérés au niveau du serveur. Roundcube est un client, qui certes s'installe sur un serveur (web), mais qui est à comparer à un client lourd installé sur l'ordi. Bien sûr, les clients lourds ont souvent un antispam (comme Thunderbird), mais ça ne vaut pas un antispam serveur parce que ça marche avec n'importe quel client! Tu lis tes emails depuis Thunderbird? Depuis ton tél? Depuis le webmail parfois? Ça marche toujours pareil. C'est d'autant plus important avec imap (je pense que l'antispam sur le client, c'est d'ailleurs un reliquat d'une époque où on téléchargeait tous les emails avec pop3, toujours sur le même ordi).
En outre avoir un antispam sur le webmail, ça signifierait du traitement antispam fait quand vous vous connectez à votre compte, donc alourdirait l'expérience webmail; alors que direct sur le serveur, le traitement se fait à l'arrivée de chaque email, 1 par 1. C'est beaucoup plus léger comme traitement. Imagine que tu t'es pas connecté sur ton compte email depuis une semaine, t'as reçu des centaines d'emails à traiter d'un seul coup. Maintenant multiplie ça par tes utilisateurs. Ça fait des périodes où y a pas de traitement (la nuit), et soudainement plein (le matin), et tout ça en plus fait par le serveur web (du code PHP — dans le cas de Roundcube — qui tourne au moment d'une requête). Ça pourrait aussi être traité côté client en javascript, mais dans ce cas là se pose le problème de sauver la base de données du filtre (bayésien en général).
Enfin voilà, perso je trouve que c'est bien mieux ainsi.
Par contre il existe plusieurs techniques bien connues pour gérer le spam (envoyer à une adresse email spécifique, simplement déplacer dans un répertoire, etc.) et il pourrait y avoir une option pour mapper un bouton "spam" (ou "not spam" selon contexte) à ces diverses actions, selon technique utilisée. Ça oui, je suis d'accord, ce serait cool et rendrait l'expérience plus transparente aux utilisateurs.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Tout est possible. Faut ensuite voir le "coût", que ce soit le coût de développement, c'est à dire la complexité, le temps que cela va nous prendre à avoir une architecture convenable, mais aussi le coût additionnel du traitement, et donc notamment le temps additionnel et la mémoire utilisée, etc. Déjà que beaucoup se plaignent du fait que le non-destructif peut être plus lent (car à chaque changement de l'image ou d'opération, on doit potentiellement recalculer toutes les opérations "au dessus"), et qu'il va rapidement bouffer toute la mémoire, voire swapper, et devenir encore plus lent (cf. commentaire plus haut au sujet de Darktable)… Puis faut voir si ce coût vaut le coup en comparaison du gain.
Surtout qu'au début on parlait d'optimisation, maintenant on veut rendre le traitement encore plus parfait (donc lent en général). :-)
Par exemple, la rotation, bah, tourne réellement la matrice (comme sur ton schéma), ensuite on applique ton filtre, et à la fin on interpole sur une grille 4x4 …
Déjà il faut bien noter que ce n'est commutable qu'avec certains types d'opérations. Par exemple si une opération changeait les pixels en fonction de leur position, cela ne serait pas la même chose de l'appliquer avant ou après rotation (exemple typique: utilisation d'une texture que l'on va mapper au dessus de l'image). C'est un travail assez important de bien cataloguer les opérations. Et l'utilisateur a peut-être choisi exprès d'appliquer telle opération sur les pixels avant ou après une rotation car il voulait tel rendu, ou tel autre. Il faut donc bien faire attention quand on réordonne. Pas tout ne peut l'être.
Mais oui, il y a des moyens d'optimiser un graphe et c'est un travail qui demande du temps pour le faire bien, en utilisant des connaissances mathématiques puis en les appliquant à la réalité de la représentation algorithmique. Et surtout ne pas changer le rendu désiré par l'artiste.
D'accord, mais ta description, c'est carrément un arbre (donc le graphe a bien une forme particulière)
Non, mon exemple est un arbre. Pourquoi en faire une généralité?
On pourrait avoir une opération qui re-rentre dans un autre nœud. Par exemple ci-dessous, op1 rentrerait dans op2 et re-rentrerait dans op3, ce qui est très pratique car cela évite d'avoir à recréer des nœuds qui recalculeraient des opérations que l'on a déjà calculées.
op3
^ ^
op2 ^
^ ^
op1 >>>
On a ce genre de graphes tout le temps dans Blender. Je ne suis pas sûr si GEGL permet plusieurs sorties, mais si ce n'est pas le cas à l'heure actuelle, ce ne serait pas dur à implémenter; ensuite il faut juste adapter l'UI. Dans GIMP, certains semblent ne pas vouloir une UI trop complexe. Ce que je comprends tout à fait pour l'UI de base, du moment qu'on puisse aussi proposer une UI alternative pour gérer des graphes complexes. Enfin on verra cela quand nous commencerons à réfléchir sur une UI pour le non destructif dans GIMP.
Par contre, dans ton modèle, je vois pas comment on peut faire une rotation
Je reprends donc mon exemple. Supposons que l'on ait une rotation comme opération non destructive sur le Layer 2.
puisque c'est pas une opération qui demande deux calques
Une opération n'a pas forcément 2 entrées. Elle peut en avoir 1, 2… et même zéro! (par exemple une opération de chargement d'image n'a pas besoin d'entrée. Elle a juste un paramètre pour indiquer un chemin d'accès au fichier, ou même des opérations qui génèrent de l'aléatoire). De même pour les sorties.
Sinon, encore une question […]
Je ne peux pas vraiment répondre à ce type de questions. Comme je disais, je ne suis pas du tout expert en algorithmique du traitement d'image. J'ai fait des maths à niveau correct et de l'algorithmique à la fac, mais c'était y a des années et je ne lis pas de livres de maths le soir avant de me coucher. Donc oui je comprends comment marchent les divers algorithmes quand je lis du code. Par contre non je ne pourrai pas comparer les algorithmes. Enfin si, peut-être si je me mettais à lire beaucoup sur le sujet, puis à prendre un crayon et difficilement essayer de me remettre à résoudre des problèmes mathématiques, mais je n'en ressens pas le besoin. :P
On a plusieurs dévs qui sont très calés sur ce genre de choses, et je leur fais confiance. De mon côté, je fais d'autres choses peut-être un peu plus terre à terre, mais bon, chacun son truc. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est une question que je me pose vraiment. Quel est l'intérêt d'une levée de fond avec un système de crowd-funding « traditionnel » comme indiegogo plutôt que patreon qui permet d'avoir une paye chaque mois ?
C'est très différent. Et nous avons beaucoup pensé à ce type de financement aussi, mais il ne correspondait pas à notre situation. Par contre, comme Creak le note, rien n'empêche d'utiliser Patreon (ou tout simplement de monter un système de financement mensuel sur le site) après coup, et on le fera peut-être.
Pourquoi Patreon n'était pas adapté? Car ça commence très bas. On dit aux gens qu'on va faire quelque chose et à chaque sortie (ou mois), on récupère le montant sponsorisé à ce jour. Or si c'est pour récupérer 100 € pour 1 mois de travail, autant faire tout bénévolement tout de suite. C'est acceptable quand on fait de la BD (même si 100 € la page par exemple reste faible, c'est moins ridicule que genre 100 € la minute d'animation, ce qui correspond à storyboard + 1440 dessins en HD). On voit bien que ceux dont les financements montent haut, c'est après pas mal de temps et qu'une certaine réputation s'est installée. Cela marche donc OK si on est déjà célèbre ou après beaucoup de temps, et surtout pour une seule personne (si on est 2, 3, 4, ça divise le financement de beaucoup). Et cela ne prend pas en compte le financement initial. Nous voulions voir avant de commencer notre projet si les gens nous suivraient.
Par contre, quand notre financement initial sera terminé, puisque nous avons passé notre premier palier, je pense que cela pourra être intéressant de compléter par un système de type Patreon, en effet.
les youtubers que je sponsorise se font quand même de l'argent avec la pub de Youtube
Franchement nous éviterons autant que possible de mettre de la pub, que ce soit sur les vidéos (sur Youtube ou alors), sur nos sites, etc. Jusqu'alors je n'ai jamais mis la moindre pub sur la moindre de mes créations et je ne m'en porte que mieux. Pour moi cela pollue notre espace visuel. Et un bloqueur de pub, ce n'est pas la réponse selon moi. Ce n'est qu'un contournement. Moi, je rêve d'un monde sans pub, où il n'y a pas besoin de bloqueur de pub (cela n'arrivera probablement jamais, mais je ne souhaite pas être fataliste et contribuer pour autant à ce monde).
J'ai entendu des arguments, même non monétaires, notamment on m'a dit que les vidéos sans pub sur Youtube étaient dépriorisées par Google (une recherche va afficher des vidéos avec pub en haut en priorité). C'est triste, mais je trouve l'expérience des pubs sur Youtube tellement horrible et désagréable que je refuse à ce jour de le faire subir à ceux qui visionneront nos vidéos.
En outre, honnêtement je préfère de loin vivre de l'argent direct par des contributeurs qui veulent nous soutenir explicitement (à ce jour 313 personnes, dont nous ne connaissons pas la grande majorité, nous soutiennent; ça fait chaud au cœur, plus que de recevoir même 3 fois cet argent en échange de zombification publicitaire) que par les conglomérats de la pub qui ne sont que des parasites selon moi.
Et même si je sais que beaucoup de gens n'ont pas l'air d'être plus touchés que cela par la pub, j'espère tout de même au fond de moi que nos contributeurs s'en rendent compte (peut-être certains?) et nous soutiennent même davantage pour cela.
P.S.: c'est aussi un des trucs que j'apprécie sur LinuxFR. Les seuls "bandeaux de pub" qu'ils ont sont choisis et ciblés pour les projets amis et sont davantage du soutien explicite par LinuxFR à ces projets et un peu de mise en avant, non comparable à ces pubs horribles et impersonnelles qu'on a habituellement pour bouffer du "temps de cerveau disponible" en échange d'argent.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En imagerie informatique, les données sont discrètes. Dans la "nature", une image est continue. Elle n'est pas une succession de point. Donc une vraie rotation physique n’abîme pas une image (tu as une photo posée sur la table, tu la tournes, elle ne perd pas en qualité! :P).
Mais dans une représentation bitmap, une image est une matrice limitée de point. Donc à part si tu fais une rotation qui garde une matrice (90°, 180°, 270°…), tes pixels d'origine se retrouvent entre 2 points de la matrice (les nouveaux pixels).
Exemple la matrice de pixels:
1 2
3 4
… après rotation à 45° devient:
1
3 2
4
Ce n'est plus une matrice, et il faut donc calculer les nouveaux pixels qui formeront l'image après rotation, à partir des pixels d'origine. Il y a pour cela divers algorithmes dit d'interpolation (regarde les paramètres de l'outil "rotation" de GIMP, tu peux voir que tu peux choisir le type d'interpolation, ce qui est bien sûr plutôt pour les utilisateurs avancés). Une interpolation possible pourrait être tout simplement de faire la moyenne pondérée entre les pixels qui chevauchent le nouveau pixel (c'est en gros l'interpolation linéaire quoi). Il y a d'autres algorithmes moins naïfs (ce qui ne veut pas dire que celui-ci est mauvais pour autant!), c'était juste pour prendre un exemple simple.
le graphe ressemble à plusieurs listes qui se terminent en un même nœud ?
Dans l'UI, ça ressemble à une liste.
Mais c'est en fait un graphe où à chaque nœud, on a rentré 2 calques, ce qui a produit un résultat, que l'on va "compositer" avec un autre calque.
Ainsi la liste de calque:
"Layer 1" (Normal)
"Layer 2" (Multiply)
"Layer 3"
La différence, c'est que Docker, c'est pour les serveurs, alors que là c'est un système de packaging utilisateur. On veut donc qu'un programme s'intègre à son environnement. Comme j'explique plus haut, on veut notamment lier les formats de fichier à une application (double clique sur un .xcf: ça doit ouvrir GIMP); on veut aussi mettre à jour le menu utilisateur automatiquement; on veut peut-être aussi fournir des infos aux autres logiciels pour interagir entre logiciels; on veut mettre l'icône de l'application accessible aux divers logiciels du bureau qui pourraient en avoir besoin, etc.
La partie sandboxing n'est pas pour moi la fonctionnalité cible. C'est uniquement une nécessité. Puisque ce sont des logiciels qui pourront être téléchargés d'un peu n'importe où, il faut pouvoir protéger un minimum l'utilisateur (même si on ne peut le protéger de lui-même et donc les risques existent toujours) et ses données.
Pareil pour les dépendances. Ce n'est pas à voir comme un but. Je suis certain que les dévs préféreraient ne pas en avoir besoin. Mais sans cela, un paquetage sera lié à une distribution en particulier (puisque chaque distrib a potentiellement des versions de lib différentes).
Le besoin, c'est simplement qu'il est très dur de télécharger un programme pour Linux quand il n'est pas packagé par sa distribution, ou seulement dans une version ancienne/bugguée. Et les rares fois où certains projets proposent quelques choses (en général juste une archive à décompresser quelque part), ça s'intègre absolument pas à votre bureau. Et s'ils proposent un paquetage de distrib, c'est limité à certaines distrib (.rpm, .deb, et encore pas toutes les distribs avec le même système de paquetage ne peuvent installer les mêmes paquets si certains chemins d'accès ou des noms de dépendances diffèrent par exemple…), et on a besoin des droits root pour installer.
C'est dommage qu'il n'existe aucun standard pour cela, et c'est ce qu'ils sont en train de créer.
D'ailleurs plusieurs font la remarque que c'est du GNOME, mais comme je le lis, même si cela vient de dévs GNOME au départ, c'est un projet de standard (XDG) qui devra fonctionner sous tous les environnements de bureau.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
il suffit d'ajouter des types de nœuds spécifiques pour des opérations génériques:
C'est bien ce que je dis. Il faut créer de nouvelles sous-classes de nœud et y mettre tous les nœuds qu'on arrive à identifier d'une certaine catégorie, puis réarchitecturer une bonne partie de la lib pour mettre à profit les propriétés de ces types de nœuds, etc. C'est du boulot, et ce il suffit me chagrine beaucoup. Pourquoi quelqu'un d'extérieur à un projet a souvent cette idée que les choses sont si simples à faire?
Ensuite je le redis: on accueille les bonnes volontés! Si tu penses avoir les idées et les capacités pour optimiser GEGL, on sera tous très heureux.
On remarque (faire un dessin) que map f et move (a,b) g commutent ! Donc on peut se débrouiller pour réordonner les enchaînements « move/map/move/map » et avoir seulement deux nœuds.
La commutation sur pas mal de type de nœud est vraie théoriquement, pas dans la pratique.
Imagine une fonction f() qui transforme un pixel gris entre [0; 0.5[ en noir, et un pixel gris entre [0.5; 1] en blanc (on va travailler sur un canal unique).
Tu as au départ une image de 4 pixels (2x2) avec un pixel sur 2 noir puis blanc:
N B
B N
Applique maintenant f(). L'image est inchangée. Applique maintenant une rotation de 45°. Bon il existe divers algorithmes de rotation, donc on va juste supposer qu'on utilise un algorithme qui fait une moyenne entre les pixels adjacents.
Résultat final: une image totalement grise uniformément.
Commute maintenant les opérations. Fait d'abord la rotation (tous les pixels deviennent gris), puis applique f().
Résultat: tous les pixels sont blancs!
Nous avons 2 images totalement différentes au final. Théoriquement (mathématiquement) tu as raison, on peut réordonner ces opérations. Dans la réalité de l'imagerie informatique, ce n'est plus vrai.
En plus, je parle même pas du cas où f() utiliserait la position du pixel comme donnée d'entrée (par exemple pour effectuer un traitement en mixant avec une image de pattern…), et déplacer les pixels avant ou après modifierait donc complètement le rendu aussi.
Enfin, rien ne peut être optimisé de manière aussi naïve si on a pas l'assurance d'avoir du code sans effet de bord, et je ne sais pas si c'est pertinent pour du traitement d'images …
Ben voilà, tu as compris. On ne peut pas juste optimiser naïvement comme les exemples proposés plus haut. C'est beaucoup plus compliqués que juste des mathématiques (celles ci sont la base, mais il faut ensuite pouvoir les appliquer dans la réalité des représentations informatiques).
Pourquoi est-ce un graphe ? Une liste d'opérations à faire ne serait pas aussi bien ?
Comment tu fais pour du compositing sans graphe? Une liste d'opérations ne permet que de modifier une image, mais dans la réalité, on (= tous ceux qui utilisent ce genre de logiciels de dessin et traitement d'image) mélange des dizaines d'images les unes aux autres. On pourrait même avoir des opérations qui rentre dans un noeud et re-rentre dans un autre nœud, pourquoi pas.
Enfin bon, de toutes façons, même sans aller plus loin, GIMP serait bien triste si on pouvait plus avoir de compositing (= adieu les calques!).
Je sais pas si tu as déjà testé l'éditeur de Node de Blender, mais tu pourrais presque plus rien y faire s'il s'agissait juste d'un système linéaire, et il perdrait soudainement beaucoup de son intérêt (alors qu'à l'inverse, à l'heure actuelle, c'est un des gros points forts de Blender).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Perso j'attends ces technologies avec impatience.
Par contre ce n'est pas du tout fait pour remplacer les systèmes de packaging des distribs Linux (et j'espère sincèrement que personne n'aura cette idée saugrenue).
Sur mon ordi, 99% (doigt mouillé) sont des logiciels installés par le packaging de ma distrib. Par exemple j'en ai rien à faire que Firefox soit un chouille en retard en version. Pareil pour mes lecteurs vidéo/audio, libreoffice, ou de manière générale la plupart des logiciels que j'utilise et qui me conviennent très bien. Par contre il existe 2 cas où ça me gêne:
1/ Certains programmes ont un problème qui me gêne depuis longtemps (voire une régression, bug qui n'existait pas avant et apparu lors d'une mise à jour). Or en cherchant des infos, je me rends compte que ce problème est connu et corrigé par la version stable en download. Franchement dans ce cas, attendre que la distrib mette à jour son paquet, ce qui prend souvent du temps (surtout pour les petits logiciels) me fait chier.
2/ Il existe de rares cas où avoir les dernières fonctionnalités upstream est important, en général c'est en rapport avec ses activités. Typiquement pour moi: Blender, GIMP, Scribus… ont des fonctionnalités qu'on va vraiment utiliser dès qu'on les obtient. Je ne veux pas attendre je-ne-sais-combien de mois non plus.
Or sous GNU/Linux, les téléchargements sur site, c'est en général soit du source-seulement, soit des archives à décompresser, et à mettre quelque part. Un utilisateur de base ne sera pas capable de faire en sorte que les fichiers correspondants lancent la version téléchargée (par exemple, double cliquer sur un .blend -> cela lance Blender installé par la distrib, pas celui téléchargé). Vous n'aurez pas le programme dans le menu (donc la plupart du temps, les utilisateurs gardent le dossier décompressé sur le bureau pour accès "plus ou moins simple et rapide"). Etc. C'est chiant, sale (l'installation) et pas du tout intégré à votre environnement.
Or ce type de solution a pour but d'installer des apps en mode utilisateur mais de manière propre. Vous pourrez cliquer sur des fichiers qui ouvriront votre application (installation des fichiers desktop); vos menus seront mis à jour avec la nouvelle app, sa description et son icône, dans la catégorie adéquate; vous n'avez pas besoin d'encombrer votre bureau de répertoires, etc. Tout comme une app installée par le système de paquetage de votre distrib, intégrée et propre, mais en mode utilisateur et avec une version récente, avec des droits réduits (car installé depuis une source moins sûre) à donner au fur et à mesure à l'application!
Franchement je trouve cela extrêmement gênant que tous les logiciels Libres — si on veut la version upstream — sont finalement bien plus simples à installer sous Win et OSX que sous Linux.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Bien sûr qu'on en est capable techniquement (comme un peu tout). Je parle de GIMP en particulier et j'entendais "ce qu'on pourrait faire", c'était pas une question de savoir si les langages ont cette capacité (quand même, heureusement qu'ils l'ont!).
Aussi ce que je disais, c'est surtout qu'il faut adapter l'architecture du code. À lire certains commentaires, on a l'impression que c'est trop facile, "il suffit d'optimiser" (yakafokon). Alors que pour le permettre, il faut identifier les cas possibles d'optimisation (comme je disais plus haut, des suites d'opérations matricielles, des ops sur des pixels si et seulement si elles ne sont pas dépendantes d'autres pixels de l'image, etc.), puis éventuellement adapter l'architecture du programme pour rendre ces optimisations faisables. Et ainsi de suite.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Mais du coup pourquoi ne pas avoir tenté le financement participatif ?
Qu'est-ce que c'est sinon que du financement participatif?
Je pense que ce que tu voulais dire est: pourquoi ne pas avoir essayé de le faire avec une des plateformes commerciales les plus connues? Je pense que la raison est qu'ils veulent déjà ne pas donner de limite de temps, en outre ils veulent permettre des financements de type "abonnement régulier" (ce que d'autres plateformes font aussi maintenant ceci dit)… Aussi probablement n'aiment-ils pas donner un pourcentage à la plateforme, ou ils n'aiment pas ce que représentent ces entreprises? Je ne sais pas… Mais toujours est-il qu'il n'y a pas une seule façon de faire et il s'agit bien d'un financement participatif.
Pour mes projets, j'ai moi-même longuement réfléchi et j'ai choisi des plateformes existantes par facilité mais franchement à terme, je préférerais de loin héberger nos propres campagnes…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
la version de développement de GIMP, à ce moment là, était totalement inutilisable, et ce, encore jusqu'à il y a à peine deux ans, car si lente que l'on pouvait donner un coup de pinceau puis aller préparer un café en regardant le trait s'afficher (ou presque !).
Or comme j'explique, leur tentative de port date de 2011 (cf. leur blog post), c'est à dire y a 4 ans, donc bien avant (2 voire 3 ans) que la bibliothèque GEGL ne commence à devenir vraiment utilisable (cad. pas trop lente). Et en outre, GIMP 2.10 n'est même pas encore sorti et surtout il n'aura même pas encore l'UI adaptée pour travailler en non-destructif. Donc clairement si Darktable décide de reprendre leur port GEGL, ce n'est pas pour demain. :-)
C'est pas grave, personne n'est pressé. Ce sont des choses qui se font avec le temps.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Oui, GEGL est fait pour être extensible, et les graphes visibles de l'extérieur, avec beaucoup d'introspection. Donc oui, on voit les détails du graphe de l'extérieur, on peut même récupérer automatiquement la description des opérations, la liste des paramètres et leur description, etc. Tout est fait pour l'introspection et la visibilité du graphe.
Mais pour faire de l'optimisation, faut connaître l'algorithme exact. Sinon tu te remets à réimplémenter tous les algorithmes par du code extérieur (et dans ce cas, pourquoi utiliser GEGL?) et surtout c'est de l'approximation. Optimiser, oui, mais uniquement si tu as exactement le même résultat (au pixel près) avec et sans l'approximation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Peut-être qu'il est possible de faire une "optimisation" du graph qui fusionnerait des opérations, mais de façon externe à la lib ?
Je ne comprends pas ce que tu veux dire… Comment est faite cette optimisation? Qui l'a fait si ce n'est pas GEGL? Quelle information utilise-t-il pour déterminer comment optimiser des nœuds sans en connaître le contenu?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
J'imagine que gegl ne fait pas d'optimisation, il n'est pas capable d'éviter la création d'un buffer lorsque l'on passe d'un noeud d'un graph à un autre ?
Je ne suis pas le mieux calé pour parler de GEGL. Aucun de mes patchs là-bas ne sont algorithmiques. J'y touche plus dans le cadre de problèmes rencontrés dans GIMP que pour GEGL même. Donc ma première réponse, c'est que je ne sais pas s'il fait la moindre optimisation pour réduire des opérations.
Mais est-ce qu'il pourra le faire à terme ?
S'il ne fait pas déjà, je ne vois rien qui empêche de le faire à l'avenir. Ensuite il y a des cas plus simples que d'autres. Par exemple, il y a toute une série d'opérations qui sont matricielles (les transformations mathématiques: rotation, translation, réflexion, changement d'échelle…), et bon ça la multiplication de matrice, c'est pas compliqué! Si on a plusieurs opérations matricielles de ce style qui se suivent, on devrait être capable très simplement de les combiner en une seule de façon transparente (tout en gardant une visualisation multi-nœuds).
D'ailleurs c'est peut-être déjà fait, aucune idée!
Pour d'autres types d'opérations, j'imagine que ça dépend. Beaucoup de choses simples à faire pour un humain ne le sont pas pour un ordi (et vice-versa). Donc à part programmer des cas particuliers partout (possible aussi, et cela reste intéressant si certains cas particuliers sont des optimisations connus pour faire gagner énormément et difficilement automatisables autrement), ce qu'il faut, c'est réorganiser le code pour créer des schémas.
Par exemple, une opération qui traite chaque pixel l'un après l'autre, ce dont tu parles, si c'est entièrement codé comme une boucle de programmation, c'est dur à réduire (car un programme ne "comprend" pas son propre code!). Par contre, on devrait être capable de faire une sous-classe d'opération pour les opérations "pareil sur tous les pixels" où — au lieu de faire des boucles sur les pixels — on donne juste l'opération mathématique à appliquer sur le contenu d'un pixel. À ce moment là, le programme sera capable d'enchaîner les opérations dans la même boucle, ce qui est déjà une bonne optimisation.
Ensuite il faut faire attention à ne pas introduire d'erreurs. Dans notre cas précis, cela fonctionne si les seules données extérieures sont indépendantes de l'image. Si par exemple, la modification d'un pixel utilise les données d'autres pixels, alors ce n'est plus possible (du moins plus aussi facile). En effet, la seconde opération utiliserait le pixel après modification par la première opération. Or si on exécute l'optimisation "2 opérations en une", elle n'aurait accès qu'au pixel avant modification par la première opération! On introduirait donc une erreur puisque le résultat serait différent.
Enfin voilà, tout est possible, mais faut bien y réfléchir et trouver l'architecture idéale.
Et dans tous les cas, il est conseillé de faire un programme qui marche bien avant de l'optimiser. Règle de base du bon programmeur. :-)
Je pause cette question, car pour avoir utiliser darktable, qui ne fait pas de destructif non plus, il arrive vite à manger toute la mémoire, avec seulement quelques opérations.
Ensuite y a pas de miracle. Le non-destructif a de gros avantages, mais ce n'est pas magique. Ça a son prix. La qualité a toujours son prix, c'est la raison pour laquelle dans beaucoup de workflow, il ne sert à rien d'en faire. C'est comme utiliser du jpg pour le web. Utiliser du png est théoriquement bien meilleur, mais dans 99% des cas, si l'usage est "web", alors on va exporter en jpg et de toutes façons personne (pas même soi-même) ne verra la différence. Par contre, quand on exporte pour travailler ailleurs, ou intégrer dans une vidéo, c'est du PNG.
Il faut savoir choisir les pratiques en fonction des besoins.
De manière générale travailler sur des données médias (son, et encore plus image), ça prend une place de dingue.
Pour ZeMarmot, nos ressources pour le teaser de 1 min font plusieurs GO de données! Notamment on travaille en HD avec des fichiers XCF qui peuvent dépasser 100 MB. Et encore on a des retours de gens qui travaillent dans des secteurs où leurs fichiers XCF font plusieurs GB! (ceux qui scannent des images à extrêmement haute résolution par exemple, ou des secteurs médicaux, scientifiques, etc.) Donc oui bien sûr, dans leur cas, rien qu'ouvrir l'image peut prendre toute la mémoire sur un ordi de base du supermarché.
Bon ces tailles de fous ne sont pas la majorité. Mais plusieurs centaines de MB par contre, c'est courant. Donc de nos jours, si tu travailles des images (photos, dessins…), avoir 8GB de RAM, c'est pas grand chose. Être à 16 ou même 32 GB, c'est pas du luxe. C'est inhérent même aux qualités et résolutions qu'on atteint maintenant avec l'imagerie (même amateur).
En conclusion: oui on peut probablement optimiser, et on le fera sûrement (développeurs recherchés! Si tu développes et souhaites ajouter le type d'optimisation dont on a parlé ici, tu es le bienvenu!). Mais faut pas non plus croire au miracle. Si tu charges des images de dizaines de Mégas par défaut (cas des images DSLR de nos jours), et que tu fais des dizaines d'opérations dessus, oui ça monte vite.
Faire du destructif est une possibilité et peut très bien être un choix valide. Tu perds en flexibilité et potentiellement en qualité du résultat final par contre.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ok.
Je dois t'avouer qu'à ce jour, je n'ai jamais eu à payer quelqu'un (ni même moi-même). Et donc mes chiffres sont plutôt de l'extrapolation de ce que je lis et ce qu'on me dit.
Mais oui, ce sera plus proche du SMIC qu'autre chose, donc c'est bien de savoir que c'est plutôt dans les 31% de charges (quoiqu'honnêtement je préfèrerai donner de bonnes payes à tous avec de grosses charges que des petites sommes avec de petites charges!).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Par contre je sais pas qui choisit (la rédac de LinuxFR ou le magazine sponsor?), mais c'est assez marrant que Linux Magazine me récompense pour des sujets pour lesquels j'avais essayé de les contacter à plusieurs reprises et mes emails comme mes messages téléphoniques ont à chaque fois été ignorés. ;-(
J'aurais bien apprécié notamment avoir même juste un petit encart au sujet de notre film d'animation Libre, et fait avec des Logiciels Libres (ce qui je pense est complètement dans le sujet!) dans un de leurs magazines. Enfin bon, merci quand même. C'est juste une petite remarque, mais je leur en veux pas. :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
:-)
Ceci dit, comme j'explique sur le journal, les contributions ont diminué beaucoup depuis 2 jours. Nous faisons aussi un peu moins de promotion car nous sommes épuisés, c'est probablement aussi dû à cela. Mais il faut savoir que les 100% sont loin d'être suffisants pour terminer le projet (comme on l'explique dans la page de crowdfunding, c'était notre première étape pour pouvoir démarrer!). Donc j'en appelle toujours aux personnes intéressées. Si vous voulez voir ce projet mené à bout, il est tout à fait encouragé de continuer à le financer!
Toute somme additionnelle nous permettra de travailler plus longtemps et donc de repousser la prochaine campagne de financement pour pouvoir continuer le projet, et ainsi d'éviter de reperdre trop de temps à chaque fois!
En tous les cas, oui maintenant on va commencer, travailler quelques mois, puis nous présenterons notre résultat. Avec les fonds actuels, c'est presque du bénévolat (mais c'est pas grave, c'est un projet perso, et on y croit sur le long terme!), puisqu'il faut considérer les charges (qui diminuent de moitié environ tout paiment humain), mais on produira du code et contributions aux LL, design et recherches pour le projet, et environ 1 scène de plusieurs minutes. Puis nous devrons relancer une campagne de financement avec ce premier jet, en espérant qu'il donnera envie aux gens de par le monde de voir la suite du film et/ou de donner plus pour créer et améliorer les logiciels libres.
C'est notre espoir: lancer une dynamique pour financer de l'Art Libre et de la contribution aux Logiciels Libres de création.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 2. Dernière modification le 30 juin 2015 à 19:37.
De rien! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: contenu inutile.
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 9.
Tout à fait!
C'est exactement cela. Les "images" GIMP (XCF) sont à considérer comme des projets en cours. Un format de travail. Ce n'est pas à considérer comme un standard (ce n'en est pas un), cela suit les évolutions logicielles de GIMP même, et ne peut être comparé à un format d'image (PNG, JPG, whatever…).
C'est comme Blender. Enregistrer, c'est du .blend (le format de travail qui suit les logiques logicielles de Blender). Ça n'empêche pas d'exporter en Collada (le standard pour la 3D) ou d'autres formats (souvent proprios).
En effet comme tu le notes, l'édition sans perte est une des énièmes très bonnes raisons: les formats d'image n'ont de concept de calque d'effet. Il faudra donc du XCF (enregistrer en PNG, jpg ou autre impliquera d'appliquer les effets et donc perdront de l'info). De même que la haute précision de couleur (PNG par exemple prend en charge jusqu'à 16 bits. GIMP ira bien plus haut).
Enfin il y a l'UI elle-même. À l'heure actuelle, on s'est contenté d'utiliser la même UI (puisque historiquement c'était la même chose), et donc ça perturbe les utilisateurs qui se disent "ben c'est la même chose". C'est compréhensible. Mais l'idée c'est qu'à l'avenir on aura 2 UIs différentes et adaptées. En fait j'ai même déjà du code
stash-équi commence le travail, mais faut que je trouve le temps de finir.Par exemple beaucoup de gens demandent une gestion de "l'export pour le web", c'est à dire notamment changer la résolution d'une image très haute rés, appliquer éventuellement quelques filtres, etc. À l'heure actuelle, on doit faire ce genre de choses dans l'image même, puis surtout ne pas oublier de les annuler après export de l'image (pour ne pas engendrer de perte de qualité, surtout quand l'image est aussi destinée pour de la haute résolution). Ben je pense que ce genre de choses devraient être faisable aisément dans une UI séparée qui gère ce genre de choses (comme un graphe d'effet à appliquer seulement dans un mode d'export particulier qu'on peut sauver).
Ce sont des exemples mais on peut en trouver beaucoup d'autres. Sauver et exporter sont vraiment des processus très différents. Simplement nous n'avons pas encore l'UI. C'est la base de cette évolution.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Question de n00b
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 8.
Oui et non. Oui, ça limite l'intérêt, et notamment clairement la prévisualisation en directe pourrait devenir une véritable plaie (bloquant l'UI et empêchant de configurer correctement son filtre si à chaque fois qu'on affleure même un slider, on doit se taper une prévis).
Ensuite non, la non-destructivité est quand même utile (selon moi) pour les filtres longs. Du moment qu'on gère bien toute la partie ennuyante (comme la prévisualisation, en ne l'autorisant pas sur certains filtres), il reste tout de même d'autres avantages bien réels. Par exemple, tu parles de changer le paramètre d'un filtre. Ben dans ce cas là, même avec la méthode destructive (annuler, refaire le filtre), on doit se retaper les 15 minutes de traitement du filtre. Ben au moins avec la méthode non-destructive, on peut le faire n'importe quand, même après plusieurs heures de travail et des centaines d'autres actions faites entretemps; donc revenir sur l'historique — si possible, des fois ça ne l'est même pas — en revient à perdre des heures de travail.
Je ne suis pas certain, mais il est clair que nous ne laisserons pas ce genre de problèmes arriver (ou par erreur, et dans ce cas là, ce sera à considérer un bug à corriger). Il faudra les traiter. Je peux imaginer plusieurs choses.
Déjà la détection: on peut ajouter une notion de coût (théorique, comme un paramètre disponible en introspection) à une opération (il me semble me rappeler que cela a d'ailleurs déjà été discuté sur IRC). Ainsi avant même de commencer une opération, on peut avertir l'utilisateur que la prévisualisation risque d'être longue pour certaines opérations (voire même l'interdire pour des opérations qu'on sait vraiment vraiment trop longue), ou bien même pour toute opération si on l'exécute sur une image de vraiment trop grande taille. Ensuite on peut aussi avoir, en plus, un timer qui prend la main quand une prév dure trop longtemps, et donne la possibilité à l'utilisateur de l'interrompre.
Ensuite comment gérer ces ops trop longues?
1/ On peut donc simplement interdire la prév automatique comme je disais.
2/ Mais on peut aussi permettre une prév explicite avec un bouton dans ce cas. C'est à dire que ça ne va pas re-rendre le résultat juste en bougeant un slider d'un micromètre (bon moyen de rendre une UI inutilisable). Par contre, l'utilisateur peut bouger ses boutons et sliders tranquillement, puis cliquer sur un bouton, aller prendre un café et revenir voir le résultat après 15 minutes. Éventuellement refaire des changements, etc. Ou sinon appliquer (ce qui sera instantané puisque tout est déjà calculé).
Cela reste toujours légèrement plus pratique et rapide que d'appliquer, annuler, rouvrir l'UI de plugin, réappliquer, réannuler… Pas énormément différent, hein. Mais un peu, selon moi.
3/ L'utilisateur peut supprimer la visualisation d'un filtre (avec l'icône "œil"). Ça permet de l'appliquer au début, mais ensuite de l'empêcher d'actualiser sans cesse la vue (surtout si on prévoit de peindre sur le calque de base, etc.).
4/ On peut aussi permettre d'appliquer un filtre (ou une liste de filtres) directement sur l'image (c'est à dire en destructif comme maintenant). En fait j'en ai jamais discuté avec les autres, mais personnellement cela me paraît une fonctionnalité évidente.
Il y a toujours des cas où appliquer un filtre est mieux, voire nécessaire. Par exemple si on souhaite peindre directement sur le rendu (et non sur le calque de base, ni sur un autre calque au dessus), il n'y a pas d'autres choix que d'appliquer le filtre pour qu'il ne fasse qu'un avec son calque. Blender par exemple permet de faire cela (on peut mettre des filtres genre miroir sur des objets 3D. Puis ensuite on l'applique, ce qui permet de travailler sur un côté de l'image différemment par exemple).
En tous cas, cela signifie qu'une architecture non-destructive n'oblige absolument pas à travailler non-destructif tout du long. L'utilisateur peut toujours revenir à une méthode de travail destructive.
5/ Enfin, en revenant sur la problématique des prévisualisations, il y a des moyens de les accélérer (en dehors de la solution d'optimiser les opérations elle-même bien sûr), notamment lorsque le viewport ne montre qu'une partie de l'image. Ou à l'inverse quand la vue de l'image est plus petite que la taille réelle du fichier à cause d'un zoom-out. Bon c'est pas moi l'expert, mais voici un email du mainteneur GEGL sur le sujet de l'accélération de la prévisualisation.
Ce sont des choses auxquels les divers développeurs réfléchissent beaucoup.
Non puisque comme je disais, on devrait toujours pouvoir les utiliser en destructifs à l'ancienne. C'est juste une question d'UI.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Vagabondage
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 10.
Salut,
Cette photo, c'était en Mongolie. J'ai vagabondé entre la France et le Japon pendant 6 mois, puis j'ai vécu au Japon, en Corée, en Nouvelle Zélande, où j'ai aussi pas mal bougé.
En effet je code pas, ou presque, quand je suis sur la route.
Ben tu mets en pause quand tu sais que de toutes façons, tu n'auras pas vraiment l'opportunité de contribuer. Par exemple à l'époque je contribuais beaucoup dans le monde XMPP. Ben avant de partir, j'ai quitté la XSF (ils ont assez de membres fantômes, pas la peine d'en rajouter un), de la même façon que j'ai démissionné de mon job ou que j'ai donné un préavis pour l'appart que je louais à l'époque. Y a pas vraiment de différence. :-)
Par contre une fois un peu plus posé, même si tu peux rester mobile et déménager tous les mois, rien n'empêche de contribuer avec même un petit portable léger et peu puissant. J'ai codé pendant plusieurs années sur un petit eeepc acheté au Japon. J'ai même codé dans une startup au Japon avec cet eeepc pendant plus d'1 an (avant qu'ils m'achètent un ordi puissant) où j'étais senior developer.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 10.
Bon j'ai dit que je répondrai pas, mais je marche dedans! J'arrive pas à retenir mes doigts.
Qu'est-ce qui ne marche pas? Qu'un outil n'est pas parfait n'est pas la même chose qu'un outil cassé. L'outil de texte marche très bien. Quand on trouve un bug, je peux t'assurer qu'on n'attend pas longtemps avant de le corriger.
En outre, c'est justement ce petit plus de l'UI parfaite qui prend du temps. Parler c'est beau, mais si tu as la science de l'UI idéale infuse, on les veut bien tes dessins et tes spécs détaillés (c'est à dire qui prend en compte tous les cas, pas juste un yakafokon en 1 ligne) pour rendre l'outil de texte bien meilleur.
Merci de venir nous donner des leçons de vie. Heureusement que les trolls sont là pour nous apprendre comment gérer notre temps (avec ce magnifique exemple justement pour nous le faire perdre! En fait c'est peut-être cela la "gestion" du temps que tu veux nous enseigner?); sans eux, que ferait-on?
Je concluerai par un lien vers notre bugtracker, de la liste des rapports qui sont passés en statut "FIXED" (= corrigé) depuis janvier 2015: 75 bugs à ce jour
Et encore, c'est sans compter les bugs découverts en interne et corrigés sans qu'il y ait eu un rapport de bug. Je compte donc, dans la seule année 2015, 459 commits dans GIMP master, 26 dans babl master, et 218 dans GEGL master. C'est sûr, les développeurs de GIMP n'en font vraiment pas une et "se fout[tent] de l'utilisateur".
D'ailleurs saviez-vous que lorsqu'un utilisateur rapporte un bug, en fait on va se moquer de lui derrière son dos et on rigole bien car on fait exprès de ne jamais corriger les bugs.
Non mais qu'est-ce qu'il faut pas lire!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Écrire du texte, "C'est tout con, mais c'est horripilant"
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 10.
Tout à fait. La gestion du texte est un très gros chantier sur lequel on aimerait tous venir un jour. C'est clairement un outil assez frustrant à de nombreux égards. Je suis le premier à être d'accord, et Aryeom ne dira pas le contraire non plus! Tous les autres dévs en sont conscients aussi car on en parle régulièrement (on en a encore parlé avec le mainteneur y a 2 mois lors de LGM 2015).
De manière général, le commentaire initial du fil liste plusieurs problèmes réels, connus et qu'on veut améliorer.
Par contre j'ai voulu répondre, mais j'ai abandonné. Le commentaire n'a clairement pas été fait pour initier un échange constructif, et je sens que toute réponse (celle-ci comprise probablement) ne m'apportera que des attaques ad-hominem. C'est donc mon premier et dernier message sur ce fil de discussion.
Par contre si y a d'autres questions ou commentaires intéressants, et même des critiques constructives, n'hésitez pas à créer un autre fil.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Question de n00b
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Entretien avec Jehan, développeur GIMP. Évalué à 6.
Benoît Sibaud a bien répondu avec des détails. Mais globalement ce que tu dis est juste aussi.
En gros, l'idée est de ne plus travailler avec des filtres temporellement mais avec un graphe (ou au moins une pile) de filtres. Tu ne modifies donc plus l'image avec ça, puis ça, puis ça. Puis tu dois tout annuler pour retirer juste le premier filtre. Tu as juste une image (qui reste toujours clean) et une pile de filtres au dessus. Et tu peux éditer tes filtres, les réordonner, en ajouter un, avant, après ou au milieu des filtres existants, etc.
L'historique n'a plus tellement de sens et n'est plus utile. Cette méthode de travailler est bien plus flexible.
Par contre, il y a certaines choses pour lesquelles l'historique a toujours du sens: tout ce qui est peinture ou assimilé.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Fréquence
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Émissions "Symbiose" de l'APRIL sur "Ici et Maintenant". Évalué à 2.
Oh et pour ceux qui ont une radio, tout simplement, c'est 95.2FM. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Gestion des indésirables ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Appel à financement pour le prochain RoundCube. Évalué à 4.
En général, les spams sont gérés au niveau du serveur. Roundcube est un client, qui certes s'installe sur un serveur (web), mais qui est à comparer à un client lourd installé sur l'ordi. Bien sûr, les clients lourds ont souvent un antispam (comme Thunderbird), mais ça ne vaut pas un antispam serveur parce que ça marche avec n'importe quel client! Tu lis tes emails depuis Thunderbird? Depuis ton tél? Depuis le webmail parfois? Ça marche toujours pareil. C'est d'autant plus important avec imap (je pense que l'antispam sur le client, c'est d'ailleurs un reliquat d'une époque où on téléchargeait tous les emails avec pop3, toujours sur le même ordi).
En outre avoir un antispam sur le webmail, ça signifierait du traitement antispam fait quand vous vous connectez à votre compte, donc alourdirait l'expérience webmail; alors que direct sur le serveur, le traitement se fait à l'arrivée de chaque email, 1 par 1. C'est beaucoup plus léger comme traitement. Imagine que tu t'es pas connecté sur ton compte email depuis une semaine, t'as reçu des centaines d'emails à traiter d'un seul coup. Maintenant multiplie ça par tes utilisateurs. Ça fait des périodes où y a pas de traitement (la nuit), et soudainement plein (le matin), et tout ça en plus fait par le serveur web (du code PHP — dans le cas de Roundcube — qui tourne au moment d'une requête). Ça pourrait aussi être traité côté client en javascript, mais dans ce cas là se pose le problème de sauver la base de données du filtre (bayésien en général).
Enfin voilà, perso je trouve que c'est bien mieux ainsi.
Par contre il existe plusieurs techniques bien connues pour gérer le spam (envoyer à une adresse email spécifique, simplement déplacer dans un répertoire, etc.) et il pourrait y avoir une option pour mapper un bouton "spam" (ou "not spam" selon contexte) à ces diverses actions, selon technique utilisée. Ça oui, je suis d'accord, ce serait cool et rendrait l'expérience plus transparente aux utilisateurs.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: perf ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 3.
Tout est possible. Faut ensuite voir le "coût", que ce soit le coût de développement, c'est à dire la complexité, le temps que cela va nous prendre à avoir une architecture convenable, mais aussi le coût additionnel du traitement, et donc notamment le temps additionnel et la mémoire utilisée, etc. Déjà que beaucoup se plaignent du fait que le non-destructif peut être plus lent (car à chaque changement de l'image ou d'opération, on doit potentiellement recalculer toutes les opérations "au dessus"), et qu'il va rapidement bouffer toute la mémoire, voire swapper, et devenir encore plus lent (cf. commentaire plus haut au sujet de Darktable)… Puis faut voir si ce coût vaut le coup en comparaison du gain.
Surtout qu'au début on parlait d'optimisation, maintenant on veut rendre le traitement encore plus parfait (donc lent en général). :-)
Déjà il faut bien noter que ce n'est commutable qu'avec certains types d'opérations. Par exemple si une opération changeait les pixels en fonction de leur position, cela ne serait pas la même chose de l'appliquer avant ou après rotation (exemple typique: utilisation d'une texture que l'on va mapper au dessus de l'image). C'est un travail assez important de bien cataloguer les opérations. Et l'utilisateur a peut-être choisi exprès d'appliquer telle opération sur les pixels avant ou après une rotation car il voulait tel rendu, ou tel autre. Il faut donc bien faire attention quand on réordonne. Pas tout ne peut l'être.
Mais oui, il y a des moyens d'optimiser un graphe et c'est un travail qui demande du temps pour le faire bien, en utilisant des connaissances mathématiques puis en les appliquant à la réalité de la représentation algorithmique. Et surtout ne pas changer le rendu désiré par l'artiste.
Non, mon exemple est un arbre. Pourquoi en faire une généralité?
On pourrait avoir une opération qui re-rentre dans un autre nœud. Par exemple ci-dessous,
op1rentrerait dansop2et re-rentrerait dansop3, ce qui est très pratique car cela évite d'avoir à recréer des nœuds qui recalculeraient des opérations que l'on a déjà calculées.On a ce genre de graphes tout le temps dans Blender. Je ne suis pas sûr si GEGL permet plusieurs sorties, mais si ce n'est pas le cas à l'heure actuelle, ce ne serait pas dur à implémenter; ensuite il faut juste adapter l'UI. Dans GIMP, certains semblent ne pas vouloir une UI trop complexe. Ce que je comprends tout à fait pour l'UI de base, du moment qu'on puisse aussi proposer une UI alternative pour gérer des graphes complexes. Enfin on verra cela quand nous commencerons à réfléchir sur une UI pour le non destructif dans GIMP.
Je reprends donc mon exemple. Supposons que l'on ait une rotation comme opération non destructive sur le Layer 2.
Et voilà!
Une opération n'a pas forcément 2 entrées. Elle peut en avoir 1, 2… et même zéro! (par exemple une opération de chargement d'image n'a pas besoin d'entrée. Elle a juste un paramètre pour indiquer un chemin d'accès au fichier, ou même des opérations qui génèrent de l'aléatoire). De même pour les sorties.
Je ne peux pas vraiment répondre à ce type de questions. Comme je disais, je ne suis pas du tout expert en algorithmique du traitement d'image. J'ai fait des maths à niveau correct et de l'algorithmique à la fac, mais c'était y a des années et je ne lis pas de livres de maths le soir avant de me coucher. Donc oui je comprends comment marchent les divers algorithmes quand je lis du code. Par contre non je ne pourrai pas comparer les algorithmes. Enfin si, peut-être si je me mettais à lire beaucoup sur le sujet, puis à prendre un crayon et difficilement essayer de me remettre à résoudre des problèmes mathématiques, mais je n'en ressens pas le besoin. :P
On a plusieurs dévs qui sont très calés sur ce genre de choses, et je leur fais confiance. De mon côté, je fais d'autres choses peut-être un peu plus terre à terre, mais bon, chacun son truc. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Il reste 41 heures pour ZeMarmot. Évalué à 2.
C'est très différent. Et nous avons beaucoup pensé à ce type de financement aussi, mais il ne correspondait pas à notre situation. Par contre, comme Creak le note, rien n'empêche d'utiliser Patreon (ou tout simplement de monter un système de financement mensuel sur le site) après coup, et on le fera peut-être.
Pourquoi Patreon n'était pas adapté? Car ça commence très bas. On dit aux gens qu'on va faire quelque chose et à chaque sortie (ou mois), on récupère le montant sponsorisé à ce jour. Or si c'est pour récupérer 100 € pour 1 mois de travail, autant faire tout bénévolement tout de suite. C'est acceptable quand on fait de la BD (même si 100 € la page par exemple reste faible, c'est moins ridicule que genre 100 € la minute d'animation, ce qui correspond à storyboard + 1440 dessins en HD). On voit bien que ceux dont les financements montent haut, c'est après pas mal de temps et qu'une certaine réputation s'est installée. Cela marche donc OK si on est déjà célèbre ou après beaucoup de temps, et surtout pour une seule personne (si on est 2, 3, 4, ça divise le financement de beaucoup). Et cela ne prend pas en compte le financement initial. Nous voulions voir avant de commencer notre projet si les gens nous suivraient.
Par contre, quand notre financement initial sera terminé, puisque nous avons passé notre premier palier, je pense que cela pourra être intéressant de compléter par un système de type Patreon, en effet.
Franchement nous éviterons autant que possible de mettre de la pub, que ce soit sur les vidéos (sur Youtube ou alors), sur nos sites, etc. Jusqu'alors je n'ai jamais mis la moindre pub sur la moindre de mes créations et je ne m'en porte que mieux. Pour moi cela pollue notre espace visuel. Et un bloqueur de pub, ce n'est pas la réponse selon moi. Ce n'est qu'un contournement. Moi, je rêve d'un monde sans pub, où il n'y a pas besoin de bloqueur de pub (cela n'arrivera probablement jamais, mais je ne souhaite pas être fataliste et contribuer pour autant à ce monde).
J'ai entendu des arguments, même non monétaires, notamment on m'a dit que les vidéos sans pub sur Youtube étaient dépriorisées par Google (une recherche va afficher des vidéos avec pub en haut en priorité). C'est triste, mais je trouve l'expérience des pubs sur Youtube tellement horrible et désagréable que je refuse à ce jour de le faire subir à ceux qui visionneront nos vidéos.
En outre, honnêtement je préfère de loin vivre de l'argent direct par des contributeurs qui veulent nous soutenir explicitement (à ce jour 313 personnes, dont nous ne connaissons pas la grande majorité, nous soutiennent; ça fait chaud au cœur, plus que de recevoir même 3 fois cet argent en échange de zombification publicitaire) que par les conglomérats de la pub qui ne sont que des parasites selon moi.
Et même si je sais que beaucoup de gens n'ont pas l'air d'être plus touchés que cela par la pub, j'espère tout de même au fond de moi que nos contributeurs s'en rendent compte (peut-être certains?) et nous soutiennent même davantage pour cela.
P.S.: c'est aussi un des trucs que j'apprécie sur LinuxFR. Les seuls "bandeaux de pub" qu'ils ont sont choisis et ciblés pour les projets amis et sont davantage du soutien explicite par LinuxFR à ces projets et un peu de mise en avant, non comparable à ces pubs horribles et impersonnelles qu'on a habituellement pour bouffer du "temps de cerveau disponible" en échange d'argent.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: perf ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 5.
En imagerie informatique, les données sont discrètes. Dans la "nature", une image est continue. Elle n'est pas une succession de point. Donc une vraie rotation physique n’abîme pas une image (tu as une photo posée sur la table, tu la tournes, elle ne perd pas en qualité! :P).
Mais dans une représentation bitmap, une image est une matrice limitée de point. Donc à part si tu fais une rotation qui garde une matrice (90°, 180°, 270°…), tes pixels d'origine se retrouvent entre 2 points de la matrice (les nouveaux pixels).
Exemple la matrice de pixels:
1 2
3 4
… après rotation à 45° devient:
Ce n'est plus une matrice, et il faut donc calculer les nouveaux pixels qui formeront l'image après rotation, à partir des pixels d'origine. Il y a pour cela divers algorithmes dit d'interpolation (regarde les paramètres de l'outil "rotation" de GIMP, tu peux voir que tu peux choisir le type d'interpolation, ce qui est bien sûr plutôt pour les utilisateurs avancés). Une interpolation possible pourrait être tout simplement de faire la moyenne pondérée entre les pixels qui chevauchent le nouveau pixel (c'est en gros l'interpolation linéaire quoi). Il y a d'autres algorithmes moins naïfs (ce qui ne veut pas dire que celui-ci est mauvais pour autant!), c'était juste pour prendre un exemple simple.
Dans l'UI, ça ressemble à une liste.
Mais c'est en fait un graphe où à chaque nœud, on a rentré 2 calques, ce qui a produit un résultat, que l'on va "compositer" avec un autre calque.
Ainsi la liste de calque:
"Layer 1" (Normal)
"Layer 2" (Multiply)
"Layer 3"
C'est un graphe:
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Docker et snappy
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal XDG apps testable sous Fedora. Évalué à 8.
La différence, c'est que Docker, c'est pour les serveurs, alors que là c'est un système de packaging utilisateur. On veut donc qu'un programme s'intègre à son environnement. Comme j'explique plus haut, on veut notamment lier les formats de fichier à une application (double clique sur un .xcf: ça doit ouvrir GIMP); on veut aussi mettre à jour le menu utilisateur automatiquement; on veut peut-être aussi fournir des infos aux autres logiciels pour interagir entre logiciels; on veut mettre l'icône de l'application accessible aux divers logiciels du bureau qui pourraient en avoir besoin, etc.
La partie sandboxing n'est pas pour moi la fonctionnalité cible. C'est uniquement une nécessité. Puisque ce sont des logiciels qui pourront être téléchargés d'un peu n'importe où, il faut pouvoir protéger un minimum l'utilisateur (même si on ne peut le protéger de lui-même et donc les risques existent toujours) et ses données.
Pareil pour les dépendances. Ce n'est pas à voir comme un but. Je suis certain que les dévs préféreraient ne pas en avoir besoin. Mais sans cela, un paquetage sera lié à une distribution en particulier (puisque chaque distrib a potentiellement des versions de lib différentes).
Le besoin, c'est simplement qu'il est très dur de télécharger un programme pour Linux quand il n'est pas packagé par sa distribution, ou seulement dans une version ancienne/bugguée. Et les rares fois où certains projets proposent quelques choses (en général juste une archive à décompresser quelque part), ça s'intègre absolument pas à votre bureau. Et s'ils proposent un paquetage de distrib, c'est limité à certaines distrib (.rpm, .deb, et encore pas toutes les distribs avec le même système de paquetage ne peuvent installer les mêmes paquets si certains chemins d'accès ou des noms de dépendances diffèrent par exemple…), et on a besoin des droits root pour installer.
C'est dommage qu'il n'existe aucun standard pour cela, et c'est ce qu'ils sont en train de créer.
D'ailleurs plusieurs font la remarque que c'est du GNOME, mais comme je le lis, même si cela vient de dévs GNOME au départ, c'est un projet de standard (XDG) qui devra fonctionner sous tous les environnements de bureau.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: perf ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 6. Dernière modification le 18 juin 2015 à 18:13.
C'est bien ce que je dis. Il faut créer de nouvelles sous-classes de nœud et y mettre tous les nœuds qu'on arrive à identifier d'une certaine catégorie, puis réarchitecturer une bonne partie de la lib pour mettre à profit les propriétés de ces types de nœuds, etc. C'est du boulot, et ce
il suffitme chagrine beaucoup. Pourquoi quelqu'un d'extérieur à un projet a souvent cette idée que les choses sont si simples à faire?Ensuite je le redis: on accueille les bonnes volontés! Si tu penses avoir les idées et les capacités pour optimiser GEGL, on sera tous très heureux.
La commutation sur pas mal de type de nœud est vraie théoriquement, pas dans la pratique.
Imagine une fonction f() qui transforme un pixel gris entre [0; 0.5[ en noir, et un pixel gris entre [0.5; 1] en blanc (on va travailler sur un canal unique).
Tu as au départ une image de 4 pixels (2x2) avec un pixel sur 2 noir puis blanc:
N B
B N
Applique maintenant f(). L'image est inchangée. Applique maintenant une rotation de 45°. Bon il existe divers algorithmes de rotation, donc on va juste supposer qu'on utilise un algorithme qui fait une moyenne entre les pixels adjacents.
Résultat final: une image totalement grise uniformément.
Commute maintenant les opérations. Fait d'abord la rotation (tous les pixels deviennent gris), puis applique f().
Résultat: tous les pixels sont blancs!
Nous avons 2 images totalement différentes au final. Théoriquement (mathématiquement) tu as raison, on peut réordonner ces opérations. Dans la réalité de l'imagerie informatique, ce n'est plus vrai.
En plus, je parle même pas du cas où f() utiliserait la position du pixel comme donnée d'entrée (par exemple pour effectuer un traitement en mixant avec une image de
pattern…), et déplacer les pixels avant ou après modifierait donc complètement le rendu aussi.Ben voilà, tu as compris. On ne peut pas juste optimiser naïvement comme les exemples proposés plus haut. C'est beaucoup plus compliqués que juste des mathématiques (celles ci sont la base, mais il faut ensuite pouvoir les appliquer dans la réalité des représentations informatiques).
Comment tu fais pour du compositing sans graphe? Une liste d'opérations ne permet que de modifier une image, mais dans la réalité, on (= tous ceux qui utilisent ce genre de logiciels de dessin et traitement d'image) mélange des dizaines d'images les unes aux autres. On pourrait même avoir des opérations qui rentre dans un noeud et re-rentre dans un autre nœud, pourquoi pas.
Enfin bon, de toutes façons, même sans aller plus loin, GIMP serait bien triste si on pouvait plus avoir de compositing (= adieu les calques!).
Je sais pas si tu as déjà testé l'éditeur de Node de Blender, mais tu pourrais presque plus rien y faire s'il s'agissait juste d'un système linéaire, et il perdrait soudainement beaucoup de son intérêt (alors qu'à l'inverse, à l'heure actuelle, c'est un des gros points forts de Blender).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Perte des avantage de mutualisation
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal XDG apps testable sous Fedora. Évalué à 10.
Perso j'attends ces technologies avec impatience.
Par contre ce n'est pas du tout fait pour remplacer les systèmes de packaging des distribs Linux (et j'espère sincèrement que personne n'aura cette idée saugrenue).
Sur mon ordi, 99% (doigt mouillé) sont des logiciels installés par le packaging de ma distrib. Par exemple j'en ai rien à faire que Firefox soit un chouille en retard en version. Pareil pour mes lecteurs vidéo/audio, libreoffice, ou de manière générale la plupart des logiciels que j'utilise et qui me conviennent très bien. Par contre il existe 2 cas où ça me gêne:
1/ Certains programmes ont un problème qui me gêne depuis longtemps (voire une régression, bug qui n'existait pas avant et apparu lors d'une mise à jour). Or en cherchant des infos, je me rends compte que ce problème est connu et corrigé par la version stable en download. Franchement dans ce cas, attendre que la distrib mette à jour son paquet, ce qui prend souvent du temps (surtout pour les petits logiciels) me fait chier.
2/ Il existe de rares cas où avoir les dernières fonctionnalités upstream est important, en général c'est en rapport avec ses activités. Typiquement pour moi: Blender, GIMP, Scribus… ont des fonctionnalités qu'on va vraiment utiliser dès qu'on les obtient. Je ne veux pas attendre je-ne-sais-combien de mois non plus.
Or sous GNU/Linux, les téléchargements sur site, c'est en général soit du source-seulement, soit des archives à décompresser, et à mettre quelque part. Un utilisateur de base ne sera pas capable de faire en sorte que les fichiers correspondants lancent la version téléchargée (par exemple, double cliquer sur un .blend -> cela lance Blender installé par la distrib, pas celui téléchargé). Vous n'aurez pas le programme dans le menu (donc la plupart du temps, les utilisateurs gardent le dossier décompressé sur le bureau pour accès "plus ou moins simple et rapide"). Etc. C'est chiant, sale (l'installation) et pas du tout intégré à votre environnement.
Or ce type de solution a pour but d'installer des apps en mode utilisateur mais de manière propre. Vous pourrez cliquer sur des fichiers qui ouvriront votre application (installation des fichiers desktop); vos menus seront mis à jour avec la nouvelle app, sa description et son icône, dans la catégorie adéquate; vous n'avez pas besoin d'encombrer votre bureau de répertoires, etc. Tout comme une app installée par le système de paquetage de votre distrib, intégrée et propre, mais en mode utilisateur et avec une version récente, avec des droits réduits (car installé depuis une source moins sûre) à donner au fur et à mesure à l'application!
Franchement je trouve cela extrêmement gênant que tous les logiciels Libres — si on veut la version upstream — sont finalement bien plus simples à installer sous Win et OSX que sous Linux.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: perf ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 4.
Bien sûr qu'on en est capable techniquement (comme un peu tout). Je parle de GIMP en particulier et j'entendais "ce qu'on pourrait faire", c'était pas une question de savoir si les langages ont cette capacité (quand même, heureusement qu'ils l'ont!).
Aussi ce que je disais, c'est surtout qu'il faut adapter l'architecture du code. À lire certains commentaires, on a l'impression que c'est trop facile, "il suffit d'optimiser" (yakafokon). Alors que pour le permettre, il faut identifier les cas possibles d'optimisation (comme je disais plus haut, des suites d'opérations matricielles, des ops sur des pixels si et seulement si elles ne sont pas dépendantes d'autres pixels de l'image, etc.), puis éventuellement adapter l'architecture du programme pour rendre ces optimisations faisables. Et ainsi de suite.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: deux salaires à plein temps sur la base du SMIC
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Campagne d'adhésion pour Libervia (projet « Salut à Toi ») : soutenez-nous, c'est le moment !. Évalué à 7.
Qu'est-ce que c'est sinon que du financement participatif?
Je pense que ce que tu voulais dire est: pourquoi ne pas avoir essayé de le faire avec une des plateformes commerciales les plus connues? Je pense que la raison est qu'ils veulent déjà ne pas donner de limite de temps, en outre ils veulent permettre des financements de type "abonnement régulier" (ce que d'autres plateformes font aussi maintenant ceci dit)… Aussi probablement n'aiment-ils pas donner un pourcentage à la plateforme, ou ils n'aiment pas ce que représentent ces entreprises? Je ne sais pas… Mais toujours est-il qu'il n'y a pas une seule façon de faire et il s'agit bien d'un financement participatif.
Pour mes projets, j'ai moi-même longuement réfléchi et j'ai choisi des plateformes existantes par facilité mais franchement à terme, je préférerais de loin héberger nos propres campagnes…
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Darktable et GEGL
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 6.
Salut,
Oui c'est bien ce que je dis dans la dépêche:
Or comme j'explique, leur tentative de port date de 2011 (cf. leur blog post), c'est à dire y a 4 ans, donc bien avant (2 voire 3 ans) que la bibliothèque GEGL ne commence à devenir vraiment utilisable (cad. pas trop lente). Et en outre, GIMP 2.10 n'est même pas encore sorti et surtout il n'aura même pas encore l'UI adaptée pour travailler en non-destructif. Donc clairement si Darktable décide de reprendre leur port GEGL, ce n'est pas pour demain. :-)
C'est pas grave, personne n'est pressé. Ce sont des choses qui se font avec le temps.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: perf ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 1.
Oui, GEGL est fait pour être extensible, et les graphes visibles de l'extérieur, avec beaucoup d'introspection. Donc oui, on voit les détails du graphe de l'extérieur, on peut même récupérer automatiquement la description des opérations, la liste des paramètres et leur description, etc. Tout est fait pour l'introspection et la visibilité du graphe.
Mais pour faire de l'optimisation, faut connaître l'algorithme exact. Sinon tu te remets à réimplémenter tous les algorithmes par du code extérieur (et dans ce cas, pourquoi utiliser GEGL?) et surtout c'est de l'approximation. Optimiser, oui, mais uniquement si tu as exactement le même résultat (au pixel près) avec et sans l'approximation.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: perf ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 2. Dernière modification le 16 juin 2015 à 17:37.
Je ne comprends pas ce que tu veux dire… Comment est faite cette optimisation? Qui l'a fait si ce n'est pas GEGL? Quelle information utilise-t-il pour déterminer comment optimiser des nœuds sans en connaître le contenu?
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: perf ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GEGL 0.3.0 et babl 0.1.12 sont de sortie. Évalué à 7.
Je ne suis pas le mieux calé pour parler de GEGL. Aucun de mes patchs là-bas ne sont algorithmiques. J'y touche plus dans le cadre de problèmes rencontrés dans GIMP que pour GEGL même. Donc ma première réponse, c'est que je ne sais pas s'il fait la moindre optimisation pour réduire des opérations.
S'il ne fait pas déjà, je ne vois rien qui empêche de le faire à l'avenir. Ensuite il y a des cas plus simples que d'autres. Par exemple, il y a toute une série d'opérations qui sont matricielles (les transformations mathématiques: rotation, translation, réflexion, changement d'échelle…), et bon ça la multiplication de matrice, c'est pas compliqué! Si on a plusieurs opérations matricielles de ce style qui se suivent, on devrait être capable très simplement de les combiner en une seule de façon transparente (tout en gardant une visualisation multi-nœuds).
D'ailleurs c'est peut-être déjà fait, aucune idée!
Pour d'autres types d'opérations, j'imagine que ça dépend. Beaucoup de choses simples à faire pour un humain ne le sont pas pour un ordi (et vice-versa). Donc à part programmer des cas particuliers partout (possible aussi, et cela reste intéressant si certains cas particuliers sont des optimisations connus pour faire gagner énormément et difficilement automatisables autrement), ce qu'il faut, c'est réorganiser le code pour créer des schémas.
Par exemple, une opération qui traite chaque pixel l'un après l'autre, ce dont tu parles, si c'est entièrement codé comme une boucle de programmation, c'est dur à réduire (car un programme ne "comprend" pas son propre code!). Par contre, on devrait être capable de faire une sous-classe d'opération pour les opérations "pareil sur tous les pixels" où — au lieu de faire des boucles sur les pixels — on donne juste l'opération mathématique à appliquer sur le contenu d'un pixel. À ce moment là, le programme sera capable d'enchaîner les opérations dans la même boucle, ce qui est déjà une bonne optimisation.
Ensuite il faut faire attention à ne pas introduire d'erreurs. Dans notre cas précis, cela fonctionne si les seules données extérieures sont indépendantes de l'image. Si par exemple, la modification d'un pixel utilise les données d'autres pixels, alors ce n'est plus possible (du moins plus aussi facile). En effet, la seconde opération utiliserait le pixel après modification par la première opération. Or si on exécute l'optimisation "2 opérations en une", elle n'aurait accès qu'au pixel avant modification par la première opération! On introduirait donc une erreur puisque le résultat serait différent.
Enfin voilà, tout est possible, mais faut bien y réfléchir et trouver l'architecture idéale.
Et dans tous les cas, il est conseillé de faire un programme qui marche bien avant de l'optimiser. Règle de base du bon programmeur. :-)
Ensuite y a pas de miracle. Le non-destructif a de gros avantages, mais ce n'est pas magique. Ça a son prix. La qualité a toujours son prix, c'est la raison pour laquelle dans beaucoup de workflow, il ne sert à rien d'en faire. C'est comme utiliser du jpg pour le web. Utiliser du png est théoriquement bien meilleur, mais dans 99% des cas, si l'usage est "web", alors on va exporter en jpg et de toutes façons personne (pas même soi-même) ne verra la différence. Par contre, quand on exporte pour travailler ailleurs, ou intégrer dans une vidéo, c'est du PNG.
Il faut savoir choisir les pratiques en fonction des besoins.
De manière générale travailler sur des données médias (son, et encore plus image), ça prend une place de dingue.
Pour ZeMarmot, nos ressources pour le teaser de 1 min font plusieurs GO de données! Notamment on travaille en HD avec des fichiers XCF qui peuvent dépasser 100 MB. Et encore on a des retours de gens qui travaillent dans des secteurs où leurs fichiers XCF font plusieurs GB! (ceux qui scannent des images à extrêmement haute résolution par exemple, ou des secteurs médicaux, scientifiques, etc.) Donc oui bien sûr, dans leur cas, rien qu'ouvrir l'image peut prendre toute la mémoire sur un ordi de base du supermarché.
Bon ces tailles de fous ne sont pas la majorité. Mais plusieurs centaines de MB par contre, c'est courant. Donc de nos jours, si tu travailles des images (photos, dessins…), avoir 8GB de RAM, c'est pas grand chose. Être à 16 ou même 32 GB, c'est pas du luxe. C'est inhérent même aux qualités et résolutions qu'on atteint maintenant avec l'imagerie (même amateur).
En conclusion: oui on peut probablement optimiser, et on le fera sûrement (développeurs recherchés! Si tu développes et souhaites ajouter le type d'optimisation dont on a parlé ici, tu es le bienvenu!). Mais faut pas non plus croire au miracle. Si tu charges des images de dizaines de Mégas par défaut (cas des images DSLR de nos jours), et que tu fais des dizaines d'opérations dessus, oui ça monte vite.
Faire du destructif est une possibilité et peut très bien être un choix valide. Tu perds en flexibilité et potentiellement en qualité du résultat final par contre.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Meilleures contributions LinuxFr.org : les primées de mai 2015. Évalué à 2.
Ahah! C'est donc cela! :-D
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Il reste 41 heures pour ZeMarmot. Évalué à 2.
Ok.
Je dois t'avouer qu'à ce jour, je n'ai jamais eu à payer quelqu'un (ni même moi-même). Et donc mes chiffres sont plutôt de l'extrapolation de ce que je lis et ce qu'on me dit.
Mais oui, ce sera plus proche du SMIC qu'autre chose, donc c'est bien de savoir que c'est plutôt dans les 31% de charges (quoiqu'honnêtement je préfèrerai donner de bonnes payes à tous avec de grosses charges que des petites sommes avec de petites charges!).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Merci!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Meilleures contributions LinuxFr.org : les primées de mai 2015. Évalué à 6.
Merci à LinuxFR et à Linux Magazine!
Par contre je sais pas qui choisit (la rédac de LinuxFR ou le magazine sponsor?), mais c'est assez marrant que Linux Magazine me récompense pour des sujets pour lesquels j'avais essayé de les contacter à plusieurs reprises et mes emails comme mes messages téléphoniques ont à chaque fois été ignorés. ;-(
J'aurais bien apprécié notamment avoir même juste un petit encart au sujet de notre film d'animation Libre, et fait avec des Logiciels Libres (ce qui je pense est complètement dans le sujet!) dans un de leurs magazines. Enfin bon, merci quand même. C'est juste une petite remarque, mais je leur en veux pas. :P
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bravo !!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Il reste 41 heures pour ZeMarmot. Évalué à 3.
:-)
Ceci dit, comme j'explique sur le journal, les contributions ont diminué beaucoup depuis 2 jours. Nous faisons aussi un peu moins de promotion car nous sommes épuisés, c'est probablement aussi dû à cela. Mais il faut savoir que les 100% sont loin d'être suffisants pour terminer le projet (comme on l'explique dans la page de crowdfunding, c'était notre première étape pour pouvoir démarrer!). Donc j'en appelle toujours aux personnes intéressées. Si vous voulez voir ce projet mené à bout, il est tout à fait encouragé de continuer à le financer!
Toute somme additionnelle nous permettra de travailler plus longtemps et donc de repousser la prochaine campagne de financement pour pouvoir continuer le projet, et ainsi d'éviter de reperdre trop de temps à chaque fois!
En tous les cas, oui maintenant on va commencer, travailler quelques mois, puis nous présenterons notre résultat. Avec les fonds actuels, c'est presque du bénévolat (mais c'est pas grave, c'est un projet perso, et on y croit sur le long terme!), puisqu'il faut considérer les charges (qui diminuent de moitié environ tout paiment humain), mais on produira du code et contributions aux LL, design et recherches pour le projet, et environ 1 scène de plusieurs minutes. Puis nous devrons relancer une campagne de financement avec ce premier jet, en espérant qu'il donnera envie aux gens de par le monde de voir la suite du film et/ou de donner plus pour créer et améliorer les logiciels libres.
C'est notre espoir: lancer une dynamique pour financer de l'Art Libre et de la contribution aux Logiciels Libres de création.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]