A few months ago I was experimenting with QuickTime for Java. It’s the binding between Apple’s QuickTime “stuff” and the Java language, allowing a Java developer to invoke QuickTime on the Mac (and presumably also on Windows). The reason this appeals is that we do Java, and have accumulated a fair amount of Mac hardware.

To cut a long story short, my limited experienced shows that QuickTime, when compared to the standard Java image libraries, produced smaller images of higher quality, faster. It’s unusual to get all three benefits together (smaller, faster, better). Too good to be true, even, which leads me to think I’ve screwed up someplace, but I’ve not spotted it yet.

The particular test that interested me was was taking a camera phone photo, resizing it and rotating it. Here’s an example original:

Jack

Here’s the rotation using tried-and-trusted AffineTransform plus ImageIO:

affine

And here’s the same transformation run through QuickTime for Java using the GraphicsImporter and Matrix objects:

matrix

Now, it’s subtle but the QT4J image looks to have sharper colours, and seems to be a better representation of the original input. It’s also 20k compared to the 76k using the Java 2D libraries, and the code runs 1.7 times faster. The downside: you need Apple hardware.

Update: sadly these JPG images have been downloaded and re-saved since this post was written, for various blog platform ports. The quality will have dropped.

A few conclusions: it seems the Java 2D code doesn’t just fall through to QuickTime on the Apple platform in any simple sense (which, I suppose I might have naively expected). Second, I suspect there’s a lot of tuning that can be done in the Java 2D client usage to improve the quality, but QT4J seems to have good defaults.

(Before you ask, the dog’s name is Jack.)