mit GIMP bearbeitete Grafiken werden nicht eingebunden

Antwort erstellen


Diese Frage dient dazu, das automatisierte Versenden von Formularen durch Spam-Bots zu verhindern.
Smilies
:D :) :( :o :shock: :? 8) :lol: :-x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen:

BBCode ist eingeschaltet
[img] ist eingeschaltet
[flash] ist ausgeschaltet
[url] ist eingeschaltet
Smilies sind eingeschaltet

Die letzten Beiträge des Themas

Ich habe die Datenschutzerklärung gelesen und bin damit einverstanden.

   

Wenn du eine Datei oder mehrere Dateien anhängen möchtest, gib die Details unten ein.

Ansicht erweitern Die letzten Beiträge des Themas: mit GIMP bearbeitete Grafiken werden nicht eingebunden

von Gast » Do 17. Jan 2019, 22:50

Bitte lies auch mal eine richtige LaTeX-Einführung. Längen ändert man nicht mit \def, sondern immer mit \setlength. Mit \def macht man aus der Länge ein Makro und beschädigt sie daher maximal. Das führt früher oder später zu Problemen!

Deine Fehlinterpretation von px und deine Verweigerung zu glauben, dass deine viewport-Angabe schlicht nicht zum Bild passt, sind andere Hinweise, dass du dich näher mit der Materie beschäftigen solltest.

Das Problem liegt jedenfalls nicht an GIMP, sondern an einer Fehlbedienung in Folge fehlenden Verständnisses.

von u_fischer » Do 17. Jan 2019, 19:31

Laut deiner log-Datei ist dein Bild 154.176pt x 57.816pt groß. Dein Viewport ist daher *außerhalb* des Bildes und es ist wohl aus dem selben Grund nicht sichtbar, aus dem hier das zweite Bild fehlt:
\documentclass{article}
\usepackage{graphicx}


\begin{document}
\includegraphics{example-image-duck}

\includegraphics[viewport=200px 10px 600px 200px,clip]{example-image-duck}

\end{document}

... es lag an GIMP

von Roman_95 » Do 17. Jan 2019, 18:06

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:
Bartman hat geschrieben: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
Dateianhänge
Export_Standardwerte.JPG
Export_Standardwerte.JPG (83.19 KiB) 3547 mal betrachtet
Export_funktionierend.JPG
Export_funktionierend.JPG (82.8 KiB) 3546 mal betrachtet

von Bartman » Do 17. Jan 2019, 17:24

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.

von Gast » Do 17. Jan 2019, 16:05

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.

von Gast » Do 17. Jan 2019, 15:55

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.

... es muss wohl an GIMP liegen

von Roman_95 » Do 17. Jan 2019, 15:16

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
Dateianhänge
untitled-2.log
(12.89 KiB) 182-mal heruntergeladen
untitled-2.pdf
(1.74 MiB) 202-mal heruntergeladen

von u_fischer » Mi 16. Jan 2019, 16:59

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.

von Roman_95 » Mi 16. Jan 2019, 16:38

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 :D
Dateianhänge
main.log
(117.17 KiB) 200-mal heruntergeladen

von u_fischer » Mi 16. Jan 2019, 16:13

\def\linewidth{0.3\textwidth} 
Wer hat dir denn das beigebracht?

Nach oben