darktable-chartDieses Kapitel behandelt verschiedene technische Themen, die Ihnen helfen darktable auf einer bestimmten Hardware zum Laufen zu bringen oder die Leistung zu optimieren. Viele zusätzliche technische Hintergrundinformationen sowie Tipps und Tricks finden Sie im Blog-Bereich unserer Homepage.
 |
Der Speicherbedarf von darktable ist hoch. Eine einfache Rechnung macht dies deutlich. Wenn Sie ein 20MPix-Bild haben, speichert Darktable aus Gründen der Präzision dieses intern als 4 x 32-Bit Fließkommazelle für jedes Pixel. Jedes Vollbild dieser Größe benötigt ca. 300MB Speicherplatz. Da wir das Bild verarbeiten wollen, benötigen wir mindestens zwei Puffer für jedes Modul – einen für den Eingang und einen für den Ausgang. Wenn wir ein komplexeres Modul haben, kann es sein, dass sein Algorithmus zusätzlich mehrere Zwischenpuffer gleicher Größe benötigt. Ohne weitere Optimierung wären zwischen 600MB und 3 GB nur für die Speicherung und Verarbeitung von Bilddaten erforderlich. Darüber hinaus haben wir darktable's Code-Segment, den Code und die Daten aller dynamisch verknüpften Systembibliotheken und nicht zu vergessen weitere Puffer, in denen darktable Zwischenbilder für den schnellen Zugriff während der interaktiven Arbeit speichert (mip map cache). Alles in allem benötigt darktable ein Minimum von ca. 4 GB, um gut zu laufen.
Von dem zuvor beschriebenem ist es offensichtlich, dass Ihr Computer ein vernünftiges Speicher-Setup benötigt, damit darktable korrekt ausgeführt wird. Mindestens 4 GB physischen Arbeitsspeicher plus 4 bis 8 GB zusätzlichen Swap-Speicherplatz sind erforderlich. Letzteres ist erforderlich, damit Ihr System vorübergehend nicht benötigte Daten auf die Festplatte auslagern kann, um physischen Arbeitsspeicher freizugeben.
Theoretisch kann darktable auch mit weniger physischem RAM betreiben werden, vorausgesetzt dies wird mit einem ausreichend großen Auslagerungsspeicher ausgeglichen. Sie sollten jedoch darauf vorbereitet sein, dass Ihr System dann stark überlastet werden kann, da viel Daten auf und von der Festplatte gelesen oder geschrieben wird. Es liegen positive Berichte von mehreren Anwendern vor, bei denen dies gut funktioniert.
Neben der Gesamtmenge an Systemspeicher gibt es noch einen weiteren limitierenden Faktor: den verfügbaren Adressraum Ihrer Hardware-Architektur. Wie viel Speicher von einem Prozess adressiert werden kann, hängt von der Anzahl der Adressbits ab, die Ihre CPU anbietet. Bei einer CPU mit 32-Bit-Adressregistern sind das 2^32 Byte, also insgesamt 4GB. Dies ist die absolute Obergrenze des Speichers, die von einem Prozess genutzt werden kann und stellt eine knappe Situation für darktable dar, wie oben erwähnt.
Der Ausweg für darktable heißt Kacheln. Anstatt ein Bild in einem großen Stück zu bearbeiten, teilen wir das Bild für jeden Bearbeitungsschritt (Modul) in kleinere Teile auf. Dies erfordert immer noch einen kompletten Eingangs- und Ausgangspuffer, aber Zwischenpuffer können so klein gemacht werden, dass alles in die Hardwaregrenzen passt.
Leider ist dies noch nicht die ganze Geschichte. Es gibt einen Effekt namens Speicherfragmentierung, der Software treffen kann und wird, die eine umfangreiche Speicherverwaltung durchführen muss. Wenn ein solches Programm 5 mal 300 MB auf einmal allokiert und wieder freigibt, sollte dieser Speicher normalerweise für eine große 1,5 GB Allokation zur Verfügung stehen. Dies ist jedoch oft nicht der Fall. Der Speicherzuweiser des Systems sieht diesen Bereich möglicherweise nicht mehr als einen zusammenhängenden 1,5-GB-Block, sondern als eine Reihe von 300-MB-Bereichen. Wenn kein anderer freier Speicherplatz von 1,5 GB zur Verfügung steht, würde die Zuweisung fehlschlagen. Während eines Programmlaufs wird dieser Mechanismus immer mehr von den größeren Speicherblöcken zu Gunsten der kleineren wegnehmen. darktable 2.0 mip map cache weist mehrere kleine Speicherblöcke pro Thumbnail zu, sodass dieses Problem noch größer ist. Aus diesem Grund werden 32-Bit-Systeme ab darktable 2.0 nur noch eingeschränkt unterstützt.
Als ob das nicht schon eine Herausforderung genug wäre, gibt es noch weitere Dinge, die den Zugriff auf den Speicher einschränken könnten. Auf einigen älteren Boards müssen Sie die BIOS-Option „Memory Remapping“ aktivieren, damit der physikalisch installierte Speicher aktiviert wird. Zusätzlich benötigen Sie, wenn Sie auf einem 32-Bit-Betriebssystem arbeiten, wahrscheinlich eine Kernel-Version, die „Physical Address Extension“ (PAE) aktiviert hat. Dies ist bei Linux oft, aber nicht immer der Fall. Viele Distributionen liefern unterschiedliche Kernel, einige mit und andere ohne aktivierte PAE; Sie müssen den richtigen Kernel auswählen. Um zu überprüfen, ob das System korrekt eingerichtet ist, verwenden Sie den Befehl „free“ in einem Terminal und überprüfen Sie die Ausgabe. Wenn die Ausgabe weniger Arbeitsspeicher als Sie installiert haben, haben Sie ein Problem, das korrigiert werden muss; zum Beispiel haben Sie 4 GB auf Ihrem Board, aber Ihr Kernel sieht nur 3 GB oder weniger. Weitere Hilfe finden Sie in Ihrem BIOS-Handbuch und in den Informationen zu Ihrer Linux-Variante.
Wie schon erwähnt, sind 32-Bit-Systeme schwierige Umgebungen für Darktable. Noch immer betreiben einige Anwender darktable auf ihnen, wenn die grundlegenden Anforderungen an den Gesamtsystemspeicher und die in den obigen Abschnitten genannten Themen richtig adressiert werden.
Es gibt verschiedene Einstellparameter, um den Betrieb zu ermöglichen. Wenn Sie neu installieren, erkennt darktable Ihr System und setzt standardmäßig konservative Werte. Wenn Sie darktable von einer älteren Version upgraden (z.B. von 0.9.3 auf 1.0), stehen die Chancen gut, dass Sie ungünstige Einstellungen in Ihren Einstellungen haben. Die Folgen können sein, dass ein Darktable-Abbruch aufgrund von Allokationsfehlern oder – sehr typisch – darktable nicht in der Lage ist, eine neue Filmrolle ordnungsgemäß zu importieren. Als häufiges Symptom werden für viele Ihrer Bilder Schädel statt Daumen angezeigt.
If this is the case, take a minute to optimize the preference settings in this case. You will find them under „cpu / gpu / memory“ (Abschnitt 8.8, „Cpu / gpu / memory“) in darktable's preference dialog. You should also find these parameters as configuration variables in $HOME/.config/darktable/darktablerc and edit them there.
Hier eine kurze Erklärung der relevanten Parameter und der vorgeschlagenen Einstellungen:
Dieser Parameter legt die maximale Anzahl von Threads fest, die parallel zum Import von Filmrollen oder anderen Hintergrundmaterialien erlaubt sind. Aus offensichtlichen Gründen können Sie auf 32-Bit-Systemen immer nur einen Thread haben, der Ressourcen frisst. Also musst du diesen Parameter auf 1 setzen; alles höhere wird dich erledigen.
Dieser Parameter gibt darktable an, wie viel Speicherplatz (in MB) für die Speicherung von Bildpuffern während des Modulbetriebs zur Verfügung steht. Wenn ein Bild nicht innerhalb dieser Grenzen in einem Stück bearbeitet werden kann, übernimmt das Kacheln das Bild und verarbeitet es in mehreren Teilen nacheinander. Setzen Sie diesen Wert auf den kleinstmöglichen Wert von 500 als Ausgangspunkt. Sie könnten später experimentieren, ob Sie es ein wenig erhöhen können, um den Aufwand für das Kacheln zu reduzieren.
Dies ist ein zweiter Parameter, der das Kacheln steuert. Er legt eine untere Grenze für die Größe der Zwischenbildpuffer in Megabyte fest. Der Parameter wird benötigt, um in einigen Fällen (bei einigen Modulen) ein übermäßiges Kacheln zu vermeiden. Setzen Sie diesen Parameter auf einen niedrigen Wert von 8. Du könntest sie später auf 16 erhöhen.
Hiermit wird gesteuert, wie viele Miniaturansichten (oder MIP-Maps) gleichzeitig im Speicher abgelegt werden können. Als Startpunkt setzen Sie dies auf etwa 256MB. Seit darktable 2.0 weist der Cache pro Thumbnail im Cache einige kleine Puffer zu, was zu einer erheblichen Speicherfragmentierung führt. Wie bereits erwähnt, stellt dies ein Problem für 32-Bit-Systeme dar. Aus diesem Grund ist ab darktable 2.0 die 32-Bit-Unterstützung soft-deprecated.
Es gibt hier nicht viel zu sagen. Natürlich benötigen auch 64-Bit-Systeme ausreichend Hauptspeicher, sodass die 4 GB plus Swap-Empfehlung gilt. Andererseits leiden 64-Bit-Architekturen nicht unter den spezifischen 32-Bit-Beschränkungen wie kleiner Adressraum und Fragmentierung.
Die meisten modernen Intel oder AMD 64-Bit CPUs werden über einen Adressraum im Bereich von mehreren Terabyte verfügen. Das Wort „modern“ ist in diesem Zusammenhang relativ: Alle AMD- und Intel-CPUs, die seit 2003 bzw. 2004 eingeführt wurden, bieten einen 64-Bit-Modus. Linux 64-bit ist seit vielen Jahren verfügbar.
Bei allen relevanten Linux-Distributionen haben Sie die Wahl, eine 32-Bit- oder eine 64-Bit-Version ohne zusätzliche Kosten zu installieren. Sie können sogar alte 32-Bit-Programme auf einem 64-Bit-Linux ausführen. Am Ende empfehlen wir dringend, auf eine 64-Bit-Version von Linux umzusteigen. Es gibt wirklich keinen Grund, nicht auf 64-Bit zu aktualisieren.
Auf einem 64-Bit-System können die kachelbezogenen Konfigurationsparameter auf ihrem Standardwerten belassen werden: „host memory limit (in MB) for tiling“ sollte einen Wert von 1500 haben und „minimum amount of memory (in MB) for a single buffer in tiling“ sollte auf 16 gesetzt werden. Falls Sie von einem 32-Bit- auf ein 64-Bit-System migrieren, müssen Sie diese Einstellungen überprüfen und bei Bedarf manuell im Einstellungsdialog von darktable ändern.
Normalerweise ist es nicht notwendig die der Anzahl der Hintergrund-Threads auf einem 64-Bit-System einzuschränken. Auf einem Multiprozessorsystem kann eine Anzahl von zwei bis acht Threads die Erzeugung von Vorschaubildern erheblich beschleunigen, im Gegensatz zu nur einem Thread. Der Grund dafür ist nicht so sehr die maximale Ausnutzung all Ihrer CPU-Kerne – die Pixelpipe von darktable nutzt ohnehin alle parallel – sondern das Verstecken von I/O-Latenzzeiten.
Eine Ausnahme ist erwähnenswert. Wenn Sie darktable verwenden, um zusammengesetzte Panoramen zu verarbeiten, z. B. TIFFs, wie sie von Hugin erzeugt wurden, können diese Bilder beachtliche Größen erreichen. Jeder Hintergrund-Thread muss genügend Speicher allokieren, um ein volles Bild plus Zwischenprodukte und Ausgabe in seinen Puffern zu halten. Dies kann selbst bei einem gut ausgestatteten 64-Bit-System schnell zu einem Speicherplatzmangel führen. Verringern Sie in diesem Fall die Anzahl der Hintergrund-Threads auf nur einen.
