Red Tone Reproduction Curve : (Binary data 32 bytes, use -b option to extract) Profile Copyright : Copyright Apple Inc., 2017 Connection Space Illuminant : 0.9642 1 0.82491 Device Attributes : Reflective, Glossy, Positive, Color Device Manufacturer : Apple Computer Inc. Encoding Process : Progressive DCT, Huffman coding I think it’s a cropped image I edited in the iOS Photos app. Running the binary version yields > exiftool -b -G1 -a -GPS* -overwrite_original_in_place Downloads/IMG_6815.jpg An example of the former: > exiftool -G1 -a -GPS* Downloads/IMG_6815.jpg 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. exiftool will return the hemisphere info if it can, it seems, but sometimes Tropy won’t find the data even when it’s present. Some learning later…exif gps data is definitely a little complicated and depending on the image file, it’s present in slightly different forms. PS I’ve got a GitHub issue on how Tropy handles some other binary exif tag values. 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). OTOH, many systems using northing and easting, which is what the binary version of the exif tag is, I think. Second I’m not familiar with the current version being used elsewhere. (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. 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. Wouldn’t the simple binary version be better, that is, “-74.0289527777778”?
It seems that it takes the text version and strips out all characters except for numbers, commas, and periods. In the end, the AppleScript below did the trick, with exiftool installed and doing the grunt-work in the background.I notice that Tropy imports an odd value for the exif GPS longitude & latitude. Lindsay Berger has a well done script that displays the EXIF data from Aperture. AppleScript was the only way I could find to get the underlying “managed” file names of the photos within Aperture. I worked at the bash command line with exiftool for some time before deciding to use AppleScript rather than bash or Python as a control script. But I was reluctant to spend the $30USD for something I knew could be done easier and cheaper. The Internet provided a few pay applications for this purpose. I didn’t want to go to the effort of tagging everything only to lose it if Aperture (or a future Apple Inc. Yes, You can geo-tag in Aperture, but the tags are only within Aperture – they are not written to the “Master” or “Original.” I wanted them in the original, mostly for safety sake. Hence, there I was, just back from a trip around the Grand Canyon with a bunch of photos that needed to be Geo-tagged and no easy way to do it. Apple’s new Photos application completely lacks the feature and Aperture (no longer being updated) will not allow modification of the originals. The latest seems to be the inability to set GPS data in photographs that don’t already contain them. It appears that over time, applications I use tend to mysteriously lose functionality when they are “updated” or “new” versions are released.
0 kommentar(er)
