search

darktable-org / darktable

darktable is an open source photography workflow application and raw developer
https://www.darktable.org
GNU General Public License v3.0
9.76k stars 1.14k forks source link

geotagging by gpx file: set coordinates through interpolation #9950

Closed paolobenve closed 3 years ago

paolobenve commented 3 years ago

It looks like darktable, when geotagging images through a gpx file, assigns latitude/longitude choosing one of the points in the gpx file.

I wish it were not choosing one of the point, but interpolating between the last of the previous (temporarily) points and the first of the following ones.

Use case 1 ======

Last month I flyed across the Atlantic Ocean, and took some photo in the middle of the Ocean. I had begun recording the gpx with OSMAnd before leaving in order to geotag the photos. Unfortunatly, the airplane isn’t transparent to gpx satellite signals, so my gpx file only took the points before entering and after exitibg the aircraft.

As darktable works currently, through that gpx file I get the photo geotagged at the airports of departure and arrival.

Use case 2

The app that generates the gpx file is set to record a point every minute, but the user moves a certain space every minute and shoots various photos, so the photos would remain stuck at the points where the gpx fixed the coordinates

kmilos commented 3 years ago

FWIW, could leverage the proj library for this (minimal C implementation needed of the full GeographicLib), as it seems to be widely available.

Python example: https://stackoverflow.com/questions/38451828/how-to-iterate-between-two-geo-locations-with-a-certain-speed-in-python3

HansBull commented 3 years ago

Maybe you could apply your gpx file directly to the rawfiles with exiftool. The documentation at https://exiftool.org/geotag.html states: The GPS track log file is loaded, and linear interpolation is used to determine the GPS position at the time of the image

kmilos commented 3 years ago

Linear interpolation doesn't work that well for "use case 1", but is an ok approximation and this is indeed a very neat way of addressing "use case 2".

phweyland commented 3 years ago

On the principle I don't disagree with the suggested change but I don't find the 2 use cases motivating.

  1. if GPS doesn't work one should not rely on it. In any case the position is inaccurate.
  2. Set GPS points every minute doesn't seem appropriate. Usually you can constrain the distance too to avoid the lack of accuracy, or at least set a period more compatible with the speed.
paolobenve commented 3 years ago

The gpx track has to be drawn by geodesic interpolation, too

phweyland commented 3 years ago

The gpx track has to be drawn by geodesic interpolation, too

Why ? What is the benefit ?

paolobenve commented 3 years ago

The gpx track has to be drawn by geodesic interpolation, too

Why ? What is the benefit ?

In order to address the first use case.

paolobenve commented 3 years ago

Here is the difference:

  1. without this PR: the three images are set at the beginning of the line, which is straight: non-geodesic-non-interpolation

  2. with this PR: the images are set at there position according to timestamp, and the line is the geodesic one geodesic

phweyland commented 3 years ago

Looks great. Why do we have a small straight segment on Madrid side ?

paolobenve commented 3 years ago

Because the track has 4 points, the big interval in between the 2nd and the 3rd