EXIF data shown incorrectly for fractional values
OpenPublic

Description

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

  • 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.


Version: 1.17.x
Severity: normal
URL: http://commons.wikimedia.org/wiki/Image:BumpassHell_8328.jpg

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz3892.
daniel created this task.Via LegacyNov 6 2005, 2:26 PM
bzimport added a comment.Via ConduitNov 6 2005, 4:46 PM

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

brion added a comment.Via ConduitNov 9 2005, 10:11 PM

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: exif-data.txt

daniel added a comment.Via ConduitNov 9 2005, 10:44 PM

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.

brion added a comment.Via ConduitNov 9 2005, 10:50 PM

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

daniel added a comment.Via ConduitNov 9 2005, 11:43 PM

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...

brion added a comment.Via ConduitMay 26 2009, 9:25 PM

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:

Gilles added a project: Multimedia.Via WebNov 24 2014, 3:29 PM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.