Saltar al contenido

GD o IMagick como alternativas al uso ImageMagick en Omeka

Una consulta de Pau Baig sobre la imposibilidad de utilizar ImageMagick, derivó en una conversación y en la solución a este problema que el mismo Pau encontró en la documentación de Omeka. Se trata de sustituir el uso de esta biblioteca, por otras opciones más «comunes» y extendidas, algo que sólo es posible en algunas de las últimas versiones de Omeka.

ImageMagick es una potente biblioteca utilizada por muchos sistemas de gestión de contenidos para la gestión automática de los derivados de las imágenes que cargamos en los repositorios de contenido de estos sistemas. Se trata, como decimos, de una potente aplicación, pero que puede ser difícil de instalar para usuarios noveles, y que no suele encontrarse disponible entre las aplicaciones instaladas en la mayoría de servicios de hosting -aunque en el sitio web de Omeka encontramos una interesante lista de servicios de hosting compatibles con esta tecnología-.

Desde hace algunas versiones, en Omeka existen un par de alternativas al uso de ImageMagick para la gestión de las imágenes en Omeka. En concreto, nos referimos a la extensión PECL ext/imagick -a partir de la versión 2.2 de Omeka-, y a la extensión de PHP, GD -a partir de la versión 2.3 de Omeka-.

En ambos casos, se trata de alternativas menos sofisticadas y potentes que ImageMagick, pero perfectamente funcionales y mucho más extendidas entre los proveedores de hosting -especialmente, GD-.

Para utilizar, por ejemplo, GD en lugar de ImageMagick, basta con descomentar la línea 259 del fichero «config.ini» de Omeka disponible en la ruta /application/config. En este tipo de ficheros, descomentar una línea consiste en eliminar el punto y coma inicial. Una vez descomentada, debemos modificar el valor que encontramos entre comillas «Omeka_File_Derivative_Strategy_ExternalImageMagic», por «Omeka_File_Derivative_Strategy_GD» -o por  «Omeka_File_Derivative_Strategy_Imagick», en el caso de optar por esta otra aproximación-.

Fichero config.ini original

Fichero config.ini después de canviar el valor para utilizar GD

Como se puede observar en la siguiente imagen, la opción tradicional para indicar la ruta de ImageMagick, configurable desde la sección Parámetros -o configuración, según la traducción-, desaparecerá, pues ya no es necesaria.

Opciones de configuración de Omeka

 


Comentarios

  1. Busqué una solucion por cielo mar y tierra a ese problema con Omeka. No se de que manera llegué hasta aquí, sin embargo agradezco mucho tu aporte. Me funcionó de maravilla. MUCHAS GRACIAS.

  2. Cuando exporto un sitio completo y lo importo para una BD existente, GD no interpreta los archivos ya procesados y es difícil por lo tedioso, pero volver a cargar cada ítem, es decir sobre todo en casos de bases de datos grandes.? Es posible solucionar ésto?

  3. He procedido a exportar mi BD y a su vez importarla para otro sitio pero esta vez manejado a través de XAMPP. Todo parece normal, pero las imagenes de los archivos no aparecen y parecería que es necesario subir de nuevo cada imagen.
    He trabajado sin problemas con GD Strategy.
    Para proceder a eventuales cambios, traté de usar el plugin Derivative Images pero no me permite seguir adelante.
    Deseo saber si pueden darme alguna orientación. Es para un registro de objetos de valor patrimonial trabajando con archivos digitalizados (fotos, planos, mapas, textos, etc.).
    El sitio que pongo como referencia está funcionando bien pero en un servidor externo y mi deseo es pasar todo para manejarlo mediante un servidor local (Localhost).

  4. Hola Rubén. En efecto, he hecho una «exportación» de toda la base de datos. Luego la he «importado» desde un nuevo espacio donde deseaba trabajar, que es un servidor local con XAMPP. A través de PHPMYADMIN he comprobado QUE SE HA IMPORTADO TODO. Allí están las referencias de todos los archivos.
    El asunto es que en el nuevo sitio (que es en un localhost) se carga la referencia de cada imagen desde donde yo la había traído, pero se muestra como un vínculo de imagen roto.
    Fíjate en un sitio donde tengo esto mismo trabajando (en http://sistemadocumental.sdprionegro.com/.
    Estoy trabajando con mucho esfuerzo e incertidumbre (en solitario) porque deseo dejar un sistema con omeka para que se pueda acceder a su repositorio en el futuro.
    Te agradezco mucho tu valioso comentario y asesoramiento.
    Desde Uruguay, saludos

    • ¿Pero el sistema continúa teniendo acceso al directorio /files? ¿Lo has movido también a la nueva ubicación? Es importante que, más allá de la base de datos donde se almacenan las rutas a los archivos, el sistema también puede acceder a ellos en el directorio de ficheros.
      Saludos.

  5. Aprovecho para preguntarte.
    Yo fui director del Museo de la Revolución Industrial con la historia de la agroalimentación en el Rio de la Plata durante los S. 191 y 20. Es mucho material que debo procesar.
    Es mejor dedicarse a OMEKA S y en tal caso se puede exportar del OMEKA CLASIC para aprovechar el material ?

    • Hola,
      Son dos aplicaciones diferentes y ambas se mantienen y mantendrán en paralelo. Con las dos puedes implementar un repositorio como el que describes. Normalmente, Omeka S resulta más interesante para instituciones que requieren un espacio compartido para diferentes proyectos. También está más orientado a la web semántica y los datos enlazados. Omeka Classic es más tradicional en ese sentido. Por lo que respecta a funcionalidades, ambos cuentan más o menos con las mismas, si bien, por ahora, existen bastantes más plugins para Omeka Classic que para Omeka S, simplemente, porque lleva más tiempo en el mercado.
      Saludos.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.