Swing Zweidimensionales Array mit Farben erzeugen

[Mr. J]

Hallo,
ich habe ein Problem. Und zwar habe ich ein Farbarray (Color[][] farbarray). Dieses Array fülle ich in zwei verschachtelten Schleifen (mit Zähler i und j) mit Farbwerten in der Art farbarray[j] = new Color(variable1,variable2,variable3). Variable 1,2 und 3 verändern sich während der Schleifendurchläufe auch.
Mein Problem ist jetzt dass mein Programm sehr viel Speicher frisst und mich würde interessieren ob ich irgendwo was falsch mache und unnötig Speicher verschwende.

MfG
Mr. J

 

[Marco13]

Jein. Vielleicht. Vielleicht auch nicht. Vermutlich aber schon. Die gesamte Information, die in einem (ca. 30 byte großen???) Color-Objekt steckt, passt auch in einen (4 byte großen) 'int'.

Wie groß ist denn der Array, und wie viel Speicher wird verbraucht?

 

[Mr. J]

Im aktuellen Test ist das Array 3000*3000 groß und der Speicherverbrauch liegt zwischen 700Mb und 1000Mb. Ich kann mal ein Codestück posten:

Color[][] pixelcolors = new Color[dimx][dimy];
for ( int outercounter = 1; outercounter <= dimy; outercounter++ ) {
posdir = (float) outercounter / (float) dimy;
posvar = ((float) start / (float) 255) + (((float) (stop-start) * (float) outercounter) / ((float) 255 * (float) dimy));  
int counthlp = outercounter;
for ( int innercounter = 1; innercounter <= dimx; innercounter++) {
posfix = (float) innercounter / (float) dimx;
pixelcolors[innercounter-1][dimy-counthlp] = new Color(posdir,posfix,posvar);
}
}

Die Variablen dimx und dimy werden von außen geliefert. Mit pixelcolors wird anschließend ein neues Objekt erzeugt in dem pixelcolors, dimx, dimy und ein String gespeichert werden.

MfG
Mr. J

 

[Marcinek]

Eventuell mal den Sinn dieses Programms beschreiben.

Müssen diese Farben gespeichert werden?

Immerhin sind es fast 9 Millionen Farben ... Wieviele verschiedene gibt es da? Hat jedes Feld eine andere Farbe?

 

[Mr. J]

Eigentlich sind es genau 9 Millionen Farben

Aber ja, es ist notwendig sie zu speichern. Das Programm erzeugt mir eine Farbkarte die ich zum Einen später speichern und wieder laden können will und zum anderen in einem Fenster anzeigen lasse.

MfG
Mr. J

 

[Marco13]

Uuuunnnd... wenn du jetzt mal genau den Unterschied erklären würdest, zwischen "Farbkarte" und "stinknormales Bild" würde das sicher helfen. Im Moment würde nichts dagegen sprechen, sich von jeder Color das getRGB zu holen, und das als Pixel in ein BufferedImage zu setzen...das wären dann ca. 36 MB...

 

[Mr. J]

Das Problem ist dass ich im Moment zwar nur mit dem RGB-Farbraum arbeite, allerdings soll dies später auf weitere Farbräume und Farbmodelle erweitert werden. Von daher brauche ich eine Datenstruktur die pro Pixel einen Farbwert speichert, der Farbwert kann z.B. aus RGB-, CMYK-, HSV- oder Lab-Farbraum sein.

MfG
Mr. J

 

[Marco13]

Hmja. Aber ein "Color"-Objekt spreichert auch nicht die Information in ALLEN Farbräumen (und wenn doch, würde das den absurd hohen speicherverbrauch erklären). D.h. auch da muss man ggf. umrechnen. Wenn man alles als BufferedImage oder int[][] speichert, kann man die einzelnen RGB-Werte dann ja genauso umrechnen - NOTFALLS in dem man aus dem rgb-Int ein neues Color-Objekt erstellt, aber da gibt's dann ggf. auch effizientere Möglichkeiten..

 

[Marcinek]

Ich würde diese 9 Millionen Farben garnicht im Hauptspeicher ablegen..

Sie sind dynaamisch erzeugt und daher kann ich zu jederzeit via Rechnung sagen, welche Farbe an X, Y ist.

Wenn ich die exakte Konfigration nochmal benötige, dann würde ich eine Datei schreiben mit den Farben.

Gruß,

Martin

 

[Mr. J]

Ich sollte also die einzelnen Komponenten der jeweiligen Arrayeinträge gleich als fertiges Ergebnis speichern statt 3 Einzelwerte und am besten gleich auch in einer Datei ablegen statt sie im Speicher zu behalten?

MfG
Mr. J

 

[Marco13]

Hm. Das mit der Datei erschließt sich mir jetzt auch nicht ganz ???:L Also, es geht erstmal um ca. 40 MB, das sollte ja kein Problem sein. Und in diesem Fall ist "in einem Array nachsehen" IMMER schneller, als irgendeine Berechnung....

 

[Mr. J]

Hm, ja, aber bei mir wird das Programm ja viel viel viel größer und ich weis noch nicht ganz warum, aber wahrscheinlich wärs sinnvoller die 3 Werte einfach als Array aus 3 Ints zu speichern statt als Color? Oder um mal anders zu fragen: wie kann ich es möglichst effizient ablegen so dass mein Programm nicht um so viel größer wird?

Statt den Farben nur die Erzeugungsparameter abzulegen ist keine Alternative da das Bild später auch zugeschnitten oder evtl. verzerrt werden soll und da will ich dann schon auf den Werten direkt arbeiten und wenn ichs speicher dann muss ichs sowieso als Datei ablegen.

MfG
Mr. J

 

[Marco13]

Jetzt redest du ja schon von einem Bild Da ist der Schritt zum anfangs schon erwähnten BufferedImage ja nicht weit. Das speichert R,G,B,A in EINEM int. Ist doch praktisch

 

[Murray]

Statt den Farben nur die Erzeugungsparameter abzulegen ist keine Alternative da das Bild später auch zugeschnitten oder evtl. verzerrt werden soll und da will ich dann schon auf den Werten direkt arbeiten und wenn ichs speicher dann muss ichs sowieso als Datei ablegen.

Das verstehe ich nicht so richtig. Bezieht sich das auf Marcineks Post?

Marcinek hat zu Recht geschrieben, dass sich die Werte des Arrays in Anhängigkeit der beiden Laufvariablen errechnen.
Etwas formaler: colors[x,y] = f(x,y);
Insofern könnte man dort, wo man später auf das Array zugreift, auch direkt die zugrundeliegende Methode aufrufen.
Also geht statt

for ( x = ...) {
  for ( y = ...) {
    colors[x, y] = f(x,y);
  }
}
...
Color whatever = colors[ someX, someY];

auch

Color whatever = f( someX, someY);

Das Array kann sich lohnen, wenn
- die gleichen Koordinaten mehrfach abgefragt werden
- die Berechnung an sich aufwändig ist
- nicht nur einige wenige Koordinaten abgefragt werden

Ist das in Deinem Fall so?

 

[Mr. J]

Jetzt redest du ja schon von einem Bild Da ist der Schritt zum anfangs schon erwähnten BufferedImage ja nicht weit. Das speichert R,G,B,A in EINEM int. Ist doch praktisch

Ja, nur gehe ich bei einem BufferedImage davon aus dass ich ein RGB-Farbmodell vorliegen habe, da es aber auch andere Farbmodelle sein können kann ich das BufferedImage nicht nehmen. Ich wandle meine Datenstruktur zur Anzeige in ein BufferedImage um und lasse es dann anzeigen aber als generelle Struktur kann ichs leider nicht nehmen.

-------------------------------------------------

Das Array kann sich lohnen, wenn
- die gleichen Koordinaten mehrfach abgefragt werden
- die Berechnung an sich aufwändig ist
- nicht nur einige wenige Koordinaten abgefragt werden

Ist das in Deinem Fall so?

Ja, vor allem sollen die Daten später auch verändert werden, z.B. verzerrt, von daher würde ich nicht die Erzeugungsfunktion speichern sondern lieber die Daten direkt.

MfG
Mr. J

 

[Mr. J]

Was mir auch grad noch aufgefallen ist wenn ich mit kleineren Testwerten arbeite: das Programm verbraucht jedes mal mehr Speicher wenn ich einen neuen Schleifendurchlauf aufrufe. Ist das normal oder habe ich das irgendwo ein Speicherleck, evtl. weil ich für jeden Eintrag eine new Color erzeuge und der Garbagecollector sie nicht richtig entsorgt?

MfG
Mr. J

 

[Marco13]

OK, habe jetzt mal in die Color.java geschaut:

    transient private long pData;
    int value;
    private float frgbvalue[] = null;
    private float fvalue[] = null;
    private float falpha = 0.0f;
    private ColorSpace cs = null;

D.h. ein Color-Objekt belegt ggf. so um die 80-100 bytes :shock: Wen du meinst, dass der RGB-int nicht reicht, dann vermute ich mal, dass meine ... Kenntnisse in bezug auf Farbmodelle und deren Repäsentation nicht ausrechen, um das nachvollziehen zu können (habe ich gerade auch in einem anderen Thread gemerkt). Aber zumindest wäre es IMHO nahe liegend, sich eine Form für diese Daten zu überlegen, die in dem Sinne "allgemeingültig" ist, dass sie so mächtig ist, dass sie "alle" Farben speichern kann, die bei diesem Vorhaben auftreten - Ganz naiv gesagt: Ein Array mit 4 floats sollte doch für alle praktischen Zwecke reichen?

EDIT: Zum Thema Speicherleck kann man GROB sagen: Ein Speicherleck hat man, wenn ein OutOfMemoryError kommt, obwohl keiner kommen sollte. Was Windows oder so im TaskManager als Speicherverbrauch anzeigt, sagt nicht viel aus. Wenn Speicher benötigt wird, schaufelt der GC den schon frei, sofern er das kann, aber wenn der Speicher NICHT gebraucht wird, und das Freischaufeln so gesehen nicht "notwendig" ist, macht er das auch nicht unbedingt.