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

Blocks
T67681: EXIF support (tracking)
Reference
bz3892
bzimport set Reference to bz3892.
bzimport added a subscriber: Unknown Object (MLST).
daniel created this task.Nov 6 2005, 2:26 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.Nov 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

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

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

matmarex edited the task description. (Show Details)Aug 30 2015, 10:33 PM
matmarex set Security to None.
Restricted Application added subscribers: Steinsplitter, Matanya, Aklapper. · View Herald TranscriptAug 30 2015, 10:33 PM

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

matmarex closed this task as "Resolved".Aug 30 2015, 10:35 PM

Add Comment