Forum Übersicht - Digitale Fotografie » Wünsche für Kopiersoftware

Hallo.
Mich nervt es, das wenn ich mit der Dynax 5D bilder in RAW und JPG mache, die Bilder im selben Verzeichnis sind. Wenn ich mir die Bilder dann mit einem Thumbnail-Betrachter anschaue, dauert dann das darstellen der Bilder lange, da die RAW Bilder sich sehr langsam aufbauen.

Ich habe nun angefangen ein kleines Programm zu schreiben, das die CF-Karte findet und die Bilder auf der Karte in ein von mir gewünschtes Verzeichnis auf der Festplatte Kopiert. Sollten .MRW Bilder dabei sein, wird ein "RAW-Bilder" Unterverzeichnis angelegt und die Raw-Bilder dahinein Kopiert.

Auch wird das "Last Modified" Datum der Verzeichnisse auf der CF-Karte gelesen und die Unterverzeichnisse dementsprechen benannt. (z.B. 2006-01-11_14:31) oder so. Das wird man dann wählen können. Daduch kann man auch an einem Tag zwei verschiedene Session auf den Rechner Kopieren.

Wenn das Programm fertig ist, werde ich es natürlich zur verfügung stellen.

Meine Frage jetzt: Gibt sonst noch wünsche, die ich berücksichtigen sollte?
Oder ist das alles Käse und Ihr habt keinen bedarf an dem Kopierer?

Viele Grüsse

Tim

Zitat von holtiwilan

---

Ich habe nun angefangen ein kleines Programm zu schreiben, das die CF-Karte findet und die Bilder auf der Karte in ein von mir gewünschtes Verzeichnis auf der Festplatte Kopiert. Sollten .MRW Bilder dabei sein, wird ein "RAW-Bilder" Unterverzeichnis angelegt und die Raw-Bilder dahinein Kopiert.

Auch wird das "Last Modified" Datum der Verzeichnisse auf der CF-Karte gelesen und die Unterverzeichnisse dementsprechen benannt. (z.B. 2006-01-11_14:31) oder so. Das wird man dann wählen können. Daduch kann man auch an einem Tag zwei verschiedene Session auf den Rechner Kopieren.

---

Ich weiß nicht, unter welchem System Du arbeitest, aber generell würde ich Dir
empfehlen, nicht ohne zwingenden Grund von klassischen 8.3-Dateinamen
abzuweichen - sowas rächt sich oft später durch unnötige Kompatibilitäts-
und mitunter auch Stabilitätsprobleme. Ich benenne z.B. auch viele meiner
Verzeichnisse nach dem jeweiligen Datum - ein Name wie "20060111"
(also ohne Separator) paßt aber noch wunderbar ins 8.3-Format, ist leicht
zu lesen und immer noch voll mit ISO 8601 / DIN EN 28601 konform.

Das Zeichen ':' ist hingegen unter etlichen Systemen kritisch, da es zwar
als Zeichen eines langen Dateinamen unter Windows "geduldet" wird, auf
Systemebene aber eigentlich ein für andere Zwecke reserviertes Zeichen
ist - also besser gar nicht erst verwenden, wenn Du Deine Medien auch mal
unter Fremdsystemen lesen oder in einem heterogenen Netzwerk verwenden
möchtest. Es besteht bei der Verwendung solcher Zeichen grundsätzlich immer
die Gefahr, daß es irgendwann einmal nicht mehr funktioniert, oder Du nur
mit Klimmzügen an Deine Dateien herankommst.
Selbst das '_' ist nicht universell gültig. Wenn Du z.B. ISO 9660-konforme
CD-Images Deiner Dateien brennen willst, solltest Du darauf verzichten.
Häufig wird es durch das unproblematische '-' (Hyphen) substituiert.
Aber eigentlich kann man auf die Separatoren auch gleich ganz verzichten,
sie machen die spätere automatische Auswertung nur aufwendiger.

Übrigens: Auch schon unter DOS kann ein Verzeichnis eine Erweiterung
haben. Nur auf ISO 9660-CDs ist das nicht erlaubt. Die dreistellige Extension
könntest Du noch verwenden, um eine laufende Nummer, z.B. die Stunde zu
kodieren. Mit ein paar Tricks kannst Du auch die komplette Uhrzeit darin
unterbringen, allerdings ist es dann nicht mehr so schön lesbar. Aber
vielleicht täte es ja auch eine laufende Nummer - ich benutze die Extension
z.B. oft zur Darstellung der Versionsnummer, z.B. \DRDOS.708\

Und noch ein Tip eher genereller Art: Für solche kleinen Problemstellungen
braucht man normalerweise keine Programme zu schreiben, das kann auch
schon ein kleiner Batchjob erledigen. Das geht zwar auch mit CMD/COMMAND,
so richtig Spaß macht es aber erst mit einem komfortablen Kommando-
zeilenprozessor wie den extrem leistungsfähigen, dabei aber nach wie vor
rückwärtskompatiblen Shells von JP Software, siehe http://www.jpsoft.com
Für Windows NT/2000/XP gibt's 4NT und TakeCommand32, für DOS und
Windows 9x gibt's 4DOS (Freeware) und TakeCommand16, für OS/2 gab's
4OS2, eine Linux-Version ist ebenfalls geplant... (Aber unter Unix gibt es
sowieso Shells ohne Ende ;-)

Viele Grüße,

Matthias

Ich mache das Ganze einfach mit dem Explorer!

Zitat von erich_k

---

Ich mache das Ganze einfach mit dem Explorer!

---

Naja, ich denke, Tim möchte diese nach einem wohldefinierten Schema
auflaufende Tätigkeit nicht immer wieder auf's Neue manuell durchführen.

Sowas schreit ja förmlich nach irgendeiner Form von Programmierung -
dann hast Du *einmal* etwas mehr Aufwand, weil Du über das Problem
genau nachdenken mußt, und danach läuft es automatisch ab, und Du
mußt Dir nie wieder Gedanken darüber machen. Spart Zeit und vermeidet
Fehler, die bei manueller Vorgehensweise immer mal wieder passieren...

Mein Punkt war nur, daß man für ein solch einfaches Problem normalerweise
nicht gleich zum Compiler greift. Gerade solche dateibezogenen Operationen
lassen sich sehr gut mit minimalem Aufwand als Stapeldatei (Batchjob) lösen.

Viele Grüße,

Matthias

@Matthias
Ich denke, das 8.3-Format kannst du langsam vergessen! Dieses Format behindert mehr als jemanden bringt. Darum denke ich, dass Tim's Idee nicht schlecht ist, aber es braucht noch eins, zwei Korrekturen.

@holtiwilan
Ich kann Problemlos mehrere Session von einem Tag ins gleichen Verzeichnis speichern. Meine Nummerierung steht jetzt knapp bei 8000. An der Kamera muss die Option BildNr speich auf Ein sein (Blaue Symbol -> 2 -> 1. Punkt)
Darum habe ich meine Verzeichnungen Tagesweise organisiert, zwar 2006-01-11, aber keinen Unterscheidung, ob jetzt MRW oder JPG ist, zudem verwende ich den ACDSee Pro (8.0). Dieser ist sehr flott beim Aufbauen der Thumbnails und beim Blättern, auch beim Transfer unterstütz er mich sehr stark, in dem er mir schon das Verzeichnis vorschlägt.

Darum schau Dir zuerst das ACDSee Pro mal an, bevor du dich in die Programmierung stürzst.

Gruss
Peter

Zitat von Peter Lehner

---

Ich denke, das 8.3-Format kannst du langsam vergessen! Dieses Format behindert mehr als jemanden bringt. Darum denke ich, dass Tim's Idee nicht schlecht ist, aber es braucht noch eins, zwei Korrekturen.

---

Das sehe ich etwas anders. Solange Du nur mit einer Plattform zu tun hast,
die schon immer und nativ lange Dateinamen unterstützt, gibt es natürlich
überhaupt keine Probleme. Aber in der Praxis ergibt sich ja häufig das Problem,
daß man Dateien zwischen verschiedenen Systemwelten und Dateisystemen
hin- und herbefördern muß oder in einem möglicherweise heterogenen
Netzwerk ablegen möchte. Da gibt es dann immer wieder Schwierigkeiten,
wenn unterschiedliche Systeme unterschiedliche Namenslängen und
Zeichensätze zulassen, die man dann on-the-fly konvertieren muß,
was leider nicht immer ohne Konflikte gelingt.

Und wenn gar noch eine Plattform ins Spiel kommt, bei der lange Dateinamen nur
als "Aliasnamen" für die kurzen Dateinamen entsprechend der 8.3-Konvention
realisiert sind, ist das potentielle Chaos nicht mehr weit. Dazu zählen u.a. - aber
nicht ausschließlich - sämtliche Systeme, die lange Dateinamen auf FAT-Partitionen
abbilden. Windows benutzt z.B. sehr abenteuerliche Methoden, um einen langen
Dateinamen an eine Datei mit einem kurzen Namen zu heften.
Aufgrund der Methode, wie lange Dateinamen für alte Systeme "unsichtbar"
im FAT-Format untergebracht werden, kommt es in der Praxis immer wieder
mal vor, daß "plötzlich" eine ganz andere Datei mit einem langen Dateinamen
assoziiert wird, als die, zu der er eigentlich gehörte. Die Ursachen dafür sind
vielfältig, aber systemimmanent aufgrund von fundamentalen Fehlern im Design.
Auch kommt es immer wieder vor, daß unter bestimmten Bedingungen die langen
Dateinamen verloren gehen, und der Benutzer nur noch über die kurzen Namen
auf die Dateien zugreifen kann - schön, wenn die dann aussagekräftige Namen
wie "20060112" haben und nicht "200~1498".
Windows arbeitet da zum Teil mit heuristischen Methoden, in etwa nach dem
Motto, "wahrscheinlich war es jetzt diese Datei hier, zu der dieser lange
Dateiname gehört, also nehme ich die mal". Ich will jetzt nicht allzusehr in
Details gehen (bei Bedarf privat gerne mehr), aber als wir damals VFAT-
kompatible lange Dateinamen für DR-DOS implementiert haben, mußten wir
die LFNs auch noch mit DR-DOS' Löschverfolgung DELWATCH und dem unter
DR-DOS traditionell verfügbaren Zugriffsschutz (mit datei- und verzeichnis-
basierten Paßwörtern, Read/Write/Delete/Execute-Accessrights und
World/Group/Owner-IDs) unter einen Hut bringen, wofür wir auch selbst
schweren Herzens auf einige heuristische Methoden ausweichen mußten,
anhand derer der Kernel zu erkennen versucht, mit was für einer Sorte von
Verzeichniseintrag er es gerade zu tun hat. Freundlicherweise hatte Microsoft
für lange Dateinamen nämlich den gleichen Trick mit dem Volume-Attribute
aufgegriffen, mit dem Digital Research/Novell schon lange vorher Informationen
unsichtbar für den Benutzer im FAT-Dateisystem gespeichert hat. Besonders
erquicklich daran war noch, daß sie sich genau diese Methode auch noch haben
patentieren lassen, ohne in der Patentschrift diese prior art zu erwähnen...
Aber von dieser konfliktträchtigen Mehrfachnutzung mal abgesehen, ist mir
beim Studium der offiziellen VFAT-Spec das kalte Grausen gekommen, enthält
sie doch direkt mehrere grundsätzliche und damit leider auch nicht korrigierbare
Designfehler, die Microsoft in ihrer Implementation durch verschiedene Ansätze
auf höherer Ebene zu kaschieren versucht hat. Statt die Sache direkt richtig bis
zu Ende zu durchdenken, denn mit gleichem Implementationsaufwand wäre
auch ein absolut sicheres und obendrein noch vollständig mit allen FAT-Systemen
kompatibles Design möglich gewesen... :-(

Was ich sagen will, auch wenn das in der Praxis in der Regel funktioniert,
man kann sich auf einem FAT-Volume nicht darauf verlassen, daß ein langer
Dateiname wirklich immer auf die richtige Datei zeigt und zweitens, daß er
nicht unter bestimmten Bedingungen auch ganz verloren gehen kann.
Deshalb empfehle ich immer, auch auf Systemen, die lange Dateinamen
unterstützen, solche zu wählen, die ins 8.3-Format passen würden - zumindest
solange nicht zwingend etwas dagegen spricht.

Das native CD-Dateisystem (ISO 9660) ist sogar noch deutlich restriktiver
als FAT, was die erlaubten Zeichen, die Tiefe der Verzeichnisse und die
Namenskonventionen für Unterverzeichnisse angeht. Natürlich ist es möglich,
die langen Dateinamen für den Benutzer transparent als Meta-Informationen
(Rockridge, Joliet) zu speichern, aber das funktioniert eben auch nur solange
gut, wie es funktioniert. ;-)

Solange Tim seine Dateien nur auf z.B. NTFS kopiert, nur Programme einsetzt,
die mit langen Dateinamen zurechtkommen und auch später nie wieder in die
Verlegenheit kommt, auf FAT- oder ISO-basierte Systeme umkopieren zu
müssen, braucht er sich über sowas natürlich keine Gedanken machen.

Viele Grüße,

Matthias

Zitat von erich_k

---

Ich mache das Ganze einfach mit dem Explorer!

---

Un wenn man keinen Explorer hat automatisier man sich das Ganze mit einer Ordneraktion;-)

Ich mach das momentan auch noch manuell, werde mir da aber irgendwann auch ein AppleScript basteln.


Zum Zeichen ":" im Dateinamen: Ist unter MacOS tabu, weil als Pfadtrenner eingesetzt wie der Backslash bei Windows.

Also.
Ich habe mal was "gebastelt".
Zum einen kann man die Bilder der CF-Card in ein Verzeichnis auf der Festplatte Kopieren. Die RAW Dateien automatisch in ein separates Verzeichnis schieben lassen und das Datum des letzten Bildes in dem Quellverzeichnis als Verzeichnisnamen für die lokale sicherung verwenden.

Dann habe ich noch ein Modul eingebaut, das JPG Bilder schnell und einfach auf die erforderlichen Werte für die Galerie setzt und unter neuem Namen speichert.

Schaut es euch einfach mal an.

KoMi-Toolsuite

Achja. Es ist ein in Java Programmiertes Programm. Sollte aber auf den meinsten Rechnern laufen. Zumindest wird bei Windows XP Java installiert sein.

Wenn noch fragen, wünsche oder anregungen vorhanden sind, nehme ich die gerne an.

Viele Grüße

Tim