Große Bilder laden

Marco Feltmann · 13. Mai 2013

Das übliche Leid: der mickrige VM Heap.

Ich muss (ja, ich muss!) ein großes Bild anzeigen, um die 2000x3000 Pixel.
Dieses Bild nimmt als PNG lächerliche 3MB ein, als Bitmap für Android hingegen nicht mehr ganz so lächerliche 30MB.

Alle gefundenen Lösungen zum Speicherproblem mit Bildern geht folgende Ansage voraus: Finger weg von großen Bildern.
In meinem Fall kann ich aber die Finger nicht von den großen Bildern lassen.

Welche Möglichkeiten habe ich, ein Bitmap aus einem PNG zu erstellen, dass zwar dieselben Dimensionen wie das PNG hat, doch hübsch komprimiert nur einen Zehntel des Speicherplatzes einnimmt?

matthias · 13. Mai 2013

Hoi,

die Frage wieso du musst kann ich mir wohl nicht verkneifen ... wieso musst du ein riesiges Bild anzeigen, dass auf einem kleinen Display selbst wenn der Speicher es reisst trotzdem zu Problemen führt?

Hab mir ein paar "ImageLoader" gebastelt für mein vorheriges Projekt, mithilfe derer ich Bilder aus dem assets-folder oder auch Online ziehe, decodiere, komprimiere, verkleinere, thumbnails erzeuge, als Blob in die DB speichere und auslese ...

Also wo liegt das Bild und darf es wirklich nicht kleiner werden? Feste Breite/Höhe, nix verändern? Für welche Android-Versionen? Da bin ich fürchterlich aufs Maul gefallen, weil man unter 3.0 glaube ich wars jeden sch... recyclen muss und ein removeView() auch nicht langt sondern man da teilweise echt dynamisch die Child-Objekte raus kramen darf um die dann zu recyclen.

Hast du schonmal solch ein Konstrukt getestet?

Java

URLConnection connection = url.openConnection();
connection.setUseCaches(true);
Object response = connection.getContent();
if (response instanceof Bitmap) {
	image = (Bitmap) response;
} else if (response instanceof InputStream) {
	is = (InputStream) response; 
	image = BitmapFactory.decodeStream(is); 
					
	is.close();


	ByteArrayOutputStream stream = new ByteArrayOutputStream();
	image.compress(CompressFormat.JPEG, 85, stream);
	is = new ByteArrayInputStream(stream.toByteArray());
					
	image.recycle(); 


	BitmapFactory.Options options = new BitmapFactory.Options();
	// Das lass ich mal weg, das wär für kleiner machen
	// options.inSampleSize = sampleSize;
	options.inDither = false;
	options.inPreferQualityOverSpeed = false;
	options.inPurgeable = true;
	options.inJustDecodeBounds = false;


	image = BitmapFactory.decodeStream(is, null, options);
					
	stream.close();

Alles anzeigen

Gruß,
matze

Marco Feltmann · 14. Mai 2013

Zitat von matthias

Hoi,
die Frage wieso du musst kann ich mir wohl nicht verkneifen ...

Na dann frag.

Zitat von matthias

wieso musst du ein riesiges Bild anzeigen, dass auf einem kleinen Display selbst wenn der Speicher es reisst trotzdem zu Problemen führt?

Weil der Chef es so verlangt. Frei nach dem Motto 'unter iOS funktioniert das ja auch'.
Natürlich hängt da noch ganz viel Kram hinter, der eben dieses schöne Bild produziert. Das Ding auf Tiles umzustellen würde nicht nur dort sondern auch bei der bereits laufenden iOS Variante erhebliche Umbauten nach sich ziehen. +seufz+

Zitat von matthias

Also wo liegt das Bild und darf es wirklich nicht kleiner werden?

Auf der SD-Karte im Files Directory. Beziehungsweise ohne SD-Karte im internen Files Directory. Und ja, darf es wirklich nicht.

Zitat von matthias

Feste Breite/Höhe, nix verändern?

Natürlich alles fix, sonst läuft der Rest nicht korrekt.

Zitat von matthias

Für welche Android-Versionen?

Ab API 10 aufwärts.

Zitat von matthias

Da bin ich fürchterlich aufs Maul gefallen, weil man unter 3.0 glaube ich wars jeden sch... recyclen muss und ein removeView() auch nicht langt sondern man da teilweise echt dynamisch die Child-Objekte raus kramen darf um die dann zu recyclen.

Das war soweit ich gelesen habe bis einschließlich API 10 der Fall, fällt also genau in das Wunsch-OS.

Zitat von matthias

Hast du schonmal solch ein Konstrukt getestet?

Nein. Das sieht ja recht geil aus.
Ich vermute nur, dass auch das ein bisschen Speicher frisst. Zumal das fertige Bild ja wie geschrieben als 3MB PNG vorliegt und nur im Memory, BitmapFactory sei Dank, auf über 30MB aufgeblasen wird.

Naja, das Projekt ist jetzt für teuer Geld an extern abgetreten worden. Ich bin dafür offenbar einfach zu unfähig.

matthias · 14. Mai 2013

xD Ok alles klar.

In einem vorherigen Projekt hatte ich Facebook-Alben(Wunsch vom Chef) mit eingebunden, diese im Splashscreen geladen und dann mit diversen ImageLoadern die auf AsyncTasks aufbauen verwurstet ... hat einiges an nerven gekostet

Von Bitmap verkleinern skalieren zu Blob, in DB, aus DB in Stream zu Bitmap hin und her, immer mit Device Height und Width auslesen, damit das ganze möglichst brauchbar skaliert wird ... aber wenn man nichts skalieren darf fällt halt 3/4 Code weg

Naja, soll sich teuer Extern damit auseinander setzen

Gruß,
matze

Funtik · 14. Mai 2013

Bleibt dann nur noch die frage, wie "teuer extern" das denn hinbekommt und wo und wie die das gelernt haben...

würde auch gerne endlich alles mögliche in android programmieren können und auf alles ne antwort wissen

Marco Feltmann · 14. Mai 2013

Zitat von Funtik

würde auch gerne endlich alles mögliche in android programmieren können und auf alles ne antwort wissen

Ich auch.

Nun, immerhin hatte er die besseren Argumente und darf jetzt https://github.com/moagrius/MapView benutzen.
Frag mich nicht.

matthias · 15. Mai 2013

Hoi,

hab nochmal nach geguckt, wie groß die Bilder bei mir sind bevor ich sie verwurste ...

Im Falle Facebook bekommt man ja glaub pro Bild 9 Größen ... da such ich mir mittels

Java

if (thumb.getWidth() &lt;= SplashScreen.deviceWidth && thumb.getWidth() &gt; (SplashScreen.deviceWidth / 2)) {
		file = thumb.getSource();
		break;
}

das am besten Passende raus.

Bei den Offline-Bildern ist das Größte 1024x1024 und 698KB groß ... selbst bei diesen Werten hatte ich vor meinem riesen Optimierungsaufwand schon die höchsten Probleme

Wär cool, wenn du berichten würdest, ob der Teuer-Extern-Mensch das mit der MapView locker flockig hin bekommt

Gruß,
matze

Marco Feltmann · 15. Mai 2013

Nachdem er feststellte, dass seine Implementierung des OpenGLRenderers (Google Geräte...) maximal Texturen von 2048x2048 zulässt...
Wie geschrieben: bessere Argumente und plötzlich darf man tiles nutzen.

matthias · 15. Mai 2013

xD was lernen wir daraus? Eigentlich können wir nur entnehmen besser zu argumentieren

Muss irgendwann mal testen was das Maximum ist, das mein Konstrukt so reisst ... vll. morgen

Große Bilder laden

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema