GDI+ Delphi Berlin oder höher

[Benmik]

Es geht hier um den Datentyp 5. Eigentlich soll er 8 Bytes lang sein mit 4 Bytes Zähler und 4 Bytes Nenner. Laut Spezifikation ist er "unsigned", müsste also 2 x Cardinal sein, denn es gibt ihn auch noch mit Vorzeichen als Typ 10.

Es ist aber keineswegs so, dass der Typ 5 immer nur 2 x 4 = 8 Bytes hat, zum Beispiel nicht bei den GPS-Werten. Bei GPSLongitude und GPSLatitude hat er 3 x 8 = 24 Bytes (das ist auch so bei EXIFTool vermerkt). Da könnte es bei deinem iPhone haken, weil es vermutlich GPS-Daten in die JPG schreibt. Daher ist deine Lösung nicht optimal an den Typ 5 angepasst.

Ich mache das ungefähr so (ist jetzt so dahingeworfen):

Delphi-Quellcode:

var Buff:TBytes;
    Zähler,Nenner,DritterWert:Cardinal; 
begin
  SetLength(Buff,Length);
  Move(Value^, Buff[0], Length);
  Zähler := PCardinal(@TB[0])^;
  Nenner := PCardinal(@TB[4])^;
  If Length >= 12
    then DritterWert := PCardinal(@TB[8])^;
end;

Der Zusammenbau von GPSLatitude etc. ist auch nicht ganz trivial. Das verdeutlich das Prinzip, vielleicht hilft dir das erstmal weiter.

[Willie1]

Zitat von Benmik:

Es geht hier um den Datentyp 5.

Der Zusammenbau von GPSLatitude etc. ist auch nicht ganz trivial. Das verdeutlich das Prinzip, vielleicht hilft dir das erstmal weiter.

Ja, es geht um PropertyTagTypeRational: 2 Zahlen = 4 Bytes für Zähler und Nenner. Ich hatte es mit Move gemacht, vor 15 Jahren konnte ich es nicht besser. Bennik, genau die Geo-Koordinaten haben mich auf diese Idee gebracht, es geht.

Delphi-Quellcode:

  Type
    TRationalBuff = array[0..1] of Integer;
    TPRationalBuff = ^TRationalBuff;

          else                     //alle anderen
          with PropItem^ do begin
//            Move(Value^, RationalBuff, Length);    //löst Fehler bei Apple aus
            RationalBuff := TPRationalBuff(Value)^;
            R1:=RationalBuff[0];
            R2:=RationalBuff[1];
            if R2 > 0 then
              s:=Format('%0.4f',[R1 / R2])
            else
              s:='error';
            s1:=ShowID(ShowTagStr, GetMetaDataIDString(id), PropID);
            Result:=Format('%s %s',[s1,s])
          end;

Die GDP-Dateien habe ich natürlich auch neu kompiliert, da gibt es viele string - Typen, jetzt alle als 16-Bit-String, Kann es da zu Problemen kommen? Ich weiß aus schmerzhafter Erfahrung Test- oder Demoprogramm ist das eine, der Einsatz in einem großen Programm ist das andere. Meine Motivation hatte ich oben erklärt. Willie.

[Benmik]

Der RationalBuff kann nur 8 Byte aufnehmen, bei GPS sind es aber 24. Mit ihm kommst du also nicht an bestimmte GPS-Daten ran (GPSLongitude, GPSLatitude).

Move an sich ist völlig OK; man kann es auch über eine Pointer-Variable machen, aber dann hat man nicht die Flexibilität von TBytes. Ich meine, es ist immer noch am besten, Length zu messen, TBytes entsprechend zu dimensionieren und danach zu handeln.

Bei den Stringtypen von Typ 7 ist es nicht ganz so einfach, die können laut Spezifikation auch Unicode sein, worauf du mit AnsiChar nicht weiter kommst. Das betrifft vor allem UserComment. Man kann die Strings ruhig bei Delphi-String belassen, muss sich dann aber um die Konvertierungen kümmern.

Ich muss jetzt zum Zug; später komme ich eventuell dazu, etwas zu posten.

[Willie1]

Hallo Bennik, gute Fahrt, bei der Bahn muss man immer Sorgen haben!

Ich habe versucht mein Projekt von ca. 2008 mit D-Berlin zu kompilieren. Meine eigenen Komponenten zu integrieren war einfach. Aber es ist genauso, wie ich befürchtet hatte. Es knallen die Fehlermeldungen. Besonders eine Bibliothek von 2006 von Gerry McGuire dExif macht Probleme. Er hat wohl sehr tricky programmiert.
Ich muss bei Delphi 2005 bleiben: Trotzdem sind deine Hinweise für mich sehr wichtig. Sind AnsiString, AnsiChar PAnsiChar bei Delphi 2005 schon bekannt oder muss ich die Änderungen wieder zurücknehmen. Das wäre blöd.
Gruß Willie.

[Benmik]

Jetzt fahre ich 15 km mit dem Rad zum Bahnhof und der Zug fällt aus! So'n Mist. Und kein LTE.

dEXIF wollte ich dir empfehlen, aber ich dachte, du möchtest alles selber machen.

Schau doch mal auf diese Version, die mit Rio 10.3.3 anstandslos funktioniert. Mit dieser Unit brauchst du aber eigentlich überhaupt michts mehr selbst zu machen, was EXIF, betrifft, es ist alles fix und fertig.

[Willie1]

Zitat von Benmik:

Jetzt fahre 15 km mit dem Rad zum Bahnhof und der Zug fällt aus! So'n Mist. Und kein LTE.

Ich war viele Jahre Wochenendpendler. Ich sage dir, es stimmt, früher war die Bahn besser!!!

Ich benutze dExif für IPTC-Daten aus zu lesen und zum Schreiben des JPG-Kommentars. An eine neue Version von Gerry McGuire hab' ich nicht gedacht. Willie.

[Benmik]

Ich kann nur an dich appellieren, mit Rio 10.3.3 weiterzumachen. Das Allermeiste, was jetzt veröffentlicht wird, setzt auf Sprachfeatures, die mindestens Delphi 2009 voraussetzen. Du musst dir die Arbeit sowieso machen, und so schlimm ist das auch gar nicht.

Das erwähnte dEXIF läuft ohne Probleme unter Rio und nimmt dir fast alle Arbeit ab. Probiere dies:

Delphi-Quellcode:

procedure TesteDEXIF;
var ImgData: TImgData;
    Verz,Datname:string;
begin
  Verz := 'C:\Temp\';
  Datname := 'BLD00405.JPG';
  ImgData := TImgData.Create;
  Try
    If ImgData.ProcessFile(Verz + Datname) and ImgData.HasExif then begin
    end;
  Finally
    ImgData.Free;
  End;
  Application.Terminate;
end;

Alles, was du brauchst, findest du dann in ImgData.ExifObj - und noch viel mehr.
Setze mal einen Haltepunkt auf ImgData.Free; .
Ich habe dir im Debugger mal beispielhaft DateTimeOriginal geöffnet, mit dem du solche Schwierigkeiten hattest.