Gimp 2.8 a la vista, algunas reflexiones

Leo hoy a través de [1] que alrededor de finales de este año o principios del siguiente se liberará por fin la versión estable de Gimp 2.8, después 3 años de lento desarrollo. Y no solo eso, parece que ya hay un roadmap establecido para Gimp hasta la versión 3.8 [2]. Según GimpUsers [2] , el tiempo entre lanzamientos se reducirá a partir de la versión 2.10, algo que será de agradecer .

¿Qué novedades nos esperan? De la versión 2.8 no se puede decir mucho ya, no hay sorpresas, tendremos el modo de ventana unificada (lo que supondrá más comodidad para muchos, me incluyo) y agrupación de capas (algo realmente útil, palabra de honor).

La versión 2.10 será algo más interesante, aunque a priori pueda no parecerlo si sólo se mira el roadmap. En primer lugar, se realizará una limpieza de código, incluyendo cambios en la API de registro de plugins. Aunque esto no suponga una mejora inmediata para el usuario puede redundar en una aceleración posterior del desarrollo, ejecutables más pequeños y menor consumo de memoria. Además de la limpieza de código se incluirán todos los proyectos del GSoC sobre Gimp realizados hasta la fecha, que son los siguientes:

Clonación adaptativa [4] : Facilitará el pegado de trozos de imagen procedentes de otras fotografías o ilustraciones de forma que no parezca tan antinatural por exceso de contraste o diferencias entre colores e iluminación.
Nuevo widget GimpSizeEntry [5]: Proveerá un nuevo selector de unidades de medida de longitud, y de paso se refactorizará algo ciertas partes de código para hacerlas más extensibles.
Filtro iWarp como herramienta [6]: Hasta donde he entendido, creo que se trata de una herramienta que permitirá aplicar ciertos filtros localmente como si estuviéramos trabajando con un pincel. Ya existe algo parecido en Krita, así que puede que se hayan inspirado en ellos.
Port de los plugins de Gimp a GEGL [7] : Un paso necesario para que Gimp dé el salto definitivo a GEGL, lo que permitirá un mayor rendimiento y facilitará la creación de nuevas herramientas de transformación.
OpenCL en GEGL [8]: Gracias a este proyecto la aceleración mediante GPU llegará a Gimp .

En la versión 3.0 se dará el salto a las bibliotecas GTK3, de forma que en entornos de escritorio dominados por aplicaciones del proyecto Gnome se podrá reducir el consumo de memoria (al tener que mantener un conjunto menor de bibliotecas en memoria, hoy en día coexisten GTK2 y GTK3). Otra mejora no menos importante será la posibilidad de tratar con imágenes con más profundidad de color (hoy en día solo trabaja con 32 bits de profundidad, 8 para canal, rojo, verde, azul y transparencia). Este lanzamiento será el que permita el salto definitivo a GEGL.

La versión 3.2 nos traerá detección automática de los límites de capa (con el consecuente ahorro de memoria gracias a la posibilidad de ajustar el tamaño de los mapas de bits), efectos de capa (bordes, relieve y muchos otros), y filtros de capa (poder usar ciertas capas a modo de filtro sobre otras capas). A mi entender esta versión será una de las más importantes, porque si Photoshop no mejora mucho en lo que sigue, Gimp habrá llegado por fín a su nivel.

Ya no describo las siguientes versiones porque puede que cambien objetivos, y sobretodo porque con lo poco que sé, soy incapaz de valorar qué nos aportarán estas.

Ahora me permitiré opinar un poco sobre todo esto. Es de suponer que, después de 3 años de desarrollo, la gente se tome a cachondeo el plan establecido por el equipo de Gimp... yo esta vez confío en ellos. ¿Por qué? Pues porque han aprendido de sus errores, y tuvieron muchos.

Hay varias razones por las que Gimp se ralentizó tanto. Una de ellas, la principal, es que el equipo de desarrollo es verdaderamente pequeño. Ahora cabe analizar el por qué es pequeño, un motivo esencial es la falta de financiación, la gente hace pocas donaciones a ese proyecto (y es entendible), otro está relacionado con la dificultad de desarrollar ese tipo de software. Los programas de tratamiento de imagen son difíciles de desarrollar y no todo el mundo tiene la habilidad suficiente como para aportar su granito de arena.

Ahora bien, hay otra razón esencial que explica esa lentitud que ha desesperado a tantos, se trata de un error que ha costado el desencanto de mucha gente: El equipo de Gimp empezó a desarrollar nuevas características a porrillo, todas en la misma rama, pero pocas de ellas se terminaban. En parte es normal, los programadores prefieren desarrollar su código a tocar el de otros. El caso es que esos desarrollos a medias sirvieron para bloquear otros, y finalmente para retrasar el lanzamiento de Gimp 2.8.

Por suerte ellos mismos se dieron cuenta y no creo que vuelvan a trabajar de la misma manera nunca más, se han empezado a organizar para trabajar en ramas diferentes y no bloquearse mútuamente. Eso permitirá una aceleración del desarrollo, y eso a su vez atraerá más donaciones y desarrolladores.

Para acabar trataré otro asunto relacionado. Sinceramente, creo que ciertas distribuciones (y en especial Ubuntu) deberían haberse implicado más en el desarrollo de Gimp, porque se trata de una de esas piezas clave que pueden suponer que la gente se acerque o salga huyendo de un sistema Linux. Aunque Gimp no reporte beneficios directos a empresas como Canonical o Redhat, sí que podría permitir un crecimiento sustancial de la base de usuarios de Linux, a la vez que un aumento potencial de ganancias para esas empresas. ¿Se darán cuenta? Esperemos.

Viricmind Labs

Promociones

Entradas Recientes

Archivo

Mis tweets