ruby-on-rails - rails - paperclip::errors::notidentifiedbyimagemagickerror

Carrierwave o Libélula

Question

He estado buscando herramientas de carga de archivos en rieles y las que me parecieron más atractivas e interesantes fueron carrierwave y libélula.

Al mirar a su alrededor, parece que carrierwave adopta el estilo más tradicional en el que puede procesar el archivo al guardar, mientras que la libélula es un middleware, por lo que le permite procesarlo sobre la marcha.

Me preguntaba si las personas tenían alguna referencia a la prueba de rendimiento o cualquier prueba que los comparara.

Además, solo tiene curiosidad por conocer las opiniones de las personas sobre ambos y cuáles prefieren y, por supuesto, por qué lo prefieren.

Answer 1

Clip de papel

Paperclip está pensado como una biblioteca de archivos adjuntos fácil para Active Record. La intención detrás de esto era mantener la configuración lo más fácil posible y tratar los archivos tanto como otros atributos como fuera posible. Esto significa que no se guardan en sus ubicaciones finales en el disco, ni se eliminan si se establece en cero, hasta que se llame a ActiveRecord::Base#save . Gestiona las validaciones según el tamaño y la presencia, si es necesario. Puede transformar su imagen asignada en miniaturas si es necesario, y los requisitos previos son tan simples como instalar ImageMagick (que, para la mayoría de los sistemas modernos basados ​​en Unix, es tan fácil como instalar los paquetes correctos). Los archivos adjuntos se guardan en el sistema de archivos y se mencionan en el navegador mediante una especificación fácilmente comprensible, que tiene valores predeterminados razonables y útiles.

Ventajas

1. validaciones, Paperclip presenta varios validadores para validar su archivo adjunto: AttachmentContentTypeValidator AttachmentPresenceValidator AttachmentSizeValidator
2. Eliminar un Adjunto Establezca el atributo en cero y guarde. @user.avatar = nil @user.save
3. Paperclip es mejor para un entorno orgánico de Rails que utiliza activerecord y no todas las otras alternativas. Paperclip es mucho más fácil de manejar para los desarrolladores principiantes de rieles y también tiene capacidades avanzadas para el desarrollador avanzado.
4. Gran admirador de Paperclip porque no requiere RMagick, es muy fácil configurarlo para que se publique en Amazon S3 y declarar que todo en los modelos (validaciones, etc.) lo mantiene limpio.
5. Con respecto a la carga de múltiples archivos y la retroalimentación del progreso, ambos son posibles tanto con Paperclip como con Attachment_fu, pero ambos suelen requerir un poco de esfuerzo con iframes y Apache para funcionar.

Onda portadora

Esta gema proporciona una forma simple y extremadamente flexible de cargar archivos desde aplicaciones de Ruby. Funciona bien con aplicaciones web basadas en Rack, como Ruby on Rails.

Ventajas

1. Integración simple de la entidad modelo. Agregar un atributo de image cadena única para hacer referencia a la imagen cargada.
2. Métodos de modelo "mágico" para cargar y obtener imágenes de forma remota.
3. Integración de carga de archivos HTML utilizando una etiqueta de archivo estándar y otra etiqueta oculta para mantener la versión ya cargada "en caché".
4. Interfaz directa para crear versiones de imágenes derivadas con diferentes dimensiones y formatos. Las herramientas de procesamiento de imágenes están muy bien escondidas detrás de las escenas.
5. Modelar métodos para obtener las URL públicas de las imágenes y sus versiones redimensionadas para la incorporación de HTML.
6. si el caché de rieles incorporados, Carrierwave funcionará mejor, ya que los archivos se pueden cargar sin ningún procesamiento. Si no haces ningún procesamiento, no importa.
7. Genera pulgares en la carga (ahorra tiempo de CPU)
8. Puede usar archivos directamente desde un documento estático / en caché
9. No necesita ningún frente de caché
10. Admite varios backends de almacenamiento (S3, Cloudfiles, GridFS, archivos normales) fáciles de extender a nuevos tipos de almacenamiento si es necesario. Uno de los hechos es que no confunde sus modelos con la configuración. Puede definir clases de cargador en su lugar. Le permite reutilizar fácilmente, extender, etc. su configuración de carga. Lo que más nos gustó es el hecho de que CarrierWave es muy modular. Puede cambiar fácilmente su motor de almacenamiento entre un sistema de archivos local, AWS S3 basado en la nube y más. Puede cambiar el módulo de procesamiento de imágenes entre RMagick, MiniMagick y otras herramientas. También puede usar el sistema de archivos local en su entorno de desarrollo y cambiar al almacenamiento S3 en el sistema de producción. Carrierwave tiene un buen soporte para elementos externos como DataMapper, Mongoid, Sequel e incluso se puede usar con una administración de imágenes de terceros como cloudinary. La solución parece más completa con cobertura de soporte para cualquier cosa, pero la solución también es mucho más desordenada (para mí al menos) ya que hay mucho más código que debe manejar. Necesita apreciar el enfoque modular que adopta CarrierWave. Es indiferente en cuanto a cuál de los clientes populares de S3 que utiliza, admite tanto aws / s3 como right_aws. También es ORM agnóstico y no está estrechamente vinculado a Active Record. El estrecho acoplamiento de Paperclip nos causó algo de dolor en el trabajo.

Desventajas

1. No puedes validar el tamaño del archivo. Hay un artículo de wiki que explica cómo hacerlo, pero no funciona.
2. Las validaciones de integridad no funcionan cuando se utiliza MiniMagick (muy conveniente si le preocupa el uso de RAM). Puede cargar un archivo de imagen dañado y CarrierWave arrojará un error al principio, pero la próxima vez se lo tragará.
3. No puedes borrar el archivo original. En cambio, puedes redimensionarlo, comprimirlo, etc. Hay un artículo wiki que explica cómo hacerlo, pero nuevamente no funciona.
4. Depende de bibliotecas externas como RMagick o MiniMagick. Paperclip trabaja directamente con la línea de comandos de conversión (ImageMagick). Entonces, si tiene problemas con Minimagick (tuve), perderá horas buceando en las búsquedas de Google. Tanto RMagick como Minimagick están abandonados en el momento de escribir esto (me puse en contacto con el autor de Minimagic, sin respuesta).
5. Necesita algunos archivos de configuración. Esto se ve como una ventaja, pero no me gusta tener archivos de configuración únicos alrededor de mi proyecto solo para una joya. La configuración en el modelo me parece más natural. Esto es una cuestión de gusto personal de todos modos.
6. Si encuentra algún error y lo informa, el equipo de desarrollo está realmente ausente y ocupado. Te dirán que arregles los errores tú mismo. Parece un proyecto personal que se mejora en el tiempo libre. Para mí no es válido para un proyecto profesional con fechas límite.
7. No es compatible nativamente con mongomapper
8. Utiliza el espacio de almacenamiento para cada archivo / pulgar generado. Si usa el almacenamiento de archivos normal, ¡puede quedarse sin inodos!

Libélula

1. Lo impresionante de Dragonfly, lo que lo separa de la mayoría de los demás complementos de procesamiento de imágenes, es que permite cambiar el tamaño sobre la marcha de la vista.
2. No necesitar configurar el tamaño de las miniaturas u otras acciones en un archivo separado es una gran pérdida de tiempo y de frustración. Hace que Rails vea código como image_tag @product.image.thumb(''150x150#'') posible.
3. La magia es todo posible gracias al almacenamiento en caché. En lugar de crear la versión procesada al cargarla y luego vincularla a versiones individuales de la imagen, el complemento genera imágenes a medida que se solicitan. Si bien esto es un problema para la primera carga, la imagen recién creada se almacena en caché HTTP para todas las cargas subsiguientes, de forma predeterminada utilizando Rack :: Cache, aunque existen otras soluciones más robustas si el escalado se convierte en un problema.

Ventajas

1. ¿Cambiaré el tamaño de la imagen a menudo? Ejemplo: si desea permitir que sus usuarios cambien el tamaño de sus imágenes (o su necesidad de flexibilidad de tamaño por alguna otra razón), o un desarrollo realmente rápido. Sí: Libélula No: Carrierwave o Paperclip
2. Se puede usar con mongomapper sin problemas
3. El rendimiento debería estar bien siempre que uses un proxy de almacenamiento en caché
4. Debería funcionar con mongomapper (solo extiende ActiveModel)
5. Genera pulgares sobre la marcha (es más fácil crear nuevos diseños / tamaños de pulgares)
6. ¡Solo un archivo almacenado! Ahorra espacio
7. Procesamiento hecho sobre la marcha (está destinado a ser utilizado detrás de un proxy de caché como Varnish, Squid o Rack :: Cache, de modo que, si bien la primera solicitud puede tomar algún tiempo, las solicitudes posteriores deben ser súper rápidas)

Desventajas

1. Come CPU en cada solicitud si no tiene un proxy de caché, rack::cache o similar.
2. No hay forma de acceder a los pulgares como archivos si es necesario.

Referencias

• Ruby on Rails Carga de imágenes con CarrierWave y Cloudinary
• Rails 3 paperclip vs carrierwave vs libélula vs attachment_fu

Answer 2

Dependiendo de la configuración. Como escribe Senthil, siempre que tengas un proxy de caché al frente, está bien con Dragonfly.

Pero si está utilizando el almacenamiento en caché integrado de los rieles, Carrierwave tendrá un mejor rendimiento, ya que los archivos se pueden cargar sin ningún procesamiento. Si no haces ningún procesamiento, no importa.

Así es como resumí al considerar ambas imágenes en un proyecto con Mongomapper:

Onda portadora:

• Pros
  • Genera pulgares en la carga (ahorra tiempo de CPU)
  • Puede usar archivos directamente desde un documento estático / en caché
  • No necesita ningún frente de caché
  • Admite varios backends de almacenamiento (S3, Cloudfiles, GridFS, archivos normales) fáciles de extender a nuevos tipos de almacenamiento si es necesario.
• Contras
  • Genera pulgares en la carga (diffucult para generar nuevos tamaños de pulgar)
  • No es compatible nativamente con mongomapper
  • Utiliza el espacio de almacenamiento para cada archivo / pulgar generado. Si usa el almacenamiento de archivos normal, ¡puede quedarse sin inodos!

Libélula:

• Pros
  • Debería funcionar con mongomapper, ya que solo extiende ActiveModel
  • Genera pulgares sobre la marcha (es más fácil crear nuevos diseños / tamaños de pulgares)
  • ¡Solo un archivo almacenado! Ahorra espacio :)
• Contras
  • Come CPU en cada solicitud si no tiene un proxy de caché, rack :: cache o similar.
  • No hay forma de acceder a los pulgares como archivos si es necesario.

Terminé usando ambos al final.

Un deseo futuro es que carrierwave vuelva a apoyar a MongoMapper. Después de usar ambos en varias situaciones, he descubierto que las funciones en MongoMapper (rails3 branch) siempre funcionan, y son fáciles de extender usando complementos. No puedo decir lo mismo de Mongoid a partir de ahora, pero eso podría cambiar.

Answer 3

Otras personas escribieron muy buenos resúmenes, solo me gustaría decir que, según nuestra experiencia, la configuración de Dragonfly necesitaba más mantenimiento, y debido a la negligencia de algunos desarrolladores a lo largo del camino, también nos quedamos con muchas imágenes huérfanas que persistían después del original. fue removido. Esto no hubiera sucedido con una onda de operador de vainilla. PS: migramos a cloudinary (y usamos carrierwave con él) y estamos contentos con él.

Answer 4

Uso libélula simplemente porque carrierwave dejó de admitir mongomapper y paperclip no funciona mongomapper sin algunos hacks.

Dragonfly hace el procesamiento sobre la marcha, es decir

está destinado a ser utilizado detrás de un proxy de caché, como Varnish, Squid o Rack :: Cache, de modo que, si bien la primera solicitud puede llevar cierto tiempo, las solicitudes posteriores deben ser súper rápidas.