Wieviel Speicher braucht ein Pixel?

[localhost1]

Hallo, ich weiß nicht ganz ob das die Frage trifft was ich will:

Ich will ein Bild mit Java zeichnen lassen, es gibt nur Schwarz/weiß allerdings mit graustufen, und zwar 0 weiß bis 255 schwarz(meinetwegen umgekehrt) also 256 verschiedene "Farben" wenn man so will.

Das Bild hat exakt 2201*2201 Bildpunkte. Kann man hierraus den Speicher so einfach berechnen?


ein Bildpunkt wegen der 256 Farben also 1 Byte. dementsprechend kommen insgesamt etwa 4,62 MB raus wegen der 2201*2201 Bildpunkte? Was kommt mit Komprimierung raus(grob)?

 

[AlexSpritze]

Wie willst du das Bild denn zeichnen lassen?

Und meinst du den Speicher, wenn du das Bild auf die Festplatte geschrieben hast (z.B. als PNG oder JPEG?) oder während du eine Instanz des Bildes in deinem Java-Zeichen-Programm noch im RAM hälst?

 

[SlaterB]

die Komprimierung kann man offensichtlich nicht pauschal benennen,
ist das ganze Bild weiß, in der Mitte ein grauer einfarbier Kreis, so kann das Bild bestimmt besser komprimiert werden,
als wäre es die 256-Stufen-Variante eines Fotos mit viel Anzeige, z.B. Autogrammkarte von Christian Wulff

edit: egal ob allgemeine Zip-Techniken, oder spezielle Bild-Algorithmen wie jpeg

 

[localhost1]

Ich meine den Speicher den das Bild auf der Fesplatte braucht.

Gut das mit dem Komprimieren ist ne Sache für sich. Wie sieht es also ohne Komprimierung aus?


Für das Format habe ich mich noch nicht so richtig entschieden, es ist wichtig dass keine Verluste auftreten, habe mir dahingehend sagen lassen ich soll kein jpg nehmen

 

[Gast2]

Ich meine den Speicher den das Bild auf der Fesplatte braucht.

Was hindert dich daran einfach mal 4 5 Bilder im gewünschten Format mal abzuspeichern?

 

[SlaterB]

der Speicher auf der Platte hängt vom Format ab,
wenn du kein eigenes hast, etwa 2201*2201 direkt hintereinander ablegst, musst du wohl wenigstens mit etwas Overhead wie einem Header rechnen, in dem Informationen wie Länge/ Breite/ Farben drinsteht

probier doch einfach die bekannten Formate aus, auch welche von Java überhaupt unterstützt werden,
Hintergrundliteratur zu den Formaten wäre wohl günstig, welche komprimieren, welche nicht (png, bmp),

gut, danach fragst du hier wohl gerade, ich persönlich kann das nicht im Detail benennen,
als naheliegender Ausgangspunkt zum voraussichtlichen Abschied noch ein Wiki-Link:
Grafikformat ? Wikipedia

 

[localhost1]

Was hindert dich daran einfach mal 4 5 Bilder im gewünschten Format mal abzuspeichern?

Bevor ich was programmiere überlege ich ob es Sinn macht, bisher steht nur die Theorie und kein Code

 

[hdi]

Die Frage ist auch ob diese Bilddateien nur für dein Programm lesbar sein sollen oder allgemein, d.h. tatsächlich in einem gängigen Bildformat abgespeichert werden müssen. Denn wenn die Dateien nur von deinem Programm interpretiert werden können müssen, kommst du (jetzt mal von Komprimierung abgesehen) besser weg wenn du keines der üblichen Bildformate verwendest, sondern ein reines byte-File schreibst. Denn damit sparst du dir die Metadaten, die die üblichen Bildformate inkludieren. Natürlich nur, wenn du die Metadaten nicht brauchst.

Aber im Endeffekt geht's halt doch um Komprimierung. Und da ist die Frage ob du dir einen eigenen Algo überlegen willst oder doch am besten mit einem bereits erfundenen bedient bist. Es kommt auch auf die Art der Bilder an. Wenn du bestimmte Annahmen über diese Bilder treffen kannst, kannst du dir sicherlich einen auf deine Daten optimierten Algo schreiben, der dann wohl auch besser komprimieren kann als die allgemeinen Kompressionsverfahren.

Und im End-Endeffekt würde ich dir raten: Nimm ein gängiges Format mit guter Kompression, und/oder zip das ganze. Denn ob ein File nun 4,62 oder 4,00 MB einnimmt (ich wage zu bezweifeln dass du da mehr rausholen kannst, d.h. im Vergleich zu einem gängigen komprimierten Bildformat) spielt bei den heutigen Speicherkapazitäten kaum eine Rolle.

Oder ist Speicherplatz in deinem Kontext ein kritischer Aspekt? Wieviel Bilder haste denn, zehntausend, hunderttausend?

 

[Andi_CH]

Bevor ich was programmiere überlege ich ob es Sinn macht, bisher steht nur die Theorie und kein Code

Applaus - bei Eikes System entstehen Programme die unter gewissen Bedingungen funktionieren, aber eben nur unter gewissen ...

Ich meine den Speicher den das Bild auf der Fesplatte braucht.

Gut das mit dem Komprimieren ist ne Sache für sich. Wie sieht es also ohne Komprimierung aus?

Für das Format habe ich mich noch nicht so richtig entschieden, es ist wichtig dass keine Verluste auftreten, habe mir dahingehend sagen lassen ich soll kein jpg nehmen

jpg ist verlustbehaftet. Ob es echt verlustfreie Kompression gibt weiss ich wirklich nicht.

(Ich habe damals riesige Satellitenbilder im Gigabytebereich als unkomprimierte tif gespeichert
Das Kriterium war Randomzugriff auf einzelne Pixel, weil daraus ein Projektion gerechnet wurde.)

Ist Speicherplatz wirklich das Kritierium?

Die unkomprimierte Grösse hast du ja berechnet (der overhead der Formate geht IMO unter, weil das Filesystem ja eine Blockgrösse hat.)

Was eine Kompression bringt kann unmöglich gesagt werden, wenn die Struktur der Daten random ist.

 

[langhaar!]

jpg ist verlustbehaftet. Ob es echt verlustfreie Kompression gibt weiss ich wirklich nicht.

Als Bildformat z.B. GIF, auf Dateiebene z.B. ZIP.

 

[Tomate_Salat]

Naja, für uns geht es hier um Bilder+komprimierung. Da halte ich Eikes Vorschlag:

Was hindert dich daran einfach mal 4 5 Bilder im gewünschten Format mal abzuspeichern?

doch immernoch am besten. Nimm ein paar Bilder und komprimier diese mit verschiedenen Formate+schau dir das Ergebnis an. Wenn du ein komplett eigenes Format* haben willst, können wir eh nichts dazu sagen, weil es ja anscheinend (noch) keins gibt. Deine Frage nach dem Speicherplatzverbrauch lässt sich nunmal durch ein Bildbearbeitungsprogramm lösen.


*=außer natürlich, es geht um die Implementierung+Ideen.

 

[Andi_CH]

Ok, ich hab dem möglicherweise zu wenig Gewicht gegeben.

Was kommt mit Komprimierung raus(grob)?

Es ist keine Aussage möglich, da bestimmte Kompressionsalgorithmen auch auf bestimmte Regelmässigkeiten in den Daten ansetzen (z.B. grosse Flächen konstanter Farbe).

Es handelt sich hier, wie weiter oben steht, um eine theoretische Abklärung. Was eine "Versuchsreihe" in diesem Zusammenhang bringt oder eben nicht bringt ist ja auch klar, so lange nicht mehr über die Daten bekannt ist. Allenfalls Abschätzungen um Manager zu befriedigen, mehr aber nicht.

Wer daraus viel schliessen kann, kann ja gerne aufklärend wirken:

300x299 Pixel (hab mich wohl um eines vertan)
Farbe weiss
Paint generiert tif offensichtlich mit LZE Kompression
Grösse in Bytes ausgegeben durch cygwin

 269154 weiss-24-Bit.bmp
    444 weiss-24-Bit.bmp.zip
   6400 weiss-24-Bit.tif
  90778 weiss-256-faben.bmp
   1311 weiss.gif
   2923 weiss.jpg
   7508 weiss.tif

Jetzt soll mir einer begründen, dass gif verlustfrei und jpg verlustbehaftet sein soll - ich bin jetzt einfach zu bequem ein schief liegendes Gitter mit 1 Pixel Abstand zu generieren - das dürfte wohl der Horror für jeden Kompressionsalogorithmus sein

 

[langhaar!]

Jetzt soll mir einer begründen, dass gif verlustfrei und jpg verlustbehaftet sein soll

Ich verstehe disese Aussage nicht.
Da gibt es nichts zu begründen. Dass GIF verlustfrei ist und JPG meist verlustbehaftet (JPG kann auch verlustfrei sein) sind inhärente Eigenschaften deren Kodierung.

 

[Schandro]

jpg ist verlustbehaftet und trotzdem größer als gif, weil gif ein kleineres Farbspektrum hat... (und dementsprechend auch verlustbehaftet ist)

(wobei es natürlich Ausnahmen gibt...)

 

[Lumaraf]

Das Format jpg kann grundsätzlich auch verlustfrei komprimieren, das unterstützt nur so gut wie garkeine Implementierung. Ich würde dir zu png raten. Das Format ist im normalfall verlustfrei, wird so gut wie überall unterstützt und die komprimierung ist auch ganz ordentlich.