Journal faisant suite à : http://linuxfr.org/~maderios/26956.html
Précisions : mon point de vue est totalement subjectif, je ne représente que moi même, je ne relate que mon expérience. Mon boulot : les arts plastiques, l'image.
Question OS, la démarche consiste à dire qu'il faudrait d'avantage partir des besoins des utilisateurs et non comparer avec les autres OS, surtout les pires tels que W$, pour corriger les imperfections de GNU/Linux. Question programmes, le meilleur existe concernant le graphisme : le très propriétaire Photo$. Adobe est à l'écoute des pros (et de leurs $). Gimp ferait bien de s'en inspirer (pas des $). sans états d'âme
Pour être positif :
Hommage et merci à (liste non exhaustive) :
- les bosseurs du noyau, qui dament le pion à ceux qui les taxaient de "rêveurs". Linus Torvalds (ou Richard Stallman ?) a dit qu'un programme ressemble à un roman. Sacrés romanciers.......
- l'équipe Debian, LA distribution, que je ne suis pas prêt de lâcher.
- E17, mon window manager, qui progresse lentement mais surement. Simple, beau, léger, rapide, fonctionnel, prometteur.
http://wiki.enlightenment.org/index.php/E17_User_Guide
http://omicron.homeip.net/projects/#easy_e17.sh
- l'équipe de Gimp. La 2.6 est à l'horizon et on peut espérer que l'arrivée des professionnels dans le monde de Gimp permettra beaucoup d'avancées.
- Digikam, le logiciel le plus abouti dans le genre mais qui semble plus adapté aux besoins de l'amateur qu'à ceux du professionnel.
En vrac :
"Je pense qu'au dela du 16 bits c'est la gestion de l'espace colorimétrique qui empêche gimp d'avoir sa place dans le monde de l'imprimerie professionnel. Cela sera réglé avec la prochaine version stable ! Donc rien de bien grave, d'autant que Krita, digikam permettent de faire ça sans problèmes."
Krita : expérimental (?), impraticable, inutilisable. Le seul éditeur d'images en 16 bits un peu utilisable : Cinepaint. Dommage que sa progression soit stoppée.
"16 bit par contre, c'est un pré requis pour la majorité des opérations dans le monde pré-presse,......."
Pas seulement. 16 bits ça permet d'obtenir d'avantage de dégradés_nuances de couleurs dans les hautes et basses lumières
"Et puis, qui t'oblige à utiliser Claws alors qu'il y a Thunderbird, Evolution ou Kmail ? "
Parce qu'il manque peu de chose à Claws-Mail pour être au top, la gestion correcte du html par exemple.
Et que j'utilise Thunderbird par défaut d'une solution plus légère comme Claws.
"c'est que tu sembles ne pas bien connaître la logithèque Linux au niveau de la station de travail"
Mon système Debian Lenny : 23 572 paquets sous le clic de la souris avec Synaptic. Testé tout ce qui existe surtout pour le graphisme et le son depuis 9 ans.
"donc il râle... bref lorsqu'on râle, c'est qu'on juge (souvent) et que, donc, on peut faire mieux/contribuer... ah tu peux pas ? bah apprends ou ne râles pas : ça ne sert à rien"
Attitude fataliste. Une idée simple : pour Gimp par exemple, mettre un lien quelque part dans l'interface pour envoyer directement des suggestions, des propositions, aux développeurs, sans avoir besoin de passer par un parcours du combattant. Bien entendu, pour éviter les pertes de temps, il faudrait montrer patte blanche et créer un compte. Les développeurs sont enfermés dans leur logique et leur travail de développeurs, coupés des utilisateurs, coupés de la réalité du terrain et ils ont tout à gagner de cette démarche. De plus, un développeur c'est souvent un amateur, concernant le graphisme par exemple. Comment faire face à des problème de professionnels quand on est un amateur ?
"Bref il faudrait que les râleurs deviennent un peu plus humbles et comprennent que le monde ne tourne pas autour de leur nombril, se mettent à la place des développeurs bénévoles, pour comprendre leurs raisons et leurs pratiques."
Si l'on veut que les gens utilisent Linux (à moins de vouloir rester entre soi) la solution est certainement au milieu, : plus d'écoute de la part des développeurs en favorisant la participation des utilisateurs qui passeront du statut de "râleurs" à celui de participateurs.
Une avancée peut être de ce coté là :
"Je n'utilise pas ubuntu mais debian depuis un petit temps (2002) et trouve quand même pas mal d'aide utile sur les fora d'ubuntu :) "
Journal Suite de "Ce qui manque à GNU/LINUX.......
22
juil.
2008
# $$$
Posté par Romain . Évalué à 10.
[^] # Re: $$$
Posté par Jean Roc Morreale . Évalué à 8.
[^] # Re: $$$
Posté par jms . Évalué à 2.
Des gens qui connaissent le développement et le métier (et leurs contraintes) et qui savent reformuler les "exigences".
Bref, un traducteur client/fournisseur ?
[^] # Re: $$$
Posté par libre Cuauhtémoc . Évalué à -2.
ingenieur support
[^] # Re: $$$
Posté par plopoyop . Évalué à 6.
[^] # Re: $$$
Posté par Marc Poiroud (site web personnel) . Évalué à 1.
c'est l'inverse :)
La maîtrise d'ouvrage c'est le client.
La maîtrise d'oeuvre est le tampon entre le client et les équipes de réalisation (entreprises, executants, ...)
[^] # Re: $$$
Posté par lezardbreton . Évalué à 3.
[^] # Re: $$$
Posté par Marc Poiroud (site web personnel) . Évalué à 0.
:D
# Bravo
Posté par libre Cuauhtémoc . Évalué à 1.
# digikam
Posté par flashball . Évalué à 1.
j'y connais rien en " gestion de photographies" mais que manque à digikam ? de la finition ? parce que bon il m'a --l'air-- d'etre extremement complet, de trop peut etre, faudrait meme un mode novice
ou c'est juste un troll ?
[^] # Re: digikam
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
Apres, on pourrait voir s'il y a de réels manque. ;)
Enfin, ceci n'est que mon tres humble avis
PS: J'en suis a développer mes raw avec un script maison, les trier avec konqui + gwenview, les retailler/pivoter avec gwenview (de kde4, un régal ce nouveau gwenview), puis stoker avec Digikam. Et j'avoue que j'en ai marre....
[^] # Re: digikam
Posté par feth . Évalué à 4.
A lire ton commentaire je ne peux m'empêcher de me demander ce qui t'empêche de faire de même : tu peux détailler ?
[^] # Re: digikam
Posté par B16F4RV4RD1N . Évalué à 1.
Il y a egalement le support de certaines fonctions raw 16bits dans les nouvelles versions. (de toute facon je n'utilise que du jpg pour mes photos, je ne suis pas "pro")
http://www.digikam.org/
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: digikam
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 4.
Et j'attend pour la photo la même chose d'un soft comme digikam. Et si amarok est sans soucis vis à vis de sa concurrence propriétaire comme iTunes, pour la photo, Lightroom ou Apperture marquent l'écart.
Donc oui, on peut importer dans la base, faire pivoter, tagger... d'un point de vue strictement fonctionnel, il ne manque rien ou pas grand chose à digikam. Reste l'ergonomie. L'ergonomie qui permet de traiter 50 images au lieu de 10 dans le meme temps, et d'avoir un résultat de meilleur qualité, le tout avec un moindre effort.
Alors ensuite, meme si la partie Raw de "rawstudio" est pas mal du tout, je pense que digikam est celui qui à le plus grand potentiel pour être le Lightroom du libre.
Je ne voulais pas trop rentrer dans le détail ici, pour pas rentrer dans le "dis moi de quoi tu as besoin, je t'expliquerai comment s'en passer. Mais j'aimerai avec immense plaisir y travailler avec Gilles Caulier à l'akademy. Cependant, 2 simples exemple:
- Gestion lumiere contraste: Avec raw studio(ou lightroom), on voit lorsqu'une image est sélectionné, l'histogramme de la photo et les réglettes pour changer contraste/expo. Avec digikam, je dois rentrer dans l'édition de la photo, je vois mon histogramme, mais non éditable (pourquoi?), puis sélectionner la fonction d'édition, et enfin changer sur une vignette. C'est plus lourd et moins pratique, alors que digikam apportait une idée intéressante sur raw studio avec les vues splités.
- Découpage: Pour recadrer une photo, gwenview (de kde4) ou Picassa, apporte un recadrage temps réel (assombrissement de ce qui sera coupé), voir http://www.informit.com/content/images/chap3_0672328305/elem(...)
mais en plus avec les tailles standards prédefini (1:1, 2:3, 4:3...), donc sans soucis vis à vis de l'aspect esthétique ou de l'impression ultérieur. C'est galère d'avoir a calculer ses ratio hauteur/largeur à la calculette pour arriver à une photo qu'on enverraient ensuite à développer... Mais là dessus, Gimp ne fait pas mieux, et krita (de KDE3, pas testé le 4 sur ce point) fait meme pire.
[^] # Re: digikam
Posté par psychoslave__ (site web personnel) . Évalué à 5.
L'ergonomie qui permet de traiter 50 images au lieu de 10 dans le meme temps, et d'avoir un résultat de meilleur qualité, le tout avec un moindre effort.
Tu parles d'ImageMagick ? :)
[^] # Re: digikam
Posté par Psychofox (Mastodon) . Évalué à 4.
Peut-être que si les quelques utilisateurs qui ont besoin de ces fonctions finançaient une bounty pour ajouter les choses qui te manquent sur digikam, ça se ferait tout aussi bien. A 200-300€ par tête et un nombre suffisant de demandeurs, y'a de quoi payer un dev pour y consacrer tout son temps pendant quelques semaines.
[^] # Re: digikam
Posté par NickNolte . Évalué à -1.
[^] # Re: digikam
Posté par plagiats . Évalué à 7.
[^] # Re: digikam
Posté par NickNolte . Évalué à 1.
Ces pros de la photos pourraient faire part de leur expertise dans le domaine en faisaint une requête pertinente et un tant soit peu élaborée.
Pas un simple "mock-up", qui mime l'interface de toshop; fait à l'arrache.
Ce n'est pas élitiste, ça ne fait que mettre en avant le côté sérieux et le professionnalisme de la personne qui demande.
mes 0,02€
[^] # Re: digikam
Posté par plagiats . Évalué à 6.
Mon point c'est : Arrêtez de nous dire que "libre != gratuit", on en a en moyenne 1 par journal, c'est chiant. C'est tout.
[^] # Re: digikam
Posté par NickNolte . Évalué à 4.
Mon point c'est : Arrêtez de nous dire que "libre != gratuit", on en a en moyenne 1 par journal, c'est chiant. C'est tout.J'estime que c'est utile, quand on voit ne serait-ce que l'amalgame fait dans le titre, on se dit que d'autres erreurs sémantiques peuvent se glisser ailleurs.
[^] # Re: digikam
Posté par plagiats . Évalué à 1.
Les discussions sur les logiciels libres pourront donc à tourner en rond sur les thèmes "qu'est-ce qu'un logiciel libre" (penso-merci, ce thème récurrent dès qu'on sort de linuxfr est ici sujet à troll moelleux), puis "libre != gratuit" (celui-là par contre, apparait à coup sûr dès qu'un journal dépasse les 50 commentaires).
Personnellement j'en fais une overdose et j'ai l'impression qu'on arrive rarement à ne pas se glisser dans ces lieux communs. Après, tu juges nécessaire de le répéter, va. C'est pas faux, et y a rien de mal à ça.
Au fait vous êtes au courant que libre != gratuit ? Parce que libre != gratuit. Et donc libre != gratuit, et libre != gratuit. Attention, je te rappelle que libre != gratuit. Attend, pour les artistes libre = gratuit mais en vrai libre != gratuit. Hey les gars, souvenons-nous que libre != gratuit.
Tu vois ? C'est pas faux, et y a rien de mal à ça.
[^] # Re: digikam
Posté par NickNolte . Évalué à 1.
Tu vois ? C'est pas faux, et y a rien de mal à ça.Le plus drôle ici, c'est toi qui est l'illustration même de ta critique. :)
Car à la base, il n'y avait qu'une seule instance de cette remarque dans ce journal.
Sinon, je dirais que tu as faux, ne serait-ce que dans la forme et je ne dis pas ça pour avoir le dernier mot, mais ta démonstration est complètement foireuse.
[^] # Re: digikam
Posté par plagiats . Évalué à 1.
[^] # Re: digikam
Posté par Thomas Douillard . Évalué à 3.
Le développement n'est pas gratuit. Il coûte, au moins en temps.
L'utilisation l'est, modulo l'apprentissage du logiciel.
La critique ... ça dépend. Mais si un "utilisateur du logiciel" à titre gratuit veut critiquer le logiciel auprès du développeur, il doit se rappeler que le logiciel ne lui coûte peut être pas à lui, mais qu'il coûte au développeur. Et que dans ce cas, pour éviter de se faire jeter comme un malpropre, il est peut être important de transformer une simple critique en véritable contribution (pas forcément en code, évidemment.)
[^] # Re: digikam
Posté par libre Cuauhtémoc . Évalué à -2.
[^] # Re: digikam
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 6.
Donc c'est pour moi une excuse que je refuse, car j'aspire à une situation ou les softs opensource grand public serait supérieur au softs proprio. Accepter cette excuse, c'est accepter que Linux serait un sous systeme incapable de satisfaire des besoins pro, ou meme expert... Non, j'aspire à ce que le monde du libre puisse etre au top. Et de nombreux softs libres montre que c'est possible, même si c'est très dur.
Ce qui est vrai par contre, c'est que là ou chez Adobe, il y a une jolie équipe... qui travaille de concert avec des photographes pro, de l'autre coté, Gilles Caulier semble porter sur ses épaules et sa motivation l'essentiel de ce qui est fait sur Digikam, et il accomplit déjà une tache réellement monumentale.
Plus qu'avec des bounty, amarok, plasma (...) ont su fédérer des communauté de développeurs/ergonomes/artistes..., parfois sur le long terme, parfois ponctuellement pour des restructurations... et arrivé à être compétitifs. Je pense que c'est aussi possible (sans etre facile) pour digikam, et ainsi rattrapper sur l'essentiel Lightroom.
[^] # Re: digikam
Posté par Thomas Douillard . Évalué à 6.
Oui et non. La question qui s'en suit, c'est sur qui faire reposer le prix de la perfection ? On sait parfaitement qu'un logiciel comme gimp, c'est de longues heures de prises de têtes, de codage, de debug, de gestion de projet, ... de plaisir aussi, mais pas que.
À partir de là, soit les moyens suivent derrière, soit ils ne suivent pas. Soit le modèle du libre est capable de fournir les moyens de la perfection, soit il ne l'est pas.
Donc la question se pose, si Gimp n'est pas parfait, à qui la faute ? Pour moi, il ne suffit pas de décrêter une situation ou les softs open source soient supérieurs aux softs proprios pour que ce soit magiquement le cas. Et dans ce cas là, tu ne peux pas, de toute manière, rejeter la faute sur les développeurs et les insulter (j'exagère) parce que le logiciel n'est pas parfait. Pour améliorer les choses, il faut un soutien, financier, en conseil d'ergonomie pertinents, ...
D'ou la question : qui ?
[^] # Re: digikam
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 8.
Blague à part, pour rentrer dans ton raisonnement, cette "excellence" perçu reposerai sur tous les contributeurs. En premier lieu l'équipe de developpement (leader, developpeurs, artistes...) bien sur, mais également le 2eme cercle (projets/librairies connexes utilisés, distro/packageurs...) et le 3eme cercle (utilisateurs, presse...). Le 3 eme cercle est tres important, car non seulement il peut faire le succès du produit, mais l'utilisateur est le contributeur de demain (1er ou 2eme cercle)
À partir de là, soit les moyens suivent derrière, soit ils ne suivent pas. Soit le modèle du libre est capable de fournir les moyens de la perfection, soit il ne l'est pas.
Les moyens ne sont pas figés: Le modèle du libre semble pouvoir potentiellement fournir ces moyens dans la plupart des applications grand public, et qui fonctionne par amélioration successive, ce qui exclue:
- Les jeux à scénario (genre qui se fini en 6-8h et qu'on ne retouche plus ensuite)
- Applications pro spécialisé et pointu
mais cela inclue lecteur/editeur texte, video, photo, navigateur internet, ...)
Mais effectivement tous n'y arrivent pas. Et cela semble tenir à pas mal de paramettres: buzz du projet, choix techniques, ambiance dans l'équipe, prise de décision (dictateur bienveillant/malveillant, consensus...), accueil des nouveaux contributeurs, ( ....).... et pour rajouter encore de la complexité, les recettes qui marche dépendent du contexte, de l'appli ...
Mais ce que je constate, c'est que dans certains cas ça marche, et d'autres non. Voir même quelques changements/décisions font passer un projet du bon coté: mozilla Vs Firefox, xfree86 Vs xorg... et pourtant, je me souviens qu'a l'époque de xfree86, on justifiait (moi y compris) l'archaïsme et la très lente évolution de xfree par la difficulté de trouver des développeurs assez compétant pour bosser sur un serveur X. Le changement impressionnant après le fork à démontré que le problème n'était pas au niveau des ressources...
Maintenant, un fork est un cas extreme, mais il y a aussi des changements différents. Comme le changement kicker vers plasma. L'équipe de dev a considérablement grossi, les contributions externe sont devenu possible.... tout à changé... Mais au prix d'un investissement considérable du leader, en plus de ses qualités personnelles. Sur les jeux KDE aussi, il y a eu un avant/apres, et j'y ai vu de près que non, les moyens ne sont pas constants du tout, mais il faut aller les chercher. Et que la différence entre le succès et l'échec se joue à peu de chose.
Exemple: Gof, développeur très méritant de Kopete, m'a raconté une fois qu'il y avait un développeur qui pourrissait tellement l'ambiance que 2 gas avaient quitté la team, et que lui-même avait failli partir. Heureusement, le "pourrisseur" est parti avant. Je suis arrivé juste après, et j'y ai découvert une équipe très sympathique, compétente et accueillante. Du coup, j'y ai pris plaisir, grace à Gof au passage, et plus tard, j'ai encouragé d'autres personnes talentueuses à rejoindre KDE... l'effet papillon. Dans le bon sens cette fois ci, mais ça aurait pu être l'inverse.
Voilà comment 1 gas, même pas leader, peut faire aller les choses dans le mauvais sens. Imagine ensuite pire, un leader sans vision qui refuse les patchs et les nouveaux contributeurs...
"Donc la question se pose, si Gimp n'est pas parfait, à qui la faute ?"
J'en sais rien, pour avoir un vrai avis, faudrait lire les mailing lists, lRC, proposer des patchs bien foutu et voir s'ils sont acceptés avec compliments et compte SVN en prime (ce qui s'est passé pour moi chez KDE), ou refusé sous un prétexte bidon.
Je ne sais pas ce qui se passe chez gimp, je ne peux faire que des constatations et des suppositions. Mais si je prends Inskcape et Gimp, 2 logiciels que j'utilise bcp, depuis des années, à la fois au travail et à la maison:
Au niveau du 3eme cercle
- The Gimp a un net avantage d'utilisateur et de notoriété (http://www.googlefight.com/index.php?lang=fr_FR&word1=gi(...) par exemple)
- The Gimp a un avantage au niveau historique également
Le tout donne un meilleur potentiel de ressource
Au niveau du 2 eme cercle:
- Les 2 se base sur GTK (et on peut pas dire que GTK soit inconnu de Gimp...)
- Les distro traitent équitablement les 2, voir package par defaut gimp alors que Inkscape est en option (sur Suse)
Et au final, c'est étonnement Inkscape qui évolue tres vite, dans le sens de ce que veulent les gens, avec des roadmap prévu, et suivis (http://wiki.inkscape.org/wiki/index.php/Roadmap ). A coté, Gimp semble stagner ou avoir stagné pendant des années, et refusé des demandes aussi basiques que les dossiers de calques. Cela me fait penser qu'il y a un problème dans l'équipe de dev (organisation, personnes, architecture...)... quelque chose ne colle pas ou n'a pas collé pendant longtemps.
Il serait même intéressant d'avoir des statistiques comparatives (nombre de commit, nombre de commiteur, turn over, évolution de ceci dans le temps, demande de fonctionnalités clos après rejet & acceptation... ).
Alors après, c'est à l'équipe de Gimp de voir.... Peut-etre que le pb est résolu et qu'on en verra les effets plus tard, ou qu'il est toujours là à pourrir le projet.
Alors, loin de moi l'idée d'insulter qui que ce soit, et surtout pas une équipe de développement OSS, et encore moins sans savoir ce qui s'y passe (ambiance, bébé ou décès, ...) . Mais je n'accepte pas trop la politique de l'autruche, et préfère largement l'attitude de Aaron Seigo, qui a humblement et publiquement analysé les problèmes de Kicker, avant d'y remédier, ou celle de Keith Packard, qui a affronté la pire situation qui soit, celle dite du "dictateur malveillant".
PS: désolé pour le roman ;)
[^] # Re: digikam
Posté par BAud (site web personnel) . Évalué à 2.
http://www.ohloh.net/projects/inkscape
http://www.ohloh.net/projects/gimp
Les analyses sur le code étant respectivement :
http://www.ohloh.net/projects/inkscape/analyses/latest
http://www.ohloh.net/projects/gimp/analyses/latest
[^] # Re: digikam
Posté par Psychofox (Mastodon) . Évalué à 2.
[^] # Re: digikam
Posté par Psychofox (Mastodon) . Évalué à 4.
[1] http://bluemarine.tidalwave.it/
[^] # Re: digikam
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
J'aime pas:
- l'interface un peu foutoir
- l'absence de support pour clens (un outils de correction des aberration geometrique)
- la gestion par copie des images qui sont bien range ailleurs (la durée de vie du layout du répertoire d'image sera infiniment plus grand (>10 ans) que la durer de vie du logiciel ! (6 mois / un an))
- l'absence de gestion par lot ( peu cherche aussi)
- l'absence de gestion des images raw ( peu regardé en faite)
"La première sécurité est la liberté"
[^] # Re: digikam
Posté par med . Évalué à 2.
Lensfun est intégré et il devrait faire tout ça très bien. Je ne sais pas s'il y a eu une version sortie depuis ou si ce sera pour la version KDE 4.
- l'absence de gestion par lot ( peu cherche aussi)
Il y a un menu « Traitement par lots »
- l'absence de gestion des images raw ( peu regardé en faite)
C'est géré via dcraw (loin d'être parfait cependant).
[^] # Re: digikam
Posté par Psychofox (Mastodon) . Évalué à 2.
Histoire d'améliorer ma culture personnelle, qu'appelles-tu "aberration géométrique" ?
[^] # Re: digikam
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 1.
http://www.dxo.com/fr/photo/dxo_optics_pro/exclusive_feature(...)
a cela, se rajoute l'anti bruit, l'anti poussiere (...) avant la mise dans le catalogue
[^] # Re: digikam
Posté par NickNolte . Évalué à 4.
Voici le soucis, le mec balance: "absence le support pour clens" et croit faire avancer la chose.
Or si cette personne qui semble connaître cet outil© faisait une proposition claire et concise de ce que cela implique avec exemples et tout le tatoin, voir même en proposant une autre méthode/approche dans la procédure - inutile de sortir des algos ou ce genre de chose une simple vue de l'utilisateur pourrait suffir - alors là du coup, sa voix gagnerait en portée.
Ça ne signifie pas pour autant que cela sera implémenté de suite, mais c'est certainement mieux qu'un: "il me faut ça™!"
Mes 0,02€ TVAC
[^] # Re: digikam
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
DXO est le grand soft (de nikon?) proprio qui fait cela bien. (cf un poste pas loin pour les fonctionnalités)
"La première sécurité est la liberté"
[^] # Re: digikam
Posté par med . Évalué à 1.
[^] # Re: digikam
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Mais souvent si tu gère les déformations géométrique pour chaque plan de couleur tu peux faire disparaitre des problèmes de couleur. (frange violette ou jaune sur des arêtes à fort contraste)
"La première sécurité est la liberté"
[^] # Re: digikam
Posté par liberforce (site web personnel) . Évalué à 2.
http://www.figuiere.net/hub/blog/?2008/07/16/620-introducing
http://gna.org/projects/niepce/
# Euh...
Posté par pampryl . Évalué à 10.
Parce que moi, The Gimp, je l'utilise aussi sur Windows et je ne dis pas pour autant que le 16bit manque à Windows...
Si j'ai un manque sur un logiciel en général, je ne dis pas que c'est la faute de l'OS. Sinon on peut faire l'inverse et dire que Windows c'est nul parce qu'il n'y a pas Vim installé par défaut ou que je ne peux pas faire un apt-get install monLogicielPréféré...
En l'occurence, Photoshop a aussi ses défauts que l'équipe de The Gimp souhaite surement éviter.
Je peux comprendre que tu as certains besoins, mais je ne suis pas sur qu'intituler ton journal "Ce qui manque à GNU/LINUX..." ou " Suite de "Ce qui manque à GNU/LINUX......." soit un bon moyen de faire avancer les choses. Je te rassure, il n'est pas obligatoire de développer ce qu'il te manque par toi même, mais bon, il faut se rappeler que ce sont des réalisations principalement bénévoles et que certaines choses ne sont pas forcément faites dans l'ordre qu'on souhaiterait. C'est le pendant d'utiliser ce genre de logiciel, 'pendant' bien souvent compensé par d'autres paramètres: gratuité, disponibilité du code source, qualité etc...
[^] # Re: Euh...
Posté par yohann gabory (site web personnel) . Évalué à 4.
Heu ... Sauf que lorsque l'on est photographe professionnel on ne peut pas travailler avec The Gimp. L'absence de gestion 16 bits est juste rédhibitoire.
En se sens, il parait à mon avis que les logiciels linux doivent être au niveau des attentes professionnelles pour faire réellement la différence.
Là où je trouve je journal très vrai c'est quand il remarque que les outils de graphismes sous Linux ne sont pas encore à un niveau de qualités suffisante pour remplir la mission que s'est donnée le libre selon moi : Donner à tous des outils d'apprentissages et de communications performants, librement distribuables, librement librement modifiables.
La seule exception notable étant bien entendu Blender ! Voila un logiciel qui balaie largement la concurrence. Outil utilisé par les professionnels et à la disposition du grand public et de l'étudiant.
Seulement, voila, la majorité des grandes écoles ont des contrats avec Maya et autre. On peut se battre contre cela, la qualité de Blender suffit. J'ai essayé avec Gimp et je me suis fait rétamé en moins de deux.
Ceci dit, je ne pense pas que Photoshop soit à l'origine du moindre toolkit graphique ...
[^] # Re: Euh...
Posté par pampryl . Évalué à 4.
Je nie pas que certaines choses manquent à certains... Mais attention à ne pas faire le raccourci "Logiciel libre = Linux" (exemple: The Gimp étant aussi dispo sous Windows)
Il n'est absolument pas question de "logiciels linux" (du moins pas dans ceux cités dans le journal)!
[^] # Re: Euh...
Posté par PegaseYa . Évalué à 2.
Bon, il faut quand même rétablir une réalité. Le 16 bits, c'est juste pour dire: c'est moi qui ait la plus grosse...enfin, les plus gros bits.
16 bits par canal, ça veut dire 2^(3*16) = 3x10^14 (env) couleurs différentes si je me trompe pas, pour 3 canaux RGB.
L'oeil humain n'est pas capable de distinguer ça. Déjà avec 8bits, il a du mal (preuve: créez une image en 8bits sur un canal, c'est à dire en niveaux de gris, et mettez y que des 1 et des 0... le premier qui fait la distinction des pixels m'envoie le premier spam!)
Et j'ose affirmer que le but ultime du photographe, c'est quand même que ses photos soient vues...
Pour ce qui est de l'édition, si on prend des formats petits, genre des livres ou des objets manipulables, l'élément important n'est pas la quantité de couleurs disponibles mais la définition d'impression (et donc à la source, la définition des images).
Pour ce qui est des grands formats, genre affiche 4x3m, approchez vous, et vous verrez que la définition est vraiment pourrie: on voit des gros points.
Enfin, pour terminer avec mon expérience personnelle, je suis photographe amateur (et je l'espère éclairé), je fais des stages photos et j'observe le travail de professionnels. Ceux-ci utilisent c'est vrai plus toshop que gimp. Mais c'est plus:
1- par habitude
2- parce que ça va plus vite (pour réaliser un enchainement d'opérations)
Et ce n'est pas parce qu'il manque des fonctionnalités à gimp.
En conclusion, je dirais que l'histoire du 16 bits, c'est la fonctionnalité ultime qui fait semblant de servir, et que certains présentent pour se rassurer et se persuader que le libre avec gimp, c'est-quand-même-nettement-moins-bien-la-preuve-les-pros-l'utilisent-pas.
[^] # Re: Euh...
Posté par Aldoo . Évalué à 9.
Le problème c’est quand tu veux traiter une photo 8 bits et que le résultat final reste potable.
Cas d’école : photo sous-exposée, on veut augmenter la luminosité et le contrate.
Sur l’image de départ, supposons qu’aucun pixel n’a une valeur supérieure à 2⁴ sur les 2⁸ possibles.
On aura beau appliquer toutes les transformations qu’on veut afin d’étaler les valeurs sur tout le spectre des valeurs, il restera que seules 2⁴ valeurs seront utilisées au total (sur 3 canaux, ça fait 4096 couleurs… ça fait peu).
Si on avait eu une photo en 16 bits, on aurait pu avoir un résultat final en qualité 8 bits.
Ce raisonnement est aussi utilisé pour l’audio, avec les cartes sons actuelles qui gèrent l’échantillonnage 24 bits à 192 kHz ou plus, là où le CD se contente de 16bits à 44,1 kHz.
[^] # Re: Euh...
Posté par ndesmoul . Évalué à 5.
J'ai un réflex et le format raw de l'appareil permet des traitements tout simplement impossibles avec le jpeg. En particulier avec une image en raw il est possible dans une certaine mesure de récupérer des détails dans des zones cramées (surexposées) là ou dans la version jpeg il n'y a que du blanc. Et pourtant le raw de mon appareil c'est pas du 16 bits mais seulement du 12 bits.
[^] # Re: Euh...
Posté par Anonyme . Évalué à 3.
C'est pas par ce que c'est fait par des benevoles, de facon generale un logiciel est rarement fait exactement comme on le souhaiterait, sauf quand on le fait soit meme.
[^] # Re: Euh...
Posté par pampryl . Évalué à 2.
Ais je dis l'inverse? ;-)
# Krita
Posté par freejeff . Évalué à 4.
Je n'ai jamais eu de problèmes avec !!!
Il y a plein de fonctions intéressantes !
Il est clair qu'il ne peut rivaliser avec la tonne de plugins présent dans The Gimp, mais je le trouve drôlement bien pensé, tant dans la gestion des calques que dans l'ergonomie générale !
Peut être est-ce plutôt un problème de version ou de paquets, mais de la à en faire une critique si sévère ...
[^] # Re: Krita
Posté par Aefron . Évalué à 7.
... certes il y a encore des problèmes : par exemple, je n'arrive pas à ouvrir des gros projets Gimp (plein de calques, plein de pixels) avec lui...
Il y a certes aussi beaucoup moins de plugins que pour Gimp... après, on peut aussi parler de l'état de certains plugins de Gimp : genre, le filtre "flammes", pour faire des "fractales artistiques" - au-dessus de 2500x2500 (à peu près), il segfaulte depuis des années... et ne semble plus être maintenu depuis des années non plus (alors qu'il est génial ce filtre... damned)...
Maintenant, sorti de ça, j'aime beaucoup Krita... déjà, il est en QT (et ça, çaylebien)... par exemple, aussi, lui, au moins, il a les dossiers de calques (ce qui fait que je trouve Gimp, à défaut d'inutilisable, d'une lourdeur agaçante, quand on travaille des image avec au moins une dizaine de calques)... et je pense d'ailleurs vraiment, à terme, abandonner Gimp pour Krita.
Par contre, j'aimerais bien savoir ce que Krita a "d'expérimental, impraticable, inutilisable"... des arguments seraient donnés encore, je voudrais bien... mais là, c'est vraiment au ras des pâquerettes, comme troll.
[^] # Re: Krita
Posté par abramov_MS . Évalué à 3.
# forums.
Posté par hervé Couvelard . Évalué à 8.
>>quand même pas mal d'aide utile sur les fora d'ubuntu :) "
Euh, sans vouloir faire le rabat-joie, l'aide chez ubuntu reste quand même assez sommaire, c'est juste des "chez moi j'ai fait ça."
Si tu veux une vrai aide, va chez gentoo...
Et je suis debian addict intégriste, te dire la tare que je porte. :-)
[^] # Re: forums.
Posté par Aefron . Évalué à 4.
T'as oublié le grand classique : "si ça ne marche pas, fais sudo"... du grand art : si tu ne comprends plus où tu en es et ce que tu fais, agis avec les droits root...
[^] # Re: forums.
Posté par Octabrain . Évalué à 8.
[^] # Re: forums.
Posté par Gniarf . Évalué à -3.
[^] # Re: forums.
Posté par libre Cuauhtémoc . Évalué à -5.
Chapeau mon gars
[^] # Re: forums.
Posté par Aldoo . Évalué à 10.
A — À l’aide, j’ai un problème : je n’arrive pas à faire X.
A — up !
A — up !
B — tu as essayé de faire Y ?
C — me too, X' ne marche pas !
D — moi j’ai fait Z (NDLR : qui n’a rien à voir), et X" marche
E — me too !
F — me too !
A — ça ne marche pas !
… et souvent :
A — Ah ça y est, j’ai trouvé comment faire.
… et optionnelement, 6 mois après
G — j’ai le même problème, A, comment tu as fait pour le résoudre ?
En général, ça en reste là.
Malgré tout, si on s’en tient aux forums, c’est quand même avec ceux d’Ubuntu qu’on a le plus de chance de trouver une réponse, question de masse critique.
Mais les wiki de gentoo, c’est quand-même un peu plus efficace !
(même si Ubuntu et les autres distros ont aussi des wikis, il est rare qu’ils rivalisent de précision et d’exhaustivité avec ceux de gentoo !)
# Y a des fois...
Posté par ahuillet (site web personnel) . Évalué à 9.
[^] # Re: Y a des fois...
Posté par feth . Évalué à 9.
# Rapport de bugs
Posté par Marc Poiroud (site web personnel) . Évalué à 3.
Je suis comme un con avec mes bugs car je ne maitrise pas suffisement l'anglais pour expliquer un problème.
Faut bien prendre conscience que le rapport de bug est juste limité aux anglosaxons et élimine le reste du monde.
[^] # Re: Rapport de bugs
Posté par Aefron . Évalué à 4.
... c'est surtout qu'il faut quelqu'un capable de lire ta langue, pour corriger le bug que tu signales... parce que bon, si tu veux qu'on ouvre les rapports de bugs dans la langue de son choix, quitte à ce que personne d'intéressé ne puisse les lire... euh... c'est techniquement très faisable, mais comment dire ?
Tu proposes juste de déplacer le problème, là... parce que si tu ne peux pas écrire de rapports en anglais, qui te dit que les devs du projet parlent français ? Ca revient strictement au même, ce que tu proposes...
[^] # Re: Rapport de bugs
Posté par feth . Évalué à 3.
Les logiciels sont traduits de l'anglais vers plein de langues. Il serait possible de prévoir un système de rapport de bug permettant à l'utilisateur de construire des phrases à l'aide de briques sémantiques traduites dans sa propre langue.
Ces briques seraient d'une part génériques ("J'étais en train de faire", "j'ai eu un SIGSEGV", "<insertion config systeme et matérielle>", "saisir du texte" ...), d'autre part fonctionnelles : chaque logiciel pourrait proposer un paquet de briques pour rapporter des bugs ("Activité: Composer un mail", "Activité: lire un fichier ogg").
Le résultat serait une liste de prédicats décrivant le bug.
Alors bien sûr ça serait limité, mais bon, c'est une idée en l'air à une heure du matin.
[^] # Re: Rapport de bugs
Posté par Epy . Évalué à 4.
Je caricature avec la langue maternelle mais c'était pour tabler sur toutes les langues sauf l'anglais après tout.
Certes, il faudra donc que cette personne chargée de traduire aie parfaitement compris le bug avant de pouvoir le réexpliquer, et donc connaisse très bien le soft et puisse éventuellement essayer de reproduire le bug.
[^] # Re: Rapport de bugs
Posté par Maclag . Évalué à 3.
Ca va devenir un boulot à temps pleins, traducteur amateur de logiciels libres.
[^] # Re: Rapport de bugs
Posté par B16F4RV4RD1N . Évalué à 2.
Pourquoi mozilla, gnome, krita etc arrivent a faire qque chose de simple et fonctionnels, et pas debian ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Rapport de bugs
Posté par Aefron . Évalué à 3.
... et pour le configurer, "dpkg-reconfigure exim4-config" est ton ami : en deux coups de cuiller à pot (quelques questions en ncurse), hop, tu as un MTA fonctionnel, rapport à ce que tu veux en faire (on peut dire ce qu'on veut de la présence d'un gros MTA par défaut, au moins, il y a eu de l'effort sur la facilité à le configurer)...
Ca, c'est pour les machines sans clickodrome... pour celles avec, il y a reportbug-ng (ou gnome-reportbug, pour les gens qui ont des goûts étranges)... et là, pas besoin de MTA : un MUA suffit.
Maintenant, certes, si on pouvait soumettre les bugs Debian sans avoir à gérer un mail localement, via de la page web, ce serait classe quand même.
[^] # Re: Rapport de bugs
Posté par feth . Évalué à 3.
Je préfère ma solution parce qu'elle est automatique justement, et que des prédicats identiques le resteraient à travers les langues.
Idéalement le système de rapport de bugs pourrait détecter les doublons de façon fiable (avec un très très fort pourcentage de garantie lorsque les traces sont fournies).
# ...
Posté par Anonyme . Évalué à 7.
Oui enfin si la personne est pas capable de passer 2 minutes pour trouver le site de gimp, je doute que ses suggestions et propositions soient vraiment interessantes. Et puis c'est bien d'avoir des suggestions et propositons, mais après faut surtout les implementer. Si gimp a pas encore le support 16 bits, à mon avis c'est pas par ce que personne en a encore eu l'idée.
[^] # Re: ...
Posté par Prae . Évalué à 4.
Cette affirmation me choque;
C'est pas parce que une personne ne sait pas faire "un truc" d'un côté que ses suggestions et ses propositions soient inintéréssantes de l'autre.
Je pense qu'il y a beaucoup de logiciel ou de développeurs qui se basent sur des observations de personnes externes (et dont les observations sont plus que pertinentes), tout simplement parce que tu n'es pas forcément l'utilisateur final et que tu n'es pas forcément au coeur du métier où le logiciel va être utiliser en définitif.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par NickNolte . Évalué à 1.
l'equipe veut garder le control et fait fuir les nouveaux.Comment garder le contrôl d'un truc libre?
Si tu restes dans la branche officielle, je comprendrais mais ici? Ça n'a pas empêché de faire des Gimpshop ( pas très convainquant ) ou des Cinepaint.
Faire fuir qui donc?
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Pour réussir un fork, il faut dépasser l'original assez rapidement sinon l'effort s'essoufle. C'est comme cela que cela a marché pour xorg et que cela a foiré avec cinepaint.
Gérer un fork et participer n'est pas un effort comparable du tout !
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Anonyme . Évalué à 3.
Oui oui, c'est une bonne chose d'avoir des observations de personnes externes, mais si la personne ne veut pas le faire par ce qu'il faut ouvrir un navigateur web et passer 2 minutes pour trouver la bonne section du site je suis pas sur que la personne prenne le temps d'écrire quelquechose de vraiment interessant ...
[^] # Re: ...
Posté par Aldoo . Évalué à 4.
# Gimp
Posté par psychoslave__ (site web personnel) . Évalué à 6.
En l'occurence tu rales sur beaucoup de limitations de gimp, qui sont bien présentes et bien connues, mais est-ce que tu suis un minimum le développement de ce logiciel de manière à avoir entendu parlé de GEGL ? Cette bibliothèque sera intégré dans gimp 2.6 et devrait commencé à être pleinement exploité avec gimp 3.
De plus celui qui veut participer à l'amélioration de gimp, il tombe très vite sur http://www.gimp.org/develop/ et donc http://gimp-brainstorm.blogspot.com/ où les utilisateurs ont la paroles pour présenter leurs bonnes idées.
# suis-je idiot ?
Posté par Duncan Idaho . Évalué à 5.
C'est mes yeux ?
[^] # Re: suis-je idiot ?
Posté par psychoslave__ (site web personnel) . Évalué à 6.
# Dans le libre il y a des sources
Posté par tiot (site web personnel) . Évalué à 5.
Sur http://bugzilla.gnome.org/browse.cgi?product=GIMP tu remarqueras qu'il y a plus de bogue dans la catégorie « enhancement » (amélioration). Le support 16 bit a été demandé en 2002 http://bugzilla.gnome.org/show_bug.cgi?id=74224 à première vue c'était quelque chose qui demandait beaucoup de changement. De là est parti le projet GEGL qui est maintenant utilisé par GIMP 2.5 (version de développement).
Tout ça pour dire que c'est bien la demande des utilisateurs et des professionnels qui ont abouti à une nouvelle fonctionnalité de GIMP qui sera présente dans la version 2.6. Après tu peux toujours te plaindre du temps des changements mais regarde le nombre de développeur sur le projet (un aperçu sur [http://developer.gimp.org/NEWS] et [http://www.gegl.org/#_code]).
Je pense que Gimp a plus besoin de développeurs que d'un truc pour faciliter les suggestions.
Pour le titre de mon commentaire c'est juste par rapport à ton paragraphe qui ne présente aucune source ni aucun retour d'expérience. On a la furieuse impression que tu parles d'un truc sans vraiment connaître la chose.
# Est-il possible de migrer vers Linux pour l'infographie ?
Posté par NickNolte . Évalué à 6.
platforme comme Linux:
http://www.tdt3d.com/articles_viewer.php?art_id=126
Ça a fait du chemin dans les mentalités en tout cas.
[^] # Re: Est-il possible de migrer vers Linux pour l'infographie ?
Posté par feth . Évalué à 1.
[^] # Re: Est-il possible de migrer vers Linux pour l'infographie ?
Posté par Psychofox (Mastodon) . Évalué à 4.
ton exemple n'en est pas un. On peut te trouver des trucs nuls fait avec les meilleurs outils aussi, ça n'en fait pas une preuve qu'ils sont bons ou mauvais. Dans toute création artistique, l'oeuvre n'a pas grand rapport avec ses outils. Certains artistes font des trucs géniaux avec 3 foisrien, d'autre font de la merde avec les meilleurs outils. Bref les outils ne sont qu'une aide, pas une matière à l'oeuvre.
[^] # Re: Est-il possible de migrer vers Linux pour l'infographie ?
Posté par feth . Évalué à 2.
# Gimp un logiciel phare du monde libre
Posté par Unixfix le Gaulois . Évalué à 4.
Gimp est un logiciel de création et manipulation d'image venu avec l'avènement de la photo digitale sur le tard à la photographie.
Contrairement à certains autres produit phare du LL, GIMP est un logiciel communautaire sans soutien direct d'une société finançant les développeurs.
Souvent dans ce cas, les développeurs même s'ils s'en défendent, se soucient peu des souhaits (besoins?) des utilisateurs. Après. Un parfait exemple de cet état d'esprit ce trouve dans la FAQ de GIMP:
When will an MDI/nested windows be implemented?
This is often requested by MS Windows users who lack some of the window management features common in other operating systems. An MDI interface is largely considered a step backwards by interface designers. The core GIMP developers share this sentiment, so don't expect them to implement the feature any time soon. However, there are no objections to the feature itself. So far only the Deweirifyer plugin attempts any sort of a fix. It seems to be good enough for some, but not for others. If you are interested in implementing MDI support bug 7379 is the place to start.
Après tout ces développeurs codent pendant leur temps libre et peuvent donc faire ce qu'ils veulent. Et cela est sans conséquences commerciales. Cela nuit "seulement" à l'adoption du logiciel libre mais visiblement cela ne les concernent pas !
[^] # Re: Gimp un logiciel phare du monde libre
Posté par GPN . Évalué à 5.
Que ce soit sous Gnome, KDE, Windows, le multifenêtre de Gimp m'a toujours fait royalement chier.
A chaque fois, on me répond "mauvais WM, change de WM", mais je n'ai pas envie de changer pour une appli...
Rien que pour ça je préfère utiliser Krita si j'en ai la possibilité.
[^] # Re: Gimp un logiciel phare du monde libre
Posté par Psychofox (Mastodon) . Évalué à 2.
[^] # Re: Gimp un logiciel phare du monde libre
Posté par GPN . Évalué à 2.
Pas très Mme Michou friendly...
[^] # Re: Gimp un logiciel phare du monde libre
Posté par plagiats . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.