Salut à tous, je me demandais pourquoi les GIF sont si petits lorsque vous les uploadez, même si vous choisissez 100 % de la taille, par exemple :
Cela ressemble à une erreur liée spécifiquement à ce que vous choisissez de télécharger ? Pouvez-vous le décrire exactement, étape par étape, avec des exemples ?
Voici un gif qui déclenche le problème. Lorsque je consulte ses propriétés sur mon ordinateur, son type est défini sur « image/gif ». Sa taille est de 10,4 Mo. Il semble que Discourse redimensionne ses images. Je peux télécharger des gifs plus petits que j’ai créés de la même manière sans aucun problème d’affichage.
Donc il s’agit de GIFs qui sont normalement trop volumineux pour respecter la limite de téléchargement, et ils sont redimensionnés automatiquement d’une manière ou d’une autre ? L’image résultante est minuscule :
50 x 29, 32 ko
Peut-être s’agit-il d’une régression @sam ? 
Possiblement une régression, cela se produit-il également avec des GIF non animés ?
Merci les gars — j’utilise http://giffox.com/ pour créer des gifs.
Ça marche parfois, parfois non… Je pense que vous avez peut-être raison concernant la taille. Je faisais juste quelques tests.
Ça fonctionne si c’est très court.
Voici un GIF de 2,06 Mo
Voici un GIF de 3,47 Mo
Voici un GIF de 9,06 Mo
Oui, il semble que quelque chose de très grave se passe à la limite de 4 Mo pour ces fichiers @sam @eviltrout. J’ai modifié le titre pour refléter le problème. Nous devons régler cela, nous avons régressé.
Je voulais juste confirmer que cela est isolé aux GIF animés.
Je pense que nous utilisons Gifsicle: Command-Line Animated GIFs pour le redimensionnement, donc je suppose que les paramètres ont changé.
@vinothkannans, peux-tu jeter un coup d’œil rapidement aujourd’hui ?
Cela se produit depuis que nous avons modifié la méthode de réduction de la taille des images. Le commit ci-dessus corrigera ce problème et les GIF plus volumineux seront réduits correctement.
Est-ce la bonne correction ? Je ne pense pas que nous devions « réduire la taille » de ce qui sont essentiellement des vidéos. Cela me semble être une manipulation plutôt extrême (et potentiellement très coûteuse en CPU serveur) qui pourrait altérer la qualité des vidéos (GIF).
Je ne suis pas convaincu par cette approche. Je pense que nous devrions carrément rejeter les GIF animés trop volumineux plutôt que de nous forcer à gérer le redimensionnement vidéo (ou encore mieux, la conversion en MP4), ce qui est un tout autre problème à résoudre.
Oui, cela semble être une correction simple. Je vais modifier la fonctionnalité actuelle.
De toute façon, il semble que nous redimensionnions les images GIF depuis les 5 dernières années en utilisant « gifsicle », sans rencontrer de problèmes de performance. @zogstrip pourrait fournir plus de détails.
Je pense que dans ce cas, rejeter des gifs très spécifiques va ajouter plus de code à notre dépôt.
Pour le moment, nous supposons simplement que tous les gifs sont « animés » comme indiqué ici :
Si nous devons modifier cela pour rejeter certains gifs, nous devrons mettre en place une détection de format pour les gifs animés, puis implémenter un code spécial de rejet. Cela est particulièrement compliqué pour les images que nous devons optimiser (en raison de leurs dimensions), car nous ne pourrons plus optimiser les gifs animés.
Côté positif, nous pourrons nous débarrasser de la dépendance gifsicle. Côté négatif, notre pipeline de téléchargement deviendra plus complexe.
Personnellement, je pense que la correction de @vinothkannans est acceptable et présente peu de risques ; c’est du code que nous utilisons depuis 5 ans et, à ma connaissance, il ne pose pas de problèmes majeurs de performance.
Cela dit, @codinghorror, je ne m’engagerais pas dans ce débat si tu souhaites supprimer le support du redimensionnement des gifs animés, mais ce serait un changement assez complexe. L’identification est assez simple, mais gérer le rejet avec un message d’erreur pourrait être un peu délicat.
Votre gif animé dépasse 10 Mo, il ne peut donc pas être téléchargé.
Votre gif animé dépasse 600x400 pixels, il ne peut donc pas être téléchargé.
En tout cas, la décision t’appartient. Mon avis est de laisser la correction telle quelle et d’avancer, mais si tu souhaites supprimer ce support, fais-le nous savoir.
Notez que cette suppression nécessitera également de retirer le support des avatars animés (une fonctionnalité optionnelle ; honnêtement, je ne suis pas très enthousiaste à l’idée de devoir le faire).
Hmm, donc tant que le GIF animé tient dans la limite de taille de téléchargement totale (??), sa « qualité vidéo » est effectivement réduite pour correspondre à quoi ?
Je suis vraiment perdu quant à ce qui se passe réellement ici.
Évidemment, redimensionner la hauteur et la largeur est totalement inapproprié pour un GIF… c’est ce qui a conduit au bug initial ci-dessus ?
L’historique est que nous « détruisions » les GIF animés lors de l’optimisation : si vous téléchargez des images destinées à être affichées en lightbox, nous les abîmions.
L’intérieur de notre code ne comportait aucune logique de « détection » pour déterminer si un GIF était animé ou non. L’affichage en lightbox intervient après que le message a été enregistré dans la base de données.
La correction consistait à faire en sorte que notre code de « redimensionnement » n’abîme plus les GIF animés et fonctionne correctement avec eux.
Le problème est que nous devons reprendre des parties de notre chaîne de traitement des téléversements pour prévoir un « traitement spécial » des GIF animés si nous supprimons le support.
- Un GIF est téléversé
- S’agit-il d’un GIF animé ?
- Le préprocesseur aura-t-il besoin de le redimensionner ?
- rejeter le GIF animé
- Le postprocesseur aura-t-il besoin de l’optimiser ?
- rejeter le GIF animé
- Le préprocesseur aura-t-il besoin de le redimensionner ?
- S’agit-il d’un GIF non animé ?
- le laisser passer avec la chaîne de traitement normale
- S’agit-il d’un GIF animé ?
Il faut également prendre en compte certains effets secondaires liés à la régénération à long terme du Markdown si les paramètres changent un jour, ainsi qu’au chargement d’images hotlinkées.
La solution consistant simplement à corriger le redimensionnement signifiait que nous n’avions pas à nous soucier de tout cela.
Je ne pense pas que nous devions procéder à une « optimisation » des gifs animés du tout, donc je pense que le code doit le détecter. Ajouter ce chemin ouvrirait la voie à une conversion éventuelle de gif en vidéo mp4, ce que nous souhaitons de toute façon… éventuellement. Je considère donc que ce travail est nécessaire.
Pour clarifier.
Vous souhaitez que nous :
- Supprimions
gifsiclede notre image Docker - Lorsque vous retravaillerez les anciens messages contenant des GIF animés redimensionnés, ils s’affichent avec un glyph d’image brisée dans le message
- Corrigez notre tâche de récupération d’images hotlinkées pour éviter de télécharger des GIF animés nécessitant un redimensionnement, en affichant un lien à la place
- Rejettez les GIF animés qui sont soit trop grands (en dimensions ou en taille) et animés
- Retiriez le support des avatars animés de Discourse
- Gardiez une trace des images animées et non animées dans la table uploads.
Nous estimons cela à environ 1 à 2 semaines de travail fastidieux. Nous confirmons simplement que vous souhaitez que nous nous en chargions, d’autant plus que tout fonctionne actuellement.
Bien sûr, moins de dépendances, c’est mieux, non ?
Probablement acceptable.
Vérifiez simplement la taille du fichier distant. Si elle est trop grande, ne le téléchargez pas. Sinon, je m’en fiche.
Oui, la taille du fichier sera probablement le principal problème bien avant que les dimensions hauteur et largeur ne deviennent pertinentes. (Dans le style chantant de La Zone Crépusculaire : « une autre dimension… la dimension du ttttttemps »). C’est aussi pourquoi c’est si étrange de traiter une image comme une vidéo. Ce sont des animaux très différents !
Oui, personne de sensé ne veut de ça.
Nous avons besoin de ce chemin de code car nous devrions finalement convertir automatiquement les GIFs en MP4 de toute façon. Cela nous rapproche de cet objectif, ce qui est un avantage net pour le monde.
J’ai supprimé la dépendance à gifsicle dans :