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 ]
Et en effet, Indiegogo nous a repoussé la date de fin. Nous ne savons pas du tout si c'est une pratique courante sur cette plateforme, et certains nous ont demandé comment on avait fait. Mais le fait est qu'on n'a rien fait. Ils nous ont contacté d'eux même sans qu'on demande rien, nous ont dit qu'ils ont remarqué que notre campagne avait du succès et nous ont proposé de repousser la date de fin. On a réfléchi, et on a dit oui.
En tous les cas, 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!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Nous venons d'atteindre les 101% de financement initial! Cela nous permettra de financer quelques minutes d'animation, un peu de développement de scénario, et un brin de développement logiciel… C'est le moment de devenir sérieux et de tenter plus qu'un film d'animation expérimental.
Prouvons au monde que le Logiciel Libre peut faire des merveilles, que l'Art Libre n'est pas une lubie de fou, et surtout créons un super film, avec une histoire recherchée, et pas juste une "blague" de 3 minutes.
Peut-on lever 15 000 € dans les prochaines 40 heures? Voire même 30 000€? Pourquoi pas!
C'est le moment d'exploser les réseaux sociaux avec des Marmottes partout! Faites passer le mot, contribuez. Ce n'est que le commencement!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Personne ne m'en a fait la remarque, mais je me suis rendu compte en rouvrant le fichier qu'Aryeom a utilisé la version de dév de GIMP (bien sûr!) et donc le XCF que j'ai fourni ne s'ouvre pas avec GIMP 2.8 (comme expliqué dans la news GIMP 2.10 en prépa, y a plein de nouvelles fonctionnalités, dont une bien meilleure compression, qui explique une montée de version de XCF). Voilà, si quelqu'un essaie d'ouvrir le fichier et que ça ne marche pas, ce n'est pas le XCF qui est cassé, c'est juste que vous devez utiliser la version de dév (ou demandez moi, et je le resauverai avec une version compatible 2.8).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
(il fût un moment où l'image n'était pas libre, de souvenir en -NC)
Ah celle d'avant était en NC?
En tous cas, comme je disais en contribuant l'image courante, même après la fin du financement, vous êtes les bienvenus pour la garder (au contraire même, Aryeom serait très heureuse si son image reste un long moment ici!).
Vous avez le XCF, donc vous pouvez aussi faire très facilement après coup une version qui ne garde que Tux et GNU si vous le souhaitez (bien que si vous gardez Marmotte aussi, comme un beau symbole de l'Art Libre, nous en serions très heureux aussi!).
En plus c'est une image relax, et ça c'est cool! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Aussi je suis en contact avec Konstantin depuis un mois. Il est intéressé par mon logiciel custom de gestion de projet d'animation et me propose d'y participer. Pour l'instant on n'a pas eu le temps de beaucoup en discuter en détail (un peu tout de même), car je suis à fond sur le financement de ZeMarmot (honnêtement je préférerais passer mon temps à coder et discuter design du logiciel avec Konstantin ou d'autres ceci dit!).
Ça fait d'autres contributions potentielles du projet Morevna, mais bon rien n'est encore dans le marbre.
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 ]
[^] # Re: 40 heures ?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Il reste 44 heures pour ZeMarmot. Évalué à 4.
Merci pour la mise à jour!
Et en effet, Indiegogo nous a repoussé la date de fin. Nous ne savons pas du tout si c'est une pratique courante sur cette plateforme, et certains nous ont demandé comment on avait fait. Mais le fait est qu'on n'a rien fait. Ils nous ont contacté d'eux même sans qu'on demande rien, nous ont dit qu'ils ont remarqué que notre campagne avait du succès et nous ont proposé de repousser la date de fin. On a réfléchi, et on a dit oui.
En tous les cas, 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!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: 101 %!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Il reste 41 heures pour ZeMarmot. Évalué à 9.
Et comme une bonne nouvelle ne vient pas seule, Indiegogo nous a proposé d'étendre la campagne jusqu'à la fin du mois grâce à son succès! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# 101 %!
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Il reste 41 heures pour ZeMarmot. Évalué à 10.
Nous venons d'atteindre les 101% de financement initial! Cela nous permettra de financer quelques minutes d'animation, un peu de développement de scénario, et un brin de développement logiciel… C'est le moment de devenir sérieux et de tenter plus qu'un film d'animation expérimental.
Prouvons au monde que le Logiciel Libre peut faire des merveilles, que l'Art Libre n'est pas une lubie de fou, et surtout créons un super film, avec une histoire recherchée, et pas juste une "blague" de 3 minutes.
Peut-on lever 15 000 € dans les prochaines 40 heures? Voire même 30 000€? Pourquoi pas!
C'est le moment d'exploser les réseaux sociaux avec des Marmottes partout! Faites passer le mot, contribuez. Ce n'est que le commencement!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Merci pour le logo
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Financement collaboratif du film d'animation Libre ZeMarmot. Évalué à 2.
Salut,
Personne ne m'en a fait la remarque, mais je me suis rendu compte en rouvrant le fichier qu'Aryeom a utilisé la version de dév de GIMP (bien sûr!) et donc le XCF que j'ai fourni ne s'ouvre pas avec GIMP 2.8 (comme expliqué dans la news GIMP 2.10 en prépa, y a plein de nouvelles fonctionnalités, dont une bien meilleure compression, qui explique une montée de version de XCF). Voilà, si quelqu'un essaie d'ouvrir le fichier et que ça ne marche pas, ce n'est pas le XCF qui est cassé, c'est juste que vous devez utiliser la version de dév (ou demandez moi, et je le resauverai avec une version compatible 2.8).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Toujours 100% open source ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Quoi de neuf côté LinuxFr.org. Évalué à 4.
Ah celle d'avant était en NC?
En tous cas, comme je disais en contribuant l'image courante, même après la fin du financement, vous êtes les bienvenus pour la garder (au contraire même, Aryeom serait très heureuse si son image reste un long moment ici!).
Vous avez le XCF, donc vous pouvez aussi faire très facilement après coup une version qui ne garde que Tux et GNU si vous le souhaitez (bien que si vous gardez Marmotte aussi, comme un beau symbole de l'Art Libre, nous en serions très heureux aussi!).
En plus c'est une image relax, et ça c'est cool! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Updates
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche 2015, l'année du cinéma libre ?. Évalué à 2.
Aussi je suis en contact avec Konstantin depuis un mois. Il est intéressé par mon logiciel custom de gestion de projet d'animation et me propose d'y participer. Pour l'instant on n'a pas eu le temps de beaucoup en discuter en détail (un peu tout de même), car je suis à fond sur le financement de ZeMarmot (honnêtement je préférerais passer mon temps à coder et discuter design du logiciel avec Konstantin ou d'autres ceci dit!).
Ça fait d'autres contributions potentielles du projet Morevna, mais bon rien n'est encore dans le marbre.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]