suggested mods to use Intel IPP with IM's JPEG compression

[NicolasRobidoux]

http://software.intel.com/en-us/forums/ ... hp?t=68254 includes a modified jpeg.c.
IPP = Intel® Integrated Performance Primitives (Intel® IPP) http://software.intel.com/en-us/articles/intel-ipp/ that "streamlines digital media and data-processing applications" (it's advertised as a multi-core library but it also uses the Intel vector units intelligently).

[NicolasRobidoux]

Interestingly enough, the portal of Intel IPP features a tech report on libNthumb which compares its thumbnail production speed to ImageMagick's http://software.intel.com/sites/product ... mb-ipp.pdf, down to commenting on IM's parallelization code.

P.S. It appears to me that the writers of the report compare untweaked out-of-the-box ImageMagick commands to software customized for the given task taking full advantage of a non-portable commercial library on a linux OS which uses an antique gcc even by 2010 standards. I'm not saying that IM would "beat" their solution under the best of circumstances. But I think the comparison could have been slightly less one-sided. For example, if you don't care much about quality, compile IM with Q8 by all means.

[Bonzo]

Interesting results but a bit unfair as they have written software to do one thing very well and thats all it can do?

What practical use does it have in the real world?

Also I wonder how much they spent doing it? Can the technology be implimented into Imagemagick?

[NicolasRobidoux]

State-of-the-art JPEG libraries can downsample by a small catalog of specific integer factors by selecting the appropriate "full-size" DCT coefficients. (It's a bit like doing low-pass filtering in the Fourier domain by chopping off high coefficients.) This does not really fit into IM. It's a JPEG-specific trick.
An approach which is more compatible with IM is the one used by vipsthumbnail: Use an efficient integer ratio box filter, and interpolate (with bilinear, say) to adjust to the exact final size. Of course you won't get the quality. But you may get the speed.
On the other hand: I'm not really sure this "fits" IM's niche in the software ecosystem.
A swiss-army knife is not a throwing knife is not an arrow. And vice versa.

[Bonzo]

It is funny that a lot of comparisons between imagemagick ( including the one I did ) all focus on speed; but I would think in most applications a millisecond here or there is not going to matter.

It was interesting in the other artical you linked to in another thread about how an image was resized in two steps the height then the width. I would never have thought it would be done that way.

[NicolasRobidoux]

If you read the report carefully, you'll notice that most of the gain comes from Intel IPP, the library tuned for Intel chips. No wonder Intel put this on the front page.
This is a clear and well-written report. It's just that what it says has to be taken with a rather large grain of salt.
Bonzo: In some contexts, milliseconds matter. The Amazon data is that you lose 1% sales per tenth of a second download time. Generally, however, if you are going to feed thumbnails to the web, you won't perform the reductions on the fly, in part because you don't want to clutter your server's fast memory with large images. Yes, there is a point to speeding up the production of these smaller images. But you don't need IPP and libNthumb to do that. Although libNthumb does seem like a nice out-of-the-box solution when most of your large images are JPEG.
If you really are concerned about IM speed, using vector units in a portable way probably would be a good first step. Then again: IM has about three developers (four? two?), only one of them full-time, and moving to, say, ORC http://code.entropywave.com/orc/ is neither trivial nor fun.

[fmw42]

It was interesting in the other artical you linked to in another thread about how an image was resized in two steps the height then the width. I would never have thought it would be done that way.

That is the way it has been done since the early days of image processing. It is an old trick, since the transformation is linear. Two (or three) shears (and scales) create a rotation. I believe that it can be done faster that way as it only process by rows, then by columns so can use simple incrementation, but it uses more memory as it has to store the intermediate image. However, I will defer to anyone else who knows more about it.

see for example
http://www1.cs.dartmouth.edu/reports/TR96-301.pdf

It has also been done for 3D transformations of bilinear patches (by Ed Catmull and Alvy Ray Smith), see
http://cdlab.berkeley.edu/Papers/CG/2pass80.pdf

[NicolasRobidoux]

...
It was interesting in the other artical you linked to in another thread about how an image was resized in two steps the height then the width. I would never have thought it would be done that way.

Yet a lot of software packages do it this way because it reduces the total number of flops, and allows one to get "true" 2D results while only programming 1D methods. It's a speed thing which actually makes the code simpler. So, IM does it this way with -resize. But not with -distort, which uses "(possibly slanted) ellipses" instead of "rectangles".

[NicolasRobidoux]

The report is really clear as to what makes libNthumb faster. If the "speed graphs" concern you, read the report. A lot depends on Intel's tweaked JPEG library.
Currently, the somewhat recent TurboJPEG (libjpeg-turbo), which you may have installed and linked to IM without even knowing it, probably closes the gap a fair amount.
Simultaneous JPEG decompression and downsampling at read, however, is not something I'd expect implemented in IM. Although I suppose it could. But this only works with JPEG (and only at a few ratios which (may?) depend on the block structure). So I'm certainly not holding my breath for it.
Also, you simply can't expect high throughput for tasks like this without tweaking IM to the specific tasks and context it is running within. Which is why I make a living. As are the libNthumb folk.