Am Mittwoch, 7. September 2016, 06:37:35 CEST schrieb Matthias Noack: > Hi all,
Hi. > I've just started using Darktable after a few tries in the past, this > time with reading the manual. ;-) Great software, but not too intuitive > to dive into. > > I tried to geotag my images from a longer bike travel, by using GPX > files. After some tries with the time offset, and reading the manual > again, I figured out that the time offset applies to the image and not > to the GPX data, and that there is the possibility to select a camera > time zone when loading the GPX file, that wasn't too intuitive to grasp. > The rationale behind this probably is, that the camera's time zone is > not a constant and changes with the track, but I never change my > camera's time to local when travelling - do you? The problem is that (most? all?) cameras don't store any time zone data in the images. So unless you tell darktable there is no sound way of matching image's time stamps with the UTC data in the GPX file. [...] > Apart from that, here's two bugs and one feature request (Darktable > 2.0.5 Ubuntu (wiley) PPA), which I have appended to the end of this Mail. We'd prefer to have them in our bug tracker so they won't get forgotten. Especially since you raise some valid points there. > Cheers, > Matthias Tobias > P.S. I would have loved to use the GitHub issue tracker. Probably not > your process, but it's so much easier and more inviting to have an > effort-less way, i.e. no project-only subscription/registration or > whatever, to provide feedback. Alternatively, just a b...@darktable.org > would have been nice. Well, we had our own bug tracker already before we moved to GitHub. And hosting things like that ourselves makes sure that we can move away once they pull a Sourceforge and turn evil without losing anything. > ---------------------------------------- > > # Bug 1: > > Symptom: Once geotagging was used with a wrong offset/timezone, falsely > tagged images, that weren't actually within the time range of the GPX > track, never get rid of their wrong geotag. (NOTE: I would not expect to > remove Darktable-added geotags automatically when a GPX track is applied > again, as many collections might require to apply a set of GPX tracks.) > > Actual problem: The history stack does not include added geotags, or The history stack is only for image editing modules that were applied in darkroom. All those workflow things like tags, ratings, color labels and geotagging don't belong there. > added time offsets from the geotagging menu of the lighttable view. This > includes "load sidecar file" and "write sidecar file" from the history > stack menu, as well as the detection feature for modified sidecar files > (activated in the core options). Seems like the general load/store > mechanism just ignores the geotagging entries when reading a sidecar > while (they are written, though). No, these should be read and work for me. You have to remove the image from dt and import again to force reading the xmp file. Or enable the crawler in the options (something about looking for changed sidecars on startup) and then edit the xmp. On next start you can tell dt to re-read the xmp. > In consequence, even with manually editing the sidecar files, I found no > way to get rid of a geotag added with Darktables within Darktables. There is only one way (and I would like to see more/better alternatives): in map mode you can drag them back from the map to the filmstrip. :-/ > Proposed solution: > a) include geotags into the history stack (might be annoying with > copy&paste?) As said above, that should already be the case. > (Maybe related: What is the difference between "copy" and "copy all", > manual doesn't really help: > https://www.darktable.org/usermanual/ch02s03s07.html.php) "copy" opens a window where you can select that modules to add to the clipboard while "copy all" skips the window and adds everything. > b) add buttons for "remove time offset" and "remove geotag", to be able > to delete these Darktable-added properties within Darktable somehow. Triaged. > ---------------------------------------- > > # Bug 2: > > lighttable -> history stack -> "load sidecar file" -> open dialogue > should remember last path Triaged. > # Feature Request > > Add two checkboxes to the geotagging module: > [ ] use first GPX location for images taken before track start > [ ] use last GPX location for images taken after track start Iff you mean "after track _end_" then: Triaged. > The rationale for the first one are tours where you use your bike/hiking > GPS for a multi-day tour, and usually arrive somewhere, make some > pictures around camp, and continue the next day. Even if not precise, > it'll be roughly the image location and a good starting point for the > map module. > > Maybe also add: > [ ] interpolate location between GPX locations Triaged. > Rationale: Some GPS devices have an (auto) stop feature when you are not > moving or pause while on a ferry or something. This leads to rather > large gaps between entries in the GPX file. In case you are on a ferry, > boat, plane or whatever, a linear interpolation of the location > according to where the image time is between the two GPX entries' times > would be a good approximate location. > > And finally: > [ ] do not override camera geotag Not sure about that. Why do you load a GPX file in the first place if you don't want to overwrite the data? And to be honest, that would be quite hard to implement as dt doesn't have a concept of source for these metadata. Once it's in the database it's just there without knowing where it came from. Original file? GPX file? Added via drag&drop on map? Added by a Lua script? … > Rationale: Some pictures might already have a geotag from a camera, in > some cases it might be better to use an external GPS source in some not > (some tracks suffer from GPS drift, sometimes camera positions might be > bad). > > ----------------------------------------
signature.asc
Description: This is a digitally signed message part.
