Target clones

Compilare il software nativamente sul computer permetteva di migliorare i tempi di esecuzione su CPU di circa il 30 %, rispetto ai pacchetti precompilati. Il motivo è che il compilatore effettua ottimizzazioni specifiche per l’hardware di destinazione su cui viene compilato, mentre i pacchetti precompilati devono restare generici e attivare ottimizzazioni più conservative per garantire un ampio supporto. Nota che i kernel OpenCL vengono comunque compilati per la tua GPU specifica tramite il tuo driver OpenCL, quindi lì la storia è diversa.

Nel 2016 GCC ha introdotto i target clones , seguito nel 2023 da CLang, per i quali nel 2019 ho aggiunto il supporto in Darktable solo in alcune parti (in particolare, l’equalizzatore di tono). Questo esperimento non era mai stato esteso all’intero software fino a ora.

I target clones permettono essenzialmente di compilare diverse versioni del codice, ottimizzate per diverse architetture hardware, e il software sceglierà quella giusta da eseguire in fase di esecuzione. Poiché ciò si basa su ifunc, è supportato solo su Linux (e anche lì, non per tutte le versioni di libc) e su Mac OS Intel, quindi non aspettarti alcun supporto per Windows. La stessa funzione su Windows dovrebbe essere programmata manualmente.

Con i target clones generalizzati, i pacchetti AppImage di Ansel ora sono notevolmente più veloci, con un margine entro il 5 % rispetto alle build native (ovvero compilate da te). Questa è una mano tesa verso tutti gli utenti meno esperti di informatica, che non sanno compilare il software da soli e di solito coincidono con la fascia che possiede hardware poco potente.

Linux AppImage

2 mesi fa è stato corretto un fastidioso bug che forzava la ricompilazione di tutti i kernel OpenCL a ogni avvio dell’AppImage. Il motivo era che le AppImage vengono montate in un container casuale (instabile tra un riavvio e l’altro), mentre il controllo di integrità effettuato sui kernel (per ricompilare solo quando cambiano) aveva il percorso del binario codificato in modo rigido. Quella penalità specifica delle AppImage è ora risolta.

Le AppImage sono state modificate per accettare argomenti da riga di comando ed esporre altri binari oltre alla GUI principale. Questo permette:

  1. di ottenere log di debug tramite ./Ansel-xxxx-x86_64.AppImage -d dev -d perf -d opencl -d verbose,
  2. di elaborare immagini senza GUI tramite ./Ansel-xxxx-x86_64.AppImage ansel-cli input.raw output.tif
  3. di richiamare altri programmi interni (vedi la documentazione).

A causa di problemi di dipendenze su Ubuntu, l’AppImage ha dovuto essere aggiornata a Ubuntu 24.04, il che la rende ora compatibile con tutti i sistemi Linux che supportano almeno libc 2.39. Puoi verificare la tua versione di libc eseguendo ldd --version in un terminale. L’AppImage di Ansel è quindi compatibile con :

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

Nota che l’AppImage di Ansel non include più la libreria OpenMP, poiché entrava in conflitto in modo strano con alcuni helper di debug. Ora userà quella di sistema. Se non è installata (cosa che sarebbe rara su Linux), fa parte dell’ecosistema di GCC (libgomp).

Immagini Docker

Le nightly build sono state aggiunte anche come immagini Docker . Queste permetteranno di eseguire ansel-cli su server backend. Nota però che Ansel CLI non è sicuro da eseguire su server con accesso web pubblico, poiché non impedisce l’iniezione di codice e non sanifica in alcun modo gli input dell’utente. Le immagini Docker sono basate su Ubuntu 24.04.

Un possibile caso d’uso delle immagini Docker sarebbe far girare rendering farm per delegare le esportazioni di immagini di Ansel a server con GPU potenti :

  • inviare il RAW e l’XMP di editing al server,
  • ottenere il JPG risultante.

Su reti ragionevolmente veloci, ciò eviterebbe agli utenti di acquistare hardware costoso se lo usano solo raramente al massimo del suo potenziale, condividendo al contempo il costo di un server remoto attivo 24 ore su 24 tra più utenti.

MacOS

Le nightly build per MacOS sono state aggiunte lo scorso ottobre per l’architettura Apple M (Arm64). A settembre 2025, Github ha aggiunto runner per MacOS 15 Sonoma su architettura Intel. Questo ha permesso di aggiungere oggi il supporto Intel i386 per le nightly build di Ansel. Entrambe le architetture vengono compilate su MacOS 15 Sonoma.

Nota che l’architettura Apple Intel  è destinata alla deprecazione da parte di Github ad agosto 2027, poiché Apple ha interrotto il supporto di questa architettura. Dopodiché non ci sarà un modo semplice per compilare Ansel per hardware Apple Intel.

Sulle nightly build

Le nightly build vengono generate automaticamente sui runner di Github (pensali come server virtuali che puoi avviare e fermare da script per eseguire operazioni), ogni mattina tra le 5 e le 7 UTC. I pacchetti generati vengono aggiunti alle note di pre-release , che funge da repository e fornisce 1,5 anni di cronologia delle build, così hai la possibilità di tornare a una versione precedentemente funzionante se delle modifiche al codice dovessero improvvisamente rompere l’applicazione in un modo che ti impedisce di usarla.

Le nightly build dipendono interamente:

  • da Github per la fornitura dei runner,
  • da Homebrew  per la fornitura dell’ecosistema di dipendenze MacOS,
  • da MSYS Pacman  per la fornitura dell’ecosistema di dipendenze Windows,
  • da Ubuntu  per la fornitura dell’ecosistema di dipendenze Linux.

Sono molte terze parti su cui fare affidamento, e le nightly build si rompono spesso solo perché Github ha deprecato un runner o perché uno tra MSYS/Ubuntu/Homebrew ha rinominato un pacchetto, lo ha rimosso o lo ha aggiornato a una versione più recente che cambia le API e va in conflitto con le parti interne di Ansel. Quindi, nonostante l’apparente automazione dell’intero flusso di lavoro, è comunque necessaria una manutenzione regolare e le nightly build potrebbero restare rotte per un po’ di tempo.

Ringraziamenti

Vorrei ringraziare:

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