Laden...

[gelöst] Von GIF zum Stream dann zum ByteArray und dann wieder zu GIF: Bildgröße ändert sich

Erstellt von xiconluan vor 10 Jahren Letzter Beitrag vor 10 Jahren 2.228 Views
X
xiconluan Themenstarter:in
3 Beiträge seit 2013
vor 10 Jahren
[gelöst] Von GIF zum Stream dann zum ByteArray und dann wieder zu GIF: Bildgröße ändert sich

Hallo einen schönen morgen euch allen,
ich habe leider ein kleines Problem (die Suche hier im Forum habe ich schon bemüht und auch google, aber ich hab das gefühl für meinen Fall stochere ich ein bisschen im Dunkeln). Also mein Code sieht wie folgt aus:


byte[] txtByte = null;
FileStream fs = new FileStream("D:/testbild.gif", FileMode.Open, FileAccess.ReadWrite);

txtByte = new byte[fs.Length];
fs.Read(txtByte, 0, System.Convert.ToInt32(fs.Length));

MemoryStream fsNew = new MemoryStream(txtByte);

Image myPic = Image.FromStream(fsNew);
myPic.Save("D:/superBild.gif", System.Drawing.Imaging.ImageFormat.Gif);

Ich erhalte ein neues Bild mit dem Inhalt vom Original ABER die Größe stimmt nicht

es sind immer im neuen Bild 640 x 480
das Original Bild hat aber 739 x 599

Es sei noch erwähnt, dass ich das ByteArray benötige, da ich später DICOM-"Dateien" einlesen will und ich dann dort die Bilddaten entnehmen möchte.

Wie bekomme ich das neue Bild in die richtige Größe?
[Edit] Ich habe jetzt nochmal beide Bilder angehängt. [Edit Ende]

Vielen Dank schon im Voraus

xiconluan

Eingabebild:

X
xiconluan Themenstarter:in
3 Beiträge seit 2013
vor 10 Jahren
Von GIF zum Stream dann zum ByteArray und dann wieder zu GIF: Bildgröße ändert sich

Ausgabebild:

49.485 Beiträge seit 2005
vor 10 Jahren

Hallo xiconluan,

wenn ich deinen Code nehme und damit ein eigenes Beispielbild speichere, dann ist es so groß wie das Ausgangsbild. Allerdings unterscheiden sich die Dateien in Dateigröße und Byte-Inhalt, sind aber pixelweise gleich. Fakt ist, dass durch den Code das Bild neu codiert wird.

Da es bei dir zu Abweichungen in der Bildgröße kommt, würde ich auf einen Einfluss der DPI-Zahl tippen. Allerdings speichern GIFs eigentlich keine DPIs. Trotzdem wäre das erstmal meine einzige Erklärung. An anderen Stellen (z.B. DrawImage) hatte ich das Problem der ungewollten Bildgrößenänderung durch abweichende DPI-Zahlen jedenfalls schon.

Wenn du das Bild so speichern willst, das es mit dem Original identisch ist, dann speichere einfach das Byte-Array (bzw. den Memorystream) binärer in der Zieldatei.

herbivore

PS: Wenn ich es mit deinem Bild probiere, habe ich genau den gleichen Effekt, also Änderung von 739x599 auf 640x480 Pixel.

X
xiconluan Themenstarter:in
3 Beiträge seit 2013
vor 10 Jahren

Guten Morgen herbivore,

vielen Dank !
Ich habe es nun auch mit zwei anderen Bildern versucht sowohl png (natürlich System.Drawing.Imaging.ImageFormat.Gif in Png geändert) als auch einem anderen gif - und siehe da, diese sind exakt "kopiert". Es scheint wirklich an meinem ersten Testbild zu liegen.

Sowas aber auch ... Und ich dachte die ganze Zeit es liegt an meinem Code 😃
So kann man sich irren.

Vielen Dank

Grüße

xiconluan

49.485 Beiträge seit 2005
vor 10 Jahren

Hallo xiconluan,

ich habe mit gfoidl gesprochen und er hat mich darauf aufmerksam gemacht, dass das Bild gar nicht verkleinert wird (resize), sondern dass es sich bei dem Ergebnis um einen Bildausschnitt handelt (crop). Daher wird es wohl nicht, wie von mir vermutet, an den DPI-Werten liegen. Was es genau ist, weiß ich trotzdem nicht. gfoidl hatte des Bild mit Paint geöffnet, und da wird es schon abgeschnitten geladen. Merkwürdig!

herbivore

6.911 Beiträge seit 2009
vor 10 Jahren

Hallo xiconluan,

ich hab das ursprüngliche GIF mit einem Bidlbearbeitungsprogramm (Expression Design) geöffnet und als neues GIF gespeichert, anschließend ein Diff auf Hex-Basis durchgeführt. Aufgefallen dabei ist dass das neue GIF eine andere Version hat (89a statt 87a), aber daraus kann das "Phänomen" wohl kaum kommen. Weiters ist mir aufgefallen, dass beim ursprünglichen eine Menge Zero-Padding vorhanden ist.

Ob nun dieses Zero-Padding die Ursache ist kann ich nicht mit Sicherheit sagen, aber es wäre möglich dass dadurch die Größenberechnung zu einem falschen Ergebnis kommt und somit das Bild falsch einliest (da die Zeros ignoriert werden) und das Bild letztlich beschnitten dargestellt wird.

Das Paddings könnte aber auch von einer anderen Farbtabelle, deren Einträge genullt wurden, stammen.

Um die genaue Ursache zu erforschen wäre ein Studium der GIF-Spezifikationen nötig, dazu hab ich zwar Interesse aber leider keine Zeit, daher werde ich das (zumindest jetzt) nicht mehr näher untersuchen.

Wo stammt das Bild denn her?

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

S
248 Beiträge seit 2008
vor 10 Jahren

Hallo xiconluan,

das Bild hat die folgenden zwei Metadateneinträge:
LogicalHeight: 480
LogicalWidth: 640
(Namen kommen aus FreeImage, ob dies die korrekten Bezeichner laut Spezifikation sind weiß ich nicht).

Je nach Anwendung/Implementierung wird wohl diese Auflösung verwendet beim Lesen/Schreiben des Bildes.

Ich würde mir eine Gif-Spezifikation suchen, und nachschauen wie Metadaten die Größe beeinflussen können.

edit:

Laut FreeImage-Dokumentation sind es keine echten Metadaten, sondern Animationsdaten (die in FreeImage ähnlich wie Exif-Metadaten behandelt werden.

Hier aus der Doku:

The Animation metadata model is a generic model used to load and save animation metadata attached to an animated file (such as a GIF or a MNG file).
[...]
LogicalWidth
Width of entire canvas area that each page is displayed in 0-65535
[...]
LogicalHeight
Height of entire canvas area that each page is displayed in 0-65535

Vielleicht hilft dir das weiter, ggf musst du diese Werte auf die "richtige" Größe setzten.

Grüße
spooky