Discourse perd les pixels du haut/bas lors de la génération de miniatures

Lorsque vous joignez des images à un message, Discourse les redimensionne pour créer des vignettes adaptées à l’affichage.

Il semble y avoir un bug lors de cette opération, qui entraîne systématiquement la perte des premières et dernières lignes de pixels.

Ce n’est pas un problème majeur, mais cela rend les éléments aux bordures fines étranges (par exemple, la plupart des captures d’écran de logiciels Windows 10 semblent incorrectes car le bord inférieur de la fenêtre manque).

Observations :

  • Cela ne semble pas être dû au rapport d’aspect, donc je ne pense pas qu’il s’agisse d’un recadrage intentionnel d’images très larges ou hautes ; cela ressemble à un bug.

  • J’ai vérifié que des pixels manquaient dans la ressource réelle de l’image miniature. Cela se produit donc lors de la génération de la vignette côté serveur, et non lors de son affichage par le navigateur.

  • Édition : Je viens de remarquer que les pixels du haut et du bas ne sont pas complètement disparus, mais ils sont si fondu estompés qu’ils pourraient tout aussi bien l’être. Peut-être que cela a à voir avec la manière dont les bords de l’image sont gérés par l’algorithme de redimensionnement ? Cela ne semble jamais se produire sur les bords gauche et droit, par exemple avec des captures d’écran au format portrait.

  • Lorsque vous cliquez pour afficher l’image en taille réelle, celle-ci s’affiche correctement, du moins.

J’espère que cette image d’exemple reproduira le problème ici, sur le forum Discourse :

Cela devrait être une image blanche avec une bordure rouge d’un pixel sur tous les côtés. Si le problème se produit ici, vous ne verrez que les bordures gauche et droite jusqu’à ce que vous cliquiez pour afficher l’image en taille réelle.

(Édition : Cela semble effectivement se produire ici.)

Au cas où cela ne se produirait pas, voici le résultat que je vois sur mon propre forum :

Lors de ce test, vous devez attendre un peu après avoir publié (et parfois rafraîchir le fil de discussion) pour que cela se produise, car la génération de la vignette côté serveur prend quelques secondes après la publication.

4 « J'aime »

Oui, j’ai remarqué cela aussi depuis un certain temps. Je ne suis pas sûr de ce qu’on peut y faire.

1 « J'aime »

Intéressant, je vois le haut, la gauche et la droite, mais pas le bas.

chrome://gpu
Version de Chrome Chrome/87.0.4280.141
Système d’exploitation Windows NT 10.0.19042
GL_RENDERER ANGLE (Intel(R) HD Graphics 620 Direct3D11 vs_5_0 ps_5_0)
1 « J'aime »

Je me demande si cela dépend de la taille de l’écran, avec des ressources différentes servies à différents clients.

En regardant rapidement le message/l’image ci-dessus via F12, j’ai trouvé deux ressources, plus l’image originale :

  • Image originale (1416 x 946) /original/3X/e/2/e2c5f032e18fa374c0593af71cf25d3499826289.png, qui est inchangée. URL directe

  • Version plus petite (1380 x 920) optimized/3X/e/2/e2c5f032e18fa374c0593af71cf25d3499826289_2_1380x920.png, qui présente des bords supérieur et inférieur (presque) invisibles. URL directe

  • Version encore plus petite (640x460) optimized/3X/e/2/e2c5f032e18fa374c0593af71cf25d3499826289_2_690x460.png, qui n’a aucune bordure inférieure, mais conserve les bordures gauche, supérieure et droite. URL directe

Il pourrait exister des arguments ImageMagick pour ajuster l’algorithme de mise à l’échelle et la façon dont il gère les pixels aux bords, bien que tout changement puisse bien sûr aggraver d’autres situations tout en améliorant celle-ci.

1 « J'aime »

Oui, c’est aussi mon avis. C’est un problème lié à l’algorithme de redimensionnement. Tant que la version originale est préservée, je ne vois pas de problème grave ici, je le transfère donc dans la section des demandes de fonctionnalités.

4 « J'aime »