mit GIMP bearbeitete Grafiken werden nicht eingebunden

[Roman_95]

Hallo zusammen,

ich muss in meiner Bachelorarbeit Bilder einfügen, welche ich vorher mit GIMP (Version 2.10.* bearbeitet habe. Das Dokument kompiliert zwar fehlerfrei, die Grafik wird jedoch nicht angezeigt. Das unbearbeitete Foto (.jpg) funktioniert einwandfrei. Ich habe sowohl Einbinden als .jpg und .png ausprobiert.

Ich vermute es liegt am GIMP-Export. Jedoch können die Bilder über das normale Windows-10 Anzeigeprogramm ohne Weiteres geöffnet werden, also weiß ich nicht was da nicht in Ordnung sein könnte.

Ich hoffe mir kann hier jemand weiterhelfen. Brauch ich vllt. ein GIMP-Plugin? Bin da blutiger Anfänger ^^

Das MM zeigt meinen Befehlsaufruf, ich zeige nur einen Ausschnitt aus dem Bild. Im eigentlichen Dokument habe ich ein Grafik-Verzeichnis, deshalb der \graphicspath-Befehl.

\documentclass[%
a4paper,
oneside,
12pt
]{scrbook}

\usepackage[T1]{fontenc}
\usepackage[includeheadfoot, inner=4cm, outer=2cm, top=3.5cm, bottom=2cm,
showframe=true,
]{geometry}
\usepackage{blindtext}

\usepackage{graphicx}
%\graphicspath{./graphics/} % Angabe des Standard-Grafikverzeichnisses

\begin{document}
	
\def\linewidth{0.3\textwidth}
\includegraphics[width=\linewidth, viewport=190px 10px 600px 230px, clip]{example-image-a4-numbered}

\end{document}

VG, Roman

*nettes Easter-Egg, eigentlich steht hier .8 von der Versionsnummer

[Gast]

Bei mir funktionieren sowohl jpg als auch png, die mit GIMP (dieselbe Version) erstellt oder bearbeitet wurden. Hast du in GIMP auch sicher exportiert und nicht nur gespeichert? Speichern erzeugt nämlich immer Dateien im GIMP-eigenen Format.

Auch wenn die \graphicspath-Anweisung auskommentiert war, sei darauf hingewiesen, dass die Syntax falsch ist. Jede Pfadangabe muss im Argument nämlich selbst auch noch einmal in geschweifte Klammern. Es muss also \graphicspath{{./graphics/}} oder vereinfacht \graphicspath{{graphics/}} lauten, wie auch in dem Beispiel im grfguide.

Bitte zeige uns auch die log-Datei, damit wir eventuelle Fehlermeldungen oder Warnungen sehen können.

BTW: Kürzlich hatte irgendwo jemand ein ähnliches Problem, bei dem sich herausstellte, dass die Grafiken zu groß waren. Sie waren dann zwar im PDF enthalten, der PDF-Viewer konnte sie aber nicht rendern und hat sie einfach weggelassen. Auf einem anderen Rechner mit mehr Speicher und anderem PDF-Viewer ging es dann.

[u_fischer]

\def\linewidth{0.3\textwidth} 

Wer hat dir denn das beigebracht?

[Roman_95]

Hallo,

im Anhang die .log-Datei. Habe nur das betreffende Kapitel kompiliert, ist trotzdem noch ziemlich viel. (Der alte log wurde vorher gelöscht.) An der Stelle, wo die entsprechende Grafik eingefügt wird - die einzige .png-Datei - konnte ich nichts besonderes finden. Das Fehlerbild ist das gleiche.

Ist auf jeden Fall aus GIMP exportiert - wie gesagt, der Standardbetrachter von Windows hat mit den Bildern auch kein Problem. Das Bild ist 207kB groß, das dürfte wohl auch nicht das Problem sein...

Wer hat dir denn das beigebracht?

ist n Hack um meinen Einfüge-Befehl 1:1 übernehmen zu können - dieser befindet sich in einer subfigure-Umgebung deren Breite relativ zu \textwidth festgelegt ist.

Wo du nachfragst, ich wundere mich ein wenig dass das so funktioniert

[u_fischer]

Habe nur das betreffende Kapitel kompiliert,

Du sollst keine Kapitel kompilieren, sondern dein Minimalbeispiel in deiner Frage - unter der Annahme, dass es dein Problem zeigt.


Abgesehen davon: Wenn du wirklich den viewport verwendest, den dein Beispiel zeigt, wundert es mich nicht, wenn nichts zu sehen ist.

[Roman_95]

Hallo,

sorry, falsch verstanden. Im Anhang der .log zu folgendeme MM:

\documentclass[%
a4paper,
oneside,
12pt
]{scrbook}

\usepackage{graphicx}
%\usepackage{transparent}

\begin{document}

\newlength\bildbreite	
\def\bildbreite{0.3\textwidth}
\fbox{\includegraphics[width=\bildbreite, viewport=190px 10px 600px 230px, clip]{20190116_Auslauf1.png}}
\fbox{\includegraphics[width=\bildbreite, viewport=190px 10px 600px 230px, clip]{20190116_Auslauf2.png}}
\fbox{\includegraphics[width=\bildbreite, viewport=190px 10px 600px 230px, clip]{20190116_Auslauf2.jpg}}

\end{document}

Das Bild ..._Auslauf1.png ist das welches Probleme bereitet. Exportiere ich ..._Auslauf2 als .png aus GIMP, wird es ebenfalls nicht dargestellt. Speichere ich letzteres in Paint als .png, nachdem ich das .jpg geöffnet habe, wird es im Dokument angezeigt - allerdings ein anderer Bildausschnitt, liegt das an einem anderen Aufbau/Koordinatensystem der .png-Datei? Auch die Skalierung durch \includegraphics ist nicht mehr korrekt, das Bild wird schmaler (s. Anhang). Die Bildgröße ist dieselbe, wenn ich die Bilder in Paint öffne.

Das ist aber auch nicht so wichtig, den viewport kann ich ja ohne Weiteres anpassen. Der ist bei den ursprünglichen Bildern übrigens genau wie ich ihn brauche. Mehrere hundert pixel in jeder Richtung sind mM nach auch nicht mega wenig. Oder worauf möchtest du hinaus mit deiner Aussage diesbezüglich?

Ich könnte mir helfen indem ich das Bild über Paint wieder in .jpg konvertiere, aber mir wäre es lieber den eigentlichen Fehler zu finden.

Ich muss noch sagen, dass ..._Auslauf1.png transparente Bereiche enthält (deshalb auch als .png gespeichert) Allerdings weiß ich nicht ob das eine Rolle spielt, wenn auch ein anderes aus GIMP exportiertes .png (ohne transparente Bereiche) nicht dargestellt wird. Die Verwendung des Paketes transparent macht keinen Unterschied.

Ich hoffe ihr könnt mir weiterhelfen und dass ich alle wichtigen Infos bereitgestellt habe.

VG, Roman

[Gast]

Tritt das Problem tatsächlich nur auf, wenn alle drei Bilder eingebunden werden? Anderenfalls ist das Beispiel nicht minimal. Ohne das Bild ist es übrigens auch nicht vollständig. Reproduzieren können wir das so nicht. Welche PDF-Viewer hast du eigentlich bisher ausprobiert?

Transparenz hat auf einige Viewer in der Tat seltsame Effekte. Dass ein Bild verschwindet, ist mir allerdings noch nicht begegnet.

[Gast]

Vergleiche auch mal die Auflösung der geänderten Bilder mit denen der Originalbilder. 1px in pdftex ist ja nicht zwingend ein Pixel des Bildes. 1px ist abhängig von der Einstellung von \pdfpixdimen. In der Voreinstellung ist AFAIK 1px=1pb=1/72". Wenn also das Bild eine andere Auflösung hat, dann muss natürlich die viewport-Angabe angepasst werden. Meist ist es deshalb eine gute Idee, zunächst ohne clip zu arbeiten, dann sieht man eher, ob man den richtigen Ausschnitt gewählt hat. Eine gute Idee ist auch, direkt in GIMP mal im Bildmenü den Menüpunkt zur Druckgröße auszuwählen. Dort sieht man auch die Auflösung.

[Bartman]

Informiere Dich bitte über die Befehle, die Du für die Einstellung der Breite Deiner Abbildungen verwendest.

Benutze \newlength mit \setlength oder \def bzw. \newcommand.

Du könntest in diesem Zusammenhang eventuell auch subcaption gebrauchen.

[Roman_95]

Hallo,

ich habe drei Bilder eingebunden, um zu zeigen dass es bei .png NICHT funktioniert, bei .jpg jedoch schon. Wie gesagt, es scheint mit dem GIMP-Export zusammen zu hängen, da das gleiche Bild aus Paint als .png eingebunden wird. Das Problem tritt auch auf, wenn ich nur das Bild einbinde....

Auflösung, Bildgröße etc. sind alle konsistent geblieben, also alle Dateien (auch z.B. die .xcf von GIMP) hatten die gleichen Werte.

...Ich konnte aber den Grund herausfinden, es lag tatsächlich am GIMP-Export:

Man muss in der Einstellungsmaske Für den .png-Export den Haken bei 'Auflösung speichern' entfernen (standardmäßig gesetzt, s. Anhang).


Trotzdem danke allen die sich mit dem Problem befasst haben!

Eine Frage hätte ich noch @Bartmann:

Du schriebst folgendes:

Informiere Dich bitte über die Befehle, die Du für die Einstellung der Breite Deiner Abbildungen verwendest.

Benutze \newlength mit \setlength oder \def bzw. \newcommand.

Du könntest in diesem Zusammenhang eventuell auch subcaption gebrauchen.

Aber wenn ich deine Nachricht richtig verstehe, dann habe ich im zweiten MM das ganze doch richtig verwendet, oder nicht (\newlength mit def - oder soll man diese Kombination nicht benutzen)? Im ersten MM war das mit \linewidth wie gesagt nur ein Hack....

VG, Roman