darktable nativ installiert oder in einer VM? In der VM ist es langsam.
Danke. Momentan VM (VMWare 7.1.3), da für eine erneute Dualboot Installation auf der OS SSD kaum Platz ist, dann läuft mir diese auch noch voll (vm liegt woanders). Am Wochenende schaff ich es zeitlich vielleicht ein bisschen aufzuräumen. Für die Bearbeitung, wofür ich Darktable auch schätze, da es Möglichkeiten bietet, die ich mir bei LR ewig wünschte, ohne zu wissen, dass ein anderes Tool diese bietet (ein Stichwort: Parameterisierte Maskierungen), läuft es in der VM auch recht flüssig, selbst das Entrauschen ist nicht langsamer als in LR. Nur als Verwaltungstool ists in der VM ein bisschen langsam, aber wie erwähnt, bin ich gerne bereit es erneut "nativ" zu testen.
Hölle, ich werd mich von RawTherapee verabschieden, wenn ich sehe, was aus Darktable geworden ist - auch wenn dieses erstmal nur aus der VM raus läuft aber dabei wirds mindestens bleiben
Zwei Fragen noch: Wie weise ich in Darktable einem Stichwort ein Übergeordnetes zu, damit es ein Stichwortbaum mit indirekten Stichwörtern wird (Beispiel ausLR:
klick )? Oder ist gar ein Stichwortgraph (meherere Übergeordnete Stichworte für indirekte Zuweisung bzw Vererbung) möglich?
Und: Wie bringe ich Darktable bei, beim Wechsel von Fotos in der 100% Ansicht auf die beim anderen Foto vorher ausgewählte Betrachtungsposition zu springen oder notfalls, falls das nicht geht, aufs aktive AF Feld?
Wozu braucht man im LR die DB oder Katalogfunktion? je mehr Fotos drinnen sind, umso langsamer wird die Sache. Ich hab mir angewöhnt, pro Serie einen Katalog anzulegen. ich hab mir meine Fotos so organisiert, dass ich Jahresordner habe. unter den jahrseordnern hab ich monatsordner. und in denen ist dann z.B. 2016-04-25 xxxx mein Thema. so kann ich die Themen wenigstens mal nach einen Namen suchen.
und dann bin ich auf DXO 11 gestossen. kein zwang einen Katalg anlegen zu müssen, einfach drauf los arbeiten.und man kann sich projekte anlegen, wird wahrscheinlich wie der katalog im lr sein. ich für mich bleib jetzt mal bei dxo
Zur Verwaltung ist ein Katalog/eine Datenbank sehr praktisch, dadurch sind Suchoperationen sehr schnell, es sind Aktualisierungen von aus Filtern bestehende Sammlungen in Echtzeit möglich und ich habe die Möglichkeit, die in der DB gespeicherten Sachen, wie z.B. Stichwortbäume und die Zuweisung derer zu Fotos in ein anderes DB getriebenes Tool zu exportieren (darf ich mir natürlich selbst programmieren, ist aber mit moderatem Aufwand problemlos möglich). Durch letzteren Grund muss man im "neuen" Tool nicht alles erneut machen.
Zusätzlich sind dadurch so manch andere Features möglich, wie z.B. das Speichern der Betrachtungsposition eines jeden einzelen Fotos im herangezoomten Zustand, sodass der Ausschnitt auf die richtige Stelle springt, sobald man erneut im eingezoomten Zustand die Fotos durchmistet - um nur einen weiteren Vorzug zu nennen. Dies bleibt auch nach Verschieben des Fotos bestehen.
Ferner interessieren mich außerhalb der DB befindlichen Mediendateien nicht - man hat also nur das zu Gesicht was man wirklich möchte.
Eine DB ist mir auch das liebste Speichermedium als Cache, denn das ist einfach schneller (bei der Verwaltung, bei Bearbeitung ists ******egal, da spielen andere Caches eine Rolle). Natürlich liegt LR keine höchstperformante DB zugrunde, die für jede Tabelle eigene Dateien anlegt und zusätzlich nochmal Indexdateien beinhalte, sondern handelt es sich um eine Ein-Datei-Datenbank namens SQLite. SQLite ist sehr robust, dafür nicht das schnellste. Jedoch bietet es Optimierungsmöglichkeiten, wodurch die DB neu sortiert wird, freigewordener Speicher auch wieder freigegeben wird und somit Performance wieder zurückgewonnen werden kann. Meine Erfahrung mit LR hat noch gezeigt, dass die Bearbeitungshistorie (Protokoll) unheimlich Speicher frisst und die DB langsam macht. Diese bei älteren Fotos, wo man nicht mehr jeden einzelnen Bearbeitungsschritt zurückspringen möchte, oder für verschiedene Versionen Snapshots oder virtuelle Kopien angelegt hat, zu löschen, bringt eine deutlich kleinere lrcat Datei (eine von drei SQLite DBs, die Anderen sind root-pixels und previews) und selbst mit 40k Photos eine Performance wie ein Katalog mit unter 10k Fotos. LR bietet von sich aus die Möglichkeiten zu dieser Optimierung - muss man nach der Bereinung natürlich anstoßen, ansonsten bleiben diese Altlasten in der DB.
Ein weiterer Flaschenhals sind die gecachten Previews (.lrprev - Dateien, welche nichts anderes als Bildpyramiden darstellen; Binärheader mit Strings, ein JSON String für die Auflösungsinformationen gefolgt von den einzelnen JPGs mit vorangehender Level Bezeichnung). Viele Operationen (neue hinzufügen, alte Löschen) sorgt auf HDDs gerne für Fragmentierung und somit zu Geschwindigkeitsverlust. Ne SSD wirtk hier wunder
Ist natürlich alles etwas Aufwand, aber man kanns schnell halten (1-2 Mal im Jahr die Bearbeitungshistorie aufräumen reicht bei mir).
DXO Optics Pro 9 hatte ich zur Erscheinung mal wegen Prime Denoise getestet (und hab es seitdem dies kürzlich kostenlos verteilt wurde wieder wegen dem Entrauscher). Doch cached dieses nicht die Vorschauen in der 1:1 Ansicht, wodurch es für die Verwaltung für meine Ansprüche leider zu langsam ist, da bei jedem hin/her Wechsel neu berechnet werden muss.
Wie gesagt, mein Hauptaugenmerk liegt auf eine flotte Verwaltungsmöglichkeit und hier gilt: (Vorschau-) Cache ist King.
Datum geht ebenfalls mit > und > Operatoren.
Deine beispielhafte Sammlung würde dann so aussehen:
Wie du deine Tierarten-Tags anordnest, bleibt ja dann dir überlassen.
Nochmal die Frage, wie sieht es mit relativen Zeiträumen aus? Das Datum immer per Hand nachzuziehen klingt wie letztes Jahrtausend
(nicht bös gemeint)