Page MenuHomePhabricator

EXIF data shown incorrectly for fractional values
Closed, ResolvedPublic

Description

The values for EXIF fields that are given as fractions are computed incorrectly.
Some examples for BumpassHell_8328.jpg:

  • F Number: shown as 0.979034803375, should be 7.2; given as 72/10 according to jhead.
  • Shutter speed: shown as 0.97903487118, should be 9.65625; given as 309/32 according to jhead.
  • Aperture: shown as 0.914085909977, should be 5.71875; given as 183/32 according to jhead.

Interrestingly, the first two wrong values are the same for seven digits after
the decimal point (0.9790348), but different after that. The last one is also
relatively close, but not that close.

Details

Reference
bz3892

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 8:53 PM
bzimport set Reference to bz3892.
bzimport added a subscriber: Unknown Object (MLST).

siegmund wrote:

Also, the field "Date and time of data generation" is displayed as "15:41, 6 November 2005", i.e.,
apparently the current date and time. I think it should be "2005.10.25 12:56:28". That is when I
took the image. See dump of BumpassHell_8328.jpg below.

The image was processed on an iBook (OS10.3) using GraphicConverter 5.7.1. If there is a bug in
GraphicConverter, it would be helpful to have a short description so that I can submit a bug
report (http://www.lemkesoft.com).

0000000 377 330 377 340 \0 020 J F I F \0 001 001 001 \0 264
0000020 \0 264 \0 \0 377 341 036 f E x i f \0 \0 I I
0000040 * \0 6 034 \0 \0 C a n o n \0 C a n o
0000060 n P o w e r S h o t S 1 1 0
0000100 \0 264 \0 \0 \0 001 \0 \0 \0 264 \0 \0 \0 001 \0 \0
0000120 \0 2 0 0 5 : 1 0 : 2 5 1 2 : 5
0000140 6 : 2 8 \0 001 \0 \0 \0 003 \0 \0 H \0 \0
0000160 \0 \n \0 \0 \0 2 0 0 5 : 1 0 : 2 5
0000200 1 2 : 5 6 : 2 8 \0 2 0 0 5 : 1 0
0000220 : 2 5 1 2 : 5 6 : 2 8 \0 003 \0 \0

Created attachment 1054
var_dump() of array read from the file via exif_read_data()

The data as read from exif_read_data() is consistent with the output, eg:

["XResolution"]=>
string(21) "1124073500/1852796513"

(Tried with PHP 5.0.2, 5.0.5, and 5.1.0RC4)

Attached:

so, this is another PHP bug, i assume?

Hm... may this be byte order related? JPEG itself uses Motorola byte order,
afaik, but I don't know about the EXIF data contained.

Not too sure, but I did get the same results running the function on
my Mac as on my PC.

When I try extracting EXIF data from that image using PHP 4.3.8 (cgi) (built:
Jul 16 2004 08:32:27), I get a bunch of errors, and all the fields that return
garbage on the commons do not appear in the resulting array at all. Here are a
few of the errors i get:

Warning:  exif_read_data(BumpassHell_8328.jpg): process tag(x829D=FNumber

): Illegal pointer offset(x004F < x826252A)

Warning:  exif_read_data(BumpassHell_8328.jpg): process

tag(x9201=ShutterSpee): Illegal pointer offset(x0087 < x8262572)

Warning:  exif_read_data(BumpassHell_8328.jpg): process

tag(x9202=ApertureVal): Illegal pointer offset(x008F < x826257E)

Warning:  exif_read_data(BumpassHell_8328.jpg): process

tag(x9003=DateTimeOri): Illegal pointer offset(x0057 < x8262542)

Apperently, PHP chokes on this file really bad...

Created attachment 6156
Attaching linked image to make sure it doesn't disappear. :)

Just attaching the image for reference. Bug still visible on Commons.

Attached:

BumpassHell_8328.jpg (600×800 px, 241 KB)

matmarex set Security to None.

Ten years later: the values seen on Commons are correct. Must have been fixed at some point.