Hi Norman,
Thanks for the detailed report! I don't have time to try this out right
now, but I have a couple of comments:
[EMAIL PROTECTED] wrote:
1. Select menu > File > Open image directory... and select a
directory with
some images. This is the first challenge, because JFileChooser is
still
about as user-unfriendly as possible. (I somewhat fear that many
first-time
classpath users might give up after trying to use JFileChooser.
This is
unfortunate, because the rest of Swing works pretty well these days.)
Is this before or after Roman's JFileChooser patch (last night)?
5. Select Tools > Sharpen > Laplace 3x3. Simple convolution filter
implemented
with ConvolveOp and applied to a BufferedImage TYPE_INT_RGB.
java.lang.ArrayIndexOutOfBoundsException: 3
at java.awt.image.ColorModel.getComponentSize(ColorModel.java:200)
at java.awt.image.ColorModel.coerceData(ColorModel.java:641)
at
java.awt.image.DirectColorModel.coerceData(DirectColorModel.java:405)
at java.awt.image.BufferedImage.coerceData(BufferedImage.java:288)
at java.awt.image.ConvolveOp.filter(ConvolveOp.java:126)
This worked a week ago, but very slowly. Try the Tools > Edges >
Mexican
Hat 13x13 filter, if you don't believe me. The JDK seems to include
some
optimizations for such (separable?) kernels.
OK, lets try something else:
I did some cleanup work on ConvolveOp not too long ago because it was
broken. It works now, but slowly. There is a FIXME in the source code
at the point where we need a different approach to get a speedup. If I
recall correctly, for each pixel in the output raster, we do N x N
lookups in the input raster where N x N is the size of the convolution
filter. For 3 x 3, that will be slow (effectively reading the raster
pixel by pixel 9 times). For 13 x 13, that will be unusable.
6. Select Tools > Negative Image. Obvious implementation based on
LookupOp. Works. Performance is ok (1 sec for 800x600). The result is
a BufferedImage.TYPE_INT_RGB.
BUT repainting suddenly takes 3 seconds for each paintComponent,
and the application is pretty much dead. For comparison, a repaint
of the
BufferedImage before the filtering took about 10 msec.
For 3000x2000 images, each repaint takes 40 seconds on my system.
Any ideas about what I am doing wrong here are HIGHLY appreciated.
Load a new image. Repainting time is back to the millisecond range.
Sven will probably know the answer to this. I'm sure it has something
to do with the DataBuffer implementations. The source image most likely
uses some private class that implements a "managed" data buffer, whereas
the destination image will be using the array-based DataBuffers in
java.awt.image.* (which are sure to be slower).
Anyway, thanks again for the detail...I'd love to spend some time on
this right now, but alas I don't have any...
Regards,
Dave
