Target clones

Het native compileren van de software op de computer verbeterde vroeger de looptijden op de CPU met ongeveer 30 %, vergeleken met voorgebouwde pakketten. De reden is dat de compiler specifieke optimalisaties maakt voor de doelhardware waarop hij wordt gecompileerd, terwijl voorgebouwde pakketten generiek moeten blijven en behoudender optimalisatie inzetten omwille van brede ondersteuning. Merk op dat OpenCL-kernels sowieso worden gecompileerd voor jouw specifieke GPU met behulp van jouw OpenCL-driver, dus daar ligt het verhaal anders.

In 2016 introduceerde GCC target clones , in 2023 gevolgd door CLang, waarvoor ik in 2019 in slechts enkele delen van Darktable ondersteuning toevoegde (met name de tone equalizer). Dit experiment was tot nu toe nooit opgeschaald naar de hele software.

Target clones maken het in wezen mogelijk om verschillende versies van de code te bouwen, geoptimaliseerd voor verschillende hardware-architecturen, en de software kiest tijdens runtime de juiste om uit te voeren. Aangezien dit steunt op ifunc, wordt het alleen ondersteund op Linux (en zelfs daar niet voor alle versies van libc) en Mac OS Intel, dus verwacht geen Windows-ondersteuning. Dezelfde functie op Windows zou handmatig gecodeerd moeten worden.

Met veralgemeende target clones draaien de Ansel AppImages-pakketten nu aanzienlijk sneller, en binnen een marge van 5 % vergeleken met native builds (oftewel zelf compileren). Dit is een uitgestoken hand naar alle minder computervaardige gebruikers, die de software niet zelf kunnen bouwen en meestal samenvallen met de groep die zwakke hardware bezit.

Linux AppImage

2 maanden geleden werd een vervelende bug opgelost die bij elke start van de AppImage de hercompilatie van alle OpenCL-kernels afdwong. De reden was dat AppImages worden aangekoppeld in een willekeurige container (instabiel bij herstarts), terwijl de integriteitscontrole die op kernels werd uitgevoerd (om alleen te hercompileren wanneer ze veranderden) het pad van het binaire bestand hardcodeerde. Die AppImage-specifieke straf is nu opgelost.

AppImages zijn aangepast om opdrachtregelargumenten te accepteren en andere binaire bestanden dan de hoofd-GUI beschikbaar te stellen. Dit maakt het mogelijk:

  1. om debuglogs te verkrijgen via ./Ansel-xxxx-x86_64.AppImage -d dev -d perf -d opencl -d verbose,
  2. om afbeeldingen te verwerken zonder GUI via ./Ansel-xxxx-x86_64.AppImage ansel-cli input.raw output.tif
  3. om andere interne programma’s aan te roepen (zie de docs).

Vanwege problemen met afhankelijkheden op Ubuntu moest de AppImage worden geüpgraded naar Ubuntu 24.04, waardoor hij nu compatibel is met alle Linux-systemen die minstens libc 2.39 ondersteunen. Je kunt je eigen libc-versie controleren door ldd --version uit te voeren in een terminal. De Ansel AppImage is daarom compatibel met :

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

Merk op dat de Ansel AppImage de OpenMP-bibliotheek niet meer meelevert, omdat die op een vreemde manier conflicteerde met enkele debug-helpers. Hij zal nu die van het systeem gebruiken. Als die niet is geïnstalleerd (wat zeldzaam zou zijn op Linux), maakt ze deel uit van het GCC-ecosysteem (libgomp).

Docker-images

Nightly builds zijn ook toegevoegd als Docker-images . Hiermee kun je ansel-cli op backendservers draaien. Merk echter op dat het niet veilig is om de Ansel CLI te draaien op servers met openbare webtoegang, aangezien deze code-injectie niet voorkomt en gebruikersinvoer op geen enkele manier saneert. Docker-images zijn gebaseerd op Ubuntu 24.04.

Een mogelijke use case van Docker-images zou zijn om renderfarms te draaien om het exporteren van Ansel-afbeeldingen over te hevelen naar servers met een grote GPU :

  • stuur de RAW en de bewerkings-XMP naar de server,
  • ontvang de resulterende JPG.

Op redelijk snelle netwerken zou dat voorkomen dat gebruikers dure hardware kopen die ze slechts zelden ten volle benutten, terwijl de kosten van een 24/7 externe server tussen gebruikers worden gedeeld.

MacOS

MacOS nightly builds zijn afgelopen oktober toegevoegd voor de Apple M (Arm64) architectuur. In september 2025 voegde Github runners toe voor MacOS 15 Sonoma op Intel-architectuur. Hierdoor kon vandaag ondersteuning voor Intel i386 worden toegevoegd aan de Ansel nightly builds. Beide architecturen worden gecompileerd op MacOS 15 Sonoma.

Merk op dat Apple Intel-architectuur  door Github gepland staat voor afschaffing in augustus 2027, aangezien Apple de ondersteuning van deze architectuur heeft stopgezet. Daarna zal er geen eenvoudige manier meer zijn om Ansel te bouwen voor Apple Intel-hardware.

Over nightly builds

Nightly builds worden automatisch gegenereerd op Github-runners (zie ze als virtuele servers die je vanuit scripts kunt starten en stoppen om dingen uit te voeren), elke ochtend tussen 5 en 7 uur UTC. De gegenereerde pakketten worden toegevoegd aan de pre-release notes , die als repository fungeren en 1,5 jaar aan buildgeschiedenis bieden, zodat je de kans krijgt terug te rollen naar een eerder werkende versie mocht een codewijziging de applicatie plots op een manier breken die je verhindert ze te gebruiken.

De nightly builds zijn volledig afhankelijk:

  • van Github voor het leveren van de runners,
  • van Homebrew  voor het leveren van het ecosysteem van MacOS-afhankelijkheden,
  • van MSYS Pacman  voor het leveren van het ecosysteem van Windows-afhankelijkheden,
  • van Ubuntu  voor het leveren van het ecosysteem van Linux-afhankelijkheden.

Dat zijn heel wat derde partijen om op te vertrouwen, en nightly builds breken vaak gewoon omdat Github een runner heeft afgeschaft of omdat een van MSYS/Ubuntu/Homebrew een pakket heeft hernoemd, verwijderd of geüpgraded naar een nieuwere versie die de API wijzigt en breekt met de interne werking van Ansel. Dus ondanks de schijnbare automatisering van de hele workflow is regelmatig onderhoud nog steeds nodig en kunnen nightly builds enige tijd gebroken blijven.

Met dank aan

Ik wil graag bedanken:

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