Bug #29609 for Image-ExifTool: unexpected -EXIF:ApertureValue from jpeg

Tue Sep 25 19:14:58 2007 tuzen [...] hotmail.com - Ticket created

Subject:	unexpected -EXIF:ApertureValue from jpeg
Date:	Tue, 25 Sep 2007 16:14:20 -0700
To:	<bug-Image-ExifTool [...] rt.cpan.org>
From:	"Brian Williams" <tuzen [...] hotmail.com>

Download s_aperture.jpg
image/jpeg 35.1k

Message body is not shown because sender requested not to inline it.

I have one file, attached is an example, that returns a strange value for ApertureValue. However, I checked inside the file using -htmlDump and it value appears ok. This photo was taken without a regular lens; I believe this will happen with a field-scope, telescope, or perhaps even a lens-baby. Thanks! -Brian Show quoted text

>exiftool.exe -EXIF:ApertureValue s_aperture.jpg

returns: Aperture Value : 1.$ expected: Aperture Value : f/0

Wed Sep 26 08:00:09 2007 EXIFTOOL [...] cpan.org - Correspondence added

From:

EXIFTOOL [...] cpan.org

Thanks for the bug report and the sample image. In your sample, the raw ApertureValue has a value of 2147483648 in both the EXIF and XMP information. This is clearly incorrect. The value is represented as unsigned in EXIF and positive in XMP, but in fact it should be signed and therefore -2147483648 instead of 2147483648. This is because the conversion from the APEX ApertureValue is done by the formula 2 ** (VALUE / 2). (where "**" is exponentiation) 2 ** (2147483648 / 2) is effectively infinity, while 2 ** (-2147483648 / 2) is close to zero. For this image, exiftool reports "inf" for both Exif:ApertureValue and XMP:ApertureValue on Linux and Mac OS X systems. The difference in Windows is presumably a difference in the way Perl handles a floating point overflow because it is Perl that returns the "inf" (but I don't have access to a PC at the moment, so I can't test this out). I suppose I could add explicit tests for large values like this, but these types of math calculations occur in many places and in my view adding all the required checks would unnecessarily slow down the processing. In this case, I believe the main fault is in the software wrote this incorrect value, not in exiftool.

Wed Sep 26 08:01:26 2007 The RT System itself - Status changed from 'new' to 'open'

Wed Sep 26 21:13:08 2007 tuzen [...] hotmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #29609] unexpected -EXIF:ApertureValue from jpeg
Date:	Wed, 26 Sep 2007 18:11:59 -0700
To:	<bug-Image-ExifTool [...] rt.cpan.org>
From:	"Brian Williams" <tuzen [...] hotmail.com>

Thank you for looking at this one. I believe -2147483648 is a magic number; it is the smallest int ($MinInt). ...so could perhaps this is the only value to check for? I don't think the EXIF is incorrect in the file. I understand that many non-CPU lenses do something like this. I believe this f/0 came out of the camera, and so I suspect any SLR without an "official" lens will do this. As you say, the XMP is likely incorrect, but I don't know who wrote it. I'm only going after that exif:ApertureValue. But I did read the XMP value on my PC just now and I got that same "1.$". Thanks! -Brian Show quoted text

----- Original Message ----- From: "Phil Harvey via RT" <bug-Image-ExifTool@rt.cpan.org> To: <tuzen@hotmail.com> Sent: Wednesday, September 26, 2007 5:01 AM Subject: [rt.cpan.org #29609] unexpected -EXIF:ApertureValue from jpeg

> > <URL: http://rt.cpan.org/Ticket/Display.html?id=29609 > > > Thanks for the bug report and the sample image. > > In your sample, the raw ApertureValue has a value of 2147483648 in both > the EXIF and XMP > information. This is clearly incorrect. The value is represented as > unsigned in EXIF and > positive in XMP, but in fact it should be signed and therefore -2147483648 > instead of > 2147483648. This is because the conversion from the APEX ApertureValue is > done by the > formula 2 ** (VALUE / 2). (where "**" is exponentiation) > > 2 ** (2147483648 / 2) is effectively infinity, while 2 ** (-2147483648 / > 2) is close to zero. > > For this image, exiftool reports "inf" for both Exif:ApertureValue and > XMP:ApertureValue on > Linux and Mac OS X systems. The difference in Windows is presumably a > difference in the > way Perl handles a floating point overflow because it is Perl that returns > the "inf" (but I don't > have access to a PC at the moment, so I can't test this out). I suppose I > could add explicit > tests for large values like this, but these types of math calculations > occur in many places and > in my view adding all the required checks would unnecessarily slow down > the processing. > > In this case, I believe the main fault is in the software wrote this > incorrect value, not in > exiftool. > >

Thu Sep 27 07:23:44 2007 EXIFTOOL [...] cpan.org - Correspondence added

From:

EXIFTOOL [...] cpan.org

I think you misunderstood. If the number stored in the EXIF was -2147483648 (0x8000 as an unsigned value), then we would have no problem, because this would convert to f/0 using the APEX formula. But it is a signed integer, so the value is 2147483648, which can not be correct because it leads to a near infinite F number. | | 9) ApertureValue = 2147484000 | | - Tag 0x9202 (8 bytes, rational64u[1]): | | 12dc: 80 00 00 00 00 00 00 01 [........]

Thu Sep 27 07:27:33 2007 EXIFTOOL [...] cpan.org - Correspondence added

Sorry, I'm not helping matters here by reversing "signed" and "unsigned" in my last reply. I meant to say this: If the number stored in the EXIF was -2147483648 (0x8000 as a SIGNED value), then we would have no problem, because this would convert to f/0 using the APEX formula. But it is an UNSIGNED integer, so the value is 2147483648, which can not be correct.

Thu Sep 27 12:59:19 2007 EXIFTOOL [...] cpan.org - Correspondence added

From:

EXIFTOOL [...] cpan.org

The bottom line is that if I fixed this for the Windows platform, the value displayed would be "inf" as it is on Linux and OS X, which is still not what you want. (The EXIF documentation makes no reference to any special ApertureValue used to represent f/ 0, so it can only be interpreted according to the standard formula.)

Thu Sep 27 18:05:22 2007 tuzen [...] usermail.com - Correspondence added

Subject:	RE: [rt.cpan.org #29609] unexpected -EXIF:ApertureValue from jpeg
Date:	Thu, 27 Sep 2007 15:04:43 -0700
To:	<bug-image-exiftool [...] rt.cpan.org>
From:	Brian Williams <tuzen [...] hotmail.com>

Thanks for getting me up to speed on that. I did not realize the exif:Aperture was supposed to be URATIONAL. I've always seen f/0 in various applications and assumed they were doing the right thing. I have never seen f/inf, but I suppose that is technically ok. But since Adobe displayed f/0, perhaps everybody followed? Perhaps inf is better than 1.$ Thanks, -Brian Show quoted text

> Subject: [rt.cpan.org #29609] unexpected -EXIF:ApertureValue from jpeg > From: bug-Image-ExifTool@rt.cpan.org> To: tuzen@hotmail.com> Date: Thu, 27 Sep 2007 12:59:23 -0400> > > <URL: http://rt.cpan.org/Ticket/Display.html?id=29609 >> > The bottom line is that if I fixed this for the Windows platform, the value displayed would be > "inf" as it is on Linux and OS X, which is still not what you want.> > (The EXIF documentation makes no reference to any special ApertureValue used to represent f/> 0, so it can only be interpreted according to the standard formula.)>

Fri Sep 28 07:26:36 2007 EXIFTOOL [...] cpan.org - Correspondence added

From:

EXIFTOOL [...] cpan.org

Hi Brian, I really doubt that any Adobe product displays this correctly. Are you sure you aren't looking at the value of FNumber, which is also stored in this file? Using Adobe Photoshop 7.0, the displayed value of ApertureValue for this file is "2147483648.0". On Thu Sep 27 18:05:22 2007, tuzen@usermail.com wrote: Show quoted text

> > Thanks for getting me up to speed on that. I did not realize the > exif:Aperture was supposed to be URATIONAL. I've always seen f/0 > in various applications and assumed they were doing the right > thing. I have never seen f/inf, but I suppose that is technically > ok. But since Adobe displayed f/0, perhaps everybody followed? > > Perhaps inf is better than 1.$ > > Thanks, > -Brian > >

> > Subject: [rt.cpan.org #29609] unexpected -EXIF:ApertureValue from

> jpeg > From: bug-Image-ExifTool@rt.cpan.org> To: tuzen@hotmail.com> > Date: Thu, 27 Sep 2007 12:59:23 -0400> > > <URL: > http://rt.cpan.org/Ticket/Display.html?id=29609 >> > The bottom > line is that if I fixed this for the Windows platform, the value > displayed would be > "inf" as it is on Linux and OS X, which is > still not what you want.> > (The EXIF documentation makes no > reference to any special ApertureValue used to represent f/> 0, so > it can only be interpreted according to the standard formula.)>

Tue Oct 30 08:10:30 2007 EXIFTOOL [...] cpan.org - Correspondence added

From:

EXIFTOOL [...] cpan.org

OK. Just to close this bug out, I'm going to reject it as an exiftool bug. The problem is really in this version of ActivePerl, which is printing "1.$" instead of "inf" (as other Perl versions do) for an infinite value in a sprintf() statement. Also, the ApertureValue is invalid, and should be written as a large NEGATIVE number for an Aperture of 1.0, in which case exiftool would print 1.0 as expected.

Tue Oct 30 08:11:11 2007 EXIFTOOL [...] cpan.org - TimeWorked changed from (no value) to '15'

Tue Oct 30 08:11:12 2007 EXIFTOOL [...] cpan.org - Status changed from 'open' to 'rejected'

Tue Oct 30 08:14:29 2007 EXIFTOOL [...] cpan.org - Correspondence added

On Tue Oct 30 08:10:30 2007, EXIFTOOL wrote: Show quoted text

> Also, the ApertureValue is invalid, and should be written > as a large NEGATIVE number for an Aperture of 1.0, in which > case exiftool would print 1.0 as expected.

Sorry. I meant an aperture of 0.0.

Tue Oct 30 08:14:32 2007 The RT System itself - Status changed from 'rejected' to 'open'

Tue Oct 30 08:14:52 2007 EXIFTOOL [...] cpan.org - Status changed from 'open' to 'rejected'

Tue Oct 30 10:36:16 2007 tuzen [...] hotmail.com - Correspondence added

Subject:	Re: [rt.cpan.org #29609] unexpected -EXIF:ApertureValue from jpeg
Date:	Tue, 30 Oct 2007 07:35:40 -0700
To:	<bug-Image-ExifTool [...] rt.cpan.org>
From:	"Brian Williams" <tuzen [...] hotmail.com>

Ok. Thanks for looking at this. -Brian -------------------------------------------------- From: "Phil Harvey via RT" <bug-Image-ExifTool@rt.cpan.org> Sent: Tuesday, October 30, 2007 5:10 AM To: <tuzen@hotmail.com> Subject: [rt.cpan.org #29609] unexpected -EXIF:ApertureValue from jpeg Show quoted text

> > <URL: http://rt.cpan.org/Ticket/Display.html?id=29609 > > > OK. Just to close this bug out, I'm going to reject it as > an exiftool bug. The problem is really in this version of > ActivePerl, which is printing "1.$" instead of "inf" (as other > Perl versions do) for an infinite value in a sprintf() statement. > > Also, the ApertureValue is invalid, and should be written > as a large NEGATIVE number for an Aperture of 1.0, in which > case exiftool would print 1.0 as expected. > >

Tue Oct 30 10:36:33 2007 The RT System itself - Status changed from 'rejected' to 'open'

Tue Oct 30 11:10:46 2007 EXIFTOOL [...] cpan.org - Status changed from 'open' to 'rejected'