dbrewood. The issue you encountered occurred because the shortcut only worked with file names that had a lowercase jpg extension. As mentioned, it was a rough example.
The following version works with any file extension that contains 3 or 4 characters. This may need refinement if the disk file name contain a period in the actual file name.
BTW, the file extension is basically ignored after the initial Applescript. So, how the Photos app treats the file extension should not make a difference.
dbrewood. If the previous shortcut worked, you might try the following. It includes some error checking and has a few other enhancements.
I tried to include a file extension test in the Find Files action, but it didn’t work. I guess that’s because of the issue you note in your earlier post. It seems that multiple photo files will be returned on occasion and that some method will have to be used to distinguish between them.
Okay I went for the second option and implemented it as per the attached. MastoGPT ASP2 43.shortcut (30.8 KB)
I’m not sure if I ‘translated’ the shortcut details over correctly (I’ve checked it twice), but I get errors:
I’ve now run your shortcut (2nd one) over 5 photos picked at random and the keyword was set, so it looks like I’ve messed something up whilst duplicating the routines. I still think though it’s an issue with getting the file name with the correct extension./
dbrewood. I briefly looked at your new shortcut, and your implementation of my shortcut won’t work. To complicate matters, I am unable to test your shortcut because of repeated Unknown Action messages.
However, I now have a better understanding of everything and I agree that the file-extension issue greatly complicates matters. I’ll post my new suggestions later today or tomorrow morning. If Apple had only included the ability to set keywords in a photo with a shortcut, all of this could be avoided.
dbrewood. The following is the new approach. Could you test this as written just to determine if this approach works. I’ve included a lot of comments just to explain what is happening. I tested this without issue on my Sequoia computer with six test photos which have varying file extensions.
Okay… I had a feeling imy shortcut might not work… Sigh. The missing actions are likely those for the ChatGPT application, which the shortcut uses. However if I replace the filename variable with a ‘text input’ photo file name (as in your earlier shortcut) then it does work to set the keyword, so good news there!
The ‘Photo Comments New Approach’ shortcut does indeed seem to work well enough. Could it be simplified though by using ‘Name’ instead of ‘File Path’? If so then the ‘replace regex’ would not be needed? Not sure on that, but I think so as ‘name’ does appear to be the file name without extension.
Well done that man!
The issue does indeed seem to be the correct file name extension, as there can indeed be duplicate file names as .jpg, .jpeg, or HEIC all look to be valid.
This should be such a simple thing to achieve, but no an Apple-ism indeed,
One possible solution (may) be to use the ExifTool application to read/set the keyword information. I used it many years ago on Windows (cough), I’ve posted on their forum to see if it could be used in conjunction with Shortcuts, but from what I recall it likely can’t help. I’ve had a reply to my post, but it looks like it’ll only work on stand along files?
I have limited knowledge in this area, but it’s my understanding the keywords for photos in the Photos app are stored in a database in the Photos app folder. I don’t know one way or another, but I’d be a little surprised if ExifTool had the ability to modify that database. Perhaps the Photos app imports keywords set elsewhere?
The new shortcut works well indeed. So where do we go from here? Too early I guess for me to build your code around my routines (a pain copying it all over section by section), or do you want to see if we can solve the file name extension issue first? Processes I can see are:
Once a file name has been selected, test for the existence of the three possibilities and set the right extension on the filename. Set the ‘Processed’ keyword.
If duplicates exist show a warning message giving the file name and re-run the shortcut. Possibly set keyword on all photos to ‘NotProcessed’ or similar?
When the shortcut first selects the photo check it for either of the two keywords and if found re-run it.
Does that sound viable as to allowing things to move forward?
BTW I’ve now updated macOS Tahoe to Public Beta 2 so I’m hoping I can now work with the Shortcuts app without rebooting the Mac every 2-3 shortcut runs
dbrewood. I don’t know how to directly resolve the file-extension issue. The Photo app changes jpg to jpeg when it receives a photo with a jpg extension. A shortcut recognizes and uses the jpeg extension, but AppleScript uses the disk file extension (jpg or jpeg). I don’t know how you can resolve that. Also, I don’t know if any other file extensions are changed (e.g. heic).
As written, my shortcut shows an error dialog and stops when a duplicate is found, and that seems to be the place to deal with duplicates. A duplicate could arise from several sources:
The duplicates have the same file name but different extensions.
The duplicates have the same file name but are located in different folders (not sure of this one).
The AppleScript uses the begins with operator in filtering file names, and this could result in duplicates that are not actually duplicates (e.g. “County Courthouse” and “County Courthouse Winter” are seem as duplicates).
The simple option is the existing one which is to notify and stop when duplicates are encountered. An easily implemented option is to notify when duplicates are encountered and to prompt whether to change the keywords of all photos or to stop. It might be possible to notify and to prompt which photos should have their keywords changed.
BTW, at the end of the shortcut, instead of using a Run AppleScript action, it might be a good idea to call a separate AppleScript (i.e. scpt) using the osascript command in a Run Shell Script action. The only parameter that would need to be passed is the file name from the shortcut. There’s no inherent advantage to this, but it would make things a lot easier, especially if the AppleScript becomes complex.
Thanks for the update. I’ll be brief here as replying on my phone while out getting the car serviced.
I didn’t realise that the Apple Script and Photos app worked in different extension bases. A real pain.
I guess the best options are either to detect, advise and exit as you’ve got it now, or change all photos to a ‘processed-duplicate’ keyword, again advise then quit out. Either would work for me.
Just to check, before we go further, it will be possible to read the keyword when looking at the photo filtered so it willl be possible to re-run the shortcut to choose another photo if any ‘processed’ keywords are found?
dbrewood. As far as I know, it is not possible for a shortcut to directly get the keywords of a photo. If I’m wrong about that, please let me know. However, I don’t think that’s a significant issue one way or the other, as the keywords are probably most reliably gotten by the AppleScript.
After the initial Find Files action in the shortcut, an AppleScript has to be called at some point to do its best to find a matching photo. The AppleScript find process would be based on file name without extension and possibly on other data (e.g. containing album and date). If a single match is found, the AppleScript could then return the Media Item ID (which will be used to set the keywords) and the existing keywords for the single matched photo. If the existing keywords contain processed, then the shortcut could be stopped. I haven’t actually done this, but the tentative answer to your question is yes.
Let me know what you think of the above. As time permits, I’m going to work on the AppleScript portion of this. I’ve already confirmed that an AppleScript can be called by a Run Shell Script action and that values can be passed both ways.
BTW, the following are the properties that can be used in the AppleScript to identify a photo. It will just take some testing to determine which of these are best passed from the shortcut to the AppleScript. Album is not in this list, so perhaps that can’t be used.
Okay we’re good, as long as when the photo is sourced it can use the Apple Script obtained data to avoid any which are already processed, with either flag, ‘processed’ or ‘processed duplicate’ or whatever we’re good’.
The only selection criteria needed areas per I have at the top of the shortcut, image and favourite. So feel free to play around.
dbrewood. I reread your original post, and I didn’t keep this in mind when writing suggestions. I think this process has to start with an AppleScript, which will find a random photo that does not contain the keyword processed. The AppleScript will then call the shortcut to do the rest of the work. The same general approach can be used as before, but things need to be changed around. Sorry for the confusion.
The following is a rough example of this new approach. Let me know what you think. The AppleScript can be amended to test for file extension to insure that unwanted media typea are not returned.
@peavine I’ll look at the revised shortcut later, just about east. But yes the idea is to select a single picture, as that will be used for the rest of the shortcut to process. The idea is to (eventually) automate the posting of a ‘daily’ picture to Mastodon. The elements needed are a main description, with hashtags, the image and an alternative descriptive text for the image.
Does that clarify the operation? I had thought I’d advised the purpose earlier but maybe not
I’ll report back ASAP after looking at the new shortcut.
dbrewood. You did an excellent job of explaining things. I got so involved in the intricacies that I lost sight of the main goal. Hopefully we’re on the right track now.
My new-approach shortcut does need a fair amount of work, all of which should be fairly straightforward, including:
The initial AppleScript should only return favorites.
Error checking for multiple photo matches is needed after the Find Files action.
A new AppleScript action is needed to actually set the tags of the photo to processed.
The first AppleScript in the New Approach shortcut may be slow depending on the number of photos and how many have been processed. If that’s the case, the following AppleScript may be faster:
tell application "Photos"
set photoIDs to the id of every media item
set testedPhotoIDs to {}
repeat 1000 times --1000 is an arbitrary number
set theID to some item in photoIDs
if theID is not in testedPhotoIDs then
set {theKeywords, isFavorite} to {keywords, favorite} of media item id theID
if theKeywords does not contain "Processed" and isFavorite is true then
set unprocessedPhoto to filename of media item id theID
exit repeat
else
set end of testedPhotoIDs to theID
end if
end if
end repeat
end tell
try
return unprocessedPhoto & linefeed & theID
on error
return "No Matches"
end try
@peavine Good morning, I’m off out for breakfast with my good lady so no time to do a full reply or even look at the above.
I had a thought last night, if the new code works as planned it can only return one photograph with no duplicates? Am I right in this? If we still get duplicated though just work with one of them and ignore the others as they’ll be ‘caught’ in later runs?
I’ll look at the new code later once we’re back from breakfast.
