Comme le confirme le cycle assez court, cette étape est principalement une transition vers GIMP 3.0 et le nouveau moteur GEGL censé combler les lacunes reprochées à un logiciel créé il y a maintenant treize ans. Après une longue attente de GIMP 2.4, les développeurs ont donc adopté le célèbre adage en cours dans le logiciel libre « publiez tôt, publiez souvent » (release early, release often). Les principales nouveautés de la version 2.6 :
L'interface
L'interface de GIMP a été revue et simplifiée, les entrées de menus ont été regroupées vers un ensemble plus cohérent. La différence à l'ouverture du programme est frappante avec une fenêtre d'image vide, concept absent dans les versions précédentes et qui pouvait perturber les novices (« mais où est la fenêtre principale ? »). Un simple glisser-déplacer dans cette zone ouvre l'image si le format est géré.
Les menus de la boîte à outils et de la fenêtre d'image étaient en grande partie redondant ; ils en forment maintenant un seul, disponible dans la fenêtre d'image.
Le comportement des boîtes à outils et de dialogue est désormais davantage lié à la fenêtre d'image.
Dans cette version 2.6 de nombreux composants de l'interface graphique utilisent la bibliothèque vectorielle de rendu à deux dimensions Cairo. Cela permet d'améliorer grandement le rendu de certains composants comme le démontre cette copie d'écran comparative.
Le moteur
La bibliothèque générique GEGL est en cours d'intégration, et certaines fonctions peuvent désormais y faire appel, pour les outils de couleur par exemple, passant d'une prise en charge sur 8 bits à 32 bits en virgule flottante. Certains effets, comme le flou gaussien par exemple, peuvent également bénéficier optionnellement du nouveau moteur expérimental.
Il faut cependant noter que le flux global de travail reste à 8 bits sur cette version, étant limité par le plus petit dénominateur commun (et ceci jusqu'à l'intégration complète de GEGL).
Les outils
Une sélection mixte polygonale / main levée fait son apparition.
Le cadre des textes devient redimensionnable
La vitesse du dessin a maintenant une influence sur la taille de la brosse. Cela permet, par exemple, de simuler à la souris le tracé obtenu par une tablette graphique puisqu'un mouvement rapide donnera un trait d'épaisseur et d'opacité moindres qu'un mouvement lent.
L'aide
C'est maintenant le moteur de rendu Webkit qui permet de visualiser les nombreuses pages d'aide au format HTML. Ce moteur offre la possibilité de visualiser soit les pages locales, soit les pages d'aide disponibles sur Internet (avec une priorité aux unes ou aux autres en fonction des préférences).
L'avenir
Les développeurs de GIMP ont une idée claire du chemin qui reste à parcourir pour faire de leur logiciel un incontournable du dessin matriciel, en gommant les défauts qui lui sont encore reprochés. La version 2.8 apportera par exemple une amélioration de l'outil texte par l'intégration du travail réalisé dans le cadre du Google Summer of Code 2008. L'intégration de GEGL sera améliorée et les possibilités de scriptage à partir du langage Python seront revues.
La version 3.0 est celle qui verra la bascule complète sur GEGL et l'abandon du moteur 8 bits. Cette version proposera également les groupes de calques, fonction attendue impatiemment par certains.
Pour aider au développement de GIMP et donc participer à l'avènement de la fameuse version 3.0 vous pouvez faire un don ou bien participer à la traque des bugs.
Aller plus loin
- GIMP (10 clics)
- Notes de publication de GIMP 2.6 (7 clics)
- Présentation en français sur GIMP-fr (50 clics)
- GIMP sur dmoz (4 clics)
- Journal d'un lecteur sur Gimp 2.6 (8 clics)
- PC Inpact : Traitement d'image : The GIMP 2.6 fait peau neuve (19 clics)
# gestion des images > 8 bits
Posté par gpe . Évalué à 4.
Perso (et je ne pense pas être le seul) c'est l'évolution majeure de Gimp que j'attends et qui fera que je l'utiliserai régulièrement.
D'ailleurs quand tu annonces la sortie de la 2.6 sur un forum photo la première question qui arrive c'est: "Est-ce qu'il gère enfin le 16 bits?" ...
Tu dis les développeurs ont donc adopté le célèbre adage en cours dans le logiciel libre « publiez tôt, publiez souvent »
Est-ce qu'un rythme fixe a été adopté (genre tous les 6 mois) ou est-ce au petit bonheur la change?
[^] # Re: gestion des images > 8 bits
Posté par Spacio . Évalué à 0.
A priori tout de suite si on en croit la description ici: http://gimp-fr.org/presentation_gimp26.php#couleurs
[^] # Re: gestion des images > 8 bits
Posté par gpe . Évalué à 4.
Il est important de noter que Gimp dans son ensemble reste 8-bits jusqu'à ce que GEGL couvre l'ensemble de l'application.
D'ailleurs si tu essaies d'ouvrir un tiff 16 bits Gimp 2.6 t'avertit qu'il ne le gère pas et qu'il va le convertir en 8 bits...
[^] # Re: gestion des images > 8 bits
Posté par canard_wc . Évalué à 6.
- 2.6 représente l'arrivée du moteur GEGL, mais restera un éditeur RVB 8bits. La vitesse de travail sur de grande image en est amélioré.
- 2.8 permettra d'utiliser des images de modes différents (CMJN, 16 bits ...)
[^] # Re: gestion des images > 8 bits
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 6.
Est-ce que quelqu'un pourrait me convaincre que 32 bits par canal puisse vraiment apporter quelque chose ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: gestion des images > 8 bits
Posté par jardiland . Évalué à 7.
[^] # Re: gestion des images > 8 bits
Posté par mister popo ポポ (site web personnel) . Évalué à 10.
Le cas classique est le scan de diapositives mal exposées. Tu scannes, et ensuite, ton logiciel et permet de piocher dans les 10 ou 12 bits d'informations pour arriver à construire une image correct sur 8 bits. Avec plein de bits, on peut sauver un contre jour, par exemple, qui est à la fois trop clair et trop sombre.
Pas besoin d'être pro pour ça.
[^] # Re: gestion des images > 8 bits
Posté par case42 (site web personnel) . Évalué à 10.
La modification principale que j'apporte sur mes photos, c'est de d'étendre le contraste avec l'outil "courbe" . Souvant il y a des zones "vide" aux extrèmes de l'histogramme (dans les fortes ou faibles lumières donc).
( ex flagrant ici : http://www.xwing.info/digikam/images/histogramme_correction.(...) )
En ajustant cela sur une image 8bits (genre jpeg) , tu te retrouve immencablement avec des
"franges", car forcement, tu as étendu sur 8bits une zone qui couvrait en fait 5 ou 6 bits.
Si tu parts d'une image "RAW", qui tu traite dans un outils qui sait gérer sa profondeur de 16 ou 24 bits, forcement ça change tout! avec le même exemple, tu étends sur 32 bits une zone qui en couvrait 24. Tous as toujours ces "trous" dans ton histogramme, mais ils disparaissent quand tu fais un export vers le format final (en 8bit).
Je pense que je vais prochainement craqué et investir dans un outil plus adapté au traitement photo que Gimp, mais payant: http://bibblelabs.com/fr/
[^] # çà sert à quoi l'histogramme
Posté par syj . Évalué à 8.
Car je vois bien que c'est un outil important mais je ne comprends pas son usage et son objectif.
[^] # Re: çà sert à quoi l'histogramme
Posté par Hardy Damien . Évalué à 9.
Tu peux voir rapidement les (sous|sur)expositions
plus d'info par exemple là http://luministes.com/pages/cb_histogramme.cfm
[^] # Re: çà sert à quoi l'histogramme
Posté par case42 (site web personnel) . Évalué à 10.
Dans mon exemple, l'histogramme me permet de voir comment je peux optimiser le contraste de ma photo.
Si tu prends toujours l'illustration suivante: http://www.xwing.info/digikam/images/histogramme_correction.(...)
typiquement, une photo avant retouche a un histogramme semblable à celui du bas: avec du vide à droite ou à gauche. Si elle à une bosse à gauche, c'est qu'elle est sous-exposée (tous les pixels ont des valeurs faibles), si elle a une bosse à droite, c'est qu'elle est sur-exposée (tous les pixels ont des valeurs fortes).
Grâce à l'outil "courbe", on peut corriger cela et s'approcher de l'histogramme présenté en haut sur l'image: une répartition optimal des pixels sur toute la plage de valeur.
[^] # Re: çà sert à quoi l'histogramme
Posté par kowalsky . Évalué à 4.
[^] # Re: gestion des images > 8 bits
Posté par abramov_MS . Évalué à 2.
[^] # Re: gestion des images > 8 bits
Posté par Frédéric COIFFIER . Évalué à 1.
De plus, la version 5 sort bientôt (http://bibble-photos.org/interface-bibble ) et l'achat de Bibble 4 donne droit au passage à Bibble 5 gratuitement.
[^] # Re: gestion des images > 8 bits
Posté par Cyprien Le Pannérer (site web personnel) . Évalué à 1.
C'est produit que je trouve particulièrement facile à utiliser pour le traitement des raw.
[^] # Re: gestion des images > 8 bits
Posté par imr . Évalué à 2.
[^] # Re: gestion des images > 8 bits
Posté par gpe . Évalué à 2.
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . É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...
[^] # Re: gestion des images > 8 bits
Posté par gpe . Évalué à 2.
La version 5 qui va sortir avant la fin de l'année offrira un vrai undo complet.
La version 5 n'est pas la prolongation de la 4 mais une réécriture complète du logiciel qui inclura des fonctions de cataloguages, selon plusieurs mode, de retouche avancée, etc, etc
Son concurrent direct est Lightroom.
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . É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 Frédéric COIFFIER . Évalué à 2.
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . É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 FantastIX . Évalué à -2.
Pour ajouter à ta question, l'oeil humain possède beaucoup moins (4x, si mes souvenirs sont exacts) de cellules rétiniennes sensibles à la couleur que celles sensibles à l'intensité lumineuse. En gros, pour des nuances de gris, 8 bits sont nécessaires pour que l'œil ne distingue plus les seuils entre deux teintes d'intensité de valeur différant d'une unité. Pour les couleurs, ça nous donne 6 bits par canal (R,G,B) soient 18 bits en tout par point lumineux. Finalement, 24 bits, c'est du luxe; 32 bits, ça frise l'indécence...
Donc: que la profondeur des couleurs sur un canal soit gérée sur 32 bits est pour moi une profonde hérésie ou un irrésistible argument marketing ;-) . Mais ce n'est que mon avis, bien entendu.
[^] # Re: gestion des images > 8 bits
Posté par Sarcastic . Évalué à 7.
Sauf si l'on considère que l'œil ne perçoit pas les 8 bits de façon linéaire, ou qu'on est amené à faire des modifications sur l'image qui vont modifier l'espace colorimétrique (courbe de gamma, histogrammes, tout ça).
[^] # Re: gestion des images > 8 bits
Posté par drakmaniso . Évalué à 10.
C'est exactement la même chose en musique (on travaille avec des dynamiques supérieures à la qualité CD).
Ensuite, la perception humaine est un sujet bien plus complexe qu'une simple histoire de récepteurs. Ce que l'on ne perçoit pas directement peut très bien nous toucher indirectement.
[^] # Re: gestion des images > 8 bits
Posté par Zenitram (site web personnel) . Évalué à 2.
Pfff...
32 bits, c'est 8 bits par canal (R,G,B,A, même si la A est rarement utilisé), c'est "juste" un exposant de 2 (contrairement à 24), est c'est surtout parce que c'est pratique.
Ensuite, tu parle de 6 bits "utile" par canal, on est assez d'accord sur ça. MAIS : as-tu appris à l'école ce que c'est que l'approximation? En pratique, sur tes 8 bits tu fais un transformation il te reste 7 bits "utile" (le dernier bit est du bruit venant du manque de précision), tu fais deux transformations 6 bits, 3 transformations hop 5 bits et tu as dénaturé l'image.
Bon, en pratique c'est moins violent car il y a de bons algos pour corriger, mais ça reste de la bidouille. Travailler sur 16 bits par couleur évite le bruit.
Après, pour la diffusion oui c'est inutile. Mais la on parle de travail sur une image, avec les problèmes d'approximation qui en découlent.
[^] # Re: gestion des images > 8 bits
Posté par FantastIX . Évalué à 1.
Si je parlais de la *représentation* d'une image, où 8 bits par canal est suffisant pour l'oeil humain, il en va autrement pour le traitement, bien sûr. Pour une opération sur un canal de 8 bits, le résultat sera sur 16 bits en raison de la multiplication. Mais ça reste malgré tout largement inférieur à 32 bits par canal, ce qui faisait l'objet de la question initiale de PMA.
Nous sommes donc bien d'accord que la diffusion d'une image à raison de 8 bits par canal, c'est suffisant. Le traitement, sur 16 bits par canal, d'une image, c'est suffisant. Le traitement sur 32 bits, par contre, comme le demandait PMA, j'en conclus que c'est inutile.
Sommes-nous toujours d'accord?
[^] # Re: gestion des images > 8 bits
Posté par Zenitram (site web personnel) . Évalué à 2.
Je partirai quand même du principe que qui peut le plus peut le moins, donc quitte à tout modifier dans le moteur, autant faire du 32 bits tout de suite, on sait jamais ça peut toujours servir plus tard (genre parce que la vidéo prévoit aussi des modes 10 ou 12 bits pour la diffusion finale, donc 16 bits seront un peu juste en traitement avant codage pour que les derniers bits soient conformes aux attentes), et vu la place qu'on a en RAM et disque dur maintenant ça ne changera pas grand chose.
[^] # Re: gestion des images > 8 bits
Posté par gpe . Évalué à 1.
[^] # Re: gestion des images > 8 bits
Posté par case42 (site web personnel) . Évalué à 3.
Exemple bête : pour l' [[Imagerie_à_grande_gamme_dynamique]] (c'est un nom qui fait très sérieux mais c'est à la porté de tout amateur de photo)
Si tu prends 2 photos raw en 14bits, t'est déjà à 28bits... Si t'en prends 3, t'es au delà des 32 bits... Donc 32 bits, c'est pas superflu, suivant l'usage...
[^] # Re: gestion des images > 8 bits
Posté par FantastIX . Évalué à 1.
Tant pis si je me fais moinsser mais dans ce cas pourquoi ne pas directement passer à 1024, 2048 voir 4096 bits par canal, tant qu'on y est? Ça donnerait un peu de marge au cas où il faudrait traiter pas loin de 300 images...
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . É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 FantastIX . É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é.
Ce n'était pas la peine de me donner un cours d'informatique. J'ai exagéré avec un exemple absurde sur une idée que, moi, je trouve absurde -- encore une fois ce n'est que mon avis et les avis... Ce n'était pas à prendre au premier degré. C'était juste de l'ironie.
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . É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: gestion des images > 8 bits
Posté par FantastIX . Évalué à 5.
Vois pas le rapport.
Ce n'est [pas] parce que toi tu n'en as pas besoin qu'il faut limiter les autres et une précision supérieure a 8bits est indispensable à beaucoup de personnes, pas que les photographe pros mais aussi les amateurs.
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*.
Récapitulons.
En ce qui concerne la *représentation* des images, les analyses et les études réalisées au début du siècle, ce n'est pas moi qui l'ai inventé, ont démontré que 200 nuances [par canal] étaient suffisantes.
En ce qui concerne le *traitement*, il est évident qu'il faut plus de 8 bits. Une image peut très bien subir un ensemble de traitements qui nécessitent plus de 8 bits par canal, 16 par exemple, afin d'améliorer la précision du traitement.
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é.
Et je rappelle que la question posée par PMA, à laquelle j'ai répondu, avant que ce troll ne dégénère était la suivante:
Est-ce que quelqu'un pourrait me convaincre que 32 bits par canal puisse vraiment apporter quelque chose ?
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.
Une précision de plus de 8 bits est absurde dans le cas de la *représentation d'une image. 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.
En d'autres termes, mon raisonnement ne portait que sur la *représentation* d'une image en couleurs sur 32 bits par canal. Rien d'autre. Et 32 bits c'est 16 millions de fois plus précis que ce que l'œil humain est et sera sans doute jamais capable de distinguer...
Toujours aussi catégorique?
[^] # Re: gestion des images > 8 bits
Posté par case42 (site web personnel) . Évalué à 5.
/me relis le sujet de la news...
Dans la mesure ou on parle de GIMP depuis le début, qui est tout de même, rappelons-le, un logiciel de TRAITEMENT d'image, ta distinction entre traitement et représentation, si elle a sans doute un peu de pertinence quelque part, tombe un peu hors sujet. On parle depuis le début de TRAITEMENT de l'image, et donc dire "ha mais moi je parlais juste de REPRÉSENTATION" à la fin du troll, ça fait vraiment rattrapage aux branches en catastrophe.
Mise à part ça, moi les discours du genre "X c'est largement suffisant" ( avec X comme "8 bits par canal", ou "640K de RAM" ) me laissent toujours sceptique... Je pense que ça dépend énormément de plein de choses, en particulier le périphérique final (déjà entre écran CRT ou TFT, y a un monde, dans l'impression, c'est encore une autre histoire, etc... ). Quand demain on aura jeté nos écrans à la poubelle et qu'on branchera directement nos cartes vidéo sur nos nerfs optiques, y à de fortes chances qu'on trouve ces affreuses images 8bits du début du siècles hideuses.
Sur le postula précis "l'œil ne peut pas distingué un dégradé sur plus de 7bits", moi ça me hérisse le poil de parler d'une valeur digitale avec un organe tout ce qu'il y a de plus analogique (et même pire que ça, biologique).
C'est un peu comme les 24 images par secondes du cinéma. Moi, je déteste aller au cinéma, parce que 24FPS, c'est définitivement insuffisant. Parfois, ça suffit, mais dès que ça bouge un peu, ça se voit, et c'est laid. En plus, immanquablement je ressorts avec mal à la tête ( ça fait cher le mal de tête ).
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . É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: gestion des images > 8 bits
Posté par FantastIX . Évalué à 3.
Ce n'est pas ça qui sauvera la photo de manière la plus efficace mais une conversion adaptative, non linéaire, comme pour le cas des CDROM. La résolution des signaux de faible valeur est plus fine et celle des signaux de plus forte amplitude plus faible, en raison de la répartition statistique des valeurs.
La sur- ou sous- exposition résulte d'une mauvaise exploitation de la gamme de valeurs. Exemple: une valeur maximale de 64 sur une échelle de huit bits représente une perte de 75% de la dynamique. Passer à 14 ou 16 bits ne fait que déplacer ou reporter le problème et n'éliminera pas le risque de perdre une photo sur- ou sous- exposée. Une conversion adaptative, oui. Mais ça, ce n'est pas à Gimp de le faire mais aux fabriquants de capteurs -- je ne sais pas si c'est le cas ou pas, remarque.
Si tu es obligé d'augmenter la résolution pour pallier au problème de la sur- ou sous- exposition, c'est que la conversion numérique n'exploite pas la gamme des valeurs numérique de manière efficace. Donc, ce qui compte, c'est avant tout d'avoir un algorithme de conversion efficace (e.g. adaptatif) avant de songer à augmenter la largeur des canaux de couleurs.
D'autre part, le site que tu références compare une image RAW (12/14 bits) avec une image JPEG (8bits). Une comparaison significative aurait été entre RAW et PNG en raison de la compression, non destructrice dans le cas de PNG.
Mais bon... je suis d'accord de me taire sinon je risque de me faire incendier pour hérésie compulsive...
[^] # Re: gestion des images > 8 bits
Posté par case42 (site web personnel) . Évalué à 3.
Bon plusieurs choses...
Sur le discours "mauvais algo, changer algo, pas changer matos", c'est pas faux mais c'est pas voir très loins non plus. Qu'il ne faille pas prendre les avancés du matos comme alibi pour ne pas travailler sur les algos, je suis tout a fait d'accord. Mais une chose est certaines: a qualité d'algo de traitement égal, avec 12bits on a un meilleur image qu'avec 8, c'est juste certain. Après, que l'oeil fasse pas la différence, c'est pas la question, parce qu'on a tout de même démontré que suite à manipulation, on pouvait rapidement manger la marge qu'on a avec les 12 ou 14 bits.
Bon algo ou pas bon algo, si le constructeur arrive a nous sortir des capteurs en 14, 16 ou soyons fou un jour 24 ou 32 bits, moi je prends, je crache pas dans la soupe.
C'est comme les "megapixels". On lit parfois que ça sert a rien d'en avoir moult, le fait est que plus j'en ais, plus je suis heureux, parce que ça veut dire qu'en moment du traitement, j'aurais beaucoup plus de latitude pour recarder mon image.
Enfin, il y a un détail qui n'a pas été souligné assez fortement depuis le début je trouve, c'est qu'en l'occurrence on compare du 12bits entier (RAW) avec du 32bits flottant (GEGL) (gegl sait faire autre choses, mais ça à l'air d'être le mode le plus convenu).
Or voila, on ne peut pas comparer de la sorte entier et flotant. Et donc, si tu pouvais avoir raison en parlant d'entier (32bits entier c'est trop pour traiter des RAW en 12 ou 14 bits entier), en flottant c'est plus vrai du tout! Un flottant sur moins de 32 bits est pratiquement inutilisable; et pour le coup, je cracherais pas sur du flottant en 64bits.
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . É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: gestion des images > 8 bits
Posté par gringonz . Évalué à -1.
si tu as 2 images sur 14 bits exposées avec 1IL d'ecart, soit un facteur 2 d'exposition, ca te fait pas 28 bits mais 15 ! puisque avec 15 bits tu codes deux fois plus de nombre qu'avec 14. Donc meme en extreme avec 5 photos separées d'un IL (1 diaph ou une vitesse d'ecart) ben tu monte à à peine plus de 20 bits.
donc avec les calculs intermédiaires c'est aussi simple d'utiliser 32 bits qui est la taille des mots sur les procs (pas de tous OK mais 64 bit ca ne sert vraiement à rien).
[^] # Re: gestion des images > 8 bits
Posté par gringonz . Évalué à -1.
si tu prends 2 photos separées de 1IL d'exposition, tu double la dynamique, il te faut donc 1 bit de plus soit 15 bits pour décrire l'ensemble. Al'extreme, ceux qui font de la photo HDR vont prendre au max 5 ou 6 photos separees d'1 IL, il de faudra 21 voire 22 bits. Si tes photos sont au depart en 16 bits il t'en faut 2 de plus ! moralité avec 32 bits c'est deja bien large disons pour les calculs intermédiaire... et puis c'est bien la taille de certains processeurs...
[^] # Re: gestion des images > 8 bits
Posté par FantastIX . Évalué à 2.
Ton raisonnement est correct mais c'est la pertinence d'une image, RAW ou pas, en plus de 8 bits par canal qui me titille...
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . É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 deelight . Évalué à 3.
Actuellement je dois utiliser dcraw pour sortir plusieurs JPEG correspondant aux expositions correctes des diverses zones de l'image, et ensuite les fusionner sous Gimp. Le jour ou je pourrais me contenter d'un seul export dcraw, je serai le plus heureux :)
[^] # Re: gestion des images > 8 bits
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Surtout que sur les bits des APN, il y a de tout et de n'importe quoi ;-)
[^] # Re: gestion des images > 8 bits
Posté par Gniarf . Évalué à 2.
[^] # Re: gestion des images > 8 bits
Posté par Amand Tihon (site web personnel) . Évalué à 3.
D'autres ont déjà répondu sur le sujet de la perte d'information quand on manipule des images sur 8 bits par canal, je n'en dirai pas plus.
Mais dire que 6 bits sont suffisants pour l'œil, je ne comprends pas du tout. As-tu déjà essayé un dégradé de vert sur 6 bits ? Les bandes sont très clairement visibles.
[^] # Re: gestion des images > 8 bits
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
colors = 64;
pixpercolor = 32;
npixx = colors * pixpercolor;
npixy = 50;
fp = fopen("vert6bit.ppm","w");
fprintf(fp,"P3\n# a 64 level green shade\n%d %d\n%d\n",npixx,npixy,colors);
for(i=0; i<npixy; i++) {
for(j=0; j<npixx; j++) {
fprintf(fp,"%d %d %d ",0,j/pixpercolors,0);
}
fprintf(fp,"\n");
}
fclose(fp);
Il faut bien se rendre à l'évidence et 7 bits sont bien nécessaires pour ne pas percevoir de discontinuités entre deux aplats de vert ! En revanche pour le rouge et le bleu il semble que six suffisent. Évidemment tout ceci sous réserves des distortions produites par les algorithmes de traitement appliqués par X, la puce graphique, l'écran ... Et sous réserves que mes yeux aient une capacité standard à distinguer les couleurs.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: gestion des images > 8 bits
Posté par Frédéric COIFFIER . Évalué à 6.
[^] # Re: gestion des images > 8 bits
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
[^] # Re: gestion des images > 8 bits
Posté par Thomas Douillard . Évalué à 2.
(fin d'élucubration hypotatoire)
[^] # Re: gestion des images > 8 bits
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
L'homme ne descend pas du singe, il fait partie de la famille des grands singes !
[^] # Re: gestion des images > 8 bits
Posté par Antoine . Évalué à 6.
Il me semble que notre président de la République est assez petit.
[^] # Re: gestion des images > 8 bits
Posté par Thomas Douillard . Évalué à 3.
En vrai bien sûr qu'on est cousins des grands singes.
[^] # Re: gestion des images > 8 bits
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Aujourd'hui, on sais que les autres grands singes sont loin d'être des idiots et que, si on se donnait la peine, il y en a pas mal qui pourraient atteindre le QI du pompiste moyen de l'amérique profonde (moi aussi, je sors ici une phrase toue faite). Bref, on se retrouve face a un dilemme que nous avons déjà eu il y a quelques sciècles avec les noirs ; il faut leur faire de la place et partager les richesses de la planête.
Nos gouvernements (et pas mal de citoyens) ne sont pas prêt à cela.
Pour finir, on n'est pas cousins des grands singes, on est des grands singes ! On est donc cousins des AUTRES grands singes.
[^] # Re: gestion des images > 8 bits
Posté par Thomas Douillard . Évalué à 2.
Plus sérieusement, ta limite est complètement arbitraire et très "affective" je trouve. Ta remarque sur le QI par exemple, c'est complètement toi qui le dit ... et c'est complètement mépriser le pompiste moyen aussi, d'ailleurs.
J'ai pas dit que les grands singes étaient bêtes, note bien, le fond de mon message c'est qu'effectivement l'homme ne doit pas détruire complètement son environnement ... c'est dans son propre intérêt d'ailleurs.
[^] # Re: gestion des images > 8 bits
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Parfois, pour faire avancer le débat, on est obliger de balancer des phrases un peu (trop) choc qui oblige à se rendre compte de l'absurdité de notre situation actuelle. Mais rassure toi, je n'en veux pas aux pompistes que je respecte beaucoup (quand j'en vois encore), c'est une image d'épinal comme la tienne que je te renvoyais.
L'Homme d'hier en Occident a eu beaucoup de mal a accueillir les noirs. L'Homme actuel a beaucoup de mal a accueillir ses cousins grands singes qui lui sont ses plus proches parents au sens génétique. L'Homme de demain aura certainement du mal a accueillir les autres espèces...
Un bouquin qui parle un peu de cela est : Les prairies bleus, d'Athur Clarke.
Pour ce qui est du QI, les expériences sur les autres grands singes sont assez étonnantes, mais elles manquent de continuité car justement les résultats pourraient trop déranger.
Pour conclure, je ne suis pas végétarien pour rien ;-)
[^] # Re: gestion des images > 8 bits
Posté par O'neam Anne . Évalué à 2.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: gestion des images > 8 bits
Posté par Gniarf . Évalué à 2.
[^] # Re: gestion des images > 8 bits
Posté par FantastIX . Évalué à 0.
C.Q.F.D., échec aux 32 bits par canal...
-->[ ]
[^] # Re: gestion des images > 8 bits
Posté par Sarcastic . Évalué à 6.
Le problème, c'est que la vision dépend d'un tas de trucs qui font que ce test sur écran est biaisé.
— L'écran a une dynamique de couleur faible (1000:1, généralement, bien qu'on monte plus haut avec certaines astuces qui détériorent les couleurs). C'est sûr qu'avec une dynamique pareille, pas évident de voir des différences entre les applats. Et encore, c'est en admettant que l'écran affiche des trucs différents entre 7 et 8 bits.
— L'œil s'adapte merveilleusement bien à un tas de trucs, ce qui fait que selon les conditions d'éclairage, tu seras pas amené à voir tout à fait les mêmes choses.
— On a pas tous les mêmes yeux. On a même 2 yeux différents qui ne voient pas tout à fait les mêmes choses (j'ai un œil plus sensible au rouge que l'autre, par exemple).
— Et encore une fois, l'œil s'adapte très bien à certains trucs, selon l'attention qu'on porte à un objet. Mettons une photo. Il y a un tas de contrastes dessus. L'œil va tout voir (Mettons sur 6,3 bits, puisque ça semble le standard décidé par FantastiX). Mais si on fixe une zone plus distincte, moins contrastée, on continuera à voir du contraste. S'il existe, ce qui ne sera pas forcément le cas si l'on se contente de 8 bits.
— Et enfin, cela va dépendre avec quelle partie de l'œil on regarde. Si l'on regarde avec la fovea, ou pas.
Bref, limiter les impressions à du 8 bits par canal, selon moi, c'est idiot, surtout :
— si l'on peut faire plus.
— si l'on fait du noir et blanc (Parce qu'on passe de 24 bits d'informations à 8, et que l'œil est très sensible à la luminance, surtout quand on quitte la fovea).
Évidemment toutes ces remarques sont d'autant plus valables pour les capteurs.
[^] # Re: gestion des images > 8 bits
Posté par FantastIX . Évalué à 4.
Je n'ai pas décidé de standard.
Il y a des gens bien plus intelligents que moi qui ont inventé des standards et inventé les règles de colorimétrie, que mon prof' de théorie du signal, lors de mes études supérieures, nous a rapportées (à ma classe et moi), et enseignées. C'étaient des matières sur lesquelles nous étions questionnés à l'examen.
Partant du principe qu'il n'a probablement pas pondu ça tout seul et qu'il avait très certainement des preuves pour étayer ses dires, j'ai tout simplement répété ses paroles. Dommage que je n'aie pas/plus ces cours sous la main.
Peut-être qu'il ne faut pas croire tout ce que les profs nous racontent, après tout...
[^] # Re: gestion des images > 8 bits
Posté par FantastIX . Évalué à 2.
http://www.arnaudfrichphoto.com/gestion-des-couleurs/couleur(...)
On dira ce qu'on voudra mais qu'on parle de 7 ou 8 bits par canal, le nombre de bits nécessaire et suffisant pour représenter une image reste bien en dessous du chiffre astronomique 32. Quand bien même le traitement des images le justifierait, il serait inutile de grimper au-delà de 16 bits.
[^] # Re: gestion des images > 8 bits
Posté par Sarcastic . Évalué à 3.
Cela dit, les critiques que j'ai fait sur la méthode du dégradé restent valable. Si on prend une vraie image, on va avoir des zones à forts contrastes, et d'autres avec beaucoup moins de contrastes. Et qu'on regarde en globalité ou localement, on verra tout de même du contraste, même si le ratio est important (et c'est impossible à évaluer avec un dégradé simple).
Après, je suis bien d'accord que monter au-delà de 16 bits, pour l'impression ou l'affichage, est une hérésie (même si 10 ou 12 bits ne me sembleraient pas de trop).
Toutefois, je pense que travailler en virgule flottante serait bien, parce que ça correspond plus à la façon dont notre œil fonctionne, via sa capacité d'adaptation. Mais l'intérêt, ce serait plutôt côté capteurs, alors, et avec une grande dynamique, ce qui permettrait d'éviter plusieurs prises de vues pour obtenir une image HDR. Et avant que les capteurs suivent…
[^] # Re: gestion des images > 8 bits
Posté par briaeros007 . Évalué à 2.
sur mon écran (non calibré) de même.
près, je suis bien d'accord que monter au-delà de 16 bits, pour l'impression ou l'affichage, est une hérésie
Dépend dans quel domaine amha.
Je me rapelle qu'un moment une news avait défrayé la chronique à propos d'un capteur style photo aérienne, et que la dynamique de cet appareil était suffisante pour prendre une photo entre 5 et 32 de diaph ... sans avoir à modifier l'exposition justement (qu'elle stockait suffisament de valeur par canal pour pouvoir "simuler" une exposition avec un diaph variant de 5 à 32 ;))
Mais je retrouve plus la news :(
[^] # Re: gestion des images > 8 bits
Posté par Sarcastic . Évalué à 2.
Oui, c'est pour ça que je précise bien pour l'impression ou l'affichage (même si c'est vrai que pour l'impression, c'est relativement peu applicable, vu que c'est une synthèse soustractive)
[^] # Re: gestion des images > 8 bits
Posté par Troy McClure (site web personnel) . Évalué à 4.
- c'est rapide pour faire les calculs (SSE)
- la dynamique est quasi "infinie" (virgule flottante), donc pas besoin de s'emmerder à savoir si telle ou telle opération est susceptible de saturer les 8/16 bits de ton image.
[^] # Re: gestion des images > 8 bits
Posté par beagf (site web personnel) . É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: gestion des images > 8 bits
Posté par Sarcastic . Évalué à 2.
Dommage, en effet.
Peut-être qu'il ne faut pas croire tout ce que les profs nous racontent, après tout...
Je connais un tas de profs qui racontent qu'il ne faut pas mettre d'accent sur les majuscules. (-:
En dehors de ça, c'est probablement vrai dans un tas de contextes, cette histoire de 6/7 bits. Après, le troll c'est de savoir si c'est une hérésie d'imprimer/afficher en plus de 8 bits par canal. Il me semble que dans certains contextes, ça se justifie (Donc, non, ce n'est pas une hérésie).
Après, si tu m'indiques une source qui montre le contraire, en justifiant chacun de mes points, ok.
[^] # Re: gestion des images > 8 bits
Posté par gpe . Évalué à 3.
Si au final tu veux avoir un 8 bits réel tu es obligé de traiter au moins en 16 bits sinon tu auras trop de pertes dans les traitements.
De plus tous les reflex actuels font du 12 bits pertinents au minimum. Les scanners également.
Quant au rendu sur écran même s'il est limité sur beaucoup d'écrans actuellement ça progresse et des écrans dépassant les 8 bits arrivent. De plus tout le monde ne se contente pas du rendu sur écran mais beaucoup de photographes font du tirage photo qui en fonction du papier permet d'exploiter pleinement une image avec plus de 8 bits.
[^] # Re: gestion des images > 8 bits
Posté par gpe . Évalué à 1.
[^] # Re: gestion des images > 8 bits
Posté par FantastIX . Évalué à -2.
C'est dû au traitement numérique: une multiplication de deux nombres de 8 bits donne un nombre de 16 bits. Mais c'est tout de même 65536 fois moins lourd qu'un nombre de 32 bits...
En tout cas, il existe une limite absolue qu'il est inutile de vouloir franchir: celle de la sensibilité de l'oeil humain. Cette limite donne la profondeur maximale absolue des canaux de couleurs.
[^] # Imagerie à grande gamme dynamique
Posté par TBTB . Évalué à 2.
http://fr.wikipedia.org/wiki/Imagerie_%C3%A0_grande_gamme_dy(...)
Et pour ceux qui ne peuvent pas attendre il y a CinePaint (un fork de The Gimp justement) :
http://en.wikipedia.org/wiki/CinePaint
[^] # Re: gestion des images > 8 bits
Posté par Michel Nicolas (site web personnel) . Évalué à 6.
-> pour les appareils compacts oui. Mais les réflex sont en mode RAW au minimum en 12 bits pour les plus anciens (comme le canon 350d), 48 bits pour les nouveaux et un peu plus haut de gamme (comme le 40D).
"j'ai la mauvaise habitude d'utiliser des images jpeg"
-> Le jpeg, c'est bien pour des photos de famille, de vacance, etc. C'est facilement partageable (sur cd, sur le net) car de faible poid. Mais ce n'est jamais ce qu'un photographe va utiliser, à fortiori si il compte retoucher son image ensuite.
"la différence ne peut qu'être nulle puisque ma dalle LCD même en mode photo se limite à 6-8 bits"
-> c'est tout à fait vrai pour les LCD grand public. Mais même dans ce cas, ce n'est que le rendu de l'image sur ton écran. Si tu l'imprimes ou le fait tirer dans un labo photo, tu peux profiter de la profondeur de couleur accrue.
De plus, et c'est le plus important, plus il y a de matière à ton image au départ, plus les possibilités de retouches sont grandes. Car dans les manipulation, même basiques, comme la modification du contraste, des courbes etc, on perd de l'information. Donc si tu pars avec une image 8bits et que tu la retravailles, tu risque de perde beaucoup d'informations de couleur et ton image te semblera un peu plate ou blafarde, même sur ton écran 8bits. Pauvre en couleurs en fait.
Est-ce que quelqu'un pourrait me convaincre que 32 bits par canal puisse vraiment apporter quelque chose ?
-> Avec un appareil photo compact en jpeg, il n'y a en fait aucun intérêt. Avec un réflex, même entrée de gamme, il y a un énorme intérêt.
[^] # Re: gestion des images > 8 bits
Posté par gpe . Évalué à 2.
[^] # Re: gestion des images > 8 bits
Posté par Michel Nicolas (site web personnel) . Évalué à -2.
-> pour les appareils compacts oui. Mais les réflex sont en mode RAW au minimum en 12 bits pour les plus anciens (comme le canon 350d), 48 bits pour les nouveaux et un peu plus haut de gamme (comme le 40D).
"j'ai la mauvaise habitude d'utiliser des images jpeg"
-> Le jpeg, c'est bien pour des photos de famille, de vacance, etc. C'est facilement partageable (sur cd, sur le net) car de faible poid. Mais ce n'est jamais ce qu'un photographe va utiliser, à fortiori si il compte retoucher son image ensuite.
"la différence ne peut qu'être nulle puisque ma dalle LCD même en mode photo se limite à 6-8 bits"
-> c'est tout à fait vrai pour les LCD grand public. Mais même dans ce cas, ce n'est que le rendu de l'image sur ton écran. Si tu l'imprimes ou le fait tirer dans un labo photo, tu peux profiter de la profondeur de couleur accrue.
De plus, et c'est le plus important, plus il y a de matière au départ, plus les possibilités de retouches sont grandes. Car dans les manipulation, même basiques, comme la modification du contraste, des courbes etc, on perd de l'information. Donc si tu pars avec une image 8bits et que tu la retravailles, tu risque de perde beaucoup d'informations de couleur et ton image te semblera un peu plate ou blafarde. Pauvre en couleurs en fait.
Est-ce que quelqu'un pourrait me convaincre que 32 bits par canal puisse vraiment apporter quelque chose ?
-> Avec un appareil photo compact en jpeg, il n'y a en fait aucun intérêt. Avec un réflex, même entrée de gamme, il y a un énorme intérêt.
# Merci à...
Posté par vladislav askiparek . Évalué à -1.
http://linuxfr.org/~cosmocat/27277.html
[^] # Re: Merci à...
Posté par patrick_g (site web personnel) . Évalué à 5.
# gimp et python : meme combat ;-)
Posté par manatlan (site web personnel) . Évalué à 2.
tous deux sont des transitions pour la version 3.0
interessant ... hasard ... ;-)
[^] # Re: gimp et python : meme combat ;-)
Posté par FantastIX . Évalué à 6.
[^] # Re: gimp et python : meme combat ;-)
Posté par Axel R. (site web personnel) . Évalué à 7.
[^] # Re: gimp et python : meme combat ;-)
Posté par FantastIX . Évalué à 2.
[^] # Re: gimp et python : meme combat ;-)
Posté par FantastIX . Évalué à 3.
-->[ ]
# fenêtre vide
Posté par grafit . Évalué à 2.
juste un petit point,
> l'ouverture du programme est frappante avec une fenêtre d'image vide, (...) Un simple glisser-déplacer dans cette zone ouvre l'image si le format est géré.
Je la trouve bien vide cette fenêtre, et potentiellement déroutante.
Je verrais bien dans cette fenêtre deux grosses boites :
une boite [ glisser-déplacer une image dans cette zone pour l'ouvrir ]
une boite [ créer une nouvelle image au format std1, std2, std3, autre...]
Je présume que l'état actuel est un premier pas. Il y a t'il un core gimpeur dans la salle ?
[^] # Re: fenêtre vide
Posté par Snarky . Évalué à 9.
Aïe, j'ai lu trop vite, j'ai sauté un O.... Il me semblait bien que ça n'avait pas de sens....
# Fonctionnalité manquante
Posté par Axel R. (site web personnel) . Évalué à 8.
Comment faire pour remonter ce souhait aux développeurs ?
J'ai pas vraiment trouvé de formulaire sur le bug repport de gimp (et d'ailleurs, ce n'est pas un bug, juste un souhait)
Merci,
Axel
[^] # Re: Fonctionnalité manquante
Posté par tiot (site web personnel) . Évalué à 5.
fichier > acquisition > Coller en tant que nouveau (ou ctrl + maj + V)
Cela me paraît beaucoup plus simple que de créer un nouveau document de la taille de ton image puis de la copier dedans.
[^] # Re: Fonctionnalité manquante
Posté par Zenitram (site web personnel) . Évalué à 2.
J'aurai appris comme ça comment faire un truc que je n'arrivais pas à faire avec GIMP et que je trouvais 100% naturel ailleurs (et je râlais contre GIMP pour ce problème), mais ça reste une ergonomie pourrie : il faut le savoir pour pouvoir le faire, je n'avais pas eu l'idée d'aller dans "acquisition" (qui pour moi est pour un scanner) pour faire un copier-coller de base.
[^] # Re: Fonctionnalité manquante
Posté par Fred BM . Évalué à 2.
Personnellement ça ne me dérange pas de passer par acquisition je l'ai trouvé naturellement tour seul, mais l'ergonomie est un domaine difficile et si cela peut aider certain.
Après je n'ai aucune idée du retour que l'on en a, après avoir posté une entrée.
[^] # Re: Fonctionnalité manquante
Posté par tiot (site web personnel) . Évalué à 9.
J'utilise Gimp très, très rarement (allez je dirai 1 h par an) et lorsque tu as posté un commentaire sur ce manque j'étais sûr que l'option était dans le même menu que pour faire les photos d'écrans.
J'ai mis 3 secondes à vérifier et à poster la réponse.
Je suis désolé mais lorsqu'un utilisateur très occasionnel sait où se trouve une option qu'il n'utilise jamais, on ne peut parler « d'ergonomie pourrie ».
[^] # Re: Fonctionnalité manquante
Posté par psychoslave__ (site web personnel) . Évalué à 5.
Ici dans GIMP, l'action nécessite certes de passer par un menu déroulant en plus, mais est classé de manière cohérente, ce n'est donc pas vraiment un problème d'ergonomie.
Dire qu'utiliser un logiciel de manipulation d'image pour quelque action que ce soit est 100% naturel, ça n'a pas de sens. Rien de ce que l'on fait avec un ordinateur ne nous est naturel. On peux saisir des concepts de manière instinctive quand les logiciels fonctionnent en utilisant des analogies avec le monde réel (par exemple le mode spatial sous gnome), mais ça n'a rien de naturel.
Ici c'est tes habitudes prises avec l'utilisation d'autres outils du même genre qui te font penser que c'est moins «naturel», alors qu'en fait c'est juste moins habituel du point de vu de ton expérience.
Après on peu discuter sur le fait que ce point soit plus ou moins instinctif comme classement, mais d'un point de vue ergonomie, à mon humble avis, il n'y a pas grand chose à redire.
[^] # Re: Fonctionnalité manquante
Posté par Zenitram (site web personnel) . Évalué à 4.
Donc proposer la taille du presse papier plutôt que des valeurs arbitraires me semblent bien plus ergonomique que de passer par un menu concernant des outils externes à l'ordinateur.
J'ai peut-être une vision étroite de l'ergonomie, mais je n'utilise pas souvent d'autres outils de retouche, donc je ne pense pas être trop "mappé" par les habitudes d'autres logiciels. Toi, tu as plus une vision "informaticienne", menu tout ça. Et c'est comme ça qu'on dégoute les gens "normaux" de l'utilisation d'un logiciel : en pensant en tant l'informaticien.
GIMP a une très sale réputation au niveau ergonomie, et ça change à force de le répéter (la façon de faire précédente était vraiment pas ergonomique, et après des années de critique, voila une bonne v2.6 qui corrige un peu le tir! C'était vraiment mieux avant? Je ne connais que des gens ici, passionné d'informatique, pour dire ça, une personne normale adore Firefox dont on a étudié l'ergonomie, mais rejette souvent GIMP car incompréhensible...)
[^] # Re: Fonctionnalité manquante
Posté par psychoslave__ (site web personnel) . Évalué à 1.
Pour ce qui est du presse papier dans gimp (2.4) : édition>coller comme>nouvelle image.
J'ai jamais dit que gimp c'était mieux avant, ni qu'il est maintenant parfait. Oui faire des critiques c'est bien, ça permet d'améliorer le logiciel. Je trouve juste que ce que tu disais n'était pas forcément un problème d'ergonomie, mais plus d'habitude (tu cites toi même le comportement d'autres applications comme référence).
[^] # Re: Fonctionnalité manquante
Posté par Éric (site web personnel) . Évalué à 3.
Parce que moi le "coller en tant que nouveau" il me manque sur Photoshop.
Penser qu'il faut faire une nouvelle image qui aura la taille du presse papier puis coller dedans au lieu d'agir directement à partir du presse papier ou de la sélection, ça ne me parait pas du tout intuitif moi.
Par contre de mémoire ce n'est pas dans acquisition sous Gimp, c'est au même endroit que les copier et coller, dans le menu édition. Bref, tu le vois quand tu fais "copier". C'est tout de même plus ergonomique que "créer une nouvelle image en pensant que la taille par défaut va être celle de mon presse papier" non ?
[^] # Re: Fonctionnalité manquante
Posté par Zenitram (site web personnel) . Évalué à 2.
C'était plus pratique que de fouiller dans les menus de GIMP surtout. C'était pas le top, mais c'était mieux.
La, je trouve que GIMP 2.6 est encore mieux maintenant : Ctrl-V dans la fenêtre vide, et hop une nouvelle image aux bonne dimensions, très intuitif. La méthode "Photoshop" manque toutefois, car quand on a déjà une image ça ne marche plus le Ctrl-V (il écrase l'image existante). Mais bon, la ça me convient pour moi car quand j'ai une image dans le presse papier, j'ouvre GIMP pour cette image le plus souvent, donc GIMP est vide.
[^] # Re: Fonctionnalité manquante
Posté par Okki (site web personnel, Mastodon) . Évalué à 1.
Comme dit précédemment, c'est vraiment l'endroit où l'on trouve cette option dans n'importe quel type d'application, que ça ai ou non rapport au graphisme, et pour moi on ne peut guère faire plus intuitif.
[^] # Re: Fonctionnalité manquante
Posté par Zenitram (site web personnel) . Évalué à 2.
Avec la 2.6, c'est beaucoup plus ergonomique : j'ai une image dans le presse-papier, je clique sur Gimp pour l'avoir en fenêtre principale, Ctrl-V et hop j'ai mon image.
C'est beaucoup mieux qu'avant. A croire que ce qui existait avant n'était pas terrible ;-)
Donc bon, l'ergonomie a été grandement améliorée avec cette 2.6, et c'est bien!
[^] # Re: Fonctionnalité manquante
Posté par Psychofox (Mastodon) . Évalué à 2.
Tu aurais regardé seulement une seule fois le raccourci associé à l'entrée du menu, tu le saurais.
L'ergonomie n'avait rien à voir avec ton problème. Le tien était le refus de la connaissance.
[^] # Re: Fonctionnalité manquante
Posté par Zenitram (site web personnel) . Évalué à -3.
Si pour toi seuls ceux qui fouillent dans les menus ont le droit de savoir le raccourci qui va bien, c'est pour moi de l'élitisme et un refus de "descendre vers le peuple".
Je refuse l'obligation de me taper tous les menus et apprendre par coeur les raccourcis pour un logiciel précis. Que ce logiciel aille à la poubelle si il n'a pas envie de descendre de son pied d'estale. Tu appelles peut-être ça un refus de la connaissance, moi je continuerai d'appeler ça une ergonomie pourrie.
Je vois heureusement que d'autres pensent comme moi, et maintenant le Ctrl-V fait quelque chose de plus "naturel" : ce à quoi on s'attend en tant que personne "normale". Merci à ceux qui ont réussi à faire changer ce logiciel contre les "informaticiens qui pensent que leur façon de voir l'ergonomie est la meilleure". Il aura fallu du temps, mais ils y sont arrivés!
[^] # Re: Fonctionnalité manquante
Posté par psychoslave__ (site web personnel) . Évalué à 7.
[^] # Re: Fonctionnalité manquante
Posté par NickNolte . Évalué à 2.
Faudrait arrêter de faire croire que tous les publics se destinent à l'usage de tels logiciels.
[^] # Re: Fonctionnalité manquante
Posté par psychoslave__ (site web personnel) . Évalué à 2.
Et sinon, que croient des utilisateurs professionnelles qui ne veulent même pas apprendre les raccourcis clavier d'une application qu'ils utilisent tout les jours en prétextant que c'est anti-ergonomique ?
[^] # Re: Fonctionnalité manquante
Posté par NickNolte . Évalué à 3.
J'en connais pleins des Mm Michu, des Tati Daniel qui ont 20000photos dans leur rép "Mes Documents" etc...
Et s'avez quoi? Elles ne retouchent jamais leurs photos.
[^] # Re: Fonctionnalité manquante
Posté par psychoslave__ (site web personnel) . Évalué à 1.
[^] # Re: Fonctionnalité manquante
Posté par NickNolte . Évalué à 2.
Peu importe le nom du logiciel 2D... elles n'en utilises aucuns.
Note, si je leur montre Gimp, je vais fatalement leur montrer comment corriger les yeux rouges ou redimensionner leurs images, elles vont donc baser leur apprentissage sur mon excellent processus de travail ( :) ), et vu que ce processus est optimisé, rodé avec les années, elles ne trouveront rien à redire. héhé
En même temps, pour appliquer un filre de correction yeux rouges, faut pas avoir faire Math sup ou payer un logiciel 1000€.
[^] # Re: Fonctionnalité manquante
Posté par dinomasque . Évalué à 2.
Non, c'est le petit Jean-Kevin du dessous qui le lui a installé ;)
Plus sérieusement, je connais plusieurs non geeks qui utilisent le logiciel fourni avec leur APN pour corriger les yeux rouges et faire de la retouche simple (cadrage, etc.).
BeOS le faisait il y a 20 ans !
[^] # Re: Fonctionnalité manquante
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Fonctionnalité manquante
Posté par Psychofox (Mastodon) . Évalué à 6.
Et tu l'as trouvé comment le CTRL+V la première fois ?
[^] # Re: Fonctionnalité manquante
Posté par plic . Évalué à 4.
http://www.cnrtl.fr/lexicographie/piedestal?
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Piedestal
Posté par Zenitram (site web personnel) . Évalué à 2.
Mais bon, d'autres font l'erruer et Google ne conseille pas une bonne orthographe, zut!
Bon, faut que j'apprenne par coeur!
[^] # Re: Fonctionnalité manquante
Posté par Gniarf . Évalué à 2.
http://linuxerie.midiblogs.com/archive/2008/10/06/grabouille(...)
de la part des gentils élitistes \o/
> Si pour toi seuls ceux qui fouillent dans les menus ont le droit de savoir le raccourci qui va bien, c'est pour moi de l'élitisme et un refus de "descendre vers le peuple".
> Je refuse l'obligation de me taper tous les menus et apprendre par coeur les raccourcis pour un logiciel précis.
c'est quoi l'étape suivante ? laisse-moi deviner... ah oui, tu refuseras de te servir de tes yeux pour utiliser ton logiciel parce que tu regarderas déjà la Star Ac. ergonomie de merde !
[^] # Re: Fonctionnalité manquante
Posté par briaeros007 . Évalué à 1.
Donc toi tu connais par coeur l'ENSEMBLE des raccourcis de TOUTES LES VERSIONS de vi et de emacs (et de tous les plugins), on sait jamais si tu tombe sur un vieux serveur, tu en aurais besoin...
[^] # Re: Fonctionnalité manquante
Posté par Gniarf . Évalué à 3.
il aurait fallu citer un bordel de merde métamorphe comme fail2ban qui change de tronche à chaque fois...
[^] # Re: Fonctionnalité manquante
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
[^] # Re: Fonctionnalité manquante
Posté par Axel R. (site web personnel) . Évalué à 1.
Control + C : copier
Control + N : nouveau
Control + V : Coller
Effectivement, la solution a mon problème se trouvait dans un menu.
C'est peut être ça la définition d'une ergonomie qui pue : celle qui impose l'utilisation de la souris quand on peut s'en passer :-)
Axel
[^] # Re: Fonctionnalité manquante
Posté par Psychofox (Mastodon) . Évalué à 6.
Control + C
Maj + Control + V
Il ne faut pas confondre ignorance et manque d'ergonomie.
[^] # Re: Fonctionnalité manquante
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Fonctionnalité manquante
Posté par Fred BM . Évalué à 2.
Il existe même un fichier avec tout les raccourcis habituel de photoshop à charger par Gimp pour ceux qui le désire.
http://epierce.freeshell.org/gimp/gimp_ps.php
[^] # Re: Fonctionnalité manquante
Posté par ragoutoutou . Évalué à 2.
Créer un nouveau document avec seulement la taille de ce qui est dans le presse papier mais avec les paramètres par défaut des standards de travail (réglages colorspace, ...) , c'est un gros gain de temps.
[^] # Re: Fonctionnalité manquante
Posté par Graveen . Évalué à 1.
[^] # Re: Fonctionnalité manquante
Posté par efyx (site web personnel) . Évalué à 0.
[^] # Re: Fonctionnalité manquante
Posté par NickNolte . Évalué à 2.
# mon coup de gueule à deux balles
Posté par kursus_hc . Évalué à 3.
J'utilise photoshop depuis foooort longtemps et gimp depuis ses première releases. Alors oui je sais je vais comparer deux trucs qui ne sont pas... gna gna gna je le fais quand même !!
disclaimer : Merci à toute l'équipe du gimp de faire un formidable travail, de créer une alternative correcte au ténor du genre et d'offrir leur code au monde entier.
Je n'ai jamais compris pourquoi il se sont entêtés dans cette interface ridiculement compliquée. Tu ouvres une image, PAF ! Quatre emplacements dans ta barre des tâches occupés !! Ca me rappelle le bon vieux temps ou je surfais sur le net avec douze fenêtres ouvertes.. Sérieusement, ce système va à l'encontre de tout ce qui se fait actuellement en termes d'ergonomie (onglets, dashboards..).
Donc bref, je sais que nombre de choses sont liées à l'habitude, mais l'interface du Gimp est franchement un obstacle à son développement. Photoshop à quelques défaut mais AMHA son interface frise la perfection.
Pourquoi vouloir réinventer la roue ?
[^] # Re: mon coup de gueule à deux balles
Posté par Swirly . Évalué à 10.
J'ai longtemps utilisé GIMP, retraitant peu des images en JPEG.
Maintenant que je suis contraint pour éviter les effets d'escalier ou les peignes dans l'histogramme final d'utiliser photoshop pour faire des opérations, je regrette amérement l'ergonomie que je trouvais intuitive et évidente de Gimp.
Mais cette ergonomie est très en lien avec l'ergonomie du window manager. Gimp sous windows, ce n'est pas la même chose qu'avec un gnome ou un KDE configuré...
Bref, de mon point de vue, l'interface de photoshop est absolument infame, et celle de GIMP est remarquable.
Comme quoi, les points de vue...
Vive la liberté et la diversité :)
[^] # Re: mon coup de gueule à deux balles
Posté par kowalsky . Évalué à 2.
'fin, question d'habitude quoi !
[^] # Re: mon coup de gueule à deux balles
Posté par kursus_hc . Évalué à 0.
Perso j'ai toujours quinze applis executées en même temps (je ne suis pas un adepte des bureaux virtuels), et j'apprécie le fait de mettre le focus sur UNE fenêtre pour exécuter UNE tâche : retoucher mes photos.
Au lieu de ça, je jongle en permanence avec les entrées de la barre des tâches, qui affichent juste une icone vu qu'elle est blindée, qui est la même pour chaque fenêtre, et je trouve ça pénible. Et si je décide de travailler sur 10 images en même temps, WOW ! ! On atteint des sommets d'ergonomie. Sérieusement : toutes les 10 secondes, je me retrouve à plonger dans le marasme de ma barre des tâches.
Oui je sais, c'est de ma faute gna gna, n'empêche que j'utilise Photoshop au boulot et que c'est un problème que je n'ai pas, même avec une barre des tâches surchargée.
Je ne comprend pas : le principe des tabs est révolutionnaire dans le monde des browser mais inutile dans la retouche d'images ?
[^] # Re: mon coup de gueule à deux balles
Posté par B16F4RV4RD1N . Évalué à 6.
Un raccourci pour accéder à la barre d'outil principal, un autre pour accéder aux calques etc.
(Et les bureaux virtuels sont pratiques pour ouvrir sa session gimp sans se mélanger avec le reste des autres applications, cela allègerait également ta barre de tâches)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: mon coup de gueule à deux balles
Posté par kursus_hc . Évalué à 2.
J'utilise photoshop dans un cadre professionnel, et le seul raccourci qui m'est utile est Tab : afficher/masquer les palettes. Pas de temps à perdre à appuyer sur 5 touches pour faire ce que je veux.
Quant aux bureaux virtuels, je ne les utilise pas pour d'autre raison, mais en voici une bonne : les drag and drop depuis FF ou le gestionnaire de fichier. Ha, il n'est pas sur le même bureau ? Peu importe, clic sur le bureau, clic droit sur l'appli, changer de bureau, drag and drop, clic droit sur l'appli, remettre sur le bureau initial... C'est top.
Je comprend que vous ne soyez pas d'accord, c'est la philosophie du libre. J'émettais juste mon avis, qui correspond à de vrais besoin (comme les votre hein, pas de jaloux).
[^] # Re: mon coup de gueule à deux balles
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: mon coup de gueule à deux balles
Posté par Yannick . Évalué à 4.
Ça fonctionne sous KDE4, très probablement sous KDE3, pour les autres gestionnaires de bureau je ne sais pas.
[^] # Re: mon coup de gueule à deux balles
Posté par NickNolte . Évalué à 0.
Tu ne comprends pas la philosophie du libre visiblement.
[^] # Re: mon coup de gueule à deux balles
Posté par kursus_hc . Évalué à 2.
" Je comprend que vous soyez habitué à un autre mode de fonctionnement, on à le choix, ce n'est pas la pensée unique, chacun est libre d'utiliser ce qui correspond le mieux à ses besoins."
Tu comprend mieux ?
[^] # Re: mon coup de gueule à deux balles
Posté par NickNolte . Évalué à 0.
Je n'ai pas à "mieux comprendre" comme tu dis, ici c'est une tout autre info que tu apportes.
[^] # Re: mon coup de gueule à deux balles
Posté par NickNolte . Évalué à 2.
Vu que tu peux personnaliser tes palettes, oui ça peut l'être :)
Si t'es un pro, qui utilise Photshop de manière Pro et qui donc, possède une licence, pourquoi te fais-tu "chier"(selon tes termes) avec Gimp?
En fait, tu n'utilises d'ailleurs aucunes particularités des environnement graphiques Unix et tu sembles ne pas vouloir t'y intéresser? donc quoi?
J'espère que ces quelques désagrements "ergnomiques"(toujours selon toi) ne sont pas ce qui justifie que tu mettes 1xxx euros dans une licence Photoshop, ça serait triste. :)
[^] # Re: mon coup de gueule à deux balles
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: mon coup de gueule à deux balles
Posté par B16F4RV4RD1N . Évalué à 2.
enfin, pour les drag n drop, comme il a été dit, tu peux faire du drag n drop vers la petite icone de l'espace de travail pour te retrouver directement à continuer ton drag n drop vers l'application que tu souhaites. Tu peux également (par exemple avec gnome et kde), déplacer directement l'application qui a le focus vers le bureau que tu veux avec des raccourcis clavier et des flèches de direction, c'est très rapide et ergonomique.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: mon coup de gueule à deux balles
Posté par dinomasque . Évalué à 6.
BeOS le faisait il y a 20 ans !
[^] # Re: mon coup de gueule à deux balles
Posté par kursus_hc . Évalué à 2.
Mauvais interface => changer d'interface !
[^] # Re: mon coup de gueule à deux balles
Posté par Psychofox (Mastodon) . Évalué à 5.
[^] # Re: mon coup de gueule à deux balles
Posté par kursus_hc . Évalué à -1.
[^] # Re: mon coup de gueule à deux balles
Posté par Yusei (Mastodon) . Évalué à 4.
Ceci dit, concernant la remarque sur les onglets: c'est très bien les onglets, d'ailleurs mon WM en utilise partout, alors en fait j'ai potentiellement des onglets pour toutes les applications. Le problème c'est lorsqu'une application a décidé que c'était à elle de gérer les onglets, et pas à mon WM. Je me retrouve donc avec des onglets dans des onglets, avec des raccourcis clavier différentes, et généralement une impossibilité de décrocher un onglet pour en faire une fenêtre (par exemple dans firefox).
Pourquoi ne pas militer pour l'intégration généralisée des onglets dans Metacity, Kwin, etc. plutôt que pour une intégration ad hoc d'onglets dans chaque application au monde ? Franchement, utiliser un soft qui fait plein de fenêtres (Nautilus ?) avec Metacity, c'est une galère pas possible. Avec un WM à onglets, pas de problèmes.
[^] # Re: mon coup de gueule à deux balles
Posté par Thomas Douillard . Évalué à 2.
Il te faudrait pour ça, en l'état actuel des choses, faire tout un environnement de bureau cohérent à la gnome ou kde et une charte à respecter pour les GUIs des applis amha, parce que les applis existantes ne cadrent pas vraiment avec ce paradigme.
Au passage, mon avis contredit un peu l'avis dominant qui veut que c'est au gestionnaire de gérer les fenêtre et de le faire bien, l'important c'est surtout une certaine cohérence.
Exemple bête, dans ff, le "bookmark this tab" qu'on a en cliquant droit sur un tab, il est possible avec xmonad ?
[^] # Re: mon coup de gueule à deux balles
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: mon coup de gueule à deux balles
Posté par Thomas Douillard . Évalué à 4.
Ce que je voulais faire remarquer, c'est que dans ce cas par exemple, le navigateur web peut proposer des trucs plus spécifiques pour son appli, genre bookmark d'un onglet en particulier, bookmark de tous les onglets, enfin bref dans le cas de FF tout ce qui sors quand tu cliques droit sur un onglet.
Ce qui serait pas forcément possible si tu laisse complètement les onglets gérés par le WM. Sauf API spécifique, mais on retombe vers un environnement ou tu fais communiquer le WM et l'appli à la manière d'un bureau intégré j'ai l'impression.
J'ai aussi l'impression, mais je peux me tromper, que c'est un peu une remarque générale: l'appli, ou le concepteur de l'UI, en sait sans doute plus sur l'utilisation qui va être faite de son appli que le WM, donc potentiellement il peut faire les bons choix sans que le WM ou l'utlisateur ait besoin de tripatouiller les fenêtre pour pour que ça convienne ... Bref, pour moi c'est pas forcément très malin de tout faire faire par l'utilisateur (tuning du WM) ou du gestionnaire de fenêtre, parce que l'utilisateur est pas forcément un gros geek, et parce que le WM a pas forcément toutes les cartes en mains ...
[^] # Re: mon coup de gueule à deux balles
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: mon coup de gueule à deux balles
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: mon coup de gueule à deux balles
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: mon coup de gueule à deux balles
Posté par Yusei (Mastodon) . Évalué à 2.
Pour prendre encore l'exemple de Firefox, les onglets sont clairement un moyen de regrouper un paquet de fenêtres afin de réduire l'encombrement de la zone visuelle et de la barre des tâches. Il n'y a aucun comportement spécial qu'on ne pourrait pas appliquer à une fenêtre seule.
Après, je suis d'accord avec ce que tu dis plus bas, l'utilisateur lambda ne saurait peut-être pas se servir des onglets de son WM. Mais ni ma mère ni ma grand-mère n'utilisent les onglets de FF non plus, pour la même raison.
[^] # Re: mon coup de gueule à deux balles
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: mon coup de gueule à deux balles
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
[^] # Re: mon coup de gueule à deux balles
Posté par Yusei (Mastodon) . Évalué à 4.
Ceci dit, je voulais surtout insister sur le fait que demander à chaque application de gérer ses onglets demandait plus de travail que de demander au WM de le faire. On va demander à Gimp de le faire, à Nautilus de le faire, à Evince de le faire, etc. alors qu'objectivement c'est un comportement qu'on voudrait dans chaque application qui peut ouvrir plusieurs fenêtres, autant le faire une bonne fois pour toutes.
[^] # Re: mon coup de gueule à deux balles
Posté par maderios . Évalué à 3.
Certains y verront du x° degré, d'autres de la provocation : Parce qu'elle existe
Sérieusement, au départ, p$hop a été créé pour des photographes professionnels avec l'aide de photographes professionnels, pour éditer des images numériques. Donc ils se sont basés sur les pratiques professionnelles et les besoins ergonomiques des professionnels. Gimp a été créé par des amateurs pour des amateurs, donc selon une logique différente et pas forcement adaptée au "rendement". Ce qui explique cet aspect éclaté de Gimp, encore présent dans la version 2.6, que je trouve personnellement pas ergonomique du tout, qui est une source de perte de temps et d'énervement. La meilleure des solutions consisterait à coller aux exigences professionnelles car, qui peut le plus peut le moins. Et dans ce cas pourquoi ne pas s'inspirer de p$hop ?
"L'art est fait pour troubler. La science rassure" (Braque)
[^] # De la roue et du patin..
Posté par Swirly . Évalué à 10.
Photoshop a été développé avec en tête un environnement windows (et un peu Mac OS <9 au départ)
Photoshop a été développé pour un environnement ou la notion de bureau virtuel est absente.
The GIMP a été conçu pour des environnements X11 (Xorg mainenant), et la notion de bureau virtuel y est à la base. Avec les raccourcis clavier et souris pour changer de bureau. Du coup, ces fenêtres éclatées ont BEAUCOUP de sens dans ce cas là, y compris avec la notion de fenêtre transversale à plusieurs bureaux.
Photoshop a été développé sous windows
The Gimp sous X.
ça change tout.
C'est dans ce contexte bien compris que the Gimp avec ses fenêtres multiples a des années d'avance en ergonomie sur Photoshop
Maintenant, il y en a qui sont assez fou pour utiliser The Gimp sous windows, sans l'ergonomie appropriée. C'est un peu comme photoshop dans wine... Faut quand même vouloir...
Mes deux centimes d'euro
[^] # Re: De la roue et du patin..
Posté par maderios . Évalué à 2.
Quant aux bureaux virtuels, je les utilise pour toutes autres activités (Net+son+.....), et ça, c'est un avantage immense
"L'art est fait pour troubler. La science rassure" (Braque)
[^] # Bureaux virtuels
Posté par Swirly . Évalué à 5.
Un pour les images
Un pour le net
Un pour le son
Du coup lorsque tu es sur celui ou tu fais le travail sur les images, tu as uniquement les fenêtres de GIMP qui sont en cycle avec alt+tab et maj+alt+tab
Voilà quelquechose d'impensable sous windows, de naturel sous linux, et qui a conduit à l'ergonomie de GIMP telle qu'elle est.
Par contre, un point ou je suis d'accord, c'est qu'il faudrait la possibilité (mais pas l'obligation) d'avoir plusieurs images dans une même fenêtre avec des onglets (photoshop ne le faisant pas non plus d'ailleurs)
Finalement on est d'accord :)
[^] # Re: Bureaux virtuels
Posté par maderios . Évalué à 1.
"L'art est fait pour troubler. La science rassure" (Braque)
[^] # Re: mon coup de gueule à deux balles
Posté par MsieurHappy . Évalué à 6.
[^] # Re: mon coup de gueule à deux balles
Posté par zebra3 . Évalué à 9.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: mon coup de gueule à deux balles
Posté par Yusei (Mastodon) . Évalué à 7.
Ce qui explique le fait que Gimp utilise une interface comportant plusieurs fenêtres, c'est surtout la philosophie unix: chaque outil fait son boulot et rien d'autre. Gérer les fenêtres, c'est le boulot du gestionnaire de fenêtres, pas des applications.
Alors, évidemment, à chaque fois qu'une nouvelle version de Gimp sort, des gens qui utilisent un mauvais gestionnaire de fenêtres viennent se plaindre que Gimp ne pallie pas aux défauts de leur logiciel. Certains même pensent que l'interface de Gimp résulte d'un manque de travail, alors que pour moi l'interface est un de ses avantages majeurs.
Évidemment, je n'imagine pas qu'on puisse demander à tout le monde de jeter Metacity (ou autre) à la poubelle, mais tout ce que j'espère, c'est que le jour où ces gens parviendront à obtenir une horrible interface MDI à la Windows, ils nous laisseront en option l'interface actuelle, qui est si pratique et si flexible quand on sait s'en servir... Malheureusement, comme il est difficile de maintenir plusieurs bonnes interfaces pour le même logiciel, je doute que ce soit possible.
[^] # Re: mon coup de gueule à deux balles
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
Là, déjà, une seule fenêtre dans la barre des tâches, ça voudra dire que les boîtes de dialogues seront filles de celles-ci, et que je ne pourrai plus les sélectionner avec les raccourcis de mon gestionnaire de fenêtre, ce qui va sans doute m'ennuyer passablement.
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . É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: mon coup de gueule à deux balles
Posté par VINDICATORs . Évalué à 1.
Sans compter que c'est une philosophie qui convient très bien aux modes multi-écrans cette histoire de fenêtre!
[^] # Re: mon coup de gueule à deux balles
Posté par thedude . Évalué à 5.
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.
Ca vous a jamais traverse l'esprit que si adobe, qui a l'air de connaitre son affaire en matiere de logiciel de retouche photo quand meme, s'est emboucanne a faire 2 interfaces tres differentes pour un meme produit sur 2 plateformes, c'etait qu'il yavait surement une bonne raison?
Genre, par exemple, que sous windows on a un bouton dans la barre des taches par fenetre alors que sous macos, on a un bouton dans le dock par appli?
[^] # Re: mon coup de gueule à deux balles
Posté par Mildred (site web personnel) . Évalué à 3.
Je trouve ça super pratique, ça permet d'éviter d'avoir un bureau surchargé de fenêtres inutiles, à quand la même chose sous X11?
Après, il faut aussi pouvoir gérer le cas où l'application n'a que des boîtes à outils lancées et aucune fenêtre principale (un peu comme GIMP jusqu'à présent) ... ce serait bête qu'on ne puisse plus sélectionner l'application du tout.
[^] # Re: mon coup de gueule à deux balles
Posté par NickNolte . Évalué à 1.
Sous Mac OS X, lorsque l'application n'est plus sélectionnée, les boîtes à outils sont cachées, et réapparaissent quand l'application est de nouveau au premier plan. J'ai remarqué quelque chose d'un peu similaire avec OpenOffice (et le styliste).
...
quand la même chose sous X11?
Krita procède déjà de cette façon.
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . É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: mon coup de gueule à deux balles
Posté par thedude . Évalué à 2.
On peut effectivement dire que c'est un probleme qui vient du window manager, mais c'est quand meme une facon particulierement tordue de voir le pb.
- Monsieur le vendeur, cette voiture est trop large pour rouler sur route.
- Non monsieur, ce n'est pas un probleme de la voiture, mais un probleme de route pas assez large.
C'est un peu ce que t'es en train de me dire la quand meme...
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . É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: mon coup de gueule à deux balles
Posté par thedude . Évalué à 4.
Le probleme, c'est que cette categorie de gestionnaire de fenetre, ca represente la majorite des utilisateurs de gimp, et la presque totalite des utilisateurs potentiels de gimp (ceux qui pourraient l'utiliser niveau feature mais ne le font pas parce que l'UI est a chier).
Ça reste un problème de gestion des fenêtre et ce n'est pas à Gimp de le corriger
Mais ya aucun probleme dans le gestionnaire de fenetre. Ce n'est pas une probleme, c'est un choix que de fonctionner de cette maniere, on ne peut pas dire que ca soit mieux ou moins bien.
Le WM fait des choix, les applis construisent leur UI en prenant ces choix en compte.
Le dock macos est tres bien dans le cas du gimp par exemple, mais ya d'autre cas ou il me parait moins pratique que la barre des taches qui me fait peter un plomb sous gimp.
Bref, the gimp se base sur des features de bureaux a diffusion confidentielle et cherche a se diffuser au plus grand nombre, ya pas comme un probleme la?
Adobe a au moins eu la decence de modifier l'interface de 'toshop sous windows, pour qu'elle puisse etre utilisable sous cet os.
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.
Ca existe, ce moyen. Ca s'appelle un dock. Et c'est ce qu'utilise macos (et window maker, honte a moi d'avoir oublie mon premier wm linux). Ca consiste a n'afficher qu'une icone pour toute l'application (ok, techniquement, on peut passer outre, virtual box le fait, mais ca casse toute la coherence du truc).
Gimp est une application designee pour etre utilisee sur un dock, mais diffusee a des gens qui n'ont pas de dock. Ce n'est donc pas un pb du wm, mais bien de l'application.
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . É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) . É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: mon coup de gueule à deux balles
Posté par O'neam Anne . Évalué à 2.
Cf mon commentaire «Gimp 2.6 et votre gestionnaire de fenêtre».
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: mon coup de gueule à deux balles
Posté par Zenitram (site web personnel) . Évalué à 2.
Ce qu'il fait sauf si tu le forces à afficher plusieurs boutons, ce que fait GIMP (du moins sous Windows)
Une application n'a pas à tenir compte du gestionnaire de fenêtre,
Donc il ne doit pas le forcer à afficher plusieurs boutons dans la barre de tâches, on est d'accord. Mais GIMP, lui, n'est pas d'accord, et force l'affichage de plusieurs boutons car il affiche plusieurs fenêtres indépendantes entre elles volontairement. Si GIMP respectait les usages, il créerait une fenêtre principale et plusieurs fenêtres rattachées à cette fenêtre principale...
C'est quand même surprenant que ce soit le seul logiciel à faire comme ça, non?
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Qui suppose que, qui fait l'hypothèse que. Et qui n'assume pas les conséquences. :-)
[^] # Re: mon coup de gueule à deux balles
Posté par thedude . Évalué à 3.
Mais ca la pas faute du gimp si ya 6 boutons dans la barre de taches, hein, c'est la faute du wm.
Et le truc marrant, c'est que c'est pareil sous gnome et je pourrais tres certainement dire que c'est pareil sous kde si mon virtual box acceptait de demarrer.
Comme tu dit, une application n'a pas a tenir compte du gestionnaire de fenetre, en attendant the gimp fait la supposition (tres forte s'il en est) que l'utilisateur a une WM capable de n'afficher qu'un seul bouton dans la barre des taches.
Marrant quand meme, faut surtout pas le faire, mais non quand on le fait, non seulement c'est pas un pb, mais c'est un bug chez les autres.
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . É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: mon coup de gueule à deux balles
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Ne rien supposer ou ne faire aucune hypothèse.
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 5.
[^] # Re: mon coup de gueule à deux balles
Posté par beagf (site web personnel) . É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 psychoslave__ (site web personnel) . Évalué à 1.
Le probleme, c'est que cette categorie de gestionnaire de fenetre, ca represente la majorite des utilisateurs de gimp, et la presque totalite des utilisateurs potentiels de gimp (ceux qui pourraient l'utiliser niveau feature mais ne le font pas parce que l'UI est a chier).
Bah si c'est vrai, ils devraient peut être sortir leur doigt du cul et faire une interface qui leur conviens sur leur système proprio, s'ils ont vraiment envie d'utiliser gimp.
Maintenant si dans les développeurs de gimp y a pas d'utilisateur d'OS X et qu'ils considèrent qu'ils ont d'autres priorité que travailler l'intégration de l'application sur le système d'une firme qui vends des machines où tu as même pas le droit d'installer les logiciels que tu veux, c'est pas moi qui leur jetterais la pierre.
[^] # Re: mon coup de gueule à deux balles
Posté par dinomasque . Évalué à 4.
BeOS le faisait il y a 20 ans !
[^] # Re: mon coup de gueule à deux balles
Posté par abramov_MS . Évalué à 3.
http://yro.slashdot.org/yro/08/10/08/1224224.shtml
[^] # Ergonomie ou habitude ?
Posté par franckd . Évalué à 1.
C'est peut-être la vraie raison des appli à "fenêtre unique" et l'hégémonie de certaines appli sur cet OS à fait le reste, la productivité a bon dos. Le cas des claviers est également un domaine où l'habitude a nettement pris le pas sur l'ergonomie...
[^] # Re: Ergonomie ou habitude ?
Posté par Zenitram (site web personnel) . Évalué à 2.
tu prend l'exemple de Dreamweaver, et c'est un bon exemple : des palettes flottantes, mais une seule entrée de programme dans la barre de tâches, quand tu cliques dessus toutes les palettes s'affichent.
[^] # Re: Ergonomie ou habitude ?
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: Ergonomie ou habitude ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Surtout que le libre a encore la "sale" habitude d'être fait par des passionnés d'informatique, sans l'aide d'ergonomes... Et ça se voit.
Donc pourquoi rejeter l'analyse (et les idées d'ergonomie) d'un soft proprio parce qu'il est proprio? Faut arrêter de se regarder le nombril, et voir ce qui ne va pas!
[^] # Re: Ergonomie ou habitude ?
Posté par beagf (site web personnel) . É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: Ergonomie ou habitude ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: mon coup de gueule à deux balles
Posté par Oddity . Évalué à 1.
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...
Et ben tes pros vont être déçus. Parce que chez Adobe, ils pensent bien que l'ergonomie du Photoshop windows est tellement meilleure que celle du Mac, qu'ils ont fait de Photoshop CS4 une app mono fenêtrée.
http://blogs.adobe.com/jnack/images/PS_app_frame.jpg
[^] # Re: mon coup de gueule à deux balles
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 4.
Pourquoi vouloir réinventer la roue ?
Je suis sûr que si tu leurs envoies des patchs propres pour permettre de personnaliser l'interface afin de se rapprocher de l'interface à la photoshop tout en pouvant rebasculer sur le "style" actuel de Gimp, ils les acceptent..
Comme pour tous les logiciels libres.. il y a toujours beaucoup de gens pour trouver des défauts (justifiés ou non, mais ce n'est pas la question), mais quasiment personne pour écrire du code.. et même que parfois il y a des gens pour écrire du code, mais relativement "sale" (hack et autres joyeuseries) et donc pas acceptable..
Je n'ai pas été voir mais il y a surement des discussions intéressantes sur le sujet dans la devel-list de gimp. Voir même des tentatives de patches...
# Gimp 2.6 et votre gestionnaire de fenêtre.
Posté par O'neam Anne . Évalué à 1.
Après avoir lancé Compiz, j'ai constaté que ça n'était plus du tout le cas.
J'ai donc lancé une petit enquête :
Avec Metacity :
http://gimp.org/screenshots/on-canvas-preview-of-gaussian-bl(...)
Notez que la barre de titre des fenêtres en question est plus petite, n'a pas de bords arrondis, et que la fenêtre que contient que le bouton fermer.
Avec XFWM :
http://ledek.ovh.org/images/pc/screens/gimp_26.png
Même aspect de la barre des titres que les autres fenêtres, comportement similaire à celui de Metacity.
Avec Compiz :
Traité exactement comme les autres fenêtres.
Et maintenant, qu'en est-il de votre gestionnaire de fenêtre ?
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Gimp 2.6 et votre gestionnaire de fenêtre.
Posté par gpe . Évalué à 1.
[^] # Re: Gimp 2.6 et votre gestionnaire de fenêtre.
Posté par O'neam Anne . Évalué à 1.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Gimp 2.6 et votre gestionnaire de fenêtre.
Posté par Victor STINNER (site web personnel) . Évalué à 4.
C'est pourri Metacity, l'image est tout floue ! Ou alors c'est peut-être ton écran qui est sale ?
[^] # Re: Gimp 2.6 et votre gestionnaire de fenêtre.
Posté par O'neam Anne . Évalué à 1.
C'est une capture d'écran du site officiel, regarde l'url :·D.
LinuxFr, parfois c'est bien de la MERDE : https://linuxfr.org/users/c2462250/journaux/ecriture-inclusive-feministes-et-wikipedia#comment-1793140
[^] # Re: Gimp 2.6 et votre gestionnaire de fenêtre.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Justement, à ce propos, est-ce que quelqu'un sait pourquoi il y a ce vide ? Ça me semble juste prendre de la place pour rien…
# Gimp 2.6 pour Ubuntu :)
Posté par Space_e_man (site web personnel) . Évalué à 2.
→ http://www.getdeb.net/search.php?keywords=gimp
Téléchargez les 6 paquetages (.deb : gimp, libgimp2.0, gimp-data, gimp-python, libbabl-0.0-0 et libgegl-0.0-0 ) dans un même dossier. En root, se placer dans ce dossier et exécuter dpkg - i *.deb
Lancer GIMP 2.6 à partir du menu Applications → Graphisme → ...
Mais où sont les boites de dialogues ? Je trouve plus la liste qui se trouvait jusqu'alors dans le menu Fichier → Boite de dialogue → ... de la fenêtre ... Ici, plus de menu donc... ça j'avais bien compris... mais plus de menu Boite de dialogue non plus dans le menu de la fenêtre :(
À moins que j'ai pas bien cherché :d..
[^] # Re: Gimp 2.6 pour Ubuntu :)
Posté par Space_e_man (site web personnel) . Évalué à 1.
C'est quand même vrai qu'on peut l'installer sous Ubuntu, je donne la march' à suivre, c'est plutôt sympa, non ?
Puis les fenêtre de dialogues, ben voila, j'ai trouvé :)
Elles sont d'abord disséminées dans les différents menus, puis surtout on les retrouvent toutes dans Fenêtres → Fenêtres ancrables → ... :)
Alors quoi ? C'était une question idiotes, c'est ça ? Bah...
[^] # Re: Gimp 2.6 pour Ubuntu :)
Posté par kowalsky . Évalué à 7.
Et surtout qu'a chaque fois, c'est toujours pour la même distrib qu'on y a le droit :)
[^] # Re: Gimp 2.6 pour Ubuntu :)
Posté par Space_e_man (site web personnel) . Évalué à -1.
Vraiment ?
Est-ce que ça c'est déjà vu ?! :)
Moi je dis pourquoi pas !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.