Sep 14
We are running coldfusion 8 enterprise in multi-instance mode on JRUN, and we are trying to do auto image processing for uploads to convert to a standard JPG format in thumbnail and large sizes... pretty standard stuff IMHO.
The problem is that CF8's new image functions completely barf on certain types of images, including greyscale gifs, jpegs with funny colour profiles or jpegs with non-72 dpi.
This would manifest in either jrun bombs or simple resizes of images taking longer than 5 minutes to process instead of the usual < 5secs. This understandably lead to a loss of confidence from the users of the systems when our fancy new upgrade was so painfully slow.
After much frustration we fixed some of the complete bombs happening after reading some of the great tips in this post, but we still had the long processing times to deal with.
After some trial and error the way we got around it was as follows:
- Use cfimage to read in the uploaded file
- Use cfimage to save as PNG. this is the great part! saving as PNG converts the image to 72 dpi and seems to strip the erroneous colour profiles :) and doesnt affect the quality of the image
- Use cfimage to read in the new PNG
- Do what needs doing
- Delete the PNG
- Celebrate your fast and cool utility
Sep 14, 2008 at 11:11 PM oh yeah, gifs were still causing trouble in some weird cases, but we figure screw it... gif is a dead format now... so we restricted uploads to modern photo formats such as png and jpg
Sep 15, 2008 at 12:22 AM Wow, I just was suffering with this same problem for the last week. From what I observed the color profile is exactly the problem. I have been using the 'save for web' function in photoshop and the same 5min processing time was occurring. When I realized this was the problem I switched over to Fireworks to save out the images and the process that took 5 minutes with the same photoshop image was now only taking 2-3 seconds. Weird!
Thanks for the validation.
Sep 15, 2008 at 1:23 AM I thought all that was meant to be fixed in 8.01? If not then well done for finding a workaround.
BTW, in IE7 the labels for the comment fields on your blog are offset by +1. i.e. the first field has no label, but the 2nd field has "name", the 3rd has "email", and the textarea has "website".
Sep 15, 2008 at 2:26 AM Hey thanks for the info! There's an auto-thumbnailing tool in the onTap framework. I wonder if it might be a good idea to apply the convert to png internally there to make it handle those problems in a seamless way.
Sep 15, 2008 at 12:27 PM Hi Gary, yeah we are fully patched up... still buggy! thanks for the heads up, i'm considering ditching wordpress for mangoblog, just had some problems setting it up with the shared host :(
Sep 15, 2008 at 12:30 PM oh, i almost forgot, one other thing you might want to consider reading in images with CFIMAGE is to restrict the filesize for the upload as i believe when is reads in the image to memory it decompresses it, and we easily got stack overflows etc killing the JVM when we tried uploading like 50Mb PNG files to try and break it
Sep 15, 2008 at 7:11 PM I ran into this same problem a month ago. After a lot of research I found that this is a known bug in the java JAI (not a bug in CF). The only known fix is to do what you did (read the file, save the file, read the new saved file, do image manipulation from there).
I wasted a day and a half trying to get past that bug.
Sep 16, 2008 at 2:26 AM It is also worth noting that there is a hotfix for cfimage although this addresses a different issue to the one you've mentioned here:
http://kb.adobe.com/selfservice/viewContent.do?externalId=kb403411&sliceId=1
Nov 8, 2008 at 10:08 AM I am so glad that I found this. I've been banging my head for 2 hrs try to figure out a solution and whala! Thank you!
Dec 31, 2008 at 8:34 AM I am having this same issue. I tried the suggestion to save as a PNG and then re-open and this act slowed the script down a whole lot more.
This workaround did not work for me whatsoever!! :(
May 5, 2009 at 11:36 PM I have an image with a eciRGB v2 ICCv4 colour profile. Rather than taking ages to return a result or even throw an error (cftry/cfcatch is out), it causes the server to restart!
This happens with a simple ImageRead() so I can't try converting to something else before resizing etc.
Any ideas?
May 5, 2009 at 11:39 PM wow that sounds nasty, seems like there are even more issues with it then! i hope they fix it in cf9 or next java version... speaking of which have you tried different JVMs?
May 6, 2009 at 12:53 AM No, haven't changed anything from the standard install.
cftry/cfcatch would have been the last resort for something like this but that's out too.
We may revert to cfx_imagecr as this seems to handle things ok.
May 7, 2009 at 1:34 AM I found that converting to a PNG did not have any effect - it seemed like the color profile remained (I used FusionReactor to watch what was happening and even resizing the PNG had a lot of profile related tasks in the stack trace).
However, I tried converting to a BMP instead and that worked like a champ. An image with a profile that was taking 30 minutes to resize now takes < 5 seconds.
May 7, 2009 at 1:48 AM Thanks Sean, interesting idea, BMP could have less overhead without the need to recompress... good work
Jan 10, 2010 at 7:05 AM Thank you for sharing this post!
This was really helpful!
Good vibe from Mexico!!
Jul 19, 2010 at 10:49 AM I ran into this:
ttp://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/awt/image/ColorConvertOp.html ( to convert the colour profile via standard java )
And of course failing that you could look at this:
http://coldfused.blogspot.com/2007/12/images-and-cfdocument-performance.html
Jul 19, 2010 at 10:52 AM Some java code:
ICC_Profile ip = ICC_Profile.getInstance( ColorSpace.CS_sRGB );
ICC_ColorSpace ics = new ICC_ColorSpace( ip );
ColorConvertOp cco = new ColorConvertOp( ics, null );
BufferedImage result = cco.filter( sourceImage, null );