Target Clones

Das native Kompilieren der Software auf dem Rechner verbesserte die Laufzeiten auf der CPU früher um etwa 30 % gegenüber vorgefertigten Paketen. Der Grund ist, dass der Compiler spezifische Optimierungen für die Zielhardware vornimmt, auf der er kompiliert wird, während vorgefertigte Pakete generisch bleiben und um der breiten Unterstützung willen konservativere Optimierungen auslösen müssen. Beachten Sie, dass OpenCL-Kernel ohnehin für Ihre bestimmte GPU über Ihren OpenCL-Treiber kompiliert werden, sodass die Sache dort anders liegt.

2016 führte GCC Target Clones  ein, gefolgt 2023 von CLang, für die ich 2019 in Darktable nur in einigen Teilen Unterstützung hinzugefügt habe (bemerkenswerterweise dem tone equalizer). Dieses Experiment war bis jetzt nie auf die gesamte Software skaliert worden.

Target Clones erlauben im Wesentlichen, verschiedene Versionen des Codes zu bauen, die für verschiedene Hardware-Architekturen optimiert sind, und die Software wählt zur Laufzeit die richtige zum Ausführen aus. Da dies auf ifunc beruht, wird es nur unter Linux (und selbst dort nicht für alle Versionen von libc) und Mac OS Intel unterstützt, erwarten Sie also keine Windows-Unterstützung. Dieselbe Funktion unter Windows müsste manuell programmiert werden.

Mit verallgemeinerten Target Clones laufen die AppImage-Pakete von Ansel jetzt deutlich schneller und innerhalb einer Marge von 5 % gegenüber nativen Builds (also dem Selbstkompilieren). Dies ist eine ausgestreckte Hand hin zu all den weniger computeraffinen Nutzern, die die Software nicht selbst bauen können und sich meist mit der Gruppe überschneiden, die schwache Hardware besitzt.

Linux-AppImage

Vor 2 Monaten wurde ein ärgerlicher Fehler behoben, der die Neukompilierung aller OpenCL-Kernel bei jedem AppImage-Start erzwang. Der Grund war, dass AppImages in einem zufälligen Container gemountet werden (über Neustarts hinweg instabil), während die Integritätsprüfung, die an den Kernels vorgenommen wird (um nur bei deren Änderung neu zu kompilieren), den Pfad der Binärdatei fest codierte. Diese AppImage-spezifische Einbuße ist jetzt behoben.

AppImages wurden so modifiziert, dass sie Befehlszeilenargumente akzeptieren und andere Binärdateien als die Haupt-GUI zugänglich machen. Dies ermöglicht:

  1. Debug-Logs zu erhalten über ./Ansel-xxxx-x86_64.AppImage -d dev -d perf -d opencl -d verbose,
  2. Bilder ohne GUI zu verarbeiten über ./Ansel-xxxx-x86_64.AppImage ansel-cli input.raw output.tif
  3. andere interne Programme aufzurufen (siehe die Dokumentation).

Aufgrund von Abhängigkeitsproblemen unter Ubuntu musste das AppImage auf Ubuntu 24.04 aktualisiert werden, wodurch es nun mit allen Linux-Systemen kompatibel ist, die mindestens libc 2.39 unterstützen. Sie können Ihre eigene libc-Version überprüfen, indem Sie ldd --version in einem Terminal ausführen. Das Ansel-AppImage ist daher kompatibel mit:

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

Beachten Sie, dass das Ansel-AppImage die OpenMP-Bibliothek nicht mehr bündelt, da sie auf seltsame Weise mit einigen Debug-Helfern in Konflikt geriet. Es wird nun die des Systems verwenden. Falls nicht installiert (was unter Linux selten wäre), ist sie Teil des GCC-Ökosystems (libgomp).

Docker-Images

Nightly Builds wurden auch als Docker-Images  hinzugefügt. Diese werden es erlauben, ansel-cli auf Backend-Servern auszuführen. Beachten Sie jedoch, dass Ansel CLI nicht sicher auf Servern mit öffentlichem Webzugriff ausgeführt werden kann, da es keine Code-Injektion verhindert und Benutzereingaben in keiner Weise bereinigt. Docker-Images basieren auf Ubuntu 24.04.

Ein möglicher Anwendungsfall von Docker-Images wäre der Betrieb von Rendering-Farmen, um Ansel-Bildexporte auf Server mit großer GPU auszulagern:

  • das RAW und das bearbeitende XMP an den Server senden,
  • das resultierende JPG erhalten.

In einigermaßen schnellen Netzwerken würde das Nutzer davon abhalten, teure Hardware zu kaufen, wenn sie diese nur selten voll ausschöpfen, während die Kosten eines rund um die Uhr laufenden Remote-Servers zwischen den Nutzern geteilt werden.

MacOS

MacOS-Nightly-Builds wurden letzten Oktober für die Apple-M-Architektur (Arm64) hinzugefügt. Im September 2025 fügte Github Runner für MacOS 15 Sonoma auf Intel-Architektur hinzu. Dies ermöglichte es, heute Unterstützung für Intel i386 für die Ansel-Nightly-Builds hinzuzufügen. Beide Architekturen werden auf MacOS 15 Sonoma kompiliert.

Beachten Sie, dass die Apple-Intel-Architektur  von Github für August 2027 zur Einstellung vorgesehen ist, da Apple die Unterstützung dieser Architektur eingestellt hat. Danach wird es keinen einfachen Weg mehr geben, Ansel für Apple-Intel-Hardware zu bauen.

Über Nightly Builds

Nightly Builds werden automatisch auf Github-Runnern generiert (stellen Sie sich diese als virtuelle Server vor, die Sie aus Skripten starten und stoppen können, um Dinge auszuführen), jeden Morgen zwischen 5 und 7 Uhr UTC. Die generierten Pakete werden zu den Pre-Release-Notes  hinzugefügt, die als Repository fungieren und 1,5 Jahre Build-Historie bereitstellen, sodass Sie die Möglichkeit haben, auf eine zuvor funktionierende Version zurückzurollen, falls Codeänderungen die Anwendung plötzlich auf eine Weise brechen, die Sie an ihrer Nutzung hindert.

Die Nightly Builds sind vollständig abhängig:

  • von Github für die Bereitstellung der Runner,
  • von Homebrew  für die Bereitstellung des MacOS-Abhängigkeits-Ökosystems,
  • von MSYS Pacman  für die Bereitstellung des Windows-Abhängigkeits-Ökosystems,
  • von Ubuntu  für die Bereitstellung des Linux-Abhängigkeits-Ökosystems.

Das sind eine Menge Dritter, auf die man sich verlassen muss, und Nightly Builds gehen oft einfach kaputt, nur weil Github einen Runner eingestellt hat oder eines von MSYS/Ubuntu/Homebrew ein Paket umbenannt, entfernt oder auf eine neuere Version aktualisiert hat, die die API ändert und mit den Ansel-Interna bricht. Trotz der scheinbaren Automatisierung des gesamten Workflows ist also weiterhin regelmäßige Wartung nötig, und Nightly Builds bleiben möglicherweise einige Zeit kaputt.

Danksagungen

Ich möchte danken:

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