This content has been marked as final. Show 19 replies
I tested the image with the patch applied. The result is the same: javax.imageio.IIOException: Quantization table 0x02 was not defined ... However, ImageIO.write is able to save this image to disk
imageVariable = ImageNew( ExpandPath('024nt5.jpg') );
bi = ImageGetBufferedImage(imageVariable);
outFile = createObject("java", "java.io.File").init( ExpandPath('024nt5_savedWithImageIO.jpg') );
ImageIO = createObject("java", "javax.imageio.ImageIO");
ImageIO.write( bi, "jpeg", outFile );
I assume this does not happen with every image, just certain image files? Again, while I suspect it may be a bug, without knowing more about the internals of CF's image handling, there is still a small chance that the cause may be the image file itself. I know that does not help with your current issue, but using the ImageIO.write work-around will let you to write the images to disk. At least until you have a definitive answer, one way or the other.
i confirm exact same error.
installed updates: hf801-71471.jar, hf801-71557.jar
message: Quantization table 0x02 was not defined
I also stumbled upon the exact same problem after running the cf 8.01 updater. I've added a function to my code to allow the image to be written using ImageIO or the JPEG encoder if imageWrite fails. I've attached it if anyone else wants to use it.
Thanks for the workarounds and confirmations. I've reported the bug to Adobe. Out of curiosity, has anyone tried performance testing the ImageIO method?
Thanks for posting it. Though it is worth mentioning the general recommendation is not to use com.sun.* classes directly because they are part of a "Sun proprietary API and may be removed in a future release".
Here is a quick adaptation of an example on sun.com http://java.sun.com/developer/JDCTechTips/2004/tt0217.html. Though it probably needs to be modified to account for the available quality settings.
Good point re using com.sun.* classes, I've updated the code to use imageIO for jpegs too, as per your adaptation from the sun example (with some very minor changes).
btw, I haven't taken account of the "available" quality settings because having looked at the api reference, it seems that ImageWriteParam.setCompressionQuality() will take any float between 0 and 1. The array of floats returned by getCompressionQualityValues() seems to provide a set of values that can be used as part of a user interface when setting compression quality values, rather than a list of the supported compression quality values.
Yes, you are right about getCompressionQualityValues(). I was rushing to a meeting and did not look closely at that one. After further reading, the api does mention those values can be used for interface options like "Good", "Better", and "Best".
I went to incorporate the two code snippets into a function and noticed something strange. If the ImageWrite fails, it appears to do something "wonky" to the destination file. Even though the subsequent ImageIO code runs without error, the final image file is still locked somehow or left in an unfinished state. Now considering that the original ImageWrite action did fail, perhaps this should make sense to me. But it is not the behavior I was expecting.
If I try and view the final image (with xp's picture viewer), the preview is blank. Try and open the image with another program, I get a sharing violation: "A sharing violation occurred while accessing: <path to saved image file>". However, once I bounce the CF server, the problem goes away. The image can be previewed and opened with another program.
Once I removed ImageWrite from the function entirely, the save works perfectly. So the problem is definitely related to ImageWrite.
Anyway, here is my final function code (without ImageWrite)
You could try messing about with temporary files to work around this - have imageWrite write to a temp file and if it succeeds, move the file to the destination, if it fails, try to delete it (which might fail, but what the hell). As far as I recall, imageCFC does this.
I like the idea of trying CF's imageWrite function first, but that's just because I'm assuming that there is some good reason why adobe chose not to use ImageIO to write the images (performance, support for more jpeg sub-types, I dunno).
Yes, the ideal would be to use ImageWrite. However, there are several issues that appear to be related to ImageWrite, not just this one.
I did try the temp file idea, but the failed image file generated by ImageWrite could not be deleted. Not that surprising considering the "sharing violation" error I received earlier when trying to open the image with another program.
I do not know what ImageWrite uses behind the scenes. Just that there seems to be a difference between the method it uses and the one used here. Due to the fact that there are multiple issues related to ImageWrite, I am sticking with the function above for now. I will replace it with ImageWrite once the issues are resolved.
This patch fixed the problem. Thanks for the quick response.
hans blix wrote:
<i>This patch fixed the problem. Thanks for the quick response.</i>
There are two problems mentioned within this topic, the "Quantization table 0x02 was not defined" error with some jpegs and the file locking issue.
Can anyone confirm that both of these issues are resolved by installing the hot fix? I have three cf8 servers to look after and have to schedule downtime with customers to install a hot fix - I want to be sure it's worth the hassle.
There were a total of four issues, across several different threads:
1. Quantization table 0x02 was not defined (this thread)
2. Image files locked on error (this thread)
3. Missing Huffman code table entry
4. Files get locked by cfimage, can't delete them
So far the updated hotfix (dated 05/07/2008) has fixed all (4) of the issues for me. I noticed hans blix marked all of his threads as answered. So I would guess the hotfix worked for him as well, but confirm it with him.
I've confirmed the fix for all these issues too.
Great news, thanks for responding.
I confirmed too. hf801-71557.zip kb403411 fixed this issue but not the cumulative ColdFusion 8.0.1 cumulative hot fix 1.
Yes the fix works for me!