I have a stack of CDs filled with digital images, all ranging in size from 1.1 to 3.9 MB each. I have written a script that can create a database in Appleworks and an HTML page with the thumbnails for browsing. My plan was to have Image Events re-size each image to create a thumbnail, and put that image in the database to save on memory. Unfortunately, Image Events cannot see the dimensions of the images, and therefore will not do the SCALE command. The bizarre thing is that I can get the Image Capture Scripting app to open, see the height and width, do the scaling of the image, but it won’t save the scaled image.
I would appreciate any input on these two scripts:
--This can't scale the image
set main_path to path to desktop as Unicode text
set a to choose file
tell application "Image Events"
set b to open (a as alias)
scale b by factor 0.25
save b in main_path
end tell
--This actually reads the dimensions, and scales the image, it just won't save the blasted thing.
set main_path to path to desktop
set a to choose file
tell application "Image Capture Scripting"
set b to open (a as alias)
set {c, d, e} to {height, width, resolution} of b
scale b by factor 0.2
set {f, g} to {height, width} of b
save b in main_path
close b
end tell
get c & d & e & f & g --These data show that the image has been scaled.
Thanks in advance. I am not afraid of using sips via shell scripting, I am simply under the impression that if Image Events can’t see the correct data, perhaps neither can sips.
I believe Image Events requires an intial ‘launch’-
set aFile to choose file
try
tell application "Image Events"
launch
set myImage to open aFile
scale myImage by factor 0.25
save myImage
end tell
on error errMsg
display dialog errMsg
end try
That may be true for the older version, but I just finished installing OS X 10.4, and it works famously as written. I still have 10.3.9 on my iBook at home, so I will try the [launch] command tonight.
Thanks for the input, and the reminder about including an error catcher inside the tell; I keep forgetting that!
Now that you’ve moved to Tiger, you may care to know that although “Image Capture Scripting” still exists in the Scripting Additions folder, it can no longer be scripted and “will probably be removed in the next major release.” I understand that its functions have now been taken over by “Image Events”. This version of your “Image Capture Scripting” script seems to work in 10.4. On my machine, I can only get the new dimensions after opening the new file.
set main_path to (path to desktop as Unicode text)
set a to (choose file)
tell application "Image Events"
close images
set b to (open a)
set {{c, d}, e} to {dimensions, resolution} of b
scale b by factor 0.2
set p to main_path & name of b
save b in file p
close b
set b to (open file p)
set {f, g} to dimensions of b
close b
end tell
get {c, d, e, f, g}
I haven’t tested this theory, but maybe your original script wasn’t saving because you were specifying the desktop as the destination rather than the file itself. (?)
I believe that the 1.0 version of Image Events was simply unstable or incomplete. I only scripted Image Capture to see if that could “see” the dimensions that Image Events could not. Both of their dictionaries were very similar, and I am not surprised to learn that they are going to be ‘combined.’
I know that Image Events could save a file using the syntax I wrote, because I tried it out on the [rotate] command, and it was flawless as written, including the [save in], which is directly from the dictionary also.
My belief is that the applications came from two different sections of Apple, and neither was complete until the current Tiger update, and now they are getting together for the sake of simplicity. Either way, I had been meaning to upgrade at some point in time, so I suppose my little iPhoto cataloging project was as good of a motivation as any.
Thanks for the feedback about what you were doing with Image Capture Scripting.
Yes. On my Tiger machine too, the ‘in’ parameter for Image Events’ ‘save’ command can be a representation of either the file to be saved or the folder in which it is to be saved. In the latter case, the file’s name defaults to the name of the image involved, which in turn is derived from the name of the file that was originally opened.
After my previous post, I did in fact test my theory about the ‘save’ syntax with Image Capture Scripting on my Jaguar machine. Your ICS script, as posted, wouldn’t save there either, but did when I modified the save path to include a file name.
I believe that must be the “correct” syntax for the ‘save’ command, the idea being that it’s saving a document in a file rather than saving a file in a folder. Even Image Events’ dictionary describes the ‘in’ parameter as “The file in which to save the object.” But, of course, since ‘save’ is an application command, it’s up to the application writers how it’s actually implemented. Image Events’ authors apparently realised the possible confusion and wrote code that would handle being presented with a folder specifier. Image Capture Scripting just doesn’t save the document. Using yet another application (I forget which ” it may have been TextEdit) I once succeeded in overwriting my Desktop folder because I’d specified it as the destination for the save! (It was replaced in my Home folder by a file named “Desktop”.)
Ahhh, now I see what you were getting at before. I am glad you spent some time explaining that, as I was having some difficulty figuring out how to change the name of the image during the save procedure. Sounds like this is more a UNIX like syntax, where everything is a file; you specificy exactly where the thing goes and what it is called. I like that; it will be much easier to manipulate that way. I’ll even bet that it works just fine in 10.3.9!!! Oh well, now I have some widgets…
