``JPEG datastream contains no image'' huh?
Greg Stark
For no apparent reason i seem to be getting the error
``JPEG datastream contains no image'' whenever i try to display a
specific JPEG from java while connected via modem. This problem does
not occur when connected via ethernet, nor does any browser have any
problem displaying the JPEG itself when given the URL directly. The
problem only arises when trying to display it from java.
My current theory is that either the java routines or iis is timing
out and closing the connection. But i can't see any reason for this
particular image to cause such problems.
the entire exception is as follows:
sun.awt.image.ImageFormatException: JPEG datastream contains no image
at sun.awt.image.JPEGImageDecoder.produceImage(Compiled Code)
at sun.awt.image.InputStreamImageSource.doFetch(Compiled Code)
at sun.awt.image.ImageFetcher.run(Compiled Code)
Robert Lynch
I have been dealing with this problem successfully for some time. First
one of my clients reported it, then others. There is something in the
way such images are created; I think it is too high a "quality factor",
one person attributed it to something to do with interlace, etc. So far
there seems to be no consensus on the exact source of the problem.
However, I can _fix_ it by using the image manipulation software "xv",
opening the offending .jpg then simply re-saving it with default
settings (in particular, a quality factor of Q=75).
Here is an example I recently picked up at a problem site:
[user@ravel c104]$ l hands*
-rw-rw-r-- 1 user user 10865 Jul 18 21:47 hands.jpg
-rw-rw-r-- 1 user user 16916 Jul 18 21:46 hands.jpg.orig
the original "hands.jpg.orig" causes the problem you cite:
--------------
[user@ravel c104]$ appletviewer m.html
Premature end of JPEG file
sun.awt.image.ImageFormatException: JPEG datastream contains no image
at
sun.awt.image.JPEGImageDecoder.produceImage(JPEGImageDecoder.java:133)
at
sun.awt.image.InputStreamImageSource.doFetch(InputStreamImageSource.java:215)
at sun.awt.image.ImageFetcher.run(ImageFetcher.java:98)
-------------
whereas the re-saved hands.jpg works just fine... Note the much larger
size of the .orig file, suggestive of a higher quality factor...
If you have problems testing this theory, put an offending .jpg on a
download site, let me know, and I will send it back to you, fixed!
FWIW.
Bob L.
--
Robert Lynch-Berkeley CA USA-r...@best.com
http://www.best.com/~rmlynch/
--
Thornton Prime
Greg Stark wrote in article ...
>
>For no apparent reason i seem to be getting the error
>``JPEG datastream contains no image'' whenever i try to display a
>specific JPEG from java while connected via modem. This problem does
>not occur when connected via ethernet, nor does any browser have any
>problem displaying the JPEG itself when given the URL directly. The
>problem only arises when trying to display it from java.
>
>My current theory is that either the java routines or iis is timing
>out and closing the connection. But i can't see any reason for this
>particular image to cause such problems.
>
>the entire exception is as follows:
>sun.awt.image.ImageFormatException: JPEG datastream contains no image
> at sun.awt.image.JPEGImageDecoder.produceImage(Compiled Code)
> at sun.awt.image.InputStreamImageSource.doFetch(Compiled Code)
> at sun.awt.image.ImageFetcher.run(Compiled Code)
Check and make sure you are getting the correct MIME type headers from the
HTTP stream when connecting using the modem. Maybe some proxy or firewall is
mangnlig (mangling) the HTTP headers?
Thornton
Tom Lane
Greg Stark <st...@generation.net> writes:
> For no apparent reason i seem to be getting the error
> ``JPEG datastream contains no image'' whenever i try to display a
> specific JPEG from java while connected via modem.
Did that JPEG originate from Photoshop, by any chance?
There's a known bug in early releases of the JDK which can cause the
above failure when reading a JPEG across a slow connection. The
failure only occurs if the JPEG contains a large application data
block (APPn marker) --- the problem is that the JPEG decoder is trying
to skip over the APPn and failing if not all of the APPn has been
received yet. The quoted error message is only one of several
possible complaints, but they all stem from the same root.
Photoshop is the most common source of JPEGs containing oversize
APPn blocks. In particular, if you allow Photoshop 4 to save a
thumbnail (preview) in a JPEG, the thumbnail plumps up Photoshop's
private APPn marker to several K, which is usually enough to cause
this problem.
So, several possible workarounds:
1. Get a newer JDK --- I'm told this problem is fixed in 1.1.
(If you are putting images up on the Web, this isn't much of a
solution, because you can't assume visitors to your site have
an up-to-date Java installation.)
2. When making JPEGs for Web use from Photoshop, make sure you
have turned off the "save thumbnails" preference. (This is a
good idea quite aside from bug workarounds, because the thumbnail
is just a waste of download time as far as a Web browser is
concerned.) You might still have a problem if you've got verbose
comments or lots of paths being saved into the file, but 99% of
the time, getting rid of the thumbnail will make Photoshop's APPn
small enough to not trigger the Java bug.
3. Use a tool such as 'jpegtran' (from the IJG distribution)
to strip out the Photoshop APPn entirely without any loss of
image quality. Recommended answer for the compulsive byte-trimmer.
4. (Last resort) Load and resave the image in a different image
editor that won't insert any APPn or other overhead data. This
implies a JPEG generational loss, so I don't recommend it if you
are picky about image quality.
Another respondent suggested approach #4 with a deliberate reduction
of JPEG quality setting, but I've seen no evidence that quality setting
has anything to do with this problem. Stripping the overhead data
is what makes the difference.
> The problem only arises when trying to display it from java.
I believe some other applications besides Java have comparable bugs.
Try it in Wang Imaging, which comes free with Windows 95/NT (and
is worth every penny you paid for it :-().
regards, tom lane
organizer, Independent JPEG Group
Jason Day
We had the same problem whenever we used Photoshop Version 4 to create or edit
JPEGs. We fixed the problem by opening the JPEG in Photoshop version 3 and
resaving it.
In article <wku3hon...@generation.net>, Greg Stark <st...@generation.net>
wrote:
>
>For no apparent reason i seem to be getting the error
>``JPEG datastream contains no image'' whenever i try to display a
>specific JPEG from java while connected via modem. This problem does
>not occur when connected via ethernet, nor does any browser have any
>problem displaying the JPEG itself when given the URL directly. The
>problem only arises when trying to display it from java.
>
>My current theory is that either the java routines or iis is timing
>out and closing the connection. But i can't see any reason for this
>particular image to cause such problems.
>
>the entire exception is as follows:
>sun.awt.image.ImageFormatException: JPEG datastream contains no image
> at sun.awt.image.JPEGImageDecoder.produceImage(Compiled Code)
> at sun.awt.image.InputStreamImageSource.doFetch(Compiled Code)
> at sun.awt.image.ImageFetcher.run(Compiled Code)
>
Jason Logan Day jday "at" ixl "dot" com
The sender of any unsolicited email sent to this address agrees to pay
$500/email for proofreading services.
Robert Lynch
Jason Day wrote:
[about a post about ``JPEG datastream contains no image'']
> We had the same problem whenever we used Photoshop Version 4 to create or edit
> JPEGs. We fixed the problem by opening the JPEG in Photoshop version 3 and
> resaving it.
I think another very good solution was offered by Tom Lane of the
Independent JPEG Group: just run stuff through the utility "jpegtran"
(exists on Unix and DOS platforms), a lossless transformation (image
quality wise). Not only does the problem disappear, but the resulting
.jpgs are smaller, thus faster download times.