Followup on the Applescript
Here are some of the technical details about the Applescript I mentioned Yesterday.
The first key line of the code I added to Mr. Gross' Applescript, is just a list of the EXIF tags I want to grab. Not exactly anything fancy, but this actually requires a modicum of thought, since, by default, exiftool will output the fleld names in a human readable format with spaces, but in order to keep the command-line happy is to use the form of the tag without spaces. It is usually pretty easy to figure out.
set DesiredEXIFData to "-LensID -Lens -LensType
-FocusMode -FocusDistance
-AFMode -AFPoint -AFPointsUsed
-ShootingMode -MeteringMode
-Flash -FlashSetting -FlashType -FlashMode"
I chose tags that I think would be interesting and help me learn as a photographer. Some are redundant - Lens ID, for example, is a superset of "Lens" and "Lens Type". I also added a couple that Aperture will read, such as "Flash". The trouble is, Aperture will only print "0" or "1" for flash, or something else similar. I understand the binary thing, but sometimes the number is "2". Exiftool will report this field as words with meaning: "flash did not fire" or "flash fired, return detected".
The tags need to start with the "-" character. And they shouldn't end with an "=" or you will erase the value in the source file. (By default, exiftool only does potentially destructive things after making a backup).
I decided to separate the fields desired from the actual call to exiftool, because I was distributing this script to the rest of the world and recommending that the user edit the desired fields based on their own needs and equipment. I figured it was harder to screw up the whole shebang this way.
-- Ask exiftool for tab-separated fields
set output to do shell script "exiftool -t " & DesiredEXIFData & " " & (quoted form of m_imagePath)
Pretty self explanatory. The "&" symbol is Applescript's text concatenation symbol. It's how you stick the fixed command stuff to the variable stuff.
Sharp readers will notice that I don't provide the full path to exiftool. That might come back to bite me sometime. The thing is, I don't have any idea if I installed it in the standard location or not. And I have no idea whether the end user will either. It works for now, so I am gonna live with it.
Now that we have the exiftool output, I have to do something with it.
-- Separate output by lines
set output to the paragraphs of output
-- Tell Applescript that tab is the delimiter
set AppleScript's text item delimiters to {ASCII character 9}
The exiftool argument "-t" will output the outputs the field name and the field value separated by a tab.
-- Do the following for each line of output
repeat with fields in output
-- split line into two fields
set fields to fields's text items
fields's? cringe!
-- the next two lines are probably not needed, but it makes things easy to read
set MetadataField to item 1 of fields
set MetadataValue to item 2 of fields
-- this does the actual write to the aperture database
tell curImg
make new custom tag with properties {name:MetadataField, value:MetadataValue}
end tell
end repeat
I think between the comments and Applescript's syntax, it is pretty easy to figure out what is going on.
Speaking of Applescript syntax, I think it is great at how readable it makes the code. But I always find myself struggling to try to figure out how to write it when I am coding something myself. Coming from C or Perl or bash, I find it frustrating to try to figure out how to string together things to make a working program.
Well, that's all I added to Mr. Gross' Applescript. I tested it quite a bit before I unleashed it upon the world. Within a couple hours, someone had come up with a fix for the one known bug that I decided I didn't want to fix because it rarely affected me (and never after I figured out what caused it).
There are at least two people who have tried it out, it worked for them and they like what it does. Feels good to give something to the world.
Labels: aperture, applescript, exiftool
7 Comments:
Cool script. When I run it, I get the following error message:
cat: : No such file or directory
That is the error message that happens when it is run on an image version instead of a master, before the fix was put into place.
Can you tell me if you are using managed images in Aperture or referenced?
This comment has been removed by the author.
Managed.
The file I try to run this on doesn't have "version" in the name, though.
Toine
You seem to have discovered a new failure mode.
Can you give me more information about your photo?
1) Is it a master or a version?
2) What is the name of the master?
3) What is the name of the version?
4) What is the name of the project it is in?
5) The names of all the Aperture folders it is in?
6) What is the name of your Aperture library?
7) Did you remember to change the library name in the script from my library file name to yours?
8) Does it work with any other images in Aperture?
9) There probably is a 9th, but I can't think of it at the moment.
1. I have no idea how to tell. I'm pretty sure it's a master
2. The "version name" in the Metadata View is this: Photography By Toine-20070519-_MG_3737. The File Name in Metadata View is _MG_3737.CR2
3. Photography By Toine-20070519-_MG_3737
4. 20070519 - Lea XXXXXX
5. Library/2007
6. set g_libPath to "/Volumes/Aperture Library/Aperture Library.aplibrary"
7. See 6
8. I haven't found a single image it works with
9. 42
OK. It looks like the fact that your version name and your file name are different is the problem. The script looks for a file name based on the version name, not the file name in the metadata view. This is because there is no known way to get the file name directly from Aperture, we have to take a convoluted path.
I will have to look into this and see how to work around it.
Just for as a test, can you change one of the pictures so that the "version name" in the metadata inspector matches the "file name" (except for the .CR2 extension), and then try to run the script on that file? Hopefully it works, and then I know what the problem is (but not yet how to fix it).
On a related note, I have reworked this into an Automator workflow that adds the metadata at import, which will get around this problem (or so I think...) I will blog about that soon...
Post a Comment
Subscribe to Post Comments [Atom]
<< Home