gnujsa a écrit 815 commentaires

C'est vrai, j'ai été un peu sévère pour le JPEG2000. Lorsque l'on compresse, à une très faible qualité, le JPEG2000 réalise un véritable exploit. Là où le JPEG ne donne que quelques carrés de couleur, le JPEG2000 donne une photo certes complètement pourrie et floue, mais encore tout à fait reconnaissable. On peut faire tenir une Léna (floue) dans seulement 2ko ! C'est bluffant, mais quel est l’intérêt, hormis l'exploit ? L'IJG déconseille l'utilisation de la libjpeg à des niveaux de qualité inférieur à 50, et des logiciels comme Gimp ou Photoshop compresse dans les 85-95 par défaut. ImageMagick et cjpeg à 75. Et a ces niveaux, le JPEG2000 n'apporte presque rien en qualité (à la limite le JPEG peut même paraître à certains plus net/de meilleur qualité).

C'est vrai aussi qu'en termes de rapidité il y a de grosse différence entre jasper et d'autres implémentations

Mais ça reste quand même loin derrière PNG. Un test en lossless PNG vs 2 implémentations proprio de JPEG2000 (LuraWave et Kakadu)
http://www.imagecompression.info/gralic/

Compression Decompression
(sec) (sec)
LuraWave 381.56 373.81
Kakadu 312.77 273.03
PNG 844.37 72.62

Ce qui est particulier dans PNG, c'est l'asymétrie entre les temps de compressions et de décompression, ce qui fait qu'il est très léger pour les navigateurs. Et encore il est comparé, là, avec ce qu'il se fait de mieux en codec JPEG2000, pas avec ce que l'on a dans le libre…

Le JPEG2000 ça fait 10 ans que j'en entend parler, il est toujours pas intégré dans la totalité des logiciels que j'utilise, il faut passer par des conversions en lignes de commande, si le fichier est trop gros, ça fait en moitié freezer ma machine, et je vois pas la différence dans les niveaux de compression usuels, alors j'ai fini par perdre espoir. Mais dans le cinéma, il s'est imposé au travers du MJPEG2000.

Tu a complètement raison, mais c'est beaucoup plus facile de faire un calcul mathématique que de mettre en place un sondage, alors on s'en contente même si la métrique ne veut rien dire, ou pire si elle est trompeuse.

Par exemple la plupart des tests effectués sur les valeurs de bruits des appareils photos numériques sont basés sur l'écart-type calculé pixel à pixel. Le calcul est d'une simplicité enfantine, et ça donne un chiffre comparable, même s'il ne représente rien du tout. Un teste simple est de prendre une photo bruitée et de la flouter légèrement d'un flou gaussien. L'écart-type entre chaque pixel va bien chuter, et la métrique correspondante (SNR en dB) va augmenter, mais la photo ne sera pas meilleur. Elle sera moins nette d'une part, mais même son bruit ne disparaîtra pas. Il sera simplement étalé vers les basses fréquences ou justement l’œil est très sensible. Ça fera passer le bruit de type grain, à un bruit, encore plus moche, de type tache floue. Mais on aura en contre-partie beaucoup plus de décibel à annoncer sur la fiche technique …

Les techniques de calcule utilisées sur le site de Mozilla (type SSIM) sont censées remédier à ce problème et mesurer mathématiquement une impression visuel (!) Mais elles comportent d'autre biais. La technique du sondage de type JND (just-noticeable differences, seuil à partir duquel 50% des observateurs constate une différence) serait bien meilleure.
Kodak dans les années 90 utilisait ce système pour mesurer la granularité de ses films (le Print Grain Index)

Dommage qu'à cause des brevet on ne puisse pas choisir HEVC-MSP car il déchire tout dans le test.

moui.. J'ai pas regardé le test en détail, mais en ne considérant que le canal de luminance (le plus important visuellement), et à des taux de compression usuels (réglage "qualité" entre 75 et 90), ça fait en gros du 10% plus petit que le JPEG classique. C'est un tout petit déchirement alors… une égratignure.

La seule métrique vraiment flatteuse c'est celle en RGB, mais elle est à mon avis la plus trompeuse pour plusieurs raisons: les appareils photos, "sous-échantillonnent", dès la prise de vue les canaux R et B (matrice de Bayer: 2 fois moins de pixels rouge et bleu que de vertes), ensuite ils floutent encore un peu pour noyer le bruit, y compris dans les RAW ! (qui ne sont donc plus vraiment RAW, mais chute il faut pas le dire), puis encore une fois dans lors du dé-matriçage et également lors du dé-bruitage toujours beaucoup plus fort sur la chrominance. Et pour finir, les jpeg sont couramment utilisé avec les canaux de chrominances sous-échantillonnés.

Et pour la métrique basée sur le PSNR, et bien c'est même moins bien que le vieux JPEG pour les facteurs de qualité usuel (>75)

Alors, il y a pas de quoi sauter au plafond, je trouve, surtout si en plus il y a des cochonneries de brevets dedans.

Et quelque chose de TRÈS important, et pas indiqué par les tests, est : Es-ce que d'ouvrir une image, par exemple de 10 Mpix, met à genoux un ordinateur de plus de 4/5 ans ? (comme le JPEG2000). Parce que si le but est de remplacer le couple JPEG/PNG, ça veut dire que le web peut rapidement en être farci, et que ça serait bête que l'on soit obligé de racheter des ordinateurs derniers cris, ou de recharger la batterie de son portable tout les 1/4 d'heures, pour aucune amélioration visible …

Un autre raison qui doit peut-être faire hésiter Mozilla est qu'il existe au moins 4 concurrents aux fonctionnalités similaires;

• WebP
• JPEG-XR
• JPEG2000
• PGF

Moi ça me rappelle les débats (houleux) entre MNG et APNG cette histoire.

Sans compter, qu'hormis pour les compressions extrêmes (>15 ou 20:1), c'est pas mal dur de voire la différence entre chacun, et le bon vieux JPEG.

Reste les fonctionnalités, mais on arrive déjà à faire presque tout avec les formats existants:

• grande efficacité sur les photos —> JPEG
• grande efficacité sur les graphiques —> PNG
• grande profondeur de couleur —> PNG (16 bits, ça dépasse largement les capacités des meilleurs écrans)
• canal alpha (jusqu’à 16 bits !) —> PNG
• compression sans perte (lossless) —> PNG
• animation —> GIF^W ANPG^W MNG^W WEBM (ouf!)

Ensuite, tout le monde n'a pas le processeur dernier cri et des tonnes de RAM, et donc la rapidité de décodage est aussi importante à mon avis. Et là, le JPEG est très bon, mais le PNG est … imbattable! Il est rapide comme l'éclaire et consomme très peu de mémoire. Ce qui peu paraître étrange pour quiconque à déjà essayer d'enregistrer une image au format PNG, qui est une opération plutôt lente. (c'est un des plus lent en enregistrement, mais LE plus rapide en lecture). J'ose pas imaginer la catastrophe si on remplaçait toutes les images PNG que comportent les pages web par des JPEG2000 qui est horriblement lent à décoder.

Pour ceux qui veulent faire leurs propres essais, il y a ces paquets pour Debian (et peut-être d'autres distribs):

• JPEG: libjpeg-progs
• JPEG2000: libjasper-runtime
• JPEG2000: openjpeg-tools (autre implémentation)
• WEPB: webp
• JPEG-XR: libjxr-tools

Par contre pour le paquet pgf c'est autre chose (en rapport avec LaTeX). Il faut le compiler soi-même: http://www.libpgf.org/

J'avoue ne pas trop comprendre l’engouement pour ces formats, qui, à qualité égale ne permettent, au mieux, que de réduire un tout petit peu la taille des fichiers. Surtout si l'on compare les gains en lossless par rapport au vénérable PNG. À la glorieuse époque des modems 33k, 56k, j'aurai compris.

— "oui, mais un jour les écrans afficheront 65535 nuances de gris !"
— "bof, notre œil a déjà bien du mal à en discerner 255, et pour l'édition il existe des formats plus adaptés (TIFF, DNG)"

je peux réaliser la même chose en une ligne (une ligne, t'as vu comme je suis un grand hacker) de socat.

C'est impressionnant le nombre de dérivés et d'outils offrant les mêmes fonctionnalités (voire étendues) que netcat. En ne considérant que ceux packagés dans Debian:

• netcat (juste un méta-paquet celui là)
• netcat-traditional (l'original)
• netcat6 (ipv6)
• netcat-openbsd (multiples améliorations)
• netrw (optimisé transfert de fichier)
• cryptcat (netcat chiffré)
• socat (multiples améliorations)
• netpipes

Il y aussi d'autres programmes offrant des fonctionnalités similaires comme les paquets ucspi-tcp, ucspi-tcp-ipv6, tcputils, ainsi que des netcat "cachés" dans busybox (busybox nc) et dans nmap (fournissant /usr/bin/ncat, un netcat remplie d’améliorations). Et j'en oublie sûrement !

D'ailleurs avec un format d'image comme TIFF on s'évite purement et simplement les problèmes de polices ou de règles de mise en page, le destinataire reçois bien ce que l'expéditeur a devant le nez…

TIFF est peut-être le format d'image le moins sûr que je connaisse, tant il a de variantes. C'est en réalité un conteneur (un peu comme les *.avi (famille RIFF) en pire/mieux). Il a l'avantage d'être très souple, et l’inconvénient d'être très souple, ce qui fait que malgré son grand âge, il est encore très utilisé. Par exemple, la plupart des fichiers "RAW" des appareils photos numériques (.NEF, PEF, CRW, CR2, ARW, OTF, DNG, etc.) sont en réalité des fichiers TIFF "étendus". On peut également utiliser différentes compressions dans un TIFF, comme le jpeg, ou encore des images multi-dimensions (3D, 4D, 5D), stocker une vidéo, des systèmes colorimétriques exotiques, etc. Je l'utilise couramment, mais pour échanger des fichiers, je lui préfère un format plus "rigide", comme le JPEG ou le PNG (qui sont en plus des standards du web, donc lus directement par les navigateurs, même anciens, sans plugin).
Il date d'une époque où Microsoft n'était pas en position de monopole sur les systèmes informatiques et avait grandement intérêt dans des formats standards : Coopération Aldus/Microsoft (.TIFF), coopération IBM/Microsoft (RIFF: .AVI, .WAV, .ANI, etc.). Quelques années avant d'autres sociétés avaient été intéressées par les formats "d'échanges": Commodore/Amiga (.IFF), Apple (AIFF).

Une faille aussi beante restee ouverte aussi longtemps, ca a confirme ce que je pensais depuis un bail: personne ne relit le code, ceux qui le font n'ont pas les competences pour le faire bien, et ceux qui ont les competences ont bien trop de boulot pour le faire gracieusement.

Quoi, un seul contre-exemple te permet d'invalider le fameux "given enough eyeballs, all bugs are shallow" ? C'est maigrichon et un peu facile. D'autant que comme le fait remarquer Marotte quelques commentaires plus bas, ça ne concerne que Debian et ses dérivés, pas l'upstream OpenBSD, ni les autres distrib Linux.

Non, ce n'est pas la même chose. Sous Windows les logiciels IE et Windows Media Player étaient imposés par défaut (imposés car on ne pouvait pas régler les logiciels par défaut), et non désinstallables. Cela leur a valu des ennuis avec la commission européenne à l'époque. Je parle au passé, car il me semble que les choses ont changé depuis (c'est au moins devenu réglable/désactivable). Sous Debian, ces logiciels sont désinstallables (au prix minime de la perte d'un meta-paquet) et surtout désactivable très simplement depuis l'interface de firefox (iceweasel).
Les logiciels par défaut se règlent facilement dans Debian via la commande update-alternatives.


$ update-alternatives --get-selections|wc -l
276

Sur ma machine, je peux régler le choix de 276 programmes et bibliothèques par defaut réglables, soit beaucoup plus que sous des systèmes proprios. Il existe des interfaces graphiques à update-alternatives, notamment galternatives (Gtk) et systemsettings (KDE). De plus les bureaux Gnome et KDE permettent eux aussi de régler certains logicels par défaut de manière plus basique (navigateur web, MUA, éditeur de fichiers, etc.). Ces configurations n'étaient pas possibles sous Windows, et elles le sont devenues car Microsoft y a été obligé. Sous Linux en général, et Debian en particulier, c'était plutôt le problème inverse: trop de façon de configurer qui pouvaient entrer en conflit, d'ou la création des "alternatives" par Debian¹ (et utilisées depuis par d'autres distro), pour uniformiser la configuration des logiciels (et bibliothèques) par défaut.

Par exemple, comment lancer l'éditeur de texte par défaut ?
 * La variable d'environnement EDITOR ?
 * La variable d'environnement VISUAL (une manière générique d'appeler un éditeur de type vi) ?
 * Le script sensible-editor (du paquet debianutils tagué essential) ?
 * editor (lien symbolique géré par les alternatives) ?
 * gnome-text-editor (lien symbolique géré par les alternatives) ?
 * Via l'entrée gconf (Gnome) ou le réglage de systemsettings (KDE)?

Suivant la config, le nombre d'indirection peut être impressionnant:
réglage gconf ou systemsettings qui pointe vers sensible-editor qui pointe à son tour vers EDITOR ou VISUAL si les variables sont définies ou nano ou vi. Vi lui-même est souvent un lien vers vim (ou nvi/elvis), et vim est généralement un lien vers la version de vim installée (vim.gnome, vim.tiny, etc.) .

Ce message est un peu hors-sujet par rapport au journal, mais on retrouve trop souvent à mon goût des commentaires ultra-relativistes du type "finalement les logiciels propriétaires et les logiciels libres c'est tout pareil"

 
 
¹ Les alternatives ne règlent pas tout les problèmes, notamment car ces réglages ne sont accessibles qu'a root, d'où l'interêt des réglages de type gconf / systemsettings.

Moi qui ai 40 ans, je me rappelle avoir utiliser des disquettes jusque dans les années 97-98 sur mon 486 équipé du magnifique Win 3.11 for Workgroups. C'est sur, j'avais une vieille bécane. Les gens hype, découvraient Windows 95 OSR2 et le Pentium 166 MMX équipé de CD-ROM. Les disquettes (3.5") ont bien régné durant les années 90. Les graveurs CD-ROM apparus quelques années plus tôt étaient encore horriblement cher.

Un peu (plus) hors-sujet, mais j'ai appris aujourd'hui qu'orange arrêtait de relayer les newsgroup. Les applications n'ont plus de barre de menu, ni de barre d'outils, tout fout le camp. KDE reste mon dernier espoir.
C'est qu'une demi plaisanterie, j'ai peur que KDE soit envahi par des ergonomes comme d'autres bureaux libres … (et hop je reviens dans le sujet).

je suis étonné de lire que ce genre de fonctionnalité a disparu.

La réponse à cette question est d'ordre philosophique. Tu la trouvera à l'aide du navigateur web de gnome, en consultant cette adresse: about:epiphany

« Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher. », Antoine de Saint-Exupéry

Gnome est en route vers la "perfection".

Il y a un anachronisme dans ton message, car gcompris est bien plus vieux que l'ADSL "full dégroupé" (la "First stable release" de gcompris, la version 0.2.1, date de janvier 2001). Je m'en servais comme outil de propagande auprès des bons pères de famille à l'époque :)

E17 aujourd'hui n'a pas une seule ligne en commun avec E16. Il est aussi plus performant que E16 (Mais ca ce n'etait pas tres difficile).

Euh …
Remettons les choses dans leurs contexte. Décembre 1999 quand je découvrais E16 sur mon pentium 233 MMX/48 Mo de RAM, je trouvais ça … Whhouah. C'était le futur, le bureau animée qui s'ouvre en 2, super fluide avec ma carte en mode VESA, etc. Et c'était infiniment plus rapide que Gnome 1.4 ou KDE. Et à des années lumières de au niveau du look de Windows 98 SE qui venait de sortir ou de Mac Os 8 que j'utilisais au boulot. Voilà, à l'époque Linux, c'était "Whouha…". Maintenant, ça marche bien, mais c'est moins téméraire, ça copie avec une peur psychotique de paraître marginal. Bon ça n'a pas trop de rapport avec le sujet, j'arrête de faire le vieux grincheux, promis. Mais, je doute fortement que E17 soit capable de tourner sur les mêmes machines que E16 …

R.I.P. E16

Très interessant ton journal, mais alors, au final, pour mettre quelque chose dans le domaine publique en france, il faut forcement passer par une license type WTFPL¹ ?
Et quel est le problème réel a utiliser WTFPL ? (a part le ton comique sur lequel elle a été rédigé)

¹ Cette license, crée par Sam Hocevar, le Debian Project Leader actuel, comme une sorte de couche d'abstraction sur le domaine publique afin d'en gommer les diférences suivant les pays, donc pas que pour la france, même si son auteur est français.
http://sam.zoy.org/wtfpl/

Dans un des bug repport, quelqu'un avait calculer rapidement que son disque devait tenir 2 ans et demi avec le réglage d'ubuntu.

> depuis au moins deux ans, de nombreux collaborateurs ainsi que moi-même utilisons Ubuntu.

Profitez bien de vos disques, il vous reste encore 6 mois ;-)

On dit « à la itunes » (c'est marrant la consonance qu'a ce mot en français), comme on dit Quake-like au lieu de Doom-like (ou Wolf3d-like), mais il y en a eu plein d'autres, bien avant, qui ont défraîchie ces voies : achat de musique en ligne, et abstraction par une sorte de base de données (et même l'ergonomie, avec la navigation par tag). Je me souvient, par exemple, de celui-là: RealJukebox. Particulièrement infâme, bourré de spyware et tout DRMisé (et oui, déjà à l'époque, en 99)
http://www.sonicspot.com/realjukebox/realjukebox.gif

Il y en a sûrement eu d'autres encore avant. Mais, « on » oublie.

Même pas à les convertir. Il suffit de les utiliser comme des fonts Truetype. Le plus simple, c'est encore de les copier dans ~/.fonts

Mais il remplace carrement firefox! D'ailleurs ce message je le poste depuis songbird. Emacs a bien du soucis à se faire ...

C'est déjà le cas pour Krita: 8/16 bits et même 32, en RGB ou CMJN avec gestions des profils colorimétrique et calques de réglage ("couche d'ajustement"). Il faut reconnaitre que Krita avance incroyablement vite par rapport à Gimp ...

Puisque tu parles d'Ansel Adams, je te recommande la lecture de "The Print" et "The Negative". Tu y verras que, contrairement à toi, Ansel Adams n'a aucun a priori sur les différentes techniques qu'il utilise, qu'elles fassent pro ou pas. Il n'hésite pas à "pousser" ses films non pas pour gagner en sensibilité, mais pour adapter le contraste, il utilise le virage sélénium pour foncer les noirs (alors qu'il est prévu pour légèrement teinter le tirage et surtout stabiliser l'argent métallique), il va même jusqu'a voiler ses films, pour faire chuter le contraste ! On peut penser que si Ansel Adams était vivant aujourd'hui, il utiliserait non seulement Photoshop et Gimp, mais aussi tout les autres logiciels photos, juste pour profiter de tel ou tel rendu particulier. C'est pas le genre de type à n'utiliser que la technique que tout le monde utilise sous prétexte qu'elle est plus productive ...
Et puisque tu parle de productivité, tu a déjà travailler en photo ? Parce que de ce point de vue là, Photoshop est assez "oldschool" et même lent, comparé aux logiciels type Bibble/Lightroom/Aperture/Rawtherapy ...

> Par exemple tu parles de l'enregistreur de macro, c'est une feature introduite dans Photoshop en 1996.

C'est un journal sur Gimp et pas sur Photoshop, donc j'ai parlé d'une fonction qui me manquait avec Gimp. Si tu veux savoir, quand j'utilisais Photoshop, Ça me manquait de ne rien avoir de plus poussé qu'un simple enregistreur de macro, comme par exemple, avec Gimp-perl + PDL, infiniment plus puissant que l'enregistreur de macro de Photoshop.

Tu peux continuer à vomir sur Gimp si ça t'amuse. Photoshop est a un stade bien plus avancé que Gimp, personne ne niera cette évidence. Ils ont chacun des moyens et une histoire incomparable (pour rappelle en 1996/97 Gimp inventait inventait son propre toolkit: GTK - on le remercie au passage). Mais si je peux me permettre un conseil, c'est de laisser tomber tes dogmes sur LA façon de faire de la photo avec des logiciels "moderne", tu y découvriras plein de logiciel, pas très connus et peu "productif", mais au rendu unique - je ferai une liste un jour.

Désolé, j'ai répondu en partie à ton message dans la réponse faite à satan (sur linuxfr, pas le vrai satan :) )

> Les gens qui n'ont utilisé presque que the GIMP dans leur vie ont une façon de pensée qui a été marquée par le bas niveau et ils ne peuvent pas comprendre les gémissements des personnes qui ont eu, au moins plusieurs mois dans leur vie, accès à de vrais outils et pas un joujou.

Et les gens qui sont fanboy photoshop, ils sont comment, ceux-là ?

Alors voilà, je suis photographe depuis un bon paquet d'années, j'ai déjà bossé comme tireur dans des labos pro, etc, etc ... alors je sais un petit peu de quoi je parle et ce dont j'ai besoin !
Et là, on discute de 2 carences de Gimp. Moi je dit le 16 bits c'est le plus important et Zakath essaye de me convaincre que les calques de réglages sont indispensables. Pas plus.

Mes plus belles images n'ont pas du tout était faites avec de « vrai outils » (ridicule comme expression). Maintenant si tu es un photographe pressé, alors même photoshop va te paraître trop amateur ou orienté artiste. Ça m'arrive d'utiliser pour la retouche photo des logiciels tellement rudimentaires, qu'ils n'ont même pas la fonction "undo" (ou elle est trop buggué comme par exemple Iris ¹). Et quand tu fais du tirage N&B dans un labo, que tu dois maquiller avec tes petites mimines en "live", pour les agrandissements 30x40, 50x75 pas le droit à l'erreur, sinon ton patron te regarde d'un sale oeil. Et bien il n'y a toujours pas d' "undo" ou de calque de réglage. C'est vrai qu'en informatique on est habitué a avoir des assistants, des corbeilles sur le bureau, 36 confirmation « êtes-vous vraiment sur de vouloir ... ». Alors du coup on fait pas gaffe, on peut toujours revenir en arrière. On croit gagner du temps, mais finalement, souvent on en perd. par rapport a ce que dit Zakath au dessus, et bien je crame rarement mes hautes lumières, ou du moins je fait pas de la retouche pendant 2 heures sans m'en rendre compte (cf son message, volontairement extrème). Peut-être l'habitude qu'en argentique, ce genre de négligence coûte vite cher. Mais qu'on soit bien d'accord, les calques de réglages, c'est géniale, et j'aimerai beaucoup avoir ça dans Gimp.
Mais c'est pas ma priorité, ce n'est pas non plus ce qui me fait perdre le plus de temps. LE TRUC qui me ferait gagner du temps, c'est aussi un gadget, c'est l'enregistreur de macro de photoshop. Je perd un temps fou a faire des scripts jetables en perl (je suis pas du tout programmeur).

Désolé de m' être un peu emporté, et d'avoir répondu Zakath en même temps qu'a toi, mais j'ai eu une dure journée :) et le ton moralisateur de ton message m'a un peu agacé.

P.S.
y'a surement pas mal de code assembleur et C sur ta machine, il faut qu'ils soient tombé sur la tête tout ces développeur de ne pas utiliser de vrai outils comme .NET, java, ... :)

¹ http://www.astrosurf.com/buil/iris/iris.htm : Un freeware pour traiter les images astronomiques, avec des fonctions trés interessantes, comme par exemple son filtrage par ondelette. Fonctionne trés bien avec des images classiques, mais sous wine ...

> Après, oui, on peut faire sans, y a aussi des gens qui font du design avec paint ou qui naviguent avec IE...

Le rapport avec ces logiciels de microsoft ? On peut toujours revenir en arrière, supprimer, modifier, ajouter une opération, puis répéter les suivantes. Quelques soit le logiciels. Je faisais ça, même en argentique, avec des manipulations compliquées avec des masques. Que les calques de réglages soient d'un confort énorme, je le nie pas. Mais il s'agit de confort et pas de possibilité supplémentaire. Sous Gimp, on peut aussi s'aider des filtres d'affichage (gestion des couleurs, calibration, contraste, gamma). J'enregistre aussi plus de version intermédiaire, souvent dans un calque inclut directement dans l'image au format xcf non destructeur (mais en 8 bits). Je retiens plus, aussi, ce que je fait. Ça fait travailler la mémoire :) (En argentique je prenais plus de notes). Avec des logiciel du type Rawtherapy, Bible, ..., c'est pareil, c'est moins souple et/ou différent d'un calque de réglage, mais globalement, il y a toujours moyen de revenir en arrière, de manière non destructive, quelque soit le logiciel, souvent différemment, et de manière plus ou moins efficace.

Par contre pour la profondeur de couleur, il y a une perte d'information irrémédiable dès le début de l'édition. C'est, à mon avis, une bien plus grosse lacune de Gimp. Les calques de réglage font figure de gadget à côté. Et c'est d'autant plus désolant qu'il y a plein de logiciel libre sachant manipuler les images en 16 bits voire plus: Cinepaint, Nip, Digikam, ShowFoto, Krita, Rawstudio, Ufraw. Des logiciels proprio commerciaux tournant nativement sous GNU/Linux: Bibble, LightZone, NoiseNinja ou encore des freewares comme RawTherapy, Iris, ...
( Bon après, moyennant quelques acrobaties :), même l'édition en 16 bits est pratiquable sous gimp :
http://bellette.tuxfamily.org/pixelpost/index.php?x=page&(...) )

J'ai fait un ptit journal de seconde zone, de rien du tout et je me suis dit, comme ça, que je pourrai y mettre le titre que je veux. Et bien non !
Après les titres générique des menus, on va avoir droit au nom générique des journaux ?

« Sortie de l'éditeur d'image version 2.4.0 »

La base ? C'est surement très pratique et ça fait gagner du temps mais on retouche sans depuis des années. Et la plupart des logiciels n'ont même pas de veritable équivalent.
Par contre le 16 bits ...

Dis donc, toi, quand on utilise les mots "troll" et "marketeux", on évite de venir faire des remarques sur le franglais. Et puis tu pourrai être plus tolérant, vu qu'apparemment le bon français ce n'est vraiment pas ton fort non plus ...
Pour le splashscreen, j'assume, c'est une merveille :)