Target clones

Compiler le logiciel nativement sur l’ordinateur permettait d’améliorer les temps d’exécution sur CPU d’environ 30 %, par rapport aux paquets pré-compilés. La raison en est que le compilateur effectue des optimisations spécifiques pour le matériel cible sur lequel il compile, tandis que les paquets pré-compilés doivent rester génériques et déclenchent des optimisations plus conservatrices dans un souci de large compatibilité. Notez que les noyaux OpenCL sont, de toute façon, compilés pour votre GPU particulier à l’aide de votre pilote OpenCL, l’histoire est donc différente de ce côté-là.

En 2016, GCC a introduit les target clones , suivi en 2023 par CLang, pour lequel j’avais ajouté la prise en charge dans Darktable en 2019 dans certaines parties seulement (notamment l’égaliseur de tons). Cette expérimentation n’avait jamais été étendue à l’ensemble du logiciel jusqu’à présent.

Les target clones permettent essentiellement de construire différentes versions du code, optimisées pour différentes architectures matérielles, et le logiciel choisira la bonne à exécuter au moment de l’exécution. Comme cela repose sur ifunc, cela n’est pris en charge que sous Linux (et même là, pas pour toutes les versions de libc) et Mac OS Intel, il ne faut donc pas s’attendre à une prise en charge sous Windows. La même fonctionnalité sous Windows devrait être codée manuellement.

Avec des target clones généralisés, les paquets AppImage d’Ansel s’exécutent désormais nettement plus vite, et dans une marge de 5 % par rapport aux compilations natives (autrement dit compiler soi-même). C’est une main tendue vers tous les utilisateurs les moins à l’aise avec l’informatique, qui ne peuvent pas compiler le logiciel eux-mêmes et qui recoupent généralement la population possédant du matériel peu puissant.

AppImage Linux

Il y a 2 mois, un bug agaçant qui forçait la recompilation de tous les noyaux OpenCL à chaque démarrage de l’AppImage a été corrigé. La raison en était que les AppImage sont montées dans un conteneur aléatoire (instable au fil des redémarrages), tandis que le contrôle d’intégrité effectué sur les noyaux (afin de ne recompiler que lorsqu’ils ont changé) codait en dur le chemin du binaire. Cette pénalité propre aux AppImage est désormais résolue.

Les AppImage ont été modifiées pour accepter des arguments en ligne de commande et exposer d’autres binaires que l’interface graphique principale. Cela permet :

  1. d’obtenir des journaux de débogage via ./Ansel-xxxx-x86_64.AppImage -d dev -d perf -d opencl -d verbose,
  2. de traiter des images sans interface graphique via ./Ansel-xxxx-x86_64.AppImage ansel-cli input.raw output.tif
  3. d’appeler d’autres programmes internes (voir la documentation).

En raison de problèmes de dépendances sous Ubuntu, l’AppImage a dû être mise à niveau vers Ubuntu 24.04, ce qui la rend désormais compatible avec tous les systèmes Linux prenant en charge au moins libc 2.39. Vous pouvez vérifier votre propre version de libc en exécutant ldd --version dans un terminal. L’AppImage d’Ansel est donc compatible avec :

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

Notez que l’AppImage d’Ansel n’embarque plus la bibliothèque OpenMP, car elle entrait en conflit avec certains utilitaires de débogage d’une manière étrange. Elle utilisera désormais celle du système. Si elle n’est pas installée (ce qui serait rare sous Linux), elle fait partie de l’écosystème GCC (libgomp).

Images Docker

Les nightly builds ont également été ajoutées sous forme d’images Docker . Celles-ci permettront d’exécuter ansel-cli sur des serveurs backend. Notez cependant qu’Ansel CLI n’est pas sûr à exécuter sur des serveurs avec accès web public, car il n’empêche pas l’injection de code et n’assainit en aucune façon les entrées de l’utilisateur. Les images Docker sont basées sur Ubuntu 24.04.

Un cas d’usage possible des images Docker serait de faire tourner des fermes de rendu pour décharger les exports d’images Ansel vers des serveurs dotés de gros GPU :

  • envoyer le RAW et le XMP d’édition au serveur,
  • récupérer le JPG résultant.

Sur des réseaux raisonnablement rapides, cela éviterait aux utilisateurs d’acheter du matériel coûteux s’ils ne l’utilisent que rarement à son plein potentiel, tout en partageant le coût d’un serveur distant 24 h/24 et 7 j/7 entre les utilisateurs.

MacOS

Des nightly builds MacOS ont été ajoutées en octobre dernier pour l’architecture Apple M (Arm64). En septembre 2025, Github a ajouté des runners pour MacOS 15 Sonoma sur architecture Intel. Cela a permis d’ajouter aujourd’hui la prise en charge d’Intel i386 pour les nightly builds d’Ansel. Les deux architectures sont compilées sur MacOS 15 Sonoma.

Notez que l’architecture Apple Intel  est prévue pour dépréciation par Github en août 2027, Apple ayant abandonné la prise en charge de cette architecture. Après cela, il n’y aura plus de moyen simple de compiler Ansel pour le matériel Apple Intel.

À propos des nightly builds

Les nightly builds sont générées automatiquement sur les runners Github (voyez-les comme des serveurs virtuels que vous pouvez démarrer et arrêter depuis des scripts pour exécuter des tâches), chaque matin entre 5 et 7 h UTC. Les paquets générés sont ajoutés aux notes de pré-version , qui font office de dépôt, et fournissent 1.5 an d’historiques de compilation afin que vous ayez une chance de revenir à une version précédemment fonctionnelle si des changements de code cassent soudainement l’application d’une manière qui vous empêche de l’utiliser.

Les nightly builds dépendent entièrement :

  • de Github pour fournir les runners,
  • de Homebrew  pour fournir l’écosystème de dépendances MacOS,
  • de MSYS Pacman  pour fournir l’écosystème de dépendances Windows,
  • d’Ubuntu  pour fournir l’écosystème de dépendances Linux.

Cela fait beaucoup de tiers sur lesquels compter, et les nightly builds cassent souvent simplement parce que Github a déprécié un runner ou que l’un de MSYS/Ubuntu/Homebrew a renommé un paquet, l’a supprimé ou l’a mis à niveau vers une version plus récente qui change l’API et casse avec les rouages internes d’Ansel. Ainsi, malgré l’automatisation apparente de tout le flux de travail, une maintenance régulière reste nécessaire et les nightly builds peuvent rester cassées pendant un certain temps.

Crédits

Je tiens à remercier :

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