Journal : Suite de "Ce qui manque à GNU/LINUX.......
Posté par maderios () le 22 juillet 2008
0
Journal faisant suite à : http://linuxfr.org/~maderios/26956.htmlPré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 :) "
> Lire le journal (88 commentaires, moyenne: 3,6).
Vous avez demandé le commentaire #952158.
Run by 
Cette page a été générée par Templeet en 0.1155s (dont 0.0081 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
digikam
"Digikam, le logiciel le plus abouti dans le genre mais qui semble plus adapté aux besoins de l'amateur qu'à ceux du professionnel."
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
De la finition, de l'ergonomie de la simplicité, voilà ce qui est pour moi + urgent sur digikam.
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....
----------------------------------------------------------------
KDE - Kopete - Oxygen - KDEgames
[^]Re: digikam
Plusieurs non-informaticien(ne)s de ma connaissance importent leurs photos avec l'outil d'import de digikam (avec une prévisualisation, très pratique), ensuite ils/elles sélectionnent toutes les photos qui ont besoin d'être pivotées au sein de digikam, et les pivotent en un clic.
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
idem pour moi, j'ai un dossier de photos géré par digikam, j'importe toutes mes nouvelles photos dedans avec la date de l'année ainsi que du mois (dans un sous dossier), et ensuite je classe tout dans digikam avec son système de tags, et je pivote égalemt depuis digikam puisqu'il le fait très bien.
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/
You can't grep dead trees...
[^]Re: digikam
Pour prendre une analogie, les logiciels de musiques comme winamp/XMMS gérent les mp3, les tags, les playlists... mais des softs comme amarok, itunes..., bien étudié au niveau ergonomie, permettent de gérer bien bien mieux une collection ou une écoute.
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.
----------------------------------------------------------------
KDE - Kopete - Oxygen - KDEgames
[^]Re: digikam
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 ? :)
Le wiki de l'association culture libre : venez participer !
[^]Re: digikam
ceci-dit tu compares un logiciel à 200€ qui ne fonctionne que sur Mac OS X (et dont tu dois repayer 50% du prix à chaque mise à jour) et dont tu n'as aucune incidence sur son évolution à un soft qui ne te coûte rien, ne te coûtera rien, et auquel tu peux participer à l'évolution (et dans le cas de lightroom c'est presque 300€ et des mises à jours tout aussi payantes).
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
PsychoFox: Libre ne veut dire que gratuit dans la tête d'un graphiste.
[^]Re: digikam
Vous commencez à faire vraiment chier à seriner libre != gratuit. CA VA ON SAIT. On est au courant, merci. 'tain, c'est lourd à la fin.
La mort est un phénomène naturel qui se produit par l'avalement répété de petites quantités de salive au cours d'une grande période de temps. - George Carlin
[^]Re: digikam
C'est lourd de comparer une boîte multimilliardaire comme Adobe avec un groupe de poilus bénévole sur qui on ne fait que râler.
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
Je vois pas le lien entre ta réponse et mon post.
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.
La mort est un phénomène naturel qui se produit par l'avalement répété de petites quantités de salive au cours d'une grande période de temps. - George Carlin
[^]Re: digikam
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
Super.
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.
La mort est un phénomène naturel qui se produit par l'avalement répété de petites quantités de salive au cours d'une grande période de temps. - George Carlin
[^]Re: digikam
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
Ton post est brillamment argumenté, félicitations. Sinon une instance par journal dans chaque journal, pour ceux qui suivent linuxfr régulièrement, c'est lourd.
La mort est un phénomène naturel qui se produit par l'avalement répété de petites quantités de salive au cours d'une grande période de temps. - George Carlin
[^]Re: digikam
J'abonde, pour sortir du pûr libre != gratuit, on peut décomposer:
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
je dirais même plus: libre << gratuit
[^]Re: digikam
Je compare un soft proprio à un soft libre. C'est le theme de ce journal. Et l'aspect payant/libre n'empèche bcp de penser qu'Amarok est meilleur iTunes ou WMP, ou que Firefox est meilleur qu'Opera ou IE.
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.
----------------------------------------------------------------
KDE - Kopete - Oxygen - KDEgames
[^]Re: digikam
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.
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
La perfection, c'est beaucoup demander... contentons nous de l'excellence. ;)
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 ;)
----------------------------------------------------------------
KDE - Kopete - Oxygen - KDEgames
[^]Re: digikam
Pour quelques statistiques, tu peux regarder
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
Au fait as-tu déjà essayé Bluemarine[1] ? Je ne l'ai jamais essayé mais j'avais vu un article qui le présentait comme un concurrent open source (Apache License) à Lightroom et Aperture...
[^]Re: digikam
et le fameux lien oublié:
[1] http://bluemarine.tidalwave.it/
[^]Re: digikam
J'utilise digicam uniquement pour l'integration de GreyStoration.
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)
[^]Re: digikam
- l'absence de support pour clens (un outils de correction des aberration geometrique)
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
- l'absence de support pour clens (un outils de correction des aberration geometrique)
Histoire d'améliorer ma culture personnelle, qu'appelles-tu "aberration géométrique" ?
[^]Re: digikam
Bon, désolé, c'est la présentation d'un softs proprio, mais sur les differents onglets de cette page, il y a differents type de distorsion et les traitements proposés, mais les pages sont bien explicatives:
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
----------------------------------------------------------------
KDE - Kopete - Oxygen - KDEgames
[^]Re: digikam
Histoire d'améliorer ma culture personnelle, qu'appelles-tu "aberration géométrique" ?
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
C'est un outils en ligne de commande qui a une base de donné d'un grand nombre d'objectif et de leur défaut à corriger.
DXO est le grand soft (de nikon?) proprio qui fait cela bien. (cf un poste pas loin pour les fonctionnalités)
[^]Re: digikam
Bon de toute façon pour ce cas précis, c'est déjà implémenté dans digikam comme je disais plus haut. Cependant c'est vrai que c'est plus pratique pour les développeurs d'avoir un souhait clairement argumenté dans leur bugzilla ou autre. La boule de cristal pour savoir ce que veulent les utilisateurs fonctionne de manière assez aléatoire.
[^]Re: digikam
J'ai mélanger abération chromatique et déformation géométrique (coussin/barrique ou encore barillet/cousinet).
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)
[^]Re: digikam
Tu devrais regarder du côté de Niepce Digital. C'est encore en développement, mais cela devrait faire ce que tu veux au final je pense. Bon par contre c'est en GTK.
http://www.figuiere.net/hub/blog/?2008/07/16/620-introducing
http://gna.org/projects/niepce/