Imagemagick version 6.3.7-9 runs 2.6x slower than 6.2.4-5

[NZPav]

I have been beta testing Mepis8, a Debian Lenny derivative and trying to work out why video encoding is so slow in comparison to Mepis7, which is based on Debian Etch.
After much testing, I discovered I could install the etch version of imagemagick (6.2.4-5) and video encoding was only marginally slower, by a few seconds per minute than in Mepis7, but when I use the Lenny version of Imagemagick, (6.3.7-9), the same piece of video took 2.58x longer to encode.

Not sure if this is a bug or not, but it's sure bugged me for the last 5 weeks. Has this type of thing been reported previously? I see 6.4.7-10 is now available and was wondering if anybody else has reported or identified a slow-down that may have been fixed? I tried looking through the changelogs, but there is simply too much info there for me to process, and I just don't really understand much of it

My System specs
Asus Notebook
Linux 2.6.27-7-mepis-smp (i686)
AMD Turion(tm) 64 X2 Mobile Technology TL-56
GeForce Go 7300 - 256Mb - Nvidia 177.82 driver
2Gb DDR667

Thanks in advance

Mike P

[magick]

Recent releases of ImageMagick address performance issues as well as adding support for OpenMP which permits algorithms to run simultaneously on multiple cores. If ImageMagick 6.4.7-10 performs poorly, post your workflow here so we can identify any bottlenecks. In some cases we expect a slight slowdown because of added features such as alpha blending and area resampling.

[NZPav]

Great, thanks for that. I'll see if I can get it compiled as a .deb for the community and I to test and report back

Mike P

[NZPav]

Stevo from the Mepislovers community compiled a set of .debs for Mepis and I took them for a spin. These .debs may be compatible with Debian proper.

The results were positive. Still not as fast as etch, but considering the massive additional benefits the latest version provides, I think this is more than sufficient.

Imagemagick from etch took between 52-58 seconds to encode a short piece of video
Imagemagick from lenny took between 124-135 seconds to encode the same short piece of video
Imagemagick 6.4.7-10 compiled for Mepis8 took 104 seconds to encode the same short piece of video on my first run.

That's good enough for me at this stage. Check the following thread on Mepislovers for additional details and comments from the compiler.
http://www.mepislovers.org/forums/showt ... hp?t=18893

Thanks to all

Mike P

[magick]

Can you post the command(s) you are using in your workflow? It may be possible to find additional speed-ups but we need the baseline command set to benchmark from.

[NZPav]

I am using digikam 0.9.4 as the front-end.
I selected 6 photos, then clicked on
Tools > Create MGEG Slide Show...
Set the parameters and ran the encoder

I did not select an audio track for all of my testing.

The command line is :

images2mpg --with-gui -f DVD -n PAL -S 420mpeg2 -d 3 -t 10 -c 000000 -T /var/tmp/kde-michael/kipi-mpegencoderplugin-11575/ -M /usr/bin -I /usr/bin -o "/home/michael/Desktop/toylibtest.mpg" -i "/home/michael/Pictures/Toy_Library/Sand_&_Water/SW006_Little_Tikes_Water_Slide.jpg" "/home/michael/Pictures/Toy_Library/Sand_&_Water/SW007_Noah's_Ark.jpg" "/home/michael/Pictures/Toy_Library/Sand_&_Water/SW009_Waterpark_Whirlee.jpg" "/home/michael/Pictures/Toy_Library/Sand_&_Water/SW011_Do_Re_Mi_Dolphins.jpg" "/home/michael/Pictures/Toy_Library/Sand_&_Water/SW014_Waterwheel_Play_Table.jpg" "/home/michael/Pictures/Toy_Library/Sand_&_Water/SW015_Twinkle_Fish_Set.jpg"
-----------------------------------------------
Initialising...

Encoding image files...

Images encoding (%) : 0 [0
INFO: [yuvscaler] yuvscaler 1.8.0 (15-02-2004) is a general scaling utility for yuv frames
INFO: [yuvscaler] (C) 2001-2004 Xavier Biquard <xbiquard@free.fr>, yuvscaler -h for help, or man yuvscaler
Images encoding (%) : 0 [0
- - - - - CLIPPED - - - - -
Images encoding (%) : 100 [7

Merging MPEG flux...

Encoding terminated...
-----------------------------------------------

EXIT STATUS : encoding process finished successfully.

Hope this helps.

Mike P

[broucaries]

Any new of this bug ?

Bastien

[magick]

Any new of this bug ?

Technically its not a bug since the command completes, however, we are always interested in performance increases. If you check the ChangeLog you will see that there are a number of performance related enhancements to recent versions of ImageMagick including OpenMP support. With OpenMP support, most algorithms are partitioned amongst the cores on your systems and we see, in some cases, a near linear speed-up.

Modern versions of ImageMagick can be slower than legacy versions, in some cases, due to the extra processing required to deal with new features. For example, previously you could get a hallo along the edges of a transparent image when it was resized. We added premultiplied alpha which produces clean edges (a solid pixel next to a transparent pixel) when resized but also adds extra floating point calculations which slows down processing as compared to the original broken algorithm.

To investigate performance issues we need a method to reproduce the issue. Ideally your posting should include a URL to one or two images, an ImageMagick command or short program (that compiles out of the box), and performance statistics (one for a previous version of ImageMagick and one for a modern version, ideally ImageMagick 6.4.9-2 and the hardware attributes including processor speed, memory, and the output of identify -configure). With this information in hand we will report the reason for any perceived slow down. Perhaps we have enhanced the algorithm and more cycles are required or perhaps we will identify an opportunity to increase performance.

[broucaries]

Ok, we have got the different imagemagick command runned and the image used by the user. Do you see something suspicious ?
Any idea to get more informations ?

see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514456

Commands run http://bugs.debian.org/cgi-bin/bugrepor ... bug=514456
images http://bugs.debian.org/cgi-bin/bugrepor ... bug=514456

Regards

Bastien

[magick]

We need the problem reduced to just ImageMagick commands so we can readily reproduce the problem on our systems. We did make an attempt at images2mpg but our system does not support it (we have the Kipi 0.2 plugins) and when we extracted it from an older Kipi release it failed because the underlying utilities have changed (e.g. ppmtoy4m has been replaced by pnmtoy4m with different options).