Exif bzw. IPTC

[wp_xyz]

GITHUB: Daten sind in WP_XYZ_Version eingepflegt.

Damit wir uns richtig verstehen: Meine Änderungen haben auf wip-samples aufgebaut, wo alle Versionen vereinigt sind. Daher sollten sie eigentlich nach wip-samples.

[wp_xyz]

Ich habe mir jetzt die Tests angesehen. Genau, so ähnlich würde ich das auch machen. TstImgDataCanProcessFile liefert einen Fail bei der Datei mit der Endnummer 02, aber diese enthält lt den mir verfügbaren Programmen (IrfanView, Serif PhotoPlus 7, ExifTool* ) weder EXIF noch IPTC Daten, daher müsste hier m.E. auf CheckFalse geprüft werden.

(*) ExifTool zeigt bei Datei DUTPic02.jpeg zwar Daten an, jedoch erscheinen mir diese allgemeine JPEG-Parameter zu sein.
In der Anlage schicke ich den Output von ExifTool für beide Dateien. Ich will einen Testcase schreiben, der die gezeigten Parameter abfragt und vergleicht.

[Christian]

Ja hab deinen Fork ja auch gemergt damit alles wieder auf nem Stand ist...

[MitjaStachowiak]

Ich denke, ich kann die Tage etwas Zeit abzweigen und meinen Teil ordentlich überarbeiten.

Mitja, in "TImageInfo.Readcomments", im else-Zweig von "if pos('ASCII', p^.Row) = 1", [...]

Ja, richtig wäre hier glaube ich setLength(w, (Length(p^.Raw)-10) div 2); Der Fehler fällt aber erst mal nicht auf, da nur zuviel Speicher reserviert und ausgegeben wird. Jetzt weiß ich endlich, warum manchmal irgendwelche Kryptischen Zeichen ans Ende der Texte gehängt wurden

Werde mal mein Git wieder anwerfen.

[wp_xyz]

Andreas, in der Anlage nun meine Test-Unit - alles grün!. Damit alle Tags gefunden wurden, waren ein paar Änderungen an den dEXIF-Units nötig. Die Dateien bauen auf den vorher geschickten Versionen auf.

[MitjaStachowiak]

So: https://github.com/mitjastachowiak
Wenn ihr mir Zugriff gebt, werde ich die Tage etwas mithelfen...

[af0815]

@Mitja Achtung du hast Schreibzugriff auf afriess/dexif , wenn du die Anfrage bestätigst.

Meine Vorgangsweise jetzt:

*) Tests in den Master-Zweig
*) Doku in den Master-Zweig
*) Integriere dann die Änderungen in den master wenn die Tests Ok sind.

Generell stellen sich mir schon ein paar (viele) Fragen:

a) Richtiger Lazarus Fork, dann aber mit anderen Namen Bsp. -> LaxEXIF
b) Wenn nicht, wer kontrolliert gegen Delphi und vor allen gegen welche Versionen ?
c) Zu welcher Lazarus Version soll das das kompatibel bleiben ?
...

Diskussion dazu würde natürlich auch Offline/Skype4B/VOIP/ ... gehen.

Andreas

[wp_xyz]

a) Richtiger Lazarus Fork, dann aber mit anderen Namen Bsp. -> LaxEXIF

ja, sehr gut!

b) Wenn nicht, wer kontrolliert gegen Delphi und vor allen gegen welche Versionen ?

Wenn wir den Fork schon LazEXIF nennen, könnten wir genauso gut Delphi rausnehmen
- weniger hässliche IFDEFs
- Verwendung der FPC-Funktionen für Big-Endian-Umwandlung
Dadurch würde der Code schon ein Stück lesbarer!

c) Zu welcher Lazarus Version soll das das kompatibel bleiben ?

Möglichst weit zurück, mindestens Laz 1.4.4/fpc 2.6.4. In der Linux-Welt haben sie oft uralte Versionen. Das heißt, all der neumoderne Schnickschnack muss draußen bleiben.

Folgende Wünsche von mir:
Wenn der Code einmal halbwegs stabil ist, müsste sich einer die Mühe machen, das Durcheinander von Methoden, die von der Logik her private oder protected sein sollten, im public-Abschnitt aufzuräumen und richtige Properties anstatt der eingefügten öffentlichen Objekt-Felder einzuführen (ich habe in der heute verschickten Version mit Properties Height und Width etc angefangen - man hat dadurch einfach viel mehr Möglichkeiten). Außerdem würde ich mir einen weitgehend einheitlichen Codierstil wünschen, Einrückungen kreuz und quer und unsystematische Groß/Kleinschreibung machen einem die Arbeit in dem nicht ganz einfachen Code unnötig schwer.

[af0815]

GITHUB:
a) Alle Zweige merged und dann entfernt und den Letztstand in den master gebracht.
b) Die Doku auf den Letztstand gebracht

Bitte vom jetzigen master wegarbeiten.

@wp_xyz: Es ist definitionssache wie ProcessFile Rückmeldung geben soll, aktuell ist:
Reads the file and and set the EXIF or IPTC information
true = file is readable and is a valid format eg. jpg or tiff act.
false = file is not readable or an not supported type or has no metadata

das ist das, was ich davon aus dem Code verstanden habe und wenn ich mir die Beispiele vom original Author ansehe. Diese definition ist nachvollziehbar, weil wenn die Datei nicht auswertbar ist, warum sollte ich dann weitermachen. Die grundlegende Frage ist, ob man das mit den Metadaten hier schon abfrägt oder nicht. Deswegen schlägt der Test bei der Datei OHNE EXIF aktuell fehl.

Vor allen denke ich daran, wenn es support für das Schreiben gibt, ob man da nicht die definition etwas ändern sollte.

Andreas

[af0815]

Folgende Wünsche von mir:
Wenn der Code einmal halbwegs stabil ist, müsste sich einer die Mühe machen, das Durcheinander von Methoden, die von der Logik her private oder protected sein sollten, im public-Abschnitt aufzuräumen und richtige Properties anstatt der eingefügten öffentlichen Objekt-Felder einzuführen (ich habe in der heute verschickten Version mit Properties Height und Width etc angefangen - man hat dadurch einfach viel mehr Möglichkeiten). Außerdem würde ich mir einen weitgehend einheitlichen Codierstil wünschen, Einrückungen kreuz und quer und unsystematische Groß/Kleinschreibung machen einem die Arbeit in dem nicht ganz einfachen Code unnötig schwer.

Ich habe das versucht, nur beim gegenprüfen mit den originalen Demos, habe ich gesehen, das der auf alles von aussen zugreift

Die Frage nach dem Codierstil, hehe ist so alt wie das Thema Pascal<->C, auf was wollen wir uns einigen ?

Andreas

BTW: wp_xyz hast du einen Github-Account (ev. per PN/Mail) ?

[wp_xyz]

Nein, einen GitHub-Account habe ich nicht. Mal sehen, muss mich erst einarbeiten... Aber ohne, wird es problematisch, ich habe eben gesehen, dass von meinen geschickten Dateien so gut wie nichts im Master angekommen ist...

[af0815]

Nein, einen GitHub-Account habe ich nicht. Mal sehen, muss mich erst einarbeiten... Aber ohne, wird es problematisch, ich habe eben gesehen, dass von meinen geschickten Dateien so gut wie nichts im Master angekommen ist...

Oops, muss ich nochmals kontrollieren.

Edit: Sorry, doppelt gemoppelt gewesen, beim einspielen der Kommentare, ist nicht die richtige Version hinzugekommen und hat die Änderungen von dir überbügelt. Sollte jetzt nicht mehr vorkommen, nachdem alle Versionen jetzt bei einander sein sollten.

Andreas

[af0815]

Test mit Lazarus 1.4.4 r55637 FPC 2.6.4 i386-win32-win32/win64 gehen nicht. Das lässt sich schon mal nicht kompilieren. TFPReaderJpeg.ImageSize gabs damals noch nicht.

Die Frage ist nur, was für IFDEFS sind dann sinnvoll.

Andreas

[MitjaStachowiak]

Ich bin auch kein Fan von GIT, aber irgendwie komme ich damit inzwischen klar..

Wollen wir morgen Abend mal telefonieren? Habe vormittags 'ne Klausur aber abends sollte gehen.

[wp_xyz]

Test mit Lazarus 1.4.4 r55637 FPC 2.6.4 i386-win32-win32/win64 gehen nicht. Das lässt sich schon mal nicht kompilieren. TFPReaderJpeg.ImageSize gabs damals noch nicht.

Stimmt... Ich habe mir jetzt die entsprechende Routine aus fpspreadsheet ausgeliehen, zusammengekürzt und mit einem {$IF FPC_FULLVERSION < 30000} bedingt eingebunden. Damit kompiliert das Package auch mit der ältesten Version, die ich noch auf dem Rechner habe (Laz 1.0 / fpc 2.6.0), wobei hier aber das BaseSample nicht mehr übersetzt werden kann (ValueListEditor.InsertRow gab's noch nicht). Ab 1.2 geht auch diese Demo.

Wahrscheinlich wird es mit älteren Versionen Probleme mit der String-Konvertierung geben, z.B. beim Kommentarfeld. Zum Glück sind die allermeisten Strings ASCII (<128), und ich bezweife, ob die immer wieder vorkommenden ansistring-Casts wirklich nötig sind.

Mit 1.4.4 (und früher) bin ich dann noch auf einen Fehler in dEXIF gestoßen. Im BaseSample sind meine eigenen Fotos in TImageInfo.Calc35Equiv abgestürzt, weil ein dafür benötigtes Tags in der Tag-Liste auskommentiert war. Außerdem hat die Routine bei einer fehlgeschlagenen Tag-Suche trotzdem weitergearbeitet - von diese Sorte könnte ich mir noch einige Fehler vorstellen...

Das zip im Anhang enthält die korrigierte dEXIF.pas, sowie ein diff zum jetzigen Zustand.