Partage d'URL sur Facebook : image de mauvaise qualité

T'as essayé de mettre l'og:image en jpg directement ?
https://developers.facebook.com/tools/debug/?q=https://cboncbon.jp/food/

 

Soit tu as trouvé depuis, soit il faudrait nous en dire plus sur ton protocole de test, parce que ça semble très bien comme c'est actuellement dans l'outil de test de Facebook.
(URL supprimée sur demande de l'auteur de la discussion)

 

Oui, il y a toujours une recompression JPG (qui n'est pas très doué avec ce genre d'images quand le taux de compression est élevé), et il n'y a rien que tu puisses faire.

 

Toutafé.

Comme il est question de formats d'images, j'en profite pour caser quelques infos sur JPEG XL, que j'attend avec une grande impatience :

https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs

https://www.slideshare.net/cloudinarymarketing/imagecon-2019-jon-sneyer

 

Ça, c'est toujours un peu le problème.
Mais une fois que ce sera supporté par ImageMagick et GD, déjà... une grosse partie du travail sera fait, les CMS pouvant l'implémenter facilement (pour ceux qui se chargent de redimensionner les grandes images).

Reste aussi le temps avant qu'une majorité de navigateurs installés le supporte, mais il y aura des modules Apache et NGinx pour transcoder à la volée. Sur le serveur, le fichier est un JPEG XL, et si le navigateur ne le supporte pas, le module convertit et lui envoie du JPEG. Ça n'est bien sûr pas idéal, mais ça évite de stocker les deux formats extrêmement longtemps parce qu'il reste, mettons, 10% de navigateurs anciens en circulation... j'ai rarement vu quelque chose d'aussi bien pensé pour faciliter la transition.


Il y a déjà un site qui permet de tester en ligne les gains pour les simples conversions de JPEG vers JPEG XL (et l'inverse, pour vérifier soi-même que l'opération inverse permet bien de récupérer le JPEG d'origine, octet pour octet, pixel pour pixel) : https://brunsli.dev (tout est fait coté navigateur).
C'est une interface pour la commande cbrunsli qui peut être déjà être installée manuellement depuis le Github https://github.com/google/brunsli

Bien sûr, ça n'est pas le "vrai" JPEG XL, mais cette idée de prendre en compte l'existant et de permettre de réduire l'espace utilisé par les JPEG me semble géniale. Rien que pour mon site, j'en vois l'intérêt (j'ai quelques centaines de milliers d'images... au moins), alors pour une boite comme Facebook/Instagram qui stocke des milliards et des milliards de photos depuis des années et qui ne sont plus consultées qu'une fois dans les neiges, j'imagine que l'idée de réduire leur stockage sans perte de qualité et avec une consommation CPU réduite va être très séduisante.