PDA

View Full Version : v4.25: Fehler beim verlustfreien Drehen



drodo
21.07.2009, 03:58 PM
Ich habe zwei Fehler beim verlustfreien Drehen beobachtet:

1.
Nach dem Drehen ("Optimiere JPG-Datei" deaktiviert) sind die Pixelmaße der schmaleren Bildseite verändert.
Vorher: 3550 pixel
Nachher: 3544 pixel

2.
Nach dem Drehen ("Original EXIF-Datum/Zeit auf die Datei anwenden" aktiviert) wird das Datum falsch/unrealistisch verändert.
Vorher: 21.04.2009 / 18:13:32
Nachher: 27.10.1617 / 12:47:44

Gruß, drodo

Foxy
21.07.2009, 04:49 PM
Zu Punkt 1...

...aus der 'IrfanView'-Online Hilfe:

http://en.irfanview-forum.de/vb/attachment.php?attachmentid=1657&stc=1&d=1248194930


Zu Punkt 2:

Das Verhalten kann ich mit dem von mir verwandten Bildmaterial nicht bekräftigen.

Füge ein Beispielbild bei, anhand dessen man selbst probieren kann.

drodo
21.07.2009, 06:04 PM
Hallo Foxy,

danke für Deine Antwort.

zu 1.
Das müsste bedeuten, dass die Pixelmenge nach dem Drehen durch 16 teilbar ist. 3544 ist jedoch nicht durch 16 teilbar (= 221,5).
Zudem ist die Pixelmenge der langen Seite des Bildes mit 5410 Pixeln vor dem Drehen ebenfalls nicht durch 16 teilbar (= 338,125), und sie ist nach dem Drehen sogar unverändert bei 5410 Pixeln geblieben.

Da scheint also etwas nicht in Ordnung zu sein.

zu 2.
(Eine Testdatei kann ich hier leider nicht einstellen.)
Ich habe die Aktion aber an einem weiteren Bild mit anderem Ursprungsdatum durchgeführt. Es hat nach dem Drehen exakt dasselbe falsche Datum (27.10.1617 / 12:47:44) wie die erste Datei.
Diese Dateien sind mit Nikon Scan 4.0.2 erzeugt und mit Adobe Bridge CS4 (3.0.0.464) bzw. Adobe Camera Raw 5.4 bearbeitet worden.

Eine dritte Datei, aus anderer Quelle, habe ich auf gleiche Weise gedreht. Hier ist das Datum korrekt geblieben.

Das Ursprungsproblem liegt also evtl. im Zusammenhang mit der Nikon- bzw. Adobe-Software.

Gruß, drodo

Foxy
21.07.2009, 07:18 PM
zu 1.
Es bleibt uns vorerst ungewiß, ob ein Bild, das dem Multiplikat von 16 nicht entspricht, automatisch auf ein solches reduziert wird.


zu 2.
Evtl. liegt’s auch an den EXIF-Daten. Solange ich’s nicht selber reproduzieren kann, bleibt mir nur das Reich der Spekulationen.

drodo
22.07.2009, 11:29 AM
Zur Prüfung habe ich hier einmal die von IrfanView bzw. Photoshop ausgelesenen Daten einer der betroffenen Dateien angehängt.

Syncro
23.07.2009, 10:40 PM
Hallo,

Da ich mich selber auch grad mit den verlustfreien JPG-Operationen beschäftige, kann ich glaub ich Punkt 1 erklären.
Der zitierte Absatz aus der IrfanView-Hilfe ist hier etwas unpräzise. (Allerdings sollte so eine Online-Hilfe ja auch nicht überladen werden, indem jeder einzelne kleine Punkt mit ellenlangen Spezifikationen erläutert wird.)

Ein JPG-Bild ist ja in Blöcke aufgeteilt. Mindest-Größe ist 8x8 Pixel, oft ist die Block-Größe (für bestimmte Farb-Kanäle) jedoch bei 16 (Stichwort Subsampling, oder Downsampling). Theoretisch können die Blöcke auch noch größer sein, aber mehr als 16x16 wird nur selten verwendet. Und die verlustfreien JPG-Operationen sind nur dann IN JEDEM FALL vollkommen verlustfrei, wenn die Auflösung des ursprünglichen JPGs ein Vielfaches dieser Block-Größe ist. Es kommt also ganz auf das Ausgangsbild und auch auf die genaue Art der 'verlustfreien' Operation an, ob dann am Ende wirklich etwas von den Rändern des Bilds entfernt werden muss.

@drodo: Dein Bild hatte, wenn ich es deinen Angaben hier richtig entnehme, eine Auflösung von 5410x3550. Block-Größe wohl bei 8x8 (oder 16x8). Du hast das Bild dann vermutlich um 90 Grad im Uhrzeigersinn gedreht. So, die lange Seite mit 5410 Pixel ist zwar nicht durch 8 (bzw. 16) teilbar, da aber bei deiner Drehung der rechte Rand unten landet, kann er dort auch behalten werden. Zur schmalen Seite: 3550 Pixel nicht durch 8 teilbar. Bei deiner Drehung müsste der Rand von unten nun an die linke Seite. Das lässt das JPG-Format aber nicht zu. Einzige Möglichkeiten: Der Rand, der nun eigentlich links stehen sollte, wird einfach auf der rechten Seite mitgespeichert. (Könnte aber etwas komisch aussehen. ;)) Oder dieser Rand (hier 6 Pixel) wird entfernt - was IrfanView dann auch macht.

Fazit: Kein Fehler. IrfanView macht hier alles richtig.


Zu Punkt 2:
Mit den EXIF-Tags kenn ich mich nun nicht so aus. Vielleicht wirklich ein Problem mit den Anwendungen, die das Bild erzeugt haben? Das Datum, das da wohl verwendet wird, ist ja Folgendes: "2009.04.21 18.00.10" (ModifyDate). Werden diese Daten normalerweise nicht mit einem Doppelpunkt abgetrennt? (Also so: "2009:04:21 18:00:10") Wenn ja, dann verschluckt sich IrfanView möglicherweise an diesem nicht standardgemäß gespeichertem Datum.
Könnte hier aber auch was ganz Anderes sein.

drodo
25.07.2009, 02:23 PM
Hallo Syncro,

besten Dank für Deine Ausführungen.

zu 1.
Zwischenzeitlich habe ich mich ein wenig mit den JPEG-Spezifikationen beschäftigt, und mir scheint Deine Erklärung jetzt nachvollziehbarer und auch prinzipiell richtig. Es ist also offenbar kein Fehler von IrfanView.

Wenn es darauf ankommt, ist der Aspekt der Blockgröße von JPEGs also vor der weiteren Bearbeitung (z.B. Scannen, Bilddrehung etc.) zu berücksichtigen, um Verluste von Bildinformationen (Pixeln) zu vermeiden.

zu 2.
Deine Entdeckung der ungewöhnlichen Schreibweise des Datums (Punkt als Trennzeichen, statt Doppelpunkt) ist sehr interessant und könnte eine Spur sein.

Gruß, drodo