Le flou

• [^]Re: Le flou

  Posté par halt () le 26/01/2006 à 14:11. (lien). Évalué à 2.

  Le troll Gimp/Photoshop: autant pour une utilisation simple, Gimp suffit emplement, autant pour un usage Pro, photoshop est indispensable.
  
  
  Ce qui manque à Gimp?
  -CMYK
  -couleurs sur 16bits
  -bonne gestion des très lourdes images (même si Gimp est un peu moins mauvais qu'avant)
  -moins de bugs graphiques
  -le système multi-fenêtres foireux (en tout cas sous Gnome, ce qui est un comble)

  • [^]Re: Le flou

    Posté par Frédéric COIFFIER () le 26/01/2006 à 16:04. (lien). Évalué à 4.

    Je pense que sur les 2 premiers points (canaux 16bits et CMYK), Krita est sur la bonne voie !
    Mais il est encore en plein développement, très jeune (et donc, moins mature que Gimp) mais en tout cas, ils ont de très bonnes idées !

    • [^]Re: Le flou

      Posté par Nicolas Dumoulin (Jabber id, page perso, ) le 27/01/2006 à 09:58. (lien). Évalué à 1.

      Valable aussi pour le point 5 :-)

    [^]Re: Le flou

    Posté par imalip (page perso, ) le 26/01/2006 à 16:43. (lien). Évalué à 4.

    Tu as vraiment lu ce qu'il y avait dans la phrase qui contenait Gimp et Photoshop, ou c'est juste un reflexe de lacher un troll comme ca ?

    --
    "While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal

    • [^]Re: Le flou

      Posté par efbie () le 26/01/2006 à 18:47. (lien). Évalué à 5.

      Le problème gimp/photoshop est un véritable problème pour les gens qui bossent dans le graphisme et qui veulent passer sous linux. Au siggraph de l'année passée il y avait un rassemblement ou les grosses boites (ILM, pixar, etc...) pouvaient discuter de la place de l'open source dans leur travail.
      
      Les conclusions étaient que linux était une très bonne plateforme qu'ils utilisent d'ailleurs beaucoup, que les solutions opensource devenaient de plus en plus sérieuses. Cependant la question qui revenait sans cesse, c'est le manque de logiciel de retouche 2D adapté au travail professionel. Gimp et cinepaint étaient pointés du doigt comme étant particulièrement mauvais.
      
      Rebelotte pour le projet orange, qui consiste a réaliser un film d'animation entièrement en open source : Cinepaint est inutilisable, et gimp n'est pas terrible non plus, ils sont donc en train de coder leurs propres outils de composition dans blender.

      • [^]Re: Le flou

        Posté par halt () le 26/01/2006 à 19:21. (lien). Évalué à 3.

        Efbie, je te remercie pour ta clairvoyance.
        
        Contrairement à ce que pense beaucoup, Gimp n'est pas du tout une killerApp.
        
        PureData par contre connaît une très forte percée face à MaxMSP et Proce55ing est de plus en plus utilisé au détriment de Macromedia Director.

        • [^]Re: Le flou

          Posté par jerome (page perso, ) le 27/01/2006 à 11:20. (lien). Évalué à 5.

          Contrairement à ce que pense beaucoup, Gimp n'est pas du tout une killerApp.

          
          Ouais, enfin, faut relativiser un peu les propos. GIMP n'est pas l'équivalent de photoshop MAIS c'est une killer app sur linux comparativement à l'existant sur cette même plate-forme (pour le coup, ya pas grand chose d'autre) ET les utilisateurs de photoshop reprochent plein de choses à GIMP indépendament de la technique, sur les aspects ergonomiques en particulier (fenêtres, raccourcis, mode de gestion des pointeurs multiples, etc), reproches souvent motivés par le manque d'habitude.
          Et NON, la GUI de GIMP n'est pas mauvaise, par contre, le WM de GNOME est une merde, ça, c'est sûr. Notons que celui de MacOSX est encore pire et que nombre de graphistes s'en plaignent régulièrement (surtout quand ils ont essayé autre chose).
          
          Enfin, ne prenons pas GIMP pour l'équivalent de Photoshop, mais accordons lui le respect qu'il mérite pour ses nombreuses innovations et les bons services qu'il nous rend :)

          • [^]Re: Le flou

            Posté par efbie () le 27/01/2006 à 13:59. (lien). Évalué à 5.

            > Non la GUI de Gimp n'est pas mauvaise
            
            Euuuh, personellement j'ai rarement vu un programme avec une GUI aussi mauvaise. Et me dis pas que c'est le manque d'habitude, j'utilise gimp tous les jours par faute de mieux...
            quelques exemples de trucs qui m'horripilent au plus haut point :
            
            - 5 popups pour sauvegarder un png.
            - L'énorme popup lorsqu'on utilise l'outil de redimensionnement
            - l'impossibilité de configurer gimp pour qu'il fasse défiler l'image avec un raccourci autre que le bouton du milieu de la souris (pratique quand on utilise une palette graphique... )
            
            Ca se sont les plus gros mais il y a les millions d'autres petits trucs ennuyants qui rendent l'utilisation de gimp vraiment pénible si on veut faire autre chose que des bannières de site web.

            • [^]Re: Le flou

              Posté par David () le 31/01/2006 à 14:21. (lien). Évalué à 2.

              D'ailleurs quelqu'un sait comment zoomer/dézoomer à partir du clavier? Sous photoshop, c'était Ctrl+ et Ctrl-.
              Et puis dans Gimp, je n'ai jamais compris pourquoi la palette d'outil n'est pas "toujours au dessus". Gimp ne semble proposé l'option, mais laisse cette fonctionnalité à la charge du WM.

              --
              -- Front de Libération des Sources --
              Pour stopper les trolls, citons les sources !

              • [^]Re: Le flou

                Posté par jerome (page perso, ) le 01/02/2006 à 11:33. (lien). Évalué à 1.

                Nb de popups : pour enregistrer un PNG à partir d'une image à plusieurs calques : 3 fenêtres de dialogue : une pour le chemin / extension, une pour demander d'aplatir l'image, une pour les préférences de l'export. On pourrait avoir une seule fenêtre de dialogue, mais elle serait un peu touffue ...
                
                Zoom / dézoom : '-' et 'S-=' soit '+'
                
                Pour faire défiler l'image, c'est vrai qu'il faut afficher la fenêtre de défilement (ctrl + maj + n puis utiliser les flèches), pas très convi, mais possible.
                
                Pour garder la boîte à outils toujours visible (par vraiment d'intérêt mais bon), il y a dans les préférences "Gestion des fenêtres" de quoi envoyer tout un tas d'info au WM sans configurer pour autant le WM de manière à protéger la BAO de superposition, etc.
                
                Je ne suis pas contre le fait de reprocher des trucs à GIMP mais il faut distinguer ses véritables défauts des choix par défaut du soft, imposés par le desktop (GNOME), la distrib (conf par défaut pas forcément adéquate), le WM, etc. Sans compter l'éventuelle mauvaise connaissance des propriétés récentés ajoutées au soft.

        [^]Re: Le flou

        Posté par GuieA_7 (page perso, ) le 27/01/2006 à 09:07. (lien). Évalué à 3.

        J'espère que ces GROSSES boites ne vont pas se contenter de dire que "bouh the Gimp c'est de la merde !" et qu'elles vont aider d'une manière ou d'une autre ce projet (que j'adore) et qui a un grand besoin de développeurs (encore que vu l'activité ces derniers mois ça va peut être mieux).
        Parce qu'à ce moment là, tant qu'on y est, Blender c'est moins bien que 3DS alors on peut aussi dire que c'est tout pourri une fois qu'on a plus que 3 cubes qui se courent après.

    [^]Re: Le flou

    Posté par Sytoka Modon (page perso, ) le 26/01/2006 à 20:14. (lien). Évalué à 2.

    A vrai dire, le CMYK est un peu dépassé. Tu as le pentone....
    
    Bref, ce qu'il faut, c'est une gestion des couleurs "Lab" et une vrai gestion des profiles ICC tant au niveau de l'impression, que du coté de l'écran et du scanner. Pour la partie écran, il faudrait faire cela au niveau de XWindow. Là le pinguoin serait novateur car la gestion des profiles ICC n'est pas encore intégré au système dans XP (je ne sais pas pour XP).

    • [^]Re: Le flou

      Posté par Psylo (page perso, ) le 26/01/2006 à 22:57. (lien). Évalué à 3.

      Une couleur pantone, c'est juste une teinte particulière (ex le rose fluo d'une couv de magazine), pas un système de colorimétrie comme la quadrichromie CMJN, qui n'est en rien dépassée... ça fait des années que les systèmes à 7 couleurs (septichromie) existent et c'est franchement pas souvent utilisé.

      • [^]Re: Le flou

        Posté par Sytoka Modon (page perso, ) le 27/01/2006 à 07:56. (lien). Évalué à 2.

        Merci a ceux qui mon moissé...
        
        J'étais exprès sur la pente opposé histoire de lancer le débat.
        
        Je maintiens que le système interne doit être le "Lab" et non CMJN. Le "Lab" est l'avenir et est en train de devenir le point central à partir duquel se font tous les profiles ICC. C'est en quelque sorte l'espéranto de la couleur.
        
        A t'on déjà évoqué le Lab ici ? A t'on déjà évoqué d'intégrer les profils ICC directement dans la couche X pour la gestion des écrans, dans la couche cups pour la gestion des impressions...
        
        Bref, mon post méritait mieux que de ne plus être visible !

        • [^]Re: Le flou

          Posté par Psylo (page perso, ) le 27/01/2006 à 14:26. (lien). Évalué à 1.

          L'intégration des profils ICC dans X et dans CUPS serait effectivement une très bonne chose.
          L'utilisation du lab par contre, a part dans un usage réellement professionel, je reste un peu sceptique.

          • [^]Re: Le flou

            Posté par Sytoka Modon (page perso, ) le 27/01/2006 à 21:32. (lien). Évalué à 3.

            On veut jouer dans la cour des grands ou pas ?
            
            Franchement, quitte a mettre la couleur au coeur du systeme, autant le faire avec l'espéranto local donc le Lab.
            
            Si on le fait en CMJK, a peine finit, ce sera dépassé. Et pour un usage professionnel, le pingoin serait vraiment au top.
            
            Quel est le cout de la transformation Lab -> RGB via un profil ICC. Ca doit bien pouvoir se programmer en utilisant les ressources de la carte graphiques, qui a part pour les jeux, passe son temps a se tourner les pouces.

            • [^]Re: Le flou

              Posté par pierthi () le 28/01/2006 à 14:55. (lien). Évalué à 2.

              Boaf, le Lab comme espace colorimétrique sur le serveur X, je n'y crois pas trop non plus. Juste pour ceux qui débarquent, une gestion colorimétrique n'est ni plus ni moins qu'un moyen de garantir que les couleurs s'afficheront pareilles d'un périphérique à l'autre (camera, scanner, écran, imprimante, ....).
              
              Je ne pense pas qu'il ait besoin que le serveur X sache gérer le Lab en interne (X sait d'ailleur déjà convertir le Lab => RGB), pour faire une bonne gestion colorimétrique. On peut largement le faire au niveau applicatif.
              
              Genre avant d'afficher une image, l'appli applique un profil d'entrée qui converti le RGB/CMYK en Lab, puis un autre profil de sortie en fonction du périphérique (écran / imprimante), qui convertira le Lab en RGB/CMYK. Ca à l'air beaucoup, mais des libs comme littlecms font ça en 2/3 lignes de code C et en un clin d'oeuil, même sur la dernière des bouses. Avec ça, X n'a absolument pas besoin de gérer le Lab.
              
              Le vrai problème est de générer (ou récupérer) ces foutus profils ET les conditions techniques de leur utilisation (genre pour une imprimante, quel mode d'impression, quelle réduction d'encrage, linéarisation, ...). Changez un paramètre, et vous pouvez regénérer votre profil. Sauf que générer un profil, c'est :
              
              1. Délicat, il faut savoir ce qu'on fait.
              2. Il faut du matos qui coute la peau du cul (spectro), en plus de logiciels spécialisés.
              
              Même si dans l'idéal, les constructeurs pourraient fournir ces profils, la plupart du temps, ils sont noyés dans les drivers pour Windows et Mac OS, avec une licence proprio évidemment :-(
              
              Et puis bon, garantir des couleurs identiques entre une imprimante et un écran, je n'y crois pas non plus, tant les gamuts sont différents. Dans ce cas, autant se contenter d'approximation, au lieu de sortir l'artillerie lourde.

              • [^]Re: Le flou

                Posté par Sytoka Modon (page perso, ) le 29/01/2006 à 09:26. (lien). Évalué à 2.

                > convertir le Lab => RGB), pour faire une bonne gestion
                > colorimétrique. On peut largement le faire au niveau applicatif.
                

                C'est ce qui est fait à l'heure actuelle. Un beau bordel tu veux dire. Chacun fait comme il veut ou il veut. Regardes sous Windows et la qualité des implentations des profiles d'une application à une autre. Je ne vois pas ce qui te chagrine. A pratir du moment où on a un système client serveur qui marche (affichage, impression, scanner...), autant mettre la gestion colorimétrique au coeur de ces systèmes. Regardes l'impressions sous les UNIX, a chaque application de la gérer... vachement bien ! On aurait eu dès le début un serveur xprint bien conçu, le système d'impression en aurait été facilité pour tout le monde. Combien de ligne de code en moins au global.

                > RGB/CMYK. Ca à l'air beaucoup, mais des libs comme littlecms font > ça en 2/3 lignes de code C et en un clin d'oeuil, même sur la
                > dernière des bouses. Avec ça, X n'a absolument pas besoin de
                > gérer le Lab.
                

                Justement. Pour le peu de ligne à mettre, autant mettre littlecms en module de X !

                > 2. Il faut du matos qui coute la peau du cul (spectro), en plus de
                > logiciels spécialisés.
                

                Là je t'accorde que c'est un vrai problème. J'ai vu il y a 15 jours un spectro qui fait ca. Ca m'a l'air ultra propriétaire et bien fermé. En gros t'achète un super truc mais cela ne marche que sur quelques OS. Tant pis pour toi si un jour tu les mets à jour...

                > Et puis bon, garantir des couleurs identiques entre une
                > imprimante et un écran, je n'y crois pas non plus, tant les gamuts
                > sont différents. Dans ce cas, autant se contenter 
                

                Avec des bons écrans tubes, on arrive quand même à faire des choses propres. C'est sur qu'avec les LCD, c'est pas encore ca.

                • [^]Re: Le flou

                  Posté par Psylo (page perso, ) le 29/01/2006 à 22:40. (lien). Évalué à 2.

                  Le gros problèmes c'est surtout que les modes RGB et CMJN, possèdent des teintes qui n'existent pas dans les autres modes (a part dans le mode Lab, evidement, mais les couleurs Lab que tu affiche à l'ecran sont du simple RGB).
                  Du coup le joli rouge video est inimprimable en CMJN (100% de magenta et 90% de jaune, c'est l'approximation la plus proche), et le joli cyan 100% de la photo que tu scan est inaffichable à l'ecran.

      [^]Re: Le flou

      Posté par med (page perso, ) le 28/01/2006 à 12:55. (lien). Évalué à 2.

      Apparemment la future version de krita va gérer les couleurs « Lab » si j'en crois cette entrée du blog de Cyrille Berger, un des développeurs : http://cyrilleberger.blogspot.com/2006/01/one-day-one-featur(...) . D'ailleurs il fait une entrée par jour avec les nouvelles fonctionalités à venir. C'est très intéressant.

    [^]Re: Le flou

    Posté par Mildred (Jabber id, page perso, ) le 27/01/2006 à 21:24. (lien). Évalué à 1.

    Avec Gimp2 et la nouvelle interface, je trouve que c'est très bien ... Des onglets pour les différents dialogues et je n'ai plus que deux fenêtres:
    - la palette à outils avec les différents dialogues dans des onglets
    - la fenêtre de dessin
    
    j'adore cette interface... que je préfère a une grande fenêtre avec tous les outils et une grande place vide au milieu pour l'image ... vide lorsqu'il n'y a pas d'image.
    C'est un peu comme OpenOffice ouvert sans aucun document ... prend une place monstre juste pour afficher 3 menus.

    --
    La Roue du Temps