Journal GIMP ça déchire

Posté par (page perso) . Licence CC by-sa
119
11
oct.
2013

GIMP c'est le genre de logiciel que j'ai toujours voulu apprendre sans jamais en prendre le temps (je ne fais pas tant de photos que ça); mais au moment où j'en avais besoin j'avais toujours un mal fou à faire ce que je voulais par méconnaissance.

Suite à cette dépêche j'ai acheté le livre de Dimitri Robert pour enfin apprendre correctement les bases (jusqu'ici je savais à peu près m'en servir, mais mal).

De cette façon j'ai enfin compris pourquoi mes déplacements ne fonctionnaient jamais comme je voulais (par défaut ça déplace le calque visible et non celui sélectionné), que les sélections c'était des niveaux de gris et non juste un booléen, que le masque rapide c'est génial, que l'outil d'extraction de premier plan que j'avais vu en vidéo il y a longtemps était un outil de base désormais, qu'on pouvait se déplacer dans l'image en cliquant sur la petite icône en bas à droite, etc. Bref, j'ai enfin appris à m'en servir, merci à l'auteur pour ce livre simple et efficace.

Du coup dans mon élan je me suis mis à suivre des tutos sur le net, à apprendre enfin à me servir des courbes de couleurs, à détourer des cheveux grâce à elles.

Et là j'ai découvert des trucs magiques, comme le plugin resynthesizer qui permet de faire disparaître en un clin d'œil des morceaux d'une image (voir ce tuto, attention le menu s'appelle désormais Filtres/Améliorations/Heal selection; ça marche aussi avec Filtre/Mappage/Resynthesize, mais moins bien pour supprimer un élément).

Et là je viens de voir la vidéo des dernières modifs du GSOC, la déformation à N points (désolé pour le lien vers ce site, c'est le lien pointé sur le site officiel de GIMP, je n'y peux rien). Et là je dois dire que même si je suis développeur et que je comprends les grandes lignes de ce qu'il se passe derrière, c'est impressionnant !

Bref, GIMP est un super outil, et ça vaut le coup de prendre le temps de s'y mettre, ne serait-ce que pour s'amuser.

Prochaine étape: Blender :)

P.-S.: et n'hésitez pas à partager des astuces/tutos intéressants sur le sujet en commentaire…

  • # Ça donne envie

    Posté par (page perso) . Évalué à 8.

    C'est amusant ce journal.

    Je me fais la réflexion qu'il faut que je creuse un peu Gimp depuis des années, sans prendre le temps de le faire.
    Je suppose que je ne suis pas le seul, quand je vois la note (24 au moment où j'écris)
    Pourtant, pas un seul commentaire. Il faut dire que sauf à avoir lu le livre, on peut difficilement avoir une opinion.

    Merci tout de même de m'avoir redonné envie de me plonger dans Gimp.

    • [^] # Re: Ça donne envie

      Posté par (page perso) . Évalué à 7.

      Peut être qu'un probleme de gimp c'est que sa relative non-intuitivité n'est pas compensée par les tutoriaux disponibles, en gros ça manque un peu de tutoriaux attrayants et à jour. Pour m'être recemment interessé à Blender, j'ai été impressionné par le foisonnement de tutos vidéo, qui expliquent comment faire ci ou ça. Je ne suis généralement pas fan de tuto videos, mais je trouve que pour blender ça marche beaucoup mieux qu'une vieille page html. Et on n'a aucune difficulté à trouver des tutoriaux "à jour" , on n'est pas obligé de se farcir des tutos obsoletes qui montrent une vieille version.

      • [^] # Re: Ça donne envie

        Posté par . Évalué à 1.

        Un peu hors sujet, mais quel logiciel libre pour faire de jolis tutos video ?

        • [^] # Re: Ça donne envie

          Posté par . Évalué à 2.

          Le seul que je connaisse et utilise de temps à autre: Kazam screencaster, GNU GPLv3
          https://launchpad.net/kazam (PPA et .tar.gz disponibles)

          L'acacia acajou de l'académie acoustique est acquitté de ses acrobaties. Tout le reste prend "acc".

          • [^] # Re: Ça donne envie

            Posté par (page perso) . Évalué à 1.

            J'en ai essayé pas mal parce qu'y en a beaucoup qui sont dans les dépôts de distribution mais qui ne marchent tout simplement pas.

            Si je me plante pas, pour cette vidéo, j'ai utilisé Kazam sur une partie et FDesktopRecorder sur une autre:
            http://youtu.be/osSiETyae5c
            Donc je les recommande. Ils marchent bien.

            Par contre RecordMyDesktop, je n'ai jamais réussi à rien en tirer. Déjà la vidéo est en général tout simplement dégueulasse, avec plein d'artefacts. Inutilisable en un mot. Et aussi il crashe tout le temps (j'ai encore la mauvaise expérience d'un atelier dans mon emploi précédent que j'enregistrai, et à la fin de l'atelier, je me suis rendu compte que RecordMyDesktop avait crashé au milieu!).

            Par contre la guerre libav/ffmpeg est vraiment un désastre. J'aimerais vraiment qu'ils se décident à clairement renommer l'un des deux parce que ces derniers temps, j'ai croisé et patché des bugs dans plein de logiciels à cause d'incompatibilités.
            Le problème est qu'ils ont le même nom, réutilisent même les noms d'outil de l'autre projet (en les disant dépréciés, mais en s'emparant du spot quand même), mais que les uns les autres intègrent de subtiles différences et incompatibilités un peu partout dans l'API.
            Maintenant dès qu'un logiciel utilise libav, je me mords les doigts pendant la compilation parce que les chances d'erreur pendant compilation ou link sont démultipliés selon ce que les dévs utilisent eux-même.
            Je parle de ça parce que j'ai eu plusieurs problèmes notamment en compilant des logiciels de screencast (par exemple pour compiler FDesktopRecorder sur ma Linux Mint).

            • [^] # Re: Ça donne envie

              Posté par (page perso) . Évalué à 4.

              Exactement, ma procédure de screencast :

              • RecordMyDesktop (produit des rushes en .ogv)
              • PiTiVi (pour le montage, les écrans de titre, etc, c'est rapide - et modérément buggé - mais kdenlive me manque parfois)
              • SubtitleEditor (pour les sous-titres)
              • Avidemux - now that's a website ;) (en ligne de commande, avec un gros config.js pour gérer les cibles d'encodage, les sous-titres incrustés oui / non, les formats, etc)
              • [^] # Re: Ça donne envie

                Posté par (page perso) . Évalué à 5.

                Vous avez quelque chose contre un simple ffmpeg ou vlc ?

                • [^] # Re: Ça donne envie

                  Posté par (page perso) . Évalué à 2. Dernière modification le 11/10/13 à 17:36.

                  Heu, non. Mais que je sache, ni l'un ni l'autre ne fait le montage, ou les sous-titres..?

                  • [^] # Re: Ça donne envie

                    Posté par (page perso) . Évalué à 4.

                    Non, mais pour capturer l'écran avant de travailler tout ça, c'est suffisant non ?

                    D'ailleurs si, VLC peut insérer une piste de sous-titres je pense, et ffmpeg peut certainement le faire, mais ils ne sont pas des éditeurs de sous-titres, pour ça il faudrait un autre outil.

                    • [^] # Re: Ça donne envie

                      Posté par (page perso) . Évalué à 4.

                      Pour info j'ai réalisé les trois vidéos qui sont sur cet article avec ffmpeg, je ne sais plus quel éditeur de sous-titre, et mkvtoolnix pour assembler la capture et les sous-titres.

                      • [^] # Re: Ça donne envie

                        Posté par (page perso) . Évalué à 2.

                        Salut,

                        J'aime les logiciels console, et j'utilise ffmpeg à l'occasion pour réencoder des vidéos, par exemple. Mais c'est vrai que des fois, je veux pas me faire chier et j'aime bien cliquer sur un bouton, surtout pour des trucs aussi chiants qu'enregistrer des écrans.

                        Ceci dit, les GUIs sont pratiques sur d'autres aspects aussi. Par exemple pour pouvoir ajouter un décompte. Tu vas me dire qu'on peut juste couper les premières secondes de vidéo, mais des fois, tu fais une vidéo, et basta. T'as pas envie de retoucher, quand c'est pas pour l'art.

                        Et ffmpeg permet-il aisément de n'enregistrer qu'une fenêtre sélectionnée (comme dans ma vidéo) ou qu'une zone de l'écran sélectionnée à la souris? Ou faut-il faire un crop dans un NLE après? Ça aussi par exemple, ce sont des détails, mais c'est toujours ça de gagné quand on veut pas se faire chier. Si je fais une vidéo pour montrer un unique programme, j'ai pas vraiment envie de montrer ma barre des tâches, ou bien les évènements du desktop quand on m'envoie un message par IM, etc. Et les GUIs permettent de sélectionner ainsi juste ce qu'on veut montrer.

        • [^] # Re: Ça donne envie

          Posté par (page perso) . Évalué à 1.

          RecordMyDesktop. Sans les mains.

        • [^] # Re: Ça donne envie

          Posté par (page perso) . Évalué à 2.

          Pour mes vidéos sur SàT j'utilise ffmpeg, c'est le seul qui fonctionnait correctement sans saccade sur ma machine, et qui produisait un bon résultat.

        • [^] # Re: Ça donne envie

          Posté par (page perso) . Évalué à 2.

          Pas vraiment « vidéo », mais pour faire ce genre de tuto, il y a maintenant Dahu : http://dahuapp.github.io/ (très inspiré de Wink, pour ceux qui connaissent)

          C'est encore très jeune, pas bien fini, mais ça commence à être fonctionnel. À la base c'est un projet que j'ai fait coder par mes étudiants, et je continue à coder un peu dessus.

          (Sur cet exemple en particulier, l'approche vidéo est supérieure, pour avoir les belles animations ceci dit).

        • [^] # Re: Ça donne envie

          Posté par (page perso) . Évalué à 3.

          Pour information, pour bon nombre de captures dont les « animées » (celles montrant plusieurs étapes successives d'une manipulation) que j'ai réalisées pour le livre, j'ai utilisé :

          • GtkRecordmydesktop pendant que je réalisais l'opération
          • VLC pour jouer la vidéo et faire des captures d'écran aux moments choisis
          • GIMP pour assembler les captures choisies (merci l'outil d'alignement de calques)
          • Shutter pour ajouter des pastilles avec des numéros (j'aurais pu le faire avec GIMP mais c'est tellement facile avec Shutter)

          Le gros avantage de Recordmydesktop est de capturer les bons pointeurs de souris, et comme dans GIMP il y en a une palanquée… Après, forcément, ça donne envie de faire des tutos vidéo comme celui-ci : http://libresavous.com/doc/gimp-detourage-ciseaux-intelligents/

  • # Blender

    Posté par (page perso) . Évalué à 2.

    Il me semble que dans une autre vie tu as eu droit à une formation Blender… :)
    Mais le problème c'est que son IHM a beaucoup changé depuis quelques années (pour le plus grand bien), et que quand on en a pas fait depuis longtemps le retour peut être difficile.

    Sinon, tu as l'intention de mettre de la 3D dans SàT, ou c'est pour autre chose ?

    • [^] # Re: Blender

      Posté par (page perso) . Évalué à 2.

      Oh, la seule formation Blender que j'ai eu (mais que je n'ai malheureusement pas suivi assidûment à l'époque), c'était effectivement dans une autre vie (fort fort lointaine) dans le sud, par un collègue, ce serait donc toi ? Si oui, où en es tu de ton jeu qui avait l'air très prometteur ?

      En fait ma vie a beaucoup changé ces derniers temps (en bien !), et du coup j'arrive un peu mieux à m'organiser pour faire ça.

      Autant GIMP peut clairement me servir pour SàT (icônes, tutos, etc), autant Blender c'est juste pour le plaisir (quoique ses possibilités de montage peuvent peut-être être utiles pour des démos vidéo). Je viens d'acheter le livre « la 3D libre avec Blender 2.6 » qui est plus conséquent que celui sur GIMP :). On verra si j'aurai le courage de le lire jusqu'au bout.

      • [^] # Re: Blender

        Posté par (page perso) . Évalué à 2.

        Mon précédant jeu est en "pause" ; le choix de notre moteur 3D (JME) s'est avéré mauvais à l'usage ; ça a beaucoup ralenti le développement, et la motivation est partie. Mais j'ai attaqué un jeu un peu moins ambitieux depuis (avec Ogre), dans lequel je peux réutiliser en grande partie mes assets ; je vais essayer d'avancer substantiellement pendant mes vacances.

        Autant GIMP peut clairement me servir pour SàT (icônes, tutos, etc), autant Blender c'est juste pour le plaisir

        Il y a quelques années j'avais utilisé Blender pour faire des icônes avec un rendu assez réaliste pour un prototype client, et ça marchait plutôt bien. Avec un peu d'imagination ça peut être un outil très utile pour de la 2D ; on pourrait aussi imaginer des avatars sous la forme de sprites animés etc….

  • # Des beaux plug-ins

    Posté par (page perso) . Évalué à 10. Dernière modification le 11/10/13 à 10:47.

    Un des gros intérêts de GIMP est notamment son système de plug-ins, qui permet à des développeurs extérieurs au projet de proposer des extensions plus ou moins utiles (comme 'resynthetizer' que tu cites).
    Si j'étais un bon vendeur, je te conseillerais notamment de jeter un oeil au super plug-in G'MIC, développé par chez nous, mais malheureusement je n'ai pas ce talent pour refourguer des liens en toute situation :)

    • [^] # Re: Des beaux plug-ins

      Posté par (page perso) . Évalué à 2.

      gimp-gmic fait partie des paquets installés sur ma Debian sid ;)

      Faudra que j'y jette un œil plus en détails…

    • [^] # Re: Des beaux plug-ins

      Posté par (page perso) . Évalué à 2.

      G'MIC fait des trucs supers mais son intégration à GIMP n'est pas géniale. On se retrouve avec deux ensembles de filtres dans deux interfaces différentes : les filtres par défaut de GIMP et ceux listés dans la boîte de dialogue de l'effet G'MIC. J'aurais préféré avoir les filtres G'MIC éparpillés dans les menus existants et dans les bonnes catégories.

      • [^] # Re: Des beaux plug-ins

        Posté par (page perso) . Évalué à 3.

        C'est probablement ce qu'on va essayer de faire quand on va essayer de mieux s'intégrer à GEGL (si on le fait un jour), mais ce n'est pas évident. Et on risque de perdre un aspect très important du plug-in actuel, qui est sa possibilité de mise à jour automatique des filtres.
        Actuellement, lorsque l'on ajoute un filtre à G'MIC, il suffit pour les utilisateurs d'appuyer sur un bouton 'refresh' pour le faire apparaitre dans la liste existante : pas de réinstallation du plug-in, rien à faire, c'est facile. Avec une dissémination des filtres dans les menus, ça va être une autre paire de manches.

        • [^] # Re: Des beaux plug-ins

          Posté par (page perso) . Évalué à 4.

          Je prévois probablement de travailler sur un système de gestion de plugin. Si le projet va au bout (pas commencé le moindre code, mais j'ai déjà commencé à gribouiller des idées et à regarder à droite à gauche ce que font les autres, comme Mozilla, etc.), on devrait pouvoir installer/désinstaller facilement avec une liste à jour, et surtout les mises-à-jour devraient être automatiques aussi. Comme dans Firefox quoi.

          Sauf que ce sera fait de manière générique pour tous les plugins, y aura plus besoin de bidouiller dans ton coin (ce qui est super, mais comme le fait remarquer Julien Jorge, pas très intégré malheureusement).

          • [^] # Re: Des beaux plug-ins

            Posté par (page perso) . Évalué à 2.

            Ha, bon il faut qu'on attende un peu alors.

            Sauf que ce sera fait de manière générique pour tous les plugins, y aura plus besoin de bidouiller dans ton >coin (ce qui est super, mais comme le fait remarquer Julien Jorge, pas très intégré malheureusement).

            Le terme "pas très intégré" me parait un peu exagéré. A priori on ne peut de toute façon pas "intégrer" une fonctionnalité dans un framework qui n'existe pas encore. Heureusement qu'on l'a fait dans notre coin au final. C'est un peu le problème avec GIMP, on a toujours un peu l'impression de devoir attendre les fonctionnalités arriver ;)

            • [^] # Re: Des beaux plug-ins

              Posté par (page perso) . Évalué à 4.

              Le terme "pas très intégré" me parait un peu exagéré. A priori on ne peut de toute façon pas "intégrer" une fonctionnalité dans un framework qui n'existe pas encore.

              Y a tout de même un framework de plugin. Ce qui n'est pas là, c'est un système de gestion des plugins.
              Mais oui ça peut être mieux, c'est sûr. :-)

              C'est un peu le problème avec GIMP, on a toujours un peu l'impression de devoir attendre les fonctionnalités arriver ;)

              C'est vrai. L'équipe est bien trop petite. Encore une fois, on y peut rien malheureusement.

              J'essaie un peu d'accélérer les choses, à mon niveau, mais ça reste très limité bien entendu. Par exemple ces derniers jours, j'essaie de pousser une sortie de correctifs (donc 2.8.8). Y a pas de nouvelles fonctionnalités bien sûr, mais je pense que même les versions mineures, GIMP met trop de temps à les sortir, et j'aimerais accélérer le rythme.

              Les versions majeures, j'aimerais aussi qu'on les accélère, mais je pressens que cela ne pourra être fait avant au moins la 3.0, et encore il faudra arriver à convaincre les autres. Car la 2.10 (GEGL) et la 3.0 (GTK+ 3) sont des chantiers trop gros et ne peuvent être fait "partiellement".

              • [^] # Re: Des beaux plug-ins

                Posté par . Évalué à 0. Dernière modification le 03/11/13 à 04:26.

                peut-être proposer une weekly build séparément des "versions officielles" ?

        • [^] # Re: Des beaux plug-ins

          Posté par . Évalué à 2.

          Euh ca va donner quoi pour les autres logiciels que Gimp, je prend les logiciels KDE par exemple? G'mic ne pourra plus etre integrer?

          • [^] # Re: Des beaux plug-ins

            Posté par (page perso) . Évalué à 2. Dernière modification le 11/10/13 à 18:20.

            Non, aucun problème.

            Du point de vue du projet G'MIC, le plug-in pour GIMP est "seulement" une des interfaces disponibles pour manipuler les fonctionnalités de G'MIC (c'est aussi la plus utlisée d'ailleurs). Si on retravaille cette interface particulière, ça ne changera rien pour les autres interfaces qui existent déjà.

            A noter que l'intégration d'un plug-in G'MIC pour Krita est en bonne voie, comme l'a décrit Thimothée Giet dans son blog : http://timotheegiet.com/blog/comics/gmic-colorize-comics-working-in-krita.html

  • # la déformation à N points

    Posté par (page perso) . Évalué à 4.

    Ce truc est énorme !

    Ça va m'être utile ce machin, c'est prévu pour quand ce truc ?

    • [^] # Re: la déformation à N points

      Posté par (page perso) . Évalué à 2.

      Tu peux déjà compiler la branche « soc-2013-n-point-deformation-tool » dispo ici: https://git.gnome.org/browse/gimp/

      Après je ne sais pas quand ce sera inclus mainstream.

      • [^] # Re: la déformation à N points

        Posté par (page perso) . Évalué à 4.

        Salut,

        faut que quelqu'un trouve de temps de faire la revue de code, nettoyer, corriger ce qu'il y a à corriger, puis merger. Si personne ne le fait avant moi, c'est dans ma TODO list parce que cet outil m'intéresse aussi pas mal.

        Le GSOC, c'est cool, mais cela reste des étudiants. Certains font un bon travail, mais il reste un énorme travail après coup pour finir. Pour tout dire, on a des gsoc de 2011 pas encore intégrés dans la branche principale.

      • [^] # Re: la déformation à N points

        Posté par (page perso) . Évalué à 2. Dernière modification le 12/10/13 à 13:15.

        Bon alors pour j'ai compilé la branche de dév pour tester sur ma Debian Sid. Il faut compiler à la main la dernière version de babl et la branche "origin/soc-2013-n-point-deformation" pour gegl et GIMP, à part ça ça compile sans problème une fois les dépendances de GIMP, gegl et babl installées (à coups de apt-get build-dep).

        Les sources de gegl et babl sont ici: http://www.gegl.org/#_download

        Je me retrouve avec un GIMP forcément un peu boggué (genre l'outil d'extraction de premier plan ne fonctionne pas, des comportements bizarres), les ciseaux intelligents semblent avoir disparus (j'espère qu'ils ne comptent pas les enlever !), et affreusement lent (j'ai mis les options par défaut, donc ça ne devrait pas être compilé avec le mode debug, je n'ai pas creusé plus les raisons de ces ralentissements).

        L'outil de déformation en lui même je n'ai pas compris comment il sélectionnait uniquement les parties non transparentes de son calque sur la vidéo: en prenant la même image de Sintel, en la détourant, recadrant et dedimensionnant à peu près comme sur la vidéo (sinon ça râme), à chaque fois que je clique ça met la grille sur toute l'image, et du coup la déformation n'est pas la même. J'ai réussi une fois par accident à avoir la grille de la même manière que sur la vidéo, mais je n'ai pas encore réussi à reproduire ni à comprendre pourquoi. Je ne sais pas si c'est un bogue ou une combinaise de touche que je ne fais pas (les options ont l'air identiques à la vidéo).
        Ah et aussi les actions de ce nouvel outil ne sont pas encore ajoutées correctement dans l'historique d'annulation.

        Mais bon, je ne m'attendais pas à avoir un truc foncionnel en compilant à l'arrache une version de dév :)

        En tout cas un outil bien sympa. Y'a aussi un nouvel outil de déformation en tordant, « warp transoform », mais je n'ai pas trop testé encore.

        • [^] # Re: la déformation à N points

          Posté par (page perso) . Évalué à 2.

          Salut,

          l'outil d'extraction de premier plan ne fonctionne pas

          Il n'est pas encore porté sur GEGL, notre nouveau moteur. Une personne avait commencé le travail, mais n'a jamais terminé et on a un travail à moitié fait.

          les ciseaux intelligents semblent avoir disparus (j'espère qu'ils ne comptent pas les enlever !)

          Je sais pas pour celui-là, mais c'est peut-être la même chose. En tous cas, le code est toujours là. Quoiqu'il en soit, l'équipe n'a pas pour pratique de retirer des fonctionnalités utilisées. Mais je suis en train de demander sur le canal IRC, au cas où.

          et affreusement lent

          Oui, comme tu dis, c'est une version de dév. On déconseille fortement de l'utiliser en prod (quasi impossible dans l'état actuel). Et encore, y a quelques mois, c'était 10 fois plus lent. Tu faisais un simple coup de pinceau et tu voyais ton trait apparaître à la vitesse de l'escargot asthmatique. :-D

          Comme dit plus haut, on porte entièrement le moteur de GIMP vers GEGL. C'est un travail de fond, peu visible certes dans l'UI, et comme GEGL est encore très jeune, la stabilité a priorité sur les optimisations, qui vont venir avec le temps.

          L'outil de déformation en lui même je n'ai pas compris comment il sélectionnait uniquement les parties non transparentes de son calque sur la vidéo: en prenant la même image de Sintel, en la détourant, recadrant et dedimensionnant à peu près comme sur la vidéo (sinon ça râme), à chaque fois que je clique ça met la grille sur toute l'image, et du coup la déformation n'est pas la même. J'ai réussi une fois par accident à avoir la grille de la même manière que sur la vidéo, mais je n'ai pas encore réussi à reproduire ni à comprendre pourquoi. Je ne sais pas si c'est un bogue ou une combinaise de touche que je ne fais pas (les options ont l'air identiques à la vidéo).
          Ah et aussi les actions de ce nouvel outil ne sont pas encore ajoutées correctement dans l'historique d'annulation.

          J'ai vaguement testé y a quelques semaines. Donc j'en sais pas beaucoup plus que toi. En testant sur une image avec fond transparent, la sélection avait bien marché, si je me souviens. Je crois pas avoir testé avec fond non transparent, par contre. En tous les cas, oui, c'est pas intégrable en l'état.

          • [^] # Re: la déformation à N points

            Posté par (page perso) . Évalué à 2.

            Oui j'ai regardé un peu la description de GEGL sur Wikipédia, ça a l'air bien sympa :). Je suppose que ça va permettre d'amener des fonctionnalités réclamées comme les profondeurs à plus de 8 bits, et le support CMJN (dont personnellement je me moque, mais qui servent probablement au niveau pro).

            Et oui je sais bien que c'est une version de dév, je ne m'attendais pas à un truc nickel :). J'ai juste mis les infos au cas où quelqu'un voudrait tester en avant-première cet outil sympathique, je garde ma 2.8.x de Debian pour une vraie utilisation.

            • [^] # Re: la déformation à N points

              Posté par (page perso) . Évalué à 10.

              Oui j'ai regardé un peu la description de GEGL sur Wikipédia, ça a l'air bien sympa :).

              Ça l'est! :-)

              Je suppose que ça va permettre d'amener des fonctionnalités réclamées comme les profondeurs à plus de 8 bits

              Oui et c'est déjà là! Lance ton GIMP master compilé, et regarde le menu Image > Precision.
              Y a du 16 et 32-bit, entier, flottant, linéaire, gamma, pour tous les goûts!

              C'est pas encore porté sur tous les outils, donc c'est du travail en cours, mais le principal est là.

              et le support CMJN (dont personnellement je me moque, mais qui servent probablement au niveau pro).

              Ça sert pour ceux qui impriment. Un pro de l'image qui sort pas de l'écran n'en a rien à faire. Mais oui c'est une des fonctionnalités les plus demandées, car beaucoup soit impriment (designers d'affiche, etc.), soit ne comprennent pas à quoi ça sert et comment, mais on leur a dit que le CMYK, c'est pour les pros. :-)

              Aussi en vrai avoir un tel support dans ton software de graphisme n'est pas suffisant. La question des couleurs est extrêmement compliquée (pas que sur le sujet CMYK, mais les couleurs en général), et je balbutie moi-même et commence à peine à comprendre certaines choses (mais encore bien trop peu! Donc je dis sûrement beaucoup d'âneries sur le sujet). Et la plupart des gens, c'est pareil. Ils croient qu'il suffit d'avoir un programme avec un bouton "CMYK", ils cliquent dessus, et c'est bon, ils sont des pros ("la preuve! Je clique sur le bouton CMYK!"). En vrai c'est genre 1000 fois plus compliqué. Y a les questions des profils de couleur, pour faire bien tu dois calibrer tes écrans, tes scanners, tes imprimantes (ce qui génère les dits profils). Et pour le faire, y a des outils au tarif décent (comme le colorhug, c'est openhardware, et "seulement" 75 EUR. Je l'ai acheté d'ailleurs!), mais c'est limité. Si tu veux faire vraiment les choses professionnellement, tu dois avoir des outils de calibrations à des tarifs bien plus haut (plusieurs centaines d'euros), un photospectromètre, etc. Et ça sert pas à grand chose (ou moins en tous cas) si t'as un écran pourri, si t'as un ordi portable (sauf si tu le bouges jamais et change jamais l'angle de l'écran), si t'as des fenêtres (ou alors ferme les volets!), si tes murs sont peints en autre chose qu'en gris, etc.
              Sans déconner, j'ai entendu dire que les grands studios de cinéma pro ont ce genre de pièce pour aller visionner leurs films correctement.

              Je suis persuadé que 90% des gens qui travaillent en CMYK font pas les choses comme il faut (même sans aller dans les extrêmes comme aller travailler dans ta cave peinte en gris!).
              Quand Photoshop te dit "on a du support CMYK", c'est surtout très marketing. Voire certains disent que c'est un peu une forme de mensonge. À vrai dire, il semblerait que Adobe même est en train de réfléchir à faire marche arrière sur pas mal de choses au sujet de la gestion de couleurs, alors même qu'ils ont contribué à créer et populariser tout ça. Par exemple, y a eu cet email d'un représentant Adobe dans le CSS working group où il est en train de dire en gros que la gestion des couleurs, c'était peut-être une erreur de leur part depuis le début car bien trop compliqué, et d'autres ont bondi à cette déclaration. Bon je t'avoue que je pige pas tout dans la discussion, mais c'est peut-être justement parce que je pige pas beaucoup dans la gestion des couleurs (en ce sens, cet employé Adobe a raison quand il dit que c'est compliqué!).

              Sinon est-ce que GEGL/BABL aideront pour ajouter le support dans GIMP? Je pense en effet que ça pourra aider car on a plus d'abstraction pour travailler sur les formats avec BABL. Malheureusement je crois que personne ne travaille sur le support de CMYK pour le moment (si je ne m'abuse). Je pense que les dévs de GIMP actuel n'ont pas le besoin et ont d'autres priorités (moi de même). Il nous faudrait un dév qui ait ce besoin (ou bien qu'on ait terminé nos autres priorités!).
              Dans le Logiciel Libre, même si on travaille ensemble au final, chacun a un peu son propre plan à long terme. :-)

              Mais l'une des fonctionnalités majeures que cela va apporter, c'est surtout l'édition non destructrice. Par exemple les effets pourront être appliqués avec des calques d'effet, dont on peut modifier les paramètres, ou supprimer pour retrouver l'image originelle, etc. GEGL est un système de traitement d'images en graphe, où les effets et autres traitements sont des nœuds avec entrée et sortie. Un peu comme le compositing dans Blender avec des nœuds (sauf que nous n'aurons probablement pas une UI en graphe comme Blender. Je pense que ce serait génial perso, mais a priori le designer qui bosse avec nous pense différemment. Mais c'est pas encore sérieusement discuté, donc y a la marge et le temps).
              Bon tout ça (édition non destructrice) ne sera certainement pas dans GIMP 2.10. Ce serait GIMP 3.0, voire même après. On aura les fondations dans 2.10, mais pas l'UI. Mais c'est le chemin pour y arriver.

              • [^] # Re: la déformation à N points

                Posté par (page perso) . Évalué à 8.

                Petit addendum à moi-même:

                Aussi faut bien voir que travailler directement en CMYK, c'est pas "vraiment" possible. Même si tu stockes en CMYK dans le fichier ou en format interne dans le programme, ton écran lui est toujours RGB. Donc y a forcément des tables de correspondance ou autre truc du genre et par définition, ça ne peut pas être parfait car c'est tout simplement 2 systèmes totalement différents. J'ai pas encore regardé les détails d'implémentation de ce genre de chose donc je veux pas dire trop de bêtise non plus, mais bon faut être bien conscient que c'est pas parce que le fichier est stocké en CMYK que soudainement, ce que tu as à l'écran, c'est comme ton papier. Non l'écran est et reste du RGB. Papier et écran/projecteur, c'est structurellement différent.

                Oh et j'oubliais aussi dans mon énumération précédemment des choses à faire si tu veux faire les choses bien! Quand tu calibres ton imprimante, tu dois en fait calibrer (et donc générer un profil) par couple (imprimante, papier). Tu ne calibres pas pour l'imprimante seulement, ça n'a pas de sens, car chaque type de papier (couleur, texture, etc.) est différent. Donc avec la même imprimante, tes couleurs sortiront différemment selon que tu imprimes sur ton papier blanc, fin et mat ou ton autre papier qui tend vers le rose, plus épais et brillant. La gestion des couleurs est vraiment un enfer. :-)

        • [^] # Re: la déformation à N points

          Posté par (page perso) . Évalué à 2.

          J'ai réussi à faire la sélection, c'est assez étrange: si je sélectionne mon image juste détourée dans un calque, ça ne marche pas. Si j'exporte l'image en PNG (en gardant le canal alpha bien sûr), et que je la réouvre depuis le PNG, là la sélection marche comme sur la vidéo. J'espère qu'on pourra arranger cette sélection aussi: j'ai fait un test ou le bras est collé au corps, du coup quand je déplace le bras ça déforme le corps, il faudrait pouvoir couper le lien avec le corps (en fait peut-être qu'il suffirait juste que je détoure le bras séparément, il faudra que je teste).

          Mais sinon l'outil est pratique, j'aime beaucoup :)

  • # Détourer des cheveux

    Posté par (page perso) . Évalué à 7.

    Du coup dans mon élan je me suis mis à suivre des tutos sur le net, à apprendre enfin à me servir des courbes de couleurs, à détourer des cheveux grâce à elles.

    Comment fais-tu ça, le détourage de cheveux ? C'est une des choses le plus difficiles pour moi, je serais intéressé par des explications…

    • [^] # Re: Détourer des cheveux

      Posté par (page perso) . Évalué à 8.

      C'est plus facile quand il y a un contraste fort avec le fond. En gros l'idée c'est d'isoler les couleurs avec la courbe de couleurs (une fois la courbe affichée avec couleurs/courbes tu cliques sur l'image un peu partout sur les cheveux pour voir où ça se situe sur la courbe, puis tu mets les couleurs avant et après en noir), tu convertis ensuite en niveaux de gris (couleurs/désaturer/luminosité) et tu nettoie un peu. Puis tu convertis ça en masque de calque. C'est pas parfait, mais ça permet d'avoir le gros des cheveux assez facilement.

      C'est expliqué (avec une technique plus ou moins similaire) dans des tutos comme celui-ci: http://www.dom-web.net/?p=1597 . Si les cheveux sont dans une couleurs particulièrement proche du rouge, vert ou bleu, ça peut être intéressant d'utiliser les canaux pour isoler plus facilement la partie qui t'intéresse.

  • # Merci pour ce témoignage

    Posté par (page perso) . Évalué à 10.

    Bonjour,

    Merci beaucoup pour ce témoignage, ça fait rudement plaisir :)
    Je me dis que passer du temps à réécrire entièrement le livre par rapport aux éditions précédentes était une bonne idée.
    Avec un tel témoignage je ne peux pas m'arrêter là ! Mais de toute façon, je ne comptais pas m'arrêter…

  • # Le gros moins de GIMP

    Posté par (page perso) . Évalué à 6.

    J'utilise presque tous les jours GIMP, et je le manipule très bien, mais quand je compare à mes collègues qui utilisent PS, il lui manque quand même un truc énorme: la gestion d'une pile de modificateurs.

    Je m'explique: si vous faites un texte et que vous voulez ajouter une ombre et une rotation, rien de plus facile. Maintenant, si je veux modifier le texte parce qu'il y a une erreur, je dois me retaper à la main la liste des effets que je lui ai mis… Et sincèrement quand on modifie régulièrement une même image, c'est vraiment ULTRA relou !
    Tandis que sous photoshop, le calque original et chaque effet reste entièrement éditable après coup !

    C'est vraiment le dernier gros point noir que je vois sous GIMP pour le rendre comparable à PS.

    • [^] # Re: Le gros moins de GIMP

      Posté par (page perso) . Évalué à 2.

      le dernier gros point noir

      Les actions, aussi (combinaisons de niveaux d'undo et de macros, ça pourrait être implémenté différemment, mais là en l'état il n'y a pas de gestion par lots "batch" à proprement parler - heureusement qu'il y a imagemagick) ce serait bien, Mr Furet.

      • [^] # Re: Le gros moins de GIMP

        Posté par (page perso) . Évalué à 9.

        Réponse aux 2 messages précédents:

        Je m'explique: si vous faites un texte et que vous voulez ajouter une ombre et une rotation, rien de plus facile. > Maintenant, si je veux modifier le texte parce qu'il y a une erreur, je dois me retaper à la main la liste des effets que je lui ai mis… Et sincèrement quand on modifie régulièrement une même image, c'est vraiment ULTRA relou !
        Tandis que sous photoshop, le calque original et chaque effet reste entièrement éditable après coup !

        C'est ce que j'appelle plus haut l'édition non-destructrice avec les calques d'effets. C'est prévu. C'est peut-être même une des conséquences majeures qu'apportera GEGL. Par contre les chances d'avoir ça pour GIMP 2.10 sont très faibles, car bien que le port GEGL sera alors complet, il n'y aura pas l'UI pour en tirer profit. À moins qu'on ait plus de dév d'ici là, par exemple.

        Les actions, aussi

        Clairement c'est un des autres gros points manquants. C'est aussi une fonctionnalité qui je pense demandera beaucoup de réflexion et de temps pour la faire bien (on peut la développer à-peu-près relativement rapidement, mais on aime le beau code).

        mais là en l'état il n'y a pas de gestion par lots "batch" à proprement parler - heureusement qu'il y a imagemagick

        En effet à l'heure actuelle, même s'il y a un mode console pour GIMP (on peut même compiler que le mode console de GIMP, sans UI donc sans dépendance à X si on veut. Pour un serveur par ex), c'est pas l'extase. Je pense même qu'aucun des dévs ne considère cela comme une fonctionnalité majeure de GIMP. ImageMagick est clairement beaucoup plus efficace car fait pour.
        Quand des utilisateurs nous parlent de cas d'usage qui est clairement un travail à la chaîne (donc du batch) et se plaint que GIMP est pas efficace pour cela, on leur dit à chaque fois d'aller essayer ImageMagick, clairement adapté à l'usage.
        Peut-être qu'un jour, quand on aura plus de dévs, en particulier des dévs qui s'intéressent à ce mode et ces usages, et leur donne un peu d'amour, GIMP y sera bon aussi. Mais pour l'instant, je pense qu'il faut accepter ce fait, ou alors retrousser ses manches et nous aider. ;-)

        • [^] # Re: Le gros moins de GIMP

          Posté par (page perso) . Évalué à 1.

          Merci pour cette réponse "de l'intérieur" :)

          Je vais regarder (avec des vrai(e)s utilisat[eur|rice]s que je connais, moi je suis juste un bricoleur) à faire des mockups de cette implémentation de batch, car c'est un sujet qui passionne tout le monde et sa sœur, et tous ont une idée de ce à quoi ça pourrait ressembler (workflow / interface).

          Tant qu'on y est, ce qui serait super, ce serait de faciliter l'usage de GIMP pour l'animation, avec une "table lumineuse" qui montre les détours des n calques inférieurs, et permet de "jouer" (juste une commande play / pause / accell < > quoi) qui fait "défiler" l'affichage desdits calques) l'anim. En attendant je triche avec les opacités de layer et l'export GIF et ça marche.

          J'entends également des critiques sur la gestion interactive (une main sur le clavier, l'autre sur la wacom) des brosses, qui ne me posent personnellement aucun problème (mais je ne pains pas avec aussi).

          GIMP est un des éléments clefs qui m'ont accueilli chez GNU/Linux en me permettant de presque zapper Windows lors de la terrible et interminable dégénérescence (sur fond de tribal hardcore) de l'Amiga (où on avait une chaîne de traitement bitmap hors-pair, de Deluxe Paint et Brillance pour l'anim, à ADPro pour le batch, en passant par TVPaint (mais il fallait une carte graphique) ImageFX et PhotoGenics et je parle même pas de la 3D…

          C'était mon petit hommage au furet, qui fait vaillamment ce que je lui demande depuis 1998. Merci et bravo à toute l'équipe.

          • [^] # Re: Le gros moins de GIMP

            Posté par (page perso) . Évalué à 6.

            Salut,

            Je vais regarder (avec des vrai(e)s utilisat[eur|rice]s que je connais, moi je suis juste un bricoleur) à faire des mockups de cette implémentation de batch, car c'est un sujet qui passionne tout le monde et sa sœur, et tous ont une idée de ce à quoi ça pourrait ressembler (workflow / interface).

            Si t'as des mockups, et des idées plus ou moins ("plus", c'est mieux) clairement spécifiés, etc. tu peux participer au GUI brainstorm: http://gimp-brainstorm.blogspot.co.nz/
            C'est un peu mort, parce que notre expert UI s'était éloigné de nous, mais il vient de revenir y a juste une semaine. Donc nos retours UI vont s'améliorer.

            Tant qu'on y est, ce qui serait super, ce serait de faciliter l'usage de GIMP pour l'animation, avec une "table lumineuse" qui montre les détours des n calques inférieurs, et permet de "jouer" (juste une commande play / pause / accell < > quoi) qui fait "défiler" l'affichage desdits calques) l'anim. En attendant je triche avec les opacités de layer et l'export GIF et ça marche.

            Je suis pas certain de comprendre ta comparaison avec une table lumineuse. Veux-tu simplement dire une timeline où on peut spécifier plusieurs calques par frame (et pas comme actuellement, 1 calque = 1 frame)? Si c'est le cas, sois en joie, car c'est en travaux. Je suis depuis quelques mois le mainteneur officiel du plugin core animation-play qui est fourni avec GIMP. Et je suis justement en train de travailler sur ce dont tu parles. Si tu voyais ma version de dév actuelle, tu verrais que ça n'a déjà plus grand chose à voir avec la 2.8. :-)

            J'entends également des critiques sur la gestion interactive (une main sur le clavier, l'autre sur la wacom) des brosses, qui ne me posent personnellement aucun problème (mais je ne pains pas avec aussi).

            Oui il paraît que GIMP n'a pas les meilleures brosses. Si je pige bien, MyPaint serait vraiment sympa pour créer des brosses (cad que l'UI serait plus aisée à manipuler). Par contre je crois qu'elles sont plus limitées (les brosses sont toutes formées de cercles comme forme de base, ou un truc du genre). Krita aurait les meilleures brosses à ce qu'on dit. Dans tous les cas, on dit que MyPaint et Krita sont tous deux spécifiquement dédiés aux peintres (c'est comme cela que ces deux projets se présentent). GIMP se veut plus générique. Il fait de tout: du croquis au traitement photo en passant par la peinture. Depuis les derniers Libre Graphics Meeting, les 3 projets GIMP, Krita et MyPaint essaient en fait de collaborer pour partager leurs pinceaux (ou du moins pour que chacun soit capable d'utiliser les pinceaux des 2 autres). Bon je suis pas sûr que le projet avance énormément, mais les bases de la discussion sont posées.

            Ensuite pas mal de gens dessinent quand même des trucs très cools avec GIMP et la dessinatrice avec qui je travaille semble apprécier créer des brosses et des dynamiques dans GIMP. Un peu d'auto pub: mon webcomic sur la vie d'une Marmotte aventureuse. Y a pas beaucoup de mises à jour parce qu'on revoit pas mal de trucs en cours de route, mais ça devrait prendre le rythme au bout d'un moment. :-)

            l'Amiga (où on avait une chaîne de traitement bitmap hors-pair, de Deluxe Paint et Brillance pour l'anim, à ADPro pour le batch, en passant par TVPaint (mais il fallait une carte graphique) ImageFX et PhotoGenics et je parle même pas de la 3D…

            Oui j'entends pas mal parler des supers progs de dessin de l'amiga. Moi à l'époque, mon grand frère a eu un amiga pendant environ 2 ans et on faisait que jouer dessus avant qu'on grille l'alim (oui l'alim, c'est rien, mais nous on y pigeait que dalle et mes parents sont danseurs, ils y pigent encore moins), puis on a pas eu d'ordi pendant pas mal d'années. Je suis loin d'avoir eu une jeunesse de geek, je me demande comment j'ai tourné ainsi! :-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.