Skip to main content

Let's discuss about Java imaging

Posted by fabriziogiudici on March 28, 2007 at 5:46 AM PDT

I was happy to see that Slav Boleslawski's article about a specialized component for rendering photos made its way to the featured articles of this week. Indeed if Java wants to gain attention on the desktop, the whole media segment can't be ignored.

Looking around I think we can notice some early warnings that people is indeed working on this area. Today I finished editing a blog post about a component for photo management and rendering, and I included in the article a quick panorama of some existing Java imaging applications (both commercial and opensource) and of the most important Java imaging APIs. I think it would be a good thing if people working both on commercial and opensource imaging application could meet in some specialized forum - not aimed at a particular technology (so I'm not thinking of the Java2D or JAI standard forums), but for sharing the experience and the open problems.

Yes, because in my opinion there are some open problems (I discussed some of them in my post). Apart from a general lack of information (or a difficulty in retrieving that information) about how to use the imaging APIs (a recurring problem is about high-quality image resizing), there are some inconsistencies in how the APIs behave in different systems. For instance, take this table with a few compared performance results about some basic operations performed with Java2D (keep them with a pinch of salt, but I'm starting to be confident with them):

Test Quality
    Mac OS X Linux Ubuntu   Win XP  
J2DUtils.ScaleWithAffineTransform INTERMEDIATE 1214328 1169925 1236672
J2DUtils.ScaleWithAffineTransform (opt) INTERMEDIATE 1859 FAILS  1921
J2DUtils.ScaleWithDrawImage INTERMEDIATE 1844 1044457  1095032
J2DUtils.ScaleWithDrawImage (opt) INTERMEDIATE 3991 3230  2062
ScaleJ2DOp INTERMEDIATE  1755 1161022 1220625
ScaleJ2DOp (opt) INTERMEDIATE  1818 2950 1906
OptimizeJ2DOp INTERMEDIATE  5146 4053 4062
OptimizeJ2DOp (opt) INTERMEDIATE  1663 2940  1734
RotateJ2DOp INTERMEDIATE 24805 4040127 4300516
RotateJ2DOp (opt) INTERMEDIATE 57435 28843 18188

The performance has been measured on a single Mac Mini Dual Core with a triple-boot, so you can actually compare results from the different operating systems. As you can see there are some wild differences, pointed out by the red color. Operations marked with "opt" are performed on optimized images, that is an image made with GraphicsConfiguration.createCompatibleImage(). A "compatible" image "has a layout and color model that is closest to this native device configuration and can therefore be optimally blitted to this device" (from the javadoc of GraphicsConfiguration) and using them is one of the good practices of working with Swing. In facts, as you can see, using them leads to dramatic performance improvements on Linux and Windows (OTOH the bad result is several magnitudos worse, and it's clearly related to some bugs). But one operation miserably fails on Linux with an exception. And... surprise, on Mac OS X the optimized image is not always faster (BTW, the test image is a JPEG converted from a 6 megapixels image taken with a Nikon D100 and loaded by standard Image I/O - both the test image and test sources are in Mistral unit tests). On Mac OS X, by default the used imaging core is not the same as Sun, as this partially explains the difference.

I talked about this only twice with other persons on some random forums, and each time I had the impression that this is part of a dubious, common but unshared knowledge. So, my point is: why don't we setup a specific forum where we can discuss this? An excellent opensource project would be to set up a well-written set of tests similar to the one I've just presented, so that they can be authoritative - it would be a great value for all the imaging Java programmers!

Related Topics >>