GPS data in XMP file missing correct "ref" data (the E/W and N/S direction information)

Forums: 

Originally, I thought this issue was being cause by DxO PhotoLab, but realized it is caused by FastRawViewer. The problem is that the "sign" of the GPS data is either being corrupted or ignored by FastRawViewer when it creates an XMP file (as the result of setting ratings, for example).
In my case, I have used ExifTool to set the GPS coordinates in the JPG and RAW (Panasonic RW2 file, in my case) files. The GPS data in the original files appears to be copied into the XMP by FastRawViewer, but the "sign" of the GPS data is being lost or corrupted. In the particular instance of photographs I discovered this on changed my -122 longitude to +122, moving my photo from Oregon to China.
It appears that PhotoLab prefers to use the GPS data that is in the XMP file, over that which is found in the JPG and RAW files, thus, when I process the photos in PhotoLab they are showing all those photos which include an XMP file to be on the other side of the earth.
I have not tested to see if this is also a problem for N/S coordinates, but I suspect the latitude coordinates have the same problem.
It's also a problem when you publish the photos to Google Photos, because it appears to use the GPS coordinates to determine the timezone offset of the pictures, ignoring the use of the "offset" meta-data for that purpose (which is understandable, because the "offset" meta-data is not widely supported).
Sure hope you can fix this issue.
Paul Fischer
paul@wobegon.net

Dear Sir:

FastRawViewer does not writes GPS data into XMP sidecars. It copies existing XMP data (sidecar or embedded block) into newly created sidecar, using Adobe XMP SDK which (we hope) preserves existing XMP data. The altered XMP tags are: rating, label, title, description and crs: tags (exposure, contrast, white balance) for RAW processing, all other data should be passed as is (if correct). Yes, it is possible that Adobe SDK may correct some incorrect fields if present.

Of course, if XMP block in your file contains incomplete exif:GPS... tags, it will not be corrected.

Could you please provide some files (altered by exiftool, but not altered by FRV) for inspection? Use support@fastrawviewer.com to send small files (and  WeTransfer/free option or any other file sharing service for large files)

--

Alex Tutubalin/FastRawViewer team

Hello Alex,

Thanks for the quick reply. I took an unmodified pair of images (JPG and RW2) and stepped through the process of setting the GPS coordinates and then adding ratings to the image with FRV. The resulting XMP file that was created by FRV was consistent with your statement, it only contained the rating changes I made, there was no GPS data added to the XMP file by FRV.
So I need to go back to experiment with PhotoLab again, as it appears to be the faulty party. I was seeing some strange behavior with their filmstrip filter which might be part of the problem. 
If I find something that relates to FRV I'll post again.
Thanks for taking the time to provide the detailed reply,
Paul Fischer
p.s. This is the XMP file that FRV created for the JPG/RW2 image pair that included GPS data added via ExifTool:

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.6.0">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about=""
            xmlns:xmp="http://ns.adobe.com/xap/1.0/"
            xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
            xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/">
         <xmp:Rating>1</xmp:Rating>
         <xmp:MetadataDate>2022-04-24T16:21:38-07:00</xmp:MetadataDate>
         <xmp:Label>Red</xmp:Label>
         <xmpMM:InstanceID>uuid:d874e788-25f8-4d1d-947a-6e77822b5d6a</xmpMM:InstanceID>
         <photoshop:SidecarForExtension>RW2</photoshop:SidecarForExtension>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>

 

Add new comment