CFIMAGE not working with certain JPG

[andrwo]

Hi all,

Got an emergency here, hope anyone can help.

I find that more and more people are encountering problems using CFIMAGE -- no error is thrown when reading/saving certain jpg images, but the result image is just blank and gray.

The code is just simple:

<CFSET IM=ImageRead("C:\DSCN1570.JPG")>

<cfset ImageResize(IM,300,200,"highPerformance")>
<cfset ImageWrite(IM,"C:\DSCN1570-2.JPG")>

or even just:

<CFSET IM=ImageRead("C:\DSCN1570.JPG")>
<cfset ImageWrite(IM,"C:\DSCN1570-2.JPG")>

This happens after applying the latest hotfix for 8.0.1 (Cumulative Hotfix 2 for CF 8.0.1). If this patch is not installed the processing works.

Attached is an offending file. The code works if i replace the file with another jpg.

Any help is much appreciated. I'm running CF 8,0,1,195765 devt edition on Windows XP and my java version is 1.6.0_04. My metadata-extractor is 2.3.1.

Thanks,

Andrew

[BKBK]

There was a known problem with CFImage and Image functions, but I thought that was fixed before Cumulative HotFix 2. What happens when you apply the patch (Technote kb403411, hf801-71557.zip) again?

[andrwo]

Hi BKBK,

Thanks for your reply, but no that is for a different issue to do with file-locking error using CFIMAGE (I should know -- i'm the one who reported that bug to the CF8 team in the first place...)

But I seemed to have found out quite conclusively that it is HF 71557 that is responsible for this problem.

- When Cumulative Hotfix 2 is applied, then the error occurs,

- When hf801-71557.jar is applied, then the error occurs,

- When neither is applied, the image process successfully.

I've just tried in CF9 Centaur GMC -- the error does not occur (everything works fine).

I've also tried updating the CF8.0.1 Java JDK to same version of CF9 (6 Update 14)... same old thing, no luck. I've changed the metadata extractor also to 2.4.0 beta as in CF9 -- also no luck.

Regards,

Andrew

[BKBK]

These are indeed the most frustrating -- patches that fix one hole, only to open up another crack elsewhere. Have you tried saving the file with other extensions, like jpg(small letters) and jpeg?

I opened the image in a text editor and saw that Nikon Coolpix was  probably used to make the image. I wonder whether Nikon puts a header in the image that obstructs Coldfusion.

[Adam Cameron. · Accepted solution]

andrwo wrote:

But I seemed to have found out quite conclusively that it is HF 71557 that is responsible for this problem.

- When Cumulative Hotfix 2 is applied, then the error occurs,

- When hf801-71557.jar is applied, then the error occurs,

- When neither is applied, the image process successfully.

Have you tried with cumulative hotfix 3?

--

Adam

[andrwo]

Hi Adam,

Have you tried with cumulative hotfix 3?

--

Adam

I know there is a cumulative hotfix 3 for CF 8.0, but I thought the latest level for CF 8.0.1 is cumulative hotfix 2?

Please point out to me if there is one. I'm also pretty confused sometimes about the patches and different KB pages seem to have different info...

Thanks,

Andrew

[andrwo]

Hi Adam,

I take that back, you are right, there was a Cumulative Hotfix 3 for 8.0.1 released a week ago or so.

I've applied it and it seemed to have fix the problem with this image...

However, some users in the Comments section of the hotfix page seem to mention that the file-locking bug fixed in HF801-71557 seems to be recurring with CHF3, and since this is a bigger bug/problem I am a bit wary about patching it right away until i investigate further.

Anyone else have applied this CHF3 patch in production -- in relation to 71557?

Thanks,

Andrew

[andrwo]

A follow up to this thread.

I can confirm, after rolling out to our production and encountering 30,000 errors, that Cumulative Hotfix 3 for CF 8.0.1 breaks the CFIMAGE file-writing fix. Image resize and then image write will have a chance of hitting write errors.

I also discovered that while it can handle the JPG sent earlier (which CHF2 couldn't) -- the performance for image resize is problematic -- the file remained at 200Kb after downsizing and the 50x50 thumbnail (using HighestPerformance) > 100 Kb.

So CHF3 is a no go for me, I have to restore back CHF2.

- Andrew

[BKBK]

How sad for you, Andrew. The joy cut short.

With hindsight, I half expected that. It has been my experience that, if Hotfix 71557 fails in Release r, then it will also fail in Release r+1. I have learned to be wary of hot fixes that fail to fix the first time round.

[Adam Cameron.]

andrwo wrote:

A follow up to this thread.

I can confirm, after rolling out to our production and encountering 30,000 errors, that Cumulative Hotfix 3 for CF 8.0.1 breaks the CFIMAGE file-writing fix. Image resize and then image write will have a chance of hitting write errors.

I also discovered that while it can handle the JPG sent earlier (which CHF2 couldn't) -- the performance for image resize is problematic -- the file remained at 200Kb after downsizing and the 50x50 thumbnail (using HighestPerformance) > 100 Kb.

So CHF3 is a no go for me, I have to restore back CHF2.

- Andrew

Yikes.  You put that live without testing it first?  Well, yes, sorry you clearly did.  Oops.  That was probably a bad idea, yeah?  Patches of that sort of scale should always be labbed before being rolled out.  I guess that's a "for future reference" sort of thing, now that the horse has bolted.

Anyway, sorry for being perhaps partly responsible for that happenstance.

Do you have an isolated test rig that can replicate this?  I'd like to see how it goes on CF9.

--

Adam

[BKBK]

@Adam

Yikes.  You put that live without testing it first?

I think he did. He did say this:

@Andrew

there was a Cumulative Hotfix 3 for 8.0.1 released a week ago or so.

I've applied it and it seemed to have fix the problem with this image...

You will usually only do a cursory test of a hot fix anyway. You should be able to rely on Adobe to have done the essential tests.

[andrwo]

Yes, I did do some testing, but that bug is difficult to detect because it only occurs under heavy load. Of course you can argue that I should have done some load testing, but I have my own time pressure to fix this problem so I opted to see the effects of a production run on a Saturday.

Anyway...

Now given the situation, how do I bring this up for the relevant people to fix? Do the powers-that-be ever read these forums? Or should I just pray for divine intervention

Cheers.

[Adam Cameron.]

Yeah, sorry: missed the bit - that BKBK pointed out - about you saying you did some testing.  To be honest, I would never release code into production without load-testing it first.  Especially something that's perhaps already red-flagged as being a risk.  Of course there was no real reason for you to think that the previously fixed issue had been regressed.  So not - perhaps - a red flag.  maybe just an amber one.

I don't believe load testing is a "nice to have", it's essential.  In the past I just slapped my code into production after a bit of a click round to make sure it all seemed to work.  Then we released some code which worked fine whilst only one person was accessing it, but had some severe logic flaws in it which made it fail - in a data-destroying sort of way - which caused us an awful lot of issues with the client (which in turn got me shouted @ by the boss), not to mention wasted time fixing everything.

That lead me to investigate whether we could have found that sort of thing had we load-tested: yes.  Easily.  Lesson learned.  It also turned up a few other things we didn't notice which were easy tweaks which improved the performance of the app, and made the client happy again.

But anyway, that's just something to think about for future reference, I guess.  I fully understand what you mean about time constraints often preventing one from taking the perfect foolproof approach to things: we've all done that. Just sux you got caught out by it.

As for bringing it to Adobe's attention... go here: http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html.

It'd help if you could contrive a stand-alone test rig that can be made to fail under load.

--

Adam