Skip to main content
Adobe Photoshop Family

11 Messages

 • 

222 Points

Sun, Nov 27, 2016 12:13 PM

Elements: GPS Coordinates are changed in EXIF after a 'Save Metadata to File' in Organiser

I have found that the original GPS coordinates are changed in the EXIF after a 'Save Metadata to File' for a keyword for example. 

As an example: on one image the coordinates have changed from 52 8.9373N 0 37.1740W to 52 8.9333N 0 37.1667W.

It's as if the coordinates have been truncated.

I reported this problem in version 11, 4 years ago and it has not been resolved in versions 12, 13, 14 and now version 15.

I would be extremely grateful if it could be resolved due to the fact that as it is I cannot save keywords to the metadata without corrupting the coordinates

Responses

Champion

 • 

1.3K Messages

 • 

20.2K Points

4 years ago

Yes, there is a rounding/truncation when you write metadata to files.
Another instance:
My GPS Latitude is 48,50,1999664307 N
After writing metadata to files it's now:  48,50,20N
Not sure my calculations are right, but it seems that's an error of 37 meters (please correct me if I am wrong...)

So, yes again, you get corrupted values, even if the precision is probably good enough for most geotagging uses of a photo library (unless my calculation is false...)

If keeping the original values is crucial for you, I could imagine keeping the original and doing your tagging and writing metadata to files to a copy in a stack or version set.

11 Messages

 • 

222 Points

4 years ago

I don't understand why Organiser rewrites the coordinates when they haven't been changed.
There is no need to.
In any case it shouldn't be changing fields in the metadata that have not been specified

I believe Lightroom has a similar problem..

11 Messages

 • 

200 Points

I have just got Organiser 16 and found that there is a bigger bug in "Save Metadata to file" for GPS coordinates that are longitude EAST

For GPS coordinates that are longitude WEST there is still some rounding.

Organiser does set values for the four attributes in the file -  LatitudeRef , Latitude , LongitudeRef , Longitude 


For GPS coordinates that are longitude EAST

Organiser sets the  attributes in the file -  LatitudeRef , Latitude  correctly

                 LongitudeRef  is not set at all

                 Longitude is set only to the nearest degree                                                               with 0 minutes and 0 seconds

  

becomes

 

Rather more that 36 meters !!

1 Message

 • 

60 Points

I have the same problem in Photoshop Elements 2019. Organizer writes well the gps information to the file. With other programs I can read it correctly (p.e. Faststone Image Viewer or Windows Foto) but not with Photoshop. That is clearly a bug which can't be so difficult to correct. I ask me if Photoshop Pro has the same bug or it is only for Elements user.

5 Messages

 • 

100 Points

7 months ago

I have the same problem.
I cannot save to metadata due to that the GPS information is overwritten. Exporting the files to any external program shows the position way off, kilometers usually but some pictures more than that. 

Another related issue is that in the case setting the position with places does not work outside elements. If saving the metadata and using the position in an external program the position is not correct, sometimes 100's km off.

Assume it is the same in elements 20 ? How to proceed with this ?  By looking at different posts the bug seems to have been there for years, will it ever be corrected ? 

11 Messages

 • 

200 Points

7 months ago

The issue is that the GPS data is obviously held correctly within Elements but is truncated when exported. I have been asking them to fix this for years. I spent time with one of their support team giving them examples and sample photos to pass on to developers.... Nothing seemed to happen unfortunately.

7 Messages

 • 

170 Points

7 months ago

Hi,

Can anyone confirm if they are still facing the issue with PSE 2020?  You can download the trial from https://www.adobe.com/products/photoshop-elements/download-trial/try.html  

Thanks!

11 Messages

 • 

222 Points

I can confirm that the coordinates continue to be truncated in PSE2020.

The problem remains that when the original photo has detailed coordinates, these are overwritten with truncated coordinates when metadata is written to that photo.

I originally reported this 7 years ago with PSE 11

regards

John Ward

7 Messages

 • 

170 Points

Hi John,

Thanks for the confirmation. Can you please check if the magnitude of deviation is similar to what you observed in previous versions or has it improved? 

Thanks!

11 Messages

 • 

222 Points

As Mark says, the deviation varies due to the truncation of the latitude and longitude fields when metadata is written to the photo by Elements 2020.

The properties of an original photo and the same photo after a keyword tag has been written (Save metadata to file) to that photo by PSE 2020 is shown below.

This shows the truncation effect of PSE 2020 on the latitude and longitude fields.

I do not understand why PSE 2020 has to access that field at all as it is not being changed in PSE 2020.

I look forward to resolution of this long outstanding problem. 

regards

John

11 Messages

 • 

200 Points

It does need access as you can move a photo on the map and change the GPS location. In addition you can tag a photo with no recorded position at all using the map tool. However both these methods place a photo on the map and then truncate the coordinates upon export. Same bug

11 Messages

 • 

200 Points

7 months ago

Just restested with Organizer 20 - Problem still there

Imported file - saved metadata to file and GPS truncated

Screenshot of metadata (BEFORE - copy photo and AFTER - original photo) 

Note Longitude and Latitude have both been truncated

I can send email with further screen shots and details of the software used to check the GPS data if required



Champion

 • 

1.3K Messages

 • 

20.2K Points

In my test, I just realized the following.
1 - Testing a file before any "write metadata to files', I get the values of the seconds like this:
Lat  .. , .. , 47 -  Long .. ,  .. , 57
Same values in the editor and the organizer

2 - After adding a caption and writing metadata to files:
Lat  .. , .. , 47 -  Long .. ,  .. , 57 (unchanged in the editor)
Lat  .. , .. , 68333333 -  Long .. ,  .. , 9500000

In other words, the initial value is represented in real seconds (60 seconds in a mnute) in both softwares, but it is changed to hundredths of minutes in the organizer catalog.

If I add new  captions and write metadata to files, after the display mode has been changed to 1/100 th of minutes, no change in the file itsself in the editor.

So, I don't see that as a bug, just something not explained in the organizer.
The max precision is the 'seconds'  value recorded by my smartphone.




11 Messages

 • 

222 Points

I disagree, this is a bug as can be shown by my post & Mark's post.. 

Champion

 • 

1.3K Messages

 • 

20.2K Points

What I am saying is that in PSE 2020, There is an change in the display values of the coordinates, and that when exported, the coordinates themselves are not changed.
There is a field to tell which system you use: seconds or 1/100ths of minutes.

What happens in your examples as well as all mines, is that there is not only a truncation, there is a truncation on the wrong system, as appears in the Windows explorer values you are showing.
example .0683333333N is truncated to 06N instead of being translated to 40N.

The correct values appear correctly in Windows in my current test with PSE2020, I have not tested with older versions.

What I did did not find as normal was that I don't understand why 'write metadata to files' changes the values (or the format) of fields which have not been changed by the user.

11 Messages

 • 

200 Points

7 months ago

In reply to your question regarding deviation (to John), I do not think it has changed. The actual physical deviation depends on the GPS location in question. If truncation goes from  .001 to .000 the deviation is small but .999 to .000 moves a lot.

11 Messages

 • 

200 Points

7 months ago

This is a bug Original Latitude 55 degrees 40 Minutes 13.649 Seconds becomes Latitude 55 degrees 40 Minutes 13.000 Seconds. Same with Longitude.

Recording locations to the nearest second is not accurate. That is why most GPS devices use 3 decimal places at least

11 Messages

 • 

200 Points

7 months ago

This is just a truncation in the software when writing the GPS back to file. The application is obviously working to 3 decimals internally as it places photos on the correct position on the map. It is only the export routine that is broken... should not be a difficult fix

5 Messages

 • 

100 Points

7 months ago

Hi,
Agree that the truncating is a problem but I think a bigger problem is that files exported with the element organizer cannot be used in external software. If you for example share a photo this is not good. I think Adobe somehow is not following the standard or is using too few decimals maybe. Not sure but there is something with the format that is not working

Tried importing a number of photos saved by elements to Google Photo, Windows Photo and Icloud.
Windows Photo: Can handle the files
Google Photo: Cannot read the coordinates at all
Icloud: Lat is ok. Long, only the 2 first digits read (degrees). If you have a position in dd,50's you are 50-55km's off.
Above is valid for Longitude E, not sure it is the same for W.

Clearly something is wrong with the coordinate handling if it can not be used by Google and Apple sw. Is the Adobe truncating of the coordinates following the standard ?

I consider this as a major bug that needs to be corrected. Why not just leave the GPS coordinates as they are ?, problem solved.

5 Messages

 • 

100 Points

7 months ago

Adding an example on difference in Metadata format introduced by Elements.

Example between original coordinates and coordinates saved by Element organizer:

Original Photo from Iphone:

 

Reading data from Windows and metadata from Synology Photostation. Windows properties and metadata the same

 

 

Same photo as above saved with Elements Organizer


Windows is not showing the same data as when reading the metadata

GPS format differs compared with original.

GPS Info IFD Pointer differs with original.

GPS longitude ref is missing.

Format cannot be read by Google Photo and Synology map, Icloud cannot handle the longitude, uses 17,00,00 on the map, latitude ok. Must be a problem caused by the modification done by element organizer.


5 Messages

 • 

100 Points

7 months ago

Related to previous,
All Longitude W pictures are visible on maps.
All Longitude E pictures are not visible on maps.
One difference in the metadata is that Elements is missing to add GPS Longitude Ref when saving to metadata. Needed for decoding ?
Difference between W and E metadata

11 Messages

 • 

200 Points

7 months ago

Please could someone at Adobe look at the GPS metadata writeback function and do some proper investigation. The problems have been there for at least 5 years.

There are errors both when saving metadata on a photo with existing GPS data and when saving metadata on a photo that has been geocoded using the map function within Organizer.

There are differences to how E and W Longitudes are handled.
There is tuncation happening on both latitude and longitude settings
Others have reported errors with GPS Altitude in the past (but I have not seen this one)

Overall Photoshop/Organizer/Premier Elements is a very good suite of programs, but just little bugs like this let it down.

Please fix it for us !

Champion

 • 

1.3K Messages

 • 

20.2K Points

7 months ago

Mark,
The trouble with this issue (or those issues, I believe there are different ones) is that Adobe has to reproduce what you are seeing. Believe me, I have been working for two days to check and try to understand what is going on. And I can't reproduce it.
I am working on PSE2020 on Windows 10
My own source of geotagged files is from my Samsung G8.
Not very precise (to the 'second' or 7 decimals, which insures correct GPS driving aid - max error about 20 meters. I think most amateur photographers don't need more.

It's of the utmost importance that we have to compare the 'before' and 'after' GPS data with the same tool.

My tools are:
- Microsoft Explorer file properties
- Elements Organizer Information panel
- Elements editor File Info - GPS and raw sections
- Faststone File Viewer with Google Maps
- Geosetter working on Exif Viewer and  watermarked Google Maps

The 'before' and 'after' must be compared on the file modified by PSE or on the original file plus the copied or exported file, by the same tools.

The command issued by PSE to create the GPS alteration must be clearly stated and reproducible:
- copy or export
- 'update thumbnail' or re-import in new catalog.

Before and after must be compared with the same decimal or sexagesimal representation on the same tool.

So far, I have not been able to reproduce the issue. I only find curious that some of the above commands result in the organizer changing the sexagesimal display default (like in the Explorer) to decimal. Other tools keep their own preferences before and after. 

There are not only rounding error risks;  their importance can be calculated.
Errors in the many kilometers range may rather come from a false conversion from a software to another.
I believe there would have been much, much more complaints in this forum if such anomalies had been the rule. 

I must be missing the exact PSE command which produces the issue.


11 Messages

 • 

200 Points

Is there a way that I can send you a JPG file and word document with full instructions to reproduce the issue?

I can send two jpgs - BEFORE AND AFTER ....The instructions will show how the metadata was transformed by Adobe Organizer and you will be able to repeat it easily

5 Messages

 • 

100 Points

7 months ago

Looks like we have different issues with the coordinate handling, maybe I should have this in a new post.

Just to confirm the error in Longitude East. I checked the format with EXIF reader sw.

Original


Elements output

Longitude 17,55 is converted to 17, longituderef missing.

Most external sw cannot read this format, probably because of missing decimals. Windows Photo and Icloud can read it and uses the long E according to above, 17 degree. In this case around 50-55 km's off. If you are just above a degree the error will not be as significant.

I am quite new to Elements and I find it strange that this kind of bug is present, considering I am using Elements 19. 

Should be easy to correct. long W is working so it should be straight forward to just compare the difference in the implementation between W and E.

Not sure how to proceed to get this corrected. Is this the forum or is there a better way ?