Speicher
Die Anforderungen von darktable an den Speicher sind hoch. Eine einfache Berechnung illustriert das. Wenn du ein 20MPx Bild hast, wird darktable dieses intern als 4x32-bit Fließkomma Zelle für jedes Pixel speichern. Jedes ganze Bild dieser Grösse wird deshalb ca 300 MB Speicher erfordern. Wenn wir nun das Bild bearbeiten, brauchen wir mindestens zwei Pufferspeicher für jedes Modul - einen für die Eingabe und einen für die Ausgabe. Wenn wir ein komplexeres Modul haben, werden dessen Algorithmen zusätzlich mehrere Zwischen-Puffer der gleichen Größe erfordern. Ohne zusätzliche Optimierung, wird irgendetwas zwischen 600MB und 3 GB nötig sein, nur um die Bilddaten zu speichern. Darüber hinaus haben wir noch dartables Code Segment, den Code und die Daten aller dynamisch verbundenen Libraries, und nicht zu vergessen, zusätzlicher Puffer, dort wo darktable Bilder für einen schnellen Zugriff während dem Interaktiven arbeiten, zwischenspeichert (mip map cache).
Alles zusammen wird darktable ein Minimum von 4GB Speicher erfordern, um problemlos zu laufen.
🔗Gesamt System-Speicher
Aus der obigen Analyse geht hervor, dass dein Rechner ein gutes Speicher-System braucht, um darktable sauber laufen zu lassen. Wir empfehlen, dass du mindestens 4GB physikalischen RAM hat plus 4 bis 8GB zusätzlichen Swap-Speicher installiert hast.
Theoretisch kann darktable auch mit weniger physischem RAM betreiben werden, vorausgesetzt dies wird mit einem ausreichend großen Auslagerungsspeicher ausgeglichen. Du solltest jedoch darauf vorbereitet sein, dass dein 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, aber es wird sehr langsam werden für andere. Eine SSD kann dies etwas entschärfen.
🔗Verfügbarer Adressraum
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.
🔗Speicherfragmentierung
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.
🔗Weitere Einschränkungen
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 musst du die BIOS-Option „Memory Remapping“ aktivieren, damit der physikalisch installierte Speicher aktiviert wird. Zusätzlich benötigen Sie, wenn du auf einem 32-Bit-Betriebssystem arbeitest, 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; du musst den richtigen Kernel auswählen. Um zu überprüfen, ob das System korrekt eingerichtet ist, verwende den Befehl „free“ in einem Terminal und überprüfe die Ausgabe. Wenn die Ausgabe weniger Arbeitsspeicher als du installiert hast, dann hast du ein Problem, das korrigiert werden muss; zum Beispiel hast du 4 GB auf deinem Board, aber dein Kernel sieht nur 3 GB oder weniger. Weitere Hilfe findest du in deinem BIOS-Handbuch und in den Informationen zu deiner Linux-Variante.
🔗Einrichten von darktable auf 32-Bit-Systemen
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 du neu installierst, erkennt darktable dein System und setzt standardmäßig konservative Werte. Wenn du darktable von einer älteren Version upgraden (z.B. von 0.9.3 auf 1.0), stehen die Chancen gut, dass du ungünstige Einstellungen in deinen 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 deiner Bilder Schädel statt Vorschaubilder angezeigt.
Wenn das der Fall ist, solltest du deine Grund-Voreinstellungen optimieren. Du findest diese in darktable-Voreinstellungen > CPU/GPU/Speicher.
Hier eine kurze Erklärung der relevanten Parameter und der vorgeschlagenen Einstellungen:
- Anzahl der Hintergrund-Threads
- 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.
- Host-Speicherbegrenzung (in MB) für das Kacheln
- 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. Setze diesen Wert auf den kleinstmöglichen Wert von 500 als Ausgangspunkt. Du kannst später experimentieren, ob du es ein wenig erhöhen kannst, um den Aufwand für das Kacheln zu reduzieren.
- Minimaler Speicherplatz (in MB) für einen einzelnen Puffer beim Kacheln
- 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. Setze diesen Parameter auf einen niedrigen Wert von 8. Du könntest sie später auf 16 erhöhen.
- Speicher in Megabyte, der für den Thumbnail-Cache verwendet werden soll.
- Hiermit wird gesteuert, wie viele Miniaturansichten (oder MIP-Maps) gleichzeitig im Speicher abgelegt werden können. Als Startpunkt setze 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.
🔗darktable auf 64-Bit-Systemen
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 hast du die Wahl, eine 32-Bit- oder eine 64-Bit-Version ohne zusätzliche Kosten zu installieren. Du kannst 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 ihren 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 du von einem 32-Bit- auf ein 64-Bit-System migrierst, musst du 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 du darktable verwendest, 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. Verringer in diesem Fall die Anzahl der Hintergrund-Threads auf nur einen.