Imagemagick, Imagick and GD speed tests with php

[Bonzo]

Over the last month or so I have been doing some speed tests and have put the results into a pdf ( 604kb ).

Some of you may be interested and I would like to read any comments you have.

http://www.rubblewebs.co.uk/imagemagick ... ests_1.pdf

[immortal26]

Some of the Imagemagick commands are a little heavy for per say the text you created.
I know for a fact that GD would not be faster in creating that stroked text simply because of the loop to be able create the stroke...
But.. all in all, it all depends on what you are doing... so benchmarking is unneccesary IMO.
Pretty much, if i'm using Imagemagick, the rest of the code is going to be imagemagick... not good programming techniques to combine.

[Drarakel]

You may want to correct that file size typo in the other thread, as not many users would want to download the PDF if it really was that big:
viewtopic.php?f=4&t=16779

Over the last month or so I have been doing some speed tests and have put the results into a pdf ( 604mb ).

Personally, I don't use environments with GD or something with PHP at the moment, so I'm not really the right one to comment on these things... I noticed that the file size comparisons are a bit 'unfair', as the results will heavily depend on what input images (and what metadata) are used - and one can influence the file size easily by specifying more options. But you stated it quite well, that there are differences in the behaviour (for example whether the color profile is stripped with -thumbnail) and that you wanted to test with default settings (as these are the settings that most of the people will use).
So.. Nice PDF!

[Bonzo]

I have changed the filesize - do not know what I was thinking.

I left most of the code as default as I think that is the way most new users would use it and as you noticed I put a comment to that effect.
As you point out there are more options in Imagemagick I could have added to improve the image but I decided to stick to the speed rather than the quality for these tests.

I think that the results between test 1 and 2 are interesting as the input image is the same and its only the output image size that changes.

[fmw42]

I have posted some timing tests that I did a while back with the help of user Bonzo at viewtopic.php?f=4&t=16779#p62061

[Drarakel]

I have changed the filesize - do not know what I was thinking.

But it's still "604mb" there?
viewtopic.php?f=4&t=16779

[anthony]

The timing tests on different distorts show just how complex some distorts are.

Arc for example requires the use of trigonmetry functions which are inherentally slow, so it is naturally the slowest distort of them all.

Bulge requires pythorgain radus measurement whcih includes a "Square Root", making almost as complex as Arc.

Perspective however uses a sort of 'incremental scanline' technque (which was well documented), so gets quite a speed boost as it does not need to constantally re-caclulate thing from scratch.

I would like to see a compare of rotate using SRT distort and a rotate using -rotate. I have a strange feeling that the SRT distort is faster (it should be faster than perspective), mostly due to not needing to generate two intermediate (skew) tranformation in the technque the older -rotate uses.

NOTE: Perspective can also so affine transforms (EG SRT distort), as it is really just a ratio of affine transforms.
However it can be a low slower when images get highly compressed, and the EWA resampling starts to get involved.


Fred would also include tests for bilinear-forward and bilinear reverse.

It would also be nice if the actual test and the before/after images (as thumbnails) is included in the PDF document.

[anthony]

Question why did you use BarrelInverse rather than Barrel?

The Inverse has a division which is computationally harder than the more typically used Barrel distortion.



Also note that with distort the result is also highly dependant on the FINAL image size generated. Same for resize which is a specialised and highly optimized form of distort.

For better comparison the resulting image should also be the same size in all examples. You can do this either
by using a -set option:distort:viewport which overrides any size determination
distort may perform.

Also setting -filter point will turn off any influence of the EWA (multi-point gaussian cylindrical filtering) resampling algorithm. Usually however EWA only comes into play for HEAVY compression, such as near-horizon effects of tiled-perspective. Shepards and Depolar Distortions do this automatically as the derivatives are too complex to work out, but Arc doesn't so EWA has some 'near center' effects.

Removing the final save (use null: for output) would also remove that aspect of the processing from the timing,
though image reading would still be an issue.

[fmw42]

Question why did you use BarrelInverse rather than Barrel?

The Inverse has a division which is computationally harder than the more typically used Barrel distortion.



Also note that with distort the result is also highly dependant on the FINAL image size generated. Same for resize which is a specialised and highly optimized form of distort.

For better comparison the resulting image should also be the same size in all examples. You can do this either
by using a -set option:distort:viewport which overrides any size determination
distort may perform.

Also setting -filter point will turn off any influence of the EWA (multi-point gaussian cylindrical filtering) resampling algorithm. Usually however EWA only comes into play for HEAVY compression, such as near-horizon effects of tiled-perspective. Shepards and Depolar Distortions do this automatically as the derivatives are too complex to work out, but Arc doesn't so EWA has some 'near center' effects.

Removing the final save (use null: for output) would also remove that aspect of the processing from the timing,
though image reading would still be an issue.

Because one of my clients was using my texteffect script and wanted to know if Imagick was faster and texteffect uses barrelinverse as it needs fewer arguments to achieve a similar amount of bulge or pinch so it was easier to work out in the script.

All I tried to do in my PHP tests was to make the tests as equivalent as possible given any type of distortion. I was not concerned about quality of output in terms of optimizing size or filters. I tried to use the basic defaults.

I just wanted to see if Imagick was truly much faster as it was an API and it was not, except for the resize.

[anthony]

I just wanted to see if Imagick was truly much faster as it was an API and it was not, except for the resize.

The only place at which an API would be faster is in the parsing phase of command line. All other aspects are core magic library which is where most of the image would be spent, as such you should not see any great difference.

However Command line often does do some extra work, above that of the API, to make life a little easier due to the more restrictive usage. For example parsing distort and sparse color strings into a floating point argument array. This is especially tricky for sparse color! Or for the additional parsing of percent escapes, which API's can do more directly using their own internal provided string functions.

The biggest difference is that API's do not have just a single 'current image sequence' with a push/pop stack (the parenthesis on command line), but can have as many such sequences or 'image lists' as they like. For example on command line "-layers composite" has to look for that special "null:" image, to divide the current image list into two image lists for list composition. API's should not need to do this as they naturally can have multiple image lists.

[fmw42]

The only place at which an API would be faster is in the parsing phase of command line. All other aspects are core magic library which is where most of the image would be spent, as such you should not see any great difference.

This is very interesting and nullifies I think a gross misunderstanding I have if not many others that APIs will be a lot faster.

You even recommended to me to use PerlMagic to do things faster, but I suspect it was for very specific purposes (such as with -fx trying to get neighborhood statistics). But I guess I misunderstood and thought it was also faster in general.

Thanks for the clarification.

Can you explain why resize is noticeably faster with Imagick. It was the only test that showed that improvement.

If APIs are not much faster, then why do people insist on using them so much? What else do they offer that would be an advantage that one could not do in a command line script?

[anthony]

If APIs are not much faster, then why do people insist on using them so much? What else do they offer that would be an advantage that one could not do in a command line script?

Mostly because API's don't need to re-read or re-initialise all the time.

Because API's can

• store in memory a array of many image lists that can be processed in any order you like. For example I have a program that reads in hundreds of images, thumbnailing tham as 32x32 pixel images as it reads them, them compares them all in pairs one pair at a time (9,900 compares for 100 images). another would be to say sort images by general color in memory!
• if the API is already running you have little to no setup time
• You can be doing man many threads of image processing command line is limited to one line and generally in sequence processing
• You can retrieve information from images, and use that information in complex ways to modify image processing without having to re-initialise the image processing (re-reading configs and images) over and over. My jigsaw script is a good candidate for this as it starts and stops repeatedly.
• Looping though images, doing something very different with each image!

Basically it is only core library that is about the same speed. Parsing and multiple initialization of images can take a lot of time if you only can do small steps between each processing step.
But for most things the command line API is pretty well just as fast, especially if you

• make use of MPC image saving (for faster re-reads).. See my script divide_vert
• and paralleled processing using pipe-lining (even using different machines for different steps!) See enlarge_image for a pipelined script example with one step piping the image(s) into the next.
• loop of individual image processing, piping a stream of images into a final 'merge them all' type command. I have many scripts like this... See the second example of 'Layered Image Processing http://www.imagemagick.org/Usage/layers/#example

Of course in an API different and faster techniques could also have been used in some of these scripts.

[fmw42]

Thanks. That is very informative.

[anthony]

Another point for API's...

• Direct and Random access to the image in whatever way you like.

For example --- Flood Fill is an almost impossible task to implement on the command line without using thousands of individul IM commands.

-fx in command line only provides 'ordered' access, though it can randomly access a second image which is how 'distorts' work. However it still goes though the 'destination image' in that ordered sequence.


I have placed that discussion at the option remarks for
APIs and other IM usage methods
http://www.imagemagick.org/Usage/api/#api

[fmw42]

I have placed that discussion at the option remarks for
APIs and other IM usage methods
http://www.imagemagick.org/Usage/api/#api

Thanks. That is most helpful to be able to get to that easily.