Hadmut Danisch

Ansichten eines Informatikers

Fotosoftware: Ich krieg Krämpfe…

Hadmut
13.5.2010 21:58

Das ist alles so grausig schlecht.

Ich versuche gerade – was heißt gerade, seit ich von der Reise zurück bin, und das ist fast zwei Monate her – eine ordentliche Software zum Verwalten von Fotos zu finden. Sie soll die Bilder organisieren, sortieren, verschlagworten, IPTC und XMP Daten verwalten, und grundlegende Bildbearbeitung (Ausschnitt, Drehen, Entflecken, Belichtung, Sättigung, Graduationskurven, Schärfen, Entrauschen,…) sowie verschiedene Exportwege unterstützen.

Das ist einfach grausam. Die meiste Software existiert allein deshalb, weil die meisten Berufsfotografen fatalistische anspruchslose Windowsklicker sind, die sich alles bieten lassen.

Zu den IPTC und XMP Problemen muß man aber sagen, daß das nicht (nur) an der Software liegt, sondern daß das alles so murksig und stümperhaft definiert ist, das man das gar nicht richtig implementieren kann. Es bleibt letztlich kaum etwas anderes übrig, als zum Adobe SDK zu greifen. Zwar gibt es Katalogweise Beschreibungen von Eigenschaften, aber es geht daraus nicht einmal hervor, ob es um XML-Attribute oder um XML-Elemente geht. Ich habe bisher noch keine Schema-Definition gefunden. Und die Felder heißen in der Benutzeroberfläche von jeder Software anders und werden überall anders interpretiert. Die eine Software liest nicht, was die andere schreibt, weil die eine eine Eigenschaft als Element haben will, die die andere als Attribut schreibt. Die eine will, daß die Eingaben in Sprachen durch |-Zeichen getrennt werden, während die andere Software das |-Zeichen abschneidet, weil sie damit das Sprachtag vom Text abtrennt.

Gipfel der Absurdität ist, daß es laut einer Agentur derzeit üblich geworden ist und verlangt wird, daß man trotz der vielen Feldtypen, die IPTC und XMP bieten, inzwischen alles, einfach alles, in das Caption-Feld schreibt und mit | trennt, weil es dann wenigstens jede Software anzeigt. Was gar nicht so einfach ist, denn das Caption-Feld heißt in jeder Software anders, weshalb man erst einmal ausprobieren muß, wo man das hinschreibt.

Und dann müssen alle Daten doppelt dastehen: In IPTC und in XMP, weil man nie weiß, ob die Software des Empfängers das eine oder das andere auswertet. Nur gibt es keine klare Zuordnung, welches IPTC-Feld welchem XMP-Feld entspricht. Und mit Zeichensätzen geht es sowieso drunter und drüber. Manchmal wird ASCII erwartet, und ob UTF-8 geht, ist unklar. Sowas schert natürlich die Amerikaner nicht. Und an dem Anrühren dieses großen undurchschaubaren Kuddelmuddels scheinen wirklich alle Softwareschreiber und Agenturen mitgerührt zu haben. Anscheinend ist aber Adobe der Hauptverursacher, weil eine – womöglich bewußt zum Zweck des Wettbewerbsvorteils – unklare Spec das Wuchern fördert.

Daß die Bildagenturen seit Jahren mit so einer Sch… arbeiten und das auch noch klaglos hinnehmen, zeigt, wie kaputt die Softwareszene ist und wie da gemurkst und gepfuscht wird.

Ich kriege echt Krämpfe wenn ich daran denke, wieviel wertvolle Zeit ich in den letzten zwei Monaten mit schlechter Software vergurkt habe, ohne produktiv voran zu kommen. (Und inzwischen wundert es mich auch nicht mehr, warum die Agentur will, daß ich das Zeug einfach alles in die Caption schreibe, warum so viele Fotografen darüber schimpfen, daß sie das jetzt alles selbst machen müssen, während sie früher nur die belichteten Filme abgegeben haben, und warum die Agenturen eigene Leute nur dafür einstellen.) Da hat die IT so richtig saftig versagt.

digikam (KDE)
Kann einiges ganz gut, vor allem die GPS-Datenverwaltung ist gut. Schlägt in vielen Bereichen alle mir bekannten kommerziellen Programme. Die Verwaltung von IPTC und XMP ist aber grauslich, mac Und obwohl verschiedene Alben unterstützt werden, kommen alle Daten in eine einzige große Datenbank, die immer weiter verfilzt. Je größer die Bildsammlung, desto länger braucht Digikam zum Starten. Man merkt sehr deutlich, daß die Entwickler nie mit einer nennenswerten Zahl von Bildern gearbeitet haben.

Die Export-Möglichkeiten sind auf die kipi-Plugins beschränkt. Einfach mal ein Skript reinhängen oder selbst ein Plugin schreiben ist nicht vorgesehen. Wenn man bei den Entwicklern anfragt, reagieren die distanziert bis pampig, wie man es wagen kann, etwas anderes zu wollen, als sie bereitstellen. Dabei liegt der Schwerpunkt der Plugins im Export in die verschiedenen Social Networks. Sie nehmen für sich in Anspruch, Bildverwaltung wie die Profis zu betreiben, legen den Schwerpunkt aber auf Hobby-Applikationen.

Am schlimmsten ist, daß digikam die RAW-Dateien meiner Nikon nicht brauchbar wandelt. Farbfalsch, unscharf, murks. Schlechte Bildqualität ist das absolute KO-Kriterium.

BibblePro 5
Kam mir bisher als die beste Lösung vor. Die Benutzeroberfläche ist passabel, obwohl die Funktionen für GPS komplett fehlen. Es gibt es für Windows und für Linux. Die Bildbearbeitungsmöglichkeiten sind jetzt nicht der Brüller, aber die Bildqualität ist OK, und Noise Ninja ist eingebaut. Einige Grundbearbeitungsfunktionen. Ein Stempel- oder Entfleckungstool fehlt, soll aber in der nächsten Version kommen. Wenn man die Denkweise dahinter mal begriffen hat, könnte man damit ganz gut arbeiten. Vor allem die Export-Funktionen sind gut.

Aber ich habe da in den letzten Tagen so viele Bugs gefunden, daß man damit nicht ernsthaft arbeiten kann. Die GUI hat manchen Bug. Das Drehen von Bildern kollidiert mit der Autograduation. Beim Schreiben von XMP gibt es einige Probleme. Das |-Zeichen kann man in manche Felder nicht eingeben. Alternative Felder für verschiedene Sprachen werden nicht unterstützt. Beil Schreiben von Presets gibt’s Probleme, weil sie die Zahl der Zeichen als Zahl der Bytes genommen haben und (Amis!) nicht daran gedacht haben, daß bei UTF-8 Zeichen auch mehr als ein Byte haben können.

Und jetzt stehe ich gerade vor dem Problem, daß das Ding immer langsamer wird und für manche Aktionen immer länger braucht, weil es offenbar Probleme mit der Datenbank gibt, und diese gewisse Attribute immer wieder in die Datenbank schreibt. Die Metadatenbank für meine Bangkok und Dubai-Bilder ist inzwischen 200 MB groß und enthält 1072831 mal das Wort Bangkok, obwohl ich dort nur etwa 600 Fotos gemacht habe.

Ich hatte das jetzt mal testweise installiert, aber ich bekomme damit keinen stabilen Arbeitsablauf hin. Für die meisten Bugs habe ich Workarounds gefunden, aber das Datenbankproblem ist ein Problem.

Adobe Lightroom
ist von der Benutzeroberfläche und der Bildverarbeitung ganz ordentlich. Die Export-Funktionen sind mir aber zu schwach. Und das Hauptproblem heißt: Windows. Meine ganze Nachbearbeitungskaskade läuft da nicht. Und es hat den Nachteil, daß ich es nicht unterwegs einsetzen kann, weil ich nicht so viele Windows-Lizenzen habe und auch unterwegs kein Windows mit mir rumschleppen will. Ich mag Windows nicht. Und dessen Lizenzmodell schon gar nicht. Und das Adobe-Lizenzmodell ist auch mehr als problematisch mit ihrer Aktivierung und Deaktivierung. Die halten einen systematisch davon ab, etwas bei ihnen zu kaufen.

Ärgerlich ist auch, daß Lightroom seinen Katalog nicht auf einem Netzwerkfolder ablegen kann. Immerhin: Es kann die Fotos vom Netz holen und in regelmäßigen Abständen einen Backup seiner Datenbank auf dem Netz ablegen, und sogar als SQLite-Datenbank. Insofern besteht Hoffnung, einen Windows-Crash oder eine Neuinstallation zu überleben. Trotzdem nicht ohne, denn so ganz windows-typisch unterscheiden sie Groß- und Kleinschreibung nicht und speichern in Kleinbuchstaben. Microsoft hat mit seinen Dateisystemen einen unglaublichen Murks angerührt (und beanspruchen darauf auch noch Patente).

Trotzdem bleibt das Problem, daß man nicht einfach mal eine Kopie der Software auf dem Netbook für unterwegs installieren kann, um unterwegs mal schnell was zu bearbeiten. Schon wegen des Lizenzgedudels.

Tröstlich immerhin, daß bei einer Umentscheidung von BibblePro5 auf Lightroom nur die Bildbearbeitungsarbeit, aber nicht alle Arbeit verloren wäre: B5 kann die Daten als separates XMP rausschreiben und Lightroom sie einlesen. Denn daß man das nicht einfach direkt in die RAW-Datei schreiben kann, hat nun wieder Nikon mit seinem proprietären Zeugs vermasselt.

Der Status ist: Nichts als Ärger und schon jede Menge Zeit verbraten. Ein Murks schlimmer als der andere. Und als Ursache würde ich ausmachen:

  • Propietäre und undokumentierte Daten- und Dateiformate und Eigenbrötlerei aus Konkurrenzdruck
  • Lizenzmodelle
  • Schlamperei und Willkür bei Datenfeldern
  • Fehlender Standard
  • Microsoft und Windows

5 Kommentare (RSS-Feed)

Thomas
13.5.2010 23:47
Kommentarlink

Die Lage ist in der Tat bestenfalls durchwachsen. Ich verwende seit Version 1 Lightroom und bin damit eigentlich recht zufrieden. Was mich allerdings total stört ist die Gewissheit nie wieder sinnvoll von dem Programm wegzukommen, da jegliche Bildbearbeitung in der Datenbank bzw. den XMP-Dateien steckt mit denen nur Adobe etwas sinnvolles anfangen kann.

Bezüglich des Lizenzgeraffels muss ich sagen, dass das bei Lightroom für Adobe-Verhältnisse relativ entspannt ist. Es gibt keine Aktivierung/Deaktivierung, die Lizenz ist für Windows und Mac und eine zweite Installation ist sogar offiziell erlaubt. Inoffziell gibt es auch keine Unterscheidung zwischen den Sprachversionen und es scheint einen auch technisch nix von beliebig vielen Installationen abzuhalten.

Thomas


Hadmut
13.5.2010 23:52
Kommentarlink

Ich bin bei Lightroom von Photoshop ausgegangen, wo sie vor einiger Zeit eine absolute Gängelung eingeführt haben. Man kann zweimal installieren, dann gibt’s Probleme, wenn man nicht vorher wieder deaktiviert hat. Was schwierig ist, wenn die Platte kaputtgeht. Früher oder später werden sie das auch bei Lightroom machen. Und wenn ich mir die sonstigen Probleme von mit Adobe (z. B. bei Flash, siehe http://www.golem.de/1005/75102.html ) ansehe sowie die Sicherheitsprobleme, die sie in PDF eingebaut haben, muß ich konstatieren, daß sich Adobe von einer Firma, von der ich (wegen Postscript, PDF und den Fonts) mal sehr viel gehalten habe, zu einer ganz üblen Chaos-Küche entwickelt hat.


Lawlita
14.5.2010 12:43
Kommentarlink

Schonmal F-Spot probiert?


Hadmut
14.5.2010 14:18
Kommentarlink

Ja, aber sofort wieder ausgespuckt. F-Spot ist ja ganz schlmm.

Erstens ist F-Spot etwas anderes, das dient nur zum Bilder-Importieren. Verwaltung, Bearbeitung von IPTC und XMP, Export, Katalogisierung, RAW-Konvertierung usw. sind da ja gar nicht vorhanden, das hat erst gar nicht diese Funktionen.

Zweitens ist F-Spot voller Bugs. Hat mir auf der Reise beim Import Bilder entweder abgeschnitten, sie ignoriert oder einfach mehrfach importiert, und laufend fiktive Fehlermeldung ausgegeben. F-Spot ist ein ziemlicher Murks.

Und drittens ist F-Spot ungeheuer langsam, was soweit ich erkennen kann auch damit zusammenhängt, daß das über irgendwelche Desktop-Schnittstellen geht.

F-Spot ist so eine von den Krankheiten wie Network-Manager, wo Leute, die eigentlich nur aus diesem Desktop-Umfeld kommen und auf diese neumodischen unausgegorenen Konzepte abfahren, in Bereichen wildern, in denen sie sich überhaupt nicht auskennen. NetworkManager ist eine Katastrophe was Netzwerkfragen angeht. Und ähnlich ist es mit F-spot was Fotographie angeht.


noomi
22.10.2010 18:57
Kommentarlink

Ja ich weiß, is schon etwas her aber auch ich suche immer noch..

f-spot verwaltet meine inzwischen etwas mehr als 16.000 Fotos recht zügig. Allerdings wunderte ich mich nach einem Update auf V 0.8.0 über die XMP-Dateien, die plötzlich zwischen den importierten Bildern herumliegen. Aha, scheint ein neues Feature zu sein, es ist nicht abschaltbar.
Ich bin aber kein Profi und brauche das nicht. Ich will *nur* Bilder verwalten, richtig herum drehen, taggen und sie ein bisschen anpassen, croppen, Helligkeit/Kontrast nachdrehen usw.
Verstehe ich nicht, die alte, aber echt oft abstürzende Version, die es aber nicht mehr in den Repos gibt, hat nur Bilder verwaltet und hat alle anderen Angaben dazu (geänderte Zeiten/Kommentare/Tags/Drehung usw.) in einer Datenbank gespeichert.
Wenn die neue Version jetzt für jeden Furz noch eine Datei zusätzlich anlegt, wozu dann die Datenbank?
Man könnte doch [träum!] den oben beschriebenen XMP-Wildwuchs etwas eindämmen indem man einfach diese Angaben weiterhin in eine DB stopft und die XMP-Files *erst bei Bedarf* und mittels eines möglicherweise funktionierenden/anpassbaren Exportmoduls erzeugt?
Ach was rede ich, ich bin ja kein Programmierer 🙂
Und ich werde mal ‘shotwell’ testen, soll sowas ähnliches sein..