[
https://issues.apache.org/jira/browse/IMAGING-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396661#comment-17396661
]
Gary Lucas commented on IMAGING-285:
------------------------------------
> Is there some particular feature that would prevent that the latter [Commons
>Numbers] be a replacement for the former [existing code]?
It's not that at all. I looked at Commons Numbers, and there's a lot to like
about it. I really hope you see widespread adoption. In the case of Commons
Imaging, I think that the issue is one of project dependencies.
I caveat this with saying that I am not in charge of Commons Imaging, so I
don't speak for the project. But I am reluctant to add any new dependencies to
what should be just a single component API for developers to drop into to their
applications. Also, Imaging's RationalNumber class is small enough that there
isn't a strong motivation to depend on an external project even though that
project would be almost certainly be more carefully written and maintained than
the single, specialized class in Commons Imaging.
Interestingly, the TIFF standard does not specify the arithmetic to be used for
rational numbers. It calls for specifying real numbers using two unsigned
32-bit integers. Let's call them a and b. So the meaning of the computed
floating point value (double)a/(double)b is pretty unambiguous. But the
Commons Imaging RationalNumber class also has a method that returns the integer
value a/b. The TIFF standard doesn't say anything about round-off. But maybe
(a+b/2)/b might have been a better solution? I personally think so, but I am
not about to mess with the way the code has always worked. At the same time, I
have to say that one clear advantage of Commons Numbers is that It would "fill
in the blanks" where there were gaps in the specification. Since Numbers
specializes in things that Imaging merely uses, I'm sure you guys have worked
through the details on operations like that.
> 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)
