Alors que l’annonce précédente pour GIMP 2.10.18 a été publiée il y a peine plus d’un mois sur LinuxFr.org, voilà que GIMP 2.10.20 est déjà sorti !
Comme à notre habitude maintenant, non seulement cette version contient son lot de corrections (plus de trente bogues corrigés), mais aussi plusieurs nouvelles fonctionnalités, dont certaines des plus excitantes ! En résumé : le recadrage non destructif (en recadrant le canevas sans supprimer les pixels hors cadre), une meilleure prise en charge du format PSD, des contrôles sur le canevas pour le filtre Médaillon, de nouveaux filtres (Bloom, Flou de focus, Flou de l’objectif (Lens Blur), Flou variable), etc.
Cette dépêche est une traduction libre de l’article en anglais publié le 11 juin dernier sur le site gimp.org.
Sommaire
Bonne santé à tous ! par Aryeom, Creative Commons By‑SA 4.0
Nouvelles fonctionnalités
Améliorations de la boîte à outils
Nous avons pris en compte les retours d’utilisateurs sur les outils groupés apparus dans la version précédente. Beaucoup ont apprécié globalement ce changement, mais détestaient le clic pour ouvrir la liste des outils regroupés. Dans cette nouvelle version, une option permet de montrer le contenu des groupes d’outils au survol de la souris. Cette option est activée automatiquement quand la boîte à outils est disposée sur une seule colonne, mais peut également être activée pour toutes les dispositions, ou complètement désactivée, en allant sur la page Boîte à outils de la fenêtre des préférences.
Lorsque cette option n’est pas utilisée, les bulles d’aide listent maintenant tous les outils d’un groupe, pour les rendre plus visibles.
Liste des outils dans un groupe d’outils
Découpage non destructif
Par défaut, GIMP fait maintenant un découpage non destructif : au lieu de supprimer les pixels hors de la découpe, ce qui modifie les calques et le canevas, on redimensionne tout simplement le canevas. Si vous exportez l’image, elle contiendra seulement ce qui est inclus dans le canevas.
L’avantage est (au moins) triple :
- on peut retrouver l’image non découpée par le menu Image > Ajuster le canevas aux calques, aucun de vos changements entre la découpe et le retour à l’image non découpée ne disparaîtra ;
- si vous enregistrez votre projet au format XCF, vous pouvez quitter GIMP, rouvrir plus tard et annuler le découpage — ou découper différemment ;
- lorsque vous doutez de votre découpage, vous pouvez toujours voir les pixels découpés en allant dans le menu Affichage > Tout afficher.
Pour retrouver l’ancien fonctionnement « destructif », cochez la case « Supprimer les pixels découpés » dans les options de l’outil de découpage.
Découpage non destructif
Améliorations et ajout de filtres
Le filtre « Médaillon » se dote d’une interface visuelle
Le filtre Médaillon (Vignette en anglais) a maintenant des contrôles sur le canevas permettant de manipuler visuellement sa géométrie plutôt que d’entrer des valeurs numériques dans une fenêtre de dialogue. Quelle que soit la « forme de vignette » que vous choisissez, il est toujours possible de manipuler l’intérieur — qui reste inchangé, la limite du filtre où les pixels n’évoluent plus, ainsi que le point médian entre les deux. Faire glisser la souris au‑delà des contrôles extérieurs permet de tourner la forme de la vignette.
Deux nouvelles formes de vignette ont été ajoutées : « Horizontal » et « Vertical » (pouvant également être tournées).
Le filtre Médaillon
Trois nouveaux filtres de flou
Trois nouveaux filtres se destinent à l’imitation des flous de mise au point.
Flou variable prend pour base un calque ou un canal pour décider des pixels à flouter (en proportion d’une valeur maximale de flou définie par l’utilisateur) et des pixels à ne pas modifier, pour ensuite appliquer un flou gaussien.
Le filtre « Flou variable » / image Raphaël Bacco
Flou de l’objectif (Lens Blur dans le logiciel) a le même fonctionnement mais avec l’imitation bien plus réaliste d’une perte de focus permettant l’exclusion d’objets nets au premier plan, grâce à la mise en lumière (Highlight dans le logiciel) de l’arrière‑plan flouté. Vous pouvez également contrôler les seuils d’activation de cette mise en lumière.
Le filtre « Flou de l’objectif » (Lens Blur)
Flou de focus propose une interface simple pour créer des flous de mise au point, en utilisant les mêmes outils de manipulation visuelle que le filtre « Médaillon ». Vous pouvez choisir la méthode du flou gaussien ou celle du « Flou de l’objectif ». Une des utilisations de ce filtre est la création de fausses scènes de miniatures imitant les techniques photographiques — la méthode physique originelle pour obtenir cet effet utilise un décalage de lentille qui modifie le plan de mise au point.
Le filtre « Flou de focus » / image : Matt McNulty
Le nouveau filtre Floraison (Bloom dans le logiciel) crée un effet très similaire à ce que l’on peut obtenir avec le filtre « Lueur douce », mais contrairement à ce dernier, il ne désature pas l’image. En pratique, Floraison isole les zones mises en lumière, les adoucit, puis les recombine avec l’image initiale.
Le filtre « Floraison » / image : Brocken Inaglory
Améliorations de la fenêtre de dialogue des filtres
La fenêtre de dialogue des filtres GEGL possède une nouvelle option de fusion (Blending ou « Options de dégradé » dans le logiciel), qui permet de contrôler le mode de fusion et l’opacité avec lesquels un filtre est appliqué sur l’image initiale. Cette option remplace la fonction de fondu, qui a été supprimée dans la version 2.10.10.
Autre nouveauté : l’aperçu des filtres reste maintenant en mémoire même lorsqu’il est désactivé, ce qui permet de basculer rapidement entre les vues originale et filtrée.
Meilleure prise en charge du format PSD
GIMP pouvait déjà ouvrir des fichiers PSD à haute densité de couleurs (16 bits par canal). Dorénavant, ces mêmes images peuvent également être exportées dans ce même format. De plus, les canaux sont maintenant exportés dans le bon ordre, et dans leurs couleurs originelles.
Autres changements
- les différents outils de peinture peuvent maintenant sauvegarder et charger les configurations d’opacité et le mode de fusion dans des préréglages ;
- le format CR3 de Canon est à présent reconnu par GIMP et envoyé au logiciel de traitement brut (raw) de votre choix ;
- le greffon TWAIN pour l’acquisition d’image par numériseur (scanneur) a été légèrement réécrit et gère maintenant les images 16 bits en RVB ou niveaux de gris ;
- les greffons PNG et TIFF ont dorénavant pour comportement par défaut de ne pas enregistrer la valeur des couleurs lorsqu’un canal alpha est présent et a pour valeur 0, ce changement fait suite aux problèmes de fuite de données lorsqu’on se contente de découper des morceaux d’image pour en cacher le contenu en y laissant de la transparence ;
- le greffon PDF importe à présent les pages d’un document de bas en haut, comme pour les formats d’animation et comme les options par défaut d’exportation PDF ; cela apporte une plus grande cohérence, mais casse le fonctionnement des scripts tiers qui reposaient sur cette fonctionnalité.
GEGL et babl
Comme d’habitude, la sortie de GIMP est accompagnée par de nouvelles versions des bibliothèques babl et GEGL.
La nouvelle version de babl comporte surtout des corrections de bogues et des améliorations de performance, comme l’utilisation des instructions AVX2 pour la conversion des données gamma u8 vers des flottants linéaires (accélérant ces conversions d’un facteur 1,25 à 2,2). Elle apporte aussi la génération de fichier VAPI pour l’intégration Vala, utile depuis que la branche instable de GIMP prend en charge la création de nouveaux greffons en Vala.
Les changements majeurs de GEGL sont :
- de nouvelles fonctionnalités pour la gestion de métadonnées non EXIF, ajouté pour l’importation et l’exportation de divers formats de fichier de manière générique ;
- une interpolation cubique plus rapide et plus douce ;
- GEGL échoue proprement (au lieu de planter le programme en erreur de segmentation) lorsqu’elle manque d’espace d’échange mémoire (swap) ;
- l’opération « Chroma » a été corrigée pour éviter de modifier la teinte et la chrominance des couleurs neutres (nuances de gris) ;
- l’opération « Ombre portée » propose maintenant une option pour agrandir l’ombre, notamment avec un décalage X/Y à 0 et une ombre agrandie — on peut se servir de cette opération pour tracer ou « contourer » un calque de texte ou une image.
En outre, les nouvelles opérations suivantes ont été ajoutées (certaines ayant déjà été décrites plus haut) :
-
border-align: aligne une image aux bords d’une autre ; -
pack: joint deux images en une, avec un écart optionnel ; -
piecewise-blend: utilise une carte de niveaux de gris en index pour combiner une liste d’images comme une LUT (opération utilisée par les nouvelles opérations de flou) ; -
reset-origin: déplace le coin haut gauche à l’origine(0, 0); -
band-tune: égaliseur de bande paramétrique pour régler des bandes de fréquences d’image.
Contributeurs
Ont contribué à cette version : Ell, Jehan, Jernej Simončič, lillolollo, luz.paz, Marco Ciampa, Michael Natterer, Michael Schumacher, Nikc, Øyvind Kolås, pesder, Sabri Ünal, Salamandar, Sergio Jiménez‐Herena, Simon Budig, T. Collins et woob.
Ont contribué aux traductions : Alexandre Prokoudine, Anders Jonsson, Bruce Cowan, Cristian Secară, Daniel Korostil, Daniel Șerbănescu, Dimitris Spingos, Jiri Grönroos, Jordi Mas, Nathan Follens, Piotr Drąg, Rodrigo Lledó‑Milanca, Sabri Ünal, Seong Ho Cho, Tim Sabsch, Yuri Chornoivan et Georgy Timofeevsky.
Nous remercions également lillolollo, nmat, et Michael Schumacher pour avoir trié les rapports de bogues, ainsi que Julien Hardelin pour la mise à jour du manuel de l’utilisateur.
La suite
Nous finalisons actuellement le développement de la version 2.99.2, la première version instable de la série 2.99 qui mènera à la version 3.0.
Nous savons que cette version est attendue par des publics variés, des peintres numériques (notamment avec le branchement à la volée de tablettes graphiques) jusqu’aux photographes possédant des écrans 4K (les tailles d’icônes leur sont maintenant adaptées), en passant par les personnes qui voudraient simplement supprimer GTK+ 2 et Python 2 de leur système d’exploitation.
Cependant, un avertissement est nécessaire. Le temps de récolter les retours d’expérience et les rapports de bogue, nous ne recommandons pas la prochaine v2.99.2 pour un usage en production. Il y aura des améliorations comme des régressions par rapport à la série 2.10.x. Tous les détails seront publiés lorsque cette version sera (bientôt) publiée.
En attendant, n’oubliez pas que vous pouvez faire un don au projet et soutenir individuellement plusieurs membres de l’équipe. C’est une manière de récompenser les efforts accomplis, et d’accélérer le développement de GIMP.
# Destruction de l’information RGB avec un canal alpha nul (transparence complète)
Posté par Thomas Debesse (site web personnel) . Évalué à 10. Dernière modification le 22 juin 2020 à 01:36.
Où se trouve l’option, dans la fenêtre d’export ? Il me semble en effet impératif que la valeur de cette option soit très facilement basculable à l’export.
J’ai un avis mitigé sur le fait que ce comportement soit activé par défaut. Je comprends parfaitement la problématique de fuites de données.
Je me souviens d’une étude dont la source de donnée avait été publiée sous forme de google doc, et tous les noms des milliers de personnes sondées avaient été « anonymisées » avec une couleur de fond noir et une couleur de texte noir, une simple sélection ou un simple copier-coller dans un bloc note révélait les noms des sondés… 🤦
De l’autre, il existe de réelles situations où il peut y avoir des données RGB à conserver dans un pixel avec un canal alpha complètement transparent.
1. Cas rencontré de données RGB à ne pas détruire (canal alpha erroné)
Par exemple avec le projet Unvanquished, j’ai rencontré avec de vieilles cartes de Tremulous une skybox qui apparaissait comme entièrement transparente dans les miniatures de l’explorateur de fichier nautilus ou dans un éditeur d’image, mais apparaissait comme correctement opaque et coloré dans le jeu. Les faces de la skybox était des images en TGA, mais la conversion en PNG conservait le comportement étonnant. J’avais découvert que tout simplement le canal alpha était à zéro mais que le rendu de skybox dans le jeu n’utilise pas le canal alpha (ce qui fait sens puisqu’il s’agit de couvrir le « vide » du fond de l’écran et qu’il n’y a par définition derrière la skybox que du vide, donc des valeurs indéterminées. Le canal alpha était donc simplement une donnée inutile qui ne codaient rien.
Un utilisateur qui convertirait naïvement les textures en ouvrant le TGA dans GIMP et exporterait en PNG détruirait les données.
La bonne chose à faire pour celui qui manipule de telles images serait de supprimer le canal alpha erroné, mais il est dangereux de supprimer les données en faisant une simple conversion de format, ce qui peut arriver avant que l’utilisateur ne découvre que le canal alpha est erroné.
Dans mon cas je me suis rendu compte du problème bien après avoir converti les images en PNG.
2. Données stockées dans des canaux RGBA qui ne sont pas vraiment des images (le canal alpha ne code pas la transparence)
Les images au format PNG et autres formats ne servent pas nécessairement à stocker les couleurs et la transparence d’un objet sur lequel la texture est appliquée. Il est courant par exemple de stocker les coordonnées XYZ d’une carte normale dans les canaux RGB, et l’élévation d’un champs de hauteur dans le canal Alpha.
Il est par exemple tout à fait légitime de stocker une carte normale plate avec une hauteur nulle (une profondeur maximale). Avec des valeurs dans l’ensemble
[0.0, 1.0], une carte normale plate est codée comme(0.0, 0.0, 0.5)et une profondeur maximale est codée[0.0]. Dans le cas d’un fichier PNG stockant une carte normale et un champ de hauteur, dans le cas d’un canal alpha entièrement nulle, la destruction des canaux RGB doit produire des pixels de(0.0, 0.0, 0.5), pas de(0.0, 0.0, 0.0). Cet exemple de carte normale plate avec une profondeur maximale ne ressemble pas vraiment à un cas réel, mais c’est l’exemple le plus simple à décrire pour aborder le sujet. De réels cas avec tout un panachage de valeurs et quelques pixels avec un canal alpha à zéro est tout à fait réaliste.Aussi, il existe des tas d’autres combinaisons de stockage de textures dans les canaux. Par exemple le moteur Unity recommande une valeur « smoothness » dans les canaux alpha des textures spéculaires ou métalliques. Dans ces cas on ne peut pas se baser sur la valeur du canal alpha d’un pixel pour détruire les données des autres canaux.
De manière générale, c’est une très mauvaise idée de détruire les données RGB en se basant sur le canal alpha pour tout ce qui ne code pas la couleur et la transparence d’une texture.
Il est tout à fait légitime de manipuler et d’éditer de telles « images » dans un éditeur comme GIMP.
Pour référence, l’outil d’optimisation de compression PNG oxipng propose l’option
--alphapour détruire les canaux RGB invisibles en cas de transparence complète pour gagner de la place, mais cette option n’est pas active par défaut, et heureusement ! Il est tout à fait possible de coder du « noir » (0, transparence complète) dans un canal alpha pour coder autre chose que de la transparence.3. Il est possible de coder de la transparence mais de la faire varier ensuite
Il est tout à fait rationnel d’imaginer un logiciel (comme un jeu), qui lirait des composants RGB dans les composants RGB et un canal alpha dans le canal alpha, mais se garderait le droit de modifier le canal alpha pour réaliser certains effets. Par exemple on peut imaginer une image qui doit être pleinement transparente tant qu’aucun effet n’est utilisé, il ferait donc sens de mettre un canal alpha entièrement transparent dans ce cas, car ce serait la valeur par défaut. Il est impératif dans ce genre de situation que le canal RGB ne soit pas détruit.
4. Cas spécifiques de codage exotique
Il y a aussi le cas particulier où les canaux RGB ne sont pas stockés dans les canaux RGB pour produire une compression plus efficace avec des formats qui n’ont pas le même algorithme de compression selon les canaux (ce qui est vrai de PNG en fait) ou qui n’ont pas le même nombre de bit pour coder chaque composant, et dans certains cas, il est courant dans l’industrie de stocker les canaux RGB dans une autre disposition de canaux arbitraires. Par exemple il est courant pour une carte normale (qui n’aurait pas de donnée d’élévation dans le canal alpha) de ne pas stocker les coordonnées XYZ dans RGB mais X dans A, Y dans G, et de reconstruire Z par un calcul. Pour être honnête je mets ce cas en dernier parce que je doute beaucoup que des utilisateurs rencontrent ce problème avec GIMP.
En général ce genre d’optimisation se fait avec des format d’images spécifiques (DDS, CRN…), mais comme le PNG ne stocke pas le canal Alpha de la même manière que les canaux RGB, il n’est pas absurde de penser que des hacks de ce type puissent être utilisé avec le PNG. Il n’est pas absurde que des gens utilisent le format PNG comme format intermédiaire, même si je pense sincèrement qu’à peu près tout le monde utilise des outils qui échangent les canaux au moment de convertir un format comme le PNG vers le format final, sans stocker le fichier intermédiaire pour édition. Mais je ne peux pas garantir à 100% que ça n’arrive jamais nulle part.
Question probabilité que ces cas ce produisent, les cas 3. et 4. relèvent plus de l’expérience de pensée, j’ai déjà rencontré le cas 1. pour de vrai même si je reconnais que c’est exceptionnel, et pour le cas 2. ça peut concerner des milliers d’artistes et développeurs.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Destruction de l’information RGB avec un canal alpha nul (transparence complète)
Posté par Thomas Debesse (site web personnel) . Évalué à 7.
Autrement, bravo à l’équipe pour cette nouvelle version et merci pour le travail accompli, la fidélité tout ça. Et pour la dépêche ! 👍
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Destruction de l’information RGB avec un canal alpha nul (transparence complète)
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
C'est l'option intitulée "Save color values from transparent pixels" (il ne semble pas y avoir de traduction française encore, sauf erreur) lors de l'export PNG ou TIFF. Cette option existe déjà depuis longtemps et est changeable d'un clic en effet. Simplement maintenant elle est décochée par défaut.
Tout à fait, on a beaucoup hésité et discuté sur ce sujet. Voir le rapport de bug: https://gitlab.gnome.org/GNOME/gimp/-/issues/4487
Ça fait partie de ces sujets clivants où y a une partie des gens qui va nous tomber dessus car on fait A, et une autre partie qui nous tombera dessus lorsqu'on fera B à la place.
En fait tout cela n'a pas tant d'importance cependant car la vraie solution est qu'il faut comprendre un peu ce qu'on fait. Quand on utilise un outil, il faut comprendre ce que cet outil fait, sinon on est juste mal. Là en l'occurrence on exporte (non une sauvegarde, mais un export de résultat dans un format de fichier à perte). Si quelqu'un exporte en s'attendant de garder le contenu des canaux RGB pour des pixels totalement transparents, sans même vérifier si c'est vraiment le cas, ben c'est un peu du travail bâclé. C'est évidemment un usage avancé et donc quelque chose à vérifier.
Et si on veut pouvoir revenir sur l'image pour la retravailler, il faut de toutes façons sauvegarder, donc en XCF. PNG n'est un format de travail (et comparé à du XCF, c'est bel et bien destructif, quoiqu'on en dise). Il ne faut pas sauvegarder du travail en PNG, c'est juste pour un export final. Or en XCF, on ne supprime bien évidemment rien, notamment tous les canaux sont parfaitement préservés avec les infos de couleur.
Tes 4 cas listés sont de vrais cas et clairement des choses qui se font, mais quelqu'un qui travaillerait sur des variantes de signification des canaux, des formats dérivés, ou de l'imagerie avancée, etc. et qui ne regarderait pas les options d'export en détail, ben il fait une erreur dans son travail.
Attention, je ne dis pas cela seulement dans ce sens. Mes remarques sont vraies aussi quand adressées à ceux qui demandaient ce changement de valeur par défaut. Quelqu'un qui veut juste "masquer" des informations en rendant une zone transparente sans réfléchir au fonctionnement d'un format d'image (et donc du codage de couleur dans plusieurs canaux, pas juste le canal alpha pour la transparence) fait tout autant une erreur dans son travail. De même que les gens de ton exemple qui vont juste "masquer" avec du texte sur fond noir dans un google docs. Et puis y a les exemples très connus des gens qui vont ajouter des "rectangles noirs" devant du texte sur un PDF (qui est un format vectoriel, et donc le carré noir est juste un objet au dessus du texte qui n'est absolument pas supprimé).
En fait tous ces gens, dans un sens comme dans l'autre, font juste l'erreur de ne pas chercher à comprendre leurs outils de travail et vont ensuite blâmer le dit outil de ne pas avoir su lire dans leur pensée pour choisir à leur place (car il y a des cas où faire un rectangle au dessus du texte est vraiment ce qu'on voulait faire; et d'autres où on voulait en fait faire disparaître le texte. De même qu'il y a des cas où on veut ne pas toucher les canaux de couleurs même avec un canal alpha à 0, et d'autres où c'est l'inverse). Donc sur ce coup, on a juste fini par céder pour la valeur par défaut d'une option lors de l'export seulement, mais d'après moi cela ne change pas grand chose au vrai problème qui est celui de réfléchir (et non pas demander à l'outil de penser à notre place). C'est nous le boss, pas le logiciel.
Très honnêtement discuter ad-vitam eternam à ce que devrait être la valeur par défaut de cette option me fait plus l'impression d'être une perte de temps pour moi (temps que je pourrais utiliser à coder plutôt!). 😛
Là l'argument (dans un camps de l'option comme dans l'autre) est en gros toujours "ah mais si j'ai pas envie de réfléchir, ça marche pas". Ben oui, c'est souvent le cas pour tout. Que ce soit un des cas d'usage ou l'autre (car tous ces cas d'usage existent bel et bien, y a rien à en redire, autant ceux où on veut garder les valeurs de canaux non-alpha, que ceux où on veut les faire sauter), la solution, c'est juste de réfléchir. 😉
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Destruction de l’information RGB avec un canal alpha nul (transparence complète)
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
J'adore cette phrase très pertinente. Elle montre aussi la limite de l'ergonomie.
S'il y a un domaine où les geeks n'excellent pas, c'est l'ergonomie. Mais on ne peut pas dans un logiciel complexe pré-mâcher tous les choix. Il faut que l'utilisateur connaisse son sujet.
Gimp est devenu un outil complexe qui a conservé une assez grande simplicité pour des fonctions basiques. Cela peut laisser croire que tout est simple.
Les fonctions avancées de Gimp demandent un apprentissage. On touche alors à une utilisation professionnelle et comme pour tous les outils performants, la courbe d’apprentissage peut être raide.
J'ai eu la chance d'avoir André Pascual pour professeur. Même avec cela, il y a des tas de techniques graphiques que j'ignore, même si je me débrouille bien. Il m'arrive de temps à autre de l'appeler ou de venir me voir pour m'expliquer comment je dois m'y prendre pour arriver à mes fins.
La force de Gimp est de pouvoir être utilisé par un débutant alors que c'est un logiciel de qualité professionnelle. Ce n'est pas parce qu'on a la même raquette que Federer que l'on pourra jouer comme lui !
[^] # Re: Destruction de l’information RGB avec un canal alpha nul (transparence complète)
Posté par barmic 🦦 . Évalué à 4. Dernière modification le 22 juin 2020 à 16:58.
L'ergonomie ce n'est pas l'absence de cerveau. Dans un cas comme celui-ci ça peut être mettre en évidence qu'il y a un choix à faire et présenter ses implications.
L'objectif de l'ergonomie pour un logiciel comme gimp c'est que la difficulté ne vienne pas de l'outil, mais plus que de la technique d'imagerie.
Mais ça n'enlève rien à la pertinence de la phrase.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Destruction de l’information RGB avec un canal alpha nul (transparence complète)
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 10.
On ne le dira jamais assez. Tout logiciel nécessite un apprentissage, d’une part, et des connaissances préalables, plus ou moins importantes pour qu’on puisse s’en servir correctement.
Le truc soi-disant « intuitif » ne l’est que parce qu’il repose sur ces connaissances préalables et une capacité de réflexion.
Après je ne suis pas forcément d’accord avec sur l’absence d’excellence des geeks en matière d’ergonomie.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Destruction de l’information RGB avec un canal alpha nul (transparence complète)
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Certes, il existe des geeks excellents en ergonomie, mais ça ne court pas les rues !
Le grosse difficulté pour un développeur est de se mettre dans la peau d'un utilisateur de son logiciel. Les meilleurs résultats sont obtenus quand l'utilisateur et le développeur travaillent ensemble et apprennent chacun le métier de l'autre.
[^] # Re: Destruction de l’information RGB avec un canal alpha nul (transparence complète)
Posté par jyes . Évalué à 9.
Une spécificité de beaucoup de logiciels libres c’est d’être développés par leurs utilisateurs principaux, ce qui atténue beaucoup cette difficulté. Il y a aussi beaucoup de cas où l’utilisateur juge l’ergonomie d’un logiciel par comparaison avec ce qu’il connaît (et par conséquent de cette démarche, le nouveau logiciel est forcément moins bien). La plupart des utilisateurs que j’entends critiquer les logiciels de « geeks » c’est parce-qu’ils n’en comprennent pas la logique, mais leurs propositions sont rarement pertinentes.
ˆ:wq
# Détail
Posté par alex666 . Évalué à 7.
"Médaillon" c'est en quelle langue?
en français, ça s'appelle vignettage…
[^] # Re: Détail
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Juste pour info, car on a régulièrement des gens qui nous font des remarques sur les traductions de termes techniques. GIMP est un logiciel libre, et donc comme la plupart des logiciels libres, GIMP est ce que vous en faites. C'est vrai pour le code autant que les traductions, les docs, etc. C'est pareil que pour Linuxfr d'ailleurs.
Donc pour les traductions, les développeurs s'en occupent absolument pas. Nous laissons cela aux traducteurs de GNOME qui fonctionnent en équipe par langage.
La page pour l'équipe de traduction francophone est là: https://l10n.gnome.org/teams/fr/
Vous y trouverez le lien vers le bugtracker de l'équipe de traduction si vous voulez vous contenter de déposer un rapport de bug et vers un site qui explique les règles de contribution si vous voulez aller plus loin et rentrer dans l'équipe pour aider à traduire davantage, etc. 😃
En gros, ça sert pas à grand chose de rapporter un problème de traduction ici (j'ai aucune idée si "médaillon" est ou non une bonne traduction), sauf si par chance un des traducteurs fréquente linuxfr. Les développeurs n'interfèrent pas avec les équipes de traduction (elles sont maîtresses de leur zone de compétence).
Voili voilà!
P.S.: bien sûr, il y a aussi les cas où un élément n'est pas encore traduit et donc une erreur éventuelle de traduction ne serait alors que du fait des relecteurs de Linuxfr qui ont pris l'initiative d'une traduction pour l'article. Bon en l'occurrence, ce ne semble pas être le cas ici (on trouve bien cette traduction dans le fichier po). Je précise juste histoire de rappeler qu'il faut vérifier avant de rapporter une erreur de traduction, au cas où elle n'existerait que dans notre article, bien sûr!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Détail
Posté par ElectronLibre63 . Évalué à 4.
Dans quel français ? Car moi j'ai toujours entendu les photographes parler de vignetage.
[^] # Re: Détail
Posté par alex666 . Évalué à 6.
Et sans supplément de prix on pourrait avoir les deux t à vignettage!
[^] # Re: Détail
Posté par ElectronLibre63 . Évalué à 10.
Bah si, ça coûte un t de plus, et à part se rapprocher de l'orthographe anglaise et s'éloigner de la prononciation française, je ne vois pas l'intérêt.
À l'époque où j'ai commencé la photographie au reflex, je ne connaissais pas l’existence d'internet, et il y avait peu d'ouvrages sur la photographie dans la petite bibliothèque de ma ville, j'ai donc eu surtout une transmission orale de la pratique de la photo. Le vignetage était un sujet qui était rarement abordé par les photographes, sauf pour parler des défauts d'un objectifs, ou alors par ceux qui avaient la chance d'avoir un labo et qui pouvaient s'amuser à faire des effets sur leurs photo au développement. La plupart des photographes comme moi, donnaient simplement leurs pellicules à développer à un labo et ne s'occupaient donc pas de ce genre de choses. Je ne connaissais qu'une seule personne qui avait un petit labo noir & blanc, et je l'ai toujours entendu prononcer vignetage. Et les rares magazines que j'ai acheté pour avoir des comparatifs d'objectifs, écrivaient également vignetage. Avec le développement d'internet, l'accès à l'information étrangère est devenu de plus en plus facile, et essentiellement en langue anglaise, et en même temps, j'ai vu de plus en plus de personnes se mettre à écrire vignettage voire même des fois vignetting. Vu qu'il y avait déjà un mot en français, je ne vois pas l'intérêt de la remplacer par un mot franglais, donc personnellement j'en reste à vignetage. Même si j'ai toujours trouvé ça bizarre, car le mot est probablement dérivé de vignette. En fait, c'est peut-être une faute d'orthographe qui s'est propagée, mais je ne suis pas linguiste, je ne connais pas l'étymologie de ce mot (aussi bien en français qu'en anglais).
Sinon, médaillon, j'aime bien aussi (d'ailleurs il a peut-être été choisi pour éviter les débats vignetage/vignettage :).
# Merci
Posté par DavidB (site web personnel) . Évalué à 8.
Merci pour la news: c'est très informatif et très clair. Super boulot :)
# Thème sombre
Posté par pamputt . Évalué à 7.
Bonjour, la version empaquetée par ma distribution est la 2.10.10 donc ce n'est peut-être plus présent dans les dernières versions. Je voulais savoir si d'autres personnes que moi avaient des problème avec le thème sombre. Globalement, j'aime bien mais le texte des boites de dialogue est illisible chez moi, je dois toujours le surligner pour voir ce qui est écrit. Exemple avec les deux images ci-dessous avec la fenêtre de création d'un nouveau fichier
Ca vient peut-être de mon thème mais je n'ai pas encore pris le temps de regarder.
[^] # Re: Thème sombre
Posté par ʭ ☯ . Évalué à 5.
J'ai le même souci, sous Plasma. Peut-être un problème de conversion de thème GTK/QT comme au bon vieux temps?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Je sors
Posté par ʭ ☯ . Évalué à 5.
Wahou, on sait enfin comme s'occupe le septuple champion de Formule 1.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Je sors
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Ahahah. C'est un homonyme (un vrai de naissance, pas juste pseudonyme). Pour l'anecdote, y a quelques années, quand on avait loué un appartement pour l'équipe de GIMP pour le Libre Graphics Meeting (qui était en Allemagne cette année là), il s'était occupé de faire la réservation. La propriétaire attendait avec impatience devant l'appartement pour remettre les clés. Elle a été déçue quand notre schumaml à nous est arrivé. Elle s'attendait à un pilote de F1. 😉
Notre Michael Schumacher à nous, c'est lui: https://www.gimp.org/news/2017/05/15/an-interview-with-michael-schumacher-gimp-administrator/
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.