Bug #33210 [Com]: getimagesize() fails to detect width/height on certain JPEGs
Edit report at http://bugs.php.net/bug.php?id=33210edit=1
ID: 33210
Comment by: dnavas at yahoo dot com
Reported by: polone at townnews dot com
Summary: getimagesize() fails to detect width/height on certain
JPEGs
Status: No Feedback
Type: Bug
Package: GetImageSize related
Operating System: RedHat Linux 7.3
PHP Version: 4.3.11
New Comment:
http://buckslocalnews.com/content/articles/2010/02/18/bucks_sports/doc4b6b385a8b4800059886291.jpg
a rises to 401.
I think polone's code and jfif.pdf link is worth another read.
Previous Comments:
[2005-08-06 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-07-29 01:54:25] sni...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-07-27 23:18:21] polone at townnews dot com
This is NOT fixed. Raising the limit to 25 0xFF markers doesn't fix this
issue - it merely fixes certain JPEGs that have less than 25 0xFF
markers, but not all.
[2005-06-02 00:29:29] il...@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.
[2005-06-01 07:54:18] polone at townnews dot com
Description:
The getimagesize() function fails on specific JPEG files. The reason is
that php_next_marker() in:
ext/standard/image.c
has an artificial limit of 10 imposed on the number of 0xFF records that
are found in sequential order. As far as I can tell ... the JPEG file
format standards impose no such limit (see,
http://www.jpeg.org/public/jfif.pdf). The proper behaviour should be to
continue to read for the next marker until:
(1) M_SOS is found, in which case, image data has begun and no more
headers will occur
(2) M_EOI has occurred (End of Image header) - this is the proper
behavior in a properly encoded image
(3) EOF - something's wrong - but, at least it's not getimagesize()
I've provided an example of a JPEG file that will fail using
getimagesize() online at:
http://www.townnews.com/contrib/premature.jpg
A fix is easily added by removing the artificial limit and just
incrementing a in the marker's main loop around line 404:
if (++a 10)
{
/* who knows the maxim amount of 0xff? though 7 */
/* but found other implementations */
return M_EOI;
}
I realize this may be in place to prevent infinite loops, but the
reality is EOF will do that for us anyway. To fix the problem, just
switch that code hunk too:
a++;
Reproduce code:
---
?php
$sURL = http://www.townnews.com/contrib/premature.jpg;;
print_r(getimagesize($sURL));
?
Expected result:
Array
(
[0] = 350
[1] = 603
[2] = 2
[3] = width=350 height=603
[bits] = 8
[channels] = 3
[mime] = image/jpeg
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=33210edit=1
#33210 [Com]: getimagesize() fails to detect width/height on certain JPEGs
ID: 33210
Comment by: nong11yjyygy at yahoo dot com
Reported By: polone at townnews dot com
Status: No Feedback
Bug Type: GetImageSize related
Operating System: RedHat Linux 7.3
PHP Version: 4.3.11
New Comment:
very good
http://www.11nong.com
Previous Comments:
[2005-08-06 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-07-29 01:54:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-07-27 23:18:21] polone at townnews dot com
This is NOT fixed. Raising the limit to 25 0xFF markers doesn't fix
this issue - it merely fixes certain JPEGs that have less than 25 0xFF
markers, but not all.
[2005-06-02 00:29:29] [EMAIL PROTECTED]
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.
[2005-06-01 07:54:18] polone at townnews dot com
Description:
The getimagesize() function fails on specific JPEG files. The reason is
that php_next_marker() in:
ext/standard/image.c
has an artificial limit of 10 imposed on the number of 0xFF records
that are found in sequential order. As far as I can tell ... the JPEG
file format standards impose no such limit (see,
http://www.jpeg.org/public/jfif.pdf). The proper behaviour should be to
continue to read for the next marker until:
(1) M_SOS is found, in which case, image data has begun and no more
headers will occur
(2) M_EOI has occurred (End of Image header) - this is the proper
behavior in a properly encoded image
(3) EOF - something's wrong - but, at least it's not getimagesize()
I've provided an example of a JPEG file that will fail using
getimagesize() online at:
http://www.townnews.com/contrib/premature.jpg
A fix is easily added by removing the artificial limit and just
incrementing a in the marker's main loop around line 404:
if (++a 10)
{
/* who knows the maxim amount of 0xff? though 7 */
/* but found other implementations */
return M_EOI;
}
I realize this may be in place to prevent infinite loops, but the
reality is EOF will do that for us anyway. To fix the problem, just
switch that code hunk too:
a++;
Reproduce code:
---
?php
$sURL = http://www.townnews.com/contrib/premature.jpg;;
print_r(getimagesize($sURL));
?
Expected result:
Array
(
[0] = 350
[1] = 603
[2] = 2
[3] = width=350 height=603
[bits] = 8
[channels] = 3
[mime] = image/jpeg
)
--
Edit this bug report at http://bugs.php.net/?id=33210edit=1
#33210 [Com]: getimagesize() fails to detect width/height on certain JPEGs
ID: 33210
Comment by: web at tiffanymarket dot com
Reported By: polone at townnews dot com
Status: No Feedback
Bug Type: GetImageSize related
Operating System: RedHat Linux 7.3
PHP Version: 4.3.11
New Comment:
Stained Glass, Tiffany Lamp, ornament, Glass Crafts, Chess--More
The stained glass will bring the light into the color feeling, The
stained glass can make the normal products in to the art crafts, The
stained glass can bring the beautiful into elegance, The Stained glass
make the surface of the room, stare, hall, windows, door, and the
furniture, furnishings, ornament, upholster lamp into spiritualism.
Feeling the beautiful multiformity of the stained glass, make our live
into colorful
URL:http://www.glass-products.org
Previous Comments:
[2005-08-06 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-07-29 01:54:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-07-27 23:18:21] polone at townnews dot com
This is NOT fixed. Raising the limit to 25 0xFF markers doesn't fix
this issue - it merely fixes certain JPEGs that have less than 25 0xFF
markers, but not all.
[2005-06-02 00:29:29] [EMAIL PROTECTED]
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.
[2005-06-01 07:54:18] polone at townnews dot com
Description:
The getimagesize() function fails on specific JPEG files. The reason is
that php_next_marker() in:
ext/standard/image.c
has an artificial limit of 10 imposed on the number of 0xFF records
that are found in sequential order. As far as I can tell ... the JPEG
file format standards impose no such limit (see,
http://www.jpeg.org/public/jfif.pdf). The proper behaviour should be to
continue to read for the next marker until:
(1) M_SOS is found, in which case, image data has begun and no more
headers will occur
(2) M_EOI has occurred (End of Image header) - this is the proper
behavior in a properly encoded image
(3) EOF - something's wrong - but, at least it's not getimagesize()
I've provided an example of a JPEG file that will fail using
getimagesize() online at:
http://www.townnews.com/contrib/premature.jpg
A fix is easily added by removing the artificial limit and just
incrementing a in the marker's main loop around line 404:
if (++a 10)
{
/* who knows the maxim amount of 0xff? though 7 */
/* but found other implementations */
return M_EOI;
}
I realize this may be in place to prevent infinite loops, but the
reality is EOF will do that for us anyway. To fix the problem, just
switch that code hunk too:
a++;
Reproduce code:
---
?php
$sURL = http://www.townnews.com/contrib/premature.jpg;;
print_r(getimagesize($sURL));
?
Expected result:
Array
(
[0] = 350
[1] = 603
[2] = 2
[3] = width=350 height=603
[bits] = 8
[channels] = 3
[mime] = image/jpeg
)
--
Edit this bug report at http://bugs.php.net/?id=33210edit=1
