Ask a Question related to PHP Bugs, Design and Development.
-
me+php at drbeat dot li #1
#39617 [NEW]: Erroneously uses the GPS version tag to determine byte order of GPS fields
From: me+php at drbeat dot li
Operating system: Debian unstable (sid)
PHP version: 4.4.4
PHP Bug Type: EXIF related
Bug description: Erroneously uses the GPS version tag to determine byte order of GPS fields
Description:
------------
When reading GPS EXIF tags, PHP seems to use the GPS version tag to
determine the byte order of the other GPS tags instead of the byte order
indicator from the EXIF header. An image that shows the incorrect behavior
is at [url]http://www.drbeat.li/test/testgps.jpg[/url] .
In this picture, the GPS tag version is stored as the bytes [0, 0, 2, 2]
instead of as [2, 2, 0, 0]. exif_read_data() consequently returns wrong
fractions for latitude, longitude and altitude.
Reproduce code:
---------------
if (($exif = @exif_read_data($file, 0, true)) !== false && $exif['GPS'])
print_r($exif['GPS']);
Expected result:
----------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 47/1
[1] => 8/1
[2] => 96/25
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 7/1
[1] => 13/1
[2] => 60801/1250
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 436/1
)
Actual result:
--------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 196608/3276800
[1] => 65536/2004877312
[2] => 57999413/-1526726656
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 38666275/3080192
[1] => 65536/524288
[2] => 65536/6291456
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 1638400/458752
)
--
Edit bug report at [url]http://bugs.php.net/?id=39617&edit=1[/url]
--
Try a CVS snapshot (PHP 4.4): [url]http://bugs.php.net/fix.php?id=39617&r=trysnapshot44[/url]
Try a CVS snapshot (PHP 5.2): [url]http://bugs.php.net/fix.php?id=39617&r=trysnapshot52[/url]
Try a CVS snapshot (PHP 6.0): [url]http://bugs.php.net/fix.php?id=39617&r=trysnapshot60[/url]
Fixed in CVS: [url]http://bugs.php.net/fix.php?id=39617&r=fixedcvs[/url]
Fixed in release: [url]http://bugs.php.net/fix.php?id=39617&r=alreadyfixed[/url]
Need backtrace: [url]http://bugs.php.net/fix.php?id=39617&r=needtrace[/url]
Need Reproduce Script: [url]http://bugs.php.net/fix.php?id=39617&r=needscript[/url]
Try newer version: [url]http://bugs.php.net/fix.php?id=39617&r=oldversion[/url]
Not developer issue: [url]http://bugs.php.net/fix.php?id=39617&r=support[/url]
Expected behavior: [url]http://bugs.php.net/fix.php?id=39617&r=notwrong[/url]
Not enough info: [url]http://bugs.php.net/fix.php?id=39617&r=notenoughinfo[/url]
Submitted twice: [url]http://bugs.php.net/fix.php?id=39617&r=submittedtwice[/url]
register_globals: [url]http://bugs.php.net/fix.php?id=39617&r=globals[/url]
PHP 3 support discontinued: [url]http://bugs.php.net/fix.php?id=39617&r=php3[/url]
Daylight Savings: [url]http://bugs.php.net/fix.php?id=39617&r=dst[/url]
IIS Stability: [url]http://bugs.php.net/fix.php?id=39617&r=isapi[/url]
Install GNU Sed: [url]http://bugs.php.net/fix.php?id=39617&r=gnused[/url]
Floating point limitations: [url]http://bugs.php.net/fix.php?id=39617&r=float[/url]
No Zend Extensions: [url]http://bugs.php.net/fix.php?id=39617&r=nozend[/url]
MySQL Configuration Error: [url]http://bugs.php.net/fix.php?id=39617&r=mysqlcfg[/url]
me+php at drbeat dot li Guest
-
Byte Order Mark
If I use encoding UTF-8 for PHP code, Dreamweaver interprets all sequences <? or <? like Byte Order Mark. I can to change any HTML headers so,... -
TIFF BYTE ORDER
With all this info on how to save an image so everyone on both platforms can read it, I have a question. I have tried saving an image as... -
#25558 [Asn->Csd]: Dbase Version Check added in 4.3.3 detecting bad version when using memo fields
ID: 25558 Updated by: vlad@php.net Reported By: dsherron at nbc dot edu -Status: Assigned +Status: ... -
Perl DBI and Informix BYTE fields
Has anyone worked with Informix (IDS 7.31.4, if that makes any difference) BYTE fields (which can store binary data) and Perl DBI? I've set up a... -
#25558 [Asn]: Dbase Version Check added in 4.3.3 detecting bad version when using memo fields
ID: 25558 Updated by: vlad@php.net Reported By: dsherron at nbc dot edu Status: Assigned Bug Type: ... -
tony2001@php.net #2
#39617 [Opn->Asn]: Erroneously uses the GPS version tag to determine byte order of GPS fields
ID: 39617
Updated by: [email]tony2001@php.net[/email]
Reported By: me+php at drbeat dot li
-Status: Open
+Status: Assigned
Bug Type: EXIF related
Operating System: Debian unstable (sid)
PHP Version: 4.4.4
-Assigned To:
+Assigned To: helly
Previous Comments:
------------------------------------------------------------------------
[2006-11-24 13:19:02] me+php at drbeat dot li
Description:
------------
When reading GPS EXIF tags, PHP seems to use the GPS version tag to
determine the byte order of the other GPS tags instead of the byte
order indicator from the EXIF header. An image that shows the incorrect
behavior is at [url]http://www.drbeat.li/test/testgps.jpg[/url] .
In this picture, the GPS tag version is stored as the bytes [0, 0, 2,
2] instead of as [2, 2, 0, 0]. exif_read_data() consequently returns
wrong fractions for latitude, longitude and altitude.
Reproduce code:
---------------
if (($exif = @exif_read_data($file, 0, true)) !== false &&
$exif['GPS'])
print_r($exif['GPS']);
Expected result:
----------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 47/1
[1] => 8/1
[2] => 96/25
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 7/1
[1] => 13/1
[2] => 60801/1250
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 436/1
)
Actual result:
--------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 196608/3276800
[1] => 65536/2004877312
[2] => 57999413/-1526726656
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 38666275/3080192
[1] => 65536/524288
[2] => 65536/6291456
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 1638400/458752
)
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=39617&edit=1[/url]
tony2001@php.net Guest
-
me+php at drbeat dot li #3
#39617 [Asn]: Erroneously uses the GPS version tag to determine byte order of GPS fields
ID: 39617
User updated by: me+php at drbeat dot li
Reported By: me+php at drbeat dot li
Status: Assigned
Bug Type: EXIF related
Operating System: Debian unstable (sid)
PHP Version: 4.4.4
Assigned To: helly
New Comment:
BTW, this image was resized in Apple's iPhoto.
Previous Comments:
------------------------------------------------------------------------
[2006-11-24 13:19:02] me+php at drbeat dot li
Description:
------------
When reading GPS EXIF tags, PHP seems to use the GPS version tag to
determine the byte order of the other GPS tags instead of the byte
order indicator from the EXIF header. An image that shows the incorrect
behavior is at [url]http://www.drbeat.li/test/testgps.jpg[/url] .
In this picture, the GPS tag version is stored as the bytes [0, 0, 2,
2] instead of as [2, 2, 0, 0]. exif_read_data() consequently returns
wrong fractions for latitude, longitude and altitude.
Reproduce code:
---------------
if (($exif = @exif_read_data($file, 0, true)) !== false &&
$exif['GPS'])
print_r($exif['GPS']);
Expected result:
----------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 47/1
[1] => 8/1
[2] => 96/25
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 7/1
[1] => 13/1
[2] => 60801/1250
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 436/1
)
Actual result:
--------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 196608/3276800
[1] => 65536/2004877312
[2] => 57999413/-1526726656
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 38666275/3080192
[1] => 65536/524288
[2] => 65536/6291456
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 1638400/458752
)
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=39617&edit=1[/url]
me+php at drbeat dot li Guest
-
helly@php.net #4
#39617 [Asn->Fbk]: Erroneously uses the GPS version tag to determine byte order of GPS fields
ID: 39617
Updated by: [email]helly@php.net[/email]
Reported By: me+php at drbeat dot li
-Status: Assigned
+Status: Feedback
Bug Type: EXIF related
Operating System: Debian unstable (sid)
PHP Version: 4.4.4
Assigned To: helly
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
[url]http://bugs.php.net/how-to-report.php[/url]
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Your file is not available, please provide it.
Previous Comments:
------------------------------------------------------------------------
[2006-11-24 16:16:43] me+php at drbeat dot li
BTW, this image was resized in Apple's iPhoto.
------------------------------------------------------------------------
[2006-11-24 13:19:02] me+php at drbeat dot li
Description:
------------
When reading GPS EXIF tags, PHP seems to use the GPS version tag to
determine the byte order of the other GPS tags instead of the byte
order indicator from the EXIF header. An image that shows the incorrect
behavior is at [url]http://www.drbeat.li/test/testgps.jpg[/url] .
In this picture, the GPS tag version is stored as the bytes [0, 0, 2,
2] instead of as [2, 2, 0, 0]. exif_read_data() consequently returns
wrong fractions for latitude, longitude and altitude.
Reproduce code:
---------------
if (($exif = @exif_read_data($file, 0, true)) !== false &&
$exif['GPS'])
print_r($exif['GPS']);
Expected result:
----------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 47/1
[1] => 8/1
[2] => 96/25
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 7/1
[1] => 13/1
[2] => 60801/1250
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 436/1
)
Actual result:
--------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 196608/3276800
[1] => 65536/2004877312
[2] => 57999413/-1526726656
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 38666275/3080192
[1] => 65536/524288
[2] => 65536/6291456
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 1638400/458752
)
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=39617&edit=1[/url]
helly@php.net Guest
-
helly@php.net #5
#39617 [Fbk]: Erroneously uses the GPS version tag to determine byte order of GPS fields
ID: 39617
Updated by: [email]helly@php.net[/email]
Reported By: me+php at drbeat dot li
Status: Feedback
Bug Type: EXIF related
-Operating System: Debian unstable (sid)
+Operating System: *
-PHP Version: 4.4.4
+PHP Version: 4.4.4, 5.2.0
Assigned To: helly
New Comment:
[url]http://www.exif.org/Exif2-2.PDF[/url]
A. Tags Relating to GPS
GPSVersionID
Indicates the version of GPSInfoIFD. The version is given as 2.2.0.0.
This tag is mandatory when GPSInfo tag is
present. Note that the GPSVersionID tag is written as a different byte
than the Exif Version tag.
Tag = 0 (0.H)
Type = BYTE
Count = 4
Default = 2.2.0.0
2.2.0.0 = Version 2.2
Other = reserved
======================================
That is your GPS IFD is corrupted. No matter what the byte order is -
the version is always stored in the same order.
To analyze whether t he whole data is corrupted or there is still an
error in ext/exif i would need the image.
Previous Comments:
------------------------------------------------------------------------
[2006-11-25 15:20:31] [email]helly@php.net[/email]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
[url]http://bugs.php.net/how-to-report.php[/url]
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Your file is not available, please provide it.
------------------------------------------------------------------------
[2006-11-24 16:16:43] me+php at drbeat dot li
BTW, this image was resized in Apple's iPhoto.
------------------------------------------------------------------------
[2006-11-24 13:19:02] me+php at drbeat dot li
Description:
------------
When reading GPS EXIF tags, PHP seems to use the GPS version tag to
determine the byte order of the other GPS tags instead of the byte
order indicator from the EXIF header. An image that shows the incorrect
behavior is at [url]http://www.drbeat.li/test/testgps.jpg[/url] .
In this picture, the GPS tag version is stored as the bytes [0, 0, 2,
2] instead of as [2, 2, 0, 0]. exif_read_data() consequently returns
wrong fractions for latitude, longitude and altitude.
Reproduce code:
---------------
if (($exif = @exif_read_data($file, 0, true)) !== false &&
$exif['GPS'])
print_r($exif['GPS']);
Expected result:
----------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 47/1
[1] => 8/1
[2] => 96/25
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 7/1
[1] => 13/1
[2] => 60801/1250
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 436/1
)
Actual result:
--------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 196608/3276800
[1] => 65536/2004877312
[2] => 57999413/-1526726656
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 38666275/3080192
[1] => 65536/524288
[2] => 65536/6291456
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 1638400/458752
)
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=39617&edit=1[/url]
helly@php.net Guest
-
me+php at drbeat dot li #6
#39617 [Fbk->Opn]: Erroneously uses the GPS version tag to determine byte order of GPS fields
ID: 39617
User updated by: me+php at drbeat dot li
Reported By: me+php at drbeat dot li
-Status: Feedback
+Status: Open
Bug Type: EXIF related
Operating System: *
PHP Version: 4.4.4, 5.2.0
Assigned To: helly
New Comment:
Sorry, wrong link :-(
The picture is at [url]http://www.drbeat.li/test/images/testgps.jpg[/url]
Additionally, a correct image is at
[url]http://www.drbeat.li/test/images/testgps2.jpg[/url]
Previous Comments:
------------------------------------------------------------------------
[2006-11-25 15:34:50] [email]helly@php.net[/email]
[url]http://www.exif.org/Exif2-2.PDF[/url]
A. Tags Relating to GPS
GPSVersionID
Indicates the version of GPSInfoIFD. The version is given as 2.2.0.0.
This tag is mandatory when GPSInfo tag is
present. Note that the GPSVersionID tag is written as a different byte
than the Exif Version tag.
Tag = 0 (0.H)
Type = BYTE
Count = 4
Default = 2.2.0.0
2.2.0.0 = Version 2.2
Other = reserved
======================================
That is your GPS IFD is corrupted. No matter what the byte order is -
the version is always stored in the same order.
To analyze whether t he whole data is corrupted or there is still an
error in ext/exif i would need the image.
------------------------------------------------------------------------
[2006-11-25 15:20:31] [email]helly@php.net[/email]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
[url]http://bugs.php.net/how-to-report.php[/url]
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Your file is not available, please provide it.
------------------------------------------------------------------------
[2006-11-24 16:16:43] me+php at drbeat dot li
BTW, this image was resized in Apple's iPhoto.
------------------------------------------------------------------------
[2006-11-24 13:19:02] me+php at drbeat dot li
Description:
------------
When reading GPS EXIF tags, PHP seems to use the GPS version tag to
determine the byte order of the other GPS tags instead of the byte
order indicator from the EXIF header. An image that shows the incorrect
behavior is at [url]http://www.drbeat.li/test/testgps.jpg[/url] .
In this picture, the GPS tag version is stored as the bytes [0, 0, 2,
2] instead of as [2, 2, 0, 0]. exif_read_data() consequently returns
wrong fractions for latitude, longitude and altitude.
Reproduce code:
---------------
if (($exif = @exif_read_data($file, 0, true)) !== false &&
$exif['GPS'])
print_r($exif['GPS']);
Expected result:
----------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 47/1
[1] => 8/1
[2] => 96/25
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 7/1
[1] => 13/1
[2] => 60801/1250
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 436/1
)
Actual result:
--------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 196608/3276800
[1] => 65536/2004877312
[2] => 57999413/-1526726656
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 38666275/3080192
[1] => 65536/524288
[2] => 65536/6291456
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 1638400/458752
)
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=39617&edit=1[/url]
me+php at drbeat dot li Guest
-
tony2001@php.net #7
#39617 [Opn->Asn]: Erroneously uses the GPS version tag to determine byte order of GPS fields
ID: 39617
Updated by: [email]tony2001@php.net[/email]
Reported By: me+php at drbeat dot li
-Status: Open
+Status: Assigned
Bug Type: EXIF related
Operating System: *
PHP Version: 4.4.4, 5.2.0
Assigned To: helly
Previous Comments:
------------------------------------------------------------------------
[2006-11-25 19:26:34] me+php at drbeat dot li
Sorry, wrong link :-(
The picture is at [url]http://www.drbeat.li/test/images/testgps.jpg[/url]
Additionally, a correct image is at
[url]http://www.drbeat.li/test/images/testgps2.jpg[/url]
------------------------------------------------------------------------
[2006-11-25 15:34:50] [email]helly@php.net[/email]
[url]http://www.exif.org/Exif2-2.PDF[/url]
A. Tags Relating to GPS
GPSVersionID
Indicates the version of GPSInfoIFD. The version is given as 2.2.0.0.
This tag is mandatory when GPSInfo tag is
present. Note that the GPSVersionID tag is written as a different byte
than the Exif Version tag.
Tag = 0 (0.H)
Type = BYTE
Count = 4
Default = 2.2.0.0
2.2.0.0 = Version 2.2
Other = reserved
======================================
That is your GPS IFD is corrupted. No matter what the byte order is -
the version is always stored in the same order.
To analyze whether t he whole data is corrupted or there is still an
error in ext/exif i would need the image.
------------------------------------------------------------------------
[2006-11-25 15:20:31] [email]helly@php.net[/email]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
[url]http://bugs.php.net/how-to-report.php[/url]
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Your file is not available, please provide it.
------------------------------------------------------------------------
[2006-11-24 16:16:43] me+php at drbeat dot li
BTW, this image was resized in Apple's iPhoto.
------------------------------------------------------------------------
[2006-11-24 13:19:02] me+php at drbeat dot li
Description:
------------
When reading GPS EXIF tags, PHP seems to use the GPS version tag to
determine the byte order of the other GPS tags instead of the byte
order indicator from the EXIF header. An image that shows the incorrect
behavior is at [url]http://www.drbeat.li/test/testgps.jpg[/url] .
In this picture, the GPS tag version is stored as the bytes [0, 0, 2,
2] instead of as [2, 2, 0, 0]. exif_read_data() consequently returns
wrong fractions for latitude, longitude and altitude.
Reproduce code:
---------------
if (($exif = @exif_read_data($file, 0, true)) !== false &&
$exif['GPS'])
print_r($exif['GPS']);
Expected result:
----------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 47/1
[1] => 8/1
[2] => 96/25
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 7/1
[1] => 13/1
[2] => 60801/1250
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 436/1
)
Actual result:
--------------
Array
(
[GPSVersion] => ????
[GPSLatitudeRef] => N
[GPSLatitude] => Array
(
[0] => 196608/3276800
[1] => 65536/2004877312
[2] => 57999413/-1526726656
)
[GPSLongitudeRef] => E
[GPSLongitude] => Array
(
[0] => 38666275/3080192
[1] => 65536/524288
[2] => 65536/6291456
)
[GPSAltitudeRef] => ?
[GPSAltitude] => 1638400/458752
)
------------------------------------------------------------------------
--
Edit this bug report at [url]http://bugs.php.net/?id=39617&edit=1[/url]
tony2001@php.net Guest



Reply With Quote

