Glandos a écrit 1413 commentaires

Attention, il a utilisé l'option -m qui compresse un peu plus.

Mais moi, ce qui m'étonne, c'est qu'il me semblait avoir déjà passé zopfli sur cette image :/ Bon, mon avatar sur LinuxFR est vieux, j'ai dû découvrir cet outil après, va savoir…

L’objectif est de mettre à disposition de données riches, fiables, précises, standardisées, bien documentées et librement accessibles pour une connaissance 3D fine, et homogène du sol topographique, du sur-sol artificiel (bâtiments, ponts) et de la végétation.

C'est un peu caché au milieu, mais c'est une nouvelle que j'accueille avec bienveillance.

Sinon, il y a aussi la carte du chantier sur https://macarte.ign.fr/carte/322ea69dab4c7e5afabc6ec7043b5994/acquisitionslidarhd

J'ai une fonction fish qui fait ça :

function mozjpeg_all --description 'Re-encode multiple images using mozjpeg, preserving all markers'
    printf "%s\x00" $argv | xargs --null --max-args=1 --max-procs=3 -I'{}' /home/user/Dev/mozjpeg/build/jpegtran -copy all -outfile 'moz-{}' '{}'
end

Ça se transforme aisément en shell POSIX. Par contre, j'ai un avertissement de xargs qui me dit que je l'utilise mal, mais euh… ça marche.

Ah oui, c'est le jpegtran de mozjpeg. En général, ça économise 5 à 7 %. Sans perte par rapport à l'original.

Quand on rentre dans ce monde là, c'est compliqué. J'ai dû me forcer à y plonger pour une sombre histoire de Pixel Aspect Ratio et Display Aspect Ratio. C'est bien la guerre des maths. Ça ne reste que des règles de trois, mais c'est dur ne pas s'y perdre.

J'étais un peu sceptique, notamment face aux potentiels brevets, qui minent HEIF par exemple.

Ce long article semble dire que c'est pas le cas : https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs

Et surtout : la vitesse d'encodage de JPEG XL est bonne. Ce qui n'est évidemment pas du tout le cas de HEIF et AVIF. Le principal avantage de ces derniers restent la qualité à basse quantité de données. Ça parle des mini-animations, mais c'est évident que les codecs vidéos font mieux : c'est leur job.

Voir la discussion sur https://linuxfr.org/users/antistress/liens/le-nouveau-format-d-applications-pour-android-les-enferme-dans-le-google-play

Si ça pouvait envoyer les restrictions de AAB en enfer, ça serait bien. Mais voilà, je suis sceptique sur l'issue de ce combat.

une perquisition au siège de Doctolib, à Levallois-Perret.

Cette ville me dit quelque chose… Boah, c'est bon, je déconne ;)

J'ai plutôt envie de dire : enfin. C'est devenu difficile d'échapper à Doctolib aujourd'hui, en tant que patient. J'essaie, parce que je ne souhaite pas être contacté par SMS pour les rappels, et c'est obligatoire chez eux.

Enfin, pour être juste et honnête, ce n'est pas parce qu'une entreprise domine le marché qu'elle a franchi les règles. Si ça se trouve, l'enquête montrera que Doctolib a simplement fait mieux que les autres.

Ma compagne a acheté un Fairphone 3+ directement équipé de e/OS/. Ça marche. L'affichage de la note des rapports de Exodus Privacy dans le magasin d'application est très sympa.

OK, alors je découvre (horrifié) cette nouvelle…
D'après l'article lié :

In fact, App Bundles require that apps should be no bigger than 150MB.
[…]
For apps that need more than 150MB, App Bundles introduce a new feature to replace OBBs called Play Asset Delivery.
Play Asset Delivery also comes with the benefit of security since the assets are stored in and downloaded from Google Play rather than some CDN hosting provided arranged by developers on their own.

Je comprends totalement le besoin. C'est clair que télécharger une grosse application pour ne pas avoir à se servir de tout, c'est nul. Mais pourquoi avoir mis l'obligation de maximum 150 Mo ? Et si les gens veulent faire plus ?

Google prend de très gros risques à faire ça. Ça ne peut pas ne pas attirer le régulateur. Je comprends pas ce qui leur passe par la tête.

Ou alors, c'est un coup de bluff. Ça passe ou ça casse (et les contraintes se relâchent). Après tout, Google a une cote en or, ils peuvent se permettre se genre d'expérience…

Qu'on pouvait faire du RAII en C avec cleanup :

#include <stdlib.h>



#define autofree __attribute__(cleanup(free))



const size_t scratchpad_size = 500000;



void some_function(void) {

    autofree char *scratchpad = calloc(1, scratchpad_size);



    memset(scratchpad, 'A', scratchpad_size);

}

http://blog.projetarcadie.com/content/le-vote-electronique

J'ai hésité à le mettre dans la section des Liens. Mais c'est clairement dit : le vote électronique n'est pas transparent. En plus de coûter de l'argent.

https://xkcd.com/2030/

ImageOptim […] fera le travail en "devinant" les bonnes options.

Ou plutôt en brute-forçant non ? Enfin, c'est mon hypothèse, c'est souvent comme ça que font tous les encodeurs avec pertes d'images, que ce soit des images fixes ou vidéos :)

J'ai essayé Lepton aussi, mais le gros inconvénient est qu'il faut un décompresseur quelque part. Et personne n'en a. Ça prend pas mal de temps CPU à la compression et décompression, et le résultat en terme de taille est équivalent à du WebP, qui est largement répandu. Et à ce prix-là, on peut même partir sur du AVIF ;)

J'ai l'impression qu'il utilise pngquant mentionné sur https://imageoptim.com/versions.html

Ça a l'air d'être avec perte du coup, mais c'est à vérifier !

Voilà, exemple sur mon avatar en JPEG :

.rw-r--r-- 34k adrien 2021-06-17 23:06 avatar-fleur2-guetzli.JPG
.rw-r-xr-- 38k adrien 2021-06-17 23:05 avatar-fleur2.JPG
.rw-r--r-- 32k adrien 2021-06-17 23:07 moz-avatar-fleur2-guetzli.JPG

Le premier, c'est avec guetzli, le deuxième c'est l'original, le troisième, c'est mozjpeg après guetzli. C'est pas un exemple probant, mais j'avais remarqué que c'est quand même mieux :)

Oui, BPG, c'est du HEVC (donc H.265) intra-frame dans un conteneur. C'est assez efficace, mais c'est le HEIF, qui fait la même chose qui a été retenu et popularisé. Surtout par Apple, parce que c'est pas vraiment supporté non plus.

Sinon, le principe a été retenu pour AV1, qui est un codec vidéo, et dont on a extrait AVIF, qui utilise les algorithmes de codage intra-frame, sensé être plus performant que HEVC.

Mais c'est quand même très coûteux en décodage, comparé à du JPEG ou du PNG, surtout parce que ce sont des formats qui possèdent des routines d'accélération par les GPU, au contraire de AVIF (HEIF devrait pouvoir être accéléré aujourd'hui, mais je ne sais pas si c'est pris en charge). Ce point pourrait évoluer avec le temps. Et puis ça dépend du besoin… Pour afficher un logo d'un site Web, ça a besoin d'être rapide : c'est le temps de transfert plus décodage qui compte. et pas juste le temps de transfert.

Rejoindre WebP ? Je demande à voir. À tester facilement sur https://squoosh.app/

Mais j'allais dire ça : j'ai déjà testé guetzli et franchement… Ben ça fait mieux que MozJPEG, mais pour un coup démesurément plus grand.

Donc je proposerais, pour les gens qui n'ont pas peur du compromis, de mettre MozJPEG en complément de guetzli. En plus, MozJPEG produit exactement les mêmes pixels (en optimisant les tables de Huffman uniquement), contrairement à guetzli, qui rend l'image équivalente, mais qui change les couleurs.

Et si j'ai bonne mémoire, j'ai même eu des surprises : guetzli n'applique pas les optimisations de MozJPEG. Donc, passer MozJPEG après guetzli a du sens. C'est juste une étape de plus (mais rapide).

Pour les PNG, c'est clair que zopfli fait du très bon travail. J'ai pas mal utilisé optipng avant ça, mais rien à faire : zopfli est un peu plus long, mais pas tant que ça, et bien meilleur.

Non, les images compressées se décodent aussi vite. Voire plus vite, puisqu'elles sont plus petites. Mais en général, ça ne se voit pas sur les machines d'aujourd'hui.

Moi je suis d'accord.

Mais.

La solution, c'est d'abord de fermer la piste et l'aérodrome, et ensuite de construire. Je suis désolé, mais là, ça me fait penser à ces communes vendéennes après le passage de Xynthia. Qui était un drame bien plus grand, par son nombre de victimes, et par le fait que c'est la Nature, et qu'il faut s'y accommoder.

Oui, je sais, et c'est ce qui me désole finalement, parce qu'on est arrivé à une situation des débuts de la télévision : un seul fournisseur. Alors certes, les contenus sont infiniment plus diversifiés, mais avec l'opacité de l'algorithme de proposition, c'est quand même bien biaisé.

l'effort

On parle de cliquer sur un lien quand même… On est vraiment devenu flemmard à ce point-là ?

J'ai depuis très longtemps un salon XMPP disponible sur https://antipoul.fr/ que des anonymes peuvent rejoindre. Je ne suis pas souvent connecté, mais suffit de rentrer un pseudonyme, et c'est tout.

Je suis personnellement devenu utilisateur de Matrix, mais je garde quand même ce serveur XMPP, que j'auto-héberge sans souci avec Prosody.

Très bon exemple, en effet. J'ai un ami qui préfère justement largement faire son pain, alors que moi, c'est l'inverse. Je considère justement que c'est plus efficace de confier cette tâche à une seule personne, qui dispose de moyens plus efficaces de faire du pain pour plusieurs. Et c'est meilleur.

Donc oui, l'artisan maçon peut probablement auto-hébergé son site Web, mais c'est long et pas très efficace, donc il achète le service.

Mais là, on parle pas de l'artisan du coin, on parle du premier employeur de France ;)

Je ne comprends toujours pas cette position, qui consiste à acheter un service quand on peut se le fabriquer soi-même.

Et dans l'informatique, c'est pire : on va l'acheter, et personne ne va en profiter, alors qu'avec l'Open Source, c'est possible de capitaliser le travail.

Mais non, l'État pense que c'est pas possible de faire un truc Open Source soi-même, auxquels (soyons fous !) les citoyens pourraient contribuer. C'est fou comme idée.