thumbnail operation performance

[pglizniewicz]

I have a question about the -thumbnail operation performance. I did some tests and the conclusion is, that the performance of the thumbnail operation depends on the ratio between the original and target size. While I already knew that -thumbnail does downsample the original image, what explains its fast performance when the original to target ratio is more than 5:1, I'm observing odd performance for ratios between 3:1 and 5:1.

I did a simple test (using Linux time utility) making thumbnails of an image of size 3712x3712. It was thumbnalized to images from 100x100 to 2100x2100. The odd results are for thumbnails 800x800 to 1100x1100. It's faster to create a 1200x1200 than a 800x800 one. I also compared the performance to -scale with the same dimensions, and for 800x800 to 1100x1100 -scale is twice as fast.

The question is: what is happening here? What is -thumbnail taking so much time to create an image at these resolutions?

resolution	thumbnail (s)	scale (s)
100x100	0,288	1,415
200x200	0,416	1,47
300x300	0,579	1,523
400x400	0,81	1,581
500x500	1,103	1,64
600x600	1,483	1,738
700x700	1,876	1,756
800x800	2,333	1,828
900x900	2,83	1,914
1000x1000	3,379	1,928
1100x1100	4,108	2,036
1200x1200	2,144	2,088
1300x1300	2,215	2,174
1400x1400	2,291	2,242
1500x1500	2,389	2,309
1600x1600	2,475	2,361
1700x1700	2,574	2,461
1800x1800	2,634	2,536
1900x1900	2,717	2,616
2000x2000	2,814	2,7

[snibgo]

In your table, what are the numbers "0,288" etc? Perhaps these are the times in seconds for the operation, using the European "decimal comma".

I suppose your outputs between 800 and 1100 are from resize.c function ThumbnailImage() doing two operations: SampleImage() and then ResizeImage(). The timings will depend on whether your computer uses the GPU, and other factors.

[pglizniewicz]

Yes, seconds, added it to the table. All operations are CPU only, there's no GPU in the machine I was using for tests.

Had a look at resize.c and indeed, this seems to be the problem. If x_factor*y_factor is less than 0.1, ThumbnailImage() will actually Sample the image into a bigger image and then scale.

Is there any reason why (x_factor*y_factor) > 0.1 is not ((SampleFactor*columns) < image->columns) && ((SampleFactor*rows) < image->rows)?

[snibgo]

I don't know why ThumbnailImage() scales up and then resizes down. But the stated goal is to make "small low cost thumbnail images" rather than fast performance.

[pglizniewicz]

Yes, but there is no reason it should perform worse than -resize.

Another problem is, if someone is using Imagemagick to scaledown images to arbitrary dimensions, they have to copy the ThumbnailImage() logic to their app, and choose whether to do -resize and -strip or -thumbnail.

[snibgo]

On my (Windows) computer, timings of one or two seconds are too variable to be a useful guide. I use "-duplicate 9" or similar after reading an image, before doing an operation, for a more reliable performance number.

On my computer, "-sample" is much faster than "-resize", which is slightly faster than "thumbnail", which is slightly faster than "-scale".

This is a bit strange as "-scale" is a simpler operation than "-resize". Why is it slower? I suspect this is because "-resize" uses the GPU but "-scale" doesn't.

... they have to copy the ThumbnailImage() logic to their app ...

I don't understand that. Why copy the logic? Why not just call the function?

If they want some variation of the function, they can do that, of course. If the resulting code is in some sense an improved version of thumbnail, they might contribute it to the IM project.

[urban-warrior]

Rerun your time tests against the main repo or ImageMagick-7.1.0-26 or ImageMagick-doc-6.9.12-40 Beta. Is there an improvement in performance? What about the effect on image quality?