Fastest C/C++ image resizing library [closed]

Answer 1

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.

Answer 2

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.

Answer 3

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).

Answer 4

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.

Answer 5

Take a look at VIPS. It's the fastest one I've found so far, and is free for commercial use.

https://github.com/libvips/libvips/wiki/Speed-and-memory-use

On that benchmark, it's 2x faster than Pillow-SIMD, 5x faster than imagemagick, 6x faster than opencv, 8x faster than freeimage, etc. It has dramatically lower memory use too: more than 10x less than imagemagick, for example.

Answer 6

@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!)