Hi Tobias, thanks for the reply.
On 07/09/16 18:56, Tobias Ellinghaus wrote: >> 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. > > [...] I totally get that. I probably would have assumed some option to configure the time zone on a per film-roll or per camera-model basis, because it's a property which I attribute to those entities rather than the GPS track (which already has UTC). If I would have images from different cameras with different times zones in the same collection, to let's say apply a GPS track to all images taken on a specific tour, then its getting apparent. But that's a very special case that can be worked around. > >> 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. Are you asking me to put them there? :-) When I wrote the first mail, I had to make a decision: subscribe mailing-list or register with bug tracker. Went for the mailing list, as the contact page says: "development mailing list: bugs, ideas, patches, translations - all goes here." > >> 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. I get that, every team has its processes and rationales for them. It's just my opinion/experience that you have to make it easy for people to collaborate with you. You could open the tracker on GitHub and use it as an input channel only: if a valid report goes in there, put the link to the tracker as a comment and close it. >> ---------------------------------------- >> >> # 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. Ok, so no geotag in the history stack: see #1 below. > >> 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. Here's what I do: I remove the following attributes from the rdf:Description tag in the xmp file using some text editor: exif:GPSLongitude="censored ;-)" exif:GPSLatitude="censored ;-)" exif:GPSAltitudeRef="0" exif:GPSAltitude="442/10" Then I start Darktable, having the option for detecting modified sidecar files enabled. The program detects the change, I select the file in the dialogue, click "reload selected xmp files", and the geotag is still there. Interestingly, the xmp file gets overwritten in that moment. Looks like the same action as clicking the "overwrite selected xmp files" is executed - so that would be my guess what the defect is here. > >> 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): Clicking (selecting) them on the map and pressing delete would be one thing I tried. ;-) I also looked for a context menu when right-clicking the image. Maybe a little trash icon in the corner of an image on the map (maybe only shown on mouse over) would do the trick. > in map mode you can drag them back from the map to the filmstrip. :-/ Definitely worth a sentence in the manual. That worked, but it did not remove the altitude part. The xmp file remains completely unchanged, i.e. still has the whole geotag even after closing Darktable. If I remove all GPS stuff from the xmp, start Darktable, change is detected and it gets overwritten like described above, then only the last two attributes show up: exif:GPSAltitudeRef="0" exif:GPSAltitude="442/10" So it's not really deleting the whole geotag. I guess the map module does not care about altitude. Does the underlying map has altitude-data that can be applied to the geotag for the given position? Moving an image around will most likely invalidate any altitude currently assigned anyways. > >> Proposed solution: >> a) include geotags into the history stack (might be annoying with >> copy&paste?) > As said above, that should already be the case. #1 (from above): I probably misunderstand something, but above you wrote geotags don't belong into the history stack, which implies this should *not* 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. That's what I mean (copy&paste error). > >> 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? Another rationale could be a collection with images from two cameras, one with its own GPS one without. > 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? … Ok, this would then require a new field in the corresponding table of the database, which might be not worth the effort. Maybe it would be sufficient to look at the original file and see if has a geotag to decide whether or not to apply GPX data, in case the checkbox is checked. > >> 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). >> >> ---------------------------------------- Thanks, Matthias ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
