Am Donnerstag, 8. September 2016, 04:32:05 CEST schrieb Matthias Noack: > Hi Tobias, > > thanks for the reply. > > On 07/09/16 18:56, Tobias Ellinghaus wrote:
[...] > >> 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." Let's keep the discussion here then and only put the result in the tracker. [...] > > 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. We have too little man power for bug triaging already, making it more complicated and labour intensive wouldn't make things better. :( [...] > >> 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. The "defect" is that we don't clear metadata before importing an Xmp file. So the old info stays in the database. https://github.com/darktable-org/ darktable/blob/master/src/common/exif.cc#L1896-L1910 used to do that but for some reason I can't remember right now we stopped doing that. Note that the pasted code doesn't clear the geo data, that would require 3 more lines added. You would have to remove the image from dt, edit the Xmp and re-import for that. That being said, there is now a Lua script in https://github.com/ darktable-org/lua-scripts/blob/master/contrib/clear_GPS.lua that adds a shortcut to clear geo information for selected images. > >> 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. Yes, that could be doable. > > in map mode you can drag them back from the map to the filmstrip. :-/ > > Definitely worth a sentence in the manual. " In order to remove geo coordinates from an image just drag it from the map and drop it onto the filmstrip." from http://www.darktable.org/usermanual/ ch05.html.php > That worked, but it did not remove the altitude part. That's a bug. I'll fix it later. > 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" See above, the long/lat values get cleared in the database while the altitude stays, so it gets written to the Xmp. > 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? No. We discussed that in the past but couldn't find any good source for such data. > Moving an > image around will most likely invalidate any altitude currently assigned > anyways. Ack. I am not sure what to do about that though. Should the altitude be kept? Or removed when moving the image? I tend to vote for keeping as it might be from a different source like a barometric altimeter which records correct elevation independent from a possibly wrong GPS position. > >> 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. Sorry, I was somehow thinking of sidecars. [...] > Thanks, > Matthias Tobias
signature.asc
Description: This is a digitally signed message part.
