Posted in ColdFusion | Posted on 11-01-2008 | 8,204 views
From time to time people will ask (either here, or cf-talk, or wherever) about the speed of ColdFusion 8's image resizing. Typically they are asking because the speed can be a bit slow. My normal response is to remind people that Adobe provided numerous ways to resize, ranging from very slow and high quality options to much quicker and less quality options. I've been meaning to write a script that would compare these resize options and I finally got a chance too this morning.
Before I go into the script, I have to apologize. I normally tell people about the resize options (called interpolation algorithms) and then point out that Adobe ships 17 choices. However I was wrong. The options are grouped into a list of values with generic terms like highPerformance or highestQuality and named ones like lanczos and hanning (which sound like Star Trek names if you ask me).
Here is where things get a bit weird. You would think there would be a one to one relation between the generic and named options. However there are more named options than generic ones. My assumption is that Adobe mapped some of the generic options to one of the named options. I created the following list would uses both the generic and named options, and should represent a move from highest quality to highest performance.
- highestQuality
- lanczos
- highquality
- mitchell
- mediumPerformance
- quadratic
- mediumquality
- hamming
- hanning
- hermite
- highPerformance
- blackman
- bessel
- highestPerformance
- nearest
- bicubic
- bilinear
My script would go through each of these, perform a resize and see how long it took, how big the file was, and output a link to the image so I could see the quality.
In my first test using a 300k or so JPG, the highest quality resize took a huge amunt of time - close to 4 minutes. In my second test, using a larger image, it took a lot less time. The docs do say that resizing performance/result will depend on the source image, which isn't surprising, but it bares repeating I think.
Something else I noticed was that - both with the super slow to resize image and the not so slow image - I was not able to visibly tell a difference. It may be that I don't have an artist's eyes. It may also be that when I saved the image, I always used the highest quality setting (so in other words, a range of options for resizing, but always the best for saving). Based on what I saw though - at least for images to be shown on the web - I see no reason to not use the quickest resize. Of course 2 tests isn't very scientific, but it's something to keep in mind. ColdFusion defaults to the highest performance. I'd probably not use that default in my applications.
I've included the script I used below. All you have to do is modify the sourceImage line to test yourself. Here is the results from my last test:
| Method | Size | Time (Seconds) |
|---|---|---|
| highestQuality | 425Kb | 1.703 |
| lanczos | 425Kb | 1.703 |
| highquality | 392Kb | 1.187 |
| mitchell | 392Kb | 1.188 |
| mediumPerformance | 392Kb | 1.203 |
| quadratic | 367Kb | 0.938 |
| mediumquality | 390Kb | 0.704 |
| hamming | 390Kb | 0.688 |
| hanning | 398Kb | 0.687 |
| hermite | 397Kb | 0.703 |
| highPerformance | 390Kb | 0.687 |
| blackman | 407Kb | 0.687 |
| bessel | 385Kb | 1.828 |
| highestPerformance | 433Kb | 0.031 |
| nearest | 435Kb | 0.016 |
| bicubic | 433Kb | 0.032 |
| bilinear | 414Kb | 0.031 |
Notice that there seems to be no real difference in file size. At most 50k or so separates them. Also notice that bessel is oddly slow compared to the algorithms near it. That may be one to avoid.
In case you want to see the images themselves (I felt they were too big to include on this blog entry), I've linked the original, highest quality, and highest performance images:
2/**
3* Will take a number returned from a File.Filesize, calculate the number in terms of Bytes/Kilobytes/Megabytes and return the result.
4* v2 by Haikal Saadh
5*
6* @param number Size in bytes of the file. (Required)
7* @return Returns a string.
8* @author Kyle Morgan (admin@kylemorgan.com)
9* @version 2, August 7, 2006
10*/
11function fncFileSize(size) {
12 if ((size gte 1024) and (size lt 1048576)) {
13 return round(size / 1024) & "Kb";
14 } else if (size gte 1048576) {
15 return decimalFormat(size/1048576) & "Mb";
16 } else {
17 return "#size# b";
18 }
19}
20</cfscript>
21
22<cfset methods = "highestQuality,lanczos,highquality,mitchell,mediumPerformance,quadratic,mediumquality,hamming,hanning,hermite,highPerformance,blackman,bessel,highestPerformance,nearest,bicubic,bilinear">
23
24<cfset results = queryNew("method,size,time")>
25
26<cfset sourceImage = expandPath("./DSC00014.jpg")>
27
28<cfset finfo = getFileInfo(sourceImage)>
29<cfset img = imageRead(sourceImage)>
30<cfset iinfo = imageInfo(img)>
31
32<cfdump var="#iinfo#" label="File Size in Bytes: #finfo.size#">
33
34<cfimage action="writeToBrowser" source="#sourceImage#">
35
36<hr/>
37
38<cfloop index="m" list="#methods#">
39 <cfoutput>
40 <h2>Resize Method: #m#</h2>
41 <cfset newImage = duplicate(img)>
42 <cfset timer = getTickCount()>
43 <cfset imageScaleToFit(newImage, 700, 700, m)>
44 <cfset total = getTickCount() - timer>
45 <cfset filename = m & "_" & getFileFromPath(sourceImage)>
46 <cfset imageWrite(newImage,expandPath(filename),1)>
47 <cfset finfo = getFileInfo(expandPath(filename))>
48 <cfoutput><p>#fncFileSize(finfo.size)# bytes at #total/1000# seconds</p></cfoutput>
49 <img src="./#m#_#getFileFromPath(sourceImage)#">
50 </cfoutput>
51 <cfset queryAddRow(results)>
52 <cfset querySetCell(results, "method", m)>
53 <cfset querySetCell(results, "size", fncFileSize(finfo.size))>
54 <cfset querySetCell(results, "time", total/1000)>
55 <cfflush>
56</cfloop>
57
58<cftable query="results" border colHeaders htmlTable>
59 <cfcol header="Method" text="#method#">
60 <cfcol header="Size" text="#size#">
61 <cfcol header="Time (Seconds)" text="#time#">
62</cftable>


One thing I may want to look at is the blurFactor option for resizing. To be honest, I was a bit unsure of why you would want _any_ blur. It seems like that would be used for enlarging images only.
<!--- Turn on antialiasing to improve image quality. --->
<cfset ImageSetAntialiasing(myImage,"on")>
<cfset ImageScaleToFit(myImage,100,"","lanczos")>
... although I've never seen side-by-sides that demonstrated what that improved quality was supposed to look like, or seen any other explanation of what it does beyond what you are citing from the live docs.
Hmmmmm....
Use the ImageSetAntialiasing function to improve the quality of the rendered image.
Testing now...
<cfif structKeyExists(url, "aa")>
<cfset imageSetAntiAliasing(newImage)>
</cfif>
I added it right after the first gettickcount. I tested both w/o it, and with it. The times are a bit off, but not in a significant way. To be honest, I see no difference. I thought maybe I could see it in the moss, looking closely, but I was not able to.
I'm going to try a third option now - off. I assume it is the same as not setting it at all... but I'm going to test that too.
I should also try a GIF and TIFF too.
http://www.flickr.com/photos/stevenerat/156895786/...
I'll do some tests with this image, although I'm really surprised it makes a big difference
Thanks
For instance if your image is 1000px and you want a 100px thumbnail it would take 4 resize operations:
1000 : 50% = 500
500 : 50% = 250
250 : 50% = 125
125 : manual resize = 100
I wonder if the same is true with CFimage as well.
Maybe my next project will be something that converts ideas into time. :P
http://www.webveteran.com/blog/index.php/web-codin...
"Sure enough, the multiple pass method in PhotoShop yields a nicer image. However, it looks like a single pass resize with CFimage looks better."
I've also been testing the ImageResize with the ImageSetAntialiasing on/off and I see no different.
My biggest probelem is to get good quality for my thumbs.
If I Resize e.g. 3504x2336 px image to 920x613 and then to 100x67 the 920x613 quality is fine (specially if I use the ImageSharpen) but the 100x67 is has poor quality.
I tryed both bilinear and the Highest Quality and the differnt was negligible in the 920 pixel image but huge in the 100 pixel thub.
Do you know any trick's to help me whit my thumbs?
My app allows the user to upload a front and a back image of a coin and resizes them both to 600x600 pixels, then resizes again to 60x60 for the thumbnail. Using getTickCount, I find that it can take almost 3-6 seconds to resize an 800x800 to 600x600, even using bilinear.
Most peculiar.
Method Size Time (Seconds)
mediumPerformance 363Kb 471.384
quadratic 343Kb 369.116
mediumquality 362Kb 265.692
hamming 362Kb 265.255
hanning 368Kb 264.927
hermite 368Kb 266.177
highPerformance 362Kb 265.427
blackman 376Kb 264.724
bessel 355Kb 724.482
highestPerformance 405Kb 0.515
nearest 413Kb 0.094
bicubic 405Kb 0.172
bilinear 393Kb 0.25
Highest Quality: 666.993 seconds
lanczos 660.074 seconds
highquality 466.821 seconds
mitchell 471.246 seconds
mediumperformance 480.584 seconds
quadratic 371.537 seconds
mediumquality 269.695 seconds
hamming ....
Here the script timed out (I had it limited to an hour)
If you have any other suggestions I would appreciate it. I am working on a photo application so this is becoming a little burdensome! Our other server (production) has no problem with this (JVM 1.6.0_01).
Method Size Time (Seconds)
highestQuality 1.12Mb 7.531
lanczos 1.12Mb 7.625
highquality 1.12Mb 5.407
mitchell 1.12Mb 5.344
mediumPerformance 1.12Mb 5.297
quadratic 1.12Mb 4.219
mediumquality 1.12Mb 2.968
hamming 1.12Mb 3.063
hanning 1.12Mb 3.204
hermite 1.12Mb 3.469
highPerformance 1.12Mb 3.156
blackman 1.12Mb 3.188
bessel 1.12Mb 8.297
highestPerformance 1.12Mb 3.438
nearest 1.12Mb 0.422
bicubic 1.12Mb 0.594
bilinear 1.12Mb 0.297
So it looks like it is an issue with the jpgs I was using for testing. I found this thread:
http://www.coldfusionmuse.com/index.cfm/2009/6/10/...
which suggests a JVM upgrade should have fixed it. I will work around by using 'nearest' on the dev box and it shouldn't be an issue on the produciton server. Still wish I new what the hell was going on!
[Add Comment] [Subscribe to Comments]