Forum Übersicht - RE: JPG, Verlust durch nachträgliches Drehen? - 2

Hey Bruno,

beim Kopieren oder Verschieben passiert nix. Es werden ja nur die Daten 1:1 kopiert oder verschoben.


Dat Ei

Zitat von schmidi

---

Da habe ich auch noch eine frage dazu.

Wie ist es den wenn ich Bilder von einer Datei oder Festplatte in die nächste Kopiere oder verschiebe, gibt es da auch einen Verlusst oder kann man die beliebig verschieben?


Gruss und Danke

Bruno

---

Da darf nix passieren. Stell dir mal vor, du kopierst oder veränderst eine Textdatei und da würden auf einmal die Buchstaben durcheinandergewirbelt!

Zitat von Dennis

---

... Außerdem entstehen beim Öffnen niemals Verluste, immer nur beim Speichern. ...

---

Darum habe ich ja auch geschrieben:
ZITATwenn ich ein JPG öffne und ... wieder speichere[/quote]

Zitat von Dennis

---

Zitat von thomasD

---

Verliere ich nicht schon Daten, wenn ich ein JPG öffne und - mit der gleichen, verlustbehafteten Kompressionsrate - wieder speichere?

---

Nein, denn bei der ersten Speicherung als JPEG wird das Farbsubsampling vorgenommen, die 8x8-Matrizen definiert und die Quantisierung an Hand der Kompressionsstufe vorgenommen. Eine zweite Komprimierung mit identischen Daten und Parametern "findet" dann nichts mehr zum einsparen. Die Verluste entstehen nur, wenn man andere Einstellungen vornimmt, oder die Bilddaten ändert. Außerdem entstehen beim Öffnen niemals Verluste, immer nur beim Speichern.

---

Na, dass man nur öffnet und dann wieder speichert, ist ja eher selten. Meistens ändert man doch irgendetwas. Verbessert Kontraste und/oder Farben, beschneidet das Bild, entfernt Rauschen, schärft nach... Wenn ich dann wieder speichere, muss doch eine neue Komprimierung erfolgen, da sich die Bildinhalte ja geändert haben.

Nach meinem technischen Verständnis wäre es aber vor allen Dingen dann kritisch, wenn ich das geänderte Bild speichere, das EBV-Programm beende, neu starte, das Bild neu öffne, wieder verändere, speichere usw. Wenn ich einfach während des Bearbeitens nach jedem Bearbeitungsschritt eine "Sicherheitskopie" abspeichere, dürfte es keine negativen Folgen haben, da die Bilddaten ja weiter unverändert im Arbeitsspeicher des Rechners bleiben und von dem Speichervorgang unberührt bleiben (wurde ja weiter oben auch so erläutert).

Christian

Zitat von Goodspeed

---

Nach meinem technischen Verständnis wäre es aber vor allen Dingen dann kritisch, wenn ich das geänderte Bild speichere, das EBV-Programm beende, neu starte, das Bild neu öffne, wieder verändere, speichere usw. Wenn ich einfach während des Bearbeitens nach jedem Bearbeitungsschritt eine "Sicherheitskopie" abspeichere, dürfte es keine negativen Folgen haben, da die Bilddaten ja weiter unverändert im Arbeitsspeicher des Rechners bleiben und von dem Speichervorgang unberührt bleiben (wurde ja weiter oben auch so erläutert).

---

/smile.gif" style="vertical-align:middle" emoid="" border="0" alt="smile.gif" /> Wie kommst Du denn darauf?

Das hat doch nichts mit dem Arbeitsspeicher zu tun. Beim JPEG-Algorithmus wird zuerst mal ab einer bestimmten Kompresionsstufe ein Farbsubsampling vorgenommen. Dafür wird zu erst mal das Bild in den YCbCr-Farbraum überführt, und dann die Cr und Cb-Kanäle so skaliert, daß 2 oder 4 ursprüngliche Pixel einen neuen ergeben. Danach wird das Bild in 8x8 Pixel-Blöcke eingeteilt, und innerhalb dieser der linke obere als Referenzpunkt definiert. die restlichen 63 Pixel werden über eine mathematische Funktion als Abstände zu diesem Pixel beschrieben. Jetzt kommt der schädlichste Schritt: Die Quantisierung. Dort werden die bisher stetigen Werte in diskrete überführt. Dabei passieren die schlimmsten Rundungsfehler.

Wenn sich also nur die Farbwerte innerhalb der 8x8-Matrix verändern, verliert man eigentlich keine Qualität. Schlimm wird es nur, wenn man die Abmessungen des Bildes verändert. Und natürlich richtet bei unterschiedlichen Kompressionen die mit der höchsten Stufe die schlimmsten Schäden an.

Na ja, so was ähnliches meinte ich. Hab es vielleicht ein bisschen falsch ausgedrückt. Danke für die Aufklärung.

Christian

Zitat von Dennis

---

Zitat von Goodspeed

---

Nach meinem technischen Verständnis wäre es aber vor allen Dingen dann kritisch, wenn ich das geänderte Bild speichere, das EBV-Programm beende, neu starte, das Bild neu öffne, wieder verändere, speichere usw. Wenn ich einfach während des Bearbeitens nach jedem Bearbeitungsschritt eine "Sicherheitskopie" abspeichere, dürfte es keine negativen Folgen haben, da die Bilddaten ja weiter unverändert im Arbeitsspeicher des Rechners bleiben und von dem Speichervorgang unberührt bleiben (wurde ja weiter oben auch so erläutert).

---

/smile.gif" style="vertical-align:middle" emoid="" border="0" alt="smile.gif" /> Wie kommst Du denn darauf?

Das hat doch nichts mit dem Arbeitsspeicher zu tun. Beim JPEG-Algorithmus wird zuerst mal ab einer bestimmten Kompresionsstufe ein Farbsubsampling vorgenommen. Dafür wird zu erst mal das Bild in den YCbCr-Farbraum überführt, und dann die Cr und Cb-Kanäle so skaliert, daß 2 oder 4 ursprüngliche Pixel einen neuen ergeben. Danach wird das Bild in 8x8 Pixel-Blöcke eingeteilt, und innerhalb dieser der linke obere als Referenzpunkt definiert. die restlichen 63 Pixel werden über eine mathematische Funktion als Abstände zu diesem Pixel beschrieben. Jetzt kommt der schädlichste Schritt: Die Quantisierung. Dort werden die bisher stetigen Werte in diskrete überführt. Dabei passieren die schlimmsten Rundungsfehler.

Wenn sich also nur die Farbwerte innerhalb der 8x8-Matrix verändern, verliert man eigentlich keine Qualität. Schlimm wird es nur, wenn man die Abmessungen des Bildes verändert. Und natürlich richtet bei unterschiedlichen Kompressionen die mit der höchsten Stufe die schlimmsten Schäden an.

---

@Dennis

Lang ist's her, aber ich habe die Schritte der JPEG-Kompression nach ITU T.81 wie folgt verstanden:

1. Konversion des RGB-Farbraums in den YUV-Farbraum (YCbCr; IEC 601) durch Renormierung der Farbdifferenzsignale. Dieser Farbraum diente ursprünglich der Kompatibilität des PAL-Systems mit dem SW-Fernsehen. Diese Konversion wirkt NICHT reduzierend und ist reversibel.
2. Jetzt wird der Hammer rausgeholt: Eine Tiefpassfilterung reduziert die Chrominanzwerte drastisch, wegen der Erkenntnis, daß das Auge Helligkeitunterschiede deutlicher wahrnimmt als als Farbunterschiede.
3. Die folgende Blockbildung ist eine einfache Cosinustransformation (DCT), d.h. es existiert für diesen Schritt eine inverse Funktion und es entstehen keine Verluste.
4. Die jetzt folgende Quantisierung reduziert die Ursprungsinformationen deutlich. Aus den bisher verlustfreien DCT-Koeffizienten werden Quantisierungsmatrizen errechnet, die möglichst optimal die Emfindlichkeiten des Auges widerspiegeln sollen. Diese Daten finden wir im DQT-Tag der JPEG-Datei.
5. Es folgen die Schritte Umsortierung (Zick-Zack), Differenzkodierung und Entropiekodierung (meist Huffmann).

Das Dekodieren verläuft in der umgekehrten Reihenfolge:

1. Entropie-Dekodierung und Umsortierung: Kein Verlust.
2. Requantisierung: Verlust.
3. Inverse Cosinustransformation: Kein Verlust.
4. Tiefpaßfilterung mit Überabtastung der Farbdifferenzsignale: Verlust.
5. Farbraumumrechnung vom YUV-Farbraum nach RGB: kein Verlust.


Daraus folgt, daß ein Dekodier-Kodier-Zylus immer mit einem Informationsverlust behaftet ist. Daß dieser sehr gering ausfällt, spricht für das JPEG-Verfahren. Die Verluste können minimiert werden, wenn die gleiche Quantisierungstabelle verwendet wird und die Blockgrenzen nicht verändert werden.

Bei Bildspiegelungen, Bilddrehungen um ein Vielfaches von 90° und Beschnitt von Bildrändern um Vielfache von 16 Pixel können Verluste vermieden werden.

Wie die Bearbeitungssoftware aber mit den JPEG-Dateien tatsächlich umgeht, bleibt dem normalen Anwender aber meist verschlossen.

einen schönen Tag wünscht

Joachim

Zitat von jotagamma

---

Lang ist's her...

---

/smile.gif" style="vertical-align:middle" emoid="" border="0" alt="smile.gif" /> Ja, bei mir auch, allerdings habe ich mir nicht die Mühe gemacht, es nachzuschlagen...

ZITAT1. Konversion des RGB-Farbraums in den YUV-Farbraum (YCbCr; IEC 601) durch Renormierung der Farbdifferenzsignale. Dieser Farbraum diente ursprünglich der Kompatibilität des PAL-Systems mit dem SW-Fernsehen. Diese Konversion wirkt NICHT reduzierend und ist reversibel.[/quote]

Korrekt. Die Rundungsfehler hier halten sich sehr in Grenzen, ganz verlustfrei geht es natürlich nicht ab. Im Zuge der Farbraumkonvertierungen kann es schon passieren, daß man bei RGB -> ? -> RGB nicht wieder genau auf dem ursprünglichen Wert landet.

ZITAT2. Jetzt wird der Hammer rausgeholt: Eine Tiefpassfilterung reduziert die Chrominanzwerte drastisch, wegen der Erkenntnis, daß das Auge Helligkeitunterschiede deutlicher wahrnimmt als als Farbunterschiede.[/quote]

/huh.gif" style="vertical-align:middle" emoid="" border="0" alt="huh.gif" /> Also, das mit der Tiefpass-Filterung habe ich noch nie gehört, und habe damals einige Schinken bezüglich JPEG-Verfahren gewälzt. ME ist das auch nicht ganz korrekt, weil es dazu laut Spezifikation keine feste Schwelle gibt, ab wann das Farbsubsampling beginnt, das regeln die Applikationen individuell und legen das im entsprechenden tag ab. Subsampling bedeutet lediglich, daß eine 2x2-Matrix oder 1x2-Matrix auf einen Pixel reduziert wird. Meinst Du das vielleicht mit Tiefpassfilter?

ZITAT3. Die folgende Blockbildung ist eine einfache Cosinustransformation (DCT), d.h. es existiert für diesen Schritt eine inverse Funktion und es entstehen keine Verluste.[/quote]

Nö, also das stimmt so nicht. Die Blockbildung hat mit der DCT nichts zu tun. Die Blockbildung ist ein Vorgang, danach erfolgt innerhalb der Blöcke die Anwendung der DCT.

ZITAT4. Die jetzt folgende Quantisierung reduziert die Ursprungsinformationen deutlich. Aus den bisher verlustfreien DCT-Koeffizienten werden Quantisierungsmatrizen errechnet,...[/quote]

Soweit so gut...

ZITAT...die möglichst optimal die Emfindlichkeiten des Auges widerspiegeln sollen.[/quote]

Ich glaube, ich weiß, was Du meinst. Nett ausgedrückt /smile.gif" style="vertical-align:middle" emoid="" border="0" alt="smile.gif" />

ZITATDaraus folgt, daß ein Dekodier-Kodier-Zylus immer mit einem Informationsverlust behaftet ist.[/quote]

Nein, die Decodierung ist sozusagen verlustfrei, es wird das decodiert, was da ist. Nur das, was da ist, wurde leider schon bei der Codierung verstümmelt. Was sagst, würde ja bedeuten, das in der gespeicherten Datei noch alle Informationen enthalten sind, und diese erst beim Öffnen verlorengehen. Das das aber so nicht ist, hast Du ja selber oben schon erklärt.

Zitat von Zirkon

---

Zitat von Mark

---

LZW sei hier nur als beispiel benannt. Die Probleme können also auch da vorhanden sein.

---

LZW ist aber ein verlustfreier Algorithmus...

---

Der Meinung war ich auch immer. Falls das nicht so ist, bitte ich um Aufklärung.

Soweit ich weiß, wird dabei eine Tabelle mit sich häufig wiederholenden Zeichenketten angelegt, und dann für jede Zeichenkette nur noch ein Pointer auf die Tabellenzeile gesetzt. Dieses Prinzip arbeitet verlustfrei.

Zitat von Dennis

---

Soweit ich weiß, wird dabei eine Tabelle mit sich häufig wiederholenden Zeichenketten angelegt, und dann für jede Zeichenkette nur noch ein Pointer auf die Tabellenzeile gesetzt. Dieses Prinzip arbeitet verlustfrei.

---

Wers genau wissen will, siehe http://www.dogma.net/markn/articles/lzw/lzw.htm

1. Also, ich habe mir jetzt mal die offizielle Doku ITU Recommendation T.81 heruntergeladen, weil ich es genau wissen will. Wir finden sie unter
http://www.w3.org/Graphics/JPEG/itu-t81.pdf

2. LZW ist verlustfrei. Das kann ich deshalb sagen, weil ich mit diese Algorithmen in meiner Jugendzeit selbst einmal gearbeitet (entwickelt) habe und ich heute im hohen Alter die damit komprimierten Texte immer noch decodieren kann /biggrin.gif" style="vertical-align:middle" emoid="" border="0" alt="biggrin.gif" /> .

Gruß

Joachim

Als kleiner Abschweif zur ursprünglichen Frage /wink.gif" style="vertical-align:middle" emoid="" border="0" alt="wink.gif" />

auch mit dem kostenlosen Irfanview ist ein verlustfreies Rotieren von JPEG-Bildern möglich. Außerdem kann man Irfanview so einstellen, dass bei der Anzeige automatisch die EXIF-Information zur richtigen Ausrichtung der Bilder verwendet wird.

Gruß,
Andreas

Oha, hier geht's ja richtig zur Sache... ich wußte nicht, daß man soviele Leute mit dem simplem Drehen von Bildern beschäftigen kann /wink.gif" style="vertical-align:middle" emoid="" border="0" alt="wink.gif" />

Aus der Praxis:

Ich habe in PaintShopPro 6.x ein JPG geladen. Dann wollte ich es direkt ohne Drehung wieder in JPG speichern. Im Speicher-Dialog gibt's unter "Optionen" die Mäglichkeit, die Kompression einzustellen. Leider ist kein Wert unter "1" möglich. Logisch, daß das Bild nun weniger Speicherplatz benötigt.
Also in PaintShopPro ist nicht einmal eine Speicherung ohne Änderung am Bild ohne Verluste möglich.

Zweiter Versuch dann mit dem Bildbetrachter XnView (mein Favorit, da sehr klein und leistungsfähig): Hier kann man sogar die Option anwählen "Drehen ohne Verlust". Die EXIF-Daten bleiben auch erhalten, allerdings hat das gedrehte Bild wieder ein paar kB weniger, als das ursprüngliche Bild.

Weitere Software steht mir momentan nicht zur Verfügung.

Ich habe noch die Möglichkeit, das Bild direkt in meiner Kamera zu drehen. Ich meine aber, daß es nicht gedreht "herauskommt" /huh.gif" style="vertical-align:middle" emoid="" border="0" alt="huh.gif" /> ...muß ich nochmals nachschauen.

Gruß
Heiko

Also ich benutze zum drehen ACDSee 7 und das geht absolut verlustfrei /good.gif" style="vertical-align:middle" emoid="" border="0" alt="good.gif" />

LG

Alex /smile.gif" style="vertical-align:middle" emoid="" border="0" alt="smile.gif" />

Zurück zur eigentlichen Frage des verlustfreien Drehens.

Ich habe den Dimage Viewer 3.37, den es kostenlos zum runterladen bei Minolta gibt.
http://download2.konicaminoltaeurope.com/o...&ml=0&rid=&sub=

Hier wird die "Image orientation" in der EXIF-Info", also eine Dreh-Information benutzt (keine Drehung, + oder - 90 Grad). Er verwendet diese Info, um die Bilder richtig gedreht anzuzeigen. Diese Drehinfo wird z.B. mit der 7D beim Drehen der Bilder erzeugt oder kann auch nachträglich im Viewer geändert werden.

Microsoft (Datei-Explorer, Picture Manager, Picture and FAX-Viewer) verwendet leider diese Dreh_Info nicht.
Auch ein Drehen der Bilder in Mirocsoft erfolgt nicht verlustfrei.

Möchte man die Bilder wirklich drehen, sind die vorher genannten Programme geeignet.