[Igel]

Hallo!

In ACDSee 5.0 gibt es eine Funktion "Verlustfrei drehen". Wenn ich nun die Hochformatbilder drehe, ändert sich auch die Dateigröße (wird etwas kleiner (3.319.904 MB -> 3.231.096 MB). Bei FixFoto ändert sich die Dateigröße ebenfalls (wird deutlich größer (3.319.904MB -> 5.042.993MB). Wohlgemerkt, es handelt sich um das selbe Originalfoto!
Wie soll ich das verstehen? Eigentlich sollte doch eine "verlustfreie Drehung um 90 Grad" zum selben Ergebnis kommen? Woher kommen die vielen zusätzlichen Bytes bei FixFoto, bzw. wo bleiben die fehelnden Bytes bei ACDSee? Welches Programm dreht nun wirklich "verlustfrei"

Peter

[gismeth]

Hallo Igel,

ich könnte mir vorstellen, daß sich durch das drehen das Verhältnis Breite / Höhe ändert und die Breite nicht mehr durch 8 teilbar ist (1 Byte = 8 Bit (8 Pixel)).

Eine Datei auf der Festplatte muß aber mit ganzen Bytes geschrieben werden und deshlab wird das Programm wohl die fehlenden Pixel am rechten Rand dazumogeln, um wieder eine durch 8 teilbare Bildbreite zu bekommen.

Aber vorsicht: Alles nur graue Theorie, das muß so nicht stimmen. :-)

[hbert]

Beim Drehen wird das Bild komplett neu berechnet und interpoliert(!).
Anschließend wird das Ergebnis wieder im JPG_Format ausgegeben und komprimiert. Den Ratio der Komprimierung bestimmt das jeweilige Programm (bei Viewern wie diesen).

[gismeth]

Hallo hbert,

"Verlustfrei drehen" komprimiert meines Wissens nicht neu.

Es ist bei JPG-komprimierten Bildern möglich die Daten zu drehen ohne sie zuvor entpacken zu müssen. Dennoch bleibt wohl das Problem der "ungerade Breite".

[Musi]

Für FixFoto gibt es doch ein eigenes Forum.
Frag doch da mal nach.

[hbert]

Ach ja: Durch die beschriebene Prozedur ist ein "verlustfreies Drehen" nicht möglich. Aber ein verlustfreies Abspeichern des interpolierten Ergebnisses ist mit jedem Grafikprogramm möglich, welches unkomprimierte Formate (z. B. BMP) speichern kann.

[hbert]

@gismeth:

Ein komprimiertes JPEG läßt sich unter keinen Umständen mehr entpacken. Es entsteht durch die Komprimierung ein neues Bild indem bestimmte Bereiche tatsächlich neu interpretiert werden.

Man kann sich das so vorstellen: In dem Bereich v - y (eigentlich die Matrix einer Bitmap) weichen die Werte der Pixel um x Prozent voneinander ab. Diese Abweichung ist unter bestimmten Voraussetzungen zu vernachlässigen (Ratio beim Komprimieren).

Also gibt es nun nicht mehr die (Bitmap-)Information
v=00000011
w=00000010
x=00000011
y=00000010

sondern jetzt die Koprimierte (JPG-)Version
v-y=00000010

Der Bildbetrachter mach dann daraus im Arbeitsspeicher wieder
v=00000010
w=00000010
x=00000010
y=00000010

Die Seitenverhältnisse bleiben davon unberührt.

[giraffengero]

Zitat von Igel

Bei FixFoto ändert sich die Dateigröße ebenfalls (wird deutlich größer (3.319.904MB -> 5.042.993MB).

Hallo Peter,

wenn diese Dateivergrößerung eintritt, hast du sicher versucht, ein geöffnetes Bild zu drehen!
Das verlustfreie Drehen funktioniert bei FixFoto in der Computeransicht ohne große Dateigrößenänderung.

[gismeth]

Zitat von hbert

@gismeth:

Ein komprimiertes JPEG läßt sich unter keinen Umständen mehr entpacken.

Huch? Tippfehler?

Zitat von hbert

Es entsteht durch die Komprimierung ein neues Bild indem bestimmte Bereiche tatsächlich neu interpretiert werden.

Ich stecke zwar nicht unbedingt 100% im Thema, aber eigentlich dachte ich, daß das Ergebnis der Kompression eine -wie auch immer geartete- Dimension in Höhe und Breite aufweist. Und daß sich genau diese Datenmenge "drehen" läßt ohne die darin enthaltene Bildinformation erst wieder entpacken zu müssen.

Zitat von hbert

Also gibt es nun nicht mehr die (Bitmap-)Information
v=00000011
w=00000010
x=00000011
y=00000010

sondern jetzt die Koprimierte (JPG-)Version
v-y=00000010

Der Bildbetrachter mach dann daraus im Arbeitsspeicher wieder
v=00000010
w=00000010
x=00000010
y=00000010

Gut, nehemen wir also diesen Bildblock:
abcdefgh
v=00000011
w=00000010
x=00000011
y=00000010

und hier die komprimierte JPG-Version...
abcdefgh
v-y=00000010

und jetzt denken wir uns noch 8 weitere komprimierte Blöcke dazu:

abcdefgh
v1-y1=01010101
v2-y2=10101001
v3-y3=00000000
v4-y4=11111111
v5-y5=01010101
v6-y6=10101001
v7-y7=00000000
v8-y8=11111111

... dann kann man auch diese wieder drehen (z.B. links rum):

v1/y1 bis v8/y8 ->
h 11011101
g 00010001
f 10011001
e 01010101
d 10011001
c 01010101
b 10011001
a 01010101

Jetzt verlaufen die ehemals horizontal ausgerichteten Daten vertikal und die ehemals vertikalen Daten horizontal.

Das ist jetzt nur ein ziemlich vereinfachtes Beispiel, aber so ähnlich muß es gehen.
Weil: Drehe doch mal ein sehr grosses Bild verlustlos auf einem langsamen Rechner. Dann wird man feststellen, daß der Rechner das Bild niemlas in dieser Zeit hätte entpacken, drehen und wieder JPG packen können.

[Igel]

Zitat von giraffengero

wenn diese Dateivergrößerung eintritt, hast du sicher versucht, ein geöffnetes Bild zu drehen!
Das verlustfreie Drehen funktioniert bei FixFoto in der Computeransicht ohne große Dateigrößenänderung.

Stimmt - jetzt habe ich es nochmal probiert, ohne das Bild zu öffnen. Das gedrehte Bild ist - wie beim drehen mit ACDSee etwas kleiner, als zuvor. Der Unterschied zwischen drehen mit ACDSee und FixFoto ist minimal.

Zitat von gismeth

Gut, nehemen wir also diesen Bildblock:
abcdefgh
v=00000011
w=00000010
x=00000011
y=00000010

und hier die komprimierte JPG-Version...
abcdefgh
v-y=00000010

und jetzt denken wir uns noch 8 weitere komprimierte Blöcke dazu:

abcdefgh
v1-y1=01010101
v2-y2=10101001
v3-y3=00000000
v4-y4=11111111
v5-y5=01010101
v6-y6=10101001
v7-y7=00000000
v8-y8=11111111

... dann kann man auch diese wieder drehen (z.B. links rum):

v1/y1 bis v8/y8 ->
h 11011101
g 00010001
f 10011001
e 01010101
d 10011001
c 01010101
b 10011001
a 01010101

Jetzt verlaufen die ehemals horizontal ausgerichteten Daten vertikal und die ehemals vertikalen Daten horizontal.

Das ist jetzt nur ein ziemlich vereinfachtes Beispiel, aber so ähnlich muß es gehen.
Weil: Drehe doch mal ein sehr grosses Bild verlustlos auf einem langsamen Rechner. Dann wird man feststellen, daß der Rechner das Bild niemlas in dieser Zeit hätte entpacken, drehen und wieder JPG packen können.

Also mal ehrlich: dieses "ziemlich vereinfachte" Beispiel ist zu hoch für mich.
Mein Hauptproblem - der enorme Größenunterschied zwischen FF und ACDSee ist gelöst - Danke! Und so tief wollte ich gar nicht in die Theorie einsteigen.
Der Einfachheit halber werde ich bei meiner bisherigen Methode (drehen mit ACDSee in einen neuen Ordner, zusätzlich speichern der nicht gedrehten Originale) bleiben.

Peter