NikonPoint

Dirk-H hat geschrieben:Man nehme iView, ziehe die integrierten Fotobearbeitungsfunktionen ab, dann hat man ungefähr das, was ich gerade programmiere - allerdings mit einer (für mich) optimalen Benutzeroberfläche.

Baust Du auch so ein Kategoriensystem wie in IMatch ein? das würde ich nie mehr vermissen wollen...

Lars

@ Dirk: Ists denn noch auf Java-Basis?

David hat geschrieben:Java-Basis?

*schauder*

Lars

@Norbert
Ist noch im entstehen, wenn die erste Alphaversion kommt, stelle ich es einmal ausführlicher vor.

@David
Ja, ich bin Java-Entwickler.

@Lars
Was stört dich an Java?
Wie ist denn das Kategoriesystem von IMatch?

Dirk-H hat geschrieben: @Lars
Was stört dich an Java?
Wie ist denn das Kategoriesystem von IMatch?

Ich kenne keine Java-Applikation, deren empfundene Geschwindigkeit einer nativen Windows-Applikation gleichkommt. Es bleibt immer ein hakeliges Gefühl beim Arbeiten. Da ich oft recht zügig voranarbeite stört mich das meist gewaltig.

Kategorien in Imatch sind genial. Man kann einen Baum von Kategorien definieren (z.B. Ort/Europa/Deutschland/Aachen/Tierpark) und die Bilder zuordnen. Wenn ich Deutschland als Kategorie auswähle kommen natürlich auch alle Bilder der Unterkategorien.

Dazu gibt es "smart categories" die auf Formeln basieren, z.B. "alle Bilder die nicht der Kategorie Ort zugeordnet sind". Damit habe ich einen für mich ziemlich netten Workflow realisieren können.

Lars

LarsAC hat geschrieben: Ich kenne keine Java-Applikation, deren empfundene Geschwindigkeit einer nativen Windows-Applikation gleichkommt.

Ich kenne mehrere flott laufende Java-Applikationen und viele native die total hakelig sind. Das ist in erster Linie eine Frage sinnvollen Multitaskings.

Kategorien in Imatch sind genial. (...)

Klingt gut. Bei mir heißen zusammengestellte Bilder "Alben" und diese können auch Suchanfragen beinhalten. Damit ist das Prinzip schon mal da. An der Anordnung dieser Alben als Hierachie arbeite ich noch.
Was mich noch interessiert: Wie speichert IMatch die Kategorien? Sind das IPTC Daten oder zusätzliche Felder?

IMatch hat eine eigene Datenbank, die es dazu nutzt. Lad Dir doch mal die Demo runter, dann kannst Du damit rumspielen.

Man kann komplett eigene Sätze von Properties (also quasi das DB-Schema) definieren, die man den Bildern zuordnen kann. Dann kann man EXIF-, XMP- oder IPTC-Daten damit abgleichen in beliebige Richtungen, je nachdem was man halt für einen Arbeitsprozess hat. Es gibt auch scripte, die die Kategorien in IPTC-Categories oder -Keywords überführen.

Alles was in den Properties steckt kannst Du natürlich auch dynamisch zu Kategorien machen, z.B. Kategorien für Fotos bestimmter Brennweitenbereiche oder Kategorien für jedes Objektiv erstellen.

Ich werde nach meinem Urlaub mal die Doku für meinen IMatch-zentrierten Workflow vorstellen.

Lars

@Lars
Datenbank ist klar. Ich will den Nutzer etwas an die Hand nehmen und vermeiden, dass er "zusätzliche Datenfelder" für Sachen benutzt, die in IPTC sollten. Andererseits will man evtl. seinen Bilder Kommentare geben, die nicht raus an eine Bildagentur sollen. Da muss ich noch einen sinnvollen Kompromiß finden. Einfach nur alles zu ermöglichen und es dem Nutzer zu überlassen daraus einen sinnvollen Workflow zu machen, finde ich ein schlechtes (aber leider häufiges) Systemdesign. Dein Workflow würde mich daher sehr interessieren.

Was Iview bietet und in IMatch nur über Skripte realisierbar ist, ist eine automatische Kategorisierung nach Jahr, Monat und Tag.

D.h. für jedes Bild wird automatisch bei der Einbindung in die DB geschaut, ob es zu diesem Datum schon etwas gibt. Je nachdem wird dann das Bild entweder in die vorhandene Kategorie gesteckt, oder eine Neue erzeugt.

Man kann dadurch schön nach bestimmten zeitlichen Ereignissen blättern und sich durch einfachen klick ein komplettes Jahr, Monat oder Tag anschauen.
Das war eine Funktion, von der ich hoffte, daß sie im aktuellen Release von IMatch enthalten wäre. Nix wars

Dirk-H hat geschrieben: Einfach nur alles zu ermöglichen und es dem Nutzer zu überlassen daraus einen sinnvollen Workflow zu machen, finde ich ein schlechtes (aber leider häufiges) Systemdesign.

*Das* ist ein entscheidender Ansatz, den ich komplett für richtig halte. Es mag Grenzbereiche geben, bei welchen man sicher Freiheiten lassen muss. Aber diese komplett offenen Systeme sind mir zuwieder.... Eine Stufe weitergedacht kann man sich eigentlich gleich die DB selber programmieren....