Hola a todos, me preguntaba por qué los GIFs son tan pequeños al subirlos, incluso si seleccionas el 100% del tamaño, por ejemplo:
¿Esto parece ser un error específicamente en lo que estás eligiendo subir? ¿Podrías describirlo exactamente, paso a paso, con ejemplos?
Aquí hay un gif que desencadena el problema. Cuando reviso sus propiedades en mi computadora, su tipo está establecido como ‘image/gif’. Su tamaño es de 10.4 MB. Parece que Discourse está redimensionando sus imágenes. Puedo subir gifs más pequeños que creé de la misma manera sin ningún problema de visualización.
Así que esto se refiere a GIFs que normalmente son demasiado grandes para cumplir con el límite de carga; ¿se están redimensionando automáticamente de alguna manera? La imagen resultante es minúscula: 50 x 29, 32 kb. Quizás esto sea una regresión, @sam? 
Posiblemente una regresión, ¿esto también ocurre con GIFs no animados?
Gracias, chicos. Estoy usando http://giffox.com/ para crear GIFs.
A veces funciona y a veces no… Creo que podrías tener razón con respecto al tamaño. Solo estaba haciendo algunas pruebas.
Puedo hacer que funcione si es muy corto.
Aquí hay un GIF de 2.06 MB
Aquí hay un GIF de 3.47 MB
Aquí hay un GIF de 9.06 MB
Sí, parece que algo muy grave está ocurriendo en el límite de 4 MB con estos @sam @eviltrout. He editado el título para reflejar el problema. Tenemos que arreglar esto, hemos retrocedido.
Solo quería confirmar que esto está aislado a los GIFs animados.
Creo que usamos Gifsicle: Command-Line Animated GIFs para redimensionar, así que mi suposición es que los parámetros cambiaron.
@vinothkannans, ¿podrías echar un vistazo rápido hoy?
Esto está ocurriendo desde que cambiamos la forma de reducir el tamaño de las imágenes. El commit anterior solucionará este problema y los GIFs más grandes se reducirán correctamente.
¿Es esta la corrección adecuada? No creo que debamos “reducir el tamaño” de lo que son efectivamente videos. Eso parece una manipulación bastante extrema (y posiblemente muy intensiva para la CPU del servidor) que podría arruinar la calidad del video (GIF).
No estoy seguro al respecto. Creo que deberíamos rechazar directamente los GIFs animados que son demasiado grandes en lugar de forzarnos a dedicarnos al redimensionamiento de videos (o incluso mejor, convertirlos a mp4); eso es un problema completamente diferente que abordar.
Sí, parece una solución directa. Voy a modificar la funcionalidad actual.
De todos modos, parece que hemos estado redimensionando las imágenes GIF durante los últimos 5 años usando “gifsicle” y no hemos recibido ningún problema de rendimiento con ello. @zogstrip podría conocer más detalles.
Creo que en este caso, rechazar GIFs muy específicos añadirá más código a nuestro repositorio.
En este momento, simplemente asumimos que todos los GIFs son “animados”, tal como se indica en:
Si vamos a cambiar esto para que algunos GIFs sean rechazados, tendremos que implementar detección de formato para GIFs animados y luego ejecutar un código especial de rechazo. Esto es especialmente complicado para las imágenes que debemos optimizar (debido a las dimensiones), ya que ya no podremos optimizar GIFs animados.
Por un lado, nos permitirá eliminar la dependencia de gifsicle. Por otro lado, nuestro pipeline de carga se vuelve más complejo.
Personalmente, creo que la solución de @vinothkannans está bien y tiene bajo riesgo; es código que hemos tenido durante 5 años y, hasta donde sé, no hay problemas graves de rendimiento.
Dicho esto, @codinghorror, no me metería en esto si quieres eliminar el soporte para el redimensionamiento de GIFs animados, pero es un cambio bastante complejo. La identificación es lo suficientemente sencilla, pero generar el rechazo con un mensaje de error podría ser un poco complicado.
Tu GIF animado es mayor de 10 MB, por lo que no se puede subir.
Tu GIF animado es mayor de 600x400, por lo que no se puede subir.
En cualquier caso, la decisión es tuya. Mi recomendación es dejar la solución tal como está y seguir adelante, pero si quieres eliminar el soporte, avísanos.
Nota: esta eliminación también requerirá que eliminemos el soporte para avatares animados (una función opcional; para ser honesto, no estoy muy contento de tener que hacerlo).
Hmm, entonces, siempre que el GIF animado quepa en el límite total de tamaño de carga (¿?), efectivamente su calidad de “video” se reduce para igualar… ¿qué?
No tengo ni idea de lo que está ocurriendo realmente aquí.
Obviamente, cambiar el tamaño de la altura y el ancho es totalmente inadecuado para un GIF… ¿eso fue lo que provocó el error original mencionado arriba?
La historia era que estábamos ‘destruyendo’ los GIFs animados al optimizarlos, por lo que si subías imágenes que iban a ser mostradas en lightbox, las estropeábamos.
En la parte interna de nuestro código no había lógica de ‘detección’ para determinar si un GIF era animado o no. El lightbox se activa después de que la publicación se guarda en la base de datos.
La solución fue hacer que nuestro código de ‘redimensionado’ no estropeara los GIFs animados y funcionara correctamente con ellos.
El problema es que necesitamos rehacer partes de nuestra cadena de subida para dar un ‘tratamiento especial’ a los GIFs animados si vamos a eliminar el soporte.
- Se sube un GIF
- ¿Es un GIF animado?
- ¿El preprocesador necesitará redimensionarlo?
- Rechazar el GIF animado
- ¿El postprocesador necesitará optimizarlo?
- Rechazar el GIF animado
- ¿El preprocesador necesitará redimensionarlo?
- ¿No es un GIF animado?
- Permitirlo con la cadena normal
- ¿Es un GIF animado?
También hay algunos efectos secundarios a considerar con la regeneración a largo plazo del Markdown si los parámetros cambian en algún momento y con la extracción de imágenes con enlaces externos.
La solución de simplemente corregir el redimensionado significó que no tuvimos que preocuparnos por todo esto.
No creo que debamos realizar ninguna “optimización” en los GIFs animados, así que pienso que el código debe detectar esto. Agregar esa ruta abriría la puerta a una futura conversión de GIF a video MP4, algo que de todos modos queremos lograr… eventualmente. Por lo tanto, considero que este es un trabajo necesario.
Solo para aclarar.
Quisieran que nosotros:
- Elimináramos
gifsiclede nuestra imagen de Docker. - Al volver a generar publicaciones antiguas que contenían GIFs animados redimensionados, estos aparezcan con el glifo de imagen rota en la publicación.
- Corrijamos nuestra tarea de descarga de imágenes enlazadas externamente para evitar descargar GIFs animados que requieran redimensionamiento, mostrando en su lugar un enlace.
- Rechacemos los GIFs animados que sean demasiado grandes (en dimensiones o tamaño) y que sean animados.
- Eliminemos el soporte para avatares animados en Discourse.
- Mantengamos un registro de si las cargas son animadas o no en la tabla de uploads.
Estamos estimando unas 1-2 semanas de trabajo detallado aquí, solo queremos confirmar que desean que lo llevemos a cabo, especialmente porque actualmente todo está funcionando correctamente.
Claro, menos dependencias es mejor, ¿no?
Probablemente esté bien.
Simplemente verifica el tamaño del archivo remoto. Si es demasiado grande, no lo descargues. No me importa lo demás.
Sí, principalmente el tamaño del archivo será el problema, mucho antes de que las dimensiones de altura y ancho importen realmente. (En esa extraña canción de “La dimensión desconocida”: “otra dimensión… la dimensión del tiempppoo”) Esto también es por lo que es tan increíblemente extraño tratar una imagen como un video. ¡Son animales bastante diferentes!
Sí, nadie cuerdo quiere esto.
Necesitamos esta ruta de código porque deberíamos eventualmente convertir automáticamente los GIFs a MP4 de todos modos. Esto nos lleva parcialmente en esa dirección y eso es un beneficio neto para el mundo.
He eliminado la dependencia de gifsicle en: