点滴之间 聚沙成金

A simple or “baseline” JPEG file is stored as one top-to-bottom scan of the image. Progressive JPEG divides the file into a series of scans. The first scan shows the image at the equivalent of a very low quality setting, and therefore it takes very little space. Following scans gradually improve the quality. Each scan adds to the data already provided, so that the total storage requirement is roughly the same as for a baseline JPEG image of the same quality as the final scan. (Basically, progressive JPEG is just a rearrangement of the same data into a more complicated order.) The advantage of progressive JPEG is that if an image is being viewed on-the-fly as it is transmitted, one can see an approximation to the whole image very quickly, with gradual improvement of quality as one waits longer; this is much nicer than a slow top-to-bottom display of the image. The disadvantage is that each scan takes about the same amount of computation to display as a whole baseline JPEG file would. So progressive JPEG only makes sense if one has a decoder that’s fast compared to the communication link. (If the data arrives quickly, a progressive-JPEG decoder can adapt by skipping some display passes. Hence, those of you fortunate enough to have T1 or faster net links may not see any difference between progressive and regular JPEG; but on a modem-speed link, progressive JPEG is great.) Up until recently, there weren’t many applications in which progressive JPEG looked attractive, so it hasn’t been widely implemented. But with the popularity of World Wide Web browsers running over slow modem links, and with the ever-increasing horsepower of personal computers, progressive JPEG has become a win for WWW use. IJG’s free JPEG software (see part 2, item 15) now supports progressive JPEG, and the capability is spreading fast in WWW browsers and other programs. Except for the ability to provide progressive display, progressive JPEG and baseline JPEG are basically identical, and they work well on the same kinds of images. It is possible to convert between baseline and progressive representations of an image without any quality loss. (But specialized software is needed to do this; conversion by decompressing and recompressing is *not* lossless, due to roundoff errors.) A progressive JPEG file is not readable at all by a baseline-only JPEG decoder, so existing software will have to be upgraded before progressive JPEG can be used widely. See item 16 in part 2 for the latest news about which programs support it.

Read more: http://www.faqs.org/faqs/jpeg-faq/part1/section-11.html#ixzz0mOIMcVY4

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

Your jpeg file is not valid. PHP could not take care of each possible failures in image files. Desktop softwares could. Fix your image and replace it.

--Pierre

[2004-09-30 17:05 UTC] paul at gslip dot com

I disagree. I have used my code successfully on montypics.com until the upgrade to php 5.0.1. I now get exactly the same results as the original poster.
Images that worked fine on previous versions now do not. I have a sample image that can be provided. I also have code I can share with the PHP team although I cannot post it here as it is lengthy and copyrighted.

[2004-10-05 00:34 UTC] cyleriggs at kc dot rr dot com

After playing around with the images themselves i have found that converting them from jpeg to png then back to jpeg fixed the problem and yielded no quality loss. I used the linux tool set called ImageMagick to do this. I wrote a short perl script to go through all my images and fix them. Other than this i have found no other way of stopping this. one interesting fact though is that while converting the images with the imagemagick utility it complained about some corruptions, however it was still able to open them fine and convert them. Maybe PHP is being too picky about the images that it opens as despite a few corrupted bytes EVERYthing was able to open these images except for PHP.

[2004-10-05 05:33 UTC] derick@php.net

PHP only reads non-coprrupted files - there is no bug here.

[2004-10-06 23:18 UTC] cyleriggs at kc dot rr dot com

Okay, so how about a feature suggestion than, i think that there should be the option in GD that allows you to try and open images that have a few corrupted bytes. If other programs can open them just fine what would be the harm in allowing programmers to choose to live with the corruptions?

[2004-10-07 05:12 UTC] derick@php.net

Corrupted files are invalid, and may crash an application if attempted to use. That's why we will not implement that. (Actually, it's not a PHP issue either, it has to do with how libgd handles opening files).

[2004-10-12 13:23 UTC] paul at gslip dot com

Has anyone at php verified that the images are corrupt? In what way are they corrupt?
Here's what I know:
1- These images were supported with no issues whatsoever before I 'upgraded' to php 5.x

2- Every other piece of software I own, including Windows Image Viewer, Photoshop, Paint, IE, Netscape, Imagemagick, etc. open the files with no complaint.

3- A visual inspection of the files on the byte level show nothing out of the ordinary.

That all leads me to believe that the images are not corrupt and that PHP or GD has a bug.

Please, stop being so stubborn and at least look at the problem. I can show you hundreds of examples of where this is happening on the web. Just do a google search for 'is not a valid JPEG file in' to see for yourselves how many sites are having this issue.

I suspect there's some new twist on the JPEG format that new digital cameras are using ,or something along those lines, that GD and PHP just aren't yet up to speed with.

Let's get this solved folks.

[2006-02-05 15:09 UTC] pajoye@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

Thank you for the report, and for helping us make PHP better.

You can now allow the jpeg decoder to be more tolerant/weak:

error_reporting(E_ALL);
// 0 is the current behavior
ini_set('gd.jpeg_ignore_warning', 1);
$im = imagecreatefromjpeg($file);

Php 5.1.3+ will contain the fix.