Darktable Austausch

[Lümmel]

Werbung (verschwindet nach Registrierung)

vor 23 Minuten schrieb bastibe:

Das ist ein Game Changer! Exposure sitzt ja am unteren Ende der Pixel Pipeline, ist also einer der langsamsten Slider zu bewegen. Dass ich den nun im Echtzeit drehen kann, ändert alles! Ich bin beeindruckt. (Und verstehe nicht, warum Darktable auf dem selben Rechner mit Linux so viel schneller läuft als mit Windows). 

Ah, dann liegt das am Windows. Ich habe mich immer gewundert, warum Belichtungsänderungen bei dt so lange brauchen.

Auf Linux werde ich deswegen allerdings nicht wechseln 😉 

[bastibe]

Nein, dass Exposure langsam ist liegt daran, dass es ganz am Anfang der Pixelpipe steht. Sprich, wenn sich Exposure ändert müssen fast alle anderen Module ebenfalls neu rechnen. 

Darktable scheint grundsätzlich auf Linux schneller zu laufen. Das hat aber nicht spezifisch mit Exposure zu tun. 

bearbeitet 11. Februar 2022 von bastibe

[Lümmel]

Komischerweise ist das aber nur bei dt so. Alle anderen Konverter können die Belichtung ohne Verzögerung ändern. Na, vielleicht passiert da ja irgendwann auch was.

[darkentab]

vor 16 Stunden schrieb clooney:

Nutzt jemand darktable in Verbindung mit Linux? Wenn ja, wäre es einmal interessant zu erfahren, ob jemand sich seine aktuelle Version direkt aus dem git compiliert. Irgendjemand so frei?

nur wenn ich 'ne neue master-Version testen will, und dann mach ich das so:

https://www.bilddateien.de/blog/2020-07-07-darktable-bauen-zweite-instanz.html

bearbeitet 11. Februar 2022 von darkentab

[bastibe]

40 minutes ago, Lümmel said:

Komischerweise ist das aber nur bei dt so. Alle anderen Konverter können die Belichtung ohne Verzögerung ändern. Na, vielleicht passiert da ja irgendwann auch was.

Das liegt am scene referred und an der offenen Pipeline. Da in Darktable alle Innereien offen liegen macht es Sinn, die Belichtung möglichst früh zu korrigieren, so dass alle späteren Module mit sinnvollen Helligkeiten arbeiten können. Das wäre egal wenn man die Reihenfolge eh nicht kennt und alle Werte eh zwischen Null und Eins liegen. 

Die Exposure selbst ist trivial, nur eine Multiplikation. Wenn du das lieber schneller hast, schiebe sie dir einfach ans Ende der scene referred pipeline, direkt vor Filmic (oder setze das Häkchen in Filmic, dass du die Exposure direkt dort integrierst). Dann ist sie auch flott. Aber wenn du etwa den tone equalizer oder color balance benutzen möchtest arbeitet es sich halt leichter mit angepasster Helligkeit. 

[clooney]

vor 2 Stunden schrieb darkentab:

nur wenn ich 'ne neue master-Version testen will, und dann mach ich das so:

dann ist das ganz ähnlich zu meinem Vorgehen. Für das Klonen und Aktualisieren habe ich mir ein Skript gebaut, dass unter meinem Anwenderaccount aller erledigt. Die binaries + libs werden im Home Verzeichnis gebaut, so dass man alles schnell mal löschen kann. Zwischen der eigenen gebauten und der dt Version aus dem Paketmanager gibt es eine friedliche, aber separate Koexistenz. Nur die DB wird von beiden genutzt, was ich ganz smart finde.

[clooney]

Werbung (verschwindet nach Registrierung)

vor 14 Stunden schrieb troll:

Aktuelle git-Master Version habe ich gerade eben kompiliert. 

Hast du Fragen zu dem Thema?

Ja, eventuell. Ich verwende ein Skript zur Aktualisierung. Bin mir aber nicht sicher, ob alle submodule und alles andere Gedöns damit aktualisiert werden.

# Initial source download: git clone --recurse-submodules --depth 1 https://github.com/darktable-org/darktable.git && cd $HOME/darktable && mdir build
cd $HOME/darktable
#git pull
# Nur beim ersten Lauf: git submodule init
git pull --ff-only origin master
git submodule init
git submodule update
git pull --recurse-submodules
cd $HOME/darktable/build
cmake -DCMAKE_INSTALL_PREFIX=$HOME/programs -DCMAKE_BUILD_TYPE=Release ..
make -j32
make install

Habe ich irgend etwas dabei vergessen?

[pero]

vor einer Stunde schrieb clooney:

Ja, eventuell. Ich verwende ein Skript zur Aktualisierung. Bin mir aber nicht sicher, ob alle submodule und alles andere Gedöns damit aktualisiert werden.

# Initial source download: git clone --recurse-submodules --depth 1 https://github.com/darktable-org/darktable.git && cd $HOME/darktable && mdir build
cd $HOME/darktable
#git pull
# Nur beim ersten Lauf: git submodule init
git pull --ff-only origin master
git submodule init
git submodule update
git pull --recurse-submodules
cd $HOME/darktable/build
cmake -DCMAKE_INSTALL_PREFIX=$HOME/programs -DCMAKE_BUILD_TYPE=Release ..
make -j32
make install

Habe ich irgend etwas dabei vergessen?

make -j32 ? 🤪
Was ist denn das für ein Monster?

[Anzeige]

Ich würde dir das Adobe Creative Cloud Foto-Abo mit Photoshop und Lightroom empfehlen

[clooney]

vor 6 Minuten schrieb pero:

Monster

kein Monster, aber ein AMD Ryzen 9 3950X. D.h., der verkraftet ein -j32 mit seinen 32 Kernen

[pero]

Grad nachgesehen. Der hat 16 Kerne. Ich denke die 32 kommen vom SMT, nicht wahr?
Bekommst du einen Leistungszuwachs? Beim Intelschen Hyperthreading werden ja nur die Pipelines vor der Recheneinheit dupliziert.
Wenn er tatsächlich 32 mal die Recheneinheit anfordert, bremst es die Sache eher noch aus.
(Vor kurzem grad bei meiner Möhre getestet, da habe ich das abgreschaltet. Allerdings wurden bei mir rein  mathematische Prozesse
rennen lassen).
Oder reagiert der AMD da ein wenig anders?

[clooney]

vor 10 Minuten schrieb pero:

die 32 kommen vom SMT, nicht wahr?

stimmt, habe ich verwechselt. Das sind die Anzahl Threads (Simultaneous Multithreading=SMT). nproc liefert die max Anzahl der Jobs, die parallel mit der Option "-j" laufen können. Das ist bei meiner CPU 32. In der Praxis gelten aber noch Limitierungen wie Speicher insgesamt, Speichermenge, die die jeweiligen jobs nutzen und evtl. noch mehr. Insofern muss man immer mal schauen.

Ausgebremst? Gefühlt eher das Gegenteil. Vergleichsmöglichkeiten habe ich nicht, bin aber mit der Übesetzungszeit ganz zufrieden.

[guenni66]

Am 11.2.2022 um 09:49 schrieb darkentab:

nur wenn ich 'ne neue master-Version testen will, und dann mach ich das so:

https://www.bilddateien.de/blog/2020-07-07-darktable-bauen-zweite-instanz.html

Ich bin da eher faul und da meine Mühle auch nicht mehr die Schnellste beim Kompilieren ist, hole ich mir mit den regelmäßigen Updates auf mein Debian-System auch den aktuellen Darktable Night-build:

deb http://download.opensuse.org/repositories/graphics:/darktable:/master/Debian_11/ /

(habe die apt source datei angehängt - einfach in /etc/apt/sources.list.d kopieren)

LG Günther

graphics:darktable:master.list

bearbeitet 14. Februar 2022 von guenni66

[darkentab]

jaaaa .... aber ...

Die OBS-Version von master überschreibt Dir dann die stabile Version (derzeit 3.8.1) von ebendort - oder nicht.

Genau das will ich ja nicht, 25.000 zerhauene Bilder im Zweifelsfall sind mir einfach zu viele. Deshalb ja die

Am 11.2.2022 um 12:25 schrieb clooney:

 friedliche, aber separate Koexistenz.

Zwei getrennte Installationen in getrennten Verzeichnissen mit getrennten Profilen. Aber das geht - soweit ich weiß - nur in Handarbeit.

[guenni66]

vor 16 Stunden schrieb darkentab:

Die OBS-Version von master überschreibt Dir dann die stabile Version (derzeit 3.8.1) von ebendort - oder nicht.

Genau das will ich ja nicht, 25.000 zerhauene Bilder im Zweifelsfall sind mir einfach zu viele.

Na ja, die Bilder sind ja nicht zerhauen, wenn du externe xmp-Dateien nutzt. Außerdem sind die Bearbeitungsschritte ja auch im erzeugten jpg drin und können von dort wieder zurückgelegen werden (notfalls per stapel für eine große Anzahl). "Nur" die library.db kann drauf gehen bzw. auf eine neue inkompatible Version upgegraded werden. Dabei wird aber eine Sicherungskopie der alten angelegt. Die library.db und die configs lasse ich sowieso stündlich von Backintime sichern. Auch von den Bildern mit ihren xmps existieren natürlich mehrfache Sicherungen.

Sehe das Risiko also als sehr gering ein. Ich arbeite seit Darktable  v0.8 ausschießlich mit den Entwicklerversionen und habe in den Jahren noch kein einziges Bild verloren.

bearbeitet 15. Februar 2022 von guenni66

[troll]

Am 11.2.2022 um 12:31 schrieb clooney:

Ja, eventuell. Ich verwende ein Skript zur Aktualisierung. Bin mir aber nicht sicher, ob alle submodule und alles andere Gedöns damit aktualisiert werden.

# Initial source download: git clone --recurse-submodules --depth 1 https://github.com/darktable-org/darktable.git && cd $HOME/darktable && mdir build
cd $HOME/darktable
#git pull
# Nur beim ersten Lauf: git submodule init
git pull --ff-only origin master
git submodule init
git submodule update
git pull --recurse-submodules
cd $HOME/darktable/build
cmake -DCMAKE_INSTALL_PREFIX=$HOME/programs -DCMAKE_BUILD_TYPE=Release ..
make -j32
make install

Habe ich irgend etwas dabei vergessen?

So ein super Spezialist bin ich da auch nicht, "submodule update" mache ich nur sporadisch, je nachdem was so geändert wurde (kann aber wohl nicht schaden).

Das Bauen lasse ich dann ganz bequem das mitgelieferte build.sh erledigen, mit z.B.

./build.sh --build-type Release.

Installieren dann mit:

cmake --build "~/darktable/build" --target install -- -j4 

Ja, nur eine 4 😕

[Anzeige]

Guck dir auch mal das Sony 12-24 G Master an

[darkentab]

vor 8 Stunden schrieb guenni66:

Na ja, die Bilder sind ja nicht zerhauen, wenn du externe xmp-Dateien nutzt. Außerdem sind die Bearbeitungsschritte ja auch im erzeugten jpg drin und können von dort wieder zurückgelegen werden (notfalls per stapel für eine große Anzahl). "Nur" die library.db kann drauf gehen bzw. auf eine neue inkompatible Version upgegraded werden. Dabei wird aber eine Sicherungskopie der alten angelegt. Die library.db und die configs lasse ich sowieso stündlich von Backintime sichern. Auch von den Bildern mit ihren xmps existieren natürlich mehrfache Sicherungen.

auch das ist relativ.

• die RAW-Datei geht sicher nicht verloren, da "non destructive imaging"
• Ja, ich hab seit jeher die xmps aktiv, war nie anders
• JPG - nur, wenn ich eins hab. Ich mach kein doppeltes Archiv auf, sondern exportiere das jpg dann und in dem Format, das ich für den Zweck gerade brauche (und oft justiere ich dann nochmal nach bei der Bearbeitung - man lernt ja dazu 🙂).
• darktable fragt beim Start, ob xmps aktualisiert werden sollen, wenn diese von der db abweichen. Hängt von Deiner Antwort ab ...
• in github gibt es Tickets von mir, die darktable-crashes aufgrund von xmp beschreiben, die mit irgendeiner sehr alten Version geschrieben und seither nicht mehr geöffnet wurden. Pascals Vermutung: war wohl 'ne Master-Version (kann ich aber nicht nachvollziehen, hab ich damals noch nicht genutzt). Ergo teste ich mit 'nem kleinen Test-Archiv.
• Metadaten werden nur z. T. in den xmps abgelegt, z. B. Gruppierungen sind dort nicht enthalten.

Und ansonsten gibt's immer mal wieder eine entsprechende Mindestsicherung - ohne die geht mal gar nix ... 🤓

bearbeitet 15. Februar 2022 von darkentab

[clooney]

Am 14.2.2022 um 09:48 schrieb guenni66:

Ich bin da eher faul und da meine Mühle auch nicht mehr die Schnellste beim Kompilieren ist, hole ich mir mit den regelmäßigen Updates auf mein Debian-System auch den aktuellen Darktable Night-build:

deb http://download.opensuse.org/repositories/graphics:/darktable:/master/Debian_11/ /

(habe die apt source datei angehängt - einfach in /etc/apt/sources.list.d kopieren)

LG Günther

Ich nutze seit einigen Jahren Fedora, die Rawhide Variante. Damit bin ich bis auf wenige Male bisher ganz gut gefahren. Theoretisch könnte ich mir auch aus den dt-Sourcen ein rpm-Paket bauen und dann installieren. Ich glaube, so funktioniert deine Variante in Debian. Anfangs hatte ich auch überlegt, ob ich das nicht auf diese Weise mache, bin dann aber zum Schluss gekommen, dass ich alle Abhängigkeiten (inkl. dev-Pakete) über den Paketmanager installiere und dann die Sourcen aus git aufgrund der dann vorhandenen Flexibilität selbst baue. Das hat bisher immer ganz gut funktioniert, bin ich mir nie so sicher, ob das Skript (s. oben) mir auf Dauer die richtigen und aktuellen Module zusammenbaut (daher auch die Anfrage von mir).

Sicherlich ist ein -j32 da sehr hilfreich. Der erste vollständige Kompilierungsvorgang braucht schon etwas Zeit, geht aber immer noch wg. der HW recht schnell. Wenn ich mein o.g. Skript aber nach einigen Tagen erneut aufrufe, wird nicht das ganze darktable neu gebaut, sondern nur die geänderten und davon abhängigen Bibliotheken. Das geht dann wiederum noch schneller.

bearbeitet 20. Februar 2022 von clooney

[clooney]

In der neuen Entwicklungsversion gibt es im highlight reconstruction Modul die neue Möglichkeit des guided laplacians (AI)  mit einigen einstellbaren Parametern. Darktables schwache Seite liegt (schon jeher) beim Retten von Spitzlichern (highlight recovery), insofern ist das hoffentlich eine brauchbare Neuerung. Zusammen mit dem Modul filmic rgb ist das Zusammenspiel der beiden Funktionen eher von der komplexeren Art. Auf pixl.us gibt es ellenlange Threads zum Gebrauch. Falls jemand schon Erfahrungen gesammelt hat, immer her damit.

Hallo, lieber Besucher! Als Forumsmitglied (kostet nix) würdest du hier ein Bild sehen…

Einfach hier registrieren – Wir freuen uns immer über neue Mitglieder!

[bastibe]

Außerdem wurde in der Entwicklungsversion der Filmic-Algorithmus noch einmal überarbeitet, was offenbar die Farbtreue deutlich verbessert.

Im Forum wurde auch noch ein weiterer Color Preservation Mode von einem bisher externen Entwickler vorgestellt der sehr vielversprechend aussieht, dort scheint es aber noch keinen Fortschritt zu geben, den in Darktable zu mergen. 

Auf meinem eigenen Rechner habe ich mir ein lustiges Skript geschrieben, das automatisch einige Metadaten meiner Fuji-Kamera mit Darktable anwendet: Film-Simulationen, Crop, Dynamic Range Mode. Das hat mir das Editieren deutlich beschleunigt. 

Und ich arbeite daran, mir für Darktable angepasste Film Simulation LUTs zu basteln. Aber das Projekt wird noch ein bisschen dauern. 

Kurzum, die für den Sommer anvisierte Version 4 könnte ein Knaller werden! 

[bastibe]

On 4/28/2022 at 5:48 PM, clooney said:

Zusammen mit dem Modul filmic rgb ist das Zusammenspiel der beiden Funktionen eher von der komplexeren Art

Das muss man leider bei einigen der neuen Module sagen. Filmic hat sich inzwischen ein wenig beruhigt und wurde über einige Versionen sinnvoll vereinfacht. 

Aber Diffuse and Sharpen z.B. ist völlig undurchsichtig. Und die neue highlight reconstruction sieht ebenfalls schwierig aus. Nun ja. Ich hoffe einfach darauf, dass auch diese Module sich über die Zeit vereinfachen werden. 

[clooney]

Am 29.4.2022 um 07:07 schrieb bastibe:

Und ich arbeite daran, mir für Darktable angepasste Film Simulation LUTs zu basteln.

LUTs sind hier nicht so gefragt. Ich hatte mal ein Thread begonnen, in dem du als einziger reagiert hast. Wenn du mit deinen LUTs fertig bist, zeig' doch mal ein paar Bilder.

[bastibe]

Stimmt, das ist hier nicht hip. Vielleicht auch, weil die großen Editoren C1, LR, DxO lieber Presets verkaufen als dem Pöbel zu erlauben, schnöde LUTs zu laden 😂. Macht aber nichts, das muss uns ja nicht stören. Jedem das Seine und so.

Ich bastele mir die LUTs von Hand aus SOOC-Aufnahmen und parallel dazu mit Darktable entwickelten Bildern. Dann ein bisschen Programmieren und Mathe und so, dann wird daraus ein nettes LUT. 

Momentan funktionieren meine LUTs schon sehr gut, aber es gibt noch einen Randfall, den ich noch sauber untersuchen muss. Drüben in pixls gibt es einen Thread dazu mit den LUTs zum spielen. 

[Anzeige]

Viele User im Forum fanden auch die Lumix GH5 interessant

[herbert-50]

Am 30.4.2022 um 18:16 schrieb clooney:

LUTs sind hier nicht so gefragt. Ich hatte mal ein Thread begonnen, in dem du als einziger reagiert hast. Wenn du mit deinen LUTs fertig bist, zeig' doch mal ein paar Bilder.

Eigentlich schade, da man hier mit einem Mausklick doch soviel bewirken kann. Zudem sind LUTs sehr schnell.

[herbert-50]

Am 1.5.2022 um 13:08 schrieb bastibe:

Stimmt, das ist hier nicht hip. Vielleicht auch, weil die großen Editoren C1, LR, DxO lieber Presets verkaufen als dem Pöbel zu erlauben, schnöde LUTs zu laden 😂. Macht aber nichts, das muss uns ja nicht stören. Jedem das Seine und so.

...

Was mich ein bisschen wundert, weil LR, Capture One & Co können auch LUTs und auch hier werden anscheinend gute Geschäfte gemacht - ähnlich wie mit den Presets. Z.B.:

https://lutify.me/products/3d-luts-packages/basic/

oder es scheint auch Generatoren zu geben

https://3dlutcreator.com/

Vielleicht sind die LUTs bei vielen einfach noch nicht angekommen.

[herbert-50]

Ich habe bisher das Modul 3DLUT immer relativ spät in der Pixel-Pipe ausgeführt, weil die LUTs aus dem HALDCLUT-Paket ja auch in Gimp auf fertige JPGs angewendet werden. Von den Ergebnissen hat das immer ganz gut gepasst.

Hallo, lieber Besucher! Als Forumsmitglied (kostet nix) würdest du hier ein Bild sehen…

Einfach hier registrieren – Wir freuen uns immer über neue Mitglieder!

Jetzt habe ich mir eine andere LUT heruntergeladen (PictureFX-Kodachrome-1961-25-ASA-XPRD (siehe https://marcrphoto-wordpress-com.translate.goog/film-simulation/picturefx-pro-5-0/?_x_tr_sl=auto&_x_tr_tl=de&_x_tr_hl=de), was zu seltsamen Ergebnissen führt. Siehe

Nach einigem Ausprobieren habe ich festgestellt, dass man diese LUTs wohl anderes verwenden muss. Das Modul 3DLUT ersetzt Filmic RGB (so ist es auch der Default) und die Umsetzung in die Fuji-Farben (Provia: Farbkurve+Farb-Lookup-Tabelle) habe ich entfernt. So komme ich auch mit dieser LUT ab ein passables Ergebnis.

Hallo, lieber Besucher! Als Forumsmitglied (kostet nix) würdest du hier ein Bild sehen…

Einfach hier registrieren – Wir freuen uns immer über neue Mitglieder!