[KPhotoAlbum] wrong GPS position

[Reimar Imhof]

Hi,

some photos show wrong gps position in kphotoalbum. But when opening such a
photo in showPhoto every thing is fine (in showPhoto). So the gps position
from the camera is okay.
kphotoalbum shows positions that are wrong by some kilometers. Some photos are
even placed at the north pole (0,0). Other photos are read with right position
info.

This is not related to the latest kphotoalbum but also happened with older
versions. And it's not related to a special kde/qt version.
At the moment it's
openSUSE Leap 15.0,
kphotoalbum 5.3,
kde 5.12.5
kdeapps 17.12.3
qt 5.9.4

When selecting such a photo and choosing maintenance read-exif-info it is okay
(in some cases it needs a second or even third try, but in most cases it's
okay after the first try). While doing so I had the exif info dialog on the
screen and opened it again after the exif-re-read. The gps info shown in that
dialog did not change. But the position in the geo position view or the
annotation dialog was fixed.
I also tried to remove the exif db exif-info.db and rebuild it. No luck.

How can this be fixed?

Cheers
Reimar

[Tobias Leupold]

Hi Reimar!

Thanks for your report. A good starting point would be if you could provide
some photos that will produce the error. I didn't see such an error yet, but I
also don't have a camera putting GPS info into the EXIF data, but geotag my
photos manually.

Cheers, Tobias

Post by Reimar Imhof
Hi,
some photos show wrong gps position in kphotoalbum. But when opening such a
photo in showPhoto every thing is fine (in showPhoto). So the gps position
from the camera is okay.
kphotoalbum shows positions that are wrong by some kilometers. Some photos
are even placed at the north pole (0,0). Other photos are read with right
position info.
This is not related to the latest kphotoalbum but also happened with older
versions. And it's not related to a special kde/qt version.
At the moment it's
openSUSE Leap 15.0,
kphotoalbum 5.3,
kde 5.12.5
kdeapps 17.12.3
qt 5.9.4
When selecting such a photo and choosing maintenance read-exif-info it is
okay (in some cases it needs a second or even third try, but in most cases
it's okay after the first try). While doing so I had the exif info dialog
on the screen and opened it again after the exif-re-read. The gps info
shown in that dialog did not change. But the position in the geo position
view or the annotation dialog was fixed.
I also tried to remove the exif db exif-info.db and rebuild it. No luck.
How can this be fixed?
Cheers
Reimar
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum

[Reimar Imhof]

Hi Tobias,

thanks for your reply.

The problem is: The error is not photo related. It seems it could be any
photo. If you add one photo at a time to the exif db it seems all good. The
more you add at a time the bigger the chance you get wrong gps data. Or if I
select about 10 photos and have the exif info read again there is quite a good
chance that I get correct gps data (well sometimes even 10 is to much). But if
I select a larger number of photos the chance is very big, that I get wrong
positions.
What I've also seen after spending whole evening looking for gps positions:
There are quite a lot of photos that got gps data that is wrong by perhaps not
more then 50 km. There were only very little photos with terrible wrong gps
info (put at the north pole).
So sorry, I can't provide you with a "prolbem photo".

Is this somehow a race condition? Some things working parallel causing
trouble?

Cheers,
Reimar

Post by Tobias Leupold
Hi Reimar!
Thanks for your report. A good starting point would be if you could provide
some photos that will produce the error. I didn't see such an error yet, but
I also don't have a camera putting GPS info into the EXIF data, but geotag
my photos manually.
Cheers, Tobias

Post by Reimar Imhof
Hi,
some photos show wrong gps position in kphotoalbum. But when opening such a
photo in showPhoto every thing is fine (in showPhoto). So the gps position
from the camera is okay.
kphotoalbum shows positions that are wrong by some kilometers. Some photos
are even placed at the north pole (0,0). Other photos are read with right
position info.
This is not related to the latest kphotoalbum but also happened with older
versions. And it's not related to a special kde/qt version.
At the moment it's
openSUSE Leap 15.0,
kphotoalbum 5.3,
kde 5.12.5
kdeapps 17.12.3
qt 5.9.4
When selecting such a photo and choosing maintenance read-exif-info it is
okay (in some cases it needs a second or even third try, but in most cases
it's okay after the first try). While doing so I had the exif info dialog
on the screen and opened it again after the exif-re-read. The gps info
shown in that dialog did not change. But the position in the geo position
view or the annotation dialog was fixed.
I also tried to remove the exif db exif-info.db and rebuild it. No luck.
How can this be fixed?
Cheers
Reimar
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum

_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum

[Robert Krawitz]

Post by Reimar Imhof
Hi Tobias,
thanks for your reply.
The problem is: The error is not photo related. It seems it could be
any photo. If you add one photo at a time to the exif db it seems
all good. The more you add at a time the bigger the chance you get
wrong gps data. Or if I select about 10 photos and have the exif
info read again there is quite a good chance that I get correct gps
data (well sometimes even 10 is to much). But if I select a larger
number of photos the chance is very big, that I get wrong positions.
What I've also seen after spending whole evening looking for gps
positions: There are quite a lot of photos that got gps data that is
wrong by perhaps not more then 50 km. There were only very little
photos with terrible wrong gps info (put at the north pole). So
sorry, I can't provide you with a "prolbem photo".
Is this somehow a race condition? Some things working parallel
causing trouble?

It doesn't look likely given the code, but I couldn't rule it out.
Does this reproduce with KPA 5.3? If not, can you bisect to the
change at which it does happen?

Given that the behavior sounds like it's nondeterministic, it's just
possible that my performance changes did this. In which case I'll
need a set of photos that exhibits this behavior, even
non-deterministically.

[Tobias Leupold]

Hi all,

until now, I couldn't reproduce this. It also sounds odd that some
positions seem to be off by a few kilometers ... we don't calculate
anything, but only feed the map widget with the very GPS coordinates given
by the images (and stored in the EXIF DB since Johannes implemented this).

I'll further try to reproduce it ...

Tobias

Post by Robert Krawitz

Post by Reimar Imhof
Hi Tobias,
thanks for your reply.
The problem is: The error is not photo related. It seems it could be
any photo. If you add one photo at a time to the exif db it seems
all good. The more you add at a time the bigger the chance you get ...

It doesn't look likely given the code, but I couldn't rule it out.
Does this reproduce with KPA 5.3? If not, can you bisect to the
change at which it does happen?
Given that the behavior sounds like it's nondeterministic, it's just
possible that my performance changes did this. In which case I'll
need a set of photos that exhibits this behavior, even
non-deterministically.

[Johannes Zarl-Zierl]

Hi,

So what we're currently doing is the following:

1. Parse GPS data from Exif
2. Store the parsed data in exifdb
3. Use the data

The Exif-Info dialog directly shows the Exif data from the file, not the
cached fields from the exifdb. The exifdb only stores a subset of exif data
that we actually use in KPA.

From the problem description, I'd say that parsing the data works fine (and I

don't see any source of non-determinism there). I assume that the problem
persists across KPA runs if you don't recreate the exifdb, so we can rule out
step 3 as well.

Which leaves us with the storage part. The non-determinism in your problem
description also shouts "concurrent writes", so my guess would be that several
threads read exif information and try to store in in the database
concurrently. This should not be a problem for the underlying database, but I
guess you can always introduce bugs in a higher layer.

I'll see if I can spot a problem...

Btw. did you also try the current version from git (the one including Robert's
performance changes)?

As an additional pointer, could you maybe find an image in the "north pole"
category that you described and send me both the correct and the incorrect
values?

You can query the exifdb as follows:

sqlite3 exif-info.db "select
Exif_GPSInfo_GPSVersionID,Exif_GPSInfo_GPSAltitude,Exif_GPSInfo_GPSAltitudeRef,Exif_GPSInfo_GPSMeasureMode,Exif_GPSInfo_GPSDOP,Exif_GPSInfo_GPSImgDirection,Exif_GPSInfo_GPSLatitude,Exif_GPSInfo_GPSLatitudeRef,Exif_GPSInfo_GPSLongitude,Exif_GPSInfo_GPSLongitudeRef,Exif_GPSInfo_GPSTimeStamp
from exif where filename = '/path/to/DSC_1234.jpg';"

Maybe there's some pointer in the way the information gets garbled...

As an additional side-note: there's also the bug mentioned by Georgios/gsv000,
but this would affect files at step 1., so it shouldn't be at play here...

Cheers,
Johannes

[Johannes Zarl-Zierl]

Post by Johannes Zarl-Zierl
Which leaves us with the storage part. The non-determinism in your problem
description also shouts "concurrent writes", so my guess would be that
several threads read exif information and try to store in in the database
concurrently. This should not be a problem for the underlying database, but
I guess you can always introduce bugs in a higher layer.

Contradicting myself, I'm even more unsure how this can happen. You said you
get the same problem if you recreate the exif database. In that path of
execution, everything happens sequentially. So I guess my first hunch was
incorrect...

Johannes

[Reimar Imhof]

Hi Johannes,

it's fixed with the fix provided by Georgios:

// hour / minute / second:
for (int i=0 ; i < 4 ; i++ )

to

// hour / minute / second:
for (int i=0 ; i < 3 ; i++ )

in DatabaseElement.cpp

Thanks a lot
Reimar

Post by Johannes Zarl-Zierl

Post by Johannes Zarl-Zierl
Which leaves us with the storage part. The non-determinism in your problem
description also shouts "concurrent writes", so my guess would be that
several threads read exif information and try to store in in the database
concurrently. This should not be a problem for the underlying database, but
I guess you can always introduce bugs in a higher layer.

Contradicting myself, I'm even more unsure how this can happen. You said you
get the same problem if you recreate the exif database. In that path of
execution, everything happens sequentially. So I guess my first hunch was
incorrect...
Johannes
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum

[Johannes Zarl-Zierl]

Hi Reimar,

Thanks for the feedback!

Cheers,
Johannes

Post by Reimar Imhof
Hi Johannes,
for (int i=0 ; i < 4 ; i++ )
to
for (int i=0 ; i < 3 ; i++ )
in DatabaseElement.cpp
Thanks a lot
Reimar

Post by Johannes Zarl-Zierl

Post by Johannes Zarl-Zierl
Which leaves us with the storage part. The non-determinism in your problem
description also shouts "concurrent writes", so my guess would be that
several threads read exif information and try to store in in the database
concurrently. This should not be a problem for the underlying database, but
I guess you can always introduce bugs in a higher layer.

Contradicting myself, I'm even more unsure how this can happen. You said
you get the same problem if you recreate the exif database. In that path
of execution, everything happens sequentially. So I guess my first hunch
was incorrect...
Johannes
_______________________________________________
KPhotoAlbum mailing list
https://mail.kdab.com/mailman/listinfo/kphotoalbum

[Robert Krawitz]

Anybody object if I push this little cleanup while we're at it?

diff --git a/Exif/DatabaseElement.cpp b/Exif/DatabaseElement.cpp
index 2a0a871c..b1c10077 100644
--- a/Exif/DatabaseElement.cpp
+++ b/Exif/DatabaseElement.cpp
@@ -137,14 +137,12 @@ QVariant Exif::RationalExifElement::valueFromExif(Exiv2::ExifData &data) const
{
value = 0.0;
double divisor = 1.0;
- // hour / minute / second:
+ // degree / minute / second:
for (int i=0 ; i < 3 ; i++ )
{
double nom = tagDatum.toRational(i).first;
double denom = tagDatum.toRational(i).second;
- if ( denom == 0 )
- value += 0;
- else
+ if ( denom != 0 )
value += (nom / denom)/ divisor;
divisor *= 60.0;
}

[Johannes Zarl-Zierl]

Post by Robert Krawitz
Anybody object if I push this little cleanup while we're at it?

No objections from me ;-)

Thanks for cleaning this up!
Johannes