performance g2d.drawImage()

[Oni]

Hi,

ich probiere ein Bild zu verkleinern um es dann in einer jtable anzuzeigen. das funktioniert auch gut, zumindest mit kleinen bildern.
Unten ein beispiel:
bei einem kleinen bild dauert es weniger als eine sekunde, bei einen 10 mal so grossen bild(auf die pixel bezogen), über 1 1 1/2 minuten. gibt es eine bessere/schnellere möglichkeit ein bild zu verkleinern?


Beispiel 1:
-------------
10 kb grosses Bild 160x120

Konsolenausgabe:
Start
breite = 81
hoehe = 60
Tue Feb 13 12:05:20 CET 2007
Tue Feb 13 12:05:20 CET 2007
Fertig


Beispiel 2:
------------
402 kb grosses Bild 1600x1200

Konsolenausgabe:
Start
breite = 80
hoehe = 60
Tue Feb 13 12:07:40 CET 2007
Tue Feb 13 12:09:18 CET 2007
Fertig

public void convertToSmallBufferedImage(String pathGross, String pathKlein){
		try{		
			System.out.println("Start");
			File temp = new File(pathGross);
			final BufferedImage in = ImageIO.read(temp);
			
			int breite = in.getWidth();
			int hoehe  = in.getHeight();
			while(hoehe > 120){
				hoehe  = hoehe * 50 / 100;
				breite = breite * 50 / 100;
			}
			
			while(hoehe > 60){
				hoehe  = hoehe * 80 / 100;
				breite = breite * 80 / 100;
			}
			
			System.out.println("breite = " +breite );
			System.out.println("hoehe  = " +hoehe );
			
			Image scaled = in.getScaledInstance(breite, hoehe, Image.SCALE_SMOOTH);			
			BufferedImage out = new BufferedImage(breite, hoehe, BufferedImage.TYPE_INT_RGB);			
			Graphics2D g2d = out.createGraphics();
			System.out.println(new Date());
			g2d.drawImage(scaled, 0, 0, null);
			System.out.println(new Date());
			g2d.dispose();
			
			File file = new File(pathKlein);
			if(pathGross.toLowerCase().endsWith(".gif")){
				ImageIO.write(out, "gif", file);
			}
			else if( (pathGross.toLowerCase().endsWith(".jpg")) || (pathGross.toLowerCase().endsWith(".jepg")) ){
				ImageIO.write(out, "jpeg", file);
			}
      	} 
		catch (Exception ex) {
			System.out.println(ex);
		}
		System.out.println("Fertig");
	}

 

[Marco13]

Statt Image.SCALE_SMOOTH könntest du Image.SCALE_FAST verwenden. Die Alternative ist, dass du das Bild einfach kleiner zeichnest, als es ist.
g.drawImage(grossesBild, 0,0, gewünschteGrößeX, gewünschteGrößeY, obs);

 

[Oni]

SCALTE_FAST habe ich auch schon probiert, aber das hat auch nur 10 sekunden gespart.

das mit dem kleiner zeichnen probiere ich mal, ist aber auch keine optimale lösung, weil die bilder auf einem server liegen und ich sie in ein applet lade.

trotzdem danke

 

[Oni]

Sitze jetzt nicht mehr in der Berufschule sondern daheim.

In der Berufschule habe ich einen P3 1000 Mhz (jdk 1.5.xx)
Dauer 1 min 40 sek.

Daheim E6600 Core2Duo (2,4 Ghz) (jdk 1.6.xx)
Dauer 1 sek

Mit dem gleichen Code (SCALE_SMOOTH)und fuer das gleiche Bild. da stimmt doch etwas nicht, soviel schneller ist der Prozessor doch auch nicht.

 

[Tobias]

Mh, vielleicht hat da jemand die Methode im 1.6er neugeschrieben und nen besseren Algorithmus benutzt? Vielleicht setzt die Methode auch auf Threads, so das dein DualCore voll zum Tragen kommt. Vielleicht läuft auf deiner Mühle aber auch einfach nur weniger Zeugs im Hintergrund.

mpG
Tobias

 

[AlArenal]

In der Berufschule habe ich einen P4 1000 Mhz (jdk 1.5.xx)
Dauer 1 min 40 sek.

Habt ihr den aus Millionen Transistoren selbst gelötet? Es gab nie einen P4 mit 1000 MHz..... Wenn ich mich richtig erinnere startete Intel die mit 1.8 GHz und die sind echt schrecklich langsam, weil die sich zwei von drei Taktzyklen die Eier schaukeln Unsere Sekretärin hat so nen Renner und das geht echt gar nicht... Lieber P3 mit 1.4 GHz....

 

[Oni]

hmm vielleicht ist es auch ein P3 mit 1000 Mhz. Die dinger sind wirklich schlecht, aber soo auch langsam auch wieder nicht.

ich habe es jetzt nochmal auf meinem 2 rechner laufen lassen ein p4 mit 2,6 Mhz, da dauert es auch nur 1 sek. habe da auch die jdk 1.6 drauf.

vielleicht ist es ja wirklich ein bug in der jdk 1.5? bei grossen bilder ?, weil die kleinen bilder schaft mein berufsschulrechner ja auch sehr flott.

 

[WieselAc]

Probiers doch am besten mal aus und poste dein Ergebniss!

Dann wissen du und auch wir anderen genaueres.

Es gibt immer noch sehr viele die mit der JDK 1.4 arbeiten müssen/wollen/sollen/dürfen und denen so eine Info mal nützlich sein könnte.

 

[AlArenal]

Es gibt immer noch sehr viele die mit der JDK 1.4 arbeiten müssen/wollen/sollen/dürfen und denen so eine Info mal nützlich sein könnte.

Wie nützlich sind für diese Infos über 1.5 und 1.6? *kopfkratz*

 

[Marco13]

Hm - wenn du die Daten vom Sever lädst, sind sie ja schon da - ob es sich da nochmal lohnt, die lokal (in einer verkleinerten Version) zu speichern? Das ist doch allein schon wegen der Probleme mit den Schreibrechten bei Applets eher lästig :roll: Aber naja - wenns jetzt wie gewünscht geht, ists ja gut.

 

[WieselAc]

Für die wär es interessant zu wissen, ob das ein Problem in der 1.4 ist, das in der 1.5/1.6 gelöst wurde.


Aber nach genauerem lesen, um den Hintergrund seiner Frage zu verstehen, hab ich gemerkt, dass hier die ganze Zeit die Rede von der 1.5 im Vergleich zur 1.6 war.


Von daher muss ich mal wieder geflissentlich zurück rudern und meine Frage zurück ziehen. H

offentlich ist bald Feierabend selbst beim lesen verdreh ich schon alles, da weiß ich ja schon was passiert wenn ich weiter code..

 

[Oni]

Hm - wenn du die Daten vom Sever lädst, sind sie ja schon da - ob es sich da nochmal lohnt, die lokal (in einer verkleinerten Version) zu speichern? Das ist doch allein schon wegen der Probleme mit den Schreibrechten bei Applets eher lästig icon_rolleyes.gif Aber naja - wenns jetzt wie gewünscht geht, ists ja gut.

Die Bilder werden vom Client(applet) auf den Server geladen. auf dem server liegen sie dann in 2 formaten vor, einmal als kleines bild für die vorschau und einmal als grosses. ich spiele die bilder per socket verbindung auf den server und musste deshalb das applet signieren. ubertragen wird nur das gross bild und dann auf dem server verkleinert.

EDIT: mal unabhängig davon scheint das kleiner zeichnen schneller zu gehen.

g2d.drawImage(scaled, 0, 0, breite, hoehe, null);

ich teste es morgen nochmal in der berufsschule.

 

[AlArenal]

Kleiner Denkanstoß:

Ein Bild der Größe 160x120 enthält exakt 1/100 der Informationsmenge eines Bildes der Größe 1600x1200. Ein wenigstens 100fach höherer Rechenaufwand zzgl. der länegeren Zeit für die Datenübertragung ist also rein rechnerisch zu erwarten und deckt sich in etwa mit deiner Beobachtung.

 

[Oni]

Das der Rechenaufwand wesentlich groesser ist ist klar, aber bei gleichem code und dem gleichem bild so ein grosser unterschied:

Dauer:
Rechner A 1 min 40 sek
Rechner B 1 sek
Rechner C 1 sek

Wenn der Rechner mit dem DualCore Prozessor sich deutlich abheben würde könnte ich das ja noch verstehen, aber auch der P4 mit 2,6 Ghz arbeit super schnell.

 

[The_S]

Was erwartest du von einem P3 mit 1GHz? Dann laufen evtl. noch zig Sachen im Hintergrund ... Also ich hab das jetzt mal auf einem P4 mit 3,8GHz und JRE 1.5 (!!!) getestet. Allerdings nur bei einem Bild mit 1300*800 (hab auf die Schnelle kein größeres gefunden) und bei mir beträgt die Differenz ebenfalls nur 1 Sekunde.

 

[Oni]

Also bin jetzt wieder in der Berufsschule:

Der Rechner ist eine Pentium 3 mit 1001 Mhz, installiert ist ein Win XP auf dem 27 Prozesse laufen, was ja eigentlich nicht viel ist für Windows.

Hat habe nochmal getestet:
------------------------------
JDK 1.5_06 dauert es 1 min 40 sek
nach update auf
JDK 1.5_11 dauert es 1 min 40 sek
nach neuinstallation von
JDK 1.6_00 dauert es 1 sek

also lag es wohl doch an der 1.5.x

 

[The_S]

Wie viele Prozesse laufen hat gar nichts damit zu tun, sondern eher wie viele Ressourcen diese Prozesse fressen. Und wie gesagt, ich komme mit JDK 1.5 auch auf 1 Sekunde!

 

[Oni]

wenn ich nichts mache ist die cpu-auslastung bei höchstens 2 prozent und von den 512 Mb Ram ist auch nur die hälte belegt. also daran lag es nicht, ich hatte wahrscheinlich einen bug in der jdk die auf dem rechner installiert war. der nicht durch das update auf die 1.5_11 behoben wurde.

bei kleinen bildern kam ich ja auch auf 1 sekunde nur bei grossen nicht. wenn es an der hardware vom rechner liegen würde, dann dürfte es mit der jdk 1.6 ja nicht soviel schnell sein.