geplantes Script zum Einfügen von Exif-Informationen

[m.s]

Hallo zusammen,

es ist ein Skript geplant, welches die Exifdaten wie Datum & Uhrzeit, Blende, Belichtungszeit usw. in vorhandene (gescannte) JPG-Bilder einfügen kann.
Meines Wissens gibt es noch kein ein solches Programm, was auch diese Infos einfügen kann. Daher sollte das Skript für Analogfotografen interessant werden.

Mein Frage nun an die (ehemaligen) Analogfotografen:

Welche Felder werden zusätzlich zu den Standardfeldern, wie Kommentar, Beschreibung und Copyright benötigt?

Ich liste mal die vom Skript unterstützten hier auf:
[ ] ImageDescription
[ ] Make
[ ] Model
[ ] Orientation
[ ] XResolution
[ ] YResolution
[ ] ResolutionUnit
[ ] Software
[ ] DateTime
[ ] DateTimeOriginal
[ ] DateTimeDigitized
[ ] Artist
[ ] Copyright1
[ ] Copyright2
[ ] UserComment
[ ] ExposureTime
[ ] FNumber
[ ] ExposureProgram
[ ] ISOSpeedRatings
[ ] ShutterSpeedValue
[ ] ApertureValue
[ ] BrightnessValue
[ ] ExposureBiasValue
[ ] MaxApertureValue
[ ] SubjectDistance
[ ] MeteringMode
[ ] LightSource
[ ] Flash
[ ] FocalLength
[ ] ExposureIndex
[ ] WhiteBalance

Bitte hakt die gewünschten Felder nach folgendem Schema an:

[ X ] DateTimeOriginal
[ X ] FNumber
[ X ] UserComment

Grüsse
Micha

 

[ralfeberle]

Hallo!

[ X ] ImageDescription
[ X ] Model
[ X ] Software
[ X ] DateTime
[ X ] DateTimeOriginal
[ X ] DateTimeDigitized
[ X ] Artist
[ X ] Copyright1
[ X ] Copyright2
[ X ] UserComment
[ X ] ExposureTime
[ X ] FNumber
[ X ] ISOSpeedRatings
[ X ] Flash
[ X ] FocalLength

Gruß,

Ralf

PS. Eine deutsche Übersetzung wäre gut!

 

[Hippo6]

[ X ] ImageDescription
[ X ] Model
[ X ] Software
[ X ] DateTime
[ X ] DateTimeOriginal
[ X ] DateTimeDigitized
[ X ] Artist
[ X ] Copyright1
[ X ] Copyright2
[ X ] UserComment
[ X ] ExposureTime
[ X ] FNumber
[ X ] ISOSpeedRatings
[ X ] Flash
[ X ] FocalLength

Danke, Ralf

@Micha
Gute Idee, dann hat mein Workaround mit den JN_Tools endlich ein Ende (für jedes Tag ein Script)
Naja, bin ehrlich und gebe zu, dass ich meist ACDSee dafür benutzt hab.

Du solltest vielleicht alle Tags anbieten und auswählen lassen (siehe CopyEXIF).
Auswahl und Vorbelegungen der Tags in die Registry (siehe Saver3)

Gruß und

 

[Jochen]

@Eike

Nix Registry ohne zwingenden Grund, einfaches XML- oder ein simples File mit selbstgemachten Tags im gleichen Verzeichnis wie das Script reicht für die lächerlichen paar Einträge vollkommen. Alles andere bringt nur Zoff mit sich. Das merkst Du spätestens dann, wenn Du den Rechner neu aufsetzen mußt und Deine Einstellungen weg sind. So kannst Du diese mit der Datensicherung zurückkopieren, und das war's dann.
Die Registry ist ein sterbendes Fossil. Selbst Microsoft hat mittlerweile eingesehen, daß dies die blödeste Idee war, die sie je hatten und baut das grauslige Ding gerade langsam wieder ab. Die kommenden DotNet-Projekte brauchen für die Installation nur noch kopiert zu werden, nur das Framework ist noch in der Registry zu finden.

@den zukünftigen Programmautor

Wie soll das Ganze laufen? Sinnvollerweise sollte das Eintragen der EXIF-Informationen als Speichern-Script eingetragen werden können, um direkt nach dem Scannen von Dia- oder Flachbettscanner (und nur hier macht das Script wirklich Sinn, an der "Fälschung" der Digitalbild-Informationen hat sicher kaum jemand Interesse) z.B. die Informationen eintragen zu können. Anderenfalls muß man die Bilder alle noch einmal vornehmen. Da aber nur ein "Post-Save"-Script eingetragen werden kann, wäre es doch sicher angebrachter, dies mit dem Saver-Script zu vereinigen.


Gruß Jochen

 

[hhoefling]

@den zukünftigen Programmautor
Wie soll das Ganze laufen?

Da ich der Autor sein werde, es sei den jemand anderes möchte dies übernehmen,
ist eine Zusammenarbeit mit dem Saver-Script vorgesehen.
Das neue Script wird als Sub-Script aufgerufen wenn:
1.) Saver.js einen leere Exifblock angelegt hat.
2.) Aus dem Hauptdialog heraus mit einem "Erweitert..." Button.



- Es soll eine INI Datei verwenden
- Es soll sich die zuletzt eingetragenen Werte merken, und wieder vorschlagen (Ini-File)
- Es soll auch direkt via Fx aufrufbar sein.,


EDIT:
Wobei Punkt 2 dann auch zum ändern schon vorhandener EXIF's zu verwenden ist.

 

[hhoefling]

Hallo
Hat jemand von den Scriptern eine Idee wie, mit FF Möglichkeiten , komportable eine Datum und Uhrzeiteingabe zu realisieren ist ?
Automatisch Tagesdatum ist kein Problem, aber wenn "frisch" gescannt wird, ist das Tagesdatum wohl nicht das Richtige.
Hat jemdand was besserers als 6 einzelne Zahlenfelder zur Eingabe von TMJ HM
(und die Plausibilitätsprüfung wird auch knapp ausfallen, wer den 29.2.2004 einträgt ist selbst schuld ;D )


@JKS was ist mit dem TimeDate-Control? Bis auf W95 haben das doch alle.

 

[Jochen]

ist eine Zusammenarbeit mit dem Saver-Script vorgesehen.

Sehr vernünftig. Ein Dialog-Gerippe hat Joachim ja schon ins Forum gestellt.

Das neue Script wird als Sub-Script aufgerufen

Weniger schön, aber bei dem js-Gewürge irgendwie nachvollziehbar. Mit vbs hätte man fein säuberlich eine eigene EXIF-Dialogklasse im Code unterbringen können....

Hat jemand von den Scriptern eine Idee wie, mit FF Möglichkeiten , komportable eine Datum und Uhrzeiteingabe zu realisieren ist ?

Reicht es nicht, nach dem FF_GetControl die Datumseingabe zu prüfen? FF-Controls mit Plausibilitätskontrolle gibt es ja nun mal nicht. Datum und Uhrzeit lassen sich doch leicht prüfen. Wenn Du es auf die harte Tour willst, versuche dich doch mal an regular expressions .

Gruß Jochen

 

[hhoefling]

Sehr vernünftig. Ein Dialog-Gerippe hat Joachim ja schon ins Forum gestellt.

Schon gesehen.....

Weniger schön, aber bei dem js-Gewürge irgendwie nachvollziehbar.

Ich denke da eher daran das diese für den Digtalfotografen nicht so sehr wichtig ist.
Das normale Saver.js soll "schlank" bleiben.

Datum und Uhrzeit lassen sich doch leicht prüfen. Wenn Du es auf die harte Tour willst, versuche dich doch mal an regular expressions .

Gib mir mal einem Tip wie ich die fantasievollen Eingaben der Benutzer schnell und einfach
abprüfe, und auch noch den 29.2.2004 abweise

z.B
1.1.2004 ok
1.1.04 ok
01.01.04 ok
01.01.2004 ok
11.11.2004 ok
21.11.2004 ok
11.21.2004 falsch
21112004 ok
21/11/2004 ok
21-11-2004 ok
2004-11-21 falsch oder ok oder was?
usw. etc.

Ich denke das DateTimePicker Control (analog zu COLOR und FONT) währe das Einfachste.

 

[Jochen]

Das normale Saver.js soll "schlank" bleiben.

Bliebe es trotzdem.

Gib mir mal einem Tip wie ich die fantasievollen Eingaben der Benutzer schnell und einfach
abprüfe, und auch noch den 29.2.2004 abweise

z.B
1.1.2004 ok
1.1.04 ok
01.01.04 ok
01.01.2004 ok
11.11.2004 ok
21.11.2004 ok
11.21.2004 falsch
21112004 ok
21/11/2004 ok
21-11-2004 ok
2004-11-21 falsch oder ok oder was?
usw. etc.

Nichts leichter als das. Per .split und Delimiter "." in Tabelle bringen.

Wenn UBound kleiner 3 -> Müll.
Wenn Tabelle(0) < 1 || > 31 -> Müll
Wenn Tabelle(1) < 1 || > 12 -> Müll
Wenn Tabelle(2) < 1800 oder was Du nehmen möchtest || > aktuelles Jahr -> Müll

Prüfen, ob Tagesangabe zum Monat passt. Brechstangenmethode: Vorher Prüftabelle tab(0) - tab(11) anlegen und mit Maximaltageswerten des jeweiligen Monats füllen, geht bei js bereits bei der Definition und dann dort gegenprüfen.

Das ist die ganze Datumsprüfung, mit der Du sämtliche Beispielfälle erwischst, eine Schaltjahrsroutine habe ich sicher noch irgendwo rumfliegen.

Ich denke das DateTimePicker Control (analog zu COLOR und FONT) währe das Einfachste.

Wirst Du aber nicht bekommen ...

Gruß Jochen

 

[hhoefling]

Wirst Du aber nicht bekommen ...

Wieso so sicher?
Wer braucht den eine Datumseingabe?
FF soll attraktiver werden, auch was für die "analogen" bieten,
also FF würde es gut zu Gesicht stehen wenn die Control's,
die von JKS zur Anzeige verwendet werden, auch als Eingabe-Control verfügbar wären.

Aber fangen wir erst mal mit Wasser an.....

 

[W.P.]

Hat jemand von den Scriptern eine Idee wie, mit FF Möglichkeiten , komportable eine Datum und Uhrzeiteingabe zu realisieren ist ?
Automatisch Tagesdatum ist kein Problem, aber wenn "frisch" gescannt wird, ist das Tagesdatum wohl nicht das Richtige.
Hat jemdand was besserers als 6 einzelne Zahlenfelder zur Eingabe von TMJ HM
(und die Plausibilitätsprüfung wird auch knapp ausfallen, wer den 29.2.2004 einträgt ist selbst schuld ;D )...

Schon mal mit den scriptingeigenen Funktionen probiert? Zumindest für VBScript weiß ich, daß bei expliziter Umwandlung in eine Date-Variable eine Plausibiltätsprüfung durchgeführt wird, mit Fehler falls was falsch ist. Außerdem gibt es Zusatzfunktionen wie DateSerial etc. Ich bin mir sicher, da gibt es auch was für JScript.
Warum den Kopf zerbrechen, wenn schon was da ist?

Schönen Gruß,

Werner.

---

Edit:
Das müsste wohl das richtige sein:

JScript - Date-Object:
var datestring = "November 1, 1997 10:15 AM";
Date.parse(datestring);

 

[Jochen]

@Werner

habe mich schon besorgt gefragt, wo Du bleibst .

Schon mal mit den scriptingeigenen Funktionen probiert? Zumindest für VBScript weiß ich, daß bei expliziter Umwandlung in eine Date-Variable eine Plausibiltätsprüfung durchgeführt wird,

21/11/2004
21-11-2004
2004-11-21

Wobei zu prüfen wäre, ob die Datumsfunktionen so etwas nicht anstandslos fressen. Wenn ja, ist es einfacher TT.MM.JJJJ oder alternativ TT.MM.JJ zu verlangen und alles andere abzuweisen, sonst hat man eine Menge Mehrarbeit, weil man intern sein Datum ja doch in einer definierten Form halten und dazu dann konvertieren müsste. Sieht nicht gut aus, wenn man eine der obigen Datumsformen bei der Eingabe akzeptiert, bei der Anzeige aber ein anderes Format zeigt. Oder soll man sich das eingegebene Datumsformat zwecks Verwendung bei der Ausgabe auch noch merken?

@ Heinz

Wieso so sicher?

Sieh es mal so:

Joachim baut anhand der FF_AddControls die Maske zusammen und übergibt sie mit FF_ShowDialog sozusagen komplett in Obhut des aufrufenden Scripts. Dann nickt er ein paar Milliarden CPU-Zyklen ein, bis ein Button geklickt wurde oder eines der anderen triggernden Controls und er wieder die Herrschaft über die Maske übernimmt. So lange "sieht" er nichts.
Die von ihm erst dann ausgelesenen Feldinhalte liefert er dann auf Anfrage über FF_GetControl beim Script ab.
Das ist der Grund, warum er keine Tasten wie ESC oder Default-Buttons erkennen und auch keine Plausibilitätskontrolle wie bei einem Datumsfeld vornehmen kann.
Eine denkbare Lösung wären Eingabe-Controls, die sich bei jedem eingegebenen Zeichen bei ihm zurückmelden, dann könnte er eine Prüfung vornehmen, dazu bräuchte es aber zusätzlich einen Feldtyp-Parameter und auch der Rest wäre nicht einfach zu lösen. Anschließend müsste im Eingabefeld nämlich wieder automatisch positioniert werden, ich bezweifle stark, daß Joachim im letzten "begangene" Control die letzte Cursorposition zu packen bekäme, im Script wäre es ebenfalls nicht möglich. Ergo: Das wird ohne größeren Aufwand nichts.

Joachim, korrigiere mich gerne, wenn ich falsch liege .

Gruß Jochen

 

[hhoefling]

Joachim, korrigiere mich gerne, wenn ich falsch liege .

Das mit der Dialog-Schleifen Logig ist mir klar.
Der DateTimePicker ist allerdings ein Standard Windows-Control (Seit W98SE soweit ich weis) aus der comctl32.dll, genauso wie STATIC EDIT COMBO etc. Da braucht Joachim eigentlich nicht viel zu tun. Wir brauchen lediglich zwei Ausprägungen des Controls mal als DATE mal als TIME.
Also JKS, wird die Liste der Controls erweitert? oder muss ich was Basteln?

 

[W.P.]

@Jochen

habe mich schon besorgt gefragt, wo Du bleibst .

Arbeiten natürlich

21/11/2004
21-11-2004
2004-11-21

Wobei zu prüfen wäre, ob die Datumsfunktionen so etwas nicht anstandslos fressen. Wenn ja, ist es einfacher TT.MM.JJJJ oder alternativ TT.MM.JJ zu verlangen und alles andere abzuweisen, sonst hat man eine Menge Mehrarbeit, weil man intern sein Datum ja doch in einer definierten Form halten und dazu dann konvertieren müsste.

Die Script-Datum-Zeit-Funktionen sind sehr tolerant und international. Kennst es ja von VB. Ausprobieren kannst Du die Toleranz ja mit ExifZeit im Script-Download-Bereich.

Sieht nicht gut aus, wenn man eine der obigen Datumsformen bei der Eingabe akzeptiert, bei der Anzeige aber ein anderes Format zeigt. Oder soll man sich das eingegebene Datumsformat zwecks Verwendung bei der Ausgabe auch noch merken?

Hier muß letztendlich immer in das Kameraformat (EXIF) konvertiert werden, und zwar von "Hand", da dieses spezielle Format nicht unterstützt wird. Kein Problem mit String-Funktionen.
Da erst mit verlassen des Dialogs die Eingabe geprüft werden kann, durch z. B. Konvertierung, spielt es keine Rolle. Ausgegeben sollte sowieso immer im gleichen Format. Das kann auch ein eingestelltes Windows-Standard-Datumsformat sein, dann ist man international auf der sicheren Seite (Einstellung in Systemsteuerung).
Wird Datum/Zeiteingabe jedoch nicht erkannt , sollte jedoch eine Meldung ausgegeben werden. Anschließend den Dialog einfach noch mal angezeigen, bzw. nicht zerstören, um den User die Möglichkeit zu geben, auf seinen Schmarn zu reagieren. Ich sehe hier kein Problem...

Schönen Gruß,

Werner.

 

[hhoefling]

Warum den Kopf zerbrechen, wenn schon was da ist?

Genau, dafür gib'ts den DateTimePicker 8)

EDIT:
ich meine diese:

nicht die Uhr, und den flächige Kalender (der kommt bei dem Button)

 

[JKS]

Sind die Sekunden überlebenswichtig?

 

[Stefan_G.]

Hallo Joachim,

Sind die Sekunden überlebenswichtig?

nö, für mich nicht. Habe ich schon immer aus den Exifs herausgelöscht, wenn ich sie veröffentlicht habe. Allerdings könnte danach sortiert werden (als Sortierkriterium kleiner als Minute). Aber dafür habe ich ja SortFix

Gruß
Stefan

 

[Jochen]

Da Du offensichtlich etwas bastelst, wäre ich doch für die Sekunden.
Wenn das Teil benutzt wird, um ein EXIF-Datum anzuzeigen und das aus der Form entnommene Datum wieder ins Bild eingefügt wird, dann fehlen anschliessend die Sekunden. Und damit die Möglichkeit, nach Aufnahmereihenfolge zu sortieren.

Gruß Jochen

 

[hhoefling]

Sind die Sekunden überlebenswichtig?

Ja, Exif möchte es als
"The format is "YYYY:MMD HH:MM:SS" with time shown in 24-hour format,"

 

[Niels1938]

Sekunden wäre ein Vorteil.

Grüsse,