Une série de commentaire qui montre bien l'état d'esprit moyen des utilisateurs de linuxfr
1°/ le style nul
Je suis d'accord, mais au moins l'article à le mérite d'exister
2°/ le contenu inutile
Non il montre bien la vision de l'utilisateur de base d'un ordinateur. Il connait windows et c'est tout. Ok certains connaissent aussi Mac, mais ça va pas plus loin. Il y a encore une très grosse majoritée des utilisateur qui : soit ne savent pas qu'autre chose éxiste, soient pense que c'est réservé au monde professionel des grands chercheurs ou autre.
Vista est une régression ? bah si t'es pas content achète-le pas et voila.
Comme tous les gens qui ne savent pas qu'il y a autre chose, il ne peut pas ne pas l'acheter si il veut améliorer sont materiel.
Tu as vista et tu ne veux vraiment pas l'utiliser ? installe Ubuntu ou autre, c'est gratuit ça coûte pas cher.
Il ne connait pas, tout comme beaucoup de gens qui sont intéressés par les downgrading vers XP. Car XP ils conaissent et pour eux ça marchait très bien avant, ils ne savent pas qu'il y a autre chose qui marche "mieux" (enfin, question de point de vue)
Ce n'est pas vista ou microsoft qu'il faut critiquer, mais la vente liée. Vendre un système merdique c'est pas encore interdit.
Il critique pas directement windows ou microsoft, mais la regréssion et le fait qu'il faille payer pour revenir à quelque chose de plus vieux et théoriquement moins bon.
Parler de la vente liée sans prononcer une seule fois le terme « vente liée », sans parler de la possibilité d'un pc sans OS ou sans logiciel imposé par le constructeur, sans parler des alternatives à Windows… Comment dire… Il aurait peut – être dû se renseigner avant d'écrire son article ?
Et pour ce renseigner tu fais comment, une super recherche hyper approfondie ? Pour un billet d'humeur comme celui la ou le sujet c'est la régression téchnologique et le fait de payer pour changer du neuf comme du vieux ?
Pour un linuxiens les termes vente liées et système alternatifs semblent évident et pourtant demande au gens autour de toi, pas grand monde en dehors de nous ne va te dire "mais oui, bien sur".
Fais une recherche sur internet pour te documenter et tu vas voir que avec des recherches classique que fera quelqu'un qui ne connait que windows, c'est pas facile de tomber sur la vente liées, et quand tu tombe dessus c'est plutot anecdotique, rien qui te laisse penser que c'est vraiment le coeur du problème.
à aucun moment il n'évoque l'alternative à windows, cela reste très consensuel, voilà un bon article digne de libé qui enfonce les portes ouvertes... (ou les fenêtres ouvertes si vous préférez...)
C'est un billet d'humeur dans la rubrique culture, par un article technique dans la rubrique technologie. L'auteur soulève le problème de la régression technologique c'est d'ailleur surement pour ça (plus que la crainte de procès) qui fait qu'il ne dit pas que vista est une merde. Il laisse entendre que les gens préfère XP et veulent retourner à ce qu'ils avait avant, et il critique tout le bordel que c'est. D'un point de vue technique on s'en fout. Par contre d'un point de vue un peu plus philosophique c'est quand même marrant que tout le monde refuse ce "progrès" et ce casse le cul et paye encore plus cher pour du "moins bien"
Bref plein de commentaires sur : c'est nul il parle pas de nous (linux, vente lié...) Mais dans cet article on s'en fou, parler de ces trucs n'apporterais rien à l'article, et il y a une grosse majoritée de la population qui n'en as jamais entendue parlée et qui fuierait l'article alors que sont vrai thème les intéresse peut-être...
Donc plutôt que de critiquer, expliquer lui clairement que ce qu'il dit est fortement liés à d'autre thème, et donnez lui les bon pointeurs pour faire un article là-dessus, que ce soit constructif au moins.
Sans faire de commentaire sur le fond du débat, mais ta liste ne représente strictement rien...
Quelle quantité d'amélioration y a-t-il dans chaque version que tu cite ? Est-ce que l'équipe de Gcc fais une nouvelle version à chaque correction d'une faute d'orthographe ? Est-ce qu'il y a une nouvelle version à chaque fois que l'amélioration de perf atteint 10% de gain par rapport à la précédente ?
Bref, ce n'est pas parce qu'il y a eu de nombreuse version depuis la 3.3.5 que les perfs sont meilleur. Donc, on a des bench par rapport à la 3.3.5 et ces tout. Pour avoir des infos face au dernières version, il faut là aussi faire des benchs.
Il faut la même chose que pour les autres :
- un encoder qui préconfigure tout pour obtenir une video correcte pour madame michu et autres, le tout très simple d'emploi sans prise de tête ;
- un encodeur avec toutes les options disponibles et une bonne doc sur comment obtenir la meilleure qualité possible afin que les geeks et les pros fassent de belles videos.
Il y a déjà les filtres pour directshow, c'est pas suffisant ?
Dans mes souvenirs, IE peu lire les vidéos si il y a les filtres, donc il suffit d'un liens vers les filtres avec un installeur et c'est bon, non ?
Revoquer des clés, ça empêchera les gens de lire des Blu-Ray les plus récents sur les premiers appareils (vendus à prix d'or) ou, au contraire, de lire sur les appareils récents (mis à jour), les premiers disques vendus.
Je dis peut-être une connerie mais les anciens lecteurs doivent pouvoir être mis-à-jours. Je pense quand même pas qu'ils sont stupide au point de ne pas l'avoir prévu.
Et rien n'empêche les nouveau lecteur d'embarquer aussi les anciennes clés pour lire les anciens blue-ray ?
Pour moi la révocation des clées c'est juste pour permettre des "générations" de disques et s'assurer que lorsque l'une d'elles est crackée on passe à la suivante. Donc pour lire un disque il faut avoir cracké la clef de sa génération.
Au final le principe reste stupide et fait bien plus chier l'utilisateur légitime que le pirate, mais ce n'est pas pour autant que tu dois jeter ton matos à chaque fois qu'une clef est cassée.
Pourquoi l'avoir porté en natif, d'autant plus qu'il fait près de 10 Mo contre la version flash qui doit en faire moins de 1 ?
Peut-être par ce que certains n'on pas flash car il n'utilisent pas une architecture supportée ou par ce qu'ils ne veulent pas de logiciels non libre sur leur ordinateur.
Même sans aller chercher ce genre de raisons, si je voulais écrire ce genre de petit jeu, pour moi ce serais en C+OpenGL.
Pourquoi ? Tout simplement car c'est une combinaison que je connais bien, et je sais que je n'aurrais pas à me prendre la tête. Je n'aurais aucune envie d'apprendre Flash, ActionScript ou autre...
Si tu préfère la version flash, utilise la, il n'y a pas de problème. Chacun peut choisir la version qu'il lui convient.
L'argument est question était pour montrer une des intérets de plus de 8bits par canal sur un xeemple relativement simple à comprendre, dans la pratique il y a un plus de choses à prendre en compte.
Tout ce que tu dis est vrai pour du jpeg mais pas pour du raw.
L'objectif du fichier RAW est de contenir les données brutes issues du capteur. Le moins possible de traitement est fait dans l'appareil.
Pourquoi ? Car l'appareil dispose d'un temps, du puissance et d'une mémoire limité par rapport à un ordinateur moderne. Il est donc possible au dévellopement d'utiliser des algorithme beaucoup plus évolués et performants.
Donc un fichier raw reçoit les données brutes, c'est-à-dire une image en niveau de gris (chaque cellule ne capture qu'une des trois couleurs) linéaire (le capteur est linéaire, pas le choix...). Chaque pixel correspondant à une céllule du capteur. Les premières étapes sont généralement :
- le dématricage, pour passer de l'image en niveau de gris à une image couleur.
- Un convertion gamma pour quitter le mode linéaire
- La balance des blancs
Sur un fichier raw ces étapes sont éffectuées sur l'ordinateur pas sur l'appareil, donc dans ce cas, on s'en fout des algos utilisés par l'appareil.
J'ai parler de la sur-exposition car c'est une chose très utilisée par les photographes. Comme tu le dis la capture est linéaire mais pas la vision humaine, il y a donc une conversion à éffectuer.
Cette convertsion fait que la gamme sombre va être étirée et la gamme claire compressée. Il y a donc perte d'information dans les tons clairs car au final tu auras par exemple 200 valeur en linéaire converties en 100 valeurs dans l'image finale. Et un effet de peigne dans les valeurs sombres.
Ces pour cela que l'on conseil de surexposer un peu les photos lors de la prise de vue en raw. À la conversion on réexpose correctement l'image de manière à avoir une quantité d'information relativement homogène sur toute la gamme.
Et ça, ce n'est possible que parce que on travaille avec plus d'information que le résultat final. (voir par exemple [1])
Ensuite, pour ce qui est de l'exposition justement. L'appareil fait ce que tu lui demande et heureusement...
Tu peut lui demander d'exposer correctement tes photos et il fera de son mieux, mais il y a des situations ou c'est difficile, d'autre ou ces impossible. Donc c'est toujours valable d'avoir de la marge pour rattraper ce qui est possible.
Tu peut aussi régler toi même ton exposition et dans ce cas la, l'appareil te laissera faire, et si tu t'es planter, c'est cool aussi de pouvoir corriger...
Enfin, il y a des situations ou une sur/sous-exposition est voulue, ça permet d'obtenir des effets très chouette sur certaines photos. Par contre il est souvent agréable de pouvoir retrouver quelques détails dans ces zones pour leur donner un peu de volume.
La sur/sous-exposition est un des éléments qui, quand il est bien maîtriser, permet de faire des chose extrèmement intéressante, à condition d'avoir les outils pour.
Donc en gros, la conversion analogique numérique (dans le capteur) ne fais que capturer ce que tu lui demande (encore heureux ;-)) et donc il est nécéssaire d'augementer la résolution afin de pouvoir faire le meilleur traitement possible derrière et d'avoir la plus grande flexibilité.
Un exemple tout simple : Tu fais une photo pendant un concert. Le chanteur à un projecteur braqué sur lui et le batteur au fond est mal éclairé. En jpeg tu as de forte chance d'obtenir un chanteur cramer et un batteur boucher (san mauvais jeu de mots...)
Avec du raw, tu sur-expose d'1 ou 2 EL et à la convertion tu affine l'exposition des différentes zones de la photos pour obtenir une photo ou le chanteur et le batteur sont bien exposé.
Pour ce qui est de la comparaison RAW/JPEG, je suis daccord qu'il faudrais mieux comparer avec du png. Le problème c'est que tous les appareils produisent du jpeg, donc si tu veux comparer avec du png, et bien ton fichier png soit tu l'obtient a partir du jpeg (no comment) soit à partir du fichier raw (ce qui biase le test...)
Mais bon... je suis d'accord de me taire sinon je risque de me faire incendier pour hérésie compulsive...
Surtout pas, c'est bien qu'il y ait du débat. J'essaye de ne pas trop m'enflammer mais si je deviens méchant n'hésitez pas à me moinser....
Merci pour l'information. Cet un anglicisme que je ne connaissait pas et que je n'aurais pas soupsoné.
Par contre je ne comprend pas ton premier commentaire dans ce cas. Pourquoi donner une définition du mot anglais et qui donc est fausse pour le mot français sans rien préciser de plus ?
Donc, au final un petit "s/assumer/supposer/g" avec un sed qui est capable de gérer les transformations gramaticales...
Je précise pour que ce soit clair : "ne rien assumer sur la manière dont le gestionaire de fenêtre gère les fenêtre"
Il est bien entendu que le gestionaire de fenêtre est fait pour X11 et les standards associés, par contre il peut organiser les fenêtres et interagir avec l'utilisateur comme il veut.
Gimp à été dévelopé sous linux pour une interface graphique utilsant X11. C'est d'ailleur pour cela qu'ils ont dévelopé GTK, pour séparer la gestion des fenêtres et widget de la partie graphique.
Et donc les deux ont été dévelopé en respectant les standards X11, c'est à dire notement ne rien assumer du gestionnaire de fenêtre, mais lui donner des infos sur les fenêtres à gérés.
Ensuite il à été porter sous windows. Donc les problèmes sous windows sont à gérer par le portage. Les problèmes sous linux son à gérer dans GTK.
Dans tous les cas tu ne peut pas assumer sous linux que ton utilisateur utilise un WM particulier. Si tu fais une appli spécifique Gnome ou KDE, pas de problèmes, mais quand tu fais une appli qui n'est pas liée à un bureau en particulier mais qui est utilisable par tout le monde utilisant X11 c'est pas possible.
Tout le monde gueule quand une applie proprio ne respecte pas les standards, et ici personne ne gueule ? Pourtant il suffirait de les respecter pour regler vos problèmes de boutons dans vos barres des tâches. Il suffit de s'assurer que GTK mes les bon hints dans ses fenêtres et que vos barres en tiennent compte.
Je n'affirmerais pas que GTK met les bons hints, il y a longtemps que je n'ai pas fais de progs d'interface. Mais quand j'utilisait les vieilles version je n'ai jamais eu de problèms à ce niveau la. Donc le plus simple à mon avis est de vérifier si ta barre des tache respecte bien les infos *standard* qu'on lui envoie et fais ce que tu veux avec.
En plus il y a de fortes chance pour que le patch fasse une ligne. Ta barre testant surrement déjà le hint _TRANSIENT_FOR des fenêtres modale donc il suffit de rajouter un test.
Le rapport c'est que une télé de 10 pouces c'est suffisant pour afficher n'importe quel film, au dessus c'est pas nécéssaire donc pour quoi avoir une télé de 56 pouces ?
C'est la même chose que pour 8bits c'est suffisant pourquoi en prendre 32 ?
Encore une fois, il ne s'agit pas de moi et ne mélange pas tout. J'ai posté plusieurs messages ici-même comme quoi il en va autrement du *traitement* par rapport à la *représentation*.
Il ne s'aggit pas de toi mais tu as quand même poster des messages auquels je répond...
C'est le premier message notament ou tu parle de la différentation entre les deux.
Mais en finalité, la *représentation* d'une image en couleurs comprenant 8 bits par canal est largement suffisante. Pour tout le monde. Et encore une fois, ce n'est pas moi qui l'ai inventé.
C'est pas toi qui l'a inventer mais tu n'est pas aller voir ce qui disait les gens qui l'on inventé...
Creuse un petit pour voir les conditions dans lesquelles 200 niveau de couleurs sont suffisante et tu verra que ce genre de tests sont fait sur des images à contraste naturel et avec des taux limites d'aplats.
Si tu prend une images très peu contrastée avec de grands aplats de couleurs unies, si en plus ces aplats sont aux imites de l'espace de couleur, et bien même avec 8bits de précision l'oeil humain fait la différence sans problème entre les différents niveaux.
Cette étude montre que sur des images moyennes, c'est-à-dire 95% des images 200 niveaux sont suffisants, mais ce n'est pas toujours le cas.
De plus pour des tirages haut de gammes en grand formats avec 8bits tes applats quelqu'ils soient auront une drole de gueule.
Donc non ! Même pour de la représentation 8bits n'est pas toujours suffisant. Tout dépend de ce que tu représente. Et c'est même un problème avec les écrans actuels, ils manquent de dynamique et ont souvent un espace de couleur étriqué.
La seule précision qui manquait était de distinguer *représentation* et *traitement*. Mais cela a été précisé et re-précisé plusieurs fois par la suite. Il suffit de lire *tous* les commentaires que j'ai postés ici-même.
C'est peut-être moi qui suis con mais je ne vois pas de commentaire ou tu ais préciser clairement que tu parlait uniquement de la représentation. On est dans un journal qui parle de Gimp, un outils d'édition d'image, si tu parle d'autre cose il faut être clair. De plus même dans le cas de la représentation il est faut de dire que 200 niveaux suffises. Comme dit au dessus, il ne sont suffisant que pour des images moyennes.
N'oublie pas non plus que la largeur du canal a une répercussion sur la taille des fichiers images. Autant conserver une taille modeste pour le stockage pour n'augmenter la largeur de chaque canal que pour le traitement de l'image, le résultat étant sauvegardé sur 8 bits par canal après conversion. Une largeur de 32 bits par canal, puisque c'est la question initiale portait là-dessus, ne ferait qu'alourdir considérablement et inutilement chaque fichier image.
Mais je ne l'oublie pas, c'est d'ailleur un sujet de préoccupation pour moi. Toutes les photos que je fais il faut bien que je les stock, et c'est sur qu'en raw ça prend plus de place qu'en jpeg.
Mais si tu converti en noir en blanc au format timbre poste c'est encore plus petit. Tu devrais stocker tes image en 100x100 sur 1 canal de 1bit et tu verra c'est encore plus petit.
Il y a beaucoup d'information dans les 12bits par canal de mes photos et je ne tiens pas à les predre en passant à 8bits. A chaque fois que je veux refaire un traitement différent d'une photo je suis bien content d'avoir garder le raw...
Maintenant si je sauvegarde tout en 8bits et que je n'utilise plus de bits que pour le traitement et bien quand j'ouvre mon image j'ai quand même perdu 4bits d'information par rapport à ce que mon appareil à produit. Si ma photo est surexposée à l'origine, avec une photo en 8bit je ne peut rien faire a part la suprimmer pour libérer un peu de place. Si elle est en 12 bits je refait ma balance des blancs, je bosse un peu sur l'histogramme et quelques autres trucs et voilà, une jolie photo parfaitement utilisable grace à la magit des 4bits supplémentaires. Pour un exemple en image, tu en trouve plein sur le web, notament : http://www.cmp-color.fr/rawvsjpeg.html
Une photo ne doit être convertie en 8bits que au dernier moment, une fois que l'on sait qu'elle est prète et qu'il n'y a plus d'autre traitement à éffectuer. A ce moment là on la convertit en 8bit on la sauve en png ou jpeg et on la met sur le net.
Là pas de problème, mais si tu convertit avant cela veut dire que tu va perdre de l'information pendant le traitement de manière irécupérable.
Bien entendu pour un jpeg super compresser de la taille d'un timbre poste sur le web ça ne sert à rien d'avoir plus, on êut même faire avec moins...
Par contre quand tu veut de belle photos et que tu travail desus il faut que à *toutes* les étape tu garde la précision maximale et le choix le plus intéligent dans ce cas en terme de performances et de qualité c'est actuellement le 32 bits. Et gimp est fait pour travailler sur des image et produire de la qualité donc un autre choix serait absurde.
d'autre modes sont possible, gegl et babl gérent aussi le 8/16/32bits entiers, mais ils n'on d'intéret que sur des architecture ou les flotants 32bits on des problèmes de perf.
Tu peut aussi choisir de toujours rester en 8bits si tu ne fait que des images pour le web, mais dans ce cas tu doi toujours faire attention à tes applats à chaque étape du traitement et tu te complique la vie pour rien.
Gimp ne force rien du tout, il se contente de créer des fenêtres. La seule chose qu'une application peut faire c'est de donner des conseils au WM sous la forme des hints définits dans EWMH.
L'application peut indiquer qu'une fenêtre particulière est une boite à outils et dans ce cas la barre des tâche peut choisir un comportement adapté.
Les fenêtres de Gimp sont gérés par GTK, donc il faut regarder si GTK spécifie ce hint ou pas.
Donc soit c'est Gimp qui n'utilise pas le bon type de fenêtre dans GTK, soit c'est GTK qui ne permet pas de spécifier le hint, soit c'est ton gestionnaire de barre de tâche qui n'en tiens pas compte.
Ce n'est pas surprennant que Gimp ait un comportement différent de beaucoup d'autres applications ; les standards desktop sont très mal géré par beaucoup de WM, docks et autres
Le plus souvent, seule les parties correspondant à une gestion classique des fenêtres est implémenté, avec par dessus plein de hacks degeux pour gérer les applis qui ne sont elles aussi pas standard.
Le problème est donc plus au niveau du respect général de ces standard. X11 à été prévu pour permettre une très grande souplesse dans la gestion des fenêtres mais ce mauvais respect fait que la pratique est loin de la réalité.
Dans le genre tu à le toolkit du JDK 1.5/1.6 qui assume que le gestionnaire de fenêtre va forcement changer le parent de la fenetre principale de l'application. En effet la majorité des WM le font, mais ce n'est pas le cas pour tous et aussi bien le standard ICCCM que EWMH spécifie bien qu'aucune application ne doit supposer que son parent sera changé par le WM.
Après avoir revu le standard EWMH qui spécifie les infos que peuvent échanger les applis et le gestionnaire de fenêtres, tout est déjà là.
Il suffit que Gimp spécifie soit _NET_WM_WINDOW_TYPE_TOOLBAR ou _NET_WM_WINDOW_TYPE_UTILITY comme atom pour les fenêtres de dialogue, et que ton logiciel de barre de tâche comprenne ces infos et tes problèmes seront réglés.
Du côté de Gimp je ne sais pas si le bon hint est spécifié, mais de toute façon ce n'est pas à Gimp directement de le faire mais au toolkit, donc c'est plus du côter de GTK qu'il faut aller voir et éventuellement corriger le problème.
Pour ton gestionnaire de barre de tâche, aucune idées si il supporte le standard, mais si ce n'est pas le cas, il faut qu'il s'y mette.
Donc dans ton cas, tout est disponible pour le gérer, et le standard spécifie bien que l'application ne fait que décrire sont comportement, c'est au gestionnaire de fenêtre de proposé la meilleure gestion en fonction des infos qui lui sont données et des préférenece de l'utilisateur.
C'est surtout que l'ergonomie est une notion floue et que les développeurs de logiciels libres ont tendance à faire des logiciels qui sont fonctionels pour eux.
Si on écoutait toujours les ergonomes je ne suis pas sur que des gestionnaire de fenêtre tels que dwm serait apparut, et si je comprend que son ergonomie ne convient pas a beaucoup de gens, moi il me fait gagner un temps monstre en s'occupant à ma place de gérer mes fenêtres.
Je suis d'accord que beaucoup d'application sont développées avec une ergonomie pas forcement adaptée au comun des mortels, mais elle est adaptée au développeur et en générls c'est ce qui l'intéresse.
Je le répète une dernière fois, ce n'est pas un problème de Gimp si le gestionnaire de fenêtres affiche plusieurs boutons dans la barre des tâches. Gimp ne sait même pas si tu as une barre des tâches ou pas. C'est à ta barre des tâches de n'afficher qu'un bouton par appli, même Windows en est capable. C'est quand même pas dur à coder.
Une application n'a pas à tenir compte du gestionnaire de fenêtre, c'est tou t simplement impossible étant donné la quantitée de gestionnaire différents qu'il existe.
Et quand c'est le cas on obtient des programme de merde. Par exemple, il est clairement stipulé dans la norme X11 qu'une application peut demander une taille spécifique pour sa fenêtre, mais que dans tous les cas elle doit accepter la taille que lui indique le gestionnaire de fenêtre. Pourquoi ? Car le gestionnaire de fenêtres transmet les désir de l'utilisateur et si l'utilisateur veut une taille particulière, l'appli doit s'adapter.
Le problème c'est que certaines applies ce croient plus intélligente que l'utilisateur et refuse toute taille autre que celle qu'elles ont choisit et deviennent inutilisable avec des gestionnaires tels que dwm ou autre.
Je comprend que certains aiment les wm classiques, mais comprenez aussi que d'autres aiment des gestionnaires différents. Et le seul moyen d'obtenir des application qui fonctionnent partout c'est de laisser tout ce qui touche la gestion des fenêtre au WM justement...
Pour permettre une bonne gestion des fenêtre une appli peut donner des infos sur ses fenêtres au WM, ces infos sont passées en respectant des standards freedesktops. Et je ne suis pas sur qu'il existe un moyen pour l'appli de dire si une fenetre doit êtere afficher dans un dock ou pas. Ton appli ne sait pas si tu a un dock, une barre des tache ou quoi que ce soit, elle peut donc juste donner les infos des standard et le WM et les applis satélites exploitent ces infos.
Si il n'y a rien a ce niveau dans les standards, Gimp ne peut rien y faire. Par contre ton dock, si les infos ne sont pas disponibles, il peut toujours regarder si deux fenêtre ont été créés par la même application et t'offrire une option pour les regrouper. C'est même pas compliquer à faire...
Gimp fonctionne très bien avec à peu près n'importe quel gestionnaire de fenêtres. Ce que tu lui reproche c'est qu'il n'est pas forcément simple d'utilisation avec une certaine catégorie de gestionnaire de fenêtre car ceux-ci ne sont pas capable de te présenter les informations sur les fenêtres de manière simple.
Tu peut le formuler comme tu veux, c'est toujours une histoire de gestion de fenêtres.
Pour ce qui est des *vrai* dock, je ne peut pas t'en citer je n'en utilise pas, mon gestionnaire de fenêtre n'en as pas besoin. Mais dans tous les cas, tu ne peut pas blâmer Gimp du fait que ton dock est mal foutu et qu'il ne sait pas regrouper les fenêtres par applications. Mon gestionnaire de fenêtre est capable de savoir qu'elle appli à ouvert qu'elle fenêtres et de les classer automatiquement.
C'est pas une manière tordue de voir le problème. Ça reste un problème de gestion des fenêtre et ce n'est pas à Gimp de le corriger. D'une part je ne suis pas sur qu'il existe un moyen, pour une applie, de signaler au gestionnaire de fenêtres qu'il ne doit pas afficher telle ou telle fenêtre dans sa barre des tâches. Et d'autre part si on le fais dans Gimp, il faudra le faire dans toutes les applications qui ouvrent plusieurs fenêtres.
Pourquoi faire des télé de 56pouce alors qu'une vieille 10 pouce est largement suffisante pour regarder la starac ?
Ce n'est parce que toi tu n'en as pas besoin qu'il faut limiter les aures et une précision superieur a 8bits est indispensable à beaucoup de personnes, pas que lesphotographe pros mais aussi les amateurs.
Donc peut-etre que ton commentaire était ironique, et en effet ton exemple était absurde. Mais une precision superrieur à 8bits n'est pas une idée absurde mais une idée qui répond à un besoin.
J'essaye juste de te faire comprendre que ce n'est pas absurde, qu'il y a un vrai besoin derriere. Après si tu veut rester sur ton avis que c'est absurde d'avoir plus, je m'en fous mais moi ce que je trouve absurde c'est dene pas comprendre que tout le monde n'a pas les même besoins.
Certes, mais macos a un gestionnaire de fenetre tres particulier, un dock a la place d'une barre de tache etc.
Chose que linux et windows n'ont pas.
correction : chose que ton linux n'a pas...
Donc le problème viens bien du windows manager et des programmes associés et pas de l'application elle même.
Après, si tu choisit d'utiliser une gestionnaire de fenêtre qui sait pas mieux faire que sous windows tu as trois solutions :
- Tu assumes et tu galère tout seul dans ton coin en silence ;
- Tu installe wine et la version windows de photoshop ;
- Tu prie pour qu'un dev rajoute une option dans gimp : "j'ai un gestionaire de fenêtre pas doué" qui améliore un peu les choses.
Tout simplement par ce que 32 bits c'est une taille qui plait beaucoup au processeurs actuellement...
32bits ça permet d'avoir une précision suffisante pour la majoritée des traitement actuels, seul des cas spécifiques tels que certaines imageries médicales ou autre truc très spécifiques demandent plus
32bits si tu utilise des float ça te permet d'avoir une dynamique quasiment illimitée dans ton images donc c'est cool...
32 bits en float ça te permet coder très éfficacement les opération sur les machine qui supporte des instruction vectorielles c'est-à-dire quasiment tous les ordis disponibles actuellement.
Bref c'est le meilleur compromis actuellement entre performance, occupation mémoire et qualité.
Lesmodifs ne détruisent pas l'image mais détruisent tes précédent reglages, donc au final ça reviens au même le plus souvent.
Sous gimp tu fais quelques modifs et ça ne te plait pas tu peut faire quelques undos, sous bible tu ne pas repartir que des dernier point de reprises. (les differentes sauvegardes de l'image et la dernière sauvegarde des reglages)
Et même si tu modifie que quelques reglages c'est très rapidement génant. C'est quand même une fonction de base de l'édition d'image, je suis sur que même paint dispose d'un undo...
D'un point de vue qualité Bibble est au dessus des autres et je l'ai beaucoup utilisé. J'ai fais comme toi, j'ai éssayé de m'en passer, mais au bout d'un moment j'ai finis par en avoir ras le bol de perdre du temps et j'ai abandonné.
Ta formulation est d'ailleur très explicite "on arrive à s'en passer". Ce n'est pas naturel mais on fais avec... Mais au bout d'un moement....
Pour la majoritée des traitement j'utilise maintenant rawtherapee. Il n'est pas libre non plus mais il est bien plus fonctionnel. Il permet de faire des dévellopement de très bonne qualité. Et au niveau du travail sur une photo il est beaucoup plus puissant ; il dispose d'un vrai historique d'édition et permet de naviguer dedans très naturellement.
Bibble ne me sert plus que pour les photos nécéssitant un traitement très poussées pour être exploitable du style une photo très bruitée faite à 1600iso dans un concert ou un spectacle. Mais en dehors de ces cas exceptionels, bibble 4 n'a pas assez d'avantages sur la concurence pour faire oublier ses défaults.
Bibble 5 devrais changer tout ça et avec un peu de bol je pourrais de nouveau utiliser un seul logiciel pour tout mes dévellopements, en attendant une solution libre.
Au niveau solution libre d'ailleur... On commence à avoir toutes les billes pour pouvoir faire un logiciel de qualité.
- DCraw permet le décodage des raw de virtuellement tous les appareil disponibles, et propose de algos de demosaicage tout à fais corrects, des codes pour d'autres algos sont disponibles en libre.
- littlecms permet une bonne gestion des espaces de couleurs
- babl et gegl offre tout le traitement graphique derriere
Il manque juste une jolie interface autour de tout ça...
Et personnellement je ne pense pas que Gimp soit l'idéal pour le dévellopement photo. Il faut bien voir que la retouche photo et le devellopement sont deux opérations différentes qui ne s'organisent pas de la même manière,
A mon avis il faudra une appli suppléméentaire ou un autre mode de fonctionement pour gimp.
Vivement la sortie de Bibble 5 pour mon coffort personnel, mais surtout vievement une solution libre et performante...
Très pratique le undo global... il annule toutes les modifs depuis l'ouverture du fichier ou la dernière sauvegarde. Pas moyen de retourner 3 ou 4 modifs en arrière si on as pas pensé au bon moment à sauvegarder ou à copier les paramètres, ou si entre temps on l'a refait.
Il y a deux ou trois mois je n'aurrais pas parié qu'elle sortirait avant la fin de l'année, mais après la démo à la photokina je pense qu'il devrait réussir... je commencait à avoir peur qu'il nous fassent le même coup que duke nukem forever...
C'est super cool toutes les nouvelles possibilités quelle va apporter, mais je dois avouer que ça m'a particulièrement lourdé qu'on nous annonce des trucs du style cataloguages et autre, et rien sur le undo ???
C'est quand même une fonction de base sur ce genre de logiciel, l'erreur est humaine, et je dois être très humain car quand je fais du dévellopement de photos j'en fais beaucoup. Et j'ai arrêter d'utiliser bibble à cause de ça car je perdais un max de temps.
Pour l'impression pro, on utilise quasiment toujours plus de 8bits par canal et dans des espace de couleurs plus grands que ceux utiliser sur le net par exemple.
Pour simplifier, un espace de couleur en RGB est définit par 3 couleurs ; rouge, vert et bleu et un point blanc. Une couleur dans cet espace est definit par la quantitée de chacune de ces couleurs. Tu ne pourra donc pas avoir un rouge plus rouge que celui de référence par exemple...
Un espace de couleur définit un volume qui contient des couleurs, chaqu'une des couleurs de référence définit un axe dans l'espace à trois dimension et une valeur maximale sur cette axe. On définit donc un cube dans cet espace qui contient les couleurs représentables. Celle qui sont en dehors de ce cube ne sont pas représentables.
Le standard sur les ordinateur est d'utiliser l'espace sRGB qui permet de représenté la majeure partie du spectre visible avec une bonne précision en 8bits, c'est à dire 256 niveaux pour chaque couleur de l'absence à la saturation.
Pour l'impression (*) en RGB on va plutôt utiliser le adobeRGB qui est un espace plus grand, c'est-à-dire qu'il contient plus de couleurs. Ca veut dire que sur chaque axe la plage de valeurs est plus importante, donc quand on la discretise il faut plus de bits pour la réprésenter avec la même précision.
Sur ton ordinateur l'espace couleur est plus réduit il te faut donc moins de précision pour que l'oeil humain ne puisse faire la différence entre deux niveaux. Pour l'impression par contre, il te faut une plus grande précision puisque l'espace est plus grand.
De plus en impression (mais aussi sur ton écran...) quand tu regarde en détail une zone à faible contraste (ou quand tu zoom dessus) ton oeil deviens plus sensible au nuance, il n'est pas perturbé. Donc tu as besoin localement d'une plus grande précision.
Quand tu imprimme une grande affiche pour un spectacle avec une chanteuse avec une grande robe rouge, tu peu être sur qu'il y aurra un pervers pour aller regarder les plis de la robe en détail... Et les ombres peuvent devenir très moches...
Il y a plein de hose qui rentre en compte et c'est loin d'être la plus importante, mais autant éviter les problèmes à chaque étapes. Il reste ensuite à trouver un bon imprimmeur...
(*) En fait il sera convertit en CMJN la pluspart du temps mais ça ne change rien ici...
> l'interface du Gimp est franchement un obstacle à son développement. Photoshop à quelques défaut mais AMHA son interface frise la perfection.
Sous MacOS photoshop à une interface très similaire à celle de Gimp avec des fenêtres séparées et ça n'a jamais freiner sont développement.
En tout cas les professionnels en sont très satisfaits. J'en connais deux qui ne passerais pour rien au monde à windows, non pas à cause des bugs, mais à cause de l'interface "pouries" de photoshop sous win...
Un exemple tout con qui montre la pertinence des 12 ou 14 bits par cannal des fichiers RAW :
Tu prend un protrait en contre jour. Avec un fichier 8bits, tu va avoir une grosse tache noire au millieu d'un désert blanc. J'éxagère un peu mais l'idée est la.
Sur la même photo en 14 bits tu va avoir dans des teintes tre foncée un portait au millieu et dans des tons très clairs autour des nuages. Tu va pouvoir corriger l'exposition de ta photo de manière à obtnir au final un très joli portait.
Il n'y a rien de magique... Si on raisonne en niveau gris, si tu réduit à 8 bits une photo en 14bits, toutes les niveaux 0 à 64 correspondrons à l'unique couleur 0.
Si ta photo est sous-exposé tu utilise très peu les grandes valeurs mais beaucoup les faibles, si tu as une image en 14 bits tu corrige l'exposition tu convertit en 8bits et tu obtient une photo avec réellement 8bits d'information.
Si tu travail avec une photo en 8bits et que tu n'utilise que la moitiée du spectre, quand tu fais la correction d'exposition tu n'a plus que 7 bits d'informations.
De plus les capteur sont en 14 bits car il capture la lumière de manière linéaire ce qui n'est pas le cas de notre oeil, il y a donc une conversion à éffectuer ; le gamma, et cette transformation fais perdre de l'information dans certaines parties du spectre, il y a donc forcément une perte et donc nécéssitée de plus de 8bits.
Rajoute à ça le nombre de traitement que l'on applique sur une image : demosaicage, convertion sRGB, balance des blancs, contraste....
Tu acumule les erreurs à chaque fois et même avec des algos bien foutus pour limiter au maximum ces problèmes, ça finis par être génant.
Dans Gegl et Babl les opération travail à la base sur des float pour maximiser la précision et ne pas perdre d'information par rapport au format d'origine de l'image. Mais il est possible de coder des version optimiser pour des entiers 8bits, tout est prévu et gegl utilisera automatiquement la bonne fonction.
La dernière fois que j'ai regarder la prioritée était à finir les implémentation en float, mais si il y en as besoin il y aura bientôt à mon avis des versions optimisées pour le 8bit.
Donc pour ceux qui on besoin de plus de 8bits on sera satisfait, et pour ceux qui se contentent de 8bit il n'y aura pas de problèmes...
Sans vouloir critiquer Bibble qui reste un très bon logiciel, il y a quand même une abération dans son design : "Il est *impossible* de faire un Undo !", oui, oui, vous avez bien lu, pas d'annulation des modifications...
Donc tu change quelques reglage et tu te dis que c'était mieux avant, et bien tu es obliger de retrouver tout seul les réglages d'avant...
La solution recomandée sur leur site : Utilisez le copier-coller des préférences ; Avant de faire une manip, avec une touche tu copie les reglage de la photo, tu fais ta modif et si tu veux annuler tu colle les anciens reglage.
Bref le truc super intuitif, très pratique et qui ne permet qu'un niveau d'annulation.
Le pire c'est que Bibble 5 est en dévellopement depuis plusieurs année, et il y a 3/4 mois environs quand je pose la question sur le forum pour savoir si la nouvelle version aura une fonction undo, la personne chargée de communication me répond qu'ils ne savent pas encore si cela sera implémenté...
Donc la ces clairement du foutage de gueule, ils sont à la fin du dévellopement, ils ont déjà des betas internes qui tournent et il ne savent pas si ils vont mettre un undo... Une fonctions qui est quand même un peu au coeur du logiciel et nécéssite pas mal de code un peu partout... Au dernière nouvelles la fonction sera présente dans la 5.0
Donc j'avais laissé tombé la version 4 car même si c'est un des meilleur d'un point de vue qualité pour le développement des RAW, c'est aussi un des moins ergonomique. La version 5 semble corriger tous ces défault, reste plus qu'à attendre qu'elle sorte...
[^] # Re: article inutile ?
Posté par beagf (site web personnel) . En réponse au journal Umberto Eco et Windows Vista. Évalué à 4.
1°/ le style nul
Je suis d'accord, mais au moins l'article à le mérite d'exister
2°/ le contenu inutile
Non il montre bien la vision de l'utilisateur de base d'un ordinateur. Il connait windows et c'est tout. Ok certains connaissent aussi Mac, mais ça va pas plus loin. Il y a encore une très grosse majoritée des utilisateur qui : soit ne savent pas qu'autre chose éxiste, soient pense que c'est réservé au monde professionel des grands chercheurs ou autre.
Vista est une régression ? bah si t'es pas content achète-le pas et voila.
Comme tous les gens qui ne savent pas qu'il y a autre chose, il ne peut pas ne pas l'acheter si il veut améliorer sont materiel.
Tu as vista et tu ne veux vraiment pas l'utiliser ? installe Ubuntu ou autre, c'est gratuit ça coûte pas cher.
Il ne connait pas, tout comme beaucoup de gens qui sont intéressés par les downgrading vers XP. Car XP ils conaissent et pour eux ça marchait très bien avant, ils ne savent pas qu'il y a autre chose qui marche "mieux" (enfin, question de point de vue)
Ce n'est pas vista ou microsoft qu'il faut critiquer, mais la vente liée. Vendre un système merdique c'est pas encore interdit.
Il critique pas directement windows ou microsoft, mais la regréssion et le fait qu'il faille payer pour revenir à quelque chose de plus vieux et théoriquement moins bon.
Parler de la vente liée sans prononcer une seule fois le terme « vente liée », sans parler de la possibilité d'un pc sans OS ou sans logiciel imposé par le constructeur, sans parler des alternatives à Windows… Comment dire… Il aurait peut – être dû se renseigner avant d'écrire son article ?
Et pour ce renseigner tu fais comment, une super recherche hyper approfondie ? Pour un billet d'humeur comme celui la ou le sujet c'est la régression téchnologique et le fait de payer pour changer du neuf comme du vieux ?
Pour un linuxiens les termes vente liées et système alternatifs semblent évident et pourtant demande au gens autour de toi, pas grand monde en dehors de nous ne va te dire "mais oui, bien sur".
Fais une recherche sur internet pour te documenter et tu vas voir que avec des recherches classique que fera quelqu'un qui ne connait que windows, c'est pas facile de tomber sur la vente liées, et quand tu tombe dessus c'est plutot anecdotique, rien qui te laisse penser que c'est vraiment le coeur du problème.
à aucun moment il n'évoque l'alternative à windows, cela reste très consensuel, voilà un bon article digne de libé qui enfonce les portes ouvertes... (ou les fenêtres ouvertes si vous préférez...)
C'est un billet d'humeur dans la rubrique culture, par un article technique dans la rubrique technologie. L'auteur soulève le problème de la régression technologique c'est d'ailleur surement pour ça (plus que la crainte de procès) qui fait qu'il ne dit pas que vista est une merde. Il laisse entendre que les gens préfère XP et veulent retourner à ce qu'ils avait avant, et il critique tout le bordel que c'est. D'un point de vue technique on s'en fout. Par contre d'un point de vue un peu plus philosophique c'est quand même marrant que tout le monde refuse ce "progrès" et ce casse le cul et paye encore plus cher pour du "moins bien"
Bref plein de commentaires sur : c'est nul il parle pas de nous (linux, vente lié...) Mais dans cet article on s'en fou, parler de ces trucs n'apporterais rien à l'article, et il y a une grosse majoritée de la population qui n'en as jamais entendue parlée et qui fuierait l'article alors que sont vrai thème les intéresse peut-être...
Donc plutôt que de critiquer, expliquer lui clairement que ce qu'il dit est fortement liés à d'autre thème, et donnez lui les bon pointeurs pour faire un article là-dessus, que ce soit constructif au moins.
[^] # Re: Alternative ?
Posté par beagf (site web personnel) . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 8.
Quelle quantité d'amélioration y a-t-il dans chaque version que tu cite ? Est-ce que l'équipe de Gcc fais une nouvelle version à chaque correction d'une faute d'orthographe ? Est-ce qu'il y a une nouvelle version à chaque fois que l'amélioration de perf atteint 10% de gain par rapport à la précédente ?
Bref, ce n'est pas parce qu'il y a eu de nombreuse version depuis la 3.3.5 que les perfs sont meilleur. Donc, on a des bench par rapport à la 3.3.5 et ces tout. Pour avoir des infos face au dernières version, il faut là aussi faire des benchs.
[^] # Re: Comment ça s'encode?
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de Theora 1.0. Évalué à 6.
- un encoder qui préconfigure tout pour obtenir une video correcte pour madame michu et autres, le tout très simple d'emploi sans prise de tête ;
- un encodeur avec toutes les options disponibles et une bonne doc sur comment obtenir la meilleure qualité possible afin que les geeks et les pros fassent de belles videos.
[^] # Re: I had a dream...
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de Theora 1.0. Évalué à 3.
Dans mes souvenirs, IE peu lire les vidéos si il y a les filtres, donc il suffit d'un liens vers les filtres avec un installeur et c'est bon, non ?
[^] # Re: Enfin des BR sous Nunux
Posté par beagf (site web personnel) . En réponse à la dépêche Le BD+, DRM du Blu-Ray, définitivement compromis. Évalué à 2.
Je dis peut-être une connerie mais les anciens lecteurs doivent pouvoir être mis-à-jours. Je pense quand même pas qu'ils sont stupide au point de ne pas l'avoir prévu.
Et rien n'empêche les nouveau lecteur d'embarquer aussi les anciennes clés pour lire les anciens blue-ray ?
Pour moi la révocation des clées c'est juste pour permettre des "générations" de disques et s'assurer que lorsque l'une d'elles est crackée on passe à la suivante. Donc pour lire un disque il faut avoir cracké la clef de sa génération.
Au final le principe reste stupide et fait bien plus chier l'utilisateur légitime que le pirate, mais ce n'est pas pour autant que tu dois jeter ton matos à chaque fois qu'une clef est cassée.
[^] # Re: Un jeu flash
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie d'OpenAlchemist 0.3. Évalué à 4.
Peut-être par ce que certains n'on pas flash car il n'utilisent pas une architecture supportée ou par ce qu'ils ne veulent pas de logiciels non libre sur leur ordinateur.
Même sans aller chercher ce genre de raisons, si je voulais écrire ce genre de petit jeu, pour moi ce serais en C+OpenGL.
Pourquoi ? Tout simplement car c'est une combinaison que je connais bien, et je sais que je n'aurrais pas à me prendre la tête. Je n'aurais aucune envie d'apprendre Flash, ActionScript ou autre...
Si tu préfère la version flash, utilise la, il n'y a pas de problème. Chacun peut choisir la version qu'il lui convient.
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 4.
Tout ce que tu dis est vrai pour du jpeg mais pas pour du raw.
L'objectif du fichier RAW est de contenir les données brutes issues du capteur. Le moins possible de traitement est fait dans l'appareil.
Pourquoi ? Car l'appareil dispose d'un temps, du puissance et d'une mémoire limité par rapport à un ordinateur moderne. Il est donc possible au dévellopement d'utiliser des algorithme beaucoup plus évolués et performants.
Donc un fichier raw reçoit les données brutes, c'est-à-dire une image en niveau de gris (chaque cellule ne capture qu'une des trois couleurs) linéaire (le capteur est linéaire, pas le choix...). Chaque pixel correspondant à une céllule du capteur. Les premières étapes sont généralement :
- le dématricage, pour passer de l'image en niveau de gris à une image couleur.
- Un convertion gamma pour quitter le mode linéaire
- La balance des blancs
Sur un fichier raw ces étapes sont éffectuées sur l'ordinateur pas sur l'appareil, donc dans ce cas, on s'en fout des algos utilisés par l'appareil.
J'ai parler de la sur-exposition car c'est une chose très utilisée par les photographes. Comme tu le dis la capture est linéaire mais pas la vision humaine, il y a donc une conversion à éffectuer.
Cette convertsion fait que la gamme sombre va être étirée et la gamme claire compressée. Il y a donc perte d'information dans les tons clairs car au final tu auras par exemple 200 valeur en linéaire converties en 100 valeurs dans l'image finale. Et un effet de peigne dans les valeurs sombres.
Ces pour cela que l'on conseil de surexposer un peu les photos lors de la prise de vue en raw. À la conversion on réexpose correctement l'image de manière à avoir une quantité d'information relativement homogène sur toute la gamme.
Et ça, ce n'est possible que parce que on travaille avec plus d'information que le résultat final. (voir par exemple [1])
Ensuite, pour ce qui est de l'exposition justement. L'appareil fait ce que tu lui demande et heureusement...
Tu peut lui demander d'exposer correctement tes photos et il fera de son mieux, mais il y a des situations ou c'est difficile, d'autre ou ces impossible. Donc c'est toujours valable d'avoir de la marge pour rattraper ce qui est possible.
Tu peut aussi régler toi même ton exposition et dans ce cas la, l'appareil te laissera faire, et si tu t'es planter, c'est cool aussi de pouvoir corriger...
Enfin, il y a des situations ou une sur/sous-exposition est voulue, ça permet d'obtenir des effets très chouette sur certaines photos. Par contre il est souvent agréable de pouvoir retrouver quelques détails dans ces zones pour leur donner un peu de volume.
La sur/sous-exposition est un des éléments qui, quand il est bien maîtriser, permet de faire des chose extrèmement intéressante, à condition d'avoir les outils pour.
Donc en gros, la conversion analogique numérique (dans le capteur) ne fais que capturer ce que tu lui demande (encore heureux ;-)) et donc il est nécéssaire d'augementer la résolution afin de pouvoir faire le meilleur traitement possible derrière et d'avoir la plus grande flexibilité.
Un exemple tout simple : Tu fais une photo pendant un concert. Le chanteur à un projecteur braqué sur lui et le batteur au fond est mal éclairé. En jpeg tu as de forte chance d'obtenir un chanteur cramer et un batteur boucher (san mauvais jeu de mots...)
Avec du raw, tu sur-expose d'1 ou 2 EL et à la convertion tu affine l'exposition des différentes zones de la photos pour obtenir une photo ou le chanteur et le batteur sont bien exposé.
Pour ce qui est de la comparaison RAW/JPEG, je suis daccord qu'il faudrais mieux comparer avec du png. Le problème c'est que tous les appareils produisent du jpeg, donc si tu veux comparer avec du png, et bien ton fichier png soit tu l'obtient a partir du jpeg (no comment) soit à partir du fichier raw (ce qui biase le test...)
Mais bon... je suis d'accord de me taire sinon je risque de me faire incendier pour hérésie compulsive...
Surtout pas, c'est bien qu'il y ait du débat. J'essaye de ne pas trop m'enflammer mais si je deviens méchant n'hésitez pas à me moinser....
[1] http://www.volkergilbertphoto.com/capture_lineaire.html et
http://www.volkergilbertphoto.com/exposer_raw-1.html
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 2.
Par contre je ne comprend pas ton premier commentaire dans ce cas. Pourquoi donner une définition du mot anglais et qui donc est fausse pour le mot français sans rien préciser de plus ?
Donc, au final un petit "s/assumer/supposer/g" avec un sed qui est capable de gérer les transformations gramaticales...
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 1.
Il est bien entendu que le gestionaire de fenêtre est fait pour X11 et les standards associés, par contre il peut organiser les fenêtres et interagir avec l'utilisateur comme il veut.
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 3.
Gimp à été dévelopé sous linux pour une interface graphique utilsant X11. C'est d'ailleur pour cela qu'ils ont dévelopé GTK, pour séparer la gestion des fenêtres et widget de la partie graphique.
Et donc les deux ont été dévelopé en respectant les standards X11, c'est à dire notement ne rien assumer du gestionnaire de fenêtre, mais lui donner des infos sur les fenêtres à gérés.
Ensuite il à été porter sous windows. Donc les problèmes sous windows sont à gérer par le portage. Les problèmes sous linux son à gérer dans GTK.
Dans tous les cas tu ne peut pas assumer sous linux que ton utilisateur utilise un WM particulier. Si tu fais une appli spécifique Gnome ou KDE, pas de problèmes, mais quand tu fais une appli qui n'est pas liée à un bureau en particulier mais qui est utilisable par tout le monde utilisant X11 c'est pas possible.
Tout le monde gueule quand une applie proprio ne respecte pas les standards, et ici personne ne gueule ? Pourtant il suffirait de les respecter pour regler vos problèmes de boutons dans vos barres des tâches. Il suffit de s'assurer que GTK mes les bon hints dans ses fenêtres et que vos barres en tiennent compte.
Je n'affirmerais pas que GTK met les bons hints, il y a longtemps que je n'ai pas fais de progs d'interface. Mais quand j'utilisait les vieilles version je n'ai jamais eu de problèms à ce niveau la. Donc le plus simple à mon avis est de vérifier si ta barre des tache respecte bien les infos *standard* qu'on lui envoie et fais ce que tu veux avec.
En plus il y a de fortes chance pour que le patch fasse une ligne. Ta barre testant surrement déjà le hint _TRANSIENT_FOR des fenêtres modale donc il suffit de rajouter un test.
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 6.
Le rapport c'est que une télé de 10 pouces c'est suffisant pour afficher n'importe quel film, au dessus c'est pas nécéssaire donc pour quoi avoir une télé de 56 pouces ?
C'est la même chose que pour 8bits c'est suffisant pourquoi en prendre 32 ?
Encore une fois, il ne s'agit pas de moi et ne mélange pas tout. J'ai posté plusieurs messages ici-même comme quoi il en va autrement du *traitement* par rapport à la *représentation*.
Il ne s'aggit pas de toi mais tu as quand même poster des messages auquels je répond...
C'est le premier message notament ou tu parle de la différentation entre les deux.
Mais en finalité, la *représentation* d'une image en couleurs comprenant 8 bits par canal est largement suffisante. Pour tout le monde. Et encore une fois, ce n'est pas moi qui l'ai inventé.
C'est pas toi qui l'a inventer mais tu n'est pas aller voir ce qui disait les gens qui l'on inventé...
Creuse un petit pour voir les conditions dans lesquelles 200 niveau de couleurs sont suffisante et tu verra que ce genre de tests sont fait sur des images à contraste naturel et avec des taux limites d'aplats.
Si tu prend une images très peu contrastée avec de grands aplats de couleurs unies, si en plus ces aplats sont aux imites de l'espace de couleur, et bien même avec 8bits de précision l'oeil humain fait la différence sans problème entre les différents niveaux.
Cette étude montre que sur des images moyennes, c'est-à-dire 95% des images 200 niveaux sont suffisants, mais ce n'est pas toujours le cas.
De plus pour des tirages haut de gammes en grand formats avec 8bits tes applats quelqu'ils soient auront une drole de gueule.
Donc non ! Même pour de la représentation 8bits n'est pas toujours suffisant. Tout dépend de ce que tu représente. Et c'est même un problème avec les écrans actuels, ils manquent de dynamique et ont souvent un espace de couleur étriqué.
La seule précision qui manquait était de distinguer *représentation* et *traitement*. Mais cela a été précisé et re-précisé plusieurs fois par la suite. Il suffit de lire *tous* les commentaires que j'ai postés ici-même.
C'est peut-être moi qui suis con mais je ne vois pas de commentaire ou tu ais préciser clairement que tu parlait uniquement de la représentation. On est dans un journal qui parle de Gimp, un outils d'édition d'image, si tu parle d'autre cose il faut être clair. De plus même dans le cas de la représentation il est faut de dire que 200 niveaux suffises. Comme dit au dessus, il ne sont suffisant que pour des images moyennes.
N'oublie pas non plus que la largeur du canal a une répercussion sur la taille des fichiers images. Autant conserver une taille modeste pour le stockage pour n'augmenter la largeur de chaque canal que pour le traitement de l'image, le résultat étant sauvegardé sur 8 bits par canal après conversion. Une largeur de 32 bits par canal, puisque c'est la question initiale portait là-dessus, ne ferait qu'alourdir considérablement et inutilement chaque fichier image.
Mais je ne l'oublie pas, c'est d'ailleur un sujet de préoccupation pour moi. Toutes les photos que je fais il faut bien que je les stock, et c'est sur qu'en raw ça prend plus de place qu'en jpeg.
Mais si tu converti en noir en blanc au format timbre poste c'est encore plus petit. Tu devrais stocker tes image en 100x100 sur 1 canal de 1bit et tu verra c'est encore plus petit.
Il y a beaucoup d'information dans les 12bits par canal de mes photos et je ne tiens pas à les predre en passant à 8bits. A chaque fois que je veux refaire un traitement différent d'une photo je suis bien content d'avoir garder le raw...
Maintenant si je sauvegarde tout en 8bits et que je n'utilise plus de bits que pour le traitement et bien quand j'ouvre mon image j'ai quand même perdu 4bits d'information par rapport à ce que mon appareil à produit. Si ma photo est surexposée à l'origine, avec une photo en 8bit je ne peut rien faire a part la suprimmer pour libérer un peu de place. Si elle est en 12 bits je refait ma balance des blancs, je bosse un peu sur l'histogramme et quelques autres trucs et voilà, une jolie photo parfaitement utilisable grace à la magit des 4bits supplémentaires. Pour un exemple en image, tu en trouve plein sur le web, notament :
http://www.cmp-color.fr/rawvsjpeg.html
Une photo ne doit être convertie en 8bits que au dernier moment, une fois que l'on sait qu'elle est prète et qu'il n'y a plus d'autre traitement à éffectuer. A ce moment là on la convertit en 8bit on la sauve en png ou jpeg et on la met sur le net.
Là pas de problème, mais si tu convertit avant cela veut dire que tu va perdre de l'information pendant le traitement de manière irécupérable.
Bien entendu pour un jpeg super compresser de la taille d'un timbre poste sur le web ça ne sert à rien d'avoir plus, on êut même faire avec moins...
Par contre quand tu veut de belle photos et que tu travail desus il faut que à *toutes* les étape tu garde la précision maximale et le choix le plus intéligent dans ce cas en terme de performances et de qualité c'est actuellement le 32 bits. Et gimp est fait pour travailler sur des image et produire de la qualité donc un autre choix serait absurde.
d'autre modes sont possible, gegl et babl gérent aussi le 8/16/32bits entiers, mais ils n'on d'intéret que sur des architecture ou les flotants 32bits on des problèmes de perf.
Tu peut aussi choisir de toujours rester en 8bits si tu ne fait que des images pour le web, mais dans ce cas tu doi toujours faire attention à tes applats à chaque étape du traitement et tu te complique la vie pour rien.
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 3.
L'application peut indiquer qu'une fenêtre particulière est une boite à outils et dans ce cas la barre des tâche peut choisir un comportement adapté.
Les fenêtres de Gimp sont gérés par GTK, donc il faut regarder si GTK spécifie ce hint ou pas.
Donc soit c'est Gimp qui n'utilise pas le bon type de fenêtre dans GTK, soit c'est GTK qui ne permet pas de spécifier le hint, soit c'est ton gestionnaire de barre de tâche qui n'en tiens pas compte.
Ce n'est pas surprennant que Gimp ait un comportement différent de beaucoup d'autres applications ; les standards desktop sont très mal géré par beaucoup de WM, docks et autres
Le plus souvent, seule les parties correspondant à une gestion classique des fenêtres est implémenté, avec par dessus plein de hacks degeux pour gérer les applis qui ne sont elles aussi pas standard.
Le problème est donc plus au niveau du respect général de ces standard. X11 à été prévu pour permettre une très grande souplesse dans la gestion des fenêtres mais ce mauvais respect fait que la pratique est loin de la réalité.
Dans le genre tu à le toolkit du JDK 1.5/1.6 qui assume que le gestionnaire de fenêtre va forcement changer le parent de la fenetre principale de l'application. En effet la majorité des WM le font, mais ce n'est pas le cas pour tous et aussi bien le standard ICCCM que EWMH spécifie bien qu'aucune application ne doit supposer que son parent sera changé par le WM.
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 2.
Il suffit que Gimp spécifie soit _NET_WM_WINDOW_TYPE_TOOLBAR ou _NET_WM_WINDOW_TYPE_UTILITY comme atom pour les fenêtres de dialogue, et que ton logiciel de barre de tâche comprenne ces infos et tes problèmes seront réglés.
Du côté de Gimp je ne sais pas si le bon hint est spécifié, mais de toute façon ce n'est pas à Gimp directement de le faire mais au toolkit, donc c'est plus du côter de GTK qu'il faut aller voir et éventuellement corriger le problème.
Pour ton gestionnaire de barre de tâche, aucune idées si il supporte le standard, mais si ce n'est pas le cas, il faut qu'il s'y mette.
Donc dans ton cas, tout est disponible pour le gérer, et le standard spécifie bien que l'application ne fait que décrire sont comportement, c'est au gestionnaire de fenêtre de proposé la meilleure gestion en fonction des infos qui lui sont données et des préférenece de l'utilisateur.
[^] # Re: Ergonomie ou habitude ?
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 3.
Si on écoutait toujours les ergonomes je ne suis pas sur que des gestionnaire de fenêtre tels que dwm serait apparut, et si je comprend que son ergonomie ne convient pas a beaucoup de gens, moi il me fait gagner un temps monstre en s'occupant à ma place de gérer mes fenêtres.
Je suis d'accord que beaucoup d'application sont développées avec une ergonomie pas forcement adaptée au comun des mortels, mais elle est adaptée au développeur et en générls c'est ce qui l'intéresse.
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 3.
Une application n'a pas à tenir compte du gestionnaire de fenêtre, c'est tou t simplement impossible étant donné la quantitée de gestionnaire différents qu'il existe.
Et quand c'est le cas on obtient des programme de merde. Par exemple, il est clairement stipulé dans la norme X11 qu'une application peut demander une taille spécifique pour sa fenêtre, mais que dans tous les cas elle doit accepter la taille que lui indique le gestionnaire de fenêtre. Pourquoi ? Car le gestionnaire de fenêtres transmet les désir de l'utilisateur et si l'utilisateur veut une taille particulière, l'appli doit s'adapter.
Le problème c'est que certaines applies ce croient plus intélligente que l'utilisateur et refuse toute taille autre que celle qu'elles ont choisit et deviennent inutilisable avec des gestionnaires tels que dwm ou autre.
Je comprend que certains aiment les wm classiques, mais comprenez aussi que d'autres aiment des gestionnaires différents. Et le seul moyen d'obtenir des application qui fonctionnent partout c'est de laisser tout ce qui touche la gestion des fenêtre au WM justement...
Pour permettre une bonne gestion des fenêtre une appli peut donner des infos sur ses fenêtres au WM, ces infos sont passées en respectant des standards freedesktops. Et je ne suis pas sur qu'il existe un moyen pour l'appli de dire si une fenetre doit êtere afficher dans un dock ou pas. Ton appli ne sait pas si tu a un dock, une barre des tache ou quoi que ce soit, elle peut donc juste donner les infos des standard et le WM et les applis satélites exploitent ces infos.
Si il n'y a rien a ce niveau dans les standards, Gimp ne peut rien y faire. Par contre ton dock, si les infos ne sont pas disponibles, il peut toujours regarder si deux fenêtre ont été créés par la même application et t'offrire une option pour les regrouper. C'est même pas compliquer à faire...
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 2.
Tu peut le formuler comme tu veux, c'est toujours une histoire de gestion de fenêtres.
Pour ce qui est des *vrai* dock, je ne peut pas t'en citer je n'en utilise pas, mon gestionnaire de fenêtre n'en as pas besoin. Mais dans tous les cas, tu ne peut pas blâmer Gimp du fait que ton dock est mal foutu et qu'il ne sait pas regrouper les fenêtres par applications. Mon gestionnaire de fenêtre est capable de savoir qu'elle appli à ouvert qu'elle fenêtres et de les classer automatiquement.
C'est pas une manière tordue de voir le problème. Ça reste un problème de gestion des fenêtre et ce n'est pas à Gimp de le corriger. D'une part je ne suis pas sur qu'il existe un moyen, pour une applie, de signaler au gestionnaire de fenêtres qu'il ne doit pas afficher telle ou telle fenêtre dans sa barre des tâches. Et d'autre part si on le fais dans Gimp, il faudra le faire dans toutes les applications qui ouvrent plusieurs fenêtres.
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 3.
Ce n'est parce que toi tu n'en as pas besoin qu'il faut limiter les aures et une précision superieur a 8bits est indispensable à beaucoup de personnes, pas que lesphotographe pros mais aussi les amateurs.
Donc peut-etre que ton commentaire était ironique, et en effet ton exemple était absurde. Mais une precision superrieur à 8bits n'est pas une idée absurde mais une idée qui répond à un besoin.
J'essaye juste de te faire comprendre que ce n'est pas absurde, qu'il y a un vrai besoin derriere. Après si tu veut rester sur ton avis que c'est absurde d'avoir plus, je m'en fous mais moi ce que je trouve absurde c'est dene pas comprendre que tout le monde n'a pas les même besoins.
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 2.
Chose que linux et windows n'ont pas.
correction : chose que ton linux n'a pas...
Donc le problème viens bien du windows manager et des programmes associés et pas de l'application elle même.
Après, si tu choisit d'utiliser une gestionnaire de fenêtre qui sait pas mieux faire que sous windows tu as trois solutions :
- Tu assumes et tu galère tout seul dans ton coin en silence ;
- Tu installe wine et la version windows de photoshop ;
- Tu prie pour qu'un dev rajoute une option dans gimp : "j'ai un gestionaire de fenêtre pas doué" qui améliore un peu les choses.
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 2.
32bits ça permet d'avoir une précision suffisante pour la majoritée des traitement actuels, seul des cas spécifiques tels que certaines imageries médicales ou autre truc très spécifiques demandent plus
32bits si tu utilise des float ça te permet d'avoir une dynamique quasiment illimitée dans ton images donc c'est cool...
32 bits en float ça te permet coder très éfficacement les opération sur les machine qui supporte des instruction vectorielles c'est-à-dire quasiment tous les ordis disponibles actuellement.
Bref c'est le meilleur compromis actuellement entre performance, occupation mémoire et qualité.
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 3.
Sous gimp tu fais quelques modifs et ça ne te plait pas tu peut faire quelques undos, sous bible tu ne pas repartir que des dernier point de reprises. (les differentes sauvegardes de l'image et la dernière sauvegarde des reglages)
Et même si tu modifie que quelques reglages c'est très rapidement génant. C'est quand même une fonction de base de l'édition d'image, je suis sur que même paint dispose d'un undo...
D'un point de vue qualité Bibble est au dessus des autres et je l'ai beaucoup utilisé. J'ai fais comme toi, j'ai éssayé de m'en passer, mais au bout d'un moment j'ai finis par en avoir ras le bol de perdre du temps et j'ai abandonné.
Ta formulation est d'ailleur très explicite "on arrive à s'en passer". Ce n'est pas naturel mais on fais avec... Mais au bout d'un moement....
Pour la majoritée des traitement j'utilise maintenant rawtherapee. Il n'est pas libre non plus mais il est bien plus fonctionnel. Il permet de faire des dévellopement de très bonne qualité. Et au niveau du travail sur une photo il est beaucoup plus puissant ; il dispose d'un vrai historique d'édition et permet de naviguer dedans très naturellement.
Bibble ne me sert plus que pour les photos nécéssitant un traitement très poussées pour être exploitable du style une photo très bruitée faite à 1600iso dans un concert ou un spectacle. Mais en dehors de ces cas exceptionels, bibble 4 n'a pas assez d'avantages sur la concurence pour faire oublier ses défaults.
Bibble 5 devrais changer tout ça et avec un peu de bol je pourrais de nouveau utiliser un seul logiciel pour tout mes dévellopements, en attendant une solution libre.
Au niveau solution libre d'ailleur... On commence à avoir toutes les billes pour pouvoir faire un logiciel de qualité.
- DCraw permet le décodage des raw de virtuellement tous les appareil disponibles, et propose de algos de demosaicage tout à fais corrects, des codes pour d'autres algos sont disponibles en libre.
- littlecms permet une bonne gestion des espaces de couleurs
- babl et gegl offre tout le traitement graphique derriere
Il manque juste une jolie interface autour de tout ça...
Et personnellement je ne pense pas que Gimp soit l'idéal pour le dévellopement photo. Il faut bien voir que la retouche photo et le devellopement sont deux opérations différentes qui ne s'organisent pas de la même manière,
A mon avis il faudra une appli suppléméentaire ou un autre mode de fonctionement pour gimp.
Vivement la sortie de Bibble 5 pour mon coffort personnel, mais surtout vievement une solution libre et performante...
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 3.
Il y a deux ou trois mois je n'aurrais pas parié qu'elle sortirait avant la fin de l'année, mais après la démo à la photokina je pense qu'il devrait réussir... je commencait à avoir peur qu'il nous fassent le même coup que duke nukem forever...
C'est super cool toutes les nouvelles possibilités quelle va apporter, mais je dois avouer que ça m'a particulièrement lourdé qu'on nous annonce des trucs du style cataloguages et autre, et rien sur le undo ???
C'est quand même une fonction de base sur ce genre de logiciel, l'erreur est humaine, et je dois être très humain car quand je fais du dévellopement de photos j'en fais beaucoup. Et j'ai arrêter d'utiliser bibble à cause de ça car je perdais un max de temps.
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 5.
Pour simplifier, un espace de couleur en RGB est définit par 3 couleurs ; rouge, vert et bleu et un point blanc. Une couleur dans cet espace est definit par la quantitée de chacune de ces couleurs. Tu ne pourra donc pas avoir un rouge plus rouge que celui de référence par exemple...
Un espace de couleur définit un volume qui contient des couleurs, chaqu'une des couleurs de référence définit un axe dans l'espace à trois dimension et une valeur maximale sur cette axe. On définit donc un cube dans cet espace qui contient les couleurs représentables. Celle qui sont en dehors de ce cube ne sont pas représentables.
Le standard sur les ordinateur est d'utiliser l'espace sRGB qui permet de représenté la majeure partie du spectre visible avec une bonne précision en 8bits, c'est à dire 256 niveaux pour chaque couleur de l'absence à la saturation.
Pour l'impression (*) en RGB on va plutôt utiliser le adobeRGB qui est un espace plus grand, c'est-à-dire qu'il contient plus de couleurs. Ca veut dire que sur chaque axe la plage de valeurs est plus importante, donc quand on la discretise il faut plus de bits pour la réprésenter avec la même précision.
Sur ton ordinateur l'espace couleur est plus réduit il te faut donc moins de précision pour que l'oeil humain ne puisse faire la différence entre deux niveaux. Pour l'impression par contre, il te faut une plus grande précision puisque l'espace est plus grand.
De plus en impression (mais aussi sur ton écran...) quand tu regarde en détail une zone à faible contraste (ou quand tu zoom dessus) ton oeil deviens plus sensible au nuance, il n'est pas perturbé. Donc tu as besoin localement d'une plus grande précision.
Quand tu imprimme une grande affiche pour un spectacle avec une chanteuse avec une grande robe rouge, tu peu être sur qu'il y aurra un pervers pour aller regarder les plis de la robe en détail... Et les ombres peuvent devenir très moches...
Il y a plein de hose qui rentre en compte et c'est loin d'être la plus importante, mais autant éviter les problèmes à chaque étapes. Il reste ensuite à trouver un bon imprimmeur...
(*) En fait il sera convertit en CMJN la pluspart du temps mais ça ne change rien ici...
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 7.
Sous MacOS photoshop à une interface très similaire à celle de Gimp avec des fenêtres séparées et ça n'a jamais freiner sont développement.
En tout cas les professionnels en sont très satisfaits. J'en connais deux qui ne passerais pour rien au monde à windows, non pas à cause des bugs, mais à cause de l'interface "pouries" de photoshop sous win...
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 7.
Tu prend un protrait en contre jour. Avec un fichier 8bits, tu va avoir une grosse tache noire au millieu d'un désert blanc. J'éxagère un peu mais l'idée est la.
Sur la même photo en 14 bits tu va avoir dans des teintes tre foncée un portait au millieu et dans des tons très clairs autour des nuages. Tu va pouvoir corriger l'exposition de ta photo de manière à obtnir au final un très joli portait.
Il n'y a rien de magique... Si on raisonne en niveau gris, si tu réduit à 8 bits une photo en 14bits, toutes les niveaux 0 à 64 correspondrons à l'unique couleur 0.
Si ta photo est sous-exposé tu utilise très peu les grandes valeurs mais beaucoup les faibles, si tu as une image en 14 bits tu corrige l'exposition tu convertit en 8bits et tu obtient une photo avec réellement 8bits d'information.
Si tu travail avec une photo en 8bits et que tu n'utilise que la moitiée du spectre, quand tu fais la correction d'exposition tu n'a plus que 7 bits d'informations.
De plus les capteur sont en 14 bits car il capture la lumière de manière linéaire ce qui n'est pas le cas de notre oeil, il y a donc une conversion à éffectuer ; le gamma, et cette transformation fais perdre de l'information dans certaines parties du spectre, il y a donc forcément une perte et donc nécéssitée de plus de 8bits.
Rajoute à ça le nombre de traitement que l'on applique sur une image : demosaicage, convertion sRGB, balance des blancs, contraste....
Tu acumule les erreurs à chaque fois et même avec des algos bien foutus pour limiter au maximum ces problèmes, ça finis par être génant.
Dans Gegl et Babl les opération travail à la base sur des float pour maximiser la précision et ne pas perdre d'information par rapport au format d'origine de l'image. Mais il est possible de coder des version optimiser pour des entiers 8bits, tout est prévu et gegl utilisera automatiquement la bonne fonction.
La dernière fois que j'ai regarder la prioritée était à finir les implémentation en float, mais si il y en as besoin il y aura bientôt à mon avis des versions optimisées pour le 8bit.
Donc pour ceux qui on besoin de plus de 8bits on sera satisfait, et pour ceux qui se contentent de 8bit il n'y aura pas de problèmes...
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . En réponse à la dépêche Sortie de GIMP 2.6. Évalué à 2.
Donc tu change quelques reglage et tu te dis que c'était mieux avant, et bien tu es obliger de retrouver tout seul les réglages d'avant...
La solution recomandée sur leur site : Utilisez le copier-coller des préférences ; Avant de faire une manip, avec une touche tu copie les reglage de la photo, tu fais ta modif et si tu veux annuler tu colle les anciens reglage.
Bref le truc super intuitif, très pratique et qui ne permet qu'un niveau d'annulation.
Le pire c'est que Bibble 5 est en dévellopement depuis plusieurs année, et il y a 3/4 mois environs quand je pose la question sur le forum pour savoir si la nouvelle version aura une fonction undo, la personne chargée de communication me répond qu'ils ne savent pas encore si cela sera implémenté...
Donc la ces clairement du foutage de gueule, ils sont à la fin du dévellopement, ils ont déjà des betas internes qui tournent et il ne savent pas si ils vont mettre un undo... Une fonctions qui est quand même un peu au coeur du logiciel et nécéssite pas mal de code un peu partout... Au dernière nouvelles la fonction sera présente dans la 5.0
Donc j'avais laissé tombé la version 4 car même si c'est un des meilleur d'un point de vue qualité pour le développement des RAW, c'est aussi un des moins ergonomique. La version 5 semble corriger tous ces défault, reste plus qu'à attendre qu'elle sorte...