[
https://issues.apache.org/jira/browse/IMAGING-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396327#comment-17396327
]
Gary Lucas commented on IMAGING-285:
------------------------------------
No. Thanks for bringing it to my attention.
I was vaguely aware that there was some kind of calving process going on in
Commons with regard to all things mathematical, but I didn't realize that
Commons Numbers existed.
The RationalNumbers handling in the TIFF/EXIF formats is pretty narrow and
specialized. So it won't benefit from Commons Numbers, but on quick inspection
there appears to be a lot of interesting things going on: quaternions, gamma
functions. Cool stuff.
> Decoding of Rational Numbers broken when large values present
> -------------------------------------------------------------
>
> Key: IMAGING-285
> URL: https://issues.apache.org/jira/browse/IMAGING-285
> Project: Commons Imaging
> Issue Type: Bug
> Components: imaging.common.*
> Affects Versions: 1.0-alpha2
> Reporter: John Andrade
> Priority: Major
> Attachments: DJI_0267 cropped.JPG
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Decoding Lat/Long EXIF data from JPEGs does not work for some values. I have
> attached a file where the conversion fails. I used the
> getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast methods from the
> TiffImageMetaData.GPSInfo class. The values are close, but seemingly off by
> a few miles.
> I've traced the source and I believe the issue is with how the RationalNumber
> class uses two 32-bit signed integers for the numerator and denominator. The
> definition of a RATIONAL data type uses 32-bit unsigned numbers. It seems as
> if the RationalNumber class already expects this as it has a non-public
> static method called factoryMethod to create a RationalNumber from two 64-bit
> numbers.
> This error is introduced in the ByteConversions class, specifically the
> toRational method where it uses the regular RationalNumber constructor and
> thus ensures any rational numbers that have numerator or denominator greater
> than the max signed 32-bit value will produce invalid values.
> I am attaching a JPEG that has this problem. I had to crop it to reduce the
> size, but the EXIF data was preserved.
> The EXIF GPS data contained in the JPEG is:
> GpsLatitudeRef: "N"
> GpsLatitude: 38, 1, 36, 1, 4120083230, 70000000
> GpsLongitudeRef: "W"
> GpsLongitude: 90, 1, 12, 1, 2379156648, 70000000
> According to the properties of the image (right-clicking on Windows 10), the
> L/L of the image is:
> Latitude: 38: 36: 58.85833....
> Longitude: 90: 12: 33.98795... (Windows doesn't show E/W)
> These values convert to:
> 38.616349536627
> -90.2094410978095
> When I use the getLatitudeAsDegreesNorth and getLongitudeAsDegreesEast
> methods, I get the following values:
> 38.59930601561111
> -90.19239757679365
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
