After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 775249 - Problem with Metadata.get_gps_info method
Problem with Metadata.get_gps_info method
Status: RESOLVED FIXED
Product: gexiv2
Classification: Other
Component: bindings
0.10.x
Other Linux
: Normal normal
: ---
Assigned To: Gexiv2 Maintainers
Gexiv2 Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-11-28 15:46 UTC by Ondřej Tůma
Modified: 2017-03-03 20:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test photo file (286.88 KB, image/jpeg)
2016-11-28 15:46 UTC, Ondřej Tůma
  Details
skip gps zero den values (3.21 KB, patch)
2016-11-30 14:46 UTC, Ondřej Tůma
none Details | Review
Thanks. Your patch was fine from a technical POV, but I decided to used the (9.94 KB, patch)
2017-02-24 22:07 UTC, Jens Georg
committed Details | Review

Description Ondřej Tůma 2016-11-28 15:46:00 UTC
Created attachment 340925 [details]
Test photo file

The problem is somewhere in get_gps_info, gexiv2_metadata_get_gps_longitude, gexiv2_metadata_get_gps_latitude, gexiv2_metadata_get_gps_altitude and gir (python wrapping).

When i call get_gps_info() method, i get (longitude=1.508425, latitude=0.0, altitude=0.0), but when i call each get_gps_X method, i got "right" values:

>>> from gi.repository import GExiv2
>>> metadata = GExiv2.Metadata("CaorVN.jpeg")
>>> metadata.get_gps_longitude()
1.508425

>>> metadata.get_gps_latitude()
48.631806166666664

>>> metadata.get_gps_altitude()
-0.926

Values looks right, but longitude could be -1.508425. But how gexiv2_metadata_get_gps_info() function is write and each other gexiv2_metadata_get_gps_X functions are write, it could return value(s), which could not be right.

In fact, exiv2 which use libexiv2, return right longitude.

The attached photo is probably make here: https://en.mapy.cz/zakladni?x=-1.5101523&y=48.6204173&z=13&source=coor&id=-1.5084250166666666%2C48.63180618333333
Comment 1 Ondřej Tůma 2016-11-28 15:53:52 UTC
Ohh, the bug "works" on Linux Debian Stretch with libexiv2-14 (0.25-3), libgexiv2-2 (0.10.4-1), and gir1.2-gexiv2-0.10 (0.10.4-1). But it is the same on Debian Jessie with older versions.
Comment 2 Ondřej Tůma 2016-11-28 16:07:16 UTC
Yes, i see it. The problem is there:

if (den == 0) // https://git.gnome.org/browse/gexiv2/tree/gexiv2/gexiv2-metadata-gps.cpp#n67

This condition is in all gexiv2_metadata_get_gps_X functions. But in data, there is really zero values. And the X_ref multiplier is at the end of functions. So the solution is probably don't test zero values of den, resp. don't do 
division when den is zero.
Comment 3 Ondřej Tůma 2016-11-30 14:46:47 UTC
Created attachment 341058 [details] [review]
skip gps zero den values

Here is a patch to fix the problem in gexiv2_metadata_get_gps_longitude and gexiv2_metadata_get_gps_latitude
Comment 4 Jens Georg 2017-02-24 20:48:46 UTC
Sorry, I missed this somehow. Can I use the attached image in gexiv2 as a regression test?
Comment 5 Ondřej Tůma 2017-02-24 21:40:35 UTC
(In reply to Jens Georg from comment #4)
> Sorry, I missed this somehow. Can I use the attached image in gexiv2 as a
> regression test?

Hi, yes ;)
Comment 6 Jens Georg 2017-02-24 22:07:18 UTC
Created attachment 346675 [details] [review]
Thanks. Your patch was fine from a technical POV, but I decided to used the

chance to clean up and simplify the functions a little bit.

Thank you very much for digging into this. Much appreciated :)

Fix GPS rational calculation

Apparently there are some images where num == den == 0 for the GPS fractions
which caused the code to bail out too early and left a) wrong GPS values and
b) caused get_gps_info to return 0 for all other values after the failing one.

While we're at it, clean up the functions to be a bit more C++-y. Just because
we export a C interface doesn't mean we can't use nice C++ internally.

Signed-off-by: Jens Georg <mail@jensge.org>