I keep on getting this error when trying to upload a .JPG file. This error is not present for all jpegs, just for some of them.
I am running CF 9 on a Windows 64-bit server.
Any suggestions on how to modify cfimage tag or workaround this?
Using CF9? Sure. Using CF for image manipulation? Nup. Also your post is quite ill-defined. You say in the ehading it's a problem with CFIMAGE, but then you say it's a problem when you upload an image. I doubt it's anything to do with uploading the image (which is done by the web wever, not CF, anyhow).
However I have used Google, and googling your error suggests the file is quite possibly malformed.
Are the images you're having problems with created / manipulated with a specific application?
Can you post some code and the image you're having problems with? That way people won't just be looking blankly at your post going "WTF?"
Adam, thanks for your reply.
The highlighted line of code throws an error in CF:
"Numbers of source Raster bands and source color space components do not match"
Here is the photo that creates the problem:
I do not know how this photo is taken, other than it was successfully uploaded by a user using cffile on Coldfusion MX server running on Windows 32-bit.
<cfset myoldimage = #cffile.ServerFile#>
<cfset myextsn = #cffile.serverFileExt#>
<cfset mynewimage = "#Form.fullname#" & "." & "#Variables.myextsn#">
<cfset tempfile="C:\Inetpub\wwwroot\images\" & '#Form.photo#' & ".jpg">
<cfimage source="C:\Inetpub\wwwroot\images\#Variables.myoldimage#" action="convert"
<!--- Save the modified image to a file. --->
<cfimage source="#myImage#" action="write" destination="#tempfile#" overwrite="yes">
Thanks for your help.
I am not a CF pro, but I am trying to at least identify the issue here. Saying that Google results say that this JPG file is somehow malformatted or corrupted is not an answer. It was successfully uploaded on a server running CFMX, so how corrupted can it be if the older Coldfusion MX processed it previously?
I think the question was already answered (image is format PNG not JPG), but I suspect you may be misunderstanding the issue.
It was successfully uploaded on a server running CFMX, so
how corrupted can it be if the older Coldfusion MX processed
That is comparing apples to oranges. File uploading and image manipulation are two totally different things. The fact that you can successfully upload a file has little bearing on that file's content or type. For example, you could take an MS Word document and change its file extension to .jpeg and upload that. The success of the upload just means the web server received the data sent. It does not mean the received file actually IS a valid .jpeg, despite the file extension.
The highlighted line of code throws an error in CF:
Which line? None of them appear highlighted. Based on the error (and the fact that ColdFusion MX did not support image processing functions), I assume the error is caused by one of the calls.
The image in question is definitely a JPG file. I don't know why this forum saved it as PNG.
Moreover, the code in question uploads, converts and re-sizes PNG files just fine.
I understand it could be just one corrupted jpg file, but why does CF MX manage to upload it just fine. Just tested it now. CFMx - no problem. CF 9 - fail.
Open your original file with a text editor (like notepad or something).
I bet you £20 the first three characters say "PNG".
Just because a file had an extension of "JPG" doesn't make it a JPG.
Hi Sasha365 ,
Have you found a resolution to this problem where JPG files that can be perfectly read by other viewers fail to read in CFIMAGE with exception "Numbers of source Raster bands and source color space components do not match"?
I am encountering exactly the same problem with some customers in some JPG files. I can confirm it is valid JPGs. Customer reports that the same image works fine in CF8 but once we upgraded to CF9 it fails.
i have found a solution to this problem.
first, install ImageMagick (http://www.imagemagick.org/script/index.php)
then, detect whether or not the image is valid
<cfset image_path = "c:\path\to\image.jpg">
<cfif not isImageFile(image_path)>
here is the fixImage function, customize for your preferences. it essentially converts the image to a jpg format that will not throw an error with cfimage. once you run this function you can resume whatever operation you would have done with the image - IE resizing it.
<cffunction name="fixImg" access="public" returntype="void">
<cfargument name="image_name" type="string" required="true" />
<cfset ext = listLast(arguments.image_name,".")>
<cfif ext eq "gif">
<cfset uploadedImage = ImageNew("#arguments.image_name#")>
<cfset uploadedImage = imageCopy(uploadedImage, 0, 0, uploadedImage.width, uploadedImage.height)>
<cfimage action="write" destination="#arguments.image_name#" source="#uploadedImage#" overwrite="yes">
<cfexecute name="C:\Program Files\ImageMagick-6.6.2-Q16\convert.exe" arguments="""#arguments.image_name#"" -strip -colorspace rgb -quality 100 ""#arguments.image_name#""" timeout="1000" />
<cfset this.err_msg = "#cfcatch.Type#:#cfcatch.detail#:#cfcatch.ExtendedInfo#">
<cfset this.err = true>
#arguments.image_name#<br /><br />
Thanks for your posting. Kinda a sledgehammer approach (using an external program to convert it to RGB first) but a good idea an a good solution to our problem, since this only affects a small percentage of users so we are not too concerned with forking another process. Thanks again.
I am having the same problem, what works fine in CF8 is giving me the raster bands error in CF9. This sounds like a CF9 bug to me! Did you ever find any solutions other than using imagemagick?
No I never did find the problem. I will check with CF10 Devt edition soon to see if the problem still exists. However, I believe the % of jpgs encountering this problem is small, therefore what I did was to CFTRY ImageRead() and CFCATCH on the following condition to do the cfexecute:
<cfif cfcatch.Type IS "java.lang.IllegalArgumentException" AND
(FindNoCase("bandOffsets.leng th is wrong",cfcatch.Message) GT 0 OR FindNoCase("Numbers of source Raster bands",cfcatch.Message) GT 0)>
This at least minimizes the no of times this will occurs so as not to impact server performance.
BTW Jon... this bug exists also in CF8, i've experienced it there. On CF 8 the error is "bandOffsets.leng th is wrong" whereas on CF9 it is "Numbers of source Raster bands" (though this could entirely be dependent on JVM version instead).
In my case, my CF 8 code is working just fine, and I only see it in my CF 9 code. I have also narrowed it down to images that are saved with a grayscale color profile. All of the images are jpeg.
I’ve submitted a bug report to Adobe, and I’m putting in all of my findings, including a link to this thread where I found your comments.
Have a great day!
This error seems to occur when a JPG is encoded in grayscale, on CF9 (at least, that's what I found to be the case when I received the error).
The workaround is to read the image file as a binary object:
<cffile action="readBinary" file="...source to image file..." variable="objBinary" />
<cfset objImage = ImageNew(objBinary) />
... other code ...
<cfset ImageWrite(objImage, "...destination file...") />
Hope this helps someone else out.
I think what you proposed solves for some file read issues but not the CYMK issue. I don't have time to try but you can try the image attached to Sasha365 post above to see if it hits the same problem. Our image upload handling routine now has many CFCATCHes, first level will try the readBinary approach again, then if fail to CFCATCH will check for 'bandOffset' or 'raster' then launch the EXE.
Let me know if your code also works for CMYK in CF8/9 though I doubt it will, because the old code fundamentally does not handle CMYK. In CF10 it is supposed to handle CMYK properly and it is in the list of new features (not tried it yet though, too busy).
Correct, this does nothing for the CMYK issue, which is a separate issue entirely, more to do with the underlying JRE version (there are documented bugs on Oracle's site about this). For these, I just alert the use to re-save as RGB since updating Java is not something I want to entertain on my production servers at this point.