Exif bzw. IPTC

[af0815]

Zusammenführung Version von Chris mit Mitja:

Eine Menge der Änderungen betrifft AnsiString <-> String und AnsiChar <-> Char, was ist besser ?

Code: Alles auswählen

A variable of type AnsiChar is exactly 1 byte in size, and contains one ANSI character. All versions of Free Pascal up to version 3, consider Char and AnsiChar to be equivalent declarations. However, in the future the compiler may consider Char to be a synonym for WideChar.

Wenn ich das mir aus der FP Wiki ansehe, so ist genaugenommen, der AnsiChar näher an dem, was in der Datei stehen wird.

Ebenso mit AnsiString

Code: Alles auswählen

Der Datentyp AnsiString hat keine Einschränkung in der Grösse und besteht aus einem Array des Datentyp Char.
 

Andreas

[wp_xyz]

Ich habe eben die Spezifikation gefunden (http://www.cipa.jp/std/documents/e/DC-0 ... 2016-E.pdf), natürlich nicht gelesen, aber beim Überfliegen kriege ich den Eindruck, dass Strings (z.B. Kamerahersteller oderBildbeschreibung) als 1-Byte-Strings gespeichert sind (S39: "Two-byte character codes cannot be used."). Daher ist wahrscheinlich ansistring schon richtig (und nicht WideString oder UnicodeString), aber wahrscheinlich geht auch ganz einfach String.

Damit wir beide nicht dasselbe machen: Ich habe angefangen, in Chris' Version das Jpeg-Thumbnail freizuschalten. Kämpfe momentan damit, wie man ein mit fcl-image eingelesenes jpeg-Bild in die LCL überführt...

[af0815]

Ich habe eben die Spezifikation gefunden (http://www.cipa.jp/std/documents/e/DC-0 ... 2016-E.pdf), natürlich nicht gelesen, aber beim Überfliegen kriege ich den Eindruck, dass Strings (z.B. Kamerahersteller oderBildbeschreibung) als 1-Byte-Strings gespeichert sind (S39: "Two-byte character codes cannot be used."). Daher ist wahrscheinlich ansistring schon richtig (und nicht WideString oder UnicodeString), aber wahrscheinlich geht auch ganz einfach String.

Damit wir beide nicht dasselbe machen: Ich habe angefangen, in Chris' Version das Jpeg-Thumbnail freizuschalten. Kämpfe momentan damit, wie man ein mit fcl-image eingelesenes jpeg-Bild in die LCL überführt...

Ich abreite in der wip_samples

Ich vergleiche die Chris-Version mit deiner => abgeschlossen, waren nur ein paar minor Sachen. Habe die ANSIStrings drinnen gelassen ! Eben aufgrund der Spezifikation

Edit: in wip_samples ist jetzt ein Merge aller Versionen. ANSIString´und ANSIChar sind erhalten geblieben, das Paket lässt sich kompileren.

Andreas

[MitjaStachowiak]

Mein Programm zielt auf Online-Anwendungen ab. Dort braucht man das Vorschaubild nicht und deswegen lasse ich das weg.

[af0815]

Im Zweig WIP_Samples sind einmal alle Zweige zusammengeführt und es ist kompilierbar. Einige wenige Änderungen von Mitja sind nicht eingeflossen, da er sonst den Code zu stark gebrochen hätte.

Ich habe auch ein Verzeichnis für Test eingerichtet. Zumindest die Basisfunktionen sollten laufend geprüft werden. Was ich noch suchen würde, wären Beispielbilder mit passenden Lizenzen um diese in die Tests zu inkludieren.

Andreas

[wp_xyz]

Wenn ich das richtig verstehe, könnte ich dann die Version im Zweig WIP_Samples nehmen und meine eigenen Änderungen einpflegen. Das Jpeg-Vorschaubild kann ich inzwischen anzeigen, ohne LCL zu benötigen, aber für's Schreiben müsste ich mir morgen noch etwas überlegen. Auch die Speicherlecks sind weg (mehrere FillChar-Aufrufe für Records mit Strings - sehr heimtückisch!). Ich würde dann auch noch das angepasste Demoprogramm der Originalkomponente beisteuern.

[af0815]

Ja, und dann testen, was alles sauber funktioniert. Es ist auch kein Problem dir Rechte auf das Repo zu geben (PN). Die anderen Zweige sind nur zu Vergleichszwecke und für den Merge drinnen.

Andreas

[af0815]

Wenn ich ersten Tests laufen lasse, so habe ich schon meine ersten Frage.

TImgData.ProcessFile liefert genaugenommen nur dieselbe Information wie TImgData.HasEXIF zurück.

Die Frage was ist richtig ? Ich würde sagen, wenn die Datei ordnungsgemäß gescannt wurde, das Dateiformat unterstützt ist, so sollte die Information TRUE zurückliefern. Denn ob die Datei Informationen beinhaltet, kann ich ja mit HasEXIF dann abfragen.

Warum stellen sich die Frage(n), wenn ich schon ein paar Tests schreibe, dann will ich das Verhalten kennen und kann es gleich in der Datei dokumentieren. Damit wird vielleicht alles einmal klarer Einfach den Test mal versuchen und sehen was ich meine

Andreas

BTW: im wip_ liegt schon mal die erste Doku als PDF dazu. Kommentare sind willkommen

[wp_xyz]

Ich habe auch meine Fragen:

• ReadJpegFile und ReadTiffFile haben den Dateinamen als Parameter "aFileName", der aber nicht benutzt wird, sondern nur die interne Variable "Filename" (ohne "a"). Wahrscheinlich muss man in diesen Funktionen auch Filename auf aFileName setzen, indem man SetFileInfo(aFileName) aufruft. Aber sicher bin ich mir nicht
• TImgData.Sections ist deklariert für Indices 1..21. In ReadJPegSections hört die Schleife aber schon bei Index 20 auf. Allerdings gibt es noch die Variable SectionCnt, die anscheinend die tatsächlich benutzten Sections mitzählt. Aber warum ist TImgData.Sections dann kein dynamisches Array?
• ReadComments: benutzt intern einen WideString, gibt das Ergebnis aber als String zurück. Das funktioniert unter fpc 3.0+, aber vorher wahrscheinlich nicht. Ich denke man muss, um Kompatibilität zu früheren fpc-Versionen zu bewahren, hier ein UTF8Encode einbauen.
• Warum sind ReadArtist/WriteArtist etc im private-Abschnitt? Sie werden nirgendwo aufgerufen, und von außerhalb kann man das auch nicht, da "private". Ich denke, diese Funktionen von Mitja sollten public sein.

Die erneute Arbeit mit dieser Bibliothek bestätigt meinen Eindruck von früher: Mit heißer Nadel gestrickt. Ich weiß nicht, ob es sich lohnt, da viel Arbeit reinzustecken, um die Klassen sicherer zu implementieren. Wahrscheinlich wäre diese besser investiert, wenn man versuchen würde, EXIF direkt in die fpc-Routinen einzubauen. TFPCustomImage hat z.B. speziell eine StringList FExtra, die man wahrscheinlich für Meta-Daten verwenden könnte.

[EDIT]
Mitja, in "TImageInfo.Readcomments", im else-Zweig von "if pos('ASCII', p^.Row) = 1", in dem der Widestring behandelt wird, stimmt möglicherweise die Stringlängenberechnung nicht. Du schreibst: SetLength(w, (Length(p^.Raw)-10 div 2)) - muss das nicht eher heißen "SetLength(s, Length(p^.Raw) div 2 - 10)" (denn der 1-byte-String p^.Raw enthält ja nun 2-byte-Zeichen)? Analog evtl auch darunter das "Move"?

[af0815]

Mit heißer Nadel gestrickt. Ich weiß nicht, ob es sich lohnt, da viel Arbeit reinzustecken, um die Klassen sicherer zu implementieren.

Ich verwende aktuell das Paket in mehreren Projekten allerdings nur lesend. Ich muss jetzt auch noch ein paar Infos schreiben. Ok, die Frage ist, wie stabil will man es haben Ausserdem ist ein Stand angenehm den man kennt und es ist auch eine Erfahrung da mehrere Versionen einmal zusammenzufügen.

Das mit dem implementieren in die FPCCustomImage ist natürlich ein Thema, nur dann kann muss man das komplett neu implementieren. Dazu müsste ich aber mehr Infos über das EXIF/FPCCustomImage aneignen. Vorerst sage ich mal für mich -> ich stecke etwas arbeit in dExif hinein, um dann besser zu sehen was sinnvoll ist. Die Arbeit ist ja nicht verloren sondern Informationsgewinn.

Eine andere Möglichkeit wäre, CCR-Exif zu portieren/portable zu machen. Die ist viel weiter. https://code.google.com/archive/p/ccr-exif/downloads und https://code.google.com/archive/p/ccr-exif/

Andreas

[wp_xyz]

Ja, ich geb dir völlig recht. Wir sollten dExif so weit treiben, bis wir einen stabilen Referenzpunkt haben, aber nicht weiter. An die Integration in FPCustomimage kann man sich später machen.

CCR.Exif habe ich mir gestern schon angesehen, nachdem ich in der Laz-Mailingliste gelesen habe, dass die Dotted-Unit-Names jetzt funktionieren. Aber ich habe bald gesehen, dass das wahrscheinlich das kleinste Problem ist - mein Eindruck ist, dass Chris Rolliston in diese Bibliothek alles reingesteckt hat, was Delphi an Erweiterungen gegenüber altbackenem Object Pascal zu bieten hat, und ich habe bald wieder aufgegeben. Aber vielleicht war ich nur zu ungeduldig.

[af0815]

Ad. fcl-image: Wie kann man ein solches Paket in Lazarus testen/debuggen ?

im TIFF Format dürfte ein rudimentärer Anzatz für EXIF drinnen sein, zumindest laut der Wiki http://wiki.freepascal.org/fcl-image unter TIFF

Code: Alles auswählen

Sets properties in the image Extras properties, which is used by the writer, so that reading/writing keeps many common tags like Artist, Copyright, DateAndTime, HostComputer, ImageDescription, Maker, Model, Software, DocumentName, XResolution, YResolution, Orientation, bit depts, page name, isThumbnail.

BTW: Der Programmers Guide im dEXIF Paket ist recht interessant.

Edit: Wenn man sich den TFPReaderTarga.InternalRead ansieht (für TIFF) so ist der Support seeehr rudimentär und verwendet eine stark eingeschränkte EXIF readfunktion. Von richtigen EXIF und IPTC keine Spur.
Das heisst auch, wenn man das berücksichtigt, so hat es Sinn das ganze mit dExif durchzuspielen und zu begreifen, dann hat man ein Chance das, wenn nötig, zu implementieren.

Andreas

[wp_xyz]

Andreas, hier die von mir geänderten Dateien von wip-samples, sowie die beiden angepassten Original-Demos

• Lesen und Schreiben des EXIF-Thumbnail-Bildes
• Um nicht die LCL zu benötigen, wird das Vorschaubild nicht direkt als TJpegImage ausgelesen, sondern als Stream übergeben. Entsprechend beim Schreiben.
• Die Direktive dExifNoJpeg wird unter Lazarus nicht beachtet. Ich habe die Deklaration aus der Package-Datei entfernt.
• Speicherlecks beseitigt
• Gelegentlichen Absturz des EXIF-Demos wegen Bereichsüberlauf beim Durchsuchen der GPS-Tags behoben
• Das IPTC-Demo habe ich noch nicht groß getestet, weil ich keine Bilder mit IPTC-Metainformationen gefunden habe. Das Schreiben der IPTC-Daten in einer LCL-freien Version ist noch zu erledigen.
• Ob das Package noch unter Delphi funktioniert habe ich auch nicht geprüft, ich habe zumindest reichlich IFDEF DELPHI-Direktiven verwendet.
• Die Versionsnummer habe ich auf 1.04 erhöht.

Mitja, entschuldige, ich habe mir erlaubt, gelegentlich deinen Codier-Stil für das Debuggen einiger Routinen an meine Gewohnheiten anzupassen, in deiner komprimierten Schreibweise finde ich mich nicht zurecht.

[Christian]

@af, bekommen wir das alles noch zusammen ins repo ?

Schade das git unter Lazarus anhängern so unverbreitet ist man könnte zusammen sicher viel mehr erreichen als wenn jeder seine eigene Version bastelt

[af0815]

Christian, genau deswegen habe ich einen Fork gemacht. Aktuell versuche ich 3 Versionen zu vereinen. Siehe wip_Samples.

Das Konklusio kommt dann mal in den Master.

Gerade jetzt wären Ideen zu den Tests wichtig. Damit das stabiler wird. Auch gefällt mir die fehlende Kapselung nicht.

GITHUB: Daten sind in WP_XYZ_Version eingepflegt.

Andreas