Java 2D Image resize ignoring bicubic/bilinear interpolation rendering hints (OS X + linux)

Question

I'm trying to create thumbnails for uploaded images in a JRuby/Rails app using the Image Voodoo plugin - the problem is the resized thumbnails look like... ass.

It seems that the code to generate the thumbnails is absolutely doing everything correctly to set the interpolation rendering hint to "bicubic", but it isn't honoring them on our dev environment (OS X), or on the production web server (Linux).

I've extracted out the code to generate the thumbnails, rewritten it as a straight Java app (ie kicked off from a main() method) with the interpolation rendering hint explicitly set to "bicubic", and have reproduced the (lack of) bicubic and bilinear resizing.

As expected on both OS X and Linux the thumbanils are ugly and pixelated, but on Windows, it resizes the images nicely with bicubic interpolation used.

Is there any JVM environment setting and/or additional libraries that I'm missing to make it work? I'm doing a lot of banging of head against wall for this one.

Heyman

Well, at least I got the tumble weed badge off this one. Thinking of just farming out to a system imagemagick process instead. – Heyman

Answer 1

I realize this question was asked a while ago, but incase anyone else is still running into this.

The reason the thumbnails look like ass are caused by two things (primarily the first one):

• Non-incremental image scaling in Java is very rough, throws a lot of pixel data out and averages the result once regardless of the rendering hint.
• Processing a poorly supported BufferedImage type in Java2D (typically GIFs) can result in very poor looking/dithered results.

As it turns out the old AreaAveragingScaleFilter does a decent job of making good looking thumbnails, but it is slow and deprecated by the Java2D team -- unfortunately they didn't replace it with any nice out-of-the-box alternative and left us sort of on our own.

Chris Campbell (from the Java2D team) addressed this a few years ago with the concept of incremental scaling -- instead of going from your starting resolution to the target resolution in one operation, you do it in steps, and the result looks much better.

Given that the code for this is decently large, I wrote all the best-practices up into a library called imgscalr and released it under the Apache 2 license.

The most basic usage looks like this:

BufferedImage img = ImageIO.read(...); // load image
BufferedImage scaledImg = Scalr.resize(img, 640);

In this use-case the library uses what is called it's "automatic" scaling mode and will fit the resulting image (honoring it's proportions) within a bounding box of 640x640. So if the image is not a square and is a standard 4:3 image, it will resize it to 640x480 -- the argument is just it's largest dimension.

There are a slew of other methods on the Scalr class (all static and easy to use) that allow you to control everything.

For the best looking thumbnails possible, the command would look like this:

BufferedImage img = ImageIO.read(...); // load image
BufferedImage scaledImg = Scalr.resize(img, Method.QUALITY, 
                                       150, 100, Scalr.OP_ANTIALIAS);

The Scalr.OP_ANTIALIAS is optional, but a lot of users feel that when you scale down to a small enough thumbnail in Java, some of the transitions between pixel values are a little too discrete and make the image look "sharp", so a lot of users asked for a way to soften the thumbnail a bit.

That is done through a ConvolveOp and if you have never used them before, trying to figure out the right "kernel" to use is... a pain in the ass. That OP_ANTIALIAS constant defined on the class it the best looking anti-aliasing op I found after a week of testing with another user who had deployed imgscalr into their social network in Brazil (used to scale the profile photos). I included it to make everyone's life a bit easier.

Also, ontop of all these examples, you might have noticed when you scale GIFs and some other types of images (BMPs) that sometimes the scaled result looks TERRIBLE compared to the original... that is because of the image being in a poorly supported BufferedImage type and Java2D falling back to using it's software rendering pipeline instead of the hardware accelerated one for better supported image types.

imgscalr will take care of all of that for you and keep the image in the best supported image type possible to avoid that.

Anyway, that is a REALLY long way of saying "You can use imgscalr to do all that for you and not have to worry about anything".

Mechanism

Very cool library, the image quality difference is apparent right away. I'm noticing something funny, though--when I try to resize this image postimg.org/image/4icpja3qj to 134 x 100, the Scalr.resize call gives me an image that is 99 px high instead of 100. I'm using that "Method.QUALITY" example you listed, however with the extra flags it's still short a pixel. Any idea why? – Hubbs

The resize calls all take a 'target' size - but imgscalr will never distort the image, meaning it figures out the ratio first, then tries it's best to resize the image to the target without violating it. It's possible that image cannot be made 134x100 without one of the dimensions being violated, so it's making it 134x99. So if you passed in, 200x30 for example, for that image, it would smash the image down into whatever is the smallest box that would fit, WITH the correct proportions, in that box. This is why if you are just targeting a common width, you can just pass in "200" for example. – Mechanism

Given that the sizing ratio for the image is the same as the image's previous ratio (450 x 334 vs. 134 x 100), does the ratio really have to change? I understand where you're coming from, but such a size discrepancy is difficult to work around. – Hubbs

Whoops, looks like you've already provided for what I needed with Scalr.Mode.FIT_EXACT. Thanks, bravo – Hubbs

Answer 2

maybe is this a solution for you:

public BufferedImage resizeImage(BufferedImage source, int width, int height)
{
     BufferedImage result = new BufferedImage(widht, height, BufferedImage.TYPE_INT_ARGB);
     Graphics g = result.getGraphics();
     g.drawImage(source, 0, 0, widht, height, null);
     g.dispose();
     return result;
}

Fuze

You might want to cast (Graphics2D)g so you can setRenderingHints(), specifically with KEY_RENDERING and KEY_ANTIALIASING to control the output quality. Oh, and there's a typo widht/width :) – Kurtiskurtosis

Answer 3

In the end, upgrading to the latest version of ImageVoodoo seemed to improve quality.

Looking through the source code, it looks like they're doing some funky AWT rendering, and then pulling that out. Nasty, but it seems to work.

Still not as good as ImageMagick, but better than it was.

Heyman

Answer 4

@Riyad, the code for incremental scaling isn't "decently large", it's quite small (As you can see from a post back in 2007, http://today.java.net/pub/a/today/2007/04/03/perils-of-image-getscaledinstance.html#creating-scaled-instances) having a library that gives other options might be useful, but making a library to use a library is nonsense.

Millan

Luis - I guess you took offense at my use of the phrase 'decently large'... sorry about that, you are right - the core logic is very straight forward... it can be improved though, which I've done in the library and added quite a bit of additional features/functionality around that core mechanic - so to your comment "having a library that gives other options..." yes... I totally agree... that's why I wrote one :D – Mechanism

Now that I think of it, I think I'm wrong on that one. Your library makes sense because it simplifies the process... Sorry about that. Cheers! – Millan