Legacy ImageMagick Discussions Archive

(I reported this issue before through the "contact the wizards" feature a few months ago, but it isn't fully solved yet and I found this forum now and also have some new information)

Hello,

ImageMagick 6.6.3-7 2010-08-14 Q16 (I know this is not the latest version, see my other bug report of today) can't handle a grey old JPEG file. The file is here:

http://www.megafileupload.com/en/file/2 ... n-TIF.html

After a few warnings because it is an old JPEG file, there is this error:

Magick: Improper call to JPEG library in state 0. `LibJpeg' @ error/tiff.c/TIFFErrors/494.

I did compile libtiff (which I believe you are using) including the IJG lib at home yesterday and tiffcp works fine, i.e.

tiffcp -c jpeg termin.tif huhu.tif

produces a proper "new JPEG" tiff file.

Thus, the libtiff can do it, but ImageMagick can't.... I used version 3.9.4.

Funny thing is that ImageMagick has no problem handling a color "old JPEG" tiff, although both file types are similar: the actual JPEG starts at 0x300, according to the JPEGInterChangeFormat tag. (I can cut off 0x300 bytes with a hex editor and save it, and poof!, its a jpeg file )

Tilman Hausherr

The error comes from libTIFF. There is a configuration option that permits old-style JPEG images when you build libTIFF. Apparently the option is not enabled in the WIndows distribution of ImageMagick. We get the same exception on our Linux system:

• -> display termin.tif
  display: termin.tif: unknown field with tag 33000 (0x80e8) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/704.
  display: Depreciated and troublesome old-style JPEG compression mode, please convert to new-style JPEG compression and notify vendor of writing software. `OJPEGSetupDecode' @ warning/tiff.c/TIFFWarnings/704.
  display: Improper call to JPEG library in state 0. `LibJpeg' @ error/tiff.c/TIFFErrors/494.

magick wrote:The error comes from libTIFF. There is a configuration option that permits old-style JPEG images when you build libTIFF. Apparently the option is not enabled in the WIndows distribution of ImageMagick.

No, this isn't so. Because ImageMagick can handle color old-style JPEG images. Here's one:
http://www.megafileupload.com/en/file/2 ... G-TIF.html

I have no problem with convert.exe, and only a warning with IMDisplay (then it's displayed).

The error message from the IJG lib suggests that a call is made at the wrong moment. I'd suspect there is a moment where bitonal and color Old JPEG images are handled differently.

Tilman Hausherr

The exception is thrown by libTIFF, not ImageMagick. We call libTIFF and ask for image pixels and it comes back and say you're not getting any because there is "an Improper call to JPEG library in state 0.". We'll investigate and see if we can get libTIFF to return the pixels even with the exception.

magick wrote:The exception is thrown by libTIFF, not ImageMagick. We call libTIFF and ask for image pixels and it comes back and say you're not getting any because there is "an Improper call to JPEG library in state 0.". We'll investigate and see if we can get libTIFF to return the pixels even with the exception.

Thank you...

In the meantime I downloaded the sources to at least have a quick look. You're using libtiff 3.9.2, which is a year old. Maybe they (or the IJG people) fixed something since then...?

Tilman Hausherr

We fixed the problem you reported in ImageMagick 6.6.4-3 Beta available by sometime tomorrow. We make a different libTIFF call for old-style JPEG images and it handles the exception properly.

magick wrote:We fixed the problem you reported in ImageMagick 6.6.4-3 Beta available by sometime tomorrow. We make a different libTIFF call for old-style JPEG images and it handles the exception properly.

Yes, the bug is fixed in the 6.6.4-3 beta version (static build). Thanks!

I am trying to load an Old JPEG TIFF file on windows with ImageMagick 6.8.6-6 but I am receiving the 'Improper call to JPEG library' message. This issue was fixed in revision 2612 but it seems the change was reverted in revision 6859. Adding the following line from revision 2612 seems to fix my problem.
I could not figure out from the ChangeLog why this change was reverted and I am hoping the fix can be reintroduced.