PPI-Werte nach Export aus Lightroom

Wenn ich Fotos bearbeite, die ich später in Textdokumente einbinden will, weise ich ihnen gern hohe PPI-Werte zu. Das hat (besonders bei hochauflösenden Fotos) den Vorteil, dass sie zunächst mal sehr klein ins Dokument eingefügt werden und das Layout nicht zerschießen. Größer ziehen kann ich sie hinterher immer noch.

Jetzt habe ich festgestellt, dass meine bevorzugte Textverarbeitung "TextMaker" ausgerechnet die PPI-Werte aus Lightroom (v 6.14) nicht lesen kann. Mit Bildern aus anderen Programmen gab es nie solche Probleme. Offenbar gibt es also unterschiedliche Arten, wie PPI-Werte gespeichert werden.
Wenn ich so ein Lightroom-Bild in XnView öffne, bekomme ich gar zwei unterschiedliche Sets von PPI-Werten angezeigt (siehe Screenshot): in diesem Beispiel einmal 1200 ppi und einmal 72 ppi. Warum auch immer.

Die Folge ist, dass die direkt aus Lightroom exportierten Bilder nach dem Einfügen in TextMaker erst mal auf volle Textbreite gezoomt werden, obwohl sie laut ppi-Wert viel kleiner dargestellt werden müssten.
Wenn ich diese Bilder nochmal neu mit AffinityPhoto oder PhotoLine abspeichere, wird das Problem beseitigt. Also diese Programme können offenbar die PPI-Zahl aus Lightroom lesen – und schreiben sie dann beim Wiederspeichern so, dass auch TextMaker sie versteht.

In solchen Fällen kann man die "Schuld" immer zwischen den Softwareherstellern hin- und herschieben. Also entweder gibt Lightroom den PPI-Wert falsch aus oder TextMaker liest in falsch ein. Bleibt aber die Frage, warum AffinityPhoto und PhotoLine keine Probleme machen – also weder schreibend noch lesend.
Dasselbe Problem tritt übrigens auch mit LibreOffice Writer auf. Also auch dort wird der PPI-Wert von Lightroom-Dateien ignoriert, aber von den anderen Dateien beachtet.
Hingegen Microsoft Word erkennt den PPI-Wert aus Lightroom korrekt.

Ich habe zu Testzwecken eine extra-kleine Bilddatei (1200 Pixel breit) mit extra-hohem PPI-Wert (1200) ausgegeben, um das Problem nachvollziehbar zu machen. Bei korrekter Interpretation müsste das Bild jeweils in einer Breite von 1 Inch (2,54 cm) ins Textdokument eingefügt werden:
http://pixab.de/ppi-test_lightroom.jpg
http://pixab.de/ppi-test_photoline.jpg
http://pixab.de/ppi-test_affinity.jpg
(Wer kein TextMaker hat, kann es vielleicht mit LibreOffice Writer testen, wo der Fehler genauso auftritt.)

Hat jemand eine Ahnung, wo es "hakt"?

beiti schrieb:

Hat jemand eine Ahnung, wo es "hakt"?

Zum Vergrößern anklicken....

Genau genommen beim Verständnis.

Bitmaps (JPG Bilder) haben keine "ppi" (oder "dpi"). Das ist eine Größe, die erst beim Druck relevant ist: mit wieviel ppi wird ein Dokument gedruckt?

Nun ist ein Monitor auch ein bilddarstellendes Medium und besitzt auch "ppi", nämlich die Anzahl Pixel pro Zoll. Bei einem FullHD Monitor (1920x1080) mit beispielsweise 27 Zoll beträgt die "Druckdichte" (Pixeldichte) ca. 82 ppi.

Das ist eine relativ geringe Dichte, deswegen erscheinen Bilder mit vielen Pixeln (also Beispielsweise 4000x3000) auch so groß, wenn sie unskaliert (ein Farbpixel = 1 Monitorpixel) auf dem Monitor dargestellt werden.

Diese 82dpi sind hier eine genau berechnete Größe. Für Grafiker aus den Frühzeiten der Computertechnologie haben Grafikstudios hier den pauschalen Wert 72dpi eingesetzt, das war die "durchschnittliche" Pixeldichte bei Röhrenmonitoren. Daher kommen schon einmal die 72dpi in Deinem Dokument.

Moderne Grafikprogramme skalieren das anzuzeigende Bild aber herunter, damit es auf den Monitor passt, und/oder wenn es in einem Officedokument angezeigt werden soll. Letzteres ist jetzt die Stelle, wo es knackt, Du willst ja erreichen, dass die Grafik in Deinem Textdokument eine bestimmte (relative) Größe zum auszudruckenden(!) Dokument (meistens DIN A4) besitzt.

Wenn Du nur eine ppi Angabe in den JPG Header schreibst (das sind die 1200 ppi, die man in den Header schreiben kann), dann weiß das Officeprogramm immer noch nicht, wie groß denn das Bild auf dem Monitor dargestellt werden soll. Entweder muss das Programm davon ausgehen, dass wir hier einen Monitor haben und der hat nun einmal nicht 1200 ppi, sondern 72 resp. 82 ppi, oder man muss dem Programm mitteilen, mit welcher verbindlichen(!) Auflösung das Dokument nachher gedruckt werden soll. Daraus leitet das Programm die absolute Darstellungsgröße der "Drucksimulation" auf dem Monitor ab (denn der Monitor ist nichts anderes als eine Simulation des Ausdrucks).

Die Angabe der ppi Zahl in dem Bild geht also davon aus, dass dieses Dokument inkl. dem Bild mit 1200 dpi gedruckt wird. Das wäre der Idealfall, aber das wird meistens nicht der Fall sein. Und da fangen die Probleme an, wie groß soll denn das Programm das Foto darstellen, wenn es "weiß", dass der Druck nachher nicht mit 1200 dpi, sondern mit 300 dpi geschieht? Oder wenn das Programm überhaupt nicht weiß, wie hoch die Druckdichte des Druckers ist? Was heißt denn dann 1200 ppi? Was hat 1200 ppi? Sinnvoller ist die Angabe der Druckgröße im Bild (3cm x 4cm beispielsweise), dann kann das Programm mit Hilfe der Druckdichte berechnen, wie sehr es das Bild skalieren muss, damit es in der gewünschten Druckdichte die gewünschte Druckgröße erhält und auch, wie sehr das Bild skaliert werden muss, um passend im simulierten DIN A4 Dokument auf dem Monitor angezeigt zu werden.

So oder so wird aber das Bild an sich stark skaliert werden, weswegen es sinnvoll ist, das Foto in einer möglichst hohen Auflösung an das Office Programm zu übergeben. Sonst muss es ggf. sogar hochskaliert werden, was natürlich Schärfeverlust bedeutet.

Im Gimp ist diese Problematik auch konsequent richtig umgesetzt, da wird die "Druckgröße" parametrisiert, die sich ihrerseits aus der Druckdichte (nicht eine Eigenschaft des Bildes, sondern des Ausdruckes) berechnet. Eine reine Bitmap (was ein JPG ist) hat keine Druckdichte, sondern nur Pixel.

henklh schrieb:

Genau genommen beim Verständnis.

Zum Vergrößern anklicken....

Ich hatte schon befürchtet, dass hier jemand kommt, der meine Frage nicht richtig liest und mir stattdessen die Theorie hinter ppi erklären will...

Meine Frage ist viel spezifischer. Es geht um die Anfangsdarstellungsgröße beim Import in ein Textverarbeitungsprogramm. Dabei wird der ppi-Wert der Datei ausgewertet. Einer der wenigen Fälle, wo der in der Datei gespeicherte ppi-Wert tatsächlich relevant ist. Nur leider ist anscheinend die Art, wie Lightroom den Wert schreibt, nicht universell kompatibel.

Mit den verlinkten Dateien kann man das ausprobieren. Einfach in TextMaker oder LibreOffice Writer importieren und vergleichen, wie groß sie eingefügt werden.

Soweit ich es nachvollziehen kann hat henklh deine Frage eigentlich schon beantwortet - wohl etwas aussschweifend

Um mal nicht zu theoretisch zu werden:
Vielleicht hilft es, wenn Du beim Export aus Lightroom mal die gewünschten Bildmaße in cm angibst...

Deinen Verwendungszweck kenne ich nicht, aber wenn die Dokumente z.B. nur am Bildschirm betrachtet werden, würden die erwähnten 72 dpi als Auflösung ausreichen. Wenn die Originale es hergeben, kannst du die auch höher stellen, dann kannst du in deiner Textverarbeitung sicher auch noch vergössern ohne, dass sie verpixeln.

Vielleicht habe ich Dich aber auch nicht verstanden

beiti schrieb:

-...(Wer kein TextMaker hat, kann es vielleicht mit LibreOffice Writer testen, wo der Fehler genauso auftritt.)

Zum Vergrößern anklicken....

Per Texteditor geöffnet, zeigt sich, dass PL + Affi einen (Standard) JFIF Header in ihre Datei schreiben, hingegen LR einen EXIF Header.
Verblüffend, dass der/die Importfilter von Textmaker und Libreoffice letzteren nicht korrekt auswerten? Im Jahre 2019. - Vermutlich arbeiten eben nur wenige fotoaffine Leute mit den beiden Progs.

Henry06 schrieb:

Per Texteditor geöffnet, zeigt sich, dass PL + Affi einen (Standard) JFIF Header in ihre Datei schreiben, hingegen LR einen EXIF Header.

Zum Vergrößern anklicken....

Danke für den Hinweis, das klingt als Ursache plausibel!

Mir war bis zu diesem Problem gar nicht bewusst, dass es für das Schreiben des PPI-Wertes unterschiedliche Methoden gibt.
Gerade habe ich gesehen, dass XnView bei meinem Testbild aus Lightroom standardmäßig nur 72 ppi anzeigt. Allerdings kann man, wenn man auf "DPI einstellen..." geht, ein Kästchen ankreuzen "EXIF-dpi-Wert ändern, wenn vorhanden". Also offenbar kann XnView zwar nur den JFIF-Header-Wert lesen, aber bei Bedarf beide Werte schreiben.
IrfanView zeigt hingegen gleich korrekt die 1200 ppi aus dem EXIF-Header an. Auch Gimp zeigt den Wert unter "Druckgröße" korrekt an.

herrnaus schrieb:

Deinen Verwendungszweck kenne ich nicht, aber wenn die Dokumente z.B. nur am Bildschirm betrachtet werden, würden die erwähnten 72 dpi als Auflösung ausreichen.

Zum Vergrößern anklicken....

Darum, wieviel Auflösung wofür ausreicht, geht es hier überhaupt nicht. Es geht um ein reines Workflow-Problem.


Ich will nochmal versuchen, den Kern meines Problems zu erklären. Wen das nicht interessiert - bitte einfach nicht lesen:

Der PPI-Wert, der in den Metadaten einer Bilddatei gespeichert ist, hat in 99 % aller fotografischen Anwendungsfälle überhaupt keine Bedeutung (und ist für Anfänger sogar oft irreführend, weil sie ihn mit dem tatsächlichen PPI-Wert verwechseln, der sich aufgrund der konkreten Druckgröße ergibt). In meinem Fall geht es nun um eine der wenigen Situationen, wo der Wert doch mal eine Bedeutung hat.

Textverarbeitungsprogramme nutzen den PPI-Wert als Ausgangswert, um zu entscheiden, wie groß ein Bild standardmäßig eingefügt wird. Das Prinzip ist z. B. nützlich, wenn man etwas gescannt hat: Einem Scan ist ja automatisch die Scan-Auflösung als PPI-Wert zugewiesen – und so wird das Bild immer in Originalgröße ins Dokument eingefügt.

Fotos, die aus Digitalkameras stammen, sind oft pauschal als 72 ppi gekennzeichnet. Bei einem typischen 24-MP-Foto mit 6000 Pixeln in der Breite entspricht das einer theoretischen Druckbreite von gut 2 Metern. In älteren Textverarbeitungen führte das dazu, dass das Bild erst mal riesengroß eingefügt wurde und das Papierformat (meist A4) weit überragte. Man musste dann erst mal die Darstellung "runterzoomen", um überhaupt an die Anfasser ranzukommen und das Bild kleiner ziehen zu können.
Moderne Textverarbeitungen sind clever genug, das Bild in solchen Fällen gleich auf Seitenbreite oder Textbreite runterzuzoomen. Aber selbst das kann viel zu groß und unhandlich sein; Hochformat-Fotos nehmen da gleich mal die ganze Seite ein, bevor man sie manuell verkleinert.

Ich arbeite gerade an einem Text, in den ich mehrere hundert kleine Bilder einfügen muss, die ich vorher aus Lightroom exportiere. Da ist das einzelne "Kleinerziehen" der Bilder ein nicht unerheblicher Mehraufwand. Das versuche ich zu umgehen, indem ich den Bildern bereits beim Lightroom-Export 1200 oder auch 2000 ppi zuweise (muss ich noch rausfinden, welcher Wert für meine Zwecke am besten passt). Es funktioniert aber bisher nicht, weil TextMaker den von Lightroom geschriebenen PPI-Wert ignoriert.
Jetzt muss ich halt eine Lösung finden. Entweder gibt es ein Export-PlugIn für Lightroom, das den Wert "lesbar" einbettet. Oder zur Not muss ich alle Bilder nochmal durch eine weitere Stapelverarbeitung jagen, z. B. mit IrfanView.

Eventuell mit exif Tool die Werte noch mal schreiben, vorausgesetzt, die landen dann im richtigen Feld.

beiti schrieb:

Ich hatte schon befürchtet, dass hier jemand kommt, der meine Frage nicht richtig liest und mir stattdessen die Theorie hinter ppi erklären will...

Zum Vergrößern anklicken....

Musste auch schmunzeln. Ohne ein die PPI berücksichtigendes Layoutprogramm würde ich verrückt werden – allein schon beim Platzieren von Screenshots.

Ich sehe das Problem hier bei den Textverarbeitungsprogrammen, die du nutzt. Word, Libre Office, Pages, Textmaker und Co sind halt keine "echten" Layoutprogramme, sondern Consumerprodukte. Bei denen geht der Hersteller vielleicht davon aus, dass die User die Geschichte mit den PPI eh nicht raffen oder nutzen und dass der EXIF-Wert in JPEGs meist eh Unfug ist (72 und Konsorten).

In InDesign werden alle drei Bilder jedenfalls in korrekter Größe platziert (also klein), während Pages alle drei Bilder gleich groß platziert.

10dency schrieb:

.... Word, Libre Office, Pages, Textmaker und Co sind halt keine "echten" Layoutprogramme, sondern Consumerprodukte....

Zum Vergrößern anklicken....

"Word" (s. auch o.) importiert schon seit Urzeiten korrekt - ich denke, weil das einfach von einer deutlich größeren Zahl von "Foto-Usern" benutzt wird, da würde so ein "Fehler" ganz schnell auf der Bugliste landen?!

10dency schrieb:

Word, Libre Office, Pages, Textmaker und Co sind halt keine "echten" Layoutprogramme, sondern Consumerprodukte. Bei denen geht der Hersteller vielleicht davon aus, dass die User die Geschichte mit den PPI eh nicht raffen oder [...]

Zum Vergrößern anklicken....

Nur weil es keine Layoutprogramme sind, sind es nicht automatisch Consumerprodukte. Es sind professionelle Office-Programme.

Ein bisschen Verständnis für die Problematik ist ja anscheinend auch bei den Herstellern von Office-Programmen vorhanden. Sonst würden TextMaker und LibreOffice die ppi-Daten aus Affinity/PhotoLine nicht korrekt auswerten.
Word ist da noch einen Schritt weiter. Es gibt durchaus Profi-Setzer, die für einfachere Layouts auf Word (in Verbindung mit Acrobat für die PDF-Erstellung) zurückgreifen.
Etwas verwundert bin ich über Pages. Es ist das Einzige der hier genannten Textprogramme, das die ppi-Werte generell ignoriert – obwohl es dort mit dem Seitenlayout-Modus sogar einen Hauch von DTP-Funktionalität gibt.

Ich werde das jetzt in Bezug auf TextMaker weiter verfolgen. Da gibt es ja im SoftMaker-Forum einen relativ kurzen Draht zu den Entwicklern.

beiti schrieb:

Nur weil es keine Layoutprogramme sind, sind es nicht automatisch Consumerprodukte. Es sind professionelle Office-Programme.

Zum Vergrößern anklicken....

Klar. Ich meinte eher aus Grafiker/Layouter-Sicht.