Actually, I changed the old version to be faster as well and uploaded it. You shouldn’t see either version using up a lot of cycles in panning. If you do, let me know, but I wouldn’t immediately have an answer for it.
I was more interested in the rescaling and rotation quality. You can run them side-by-side. Let me know what you think.
I’ve checked a Linux and a Windows machine and hardly any cycles are being used once the images are loaded. I heard the GPU fan kick in though.
I checked all your filters and the Lanszoc3 filter appears to be the best one to my eyes. The others result in a lot of blurriness.
I had inserted numerous obscenities in the code and I didn’t want to offend anyone. However, I just ran sed on the source code and eliminated all the foul language. I’ve updated the ZIP file and the source code can be downloaded here: http://myweb.dal.ca/mkiefte/TextureDemo.java
I played with that briefly, but I couldn’t get rid of it. I don’t know where it comes from. I’ll have to dig.
Lanczos3 is clearly the best of all of them for downscaling, as it’s
the best at handling high-frequency regions (i.e., where there are
sharp changes in color, i.e., edges). Since the filter is not being
applied in real-time, then we could potentially get even better results
by increasing the window size from 3 to something larger, maybe 7,
though the time to filter is quadratic in the window size, so it’s
going to take 5.4 times longer that way. I couldn’t say whether it will
be 5.4 times better-looking for the extra computation done until
we try it. (The way to get LanczosN for whatever N you want is to
replace the 3’s in the code with your preferred N.)
The current implementation too general, although that’s what you need right now in VASSAL. I only need it for factor-of-2 downsampling and all the images already have to have power-of-2 dimensions, so this could be done via 2-d FFT very efficiently. As long as the length of the filter is also a power of 2, the operation should be extremely fast.
The Java AWT does have a ConvolveOp.class, but there’s nothing to say that’s it’s done using FFT, and my guess is that it isn’t.
Yes, you’re certainly right—given some assumptions about the input,
this could be made much faster than it is. Without any such assumptions,
I think it’s about as fast as it can be right now.
If we can do this with FFTs, then maybe we could also ship the work
off to the GPU for creating the mipmaps? That would be wicked fast,
since a GPU is basically just a whacking big matrix multiplier.
(I figured you’d know something about this stuff, BTW, as you work
on audio. The only real difference between sampling audio and images
is the number of dimensions, since hardly do you ever see anyone
using a filter which isn’t separable (which could in give you better
results in 2D than making a pass along each dimension with a 1D filter,
but at the expene of being a lot slower). I learned a lot about these
things from talking with Leigh Smith, a guy in my institute who works
on music cognition.)
The performance of the ConvolveOp class is crap, last I checked (as
I looked into that when I was writing and optimizing this stuff last
fall).
You can do it with fragment shaders. Or you could use a filter when you paste it directly onto the back framebuffer and then copy the image to a texture all inside the GPU. I don’t know if JOGL will let you do that, though. I can check it out, but I think it’s low priority right now as that can be done probably fast enough with a good FFT library. Is there such a thing for Java? We’re already using platform-dependent binaries, might as well go all the way.
And if you do fMRI, you can do it in 3D! (with a basement lab full of RedHat servers, although today, I could probably do it on my laptop).
We have somewhere here who does that. Don’t know a whole lot about it. I used to do a lot of DSP in the lab, but with all the tools that are available these days, I have to admit that I don’t think about it very much any more. Though when I was your age, we had to do FFTs by hand with an abacus. And we had to walk 5 miles in the snow to do it.
The lost opportunities just kill me.
Otherwise my impression of Java is quite positive. I’m thinking of doing more work in Java now that it appears somewhat mature and relatively easy to learn.
Thing is, we already have to have native binaries, so might as well have native FFT libraries. I know it sounds bad, but if we have an FFT implementation for every platform for which JOGL native binaries exist, then it won’t matter at all. They would just go in the same library directory.
However, FFT could just be written in Java and it would still be an order of magnitude faster than what we’re doing now. In fact, FFT is so simple, that I could just write it myself… I’ll have to open a book though.