Warum speichert meine 1-Bit-8x8-Bitmap in Photoshop mehr als 8 Bytes?

Ich möchte, dass mein 8x8 als rohe Binärdatei herauskommt; es sollte 8 Byte oder 64 Bit sein. Es kommt jedoch viel größer heraus; Speichern als PNG gab mir 154 Bytes; Das Speichern als BMP gab mir 64 Bytes (8 mal größer als es sein sollte).

Als ich ein neues Bild erstellte, sagte mir Photoshop, dass es 8 Bytes sein würde, offensichtlich ist dies nach dem Speichern nicht der Fall.

Das Allerniedrigste, was ich erreichen konnte, waren 12 Bytes, indem ich Save for Web verwendete und als Wbmp speicherte, aber ich möchte, dass es 8 Bytes sind. Es müssen binäre Rohdaten sein. Wie kann ich dieses Problem lösen?

EDIT: Und für diese Angelegenheit kommen andere niedrige Bitmengen höher als erwartet heraus. Warum wird ein 4-bpp-80x16-Bild mit 714 Bytes statt 640 ausgegeben?

Nun, Bildformate speichern mehr als nur Rohbilddaten
Das versuche ich zu erreichen; rohe Bilddaten.
Da Photoshop den Datei-Header speichern muss, der Programmen mitteilt, was Ihr Dateityp ist und wie es gelesen werden muss. Ich weiß nicht, dass Sie ein Bild einfach als Rohbild speichern können, da kein Programm es öffnen könnte. Darf ich fragen, was Sie die Rohbilddaten wollen?
Ich mache ein Spiel und versuche, es so klein wie möglich zu machen; Eine Möglichkeit, dies zu tun, besteht darin, Rohfarbindizes anstelle von "tatsächlichen Farben" zu speichern. was in diesem Fall 1-Bit ist, nur 0 und 1.
Hast du die Option "Save as Raw" in deiner Save-as-Liste? Es tut so ziemlich das, was es sagt.

Antworten (1)

Dateiformate enthalten eine Menge Dinge. Es stimmt zwar, dass Ihre Bitmap 8 Bytes groß sein kann, der Container, in dem sie gespeichert ist, jedoch nicht.

Beispielsweise benötigt eine PNG-Dateistruktur alle Arten von zusätzlichen Daten wie Fingerabdruck, Dateistrukturinformationen, Komprimierungsschema und Metadaten. Auch wenn vieles davon entfernt werden kann, Photoshop ist keineswegs optimal, die Datei wird immer noch viel größer als 8 Bytes sein.

Ein Analogon aus der realen Welt wäre ein Eimer. Während der Eimer ziemlich leicht ist, sagen wir 300 g, ist sein proportionales Gewicht ziemlich gering, wenn Sie den Eimer mit 10 Liter Wasser (3 %) oder Sand (2 % verlieren Kies) füllen. Das relative Gewicht des Behälters ist jedoch ziemlich erheblich, wenn Sie einen Zentiliter Wasser (3000%) transportieren möchten.

Alle Container haben einen Overhead. Zum Beispiel muss die Größe des Arrays irgendwo mitgeteilt werden und das allein frisst als solche Ihre Bilddaten auf. In diesem Zusammenhang ist es auch erwähnenswert, dass aufgrund der Funktionsweise von Laufwerken jede Datei eine feste Menge an Speicherplatz verbraucht, z. B. von 512 Byte bis zu mehreren Kilobyte oder so, dass es keinen Sinn macht, ultrakleine separate Dateien zu haben.

Was also tun?

  • Codieren Sie alle Ihre Bilddaten in einer einzigen Bilddatei, die als Bildatlas bezeichnet wird.
  • Schreiben Sie Ihre Bilddaten in Ihren Quellcode. Es wird immer noch größer als 8 Bytes sein, da die Array-Länge gespeichert werden muss. Dies kann jedoch unpraktisch sein.
  • Schreiben Sie Ihr eigenes Format, aber Sie kommen immer noch zum Containerproblem. Auch hier ist es am besten, mehrere Datenquellen in einer Speicherdatei abzulegen.
zu 2: nicht unbedingt; Arrays in C-Sprache speichern nirgendwo die Array-Länge. Übrigens können Sie solchen C-Quellcode automatisch in Gimp generieren - verwenden Sie das Dateiformat "XBM": #define bitmap_width 8 #define bitmap_height 8 static unsigned char bitmap_bits[] = { 0xfe, 0xfc, 0xf8, 0xf0, 0xe0, 0xc0, 0x80, 0x00 };
@szulat ja, aber die Person, die das Bild zu einem Elementarray zusammensetzt, muss wissen, wie hoch und breit dieses Array ist, um dieses Array sinnvoll zu verwenden oder einen Überlauf zu vermeiden. Auf jeden Fall muss irgendwie annotiert werden, dass es sich um ein 8 x 8 Bild handelt. Selbst wenn es im Lesegerät fest codiert ist, verbraucht es immer noch 2 Bytes an Daten, oder dies kann möglicherweise in einem Byte codiert werden, aber es benötigt trotzdem irgendwo etwas Platz.
@szulat Ihre XMB-Demo zeigt genau das, was ich sage, sie speichert zwei Werte für Breite und Höhe in der Quelle für insgesamt 10 Bytes Speichernutzung für satte 25% Container-Overhead
sicher, aber andererseits, wenn Sie den gleichen hartcodierten Algorithmus verwenden, um eine Million von 8x8-Bitmaps zu verarbeiten, haben Sie bereits 2x2x1000000-2x2 Bytes gespart :-]
#define verwendet genau 0 Bytes kompilierten Codes
@szulat Sicher, aber dann machst du einen Bildatlas, der auch ohne permanentes Codieren funktioniert, da der Overhead sinkt.
Die Größe / das Format usw. des Bildes muss meines Wissens nicht unbedingt im Bild gespeichert werden, solange Sie diese Daten irgendwo haben. Vielleicht wäre es sinnvoller, wenn ich sage, dass ich es nicht bin Versuchen Sie, hier eine "Bilddatei" zu speichern, aber nur die Daten des Bildes?
@Omega schreibt ein Skript, das die Rohdaten aus einer PNG-Datei entnimmt. Auf diese Weise können Sie die Informationen schnell skalieren, selbst wenn Sie eine beliebige Software verwenden