importing locations to a specif list of photos is applied to all the active directory
Closed this issue · 22 comments
Version: 0.7.8378 [20221209:1226]
i have a batch of 50 photos;
I want to add localisations to 5 photos only ( because I dont want to change orthers, or because I want to keep the existing localisation)
after the localisation importation, all the 50 photos are modified.
Normal behavior should (must) be to modify th selected photos only
Regards
Phil
Noted - I'll have a look.
It does indeed work that way at the moment. I think that was the original request/wasn't otherwise specified. But if I can incorporate individual filenames into the logic I'll defo do it, it's just that geotagging works with a somewhat different command logic in exiftool than the rest of the stuff.
Hummm Are you sure that it worked like that in the past ? Perhaps I am wrong…
But in the (my) real life, the way I work is:
Select a batch of photo and try to use existing file positions
There are always photos without locations ( because of Google lack of positons or in case of lack of positions from my mobile)
Then I select missing photos and try to find locations by increasing the time between positions (less precision but is often enough)
And finally add missing locations by hand by clicking the map
This means that it is necessary to have the possibility to make those jobs for selected photos only without changing anything to others.
In geosetter, I used the filter « show photos without locations ». So after each tentative to find locations, there were only the photos with missing locations
And at the end of the end, I make a « save everything »
Il think this is a major point . And sorry if I did not notice that in all my previous tests .
I am afraid I have surely added bad locations to some of my photos with the existing behavior
regards
Phil
It's definitely been the same always ;) -- the tldr is that exiftool works one of two ways:
Either the user can pass an ungodly long parameter list in command prompt or use a so-called arguments file, latter being a lot easier to manage. For whatever reason geotagging as a function either doesn't work with the args file or I have failed to figure its ways, so I had to resort to using the long command line, which is tedious but seems to work. At the time of the original request the logic (in my mind anyway) was that the active folder gets the tags applied to, not the selected files, as if there is no matching data in the gpx files then there is nothing to apply (ie no change takes place), and if there is matching data then logically it would be deemed correct.
Current somewhat lengthy code for running your position files you sent me a while ago:
Note at the end the foldername just before -v2 -- I'll see if I can make it work with a list of files instead.
Okies changed 10e15a9
See updated installer on google drive pls.
Hi, i just installed the latest google version;
strange thing with windows:
installation screen is stuck at the upper left side of my screen without posdsibility to move it
I will have to crash it
Phil
when selecting a list of photos, the nu "remove geodata" removes also the time offset
I think that's the installer being silly - not sure if I can debug it because it's just packaged by Visual Studio but it's code as such. (I have no control over it)
Let me know if trying again works
Worst case you can try https://helpdeskgeek.com/how-to/move-a-window-with-the-keyboard-in-windows/
when selecting a list of photos, the nu "remove geodata" removes also the time offset
That's a feature not a bug - logically the time offset (time zone) is linked to the location of the photo. No location, no offset.
all the popup menu are blank
and more important menu is missing !
Weird. Okay I'll have a look, it was yesterday when I last checked but there were some code changes since.
I took the version this morning
Works okay for me both Fre and Eng.
I've re-posted a build just now on googledrive. It will have a different build number but otherwise identical to what it was yesterday. See if it works.
Ok Will try later to day.
have a look in the issue about unwanted time offset blanking when removing locations from a selected list of photos. This is not major but could hide something else
I will make further tests this afternoon ( if I have menus !)
Phil
I can add in an option into Settings to control that (offset delete) on the user side if that's acceptable...?
OK the installation worked that time;
I made several tests and it is now possible to update locations to a selection of photos : fine !
for the offset, I dont think an option in the menu is a good solution because removing offset data has nothing to do with (remove) localisations; So for me it would not be removed/modified.
another feed back: from a set of photos with localisations, we have the localisations on the map; when removing the localisation, and even after refresh, the localisations are always on the map. they dont appear only by stopping and restarting the softyware and reload the photos.
One remark : by definition and by its name, your program is for "geotag"; why did you shift all the localisation columns to the right ? it is possible to change but this needs some gymnastic with the mouse !
Regards
Phil
I've found a bug in the meanwhile that if you remove the geodata (using the button in the Edit Form, not the button in the "Main Form") then that gets entirely ignored.
I dont think an option in the menu is a good solution
(ignore the odd labels, this is just what it looks on the inside and i'm working on the above bug atm.)
Basically if user checks that last box then it will do what it's doing currently, otherwise it will not delete the Offset.
from a set of photos with localisations
The map only updates if there is an actual value to update with. When the user removes the location that's a null-value, so it gets ignored by the map. I can think about working around it but technically it's a feature so to say.
why did you shift all the localisation columns
I don't lol. When @Urmel changed the dynamic column orders that came in - originally it was in the front. But I'll look into why they've moved to the back.
Reference to myself: 320a0b7
New version copied to google drive. I'll have a look at the column order in the meanwhile.
why did you shift all the localisation columns
Fixed 728e574
from a set of photos with localisations
fixed in 823d2aa
may i ask that for new issues we open new tickets please. i am personally admittedly bad enough at mixing commits together in code but at least having different tickets for different issues makes things a little easier to follow ;) -- thanks
copied to GD.
Hi @pbranly can I close this pls?
I'll be away for a week or two around from this coming Friday so I'm hoping to do a public (not "development") release if all's well beforehand.
Yes it is fixed now
Thanks
Phil