-
Dans un monde où on passe nos journées à expliquer comment réduire la taille de nos contenus, j’ai de la peine à voir comment cette solution peut être mieux qu’un bout de css… Surtout en étant destinée à des personnes du métier.
-
J’ai de la peine à voir l’intérêt de ce genre d’articles… Un simple lien aurait suffit.
-
Merci pour cet article où je découvre que Gimp peut sauvegarder aussi dans les formats que sont webp et avif.
Je me sers de Gimp pour avoir des images de cartographies. J’ai cherché à savoir si créer une image au format JPG, en qualité 80 % permettait d’avoir un poids convenable sans trop de dégâts. J’ai fait des tests avec une génération de la même image en Q=100 et utilisé, pour comparaison, d’autres outils de “destruction”.
Personnellement, je trouve qu’une qualité en deçà de 80, on pert sérieusement et si l’image est “complexe” (dans le type d’informations qu’elle renferme, beaucoup de couleurs, de détails, etc.), on se rend compte assez vite de la dégradation.
Pendant un temps, j’utilisais l’outil en ligne Optimizilla, et donc je m’en suis servi à ce moment là pour comparer aussi avec “ses” sorties. Il ne s’en sort pas “vainqueur”, loin s’en faut…
Mozjpeg est l’outil qui permet vraiment de garder de la qualité, tout en ayant une Q=80, et un poids + léger.
Idem pour une démarche concernant les formats webp et avif. C’est l’outil “convert” d’Image magick qui s’en sort le mieux. (il existe cavif - qui est pertinent -, avifenc, la lib webp, qui a des sous lib spécifiques à JPG/PNG d’un côté et GIF de l’autre)
Bref, ce n’est pas parce qu’un outil est “couteau suisse”, qu’il s’en sort le mieux. :p
Merci pour l’info. Voilà.
-
Hello PengouinPdt, merci pour le complément d’info.
C’est toujours délicat lorsqu’il s’agit de conseiller un outil pour des néophytes. De mon côté c’est cavif qui fait le taff, mais la CLI est souvent impensable sans accompagnement préalable. Pour ce qui est d’avoir mozjpeg dans Gimp, c’est prévu et ça devrait remplacer l’usage de libjpeg, de manière invisible pour l’utilisateurice lambda, ce qui me semble être une bonne chose.
Quant à ton point sur la qualité de l’image, certes une compression destructrice est, destructrice, après libre à chacun·e de se faire son idée. Je trouve que pour un affichage sur un écran d’ordinateur, sans zoomer dessus, le jpeg standard 75 est largement suffisant dans beaucoup de cas. Bien évidemment si l’objectif est de faire une galerie photo, ça me semble être un mauvais choix.
Merci pour ton avis :D
-
En fait, dans le contexte de cartographie, il me faut générer des images de qualité sans trop de pertes, d’autant que l’image “cible” minifiée est ensuite incluse dans un document ODF pour diffusion en PDF. Et pas question d’avoir une pixellisation conséquente. (Je rêve du jour où je pourrais faire cela avec le format SVG, vectoriel, mais c’est dans ce cas, très lourd - OpenStreetMap permet une sortie SVG ; du SVG dans de l’ODF me semble adéquat – ok, lors de la transformation en PDF, on y perd certainement.) :p
Concernant cavif, je plussoie ton choix, et je le trouve excellent aussi. Mais par “principe de fainéantise IT”, convert que j’utilise aussi pour le webp, dans des contextes de web, vu que je génère ces minifiées par script shell, j’ai fini par m’en servir aussi pour l’avif. Officiellement, Image Magick ne le supportera correctement que dans les futurs version à partir de la 7.x. Dans les faits, c’est fonctionnel déjà ; il fait le taf, gagne en poids, rapport à cavif, et avifenc.
-
Parfaitement, mais du coup on parle d’un exemple précis (le tien) et pas d’un conseil général :D Mais du coup, dans ton cas, tu sembles avoir toutes les connaissances pour faire le bon choix, ce qui n’est pas le cas du public de mon billet. Merci de tes précieux retours ;)
-
En fait, j’apprécie toujours de lire des articles, même sur des sujets que je connais déjà. Note : je ne dis pas “maîtrise”, car c’est loin d’être le cas. Et, bien souvent, il m’importe peu de maîtriser, mais surtout de pouvoir utiliser, et si possible, le plus aisément possible. Il m’importe surtout de comprendre, mais pas spécifiquement, jusqu’aux moindres détails, qu’exigent la maîtrise, la perfection du geste.
J’ai remarqué bien souvent que je peux toujours apprendre des détails ou en revoir d’autres. Et, cela me pousse. Cela a pour propos de voir comment d’autres font, avec quelle pertinence… ou parfois, voire de “l’étalage de connaissance, comme de la confiture”.
Exemple de détails : beaucoup, comme toi, recommande une compression de qualité à 75 pour le format JPG ; par défaut, certains logiciels, comme Mozjpeg, sont ainsi configurés. Ce qui n’est d’ailleurs pas le cas de Gimp, qui est à 90 de qualité par défaut. Comme tu l’as compris, dans mon contexte, je ne suis pas convaincu par ledit détail. 80 est une définition de qualité qui me convient. En deça, mon oeil saute, trébuche, est perturbé par les artefacts. Il faut dire que je suis fortement myope ; sans lunettes, je suis sérieusement invalide. Une qualité à 75, il commence à y avoir une sorte de flouté qui m’est désagréable, et parfois des artefacts visibles, selon l’image. Certains conseillent d’avoir la “source” au format PNG à qualité 100, et de compresser dans les autres formats. Toi, même, tu parles de détails, certes intéressants, dont personnellement, je m’en fous. Mais c’est très bien qu’ils y soient. Car ça peu intéresser bien d’autres, de manière pertinente.
De fait, hier, j’ai apprécié de découvrir, suite à ta lecture, et bien que tu n’en parles pas, ce qu’est PNSR, SSIM, etc. Et, de là, faire mon choix. tester, être convaincu… ou pas. :p Voire de découvrir d’autres outils, parfois encensés - à juste titre… ou pas.
-
-
-
-
Concernant Mozjpeg, je viens de découvrir qu’il avait des options d’optimiseur basé sur SSIM, voire apparemment mieux MS-SSIM. Et, en effet, pour une même qualité, –tune-ms-ssim permet de réduire un poil plus le poids que l’optimiseur PSNR-HVS, qui est par défaut - somme toute, cela semble normal. C’est bien sûr sensible sur des images de grosses tailles.
Il reste l’outil quetzli, de Google. Alors soit j’ai loupé quelque chose, mais impossible d’avoir une génération avec une qualité en-deça de 84, mais il est assurément lent - c’est même impressionnant les ressources qu’il s’accapare. ensuite, sur des petites images à qualité égales à ce que peut générer Mozjpeg, il fait des sorties plus légères, mais sur de grosses images, il ne fait pas mieux. Donc, pas convaincu.
-
-
C’est vraiment dommage de taper aussi fort sur PNG alors que dans beaucoup de cas il est bien meilleur que JPG, voir même que WebP ou AVIF. Si tu avais spécifié que ton billet s’appliquait uniquement aux photos ou dessins photo-réalistes, alors ça m’aurait convenu.
-
Hello,
En fait, oui, c’est un peu subjectif, car une histoire récente, une application pour un client qui avait une très mauvaise expérience utilisateur, car des fichiers PNG de 10Mo (sans transparence) était envoyé, et a l’époque, il n’y avait de recompression de l’app, car comme vous, j’optimise mes images avant de les envoyer, le problème, c’est que quand on es dans le monde de la Tech, on ne se rend pas compte que les gens, n’en savent pas autant que nous sur le sujet.
Bonne journée :)
-
Tiens, j’ai sorti mon article sur le sujet: https://trolliet.info/blog/038-tailleimage/
-
Top :)
-
-
-
-
-
Mouaif, un peu trompeur ce titre, pi pourquoi Docker bordel?
-
En quoi le titre est-il trompeur ? FreshRSS permet bien de suivre des flux RSS non ? L’article est une présentation succincte du logiciel et de son déploiement. Pourquoi Docker ? Pour séparer l’application du système et des autres applications hébergées. C’est un peu la ligne directrice du blog. Libre à vous de l’installer comme vous voulez.
-
-
-
Y’aurait moyen d’intégrer le plonk dans le JdH, comme au bon vieux temps de USENET ?
-
-
-
Cascador s’est déjà prononcé plusieurs fois sur le sujet. Si je ne me trompe pas, ce n’est pas dans l’esprit du JDH de downvote. Si on aime on vote si on aime pas on ignore et en moins de 24h la news a disparu.
Ce n’est pas mon article et je ne l’ai pas vu mais tu peux, rapidement et si tu as le temps, justifier pourquoi tu voudrais le downvote ? Merci :)
-
-
-
-
-
[Comment removed by author]
-
-
-
-
Derrière cette réflexion il y a tout simplement la question de la confiance : Accordes-tu plus de confiance envers Microsoft et son armée de dev et ses motivations purement financières (c’est une entreprise) ou bien la communauté Linux qui n’est pas une entité unique mais un aggrégats de devs aux motivations diverses (et parfois contradictoires) ?
À titre perso, j’ai plus confiance envers le noyau Linux qui attire l’attention d’énormément de monde avec son code ouvert plutôt qu’envers Microsoft qui fait ce qui fout ce qu’il veut dans sa soupe. Pour l’instant, l’Histoire a prouvé que d’un point de vue sécurité Linux s’en sort mieux…
-
-
-
-
-
-
-
Est-il vraiment si invraisemblable qu’une entité malveillante s’introduise dans votre système d’exploitation grâce à (ou par) « la communauté » ?
La réponse oui, 1000 fois oui. En parallèle, il est aussi évident qu’il faut partir sur une alternative Linux éprouvée (Ubuntu ou Ubuntu base, Debian base) et rester dans les standards. Tant que tu es dans les standard et que tu maj souvent ton système, ton scénario est proche du 0.
Et le jour où une entité infectera du Debian ou du Ubuntu, c’est peut-être déjà le cas, elle ne va pas utiliser son virus sur Madame Michu et visera quelque chose de beaucoup plus critique/valeur.
-
On a déjà vu des logiciels libres compromis. Ca arrive. Notamment sur des librairies.
L’avantage d’un code ouvert, c’est qu’il y a potentiellement toute l’humanité qui est capable de voir ce qui y a été fait. (toute l’humanité n’est pas compétente pour évaluer du code pour autant, on est bien d’accord).
Par contre je préfère utiliser une distribution la plus minimaliste possible pour laisser le moins d’angles d’attaque possible. Une Alpine sur laquelle on installe le strict nécessaire est bien plus sécurisée qu’une Debian qu’on laisse en base install à mon sens.
Et sinon oui, le particulier a bien peu de chance d’être victime d’une attaque ciblée. A moins que quelqu’un vous en veuille terriblement… c’est généralement des grosses entités qui sont visées (entreprises / états / parcs énergétiques…).
-
-
-
-
-
-
-
-
-
-
-
[Comment removed by author]
-
-
Y’a de bons exemples, j’ai bien aimé celui du sac de couchage !
-
-
Et niveau droits, ça se passe comment avec les solutions comme Funkwhale?
-
-
-
Ah, bah, comme d’hab c’est pas légal ;)
Donc après, techniquement tu peux le faire, mais tu sera une instance pirate qui se féderera avec d’autres instances pirates, et les autres instance qui veulent rester clean ne se fédereron pas avec toi pour ne pas avoir de problème ;)
-
-
-
-
Article sympa pour vulgariser le chiffrement. Seul petit point négatif AMHA : insister autant sur MD5.
Je me doute que c’est pour simplifier la rédaction, et c’est expliqué que c’est dépassé, mais quand on voit qu’il y a encore des sites qui s’en servent pour chiffrer les mots de passe, je trouve dommage de ne pas avoir au moins cité dans le paragraphe qui parle de MD5 les algorithmes qu’il faut utiliser de nos jours.
-
Et voilà que ça nous reparle d’une des pire plaies du web, les raccourcisseurs d’URL… Pamerci Korben.