Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie verlustfrei ist "verlustfreies Drehen"?
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
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. :-)
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).
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".
Für FixFoto gibt es doch ein eigenes Forum.
Frag doch da mal nach.
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.
@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
27.07.2004, 21:06
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:
Ein komprimiertes JPEG läßt sich unter keinen Umständen mehr entpacken.
:?: Huch? Tippfehler? :lol:
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.
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.
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.
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. :oops:
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
Dein Überlegungen stimmen schon teilweise. Ich habe auf der Suche nach Tempo bereits mehrere Algorithmen zur Bildbearbeitung erstellt.
Dabei läuft es aber immer auf das gleiche raus: Um ein JPEG-Bild in irgendeiner Weise sinnvoll bearbeiten zu können, muß es wieder als Matrix (Bitmap) hergestellt werden.
Natürlich stimmt das was du sagst bezüglich der einzelnen "Blöcke". Aber für diese Berechnung wird eben eine Matrix verwendet. Würde man das Bild nur auf Basis der nativen JPG-Information umrechnen wollen, würde das noch mehr Ressourcen in Anspruch nehmen.
Ich will aber nicht sagen, daß es ein echtes verlustfreies Drehen nicht gibt.
Man muß zunächst das Seitenverhältnis ermitteln und dann jedes einzelnen Byte in einem neuen ByteArray anordnen.
Dazu müsste man zunächst alle Bytearrays im Hauptspeicher anlegen, weil es ja nicht möglich ist die neue Position zu bestimmen bevor man die alte kennt. Der Computer kann ja nicht wirklich was mit der Information "von da bis da" anfangen.
Daraus sollte dann ein Verlustfreies Bild entstehen, das aber natürlich logischerweise wieder die volle Größe der Bitmap hat.