PhotoLab is giving priority to the GPS value inside of XMP files. This also explains why I was seeing correct values with some images but not with all. If you don’t know which version of ExifTool is installed on your system, type this at the command-line: exiftool -ver ![]() Just remove the space that Google Maps adds between the latitude and longitude. The number format is nearly identical to what Google Maps gives you if you right-click on a map location. I changed my script to take advantage of a relatively recent update to the GPS setting feature that allows setting the ExifTool “composite” GPSPosition variable, which does handle the signs correctly when applied to XMP files (as well as JPG and RAW image files).įor those who care, if you are using ExifTool version 12.39 or greater, this example ExifTool command-line is very convenient way to set the GPS to a bunch of image files: exiftool '-GPSPosition=+32.266,-116.817' -i -progress *.* It ignores the sign of the GPS numbers when applying them to an XMP file and converts the latitude and longitude values into positive GPS numbers. It works fine with JPG and RAW files, but not XMP files. ![]() Turns out, there is a problem when writing to the GPS*Ref variables described above when applied to XMP files. (ExifTool will also accept a number when writing this tag, positive for east longitudes or negative for west, or a string containing E, East, W or West) ![]() (ExifTool will also accept a number when writing GPSLatitudeRef, positive for north latitudes or negative for south, or a string containing N, North, S or South) I had written a shell script to write the GPS values that took advantage of an exiftool feature that converts a signed number into an E/W or a N/S directional reference (see note in GPS Tags page): 0x0001 GPSLatitudeRef string Here’s an example of a one star image with bad GPS data in the XMP file. Ultimately, the error is in the XMP file. Once the filter started working, all of the images that did not have a star rating were displaying the correct GPS location, but those with a star rating are converting 122 W into 122 E (or 122 to -122).īut wait! Changing the filter again (to display only one star images) resulted in even weirder behavior. If I fix the GPS (from 122 E to 122 W in this case) while in the “Customize” view and then generate a new DxO JPG the result is correct. Regardless, the GPS data in the files is wrong and has been changed by PhotoLab. Enabling and disabling viewing RGB files, for example, did nothing. It seems like the thread that is updating the slide view while in the customize view gets stuck. The goofiness with the filter is harder to reproduce. GPS Position : 45.4313680555556 -122.709722222222Īs I was writing this, I noticed that there is also something goofy with the filter, which might have something to do with this problem (probably a case of needing to be more careful with inspection of and writing EXIF data). Note the JPG created by PhotoLab has changed data. Like the older post, I am also located in Oregon, where the the longitude is -122 degrees, but after processing photos with a correct location my photo is located in China, which is longitude +122 degrees.īelow is the GPS data in the original JPG from my camera (after augmenting it with the proper GPS location) and the RAW image (also augmented with GPS location data using exiftool). I was shocked to find that I have walked all the way to China this morning, which is… ![]() This is a link to the screen capture of the image GPS tag from the same image opened in P元. This is a link is to a screen capture of the image with the correct GPS information. I have found that images opened in P元 have longitudinal data inverted. I am using Photomechanic6 to ingest and geotag my images. P元 3.0.3 build 4295 (latest available today). I think I found a bug in GPS DxO PhotoLab
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |