Aperture 2.1.1 released - new metadata field
Jul 30, 2008 @ 07:06 PM - Filed in:
New to Aperture
| News
Apple released Aperture 2.1.1.
I decided to take a quick look at the Applescript dictionary and noticed one additional tag, “MasterProject” of the “other tag” class. Oddly this tag hasn’t been added to the GUI (I don’t see it in the metadata inspector nor in the Query HUDs).
In 2.1, there is a tag named “MasterLocation” which provides the full path of a particular image. However it does not give you the project object. Why would you want a reference to the containing project object?
Let’s start with a very simple structure in Aperture:
If I wanted to know the name of the project of the container of the image I currently have selected using such a simple structure, obtaining the project’s name and properties will be pretty easy. I could then use that name to refer to the project. As log as the structure is left flat, no two projects can be named the same and there won’t be a problem identifying a project based on its name.
Now let’s look at a more complex structure in Aperture:
As you can see, there are two projects that have the same name. Say I want to know the value of MasterLocation of a currently selected image found in “folder 1 > project 1”. After removing “folder 1 “ from the string, I now know the project’s name. Then I want to know the properties or something similar of that parent project.
tell application “Aperture”
get properties of project "project 1"
end tell
Which project will Applescript/Aperture return? I have no idea because both have the same name. What I want is the ID of the project which is unique and thus uniquely identifies the project and thus eliminates confusion.
Aperture 2.1.1 has a new field “MasterProject” which should help solve this problem because this field provides a reference to the project object. Now users can uniquely identify a project based on an image selection.
I decided to take a quick look at the Applescript dictionary and noticed one additional tag, “MasterProject” of the “other tag” class. Oddly this tag hasn’t been added to the GUI (I don’t see it in the metadata inspector nor in the Query HUDs).
In 2.1, there is a tag named “MasterLocation” which provides the full path of a particular image. However it does not give you the project object. Why would you want a reference to the containing project object?
Let’s start with a very simple structure in Aperture:
If I wanted to know the name of the project of the container of the image I currently have selected using such a simple structure, obtaining the project’s name and properties will be pretty easy. I could then use that name to refer to the project. As log as the structure is left flat, no two projects can be named the same and there won’t be a problem identifying a project based on its name.
Now let’s look at a more complex structure in Aperture:
As you can see, there are two projects that have the same name. Say I want to know the value of MasterLocation of a currently selected image found in “folder 1 > project 1”. After removing “folder 1 “ from the string, I now know the project’s name. Then I want to know the properties or something similar of that parent project.
tell application “Aperture”
get properties of project "project 1"
end tell
Which project will Applescript/Aperture return? I have no idea because both have the same name. What I want is the ID of the project which is unique and thus uniquely identifies the project and thus eliminates confusion.
Aperture 2.1.1 has a new field “MasterProject” which should help solve this problem because this field provides a reference to the project object. Now users can uniquely identify a project based on an image selection.
Photoshop Droplets as External Editor
Jun 02, 2008 @ 11:52 PM - Filed in:
Tips
Although this tip has nothing to do
with Applescript, it does involve Aperture and automating image
processing using a 3rd party application.
One of the nice features of Photoshop is its batch processing of images and its ability to run recorded actions. The two combined together allow a user to apply the action against a directory of images or already opened images. Photoshop then allows a user to save a batch process along with an action using what Adobe calls “droplets”. The user can drop images or directories on the droplet and Photoshop processes those images using the instructions found in the recorded action.
Earlier today I created a droplet in Photoshop and saved it to my desktop. I then launched Aperture and made the droplet I just made as my external editor. The desire is to select a group of images in Aperture and have Photoshop process them using my droplet. I thought this would be really handy for preparing an image for printing or maybe I wanted a series of filters applied to the image. With Aperture 2.1, it seems as though the last image in the selection is the only one that Photoshop processes.
Although I wanted the entire selection in Aperture to be processed using the Photoshop droplet, this idea can still save a few mouse clicks. Without using this tip, you would have to instruct Aperture to open the selection in Photoshop. Once that is completed you then have to tell Photoshop to process the opened images using your action. Granted the time and effort savings isn’t terriby substantial although it could be if you were processing hundreds of images. One benefit of using a droplet as an external editor is images are handled one at a time by the droplet which is great if your images are large (imagine opening 20 200 MB TIFFs at once with 2 GB of RAM versus 1 image at a time using the same system configuration). If and when Apple addresses the problem and allows Aperture users to process multiple images using Photoshop droplets, this tip will save even more time and effort.
One of the nice features of Photoshop is its batch processing of images and its ability to run recorded actions. The two combined together allow a user to apply the action against a directory of images or already opened images. Photoshop then allows a user to save a batch process along with an action using what Adobe calls “droplets”. The user can drop images or directories on the droplet and Photoshop processes those images using the instructions found in the recorded action.
Earlier today I created a droplet in Photoshop and saved it to my desktop. I then launched Aperture and made the droplet I just made as my external editor. The desire is to select a group of images in Aperture and have Photoshop process them using my droplet. I thought this would be really handy for preparing an image for printing or maybe I wanted a series of filters applied to the image. With Aperture 2.1, it seems as though the last image in the selection is the only one that Photoshop processes.
Although I wanted the entire selection in Aperture to be processed using the Photoshop droplet, this idea can still save a few mouse clicks. Without using this tip, you would have to instruct Aperture to open the selection in Photoshop. Once that is completed you then have to tell Photoshop to process the opened images using your action. Granted the time and effort savings isn’t terriby substantial although it could be if you were processing hundreds of images. One benefit of using a droplet as an external editor is images are handled one at a time by the droplet which is great if your images are large (imagine opening 20 200 MB TIFFs at once with 2 GB of RAM versus 1 image at a time using the same system configuration). If and when Apple addresses the problem and allows Aperture users to process multiple images using Photoshop droplets, this tip will save even more time and effort.
Adobting Aperture
Jun 02, 2008 @ 06:01 PM - Filed in:
Tips
One thing that bothers me about
Aperture, Microsoft’s Expression Media (formly iView Media Pro),
and Adobe’s Lightroom is neither company has what I call
“transition tools”. How do I go from whatever solution I’m using
now to adobting your grand new image management application?
Because of XMP support, Expression Media and Lightroom probably are farther along than Aperture (yeah I know Aperture can read embedded XMP and can output XMP files but that output is limited and Aperture can’t read XMP sidecar files). However as far as I know neither Adobe nor Microsoft help current film users, users of a competitor’s product, users of even a custom made database, etc etc etc to switch to their solution. I’m surprised users go through with the move anyway, myself included.
Not all is lost when trying to move to Aperture, you just have to do some of the grunt work yourself. Say you want to move from Expression Media to Aperture or Lightroom to Aperture but you want to save all your metadata. Well first of all, your Lightroom adjustments will not work with Aperture because Adobe and Apple don’t use the same adjustments nor write the data to disk the same way. However your IPTC and custom metadata can careover to Aperture.
I’m not going to tell you exactly how to go about it. However, I will tell you the answer lies in the usage of Applescript, a tool named, exiftool, and the XMP sidecars. exiftool is the Swiss Army knife of metadata tools and among many other things it can read and write XMP files. So the idea is to read data from an XMP sidecar file for a particular image found in a directory, store it, then find that same image within your Aperture Library, you then write that data to the appropriate field within Aperture using Applescript. Of course this is probably not the only answer to the problem, perhaps others exists. This is just one I have discovered.
If you feel like going down this path, be sure to get a copy of the Exif v2.2.1 specification and the IPTC specification for IIM (Aperture 2.x does not yet support IPTC Core. Because of this you may end up losing some data, but you could keep it around by using custom fields. Not exactly ideal, but worth thinking about.). The specs may help you map out the fields between the applications as well as map the fields within the XMP file.
Because of XMP support, Expression Media and Lightroom probably are farther along than Aperture (yeah I know Aperture can read embedded XMP and can output XMP files but that output is limited and Aperture can’t read XMP sidecar files). However as far as I know neither Adobe nor Microsoft help current film users, users of a competitor’s product, users of even a custom made database, etc etc etc to switch to their solution. I’m surprised users go through with the move anyway, myself included.
Not all is lost when trying to move to Aperture, you just have to do some of the grunt work yourself. Say you want to move from Expression Media to Aperture or Lightroom to Aperture but you want to save all your metadata. Well first of all, your Lightroom adjustments will not work with Aperture because Adobe and Apple don’t use the same adjustments nor write the data to disk the same way. However your IPTC and custom metadata can careover to Aperture.
I’m not going to tell you exactly how to go about it. However, I will tell you the answer lies in the usage of Applescript, a tool named, exiftool, and the XMP sidecars. exiftool is the Swiss Army knife of metadata tools and among many other things it can read and write XMP files. So the idea is to read data from an XMP sidecar file for a particular image found in a directory, store it, then find that same image within your Aperture Library, you then write that data to the appropriate field within Aperture using Applescript. Of course this is probably not the only answer to the problem, perhaps others exists. This is just one I have discovered.
If you feel like going down this path, be sure to get a copy of the Exif v2.2.1 specification and the IPTC specification for IIM (Aperture 2.x does not yet support IPTC Core. Because of this you may end up losing some data, but you could keep it around by using custom fields. Not exactly ideal, but worth thinking about.). The specs may help you map out the fields between the applications as well as map the fields within the XMP file.
Aperture Assistant
May 01, 2008 @ 12:20 PM - Filed in:
News
Earlier today I randomly decided to
look at the activity of this web site by using Google's Analytics
service. One thing I noticed was someone had visited this site due
to a link from a domain named, aperture-assistant.com.
Well, it turns out aperture-assistant.com is the home of Aperture Assistant, a very visual based flow chart like application that basically runs applescripts for you but without having to write a line of code. Eh, imagine that. Programming turned visual. I'm sure many people will find this application far more useful than Automator (this is probably what Automator should be) and I'm also sure this application will be far more attractive to those users of Aperture that don't have time to learn Applescript or have a difficult time using it. I'm willing to bet that once I become decent at using Aperture Assistant I could beat a decent scripter in a race at writing up the same script.
After looking at the screen shots for Aperture Assistant, I suddenly realized that this is exactly how programming should be done. Why it has remained that way it has for so long is beyond me. This is very similar to the command line interface turned GUI. Once the GUI based operating systems came out, there were far more computer users. When I was in college I took a few programming classes. Each one forced students to create flow charts before even writing a single line of code. So currently a person has to convert what is in his/her head into a flow chart and then convert the chart into several lines of code. Then the person spends hours trying to figure what exactly went wrong during the conversion, assuming the flow chart was correct in the first place. But what if the person just created the flow chart in the computer and then the computer does the rest for you? I know I know, its a crazy idea having the computer working for you instead of you doing the work manually but hear me out. Imagine how many more programmers there would be and how quickly they could do their job. Oh wait....maybe that's why this kind of an application isn't too common.
Well, it turns out aperture-assistant.com is the home of Aperture Assistant, a very visual based flow chart like application that basically runs applescripts for you but without having to write a line of code. Eh, imagine that. Programming turned visual. I'm sure many people will find this application far more useful than Automator (this is probably what Automator should be) and I'm also sure this application will be far more attractive to those users of Aperture that don't have time to learn Applescript or have a difficult time using it. I'm willing to bet that once I become decent at using Aperture Assistant I could beat a decent scripter in a race at writing up the same script.
After looking at the screen shots for Aperture Assistant, I suddenly realized that this is exactly how programming should be done. Why it has remained that way it has for so long is beyond me. This is very similar to the command line interface turned GUI. Once the GUI based operating systems came out, there were far more computer users. When I was in college I took a few programming classes. Each one forced students to create flow charts before even writing a single line of code. So currently a person has to convert what is in his/her head into a flow chart and then convert the chart into several lines of code. Then the person spends hours trying to figure what exactly went wrong during the conversion, assuming the flow chart was correct in the first place. But what if the person just created the flow chart in the computer and then the computer does the rest for you? I know I know, its a crazy idea having the computer working for you instead of you doing the work manually but hear me out. Imagine how many more programmers there would be and how quickly they could do their job. Oh wait....maybe that's why this kind of an application isn't too common.
My Applescript Wishes
Apr 10, 2008 @ 04:21 PM - Filed in:
Other
I'll admit I'm not great at writing
scripts. With some time and patience I think I'm decent at getting
the job done assuming the job is even possible with
Applescript.
Let's take a stroll down Ranting Street...
1. I think using the language isn't exactly easy to use. But I think the language is easy to learn, but using it is a different matter. I have yet to come up with a good use for using just the language without actually automating an application. I suppose I could use it for a fancy calculator but I think there are other scripting languages and command line utilities and GUI apps already out there that would do a better job. Once you start automating an application, you have to learn how to automate that application. Then you move onto another application. The learning never stops. You can apply some things from what you learned with the 1st app, but the 2nd app could be drastically different and thus require more of your time and effort.
2. I think rant #1 would be addressed by addressing this rant. Where's Applescript's recordability in every Apple produced application? One of the features of Applescript is "recordability". Imagine being able to hit the Record button in the Script Editor and going through all the steps in the app you want to automate as you normally would. When your done you hit the Record button again to stop recording and your script is written for you. All of that without having to write a single line of code. You could record importing images from a directory, add some keywords after the import, apply some ratings, then export the project for whatever reason. Sounds pretty nice huh? So why isn't it available in Aperture? Because in order for an application to have recordability, the engineers developing the application have to implement recordability but unfortunately for us users they don't. I realize the Finder has some recordability but not much. I'm willing to bet there are more 3rd party applications with some recordability than all of Apple's software library.
Having this feature in Aperture would really make a workflow application a workflow application. It would save soooo much time and effort. Sure it wouldn't solve every problem out there. But it would surely save you tons of time, perhaps write the entire script for you, or at the very least give you a very good foundation to start with. I doubt this web site would even exist as well which is totally fine with me.
Also, why would Apple not implement it? Its their technology. Its an awesome time saver. And if you ask me, Automator is nice but its just a workaround for the lack of having good recordability. If recordability was in every application there would be no need for Automator.
3. Ever tried to write an application using Applescript Studio? The documentation isn't great as there are nothing specific to GUI controls and Applescript. The GUI control information is documented for the Cocoa programmer not the AS programmer. Well, I guess that's why they include so many examples. But that still doesn't answer many questions I have concerning what I can and can not do with a control and how I go about using a control, although the examples do help.
I'm sure I could come up with other gripes. But I think those are the real big ones for me. If you feel the same, I encourage you to contact Apple and let them know.
Let's take a stroll down Ranting Street...
1. I think using the language isn't exactly easy to use. But I think the language is easy to learn, but using it is a different matter. I have yet to come up with a good use for using just the language without actually automating an application. I suppose I could use it for a fancy calculator but I think there are other scripting languages and command line utilities and GUI apps already out there that would do a better job. Once you start automating an application, you have to learn how to automate that application. Then you move onto another application. The learning never stops. You can apply some things from what you learned with the 1st app, but the 2nd app could be drastically different and thus require more of your time and effort.
2. I think rant #1 would be addressed by addressing this rant. Where's Applescript's recordability in every Apple produced application? One of the features of Applescript is "recordability". Imagine being able to hit the Record button in the Script Editor and going through all the steps in the app you want to automate as you normally would. When your done you hit the Record button again to stop recording and your script is written for you. All of that without having to write a single line of code. You could record importing images from a directory, add some keywords after the import, apply some ratings, then export the project for whatever reason. Sounds pretty nice huh? So why isn't it available in Aperture? Because in order for an application to have recordability, the engineers developing the application have to implement recordability but unfortunately for us users they don't. I realize the Finder has some recordability but not much. I'm willing to bet there are more 3rd party applications with some recordability than all of Apple's software library.
Having this feature in Aperture would really make a workflow application a workflow application. It would save soooo much time and effort. Sure it wouldn't solve every problem out there. But it would surely save you tons of time, perhaps write the entire script for you, or at the very least give you a very good foundation to start with. I doubt this web site would even exist as well which is totally fine with me.
Also, why would Apple not implement it? Its their technology. Its an awesome time saver. And if you ask me, Automator is nice but its just a workaround for the lack of having good recordability. If recordability was in every application there would be no need for Automator.
3. Ever tried to write an application using Applescript Studio? The documentation isn't great as there are nothing specific to GUI controls and Applescript. The GUI control information is documented for the Cocoa programmer not the AS programmer. Well, I guess that's why they include so many examples. But that still doesn't answer many questions I have concerning what I can and can not do with a control and how I go about using a control, although the examples do help.
I'm sure I could come up with other gripes. But I think those are the real big ones for me. If you feel the same, I encourage you to contact Apple and let them know.
Scripting Resources
Apr 10, 2008 @ 04:12 PM - Filed in:
Other
I thought I would provide some
scripting resources that may provide some useful information on
using Applescript to automate. These resources should help writing
scripts with Aperture as well as other applications.
Applescript Language Guide
This was finally updated last month. Always a great place to start. HTML and PDF available.
MacScripter
Samples, hints, tricks, etc etc.
Brett Gross Photography
Although not strictly Applescript, Brett does provide some useful Applescripts that automate Aperture in someway. Who knows maybe he has the very script you want already written.
Apple's Aperture / Applescript Page
This has some very nice demos that show off some very nice things you can do with Aperture and Applescript. My favorite is the InDesign integration. I would love to hear from users that actually use this or something similar in their work.
Applescript Language Guide
This was finally updated last month. Always a great place to start. HTML and PDF available.
MacScripter
Samples, hints, tricks, etc etc.
Brett Gross Photography
Although not strictly Applescript, Brett does provide some useful Applescripts that automate Aperture in someway. Who knows maybe he has the very script you want already written.
Apple's Aperture / Applescript Page
This has some very nice demos that show off some very nice things you can do with Aperture and Applescript. My favorite is the InDesign integration. I would love to hear from users that actually use this or something similar in their work.
fullscreen property
Apr 07, 2008 @ 04:44 PM - Filed in:
New to Aperture
| News
I just read through an article on another blog (Inside
Aperture) concerning new Applescript stuff in 2.x. While I was
reading it and looking over the dictionary I just realized
something.
The application class in 2.1 has a new property: fullscreen.
The user can set and get the value of this property (it is a boolean property which means you set its value to true or false). The end result of setting this property is toggling the application fullscreen on or off. At this moment, I haven't come up with a good use for this but that doesn't mean one doesn't exist. Since Apple put it there, I'm sure its there for a good reason. I don't think its a good replacement/workaround for a slideshow because it takes some time to decode RAW files and thus the slideshow may get bogged down. But it may be useful for JPEGs.
tell application "Aperture"
set fullscreen to true
end tell
The application class in 2.1 has a new property: fullscreen.
The user can set and get the value of this property (it is a boolean property which means you set its value to true or false). The end result of setting this property is toggling the application fullscreen on or off. At this moment, I haven't come up with a good use for this but that doesn't mean one doesn't exist. Since Apple put it there, I'm sure its there for a good reason. I don't think its a good replacement/workaround for a slideshow because it takes some time to decode RAW files and thus the slideshow may get bogged down. But it may be useful for JPEGs.
tell application "Aperture"
set fullscreen to true
end tell
More new stuff for 2.1
Mar 31, 2008 @ 04:23 PM - Filed in:
New to Aperture
| News
During the weekend I finally got
around to upgrading to Aperture 2.1 as well as playing around with
new Applescript support. I'm very surprised Apple has released
2.0.1 and 2.1 with additions to Aperture's Applescript but hey I'm
certainly not complaining. Thanks Apple! I hope there is even more
to come.
Oddly, Apple only mentions one aspect of the new additions to Aperture's Applescript in the release notes for 2.1. I'm not entirely sure why that is. Here's what Apple says is new as it pertains to 2.1 and Applescript: "Extended AppleScript support. The "Reveal" verb in the AppleScript dictionary has been extended to include containers such as projects and albums.". Well I see one more addition to the dictionary: Import/Export of projects.
Here's a few simple scripts to help get you started with the new features found in 2.1:
I noticed right away the reveal verb has been updated more than just revealing containers (projects, folders, and albums) after looking at the 2.1 dictionary. The 2.0.1 reveal entry is very basic and you could only reveal a single image version at a time. The 2.1 dictionary states you need to place whatever you want to reveal in a list which got me thinking....does that mean I can reveal more than one object at once? Well as it applies to images, the answer is YES! For some reason the same isn't true for the containers (I realize you can't select more than one container in the GUI, but then why make it a list?).
tell application "Aperture"
tell library 1
tell project 1
reveal {image version 1, image version 10, image version 2}
--reveal {project 1, project 2}
--doesn't work although the dictionary gives an impression of a multiple container selection
end tell
end tell
end tell
Revealing a container is similar to revealing an image version: reveal {project 1}.
Exporting a project:
tell application "Finder"
set export_dir to (choose folder with prompt "Choose a folder to export into") as alias
end tell
tell application "Aperture"
set x to name of every project
choose from list x with prompt "Select a project"
set ap_proj to item 1 of result
set ap_proj to project ap_proj
export {ap_proj} to export_dir with consolidating images
end tell
I got caught by a stupid syntax mistake when exploring exporting projects. If you accidently leave off "images" from that last line, the script will run and the editor will ignore "consolidating" which will be treated as a variable. There are times when the editor will catch cases where a variable is used but no value is assigned to it and produces the appropriate error message. For whatever reason, the editor doesn't catch this particular case and I was trying and trying to figure out why my referenced images where not being consolidated on export. BEWARE!
And importing a project:
tell application "Finder"
set import_dir to (choose file with prompt "Choose a project to import") as alias
end tell
tell application "Aperture"
set x to name of every project
choose from list x with prompt "Select a project"
set ap_proj to item 1 of result
set ap_proj to project ap_proj
import {import_dir} into folder "blue folder1"
end tell
What's really nice with the way they implemented the ability to import projects is you can import a project into a particular location within the hierarchy within Aperture. For example, I have a blue folder named "blue folder1". I want to import a project so that it resides within that folder without any manual assistance. With 2.1, that can now be accomplished.
Oddly, Apple only mentions one aspect of the new additions to Aperture's Applescript in the release notes for 2.1. I'm not entirely sure why that is. Here's what Apple says is new as it pertains to 2.1 and Applescript: "Extended AppleScript support. The "Reveal" verb in the AppleScript dictionary has been extended to include containers such as projects and albums.". Well I see one more addition to the dictionary: Import/Export of projects.
Here's a few simple scripts to help get you started with the new features found in 2.1:
I noticed right away the reveal verb has been updated more than just revealing containers (projects, folders, and albums) after looking at the 2.1 dictionary. The 2.0.1 reveal entry is very basic and you could only reveal a single image version at a time. The 2.1 dictionary states you need to place whatever you want to reveal in a list which got me thinking....does that mean I can reveal more than one object at once? Well as it applies to images, the answer is YES! For some reason the same isn't true for the containers (I realize you can't select more than one container in the GUI, but then why make it a list?).
tell application "Aperture"
tell library 1
tell project 1
reveal {image version 1, image version 10, image version 2}
--reveal {project 1, project 2}
--doesn't work although the dictionary gives an impression of a multiple container selection
end tell
end tell
end tell
Revealing a container is similar to revealing an image version: reveal {project 1}.
Exporting a project:
tell application "Finder"
set export_dir to (choose folder with prompt "Choose a folder to export into") as alias
end tell
tell application "Aperture"
set x to name of every project
choose from list x with prompt "Select a project"
set ap_proj to item 1 of result
set ap_proj to project ap_proj
export {ap_proj} to export_dir with consolidating images
end tell
I got caught by a stupid syntax mistake when exploring exporting projects. If you accidently leave off "images" from that last line, the script will run and the editor will ignore "consolidating" which will be treated as a variable. There are times when the editor will catch cases where a variable is used but no value is assigned to it and produces the appropriate error message. For whatever reason, the editor doesn't catch this particular case and I was trying and trying to figure out why my referenced images where not being consolidated on export. BEWARE!
And importing a project:
tell application "Finder"
set import_dir to (choose file with prompt "Choose a project to import") as alias
end tell
tell application "Aperture"
set x to name of every project
choose from list x with prompt "Select a project"
set ap_proj to item 1 of result
set ap_proj to project ap_proj
import {import_dir} into folder "blue folder1"
end tell
What's really nice with the way they implemented the ability to import projects is you can import a project into a particular location within the hierarchy within Aperture. For example, I have a blue folder named "blue folder1". I want to import a project so that it resides within that folder without any manual assistance. With 2.1, that can now be accomplished.
New Applescript commands in 2.0.1
Mar 03, 2008 @ 05:35 PM - Filed in:
New to Aperture
| News
Aperture 2.0.1 was released earlier today.
I noticed Apple has added three new commands to Aperture's Applescript dictionary: duplicate, move, and reveal.
reveal
Looks like this command will "reveal" an image version found in the library. Why would you ever want to use such a command? Check out an example on Apple's Applescript page and you'll know. By the way, this is gotta be my favorite feature in the entire application because of the power and time savings it creates. That page also has a pretty good video demo of the feature; check out the page just to watch the demo.
Here's a sample script to get you started:
tell application "Aperture"
tell library 1
tell project 1
set image_count to count of every image version
repeat with i from 1 to image_count
reveal image version i
delay 1
end repeat
end tell
end tell
end tell
I placed the delay command in there so the script doesn't fly through all the image versions. You can change the amount it delays (in seconds) to fit your needs. And of course you can also reveal an image version by name.
duplicate
Although this command is basically already provided to Applescript, it now does something in Aperture. What? It allows you to duplicate an image version from one container to another. Say you need a copy of a master in project 1 as well as in project 2. Looks like it works copying versions to albums as well. Here's how you do it:
tell application "Aperture"
tell library 1
duplicate image version 1 of project "project1" to project "project2"
end tell
end tell
move
Similar to the duplicate command, this command will allow you to move an image version to another project. I don't believe it works moving to an album. That seems right as you can't move versions to albums, you must copy them to albums.
tell application "Aperture"
tell library 1
move image version 1 of project "project1" to project "project2"
end tell
end tell
I noticed Apple has added three new commands to Aperture's Applescript dictionary: duplicate, move, and reveal.
reveal
Looks like this command will "reveal" an image version found in the library. Why would you ever want to use such a command? Check out an example on Apple's Applescript page and you'll know. By the way, this is gotta be my favorite feature in the entire application because of the power and time savings it creates. That page also has a pretty good video demo of the feature; check out the page just to watch the demo.
Here's a sample script to get you started:
tell application "Aperture"
tell library 1
tell project 1
set image_count to count of every image version
repeat with i from 1 to image_count
reveal image version i
delay 1
end repeat
end tell
end tell
end tell
I placed the delay command in there so the script doesn't fly through all the image versions. You can change the amount it delays (in seconds) to fit your needs. And of course you can also reveal an image version by name.
duplicate
Although this command is basically already provided to Applescript, it now does something in Aperture. What? It allows you to duplicate an image version from one container to another. Say you need a copy of a master in project 1 as well as in project 2. Looks like it works copying versions to albums as well. Here's how you do it:
tell application "Aperture"
tell library 1
duplicate image version 1 of project "project1" to project "project2"
end tell
end tell
move
Similar to the duplicate command, this command will allow you to move an image version to another project. I don't believe it works moving to an album. That seems right as you can't move versions to albums, you must copy them to albums.
tell application "Aperture"
tell library 1
move image version 1 of project "project1" to project "project2"
end tell
end tell
News...
Mar 03, 2008 @ 05:33 PM - Filed in:
News
I'm not entirely sure how to post new
information if and when Applescript support gets updated, bugs
fixed, etc in Aperture 2.0 so I decided to do it using a blog. I
figured a static web page probably isn't the way to go due to a
lack of time stamps and other usability constraints. I hope this
will be easier on you. Let me know if you think there is a better
way.
With new commands, properties, and classes introduced (assuming Apple provides them), I will post information and examples here as well as update the other corresponding pages.
With new commands, properties, and classes introduced (assuming Apple provides them), I will post information and examples here as well as update the other corresponding pages.