Target clones

Compilar el software de forma nativa en el ordenador solía mejorar los tiempos de ejecución en la CPU en torno a un 30 %, en comparación con los paquetes precompilados. La razón es que el compilador realiza optimizaciones específicas para el hardware de destino sobre el que se compila, mientras que los paquetes precompilados tienen que mantenerse genéricos y activar optimizaciones más conservadoras en aras de una amplia compatibilidad. Ten en cuenta que los kernels de OpenCL se compilan, de todos modos, para tu GPU concreta usando tu controlador de OpenCL, así que ahí la historia es distinta.

En 2016, GCC introdujo los target clones , seguido en 2023 por CLang, para los que añadí soporte en Darktable en 2019 solo en algunas partes (en particular, el ecualizador de tono). Este experimento nunca se había escalado a todo el software hasta ahora.

Los target clones permiten, esencialmente, construir distintas versiones del código, optimizadas para diferentes arquitecturas de hardware, y el software elegirá la correcta para ejecutar en tiempo de ejecución. Como esto se basa en ifunc, solo está soportado en Linux (e incluso ahí, no para todas las versiones de libc) y Mac OS Intel, así que no esperes soporte para Windows. La misma función en Windows tendría que programarse manualmente.

Con los target clones generalizados, los paquetes AppImage de Ansel ahora se ejecutan mucho más rápido, y dentro de un margen del 5 % en comparación con las compilaciones nativas (es decir, compilar tú mismo). Es una mano tendida hacia todos los usuarios menos familiarizados con la informática, que no pueden compilar el software por sí mismos y que suelen coincidir con el grupo que posee hardware modesto.

AppImage de Linux

Hace 2 meses se corrigió un molesto error que forzaba la recompilación de todos los kernels de OpenCL en cada arranque de la AppImage. La razón era que las AppImage se montan en un contenedor aleatorio (inestable entre reinicios), mientras que la comprobación de integridad realizada sobre los kernels (para recompilar solo cuando cambian) tenía codificada de forma fija la ruta del binario. Esa penalización exclusiva de las AppImage ya está resuelta.

Las AppImage se han modificado para aceptar argumentos de línea de comandos y exponer otros binarios además de la interfaz gráfica principal. Esto permite:

  1. obtener registros de depuración mediante ./Ansel-xxxx-x86_64.AppImage -d dev -d perf -d opencl -d verbose,
  2. procesar imágenes sin interfaz gráfica mediante ./Ansel-xxxx-x86_64.AppImage ansel-cli input.raw output.tif
  3. llamar a otros programas internos (consulta la documentación).

Debido a problemas de dependencias en Ubuntu, la AppImage tuvo que actualizarse a Ubuntu 24.04, lo que la hace ahora compatible con todos los sistemas Linux que soporten al menos libc 2.39. Puedes comprobar tu propia versión de libc ejecutando ldd --version en una terminal. Por lo tanto, la AppImage de Ansel es compatible con:

  1. Ubuntu 24.04,
  2. Debian 13,
  3. Linux Mint 22,
  4. Pop!_OS 24.04,
  5. Fedora 40,
  6. openSUSE Leap 16

Ten en cuenta que la AppImage de Ansel ya no incluye la biblioteca OpenMP, ya que entraba en conflicto de forma extraña con algunos ayudantes de depuración. Ahora usará la del sistema. Si no está instalada (lo que sería raro en Linux), forma parte del ecosistema de GCC (libgomp).

Imágenes de Docker

Las compilaciones nocturnas se han añadido también como imágenes de Docker . Estas permitirán ejecutar ansel-cli en servidores backend. No obstante, ten en cuenta que Ansel CLI no es seguro de ejecutar en servidores con acceso web público, ya que no impide la inyección de código ni sanea las entradas del usuario de ningún modo. Las imágenes de Docker se basan en Ubuntu 24.04.

Un posible caso de uso de las imágenes de Docker sería ejecutar granjas de renderizado para descargar las exportaciones de imágenes de Ansel a servidores con GPU grandes:

  • enviar el RAW y el XMP de edición al servidor,
  • obtener el JPG resultante.

En redes razonablemente rápidas, eso evitaría que los usuarios compren hardware caro si solo lo usan a pleno rendimiento en contadas ocasiones, a la vez que se reparte el coste de un servidor remoto 24/7 entre los usuarios.

MacOS

Las compilaciones nocturnas para MacOS se añadieron el pasado octubre para la arquitectura Apple M (Arm64). En septiembre de 2025, Github añadió runners para MacOS 15 Sonoma en arquitectura Intel. Esto permitió añadir hoy el soporte de Intel i386 para las compilaciones nocturnas de Ansel. Ambas arquitecturas se compilan en MacOS 15 Sonoma.

Ten en cuenta que la arquitectura Apple Intel  está prevista para ser descontinuada por Github en agosto de 2027, ya que Apple ha dejado de dar soporte a esta arquitectura. Después de eso, no habrá una forma sencilla de compilar Ansel para hardware Apple Intel.

Sobre las compilaciones nocturnas

Las compilaciones nocturnas se generan automáticamente en los runners de Github (piensa en ellos como servidores virtuales que puedes arrancar y detener desde scripts para ejecutar cosas), cada mañana entre las 5 y las 7 de la madrugada UTC. Los paquetes generados se añaden a las notas de preversión , que actúan como un repositorio, y proporcionan 1,5 años de historial de compilaciones para que tengas la posibilidad de volver a una versión que funcionaba anteriormente si algún cambio de código rompe de repente la aplicación de un modo que te impida usarla.

Las compilaciones nocturnas dependen enteramente:

  • de Github para proporcionar los runners,
  • de Homebrew  para proporcionar el ecosistema de dependencias de MacOS,
  • de MSYS Pacman  para proporcionar el ecosistema de dependencias de Windows,
  • de Ubuntu  para proporcionar el ecosistema de dependencias de Linux.

Son muchos terceros de los que depender, y las compilaciones nocturnas a menudo se rompen simplemente porque Github descontinuó un runner o porque alguno de MSYS/Ubuntu/Homebrew renombró un paquete, lo eliminó o lo actualizó a una versión más reciente que cambia la API y rompe con las tripas de Ansel. Así que, a pesar de la aparente automatización de todo el flujo de trabajo, sigue siendo necesario un mantenimiento regular y las compilaciones nocturnas podrían permanecer rotas durante algún tiempo.

Créditos

Me gustaría dar las gracias a:

Translated from English by : ChatGPT, Claude. In case of conflict, inconsistency or error, the English version shall prevail.