Menu
▾
▴
csjava-developer
|
From: Toby D. <tj...@sf...> - 2005-07-22 21:38:58
|
Hi,
Can anyone help me to figure out why the code below is so slow? It
converts and image to grayscale pixel by pixel, but when I've run it
(on two different computers --- Windows and Mac OS X), it takes 20 or
more seconds to process a medium sized image. I would have expected
it take less than a second or so.
The bit-twiddling code should be quite efficient, since such
operations are (hopefully) converted to single assembly-language
instructions.
I've been using JDK 5.0 (aka 1.5), so maybe that's causing the problem?
Toby
--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)
public static void dprint(String s) {
System.out.println(s + " " + (new Date()));
}
public static void test4(String fname) {
try {
dprint("Creating buffered image:");
BufferedImage img = ImageIO.read(new File(fname));
dprint(".. done");
final int width = img.getWidth();
final int height = img.getHeight();
dprint("Starting grayscale conversion:");
for (int i = 0; i < width; i++) {
for (int j = 0; j < height; j++) {
int rgb = img.getRGB(i, j);
int b = (rgb & 0x000000FF);
int g = (rgb & 0x0000FF00) >> 8;
int r = (rgb & 0x00FF0000) >> 16;
int lum = (int) ((r + g + b) / 3.0);
int alpha = rgb & 0xFF000000;
int red = lum << 16;
int green = lum << 8;
int blue = lum;
int newARGB = alpha | red | green | blue;
img.setRGB(i, j, newARGB);
}
}
dprint("... done");
} catch (IOException e) {
e.printStackTrace();
}
}
|
|
From: Daryl V. H. <dva...@sf...> - 2005-07-23 00:46:17
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
It sounds like it is the JDK 5, on my Linux box (using a 200MHz
processor and Java v1.4.2_08) it took about 7 seconds on a 1024x768
image.<br>
<br>
As an update on my main Windows computer, the shop didn't find anything
wrong with it. <span class="moz-smiley-s2"><span> :-( </span></span><br>
Must need to re-install Windows.<br>
<br>
This time, I'm going to install Windows <i>and</i> Linux on it
(Keeping my slow one, of course).<br>
<br>
Daryl.<br>
<br>
Toby Donaldson wrote:
<blockquote cite="mid...@sf..."
type="cite">Hi,
<br>
<br>
Can anyone help me to figure out why the code below is so slow? It
converts and image to grayscale pixel by pixel, but when I've run it
(on two different computers --- Windows and Mac OS X), it takes 20 or
more seconds to process a medium sized image. I would have expected it
take less than a second or so.
<br>
<br>
The bit-twiddling code should be quite efficient, since such
operations are (hopefully) converted to single assembly-language
instructions.
<br>
<br>
I've been using JDK 5.0 (aka 1.5), so maybe that's causing the problem?
<br>
<br>
Toby
<br>
--
<br>
Dr. Toby Donaldson
<br>
School of Computing Science
<br>
Simon Fraser University (Surrey)
<br>
<br>
<br>
<br>
public static void dprint(String s) {
<br>
System.out.println(s + " " + (new Date()));
<br>
}
<br>
<br>
public static void test4(String fname) {
<br>
try {
<br>
dprint("Creating buffered image:");
<br>
BufferedImage img = ImageIO.read(new File(fname));
<br>
dprint(".. done");
<br>
final int width = img.getWidth();
<br>
final int height = img.getHeight();
<br>
dprint("Starting grayscale conversion:");
<br>
for (int i = 0; i < width; i++) {
<br>
for (int j = 0; j < height; j++) {
<br>
int rgb = img.getRGB(i, j);
<br>
int b = (rgb & 0x000000FF);
<br>
int g = (rgb & 0x0000FF00) >> 8;
<br>
int r = (rgb & 0x00FF0000) >> 16;
<br>
<br>
int lum = (int) ((r + g + b) / 3.0);
<br>
int alpha = rgb & 0xFF000000;
<br>
int red = lum << 16;
<br>
int green = lum << 8;
<br>
int blue = lum;
<br>
int newARGB = alpha | red | green | blue;
<br>
<br>
img.setRGB(i, j, newARGB);
<br>
}
<br>
}
<br>
dprint("... done");
<br>
} catch (IOException e) {
<br>
e.printStackTrace();
<br>
}
<br>
}
<br>
<br>
<br>
<br>
<br>
<br>
-------------------------------------------------------
<br>
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
<br>
from IBM. Find simple to follow Roadmaps, straightforward articles,
<br>
informative Webcasts and more! Get everything you need to get up to
<br>
speed, fast.
<a class="moz-txt-link-freetext" href="http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click">http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click</a>
<br>
_______________________________________________
<br>
csjava-developer mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:csj...@li...">csj...@li...</a>
<br>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/csjava-developer">https://lists.sourceforge.net/lists/listinfo/csjava-developer</a>
<br>
<br>
<br>
</blockquote>
<br>
</body>
</html>
|
|
From: Thomas J. <ntm...@gm...> - 2005-07-23 01:51:55
|
On 7/22/05, Toby Donaldson <tj...@sf...> wrote: > Can anyone help me to figure out why the code below is so slow? It > converts and image to grayscale pixel by pixel, but when I've run it > (on two different computers --- Windows and Mac OS X), it takes 20 or > more seconds to process a medium sized image. I would have expected > it take less than a second or so. I've run the given code snippet on my Linux box (Sun Java 1.5.0) and a G4 laptop (Sun Java 1.4.2), testing against csimage/pictures/sumo.jpg and have been unable to reproduce this behaviour. Just to double-check, this is all supposed to be done with the classes belonging to the stock JVM right? The necessary imports in question being java.awt.image.BufferedImage, java.io.File, and javax.imageio.ImageIO? It might be prudent to give it a run with the profiler ( java -Xprof className ) in the hopes that some light will be shed on exactly where performance is suffering. Additonally, have you tried running this test standalone? It may be possible that the JVM is trying to garbage collect while test4 is running. > The bit-twiddling code should be quite efficient, since such > operations are (hopefully) converted to single assembly-language > instructions. The resulting operations can be viewed with a Java Compiler such as Jad (The fast JAva Decompiler - http://www.kpdus.com/jad.html ). By the looks of it, the code is as fast as it's going to get: int l2 =3D i2 << 8; // 80 154:iload 10 // 81 156:bipush 8 // 82 158:ishl =20 // 83 159:istore 13 > I've been using JDK 5.0 (aka 1.5), so maybe that's causing the problem? It might be worth verifying that the classpath is set correctly, and that the system hasn't somehow reverted back to an older or different version of Java without your intervention. Bear in mind that it's also possible to have the 1.3 JDK doing the compiling and the 1.5 JRE actually executing the program. Are the following conversions really necessary? Would "(r + g + b)/3;" suffice, as the extra precision is just being lost anyway? > int lum =3D (int) ((r + g + b) / 3.0); Hope this helps. |
|
From: Toby D. <tj...@sf...> - 2005-07-23 04:14:59
Attachments:
lake1.jpg
|
Thanks to Thomas and Daryl for trying this ... I realized that the poor performance only seems to occur with one particular image: lake1.jpg I've tried 5 or 6 other (sometimes larger) images, and the performance is well within the expected range. But lake1.jpg is incredibly slow for some reason. I've checked this now on a variety of computers, in both Java 1.4 and 1.5. I've attached the problem image if anyone else has a couple of minutes to test it out ... Toby |
|
From: Thomas J. <ntm...@gm...> - 2005-07-23 08:21:46
|
On 7/22/05, Toby Donaldson <tj...@sf...> wrote:
> Thanks to Thomas and Daryl for trying this ... I realized that the poor
> performance only seems to occur with one particular image: lake1.jpg
I've tested it out. The image is definitely problematic. Out of
curiousity, I tried saving it as a raw bitmap, and the conversion just
flew by. I also tried jpegs of identical dimensions, which all
converted quickly (will try to generate some test patterns later).
Re-encoding the image as jpeg (several different permutations of
Gimp's Jpeg exporter settings) only served to give a fast conversion.
By the looks of things, I think it's a problem with the file encoding.
If not, then you've found a unique worst-case scenario for Sun's JPEG
decoder.
Here's some interesting excerpts from the profiler (collected with
java -Xprof myTest lake1.jpg | tee profile.log)
Interpreted + native Method =20
0.4% 0 + 22 sun.awt.color.CMM.cmmColorConvert
0.3% 0 + 15 sun.awt.color.CMM.cmmGetTransform
0.3% 0 + 13 sun.awt.color.CMM.cmmCombineTransforms
0.2% 0 + 9 com.sun.imageio.plugins.jpeg.JPEGImageReader.readI=
mage
0.1% 5 + 0 myTest.test4
0.1% 0 + 3 java.util.zip.ZipFile.open
0.1% 3 + 0 sun.awt.color.ICC_Transform.colorConvert
0.0% 0 + 2 sun.awt.color.CMM.cmmGetNumComponents
0.0% 0 + 2 sun.awt.color.CMM.cmmGetTagSize
[snip]
Compiled + native Method =20
1.1% 56 + 0 sun.awt.color.CMMImageLayout.<init>
0.8% 44 + 0 java.awt.color.ICC_ColorSpace.fromRGB
0.4% 20 + 0 java.awt.color.ICC_ColorSpace.toRGB
0.2% 12 + 0 =20
java.awt.image.ComponentColorModel.getNormalizedComponents
0.2% 6 + 2 sun.awt.color.ICC_Transform.colorConvert
0.2% 8 + 0 java.awt.image.ComponentColorModel.getDataElements
0.1% 7 + 0 java.awt.image.ComponentColorModel.getRGB
[snip]
Stub + native Method =20
64.4% 0 + 3340 sun.awt.color.CMM.cmmColorConvert
29.4% 0 + 1523 sun.awt.color.CMM.cmmGetNumComponents
0.1% 0 + 7 java.lang.StrictMath.pow
0.0% 0 + 1 java.lang.Object.clone
Flat profile of 61.52 secs (5160 total ticks): Java2D Disposer
Removing the call to write the aRGB values back in to the image neatly
cuts the runtime in half, as well as the number of color conversions.
Stub + native Method =20
61.5% 0 + 1647 sun.awt.color.CMM.cmmColorConvert
29.0% 0 + 776 sun.awt.color.CMM.cmmGetNumComponents
[snip]
Flat profile of 32.26 secs (2627 total ticks): Java2D Disposer
I'm not entirely sure how representative these figures are of the
normal behaviour when operating on plain aRGB data, as trials run too
fast for the profiler's 10Hz sampling rate. I'll look in to gathering
some more useful statistics tomorrow.
As a side-note, I just did a check-out of csjava and spent a solid
hour trying to fix the project's classpath to no avail. By the looks
of things, we are tied to Eclipse 3.0.1 for Windows (the swt includes
). What are everyone's thoughts on adding the libs to the CVS
repository so that we can use a relative classpath?
|
|
From: Daryl V. H. <dva...@sf...> - 2005-07-26 05:21:15
|
I've tested it too. I've found that this image, for some reason, takes much longer than most other images, even if they're larger. Strange. I'm going to check and see what Java says the format is as compared with other images. Daryl. Thomas Johnson wrote: >On 7/22/05, Toby Donaldson <tj...@sf...> wrote: > > >>Thanks to Thomas and Daryl for trying this ... I realized that the poor >>performance only seems to occur with one particular image: lake1.jpg >> >> >I've tested it out. The image is definitely problematic. Out of >curiousity, I tried saving it as a raw bitmap, and the conversion just >flew by. I also tried jpegs of identical dimensions, which all >converted quickly (will try to generate some test patterns later). >Re-encoding the image as jpeg (several different permutations of >Gimp's Jpeg exporter settings) only served to give a fast conversion. >By the looks of things, I think it's a problem with the file encoding. >If not, then you've found a unique worst-case scenario for Sun's JPEG >decoder. > >Here's some interesting excerpts from the profiler (collected with >java -Xprof myTest lake1.jpg | tee profile.log) > > Interpreted + native Method > 0.4% 0 + 22 sun.awt.color.CMM.cmmColorConvert > 0.3% 0 + 15 sun.awt.color.CMM.cmmGetTransform > 0.3% 0 + 13 sun.awt.color.CMM.cmmCombineTransforms > 0.2% 0 + 9 com.sun.imageio.plugins.jpeg.JPEGImageReader.readImage > 0.1% 5 + 0 myTest.test4 > 0.1% 0 + 3 java.util.zip.ZipFile.open > 0.1% 3 + 0 sun.awt.color.ICC_Transform.colorConvert > 0.0% 0 + 2 sun.awt.color.CMM.cmmGetNumComponents > 0.0% 0 + 2 sun.awt.color.CMM.cmmGetTagSize >[snip] > > Compiled + native Method > 1.1% 56 + 0 sun.awt.color.CMMImageLayout.<init> > 0.8% 44 + 0 java.awt.color.ICC_ColorSpace.fromRGB > 0.4% 20 + 0 java.awt.color.ICC_ColorSpace.toRGB > 0.2% 12 + 0 >java.awt.image.ComponentColorModel.getNormalizedComponents > 0.2% 6 + 2 sun.awt.color.ICC_Transform.colorConvert > 0.2% 8 + 0 java.awt.image.ComponentColorModel.getDataElements > 0.1% 7 + 0 java.awt.image.ComponentColorModel.getRGB >[snip] > > Stub + native Method > 64.4% 0 + 3340 sun.awt.color.CMM.cmmColorConvert > 29.4% 0 + 1523 sun.awt.color.CMM.cmmGetNumComponents > 0.1% 0 + 7 java.lang.StrictMath.pow > 0.0% 0 + 1 java.lang.Object.clone > >Flat profile of 61.52 secs (5160 total ticks): Java2D Disposer > >Removing the call to write the aRGB values back in to the image neatly >cuts the runtime in half, as well as the number of color conversions. > Stub + native Method > 61.5% 0 + 1647 sun.awt.color.CMM.cmmColorConvert > 29.0% 0 + 776 sun.awt.color.CMM.cmmGetNumComponents >[snip] >Flat profile of 32.26 secs (2627 total ticks): Java2D Disposer > >I'm not entirely sure how representative these figures are of the >normal behaviour when operating on plain aRGB data, as trials run too >fast for the profiler's 10Hz sampling rate. I'll look in to gathering >some more useful statistics tomorrow. > > >As a side-note, I just did a check-out of csjava and spent a solid >hour trying to fix the project's classpath to no avail. By the looks >of things, we are tied to Eclipse 3.0.1 for Windows (the swt includes >). What are everyone's thoughts on adding the libs to the CVS >repository so that we can use a relative classpath? > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opÌk >_______________________________________________ >csjava-developer mailing list >csj...@li... >https://lists.sourceforge.net/lists/listinfo/csjava-developer > > > -- Get Firefox! <http://www.spreadfirefox.com/?q=affiliates&id=106297&t=65> -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.9.4/57 - Release Date: 22/07/05 |
|
From: Daryl V. H. <dva...@sf...> - 2005-08-03 19:24:41
|
After performing several tests, I've come to the conclusion that there is something uncertain about lake1.jpg. It takes the longest of all the images I've tested with this program, and if I open it in a paint program (PaintShop Pro 5, in this case) and save it again without compression, it takes up more disk space, but takes only .22 seconds to convert to grayscale. So far, I have been unable to find any differences in header information, and don't know what in the world is going on as far as this image is concerned. I'm completely baffled by this. Daryl. Toby Donaldson wrote: > Thanks for looking into this, Daryl. Maybe the header of the file is > somehow corrupt, or uses some weird JPEG feature that the Java codec > doesn't handle. > > Toby > > On 25-Jul-05, at 10:22 PM, Daryl Van Humbeck wrote: > >> I've tested it too. >> >> I've found that this image, for some reason, takes much longer than >> most other images, even if they're larger. >> Strange. >> >> I'm going to check and see what Java says the format is as compared >> with other images. >> >> Daryl. >> >> Thomas Johnson wrote: >> >> >>> On 7/22/05, Toby Donaldson <tj...@sf...> wrote: >>> >>> >>>> Thanks to Thomas and Daryl for trying this ... I realized that the >>>> poor >>>> performance only seems to occur with one particular image: lake1.jpg >>>> >>>> >>> I've tested it out. The image is definitely problematic. Out of >>> curiousity, I tried saving it as a raw bitmap, and the conversion just >>> flew by. I also tried jpegs of identical dimensions, which all >>> converted quickly (will try to generate some test patterns later). >>> Re-encoding the image as jpeg (several different permutations of >>> Gimp's Jpeg exporter settings) only served to give a fast conversion. >>> By the looks of things, I think it's a problem with the file encoding. >>> If not, then you've found a unique worst-case scenario for Sun's JPEG >>> decoder. >>> >>> Here's some interesting excerpts from the profiler (collected with >>> java -Xprof myTest lake1.jpg | tee profile.log) >>> >>> Interpreted + native Method 0.4% 0 >>> + 22 sun.awt.color.CMM.cmmColorConvert >>> 0.3% 0 + 15 sun.awt.color.CMM.cmmGetTransform >>> 0.3% 0 + 13 sun.awt.color.CMM.cmmCombineTransforms >>> 0.2% 0 + 9 >>> com.sun.imageio.plugins.jpeg.JPEGImageReader.readImage >>> 0.1% 5 + 0 myTest.test4 >>> 0.1% 0 + 3 java.util.zip.ZipFile.open >>> 0.1% 3 + 0 sun.awt.color.ICC_Transform.colorConvert >>> 0.0% 0 + 2 sun.awt.color.CMM.cmmGetNumComponents >>> 0.0% 0 + 2 sun.awt.color.CMM.cmmGetTagSize >>> [snip] >>> >>> Compiled + native Method 1.1% 56 >>> + 0 sun.awt.color.CMMImageLayout.<init> >>> 0.8% 44 + 0 java.awt.color.ICC_ColorSpace.fromRGB >>> 0.4% 20 + 0 java.awt.color.ICC_ColorSpace.toRGB >>> 0.2% 12 + 0 >>> java.awt.image.ComponentColorModel.getNormalizedComponents >>> 0.2% 6 + 2 sun.awt.color.ICC_Transform.colorConvert >>> 0.2% 8 + 0 >>> java.awt.image.ComponentColorModel.getDataElements >>> 0.1% 7 + 0 java.awt.image.ComponentColorModel.getRGB >>> [snip] >>> >>> Stub + native Method 64.4% 0 + 3340 >>> sun.awt.color.CMM.cmmColorConvert >>> 29.4% 0 + 1523 sun.awt.color.CMM.cmmGetNumComponents >>> 0.1% 0 + 7 java.lang.StrictMath.pow >>> 0.0% 0 + 1 java.lang.Object.clone >>> >>> Flat profile of 61.52 secs (5160 total ticks): Java2D Disposer >>> >>> Removing the call to write the aRGB values back in to the image neatly >>> cuts the runtime in half, as well as the number of color conversions. >>> Stub + native Method 61.5% 0 >>> + 1647 sun.awt.color.CMM.cmmColorConvert >>> 29.0% 0 + 776 sun.awt.color.CMM.cmmGetNumComponents >>> [snip] >>> Flat profile of 32.26 secs (2627 total ticks): Java2D Disposer >>> >>> I'm not entirely sure how representative these figures are of the >>> normal behaviour when operating on plain aRGB data, as trials run too >>> fast for the profiler's 10Hz sampling rate. I'll look in to gathering >>> some more useful statistics tomorrow. >>> >>> >>> As a side-note, I just did a check-out of csjava and spent a solid >>> hour trying to fix the project's classpath to no avail. By the looks >>> of things, we are tied to Eclipse 3.0.1 for Windows (the swt includes >>> ). What are everyone's thoughts on adding the libs to the CVS >>> repository so that we can use a relative classpath? >>> >>> >>> ------------------------------------------------------- >>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >>> from IBM. Find simple to follow Roadmaps, straightforward articles, >>> informative Webcasts and more! Get everything you need to get up to >>> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opÌk >>> _______________________________________________ >>> csjava-developer mailing list >>> csj...@li... >>> https://lists.sourceforge.net/lists/listinfo/csjava-developer >>> >>> >>> >> >> >> -- >> Get Firefox! <http://www.spreadfirefox.com/? >> q=affiliates&id=106297&t=65> >> >> >> -- >> No virus found in this outgoing message. >> Checked by AVG Anti-Virus. >> Version: 7.0.338 / Virus Database: 267.9.4/57 - Release Date: 22/07/05 >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >> from IBM. Find simple to follow Roadmaps, straightforward articles, >> informative Webcasts and more! Get everything you need to get up to >> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >> _______________________________________________ >> csjava-developer mailing list >> csj...@li... >> https://lists.sourceforge.net/lists/listinfo/csjava-developer >> >> > > -- > Dr. Toby Donaldson > School of Computing Science > Simon Fraser University (Surrey) > -- Get Firefox! <http://www.spreadfirefox.com/?q=affiliates&id=106297&t=65> -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.9.9/62 - Release Date: 02/08/05 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X