dt 3.1.0+2164~ga64940338, Ubuntu 18.04
I observe three bugs (?) :
Dropping an image on map does not place the image at the center of the hand cursor (as it was some time before), but on the right of it. Edit : More concrete, dragging an image onto the map, the cursor is shown as grey rectangle (symbolizing the image) with a hand and a small cross at its upper left corner. Dropping the image, the image (the peak of the small black arrow) is placed at the upper right corner of the icon. The expected location would be the center of the small cross of the cursor.
The manual states : “In order to remove geo coordinates from an image just drag it from the map and drop it onto the filmstrip.” This does not work anymore. Edit :
Tried several times yesterday, including restart of dt and checking the access right of image and sidecar files. Image disappeared from map, but geotag has not been removed. So switching to lighttable and back to map view showed the (removed) image on map again.
Tried again today : now removing the geotag works as expected again. Same dt version, no settings changed. I have no idea what happened in the meantime.
Changing the magnification of the map by scrolling the mouse wheel (in the screenshots one tick up or rather down) causes the image to “move” on the map. The first screenshot shows the initial position where the image was dropped and the settings of the module. Edit : Tried also with OpenStreetMap, Google Maps and Virtual Earth. Same effect, independent of map source used.
This is not from master. That is there since months and I’m not sure it’s about darktable directly. Map view is managed with osmgpsmap library. And this library has not been update since a long time. So not sure, something could be done on darktable for that. But remember that if you want to have more feedback on bugs, the good place to post is on darktable Github, not here. Many developers probably never go there.
@airflow: do you know really how use map view to say that? Of course, map view could see selected film-roll on the map, but images needs to be (of course) on the map. And at first, when you open map view, images shown are images selected so in filmstrip below. Then click on any film-roll and see map view centered on those images. And, if not images are shown, it’s that they are or not already geotagged or outside the view.
If images appear or disappear the way you describe, that is only a library issue, so not darktable one and has the library is no more updated.
Correct locations of multiple pictures is a bug that have been fixed quite currently. As I said to you few days ago, 3.2 will be out in august and fix quite a lot of bug.
The only one (and I’m not sure if it darktable one or osmgpsmap one) is the one describe by pehar.
Hello Nilvus, thanks (again) for your swift and helpful reply…
Regarding “do I really know how to use the feature” - very valid response, it could be that I don’t. Which is exactly the reason why I post first here, before filing bug-reports, because I’d like to find out if it’s really a bug first to keep noise for the developers low. If meaningful, I’ll gladly file bug-reports and try to do my part to improve the software.
Your description about the feature matches my understanding, I think. Example: When I did a walk around a lake and shot some pictures during that walk, I would expect basically a circle of pictures around that lake. But it happens, that the circle is not complete, only some parts of the walk are shown. When I scroll around the map, zoom around etc, it happens that some pictures suddenly appear, while others (may) disappear.
Also, even if explicitely selecting a certain filmroll (meaning - a specific filter in “collect images” section), the map view zooms in into the right section of the world map most of the time. This works. But nevertheless, if there are other pictures (not contained in the filter) which are at the same map area, they are also shown. Shouldn’t be, no? From the manual: “Map view will show you a world map with the currently open image, or film roll of images, pinned to their geotagged location.”
While I’m playing around I found that the filter for ratings also doesn’t apply in the map view. So if I set it to “2 stars or more”, it will also show unrated pictures, etc.
Your suggestion to wait and check again with the upcoming release 3.2 of darktable is a good one and I will do it. If the noted problems persist, I’ll try to report them.
Just two things: map view display at first what’s in filmstrip so it also depend of the current selection, that can be made on collect images module, so by selecting a film roll for example. I just tested the collection I just create tonight and on map view, I have no images (normal as I don’t geotag them actually). If I click previous film roll, I see images geotagged few days ago. And even if I zoom out, I only see current film roll.
Anyway, remember just one thing: I use master (so future 3.2) and it’s possible you don’t have same behaviour on 3.0.x version.
In all aspects, future 3.2 will be way more stable and more bug free than any darktable 3.x.x release. Even on map view (you will see). The only annoying bug remains the one describe by @pehar but as I know this bug is not published on Github (@pehar, as your describe is just great, think about posting it in Github).
To be more precise, when I talk about the bug you describe @pehar, I just talk about bug 3.
Drag and drop issue should have been fixed since your post. You are 300 commits behind so before posting in Github, of course, test last release.
Just updated to 3.1.0+2483~g3e898ae53 (on Ubuntu 18.04) and checked behaviour again. Point 1 and 3 of my first post are still valid, behaviour did not change.
when dragging and dropping an image onto the map it is not located at the “hot spot” of the cursor (the small cross), but somewhat right of it. The exact position changes a bit if you drop a single image or a bunch of images. But it is never the “hot spot” of the cursor which would be the expected position.
the “movement” of the imge on the map when changing magnification is unchanged. Maybe the bug of osmgpsmap is related. I don’t know the API of this library so I can’t say where the “interface” between dt and the lib exactly is.
I did not file a bug at Gihub for two reasons :
wanted to get confirmation before making noise
have no Gihub account. And can’t create an account because when trying to do so, Gihub violates the safety and privacy settings of my browser.
If someone else wants to file this bug for me, it would be very welcome. I can trace the issue at Github and give more comments here if this is wanted.