I notice that Tropy imports an odd value for the exif GPS longitude & latitude.
It seems that it takes the text version and strips out all characters except for numbers, commas, and periods. For example
“74 deg 1’ 44.23” W" becomes “74,1,44.23”
Wouldn’t the simple binary version be better, that is, “-74.0289527777778”?
I’d argue for this because, first, the current value has no indication of west or east, even though that information is in the original exif tag. (I don’t have any images from south of the equator, but I assume the same thing is happening for south.) I could grab the longitude reference tag, which is either W or E, but that would make it a separate field. Second I’m not familiar with the current version being used elsewhere.
OTOH, many systems using northing and easting, which is what the binary version of the exif tag is, I think. This includes GeoJSON.
I did try to play with the datatype in the template, but Tropy kept showing the same value no matter what I picked (which seems odd).
PS I’ve got a GitHub issue on how Tropy handles some other binary exif tag values.
I need to check, but if I remember correctly Exif actually stores the full information across several tags (or that there are extra tags which guide the interpretation of the lat/long tags). We would like to introduce more complex value data types in the future, which would allow for specialized widgets (e.g., a combined view of the coordinates or even the possibility to view/move a point on a map). This also covers other binary values you mentioned: for flash, for example, I think we’d want the widget to be a select field for the standardized values, using translatable labels to display the values etc.
In any case, these are good points! I’ll post more over on GitHub.
Some learning later…exif gps data is definitely a little complicated and depending on the image file, it’s present in slightly different forms. exiftool will return the hemisphere info if it can, it seems, but sometimes Tropy won’t find the data even when it’s present. A file that has XMP-exif data for GPS and also composite data gets nothing loaded for the lat and long in a template that uses exif: GPSLatitude, whereas a file with GPS data loads just fine. An example of the former:
> exiftool -G1 -a -GPS* Downloads/IMG_6815.jpg
[XMP-exif] GPS Altitude : 114.03 m
[XMP-exif] GPS Altitude Ref : Above Sea Level
[XMP-exif] GPS Latitude : 37 deg 48' 32.30" N
[XMP-exif] GPS Longitude : 122 deg 12' 23.23" W
[Composite] GPS Altitude : 114 m Above Sea Level
[Composite] GPS Latitude Ref : North
[Composite] GPS Longitude Ref : West
[Composite] GPS Position : 37 deg 48' 32.30" N, 122 deg 12' 23.23" W
Running the binary version yields
> exiftool -b -G1 -a -GPS* -overwrite_original_in_place Downloads/IMG_6815.jpg
114.03
0
37.80897222
-122.20645278
114.03
N
W
37.80897222 -122.20645278
Could you share the full XMP content? I don’t know what exiftool means by XMP-exif exactly. If there are Exif RDF properties present in XMP body then they would actually clash with the actual Exif tags (if both are present in the file). I’m not sure which would win out during the import, but it’s certainly something that we did not anticipate – if you could share the full XMP body, I’d be curious to take a look.
Thanks, this explains it. It looks like Adobe has introduced their own Exif namespace. Tropy uses the W3 namespace which has been around for much longer. That’s why those tags don’t get imported at the moment. You could import them by importing Adobe’s Exif vocabulary and using their properties in your template: then Tropy should pick them up, but of course it’s not ideal to have two vocabularies for the same thing.
We should research if there is some consensus as to which vocabulary to use. If Adobe’s is to be preferred, we can switch vocabularies in Tropy and convert existing data during an update.
Hmmm. That’s a little odd because I don’t use Adobe products, but I did use an online tool to get the xml version of the xmp. What tool do you use to get the xmp out? Exiftool gave me the json. Or I can just send you the image.
The XMP standard was originally created by Adobe, hence most of the vocabulary is in the Adobe namespace, so this XMP data looks totally fine and I’m sure it’s embedded this way in your file.
In any case, this explains why Tropy didn’t find some of the Exif data and that’s something we should address by deciding how to deal with the two different namespaces. Ideally, we should use one and Tropy should be able to convert the other one automatically.
The bigger issue here is complex/composite values. We need to improve Tropy’s capabilities to handle complex data types (beyond simple strings and numbers) before properly addressing that.
OK now I would be curious to know what’s actually embedded in the file. If you could share the original file I’ll take a look. This one here is not better, because it’s just a custom namespace for ‘xmp-exif’ added by exiftool by the looks of it.
Yes, the XMP data looks like what you extracted using the online service you mentioned. It’s using Adobe’s NS. We’ll have to survey best practices in this regard and then either drop the W3 namespace in favor of Adobe’s or convert Adobe’s namespace when import XMP data.
I’m not terribly well informed on this, but as long as my files get read correctly, I’m good. This is stopping me from importing files right now.
(That and the ability to reload exif data if I change templates. If this was possible, I could load the images with the expectation of getting unimported gps data in the future.)