Workflow - Dateihandling JPEG/RAW

Thread Status
Hello, There was no answer in this thread for more than 30 days.
It can take a long time to get an up-to-date response or contact with relevant users.
Hi,

mich nicht. Das ist ein Paradigma bei jeder Art der digitalen Archivierung. Wer sich damit beschäftigt, beschäftigt sich zwangsläufig mit der dauernden Migration.
Ich selbst habe schon auf Disketten (großen schwarzen und kleineren bunten), Zip-Disks, CDs, DVDs und Festplatten archiviert. Warum sollte sich das ändern?

Es war jetzt eher auf das ganz böse Erwachen bezogen ;)
 
Kommentar
Anzeigen
Einer der wenigen Nachteile, die ich bei der Verwendung von darktable bemerke: das Durchblättern und Aussortieren der jüngsten Bilder ist erbärmlich langsam, weil dt nicht das eingebettete JPG anzeigt, sondern jedes Bild sofort entwickelt/konvertiert.

Das Verhalten kann man in den Einstellungen (kleines Zahnrad) einstellen. Entweder wird ein eingebettetes bzw. erzeugtes Vorschau -JPG herangezogen, oder dt erzeugt die Vorschau aus dem Raw mit halber Größe. Das ist genauer aber langsamer. Bei der Einstellung muss man genauer lesen, da diese negiert angeboten wird.
Störender finde ich die fehlende 100% Ansicht auf dem Leuchttisch. Wenn ich allerdings im Vollbildmodus arbeite und dann noch mit TAB die Seitenleiste entferne und mir ein Bild anzeigen lasse, werden mir die Bilder groß genug für eine erste Beurteilung dargestellt.. STRG+z zeigt einen Rahmen als Overlay an, wo im Bild die Schärfe sitzt. So kann ich ohne merkliche Verzögerung mit Pfeiltasten oder Mausrad die Bilder durchscrollen und die Bilder, die mich zur Bearbeitung interessieren, mittels 1-5 Bewerten. Die Tastaturbelegung ist dankenswerterweise frei einstellbar.


Zum eigentlichen Thema:
Den eigentlichen Workflow gibt es nicht. Denn dieser hängt im wesentlichen an einigen Punkten
  • von der gewünschten Ausgabe
  • vom zu erwartenden Volumen
  • zur Verfügung stehende Hardware
  • zur Verfügung stehende Zeit
  • vorhandene Kenntnisse

Dabei dürfte die gewünschte Ausgabe neben dem Volumen wohl das entscheidenste Kriterium sein. Wer seine Bilder niemals über 800-1200px braucht, weil er vornehmlich auf sozialen Platformen seine Bilder verbreitet oder auf dem Tablet präsentiert, der kann u.U. bereits mit den Kamera JPGs und einem sehr rudimentären Workflow problemlos auskommen. Im krassen Gegensatz dazu steht der ambitionierte Hobbyfotograf, der sich auf B&W Fine Art Prints ab der Größe Din A2 auf verschiedenen Papiersorten spezialisiert hat. Alleine schon durch die erforderlichen unterschiedlichen Ausgabeformate (Proofings, z.B. unterschiedliche Schärfungen, Tonwertanpassungen, etc.) muss hier deutlich tiefer in die Materie eingestiegen werden.

Auch wird ein Sportfotograf, Pressefotograf, Eventfotograf andere Voraussetzungen haben, als der gemeine Urlaubsknipser mit seiner Kompaktkamera.

Mit den Unterschieden in der Hardware meine ich weniger schnelle oder langsame Rechner sondern vielmehr den Übergang auf das mobile Computing und den langsamen Wegfall der klassischen Desktops.

So sind Smartphones inzwischen der Standard-Fotoaparat in jeder Reisegruppe. An touristischen Hotspots werden inzwischen Selfie-Sticks den Touris feilgeboten. Wenn die Smartphones fotografisch noch etwas leistungsfähiger werden und sie einen etwas erweiterten Workflow ermöglichen, dann wird es zumindest für die Kompaktkameras ganz finster. Aber worin ist der Erfolg zu begründen:
a) das Smartphone ist ein Alltagsgegenstand der immer dabei ist
b) die Bedienung ist für nahezu jedermann nachvollziehbar
c) die Verwaltung der Medien wird schon z.T. auf dem Gerät erledigt.
Aber der einfache Ansatz über Mobilgeräte die Bilder zügig und ohne großen Aufwand in die entsprechenden Medien hochladen zu können, ist m.Mg.n. der Schlüssel für zukünftige Workflows. Die Technik ist vorhanden, die erforderliche Rechenleistung nähert sich auch an. Nur an die Handhabung, die Bentuzeroberfläche, da traut sich noch so richtig keiner aus dem Schneckenhaus.
Wenn man sich dann noch Canonicals und Microsofts Ansätze zum Mobile Computing anschaut (Stichwort Continuum), dann kann ich mir schon vorstellen, dass für viele Menschen zukünftig ein Desktoprechner überflüssig sein wird.

Der zeitliche Faktor ist immmer ein Streitpunkt. Ein gut eingestellter Raw Konverter wird nicht langsamer sein. Wenn aber gar keine Zeit für eine Nachbearbeitung zur Verfügung steht, man aber seine Kamera gut im Griff hat, dann kann man doch schon etwas Zeit sparen, wenn man mit den Kamera JPGS für seine Bedürfnisse weitest gehend zufrieden ist.

Wenn der TE tiefer einsteigen möchte und mit Englischer Sprache klarkommt, kann ich einen Blick in das "The DAM Book" von Peter Krough empfehlen. Dort wird ein sehr umfangreicher Workflow vorgestellt. Teile davon finden sich in meiner jetzigen Arbeitsweise immer noch wieder, andere Teile haben sich für mich als viel zu umfangreich für meine Bedürfnisse herausgestellt.

Woher kommt eigentlich diese Annahme, dass Dateiformate nicht mehr unterstützt werden sollen? Sobald eine Kamera von einer OpenSource Bibliothek unterstützt wird, ist der Drops m.E.n. gelutscht. Der Datensatz für die einzelne Kamera ist ja nicht riesig, daher kann ich mir, aber auch aus praktischen Gründen heraus, nicht vorstellen, dass Kameramodelle aus libraw oder dcraw entfernt werden. Im allerschlimmsten Fall muss halt ein anderer Konverter herhalten und das Bild neu entwickelt werden. Bei großen Bearbeitung meinerseits steht vmtl. ein TIF o.ä. oder zumindest ein JPG zusätzlich zum Raw zur Verfügung (oder kann kurzfristig hergestellt werden).
Spannender ist die Frage, wie mit zukünftigen verschiedenen Sensortechnologien umgegangen wird. Ich finde z.B. Sigmas Foveon Sensoren spannend, hätte aber unter Linux keine Unterstüzung und die Sigma eigene Software unter Windows/Mac ist wohl auch nicht jedermans Sache. Auch hat es relativ lange gedauert bevor Fujis Sensoren im großen Umfang Unterstützung fanden.


Mein eigener Workflow ist recht spartanisch:
  • Monitor mit dispcalgui und Spyder einmessen (zumindest alle paar Wochen)
  • Bilder mit rapid photo downloader in meine Verzeichnisstruktur laden. Meine Bilder liegen sortiert nach Y/MMDD_Ereignis in Unterverzeichnissen. In /Raw liegen halt die Originale, in /Web die verkleinerten Ausgaben in /Prints liegen Bilder die ich für die Ausbelichtung vorbereitet habe. Für mich ist in meiner Ordnung wichtig, dass ich alle Informationen zu einem Ereignis in einem Oberordner zusammengefasst habe. Dann kann ich auch andere Informationen wie z.B. GPS oder einfache Textdateien mit weiteren Informationen entsprechend mit einsortieren. Diese Vorgehensweise hat sich für mich als praktikabel erwiesen.
  • Bilder, die ich bearbeiten möchte, werden in darktable herausgesucht und bearbeitet. geeqie benutze ich eigentlich nur noch auf dem Notebook mit dem kleinen 11" Bildschirm. Der Hauptvorteil von geeqie ist vor allem, dass der Betrachter Colormanagement unterstüzt
  • mögliche weitere Bearbeitung als JPG in gimp, hugin, luminance hdr, etc.
  • Skript für die Verkleinerung auf Webgröße und Upload
  • Backup. Erst dann wird die Speicherkarte wieder zum beschreiben freigegeben. Habe ich wenig Zeit, mache ich das Backup direkt nach dem Kopieren der Bilder auf den Rechner, damit die Karte wieder freigegeben werden kann.

Über die Ordnernamen, rudimentäre Metadaten und weitere Informationen (z.B. txt Dateien) finde ich mich bisher recht gut ohne Datenbank zurecht. Mein Volumen ist aber sehr gering. Ich bin reiner Hobbyknipser mit häufig recht wenig Zeit fürs Hobby.

Jetzt reichts für heute
 
Kommentar
-Anzeige-
Zurück
Oben Unten