Apply GPX Track Log doesn't seem to work

[baardman]

I usually sync my GPS data with my photos to add geo information to my photos.

Somehow the syncing results now in 0 matches. I've checked my camera and my GPS again and I can't find any unusual settings. The photos have timestamps that are within the time window the GPS recorded the log.

I live in the Netherlands. That's UTC+1 and the camera is set to Daylight Saving Time, which acts like a UTC+2.

I tested with the 2023.1.10 release

[baardman]

[thrinn]

Try to set the (new) Threshold parameter in the setting to something other than 0/space, eg. 15 seconds.

[baardman]

Thanks for the suggestion. I tried, but it makes no difference.

[Mario]

The default threshold is 300 seconds.
When you change the threshold, the file mapping stats at the bottom update to show how many files are mapped now.

I've just tried with 3 sets of images and 3 track logs, and all worked just fine.


From which version of IMatch did you upgrade to IMatch 2023?
Because when loading the settings, the Map panel checks the version of the settings, adding new data to settings produced by older IMatch versions. IMatch 2023.1 uses settings version 7 and upgrades all older settings version to include the threshold, with a default of 300 seconds.
I wonder why the threshold can be empty for some users...?

Apps silently upgrade settings all the time.
Did you notice anything special?

[baardman]

I upgraded from the latest 2021 version to the 2023 version that was available on 16-06-2023.

I changed the treshold to 300 seconds. Now it could find a few matches, but it's only a small percentage.

I've not noticed anything special the last weeks or with the 2023 version.

[baardman]

I don't know what treshold is exactly supposed to do, but when I change the treshold to 600 I get more hits. Only it positions photos outside the track on places where I have not been.

[Mario]

Please provide your track log file and the images you use and the settings you have made in the track log import settings dialog.
If I can reproduce it here, I can fix it.
You can resize the images to be very small, as long as the embedded metadata remains intact.
ZIP everything and upload to your cloud space (DropBox, OneDrive, Google Drive) and send a public link to support email address, with a link back to this thread.

What the threshold does is explained in the Map Panel help: Track Log Import Settings and Options, point 6.

[Mario]

Thank you for sending me 3 files and a track log.
2 of the files have GPS data, the 3rd file has none.

I select all 3 files, open the Map Panel and import the track log.
IMatch tells me that none of the files could be mapped. My settings are way off, apparently.

I go into the settings and click on the "Automatically match timelines" button.
IMatch calculates an offset of -0.35 hours and all 3 files are matched:



I click on OK and the Map Panel displays the suggested markers along the track:



I apply the suggested coordinates to the files and IMatch sets the GPS coordinates of the files:



I let IMatch reverse-geocode all 3 files and get sensible data from GeoNames.org for all 3 files.

From here, things seem to be working just fine.

[baardman]

Dear Mario,

Thanks for the testing. The results you get are not the places where the photos are taken.

As I wrote, I discovered that my GPS does a kind of smart recording. When it doesn't detect motion it stops recording GPS points. As soon as it detects motion it starts recording again. In the GPX file you can find gaps in the time it records.

I had the GPS mounted on my bike. Parked it and took several shots nearby. Normally  I carry the GPS in my pocket and it always detects motion.

I used a 300 second treshold and it could match all photos made within 300 seconds after I parked my bike. I think that explains why so many photos didn't match; I took photos for at least half an hour when I parked my bike

Img3 however is matched on a location which is not in the GPX file, but was within the 300 seconds threshold. That's the only thing I can't get my head around.

[Mario]

The threshold was introduced by request from users who sometimes have no GPS signal and their device does not record anything. Previously, IMatch assigned the files to the nearest (time-wise) coordinate from the track log. Which could be wrong, when the user took the photo 1 mile away after wandering around for 30 minutes without GPS reception.

The threshold defines the maximum time difference between a track log point and file time. If no track log entry within the time window defined by the threshold exists, the file is not mapped.

All 3 files were mapped, but you say they were mapped to the wrong coordinates.
I cannot tell from visual inspection if this is the case.
I will have to analyze the track log by hand and compare time stamps by hand to see if the map panel is right or not.
This will take some time.

The first file (img2.JPG) has the UTC time stamp 21.06.2023 14:10:22
In the track log, there are 17 entries for 14:06:* and then there is a big jump to 14:41:21.
So, nothing really nearby 14:10. If the threshold is less than about 4 minutes, this file will not be assigned, because the nearest track point is at 14:06:51, 03:09 minutes before.

[baardman]

OK. For me it's clear now why img2 was not assigned. It was beyond the 300 seconds treshold, so IMatch didn't find the nearest coordinate. Next time I have to take this into account.

Leaves img3 and I understand that takes some more time to investigate. There is a hit with the timestamps in the GPX file and consireding the 300 seconds treshold. However a GPS coordinate is assigned beyond the track, on a place where I have not been.

Thanks so far!

[Mario]

We'll see.
Maybe there is an open slot over the weekend. Depends on the weather

[Mario]

I've played with this a bit.

The track log has 5,700 points.
Would you consider this a better result for the 3 files provided?

Code Select Expand

Mapped file [7946] 'img1.JPG' with time stamp 2023-06-21T14:10:22Z to point 475 with time stamp 2023-06-21T13:07:05.000Z, shiftet to 2023-06-21T14:07:05Z, lat: 52.23505865782499, lon: 5.957939922809601.
Mapped file [7947] 'img2.JPG' with time stamp 2023-06-21T14:12:27Z to point 554 with time stamp 2023-06-21T13:09:09.000Z, shiftet to 2023-06-21T14:09:09Z, lat: 52.24081953987479, lon: 5.956104705110192.
Mapped file [7948] 'img3.JPG' with time stamp 2023-06-21T16:28:59Z to point 2750 with time stamp 2023-06-21T15:25:41.000Z, shiftet to 2023-06-21T16:25:41Z, lat: 52.324625328183174, lon: 5.797414658591151.
I think the interpolation of the best matching track point (based on time) and the next point in the track log is the problem in this case. The idea is that when you have a file at 10:05 and a track point at 10:03 and another at 10:07, IMatch picks the first track point but tries to interpolate the "middle" of the two points for a more precise results.
I don't have the math in my head anymore (long time since I've worked on that) and a 3rd party geo math library is involved, too. Need to check how it can produce such outliers.

[Bolitho]

Works here (with my .CR3s) - especially the new "threshold parameter"

There probably is a bug with .jpgs taken in a different timezone than the system/home timezone.
As soon as I have a chance I'll scrutinize further (might be an IMatch 2021 to 2023 migration problem or for whatever reason the timezone of the jpg is not read) and provide more information.

[Mario]

Timestamps in track logs are always in UTC and the Map Panel converts the time stamp it uses for the image into UTC or uses the new IMatch 2023 File.DateTime, which is already in UTC. There are no time zone dependencies.

The shift parameter of the mapping just allows the user to correct different time settings for the camera and GPS tracker. Also time zone offsets, if you will.
The threshold parameter introduced in IMatch 2023 gives the user an option to avoid adding GPS coordinates to files which are to far (too long) away from the next best track point.

[Mario]

I've fixed this for IMatch 2023.1.12.
The problem was indeed the interpolation of the ideal track point. The idea was good, but my math was off a bit.

The 'extreme' time differences between the best track point and the image (several minutes) in the track log used for this example emphasized the wrong calculation, causing the points to be outside the actual track.

[Bolitho]

Yes - found positions are on track now.

But: If the calculated position exceeds the set threshold (e.g. because the threshold is set too narrow) a position far away (even off the track) is applied (should be no position at all).
Apparently introduced with IM 2023.1.12.

[Mario]

Which threshold did you use to create this problem?
As always with bug reports, please specific as much information as possible.

Is this reproducible with the 3 sample files and track log you have sent?
I get correct results even with a 5 second threshold...?

[baardman]

Hoi Mario,

Someone else is replying on the post I made.

I've downloaded IM2023.1.12 and performed the test with the same 3 images. Img 1 en Img 3 I sent you, already had GPS coordinates in them and both being wrong. 

What I did:
- Set the treshold to 5 seconds
- Selected the 3 images
- Loaded the GPX track
- No hits. As expected, because the timestamps of the images are more than 5 seconds of the recorded GPS points.

Next test:
- Unloaded the GPX track
- Set the treshold to 300 seconds
- Selected the 3 images
- Loaded the GPX track
- 2 hits on img1 and img3. Img2 has a timestamp that is more than 300 seconds of the recorded GPS point.
- img1 got the right position, img3 is a bit off

The timestamp of img3 is 18:28:59. The best hit for img3 would be GPS point 3291 with timestamp 18:24:20. GPS point 3292 has timestamp 19:32:09 (much later).
The GPS coordinates that are found by imatch (52.317669, 5,748341) are not in the GPX file. The closest GPS point is 3313, timestamp 19:37:01 with coordinates 52.31765, 5.74837

So the good thing is that img3 is not off track anymore, but I can't explain why imatch places img3 on this GPS point.

[Mario]

@baardman
which time offset to you use?
I used the auto, which produces a +1 hour shift and 3 matches as shown in my post #13 above.

[baardman]

Hi Mario,

I don't know if I understand your question, but I live in the Netherlands. That's UTC+1 and the camera is set to Daylight Saving Time, which acts like a UTC+2.

The timestamps I mentioned in my last post is the timestamp the photos are really made. So that's a UTC+2 (considering daylight saving time).

I tried the following:
- Reset the threshold to 0
- Selected the 3 images
- Loaded the GPX file
- Selected auto
- I get +1 hour shift and no matches

I tried the same with a treshold of 300 seconds. Also +1 hour shift and now I have 3 matches on the wrong place


 

[baardman]

Img 1 and Img 2 are made on the same place.
The places on the map should be something like this:

[Mario]

Reset the threshold to 0 

That's to be expected. To find a match in that case would require a track point at exactly the same time stamp of the file. Almost impossible. For your file, at least ~400 seconds are required.

Img1 is at UTC 21.06.2023 14:10:22
Img2 is at UTC 21.06.2023 14:12:27

The track has several points at around 14:06 and then one at 14:41:21.

[Mario]

Hi,
I've made some changes and now the results look correct.
Please download the attached ZIP file and extract it.

Close IMatch.
Replace the file

c:\ProgramData\photools.com\IMatch6\webroot\imatch\apps\FEATURES\mapapp\track\track.js

with the track.js contained in the ZIP.

Delete the folder "c:ProgramData\photools.com\IMatch6\browser".

Then test the Map Panel again. Thanks!

[baardman]

Hi Mario,

This works! I've also tested it on my other photos and set the threshold much greater and now I get more hits and on the right place.

So I think you've solved the problem. Thanks!

Best regards,
Eric

[Mario]

Very good. Thanks for the feedback.

[novaca]

I also confirm, it works for me. With this change, off-route positions are gone.

[Mario]

Very good. Thanks for testing.
The modification will be shipped to all users as part of the 2023.1.14 release.

[Bolitho]

This version works here too.
Just assigned positions to some thousand images using several logs.

[Mario]

Excellent!