tags:

views:

3616

answers:

6

I am writing a application that needs to resize massive amounts of images... and these are my requirements

  • C/C++
  • Support jpeg/png at least
  • Fast
  • Cross-Platform

So far my options are

  • OpenCV
  • CImg
  • ImageMagick
  • GraphicsMagick (say their fast)
  • DevIL
  • GIL from Boost
  • CxImage
  • Imlib2 (say their fast)
  • Any others?

All of these would get the job done, but I am looking for the fastest here, and I was not able to find any benchmarks on their performance.

+3  A: 

Take a look at Intel IPP (Integrated Performance Primitives) (Wiki link is better then the Intel one...) it works also on AMD and has functions to resize images (bilinear, nearest neighbor, etc) and works on Linux and Windows.

It is not free (but it won't break the bank), but its the fastest that you can find.

Shay Erlichmen
If the image is got decoded, IPP is good choice. However, it could be faster by decoding and scaling in single step. I don't know how to use IPP to resize without decoding 1:1 bitmap first.
kcwu
think for just a moment about that statement. What part of doing it in a single (complicated) step is going to make it any faster? The image decoding routines still need to decode every pixel in order for the filter routines to filter them. Even if their was a library that did it in one pass - our benchmarking of IPP routines would indicate a 2pass with IPP would probably be faster anyway.
Chris Becke
maybe because doing it in the 1st pass it can use the data already in the cpu cache
CiNN
@Chris: kcwu might be right. I remember the man page for convert, with a description of parameter -size -- to limit the decoded resolution of an image, that is intended to be resized down anyway. A paste from the man page: In this example, "-size 120x120" gives a hint to the JPEG decoder that the image is going to be downscaled to 120x120, allowing it to run faster by avoiding returning a full-resolution image.
A: 

If you're looking for free stuff, and want to do things quickly, try to develop a Gimp C-compiled plugin : this is very easy, and I think Gimp does a good job at resizing :

This may not be the fastest to resize, but the cheapest (free) and the fastest to develop.

Take a look there.

Olivier Pons
Or alternatively call the resizer via a Python plugin.
graham.reeds
A: 

If you are looking for open source, how about FreeImage? For commercial stuff, I use Snowbound. Both are quite fast and capable of many different image formats and resizing algorithms.

R Ubben
+2  A: 

@Chris Becke's comment:

"think for just a moment about that statement. What part of doing it in a single (complicated) step is going to make it any faster? The image decoding routines still need to decode every pixel in order for the filter routines to filter them."

That isn't always the case. For example, when decoding a JPEG you can ask the JPEG library to give you a 1/2, 1/4, 1/8 size image (or something like that; it's a while since I've looked in detail) which it can do without having to decode the extra detail at all, due to the way JPEG works. It can be much quicker than a full decode + scale.

(Obviously you may need to scale a bit afterwards if the smaller image isn't the exact size you want.)

(Sorry I can only post this reply as a comment due to no reputaton. First time I've tried to post anything here. If someone wants to repost this or something similar as a comment and delete my answer, feel free!)

Leo Davidson
Make sense, scaling algorithm will give better result with more data (only at a certain small level it doesn't matter) but then again you need to work thru all the different compression methods (BMP, GIF, PNG, JPEG) and write a specific version.
Shay Erlichmen
+1  A: 

If IPP does what you need (e.g function Resize in section 12), then I doubt you'll find signifcantly faster x86 code anywhere else. Bear in mind that it may fall back onto slower "reference implementations" when run on AMD CPUs though.

If CPU isn't meeting your performance requirements, you might consider pushing the resizing onto a GPU using OpenGL (the simplest implementation using texture mapping would benefit from hardware interpolators, for more complex filtering use GLSL shader code). The ability of the GPU to do this sort of thing about a hundred times faster than a CPU (give or take a zero) has to be weighed against the relatively slow data transfer to and from the card though (typically a gigabyte or two per second at the most).

timday
+1  A: 

Take a look at VIPS. It's the fastest one I've found so far.