Eigenes Programm zum RAW Datei Löschen wenn kein Jpeg mehr da ist

[Knipsaa]

Vielleicht die Möglichkeit einen Ordner samt Unterordner zu durchsuchen damit man mehrere Ordner gleichzeitig erledigen kann?

Klingt nach einer guten Idee. Aber auch nach einer gefährlichen. Da muss ich mir mal Gedanken zu machen. Da kommen dann solche Themen auf wie "wird alles in ein Ordner verschoben oder in die jeweiligen Unterordner" etc.

Zum Thema Komfort:

Drag&Drop wäre nett

Was soll den von wo nach wo drag&droped werden?

Mal eine andere Frage (aber nicht ganz OT) - müssen Dateien wie jpg auf dem Mac überhaupt eine Endung haben? Unter OS/2 war das nämlich nicht notwendig und irgendwie habe ich schwach im Hinterkopf, dass das beim Mac ähnlich war.

In Unix/Linux ist es kein Muss. Und selbst in Windows kann es ohne gehen (z.B. ältere ISO 9660 Dateisysteme auf CD).

Aber bevor nicht 10 Leute hier schreien, dass sie das Tool gerne verwenden würden aber immer alle RAWs und JPEGs ohne Dateiendungen schreiben, werde ich da nicht aktiv werden.

Das Tool basiert auf Dateiendungen und das ist auch gut so.

 

[Knipsaa]

Ich weiß, dass es theoretischer Natur ist, aber Du glaubst nicht, was User alles anstellen können...
Und der Job des Prorgammierers ist es, den DAU nicht ins Verderben rennen zulassen.

Klar. Deshalb habe ich es ja auch extra geändert. Nochmal Danke für den Hinweis.

Edit:
Verzeichnisse, die JPEG-Endungen enthalten bewerte ich trotzdem weiterhin als vorhandene JPEG Datei. Sicher ist sicher.

 

[DT5]

Verzeichnisse, die JPEG-Endungen enthalten bewerte ich trotzdem weiterhin als vorhandene JPEG Datei. Sicher ist sicher.

Das finde ich sogar gut, denn dann lässt sich das auch gut für den Fall missbrauchen, dass man mehrere JPGs für eine RAW erstellt.
Also in der Art
Bild.raw
Bild.jpg\jpg1.jpg
Bild.jpg\jpg2.jpg
Bild.jpg\jpg3.jpg

Bei Drag&Drop dachte ich daran, den Ordner-Namen in die Editbox 'reinzuwerfen'. Wobei ich mir nicht sicher bin, was in so einem Fall überhaupt ankommt - die Liste der Dateien im Unterordner oder nur der Ordnername.

Als ich das schrieb wusste ich auch noch nicht, dass Du Dir den letzten Dateipfad merkst. Da ich nicht mit dem Ordner 'Eigene Dateien' arbeite, ärgert es mich immer, wenn es Programme gibt, mit denen ich mich permanent aus diesem Ordner raushangeln muss.
Wo hinterlegst Du eigentlich die vorher benutzten Dateipfade? Oder merkt sich das Java?

Aber wenn ich schon beim Wünschen bin:
Per Parameter die beiden Ordner übergeben, somit kann man die Funktion per Command-Line starten.

 

[Brawler]

Klingt nach einer guten Idee. Aber auch nach einer gefährlichen. Da muss ich mir mal Gedanken zu machen. Da kommen dann solche Themen auf wie "wird alles in ein Ordner verschoben oder in die jeweiligen Unterordner" etc.

Ich bin für in den jeweiligen Unterordner. Ein Sammelordner macht meiner Meinung nach keinen Sinn, da kann man dann nicht mehr nachvollziehen welche RAW aus welchem Ordner stammt.
Edit: Oder ein Ordner im Überordner in dem dann die Struktur der Unterordner wieder abgelegt ist mit den jeweils verschobenen RAW-Dateien.

 

[Knipsaa]

Als ich das schrieb wusste ich auch noch nicht, dass Du Dir den letzten Dateipfad merkst. Da ich nicht mit dem Ordner 'Eigene Dateien' arbeite, ärgert es mich immer, wenn es Programme gibt, mit denen ich mich permanent aus diesem Ordner raushangeln muss.
Wo hinterlegst Du eigentlich die vorher benutzten Dateipfade? Oder merkt sich das Java?

Jo sowas hasse ich auch. Deshalb habe ich extra programmiert, dass sich der letzte Pfad gemerkt wird. Das gehört zum guten Ton der Usability und hat mich zusammen mit dem UI 90% der Programmierzeit gekostet. Man könnte auch darüber nachdenken einen konfigurierbaren Start-Ordner als default zu nehmen. Das passt manchmal sogar besser als beim zuletzt verwendeten Verzeichnis zu starten.

Den Pfad hinterlege ich in einer Konfigurationsdatei die ich im Verzeichnis [user.home]/RawMoveDel liegt. Bei Windows Usern dürfte das dann in „C:/Users/[DEIN_USER_NAME]/ RawMoveDel“ sein.

Drag&Drop kann manchmal vielleicht trotzdem nützlich sein. Mal sehen, vielleicht ist es ja total easy umzusetzen.

Aber wenn ich schon beim Wünschen bin:
Per Parameter die beiden Ordner übergeben, somit kann man die Funktion per Command-Line starten.

Da hatte ich auch schonmal dran gedacht. Sollte auch nicht aufwändig sein. Vielleicht fange ich ersteinmal nur mit dem verschieben an.

 

[DT5]

Den Pfad hinterlege ich in einer Konfigurationsdatei die ich im Verzeichnis [user.home]/RawMoveDel liegt. Bei Windows Usern dürfte das dann in „C:/Users/[DEIN_USER_NAME]/ RawMoveDel“ sein.

Auch wenn ich wieder einmal rummeckern muss - aber da gehört es auf jeden Fall nicht rein. Auf der Ebene hast Du nichts zu suchen, auch wenn Du dort einen Ordner anlegen kannst.

Eigentlich hast Du unter Windows nur 3 Optionen (registry lasse ich absichtlich außen vor)
1)
Local appdata:
den Ordner liefert dir Windows - musst mal nach CSIDL_LOCAL_APPDATA suchen.
2)
Zur Not im Roaming-Ordner, was aber für dieses Programm eigentlilch keinen Sinn macht.
3)
in dem Ordner, in dem die jar liegt, auch die Einstellungen hinterlegen.

Punkt 3 hat den Vorteil, dass nach dem Löschen des Programmordners auch alle anderen Hinterlassenschaften aus dem System entfernt werden
Hat aber den Nachteil, dass man in den Ordner nicht reinschreiben kann, falls jemand auf die Idee kommt, den Ordner ins Programmverzeichnis von Windows zu schreiben.
Weiterer Nachteil wäre, dass das nicht funktioniert, wenn man direkt aus dem Browser das Porgamm starten würde (was aber nicht angedacht ist und wegen der Zip auch nicht wirklich gehr) Parameter würden dann auch nicht mehr funktionieren.

 

[Knipsaa]

Auch wenn ich wieder einmal rummeckern muss - aber da gehört es auf jeden Fall nicht rein. Auf der Ebene hast Du nichts zu suchen, auch wenn Du dort einen Ordner anlegen kannst.

Rummeckern ist kein Problem (insbesondere wenn es fundiert ist wie bei dir). Für mich gibt es bei sowas kein Meckern sondern nur Verbesserungsvorschläge.

Auch wenn ich wieder einmal rummeckern muss - aber da gehört es auf jeden Fall nicht rein. Auf der Ebene hast Du nichts zu suchen, auch wenn Du dort einen Ordner anlegen kannst.
Eigentlich hast Du unter Windows nur 3 Optionen (registry lasse ich absichtlich außen vor)
1)
Local appdata:
den Ordner liefert dir Windows - musst mal nach CSIDL_LOCAL_APPDATA suchen.
2)
Zur Not im Roaming-Ordner, was aber für dieses Programm eigentlilch keinen Sinn macht.
3)
in dem Ordner, in dem die jar liegt, auch die Einstellungen hinterlegen.

Punkt 3 hat den Vorteil, dass nach dem Löschen des Programmordners auch alle anderen Hinterlassenschaften aus dem System entfernt werden
Hat aber den Nachteil, dass man in den Ordner nicht reinschreiben kann, falls jemand auf die Idee kommt, den Ordner ins Programmverzeichnis von Windows zu schreiben.
Weiterer Nachteil wäre, dass das nicht funktioniert, wenn man direkt aus dem Browser das Porgamm starten würde (was aber nicht angedacht ist und wegen der Zip auch nicht wirklich gehr) Parameter würden dann auch nicht mehr funktionieren.

Registry ist ein nogo.

Ich bin mit dem Ort der Datei auch nicht 100% glücklich und habe es mit low Prio auf meinem TODO Zettel stehen. Aber das ist für cross-Platform schwieriger als man glaubt.

1.) Funktioniert natürlich lediglich für Windows
2.) Auch nur Windows
3.) Hatte ich auch drüber nachgedacht. Aber die Nachteile hast du schon beschrieben. Zudem wären die gespeicherten Einstellungen immer weg, wenn man eine neue Version in einen neues Verzeichnis legt (es sei den man kopiert die Datei händisch).

Mac (Library/Application Support) verhält sich auch schon wieder anders als andere Unix-Derivate.

Ich bin nach einigen Sackgassen und wg. fehlender Testumgebungen erst einmal den Weg des geringsten Widerstandes gegangen. „user.home“ existiert in Java in jedem Betriebssystem.

Fazit:
Wer nicht mit einem neuen Verzeichnis und einer 10 Kilobyte Datei in seinem User Verzeichnis leben kann (z.B. Windows „C:/Users/[DEIN_USER_NAME]/RawMoveDel“) sollte mein Tool derzeit nicht verwenden.

 

[Knipsaa]

Funktioniert bei mir am Mac (10.10.2) nicht (ohne Fehlermeldung).

Da ich keinen Mac zum testen habe:

1. Was genau ist bei welcher Aktion die Fehlermeldung (oder startet es garnicht erst)? Wenn es nicht startet: hast du alle meine Anweisungen zum Starten auf Seite 1 befolgt? Was steht im Kommandozeilen-Fenster wenn du die letzte Variante des Startens benutzt?
2. Welche Version des Tools hast du verwendet (wie lautet der Name des jar files)?
3. Welche Java Version hast du installiert

User Tutor hat das nochmal genauer unter die Lupe genommen und folgendes herausgefunden:

Das RawMoveDel Programm funktioniert bei ihm am Mac nicht, wenn er es durch Doppelklick auf die jar-Datei gestartet wird. Das Programm startet zwar, aber das Verschieben funktioniert nicht. Da scheinen am Mac entweder Restriktionen zu herrschen oder Tutor hat irgendeine besondere Sicherheitseinstellung.

Wenn er das Programm jedoch über die Kommandozeile startet (siehe Post #1) funktioniert bei ihm alles wunderbar.

Das „.sh“ Start-Skript für Unix und Mac funktioniert derzeit wegen eines Fehlers nicht. User Tutor hat mir netterweise eine funktionierende Datei gegeben, die ich in das nächste Release mit einbauen werde. Dank an Tutor dafür!

 

[schubbser]

Hm....
So wie ich es verstanden habe achtet Dein Tool nur auf Dateinamen und Endungen. Und in diesem Zusammenhang gehst Du davon aus, dass gleiche Namen automatisch gleiches Bild bedeuten.

Es gibt durchaus Fälle wo zwei gleiche Namen ggf. nicht das gleiche Bild sind.

Idealerweise sollte hier zusätzlich das Dateidatum, bzw. Exif-Informationen verglichen werden und im Falle eines Abweichens eine Warnung kommen.

 

[Knipsaa]

Hm....
So wie ich es verstanden habe achtet Dein Tool nur auf Dateinamen und Endungen. Und in diesem Zusammenhang gehst Du davon aus, dass gleiche Namen automatisch gleiches Bild bedeuten.

Es gibt durchaus Fälle wo zwei gleiche Namen ggf. nicht das gleiche Bild sind.

Idealerweise sollte hier zusätzlich das Dateidatum, bzw. Exif-Informationen verglichen werden und im Falle eines Abweichens eine Warnung kommen.

Also bei mir bedeutet gleiche Namen in einem abgegrenzten Unterordner auch immer zusammenhängende Bilder. In welchen Fällen ist das bei dir denn nicht so?

Wenn das was du schreibst für einige ein echtes Problem darstellen sollte, kann ich mal gucken, ob/wann sich das umsetzen lässt. Wenn wir aber eher von einem theoretischen Problem reden würden ich die Zeit lieber in andere Verbesserungen stecken.

 

[DT5]

Idealerweise sollte hier zusätzlich das Dateidatum, bzw. Exif-Informationen verglichen werden und im Falle eines Abweichens eine Warnung kommen.

Das wollte ich auch schon schreiben - aber zum einen ist das schwierig bei fehlenden JPG. Gibt es überhaupt echtes exif bei Raw?
Schöner & einfacher wäre es, wenn man beim Löschen einer JPG gleich die RAW mitlöscht. Dazu muss man sich aber in die Löschroutinen einklinken, was man praktisch vergessen kann.

Dateidatum bringt nichts, da die RAW nach einer Änderung ein anderes Dateidatum als die Original-JPG haben kann. Und spätestens, wenn man die jpg gedreht hat, kann man das Datum vergessen.
Ich habe hier auch crw-Dateien, da sehe ich binär kein Datum - ist wohl alles gecrypted. Das erschwert die Analyse.

 

[schubbser]

....In welchen Fällen ist das bei dir denn nicht so?

Zumindest kann ich mich daran erinnern, dass ich aus dem Urlaub schon einmal mit "ungleichen Paaren" nach hause kam. Auslöser war Speichermangel in Verbindung mit dem Wechsel von Speicherkarten zwischen zwei Kameras.

Das wollte ich auch schon schreiben - aber zum einen ist das schwierig bei fehlenden JPG........

Das hatte ich mir auch gerade gedacht. Das JPG ist ja durch den Viewer gelöscht worden und erst später kommt das Tool des TO zum Einsatz.

Im Grunde ist das Programm wirklich nur für diejenigen geeignet die dauerhaft in RAW+JPG fotografieren. Ausserdem sollte der Nutzer das Programm auch nur innerhalb eines ersten "Importverzeichnisses" anwenden.

Die Gefahren lauern wirklich darin wenn das Programm ggf. auf Altbestände losgelassen wird. Um auszuschließen, dass bei falscher Anwendung was "passiert" ist der Benutzer eigentlich gezwungen ständig alle JPGs zusätzlich mit den RAWs zu speichern. Darauf muss der Benutzer auf jeden Fall hingewiesen werden.

 

[Knipsaa]

Die Gefahren lauern wirklich darin wenn das Programm ggf. auf Altbestände losgelassen wird. Um auszuschließen, dass bei falscher Anwendung was "passiert" ist der Benutzer eigentlich gezwungen ständig alle JPGs zusätzlich mit den RAWs zu speichern. Darauf muss der Benutzer auf jeden Fall hingewiesen werden.

Ich schreibe gerne soviele Warnungen wie nur irgend möglich, damit niemand durch Falschbenutzung Datenverlust erleidet.

Aber bei einem Tool, dessen einzige Aufgabe es ist "RAWs zu löschen wenn kein JPEG mit demselben Namen existiert" davor zu warnen, dass die RAWS tatsächlich gelöscht werden wenn keine entsprechend benamste JPEGs existieren erscheint mir dann doch fast etwas übertrieben.

Genau das ist doch die Aufgabe des Tools.

Aber im Zweifel hast du recht. Damit es noch klarer ist werde ich noch weitere Warnungen auf Seite 1 hinzuzufügen.

Edit:
Post #1 geändert

@schubbser:
Meinst du dass es jetzt Verständlicher ist, dass man das Tool nur auf Altbestände loslassen darf bei denen man sicher ist auch alle JPEGs zu haben?

 

[01af]

Re: Eigenes Programm zum Löschen von Rohdateien, wenn kein JPEG mehr da ist

Dateien mit der Endung .raw sind keine Rohdateien, sondern ein spezielles Photoshop-Format. Dein Programm sollte also von solchen Dateien die Finger lassen. Zum Glück sind sie extrem ungebräuchlich, so daß wohl kaum ein Anwender darüber stolpern wird ...

 

[Knipsaa]

AW: Re: Eigenes Programm zum Löschen von Rohdateien, wenn kein JPEG mehr da ist

Dateien mit der Endung .raw sind keine Rohdateien, sondern ein spezielles Photoshop-Format. Dein Programm sollte also von solchen Dateien die Finger lassen. Zum Glück sind sie extrem ungebräuchlich, so daß wohl kaum ein Anwender darüber stolpern wird ...

Danke für die Info.


Laut dieser Seite:
http://www.dateiendung.com/format/raw

ghört ".RAW" zu Panasonic, Leica und Casio .

Hmmm, jetzt bin ich mir unsicher, ob ich es drin lassen.

 

[01af]

Re: Eigenes Programm zum Löschen von Rohdateien, wenn kein JPEG mehr da ist

... gehört ".RAW" zu Panasonic, Leica und Casio.

Wenn das stimmt (was ich jetzt nicht überprüft habe), dann solltest du vielleicht eine vom Benutzer einstellbare Option vorsehen, mit der die Behandlung von .raw-Dateien als Rohdatei ein- und ausgeschaltet werden kann. Oder noch besser – es sollte jede Datei-Endung ein- oder ausschließbar sein.

 

[Knipsaa]

AW: Re: Eigenes Programm zum Löschen von Rohdateien, wenn kein JPEG mehr da ist

Wenn das stimmt (was ich jetzt nicht überprüft habe), dann solltest du vielleicht eine vom Benutzer einstellbare Option vorsehen, mit der die Behandlung von .raw-Dateien als Rohdatei ein- und ausgeschaltet werden kann. Oder noch besser – es sollte jede Datei-Endung ein- oder ausschließbar sein.

Jo, dass ist auf lange Sicht schon auf meinem ToDo Zettel (siehe #27).

Aber dann in der Form, dass User die Liste selber bestimmen können, um z.B. auch .dxo oder .xml Dateien zu verschieben.

 

[Knipsaa]

Die neuste Version 0.6.4beta kann hier heruntergeladen werden:
https://www.dropbox.com/s/yyhthsk7qs8juqr/raw-move-del-tool-064beta.zip?dl=0

Änderung:
Ich habe lediglich das neue "Unix_RawMoveDel.sh" Start-Skript für Mac/Linux/Unix von User Tutor eingebaut

Windows-Nutzer brauche sich die neue Version also nicht herunterladen.

 

[schubbser]

I.....
Meinst du dass es jetzt Verständlicher ist, dass man das Tool nur auf Altbestände loslassen darf bei denen man sicher ist auch alle JPEGs zu haben?

Verständlich ist es.

Ich will Deine Arbeit übrigens in keinster weise schlecht machen, sondern lediglich darauf hinweisen, dass man immer dran denken muss, dass der Benutzer sich, gerade in der heutigen Zeit, eigentlich durch nichts mehr durchliest und oftmals nur "blöd" irgendwelche Knöpfchen drückt und gar nicht damit rechnet, dass ein Programm etwas macht, das man nicht erwartet.

Theoretisch wäre es evtl. noch eine Option, dass Du entsprechende Dateien nicht löscht, sondern in einen programmeigenen Mülleimer (Verzeichnis) verschiebst und es dem Benutzer dann später selbst überlässt diesen, ggf. aus Deinem Programm heraus, zu löschen.

 

[DT5]

Theoretisch wäre es evtl. noch eine Option, dass Du entsprechende Dateien nicht löscht, sondern in einen programmeigenen Mülleimer (Verzeichnis) verschiebst und es dem Benutzer dann später selbst überlässt diesen, ggf. aus Deinem Programm heraus, zu löschen.

Das birngt mich auf die Idee, dass Du innerhalb des 'moved...' Ordners für jeden Löschvorgang einen neuen Ordner anlegst. Der Name dieses Ordners sollte aus Datum+Uhrzeit bestehen. Datum natürlich im engl. Format - also in einer Struktur wie "YYMMDD-hhmmss".
Und dann kann man eine Option anbieten, alle Ordner (und somit "gelöschten" - sprich verschobenen - Dateien), die älter als zum Beispiel 30 Tage sind, zu löschen.