Where are photo file names?

turingtest2 wrote:

Bah, nothing is ever easy. That works fine if you run the script from the script editor, but If I try to wrap it up as part of an automator action in the way that léonie has shown in Photos for Mac: Batch Changing the Titles to the Filename then the use scripting additions clause won't compile, but tell me... end tell seems to work. 😕

Like I said, I really don't understand what's going on with this. Part of my problem is I haven't kept up with the newer additions to the AppleScript language like use statements, so for instance I thought that unless an app had its own scripting library term that could conflict with a StandardAdditions one (like "offset" in the StandardAdditions String Commands suite), there was no need to explicitly declare which terminology to use.

But the current Apple Control Statements Reference doc says this:

If a script uses

use scripting additions

, AppleScript may optimize scripting addition commands, sending them to the current application instead of the current target (

it

) when it does not change the meaning to do so. For example, random number does not need to be sent to another application to work correctly, and will always be sent to the current application when imported with

use

. Without a

use scripting additions

command, AppleScript must use a less efficient dispatching scheme, so explicitly declaring them is recommended.

... so that may not still be true, but since Photos has no "offset" command of its own, maybe it is just a bug in Photos' Applescript implementation that is causing these weird "silent" errors that do not halt the script ... or something. 😕

I did find something that might (partially, maybe, dubiously) explain why the script won't compile wrapped in an Automator action at http://macosxautomation.com/mavericks/usestatement/01.html. If I understand it correctly, it says that if a script contains one or more use statements, then the script must include one for scripting additions. I realize you were doing that, but perhaps it might compile if you added a use application "Photos" statement to force it to use both?

léonie wrote:

Do you have custom scripting additions installed?

I havenever tried to use them in an Automator workflow, only in standalone scripts.

Quite possibly, I'm completely wrong about this, but it seems like the weird "silent" tell current application block insertions shown in the Replies log are relying on the StandardAdditions.osax scripting addition to evaluate the offset command, which (I assume) is still part of everyone's OS X installation (in /System/Library/ScriptingAdditions), like it is in mine.

However, I just noticed that even Finder generates the same errors & current application behavior, so this isn't just something related to Photos. For example, this script:

tell application "Finder"

offset of "this text" in "some string of text including this text."

endtell

generates this in the Replies log:

tell application "Finder"

offset of "this text" in "some string of text including this text."

--> error number -10004

end tell

tell current application

offset of "this text" in "some string of text including this text."

--> 31

end tell

Result:

31

A little experimentation shows that the use scripting additions clause causes a problem if it is inside the on run {input, parameters} ... end run construct that was in léonie's automator example. If I put it outside, or simply dispense with that block altogether, then it seems to be OK. So what do I lose by leaving that out, or perhaps a better question is in what circumstances would it be useful?

tt2

léonie wrote:

Do you have custom scripting additions installed?

Hardly, this is my first proper exploration of AppleScript. 🙂

tt2

turingtest2 wrote:

So what do I lose by leaving that out, or perhaps a better question is in what circumstances would it be useful?

Good questions that I have no answers for, other than that possibly the "AppleScript must use a less efficient dispatching scheme, so explicitly declaring them is recommended" verbiage in Apple's reference might mean scripts that include use statements run faster or use less resources or something.

Ah, I meant leaving out the on run {input, parameters} ... end run construct. My current automator script is now a straight copy of the V1.3 script I posted above, and it works fine. 🙂

tt2

The "use scripting additions" clause is only necessary, if you are using more than one "Use" clause for scripting additions.

But since you are only using the "StandardAdditions.sdef" for the dialogs, it should not be necessary.

See these Help pages:

http://macosxautomation.com/mavericks/usestatement/01.html

http://www.mactech.com/articles/mactech/Vol.10/10.01/ExtendApplescript/index.htm l

Thanks, I'd found the first reference. It seems that in principle display dialog should be causing the same kind of error, or at least it would have done in days gone by. I can't see why that can be handled without triggering an error but offset does. 😕

ttt2

turingtest2:

I modified the script from your last post (which doesn't show up for me here - was it pulled for some reason?) to add several other extensions:

set

set exclude to ".jpeg.jpg.mov.png.tif.tiff.psd.nef.dng.cr2" -- Extensions to exclude from the image titles

set include to ".cr2" -- Extensions to include in the image titles

I've tested it with psd, nef, dng and cr2 files successfully. It didn't work with the .cr2 files unless I added it to the first line.

Sony raw is .arw - I have a lot of these too. There are a lot of raw formats - it would be nice if all the camera companies adopted Adobe raw (DNG) but that is extremely unlikely.

David

Old Toad wrote:

turingtest2:

I modified the script from your last post (which doesn't show up for me here - was it pulled for some reason?) to add several other extensions:

set exclude to ".jpeg.jpg.mov.png.tif.tiff.psd.nef.dng.cr2" -- Extensions to exclude from the image titles

set include to ".cr2" -- Extensions to include in the image titles

I've tested it with psd, nef, dng and cr2 files successfully. It didn't work with the .cr2 files unless I added it to the first line.

V1.3 should be here: Re: Re: Re: Re: Re: Where are photo file names?

Do you mean you needed to add .cr2 into the exclusion list before it would be force added by the inclusion list? That shouldn't be necessary but I just tried a little test and ran into the issue R C-R has mentioned about sometimes needing to close and reopen Photos to get current data from the database.

tt2

Do you mean you needed to add .cr2 into the exclusion list before it would be force added by the inclusion list? That shouldn't be necessary

I closed Photos, edited the script to remove .cr2 from the full list, opened Photos and tried again. All files were renamed except the .cr2 file. I checked the original file and it's extension was .CR2, in caps. That must be why.

Added another line to the script

set include to ".CR2" -- Extensions to include in the image titles

and that didn't work.

So I changed the two lines to:

set exclude to ".jpeg.jpg.mov.png.tif.tiff.psd.nef.dng.CR2" -- Extensions to exclude from the image titles

set include to ".cr2" -- Extensions to include in the image titles

I had added a lower case .cr2 file to the batch and all were correctly renamed with the script change above.

I'm not a scriptor so this was just by trial and error.

By the way I still can't see the post with V1.3. For some reason it remains invisible to me.

NOTE: you should add your script to the others in the Photos User Tips section.

turingtest2 wrote:

It seems that in principle display dialog should be causing the same kind of error, or at least it would have done in days gone by. I can't see why that can be handled without triggering an error but offset does.

Nor can I. I'm still puzzling over the OS X Automation article statement that "scripting addition commands are not available by default." That implies that a use scripting additions statement should always be necessary to use anything in the StandardAdditions suites, including display dialog, offset, delay, & many other commonly used commands. But I know that most do not; in fact so far it is only offset that I have noticed the strange error & automatically generated tell current application behavior with.

I get it that if the script has any other use statement (like use application "whatever" or use script "whatever") then you have to include a use scripting additions one, but that isn't true for your script or any of the ones I have experimented with.

Something else that is puzzling is the upper/lower case issue that OT mentioned. I assumed I would have to add "JPG" to the list for your script to properly handle some of my Photos files with that capitalized version of the extension, but it did not seem to be necessary, nor was there any difference with or without it in the exclude list. This sort of jibes with something I read about the considering & ignoring statements in Apple's docs (that ignoring case is the default behavior) but I'm not sure why it (apparently?) makes a difference for OT's files & not mine.

Speaking of which, I'm not sure the whole offset into a string method is a bulletproof way of uniquely identifying extensions. I haven't checks (nor do I know if it would ever come up in this context) but consider what might happen if the extension was something like .cr2 & there also was a .cr2a one. The first does have a non-zero offset into the second, so could that be problematic in some scenarios?

In the past, & for a different use, I have handled this by using a list of strings instead of a single string with all of them in it -- like set exclude_list to {"text 1", "text", "text 2", "whatever"} -- which I then test against with a simple "is in" statement. That probably is not necessary in this use ... but it does avoid the pesky offset command. 😝

Without modifying the script I added THREE new files, .PSD, .JPG and .JPEG to the library. All filenames were added as titles without the extensions as expected.

I noticed that the second line I've been working with is "Set to include" which keeps .cr2 in the title. I removed that line, keeping .cr2 in the line above, and got the following error message.

I added that line back and it worked as expected on all file extensions in the first line regardless of case.

I'd read up on case sensitivity too and both theory and practice (in my case) said I didn't need to worry about it, but perhaps it would be better if I made it explicit. As for substring searches I'd thought about it, but I've assumed until I know otherwise that there isn't a potential for a clash within the relatively limited set of valid image entensions. I've yet to explore more deeply but in my vbScripts I sometimes wrap the values with vertical bars, e.g. "|.jpg|.mov|.png|.tif|" and then add them to the search term. VBS doesn't have anything that looks as efficient if element is in list, on the other hand I've found that AppleScript doesn't seem to like some nested clauses which I would normally use to avoid having to declare variables to hold intermediate results. I shall find out what works and what doesn't. 🙂

tt2