Menu
▾
▴
csjava-developer — Discussion of the development of csjava.
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(39) |
May
(63) |
Jun
(15) |
Jul
(14) |
Aug
(3) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|---|
|
From: Daryl V. H. <dva...@sf...> - 2005-09-27 22:26:44
|
Hi, all,<br> <br> I've experienced major computer problems (slow downs, crashes, and inability to access drives), so I've had to save my data, reformat my hard drive, and reinstall ALL my software.<br> <br> Unfortunately, I forgot to save some of my data, some of which is not replaceable.<br> This includes my e-mail messages, so I can't go back and review some previous messages.<br> <br> So I'll have to reinstall everything related to this project, which means that I'll be busy for the next couple of weeks.<br> <br> This time, I've allocated my disk space into two portions, one for Windows 98, and the other for Linux.<br> <br> Daryl.<br> |
|
From: Toby D. <tj...@sf...> - 2005-09-27 20:47:42
|
Hi all, It's been a while! For those still interested, there are big changes to csimage in the casey tree of the CVS. I've implemented a new image object that extends BufferedImage, and it's been unofficially released as a beta package for CMPT 126 this semester here at Surrey. If you want to try it out and don't feel like scaling the CVS tree, jump to the end of this page: http://sleepy.cs.surrey.sfu.ca/cmpt/fall2005/cmpt126/proj1 P.S. If you want to add/remove yourself from this mailing list/project, go to http://sourceforge.net/projects/csjava. Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University (Surrey) |
|
From: Daryl V. H. <dva...@sf...> - 2005-08-09 21:54:21
|
I figured out what's wrong with the resize on image loading: After a JFrame is visible and you call .pack() on it, it only packs the window with the current size of the components, it doesn't revalidate all the components as it does before it displays the window. And the only thing that the ImagePainter was doing was setting the preferred size, not the current size of the component. I've fixed it on my computer, but I don't know how to commit anything to the CVS under a tag besides the MAIN tag. I'll need some help with this. Daryl. Daryl Van Humbeck wrote: > Preliminary testing of casey's buttons & menus (under Java 5 aka 1.5) > indicate that the resize on image loading is only resizing the frame > to fit smaller images, not larger images. > Reason is currenly unkown, as the JVM keeps crashing Eclipse with > errors outside the JVM (I am using Java 1.5). > > I might just use JCreator for a while to see if I can find the problem. > > Daryl. > > Toby Donaldson wrote: > >> I hope you haven't forgotten about the impending release of the "casey" >> version of csjava. This will be the last version that does *not* use >> features from Java 1.5. >> >> And speaking of Java 1.5, now is the time to upgrade to 1.5 if you >> haven't >> done so already. Eclipse 3.1 has been released, and it supports Java >> 1.5, so >> after casey we'll csjava will start using it. >> >> Here are the list of features for "casey". If you are going to finish >> any >> more features, let me know now! >> >> Release name: casey >> Date: early July >> New features: >> - Cartesian coordinate system (unfinished; moved to next version) >> - simple axes (unfinished; moved to next version) >> - generic load/save/quit buttons (finished) >> - basic testing code for TheMatrix (finished) >> - basic user-level documentation for TheMatrix (unfinished; moved to >> next >> version) >> - cropping (unfinished; moved to next version) >> - reversi board demo (finished) >> >> Other changes: >> - remove alpha-value code for TheMatrix since it doesn't work correctly >> (add as a feature in a later version) (finished) >> - remove scaling code (add as a feature in a later version) (finished) >> >> >> Toby >> >> > > -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.10.5/67 - Release Date: 09/08/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 |
|
From: Daryl V. H. <dva...@sf...> - 2005-08-02 00:41:55
|
Preliminary testing of casey's buttons & menus (under Java 5 aka 1.5) indicate that the resize on image loading is only resizing the frame to fit smaller images, not larger images. Reason is currenly unkown, as the JVM keeps crashing Eclipse with errors outside the JVM (I am using Java 1.5). I might just use JCreator for a while to see if I can find the problem. Daryl. Toby Donaldson wrote: >I hope you haven't forgotten about the impending release of the "casey" >version of csjava. This will be the last version that does *not* use >features from Java 1.5. > >And speaking of Java 1.5, now is the time to upgrade to 1.5 if you haven't >done so already. Eclipse 3.1 has been released, and it supports Java 1.5, so >after casey we'll csjava will start using it. > >Here are the list of features for "casey". If you are going to finish any >more features, let me know now! > >Release name: casey >Date: early July >New features: > - Cartesian coordinate system (unfinished; moved to next version) > - simple axes (unfinished; moved to next version) > - generic load/save/quit buttons (finished) > - basic testing code for TheMatrix (finished) > - basic user-level documentation for TheMatrix (unfinished; moved to next >version) > - cropping (unfinished; moved to next version) > - reversi board demo (finished) > >Other changes: > - remove alpha-value code for TheMatrix since it doesn't work correctly > (add as a feature in a later version) (finished) > - remove scaling code (add as a feature in a later version) (finished) > > >Toby > > -- 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.8/61 - Release Date: 01/08/05 |
|
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: 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: Toby D. <tj...@sf...> - 2005-07-23 04:14:59
|
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 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: 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: 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: Toby D. <tjd...@gm...> - 2005-07-11 00:20:28
|
Over the weekend I learned about Java's PixelGrabber class, which is a way= =20 of converting the underlying raster data of an image to an ordinary=20 one-dimensional array of ints. The big advantage of this is that=20 read/writing pixels is apparently much faster than going through the set/ge= t=20 methdos of the BufferedImage. So I propose that the next version of TheMatrix implement this PixelGrabber= =20 approach, assuming it is faster (this will require writing some performance= =20 tests). Toby --=20 Dr. Toby Donaldson School of Computing Science Simon Fraser University (Surrey) |
|
From: John E. <joh...@sf...> - 2005-07-10 23:38:04
|
Great idea.
-------------
John
-----Original Message-----
From: csj...@li...
[mailto:csj...@li...] On Behalf Of Toby
Donaldson
Sent: Saturday, July 09, 2005 12:28 PM
To: csj...@li...
Subject: [csjava-developer] notes on harriet release
I've been looking at the original feature list for the harriet
release, and it needs to be changed and firmed up given what has
actually been implemented in the casey version.
I think the main change in harriet should be a fundamental re-
structuring of TheMatrix. Right now, TheMatrix combines the behaviour
of a BufferedImage and a JFrame into one class. This is simple and
convenient for beginners, but it makes it awkward to do more advanced
things, such as adding your own buttons to the frame, or put the
image in some other frame in a window.
The current way around this is to use TheMatrix.getImage() to get a
reference to the BufferedImage, and then use the plain BufferedImage
as needed. This works, but the problem is that the extracted
BufferedImage lacks all the nice extra features that TheMatrix
implements for it (e.g. making copies, multiple set/get methods,
saving/loading, etc.).
So the "obvious" solution (which in fact has taken me some time to
realize as obvious) is to create a new class that extends
BufferedImage, and implements all the nifty extra methods we want for
BufferedImage. Then, we create special JFrame-derived methods for
displaying these images.
While we should be able to keep the original calling behaviour of
TheMatrix, this new design will allow calling code like this:
FancyBufferedImage im = new FancyBufferedImage("pic.jpeg");
// ... process the pixels of im without displaying it ...
show.asPlainFrame(im);
We can make as many "show" methods as we like (maybe with better names).
Any comments?
Toby
--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar
happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by
HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
csjava-developer mailing list
csj...@li...
https://lists.sourceforge.net/lists/listinfo/csjava-developer
|
|
From: Toby D. <tjd...@gm...> - 2005-07-09 19:53:52
|
I've been looking at the original feature list for the harriet
release, and it needs to be changed and firmed up given what has
actually been implemented in the casey version.
I think the main change in harriet should be a fundamental re-
structuring of TheMatrix. Right now, TheMatrix combines the behaviour
of a BufferedImage and a JFrame into one class. This is simple and
convenient for beginners, but it makes it awkward to do more advanced
things, such as adding your own buttons to the frame, or put the
image in some other frame in a window.
The current way around this is to use TheMatrix.getImage() to get a
reference to the BufferedImage, and then use the plain BufferedImage
as needed. This works, but the problem is that the extracted
BufferedImage lacks all the nice extra features that TheMatrix
implements for it (e.g. making copies, multiple set/get methods,
saving/loading, etc.).
So the "obvious" solution (which in fact has taken me some time to
realize as obvious) is to create a new class that extends
BufferedImage, and implements all the nifty extra methods we want for
BufferedImage. Then, we create special JFrame-derived methods for
displaying these images.
While we should be able to keep the original calling behaviour of
TheMatrix, this new design will allow calling code like this:
FancyBufferedImage im = new FancyBufferedImage("pic.jpeg");
// ... process the pixels of im without displaying it ...
show.asPlainFrame(im);
We can make as many "show" methods as we like (maybe with better names).
Any comments?
Toby
--
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University (Surrey)
|
|
From: Toby D. <tjd...@gm...> - 2005-07-09 18:55:21
|
The first testable version of the next release of the csimage package is now available on the CVS repository. This is in the "casey" branch of the repository, not the HEAD. The casey version incorporates Daryl's excellent button version of TheMatrix. Now you can turn on three buttons: load, save, close. They can appear in a menu, on the screen, or in a detached window. By default, no buttons are displayed, but if you right-click the window the load/save/close functions will appear in the context menu that pops up. There are also many small fixes, additions, deletions, and re- organizations. If you can, please take a moment to download this and run some of the demos to help shake out any bugs. Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University (Surrey) |
|
From: Daryl V. H. <dva...@sf...> - 2005-07-09 05:00:44
|
Just so you all know, I won't be doing much development on the csjava project for the next few days, due to the fact that my main development PC isn't working well or at all sometimes. Fortunately, I think it's still under warranty. Daryl. |
|
From: Daryl V. H. <dva...@sf...> - 2005-07-03 03:57:12
|
Hi, all, I've gotten a little tired of writing simple tests and putting them in separate methods inside a source file, having a list of commented out method calls in the main() method, and having to uncomment out the test I want which (of course) makes Eclipse think that it needs to be committed to the server. I have now added a test class (called MethodMenu) that can take the Class object from the that contains the test methods (which are static void and don't take any parameters), an array of strings that represent the method names in that class, and the names to show the user (which can be the same). This new class is under misc.*, not csimage, etc. so it looks like it's more global. As an example, I have rewritten csimage.developers.dvanhumb.ButtonTest using this new tool so that you can see how to use it. If you have any questions, please ask. Thanks, Daryl. -- 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.323 / Virus Database: 267.8.8/37 - Release Date: 01/07/05 |
|
From: Toby D. <tj...@sf...> - 2005-07-02 22:08:27
|
Daryl, Can you add some documentation to MaxAndNora.java explaining what it does and how to use it. Is there any demo chatbot code that lets the user talk to some (simple) chatbot, a la Eliza? Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University |
|
From: Toby D. <tj...@sf...> - 2005-07-02 21:16:02
|
I hope you haven't forgotten about the impending release of the "casey" version of csjava. This will be the last version that does *not* use features from Java 1.5. And speaking of Java 1.5, now is the time to upgrade to 1.5 if you haven't done so already. Eclipse 3.1 has been released, and it supports Java 1.5, so after casey we'll csjava will start using it. Here are the list of features for "casey". If you are going to finish any more features, let me know now! Release name: casey Date: early July New features: - Cartesian coordinate system (unfinished; moved to next version) - simple axes (unfinished; moved to next version) - generic load/save/quit buttons (finished) - basic testing code for TheMatrix (finished) - basic user-level documentation for TheMatrix (unfinished; moved to next version) - cropping (unfinished; moved to next version) - reversi board demo (finished) Other changes: - remove alpha-value code for TheMatrix since it doesn't work correctly (add as a feature in a later version) (finished) - remove scaling code (add as a feature in a later version) (finished) Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University |
|
From: Toby D. <tj...@sf...> - 2005-06-29 19:00:28
|
I don't know which other Java IDEs integrate CVS tools, although that = most configurable IDEs would allow for it. Whether it's as "easy" as in = Eclipse is another question. On an older machine, it might be better to look for a lightweight Java editor, and a separate CVS client. It's only a minor inconvenience to = have different tools for Java and CVS. And you should be afraid of the command-line CVS tools. They have lots = of options, but for basic checking-in and checking-out they are pretty = simple to use; you can probably crib from other examples. Toby -- Dr. Toby Donaldson School of Computing Science (Surrey) Simon Fraser University -----Original Message----- From: csj...@li... [mailto:csj...@li...] On Behalf Of Daryl = Van Humbeck Sent: Tuesday, June 28, 2005 7:38 PM To: csjava Mailing List Subject: Re: [csjava-developer] TheButtonMatrix update Does anyone know of a simple Java programming IDE that runs under Linux=20 that also has CVS support? I'm looking for something simple and fast, but then, what's fast on a=20 200MHz computer anymore? Thanks, Daryl. Toby Donaldson wrote: >Eclipse was not designed to work on older computers, that's for sure. > >On a such a computer, you would be better off to access the cvs tree = via the >command-line CVS commands, or some much simple IDE/tool. > >Toby >-- >Dr. Toby Donaldson >School of Computing Science (Surrey) >Simon Fraser University > > >-----Original Message----- >From: csj...@li... >[mailto:csj...@li...] On Behalf Of = Daryl Van >Humbeck >Sent: Friday, June 17, 2005 11:58 AM >To: csjava Mailing List >Subject: Re: [csjava-developer] TheButtonMatrix update > >An update on my testing: > >A few days ago I finally had my Linux box set up and have spent the = last=20 >few days locating and installing the dependencies and finally I can do=20 >work on it. >Unfortunately, it's only 200MHz (as apposed to 1.8GHz on my Windows = PC),=20 >and only has 144Megs of RAM, so it runs R-E-A-L-L-Y slow. >Also, the first time I ran TheButtonMatrixTest, Eclipse crashed with a=20 >fatal exception. But it did work the way it was written, for a few = seconds. > >Daryl. > >Daryl Van Humbeck wrote: > > =20 > >>Hi, all, >> >>As per Toby's previous suggestion, I've changed the button panel's=20 >>default background colour to White. >> >>I've also added more "ways" to activate the context menu, namely,=20 >>BUTTON2 & Shift+BUTTON1. >>I hope that helps somewhat. >> >>Otherwise, I can't figure out what's wrong with the menus on Linux and = >>Max OS X. >>You might want to check which version of Java you're using, but I=20 >>don't have any experience working with Java on Linux/Unix, so I don't=20 >>know how to help yet. >>I'm very puzzled :-( >> >>Daryl. >> >> >> =20 >> > > > =20 > --=20 Get Firefox! = <http://www.spreadfirefox.com/?q=3Daffiliates&id=3D106297&t=3D65> --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.5/32 - Release Date: 27/06/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=3D7477&alloc_id=3D16492&op=3Dclick _______________________________________________ csjava-developer mailing list csj...@li... https://lists.sourceforge.net/lists/listinfo/csjava-developer |
|
From: Daryl V. H. <dva...@sf...> - 2005-06-29 02:36:55
|
Does anyone know of a simple Java programming IDE that runs under Linux that also has CVS support? I'm looking for something simple and fast, but then, what's fast on a 200MHz computer anymore? Thanks, Daryl. Toby Donaldson wrote: >Eclipse was not designed to work on older computers, that's for sure. > >On a such a computer, you would be better off to access the cvs tree via the >command-line CVS commands, or some much simple IDE/tool. > >Toby >-- >Dr. Toby Donaldson >School of Computing Science (Surrey) >Simon Fraser University > > >-----Original Message----- >From: csj...@li... >[mailto:csj...@li...] On Behalf Of Daryl Van >Humbeck >Sent: Friday, June 17, 2005 11:58 AM >To: csjava Mailing List >Subject: Re: [csjava-developer] TheButtonMatrix update > >An update on my testing: > >A few days ago I finally had my Linux box set up and have spent the last >few days locating and installing the dependencies and finally I can do >work on it. >Unfortunately, it's only 200MHz (as apposed to 1.8GHz on my Windows PC), >and only has 144Megs of RAM, so it runs R-E-A-L-L-Y slow. >Also, the first time I ran TheButtonMatrixTest, Eclipse crashed with a >fatal exception. But it did work the way it was written, for a few seconds. > >Daryl. > >Daryl Van Humbeck wrote: > > > >>Hi, all, >> >>As per Toby's previous suggestion, I've changed the button panel's >>default background colour to White. >> >>I've also added more "ways" to activate the context menu, namely, >>BUTTON2 & Shift+BUTTON1. >>I hope that helps somewhat. >> >>Otherwise, I can't figure out what's wrong with the menus on Linux and >>Max OS X. >>You might want to check which version of Java you're using, but I >>don't have any experience working with Java on Linux/Unix, so I don't >>know how to help yet. >>I'm very puzzled :-( >> >>Daryl. >> >> >> >> > > > > -- 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.323 / Virus Database: 267.8.5/32 - Release Date: 27/06/05 |
|
From: Toby D. <tj...@sf...> - 2005-06-28 23:13:32
|
The latest version of Eclipse is out ... most notably, it now includes support for Java 1.5, which has many nice new features to make your Java programming lives easier. http://www.eclipse.org/downloads/index.php Toby |
|
From: Thomas J. <ntm...@gm...> - 2005-06-22 20:57:06
|
On 6/21/05, Daryl Van Humbeck <dva...@sf...> wrote: > I don't know anything about VMware, is it an emulator of sorts? It's basically a computer in a computer. It emulates the x86 environment and various hardware. You can install an operating system on it, such as Windows, Linux, or your own custom-written OS. You can find the whole marketing spiel at http://www.vmware.com/products/desktop/ws_features.html |
|
From: Daryl V. H. <dva...@sf...> - 2005-06-22 05:05:41
|
I don't want to run both Windows and Linux on the same computer at the same time becuase I can't run them at the same time. I like being able to switch between Windows and Linux with a KVM switch (basically with pressing Scroll Lock twice). That means I can start something potentially long on one computer then switch to the other and do something there while I wait. I don't know anything about VMware, is it an emulator of sorts? Daryl. Thomas Johnson wrote: >On 6/17/05, Daryl Van Humbeck <dva...@sf...> wrote: > > >>Unfortunately, it's only 200MHz (as apposed to 1.8GHz on my Windows PC), >>and only has 144Megs of RAM, so it runs R-E-A-L-L-Y slow. >> >> > >If you have a spare hard drive or extra partition(s) floating around, >Linux is capable of happily coexisting with Windows. Alternately, you >could try to get Linux running in VMware for testing purposes. If you >want, I'd be happy to help you on either of these. > > >------------------------------------------------------- >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.323 / Virus Database: 267.7.10/24 - Release Date: 21/06/05 |
|
From: Daryl V. H. <dva...@sf...> - 2005-06-22 04:44:33
|
While it does crash occasionally, I can still test parts of csjava on it. I don't have enough experience working with Linux's command-line to be comfortable with using a command-line cvs tool. Yet. For now I'm planning on doing my developement on my Windows machine and some testing on my Linux box. Daryl. Toby Donaldson wrote: >Eclipse was not designed to work on older computers, that's for sure. > >On a such a computer, you would be better off to access the cvs tree via the >command-line CVS commands, or some much simple IDE/tool. > >Toby >-- >Dr. Toby Donaldson >School of Computing Science (Surrey) >Simon Fraser University > > >-----Original Message----- >From: csj...@li... >[mailto:csj...@li...] On Behalf Of Daryl Van >Humbeck >Sent: Friday, June 17, 2005 11:58 AM >To: csjava Mailing List >Subject: Re: [csjava-developer] TheButtonMatrix update > >An update on my testing: > >A few days ago I finally had my Linux box set up and have spent the last >few days locating and installing the dependencies and finally I can do >work on it. >Unfortunately, it's only 200MHz (as apposed to 1.8GHz on my Windows PC), >and only has 144Megs of RAM, so it runs R-E-A-L-L-Y slow. >Also, the first time I ran TheButtonMatrixTest, Eclipse crashed with a >fatal exception. But it did work the way it was written, for a few seconds. > >Daryl. > >Daryl Van Humbeck wrote: > > > >>Hi, all, >> >>As per Toby's previous suggestion, I've changed the button panel's >>default background colour to White. >> >>I've also added more "ways" to activate the context menu, namely, >>BUTTON2 & Shift+BUTTON1. >>I hope that helps somewhat. >> >>Otherwise, I can't figure out what's wrong with the menus on Linux and >>Max OS X. >>You might want to check which version of Java you're using, but I >>don't have any experience working with Java on Linux/Unix, so I don't >>know how to help yet. >>I'm very puzzled :-( >> >>Daryl. >> >> >> >> > > > > -- 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.323 / Virus Database: 267.7.10/24 - Release Date: 21/06/05 |
