Good afternoon everyone,
I shoot mostly raw images (Canon R5), and to tag the images, I use two programs. GeoTag Photos Pro 2 for outings where I have my phone with me tagging the images. The other application I use is GeoPhoto Pro to tag the images manually (when I don't use the other application) and save them to the CR3.
I'll show an example. Here is an image I manually tagged
This address and coordinates are correct.
To verify this information, I used PIE (Photo Information Extractor) and it shows up correctly:
So that's correct. Notice the West in the longitude.
When I import the image into Lightroom I get these coordinates:
Throwing the image into East instead of West, and causing it to be in the middle of the Mediterrean Sea, haha.
Well, I change the E to W and it's correct.
Again, this seems to be an issue in Lightroom importing the address since other applications can see the correct GPS coordinates.
Does anyone have any ideas on how to fix this? It's quite bothersome, especially since I'd have to manually change each image.
Either the app recording the coordinates isn't strictly obeying the industry standard or LR isn't (both have happened in the past). To determine the culprit, upload a sample .cr3 to Dropbox, Google Drive, or similar and post the sharing link here. We'll stick it under the microscope, and if it's a LR bug, file a bug report.
Thank you. Here is the RAW file I tagged with those coordinates. Link to Google Drive. Even inspecting it in Windows' file properties, the coordinates are correct.
This is why it's so curious.
Anyways, thank you very much! I appreciate your help and input on the matter.
What I see when inspecting the file using Jeffrey Friedl's Metadata Viewer plug-in (which uses Phil Harvey's ExifTool) is in the attached screenshot:
You will see that the GPS coordinates appear in two different places (presumably written that way by the GeoPhoto Pro app). The correct GPS data is in the EXIF section of the file's header, the incorrect GPS data appears in the XMP section of the file's header. Obviously LrC is reading the XMP data....which I would probably expect, but with raw images such as your CR3 files any additional XMP data is usually contained in XMP sidecar files. Maybe that's a bug in LrC, but as the acknowledged metadata expert @johnrellis will have a much better explanation as to why this is happening and if he thinks that LrC shouldn't be reading that XMP data from an original proprietary raw file.
Summary: The GeoPhoto Pro app has a bug, writing a different value into the XMP GPS fields than the corresponding EXIF fields. LR also has a bug -- it should prefer EXIF over XMP when both are present.
To build on Jim's reply, here's another view of the GPS fields stored in the file (also produced by Exiftool):
[EXIF] GPS Version ID : 184.108.40.206 [EXIF] GPS Latitude Ref : North [EXIF] GPS Latitude : 40 deg 28' 27.42" [EXIF] GPS Longitude Ref : West [EXIF] GPS Longitude : 3 deg 51' 37.44" [XMP] GPS Latitude : 40 deg 28' 27.42" N [XMP] GPS Longitude : 3 deg 51' 37.44" E
As Jim observed, the EXIF longitude is West while the XMP longitude is East. That's clearly a bug in GeoPhoto Pro. The easiest workaround is to run this command in the Command prompt after running GeoPhoto Pro and before importing into LR:
exiftool -xmp:all= *.cr3
(You'll have to download and install the free Exiftool.) That will delete the erroneous XMP fields.
Jim asks about the presence of XMP in raw files. In general, LR does read XMP fields from raw files if no .xmp sidecar is present. This is by design: Some cameras store in-camera star ratings in XMP, and newer Nikon cameras have started writing default Develop settings into .nef files, which LR uses as camera-raw defaults.
There are two reasons why other apps may be showing the EXIF fields rather than the XMP fields. First, many apps don't implement the XMP standard (I vaguely recall that Windows File Explorer does not). Second, the industry standards are ambiguous about whether to prefer XMP or EXIF when both are present. The original XMP spec gave precedence to XMP, but the later Metadata Working Group standard gives precedence to EXIF (with some exceptions, which don't include GPS).
LR does a pretty good job of following MWG (Adobe was one of the instigators of MWG), but it looks like in this case it isn't correctly following MWG, giving precedence to XMP. I'm not going to bother filing a bug report about this, because I'm certain, based on past experience, it will just go into the bit bucket. Even if the LR team did eventually decide to fix it, it would most likely be at least 6 months, probably longer, which won't be of any use to you in the meantime.
Thank you, that fixed it. I made a batch file to automatically do it for me to all the files in the folder. Now how to go about fixing all the past images! Haha, slowly and copying edits I suppose.
Just out of curiosity, is there any way to save the coordinates to the CR3 file after it has been manually tagged within Lightroom? I'm going through my catalogue for the last few months and so many haven't been tagged externally due to this issue with Geo Photo, but they've all been edited. And manually copying the developed images and then pasting them over the new one is a very time consuming task going one by one.
Any ideas would be greatly appreciated.
"is there any way to save the coordinates to the CR3 file after it has been manually tagged within Lightroom?"
You could select all those photos and do Metadata > Save Metadata To File, which will write all the photos' current metadata into corresponding .xmp sidecars. Then you could use Exiftool to copy the XMP GPS fields in the sidecars into the EXIF GPS fields in the .cr3.
I can only give you hints about how to do this, since it would take me a while to figure out the precise command line. It's a little messy because the XMP and EXIF GPS fields are slighlty different. But you could see this post and thread:
and the Exiftool copying examples here: