How to use Photoshop's COM interface with Python?

Tools Nuke
#1

Hi,

I want to use Python scripts inside of Photoshop and from what I read, you need to use the COM interface of Ps. The problem is that I’m new to Python coding and Ps scripting in general and I didn’t find any info (for beginners) on this topic. I’ve searched the forums but the threads I found only provided some tips for advanced users.

So my question is: how can I learn to control Ps using python and the COM interface?

#2

This should help.

#3

Thanks for your reply, Adam!

I installed ActivePython (which seems to include win32 com) but the script doesn’t work :frowning:

(Python version is 2.7)

#4

We’ve used multiple languages to talk to PhotoShop, and we have a loose rule in house. If you are trying to talk to PS from an existing application suite, then you can bang your head against the COM problems that you will inevitably encounter and add support to the existing code. If you are writing a one-off script that will be run “from PS”, then write it in JavaScript so that it can be run directly from the PS interface. You will find much more scripting support and examples online, and you seem to have a generally better experience.

BTW, if you don’t have experience with JavaScript, you can figure it out pretty quickly if you only want to do a couple tasks in it. It looks a lot like MEL/PHP with added object oriented stuff. PS also supports VBScript and AppleScript, but why paint yourself into a platform specific corner?

#5

Maybe I should just switch to Javascript, like you said.
Using the COM interface seems to be a lot harder than I initially thought.

I’m more of a design guy actually, but I want to get into the technical aspects, too.

#6

I do all my PS work in javascript. Less headaches, and the debugging is a lot nicer

#7

I find the scripting interface a general headache and hassle. No matter what language. e.g. writing code like this to create a layermask:


activelayer_createmask = function()
{
var idMk = charIDToTypeID( "Mk  " );
    var desc77 = new ActionDescriptor();
    var idNw = charIDToTypeID( "Nw  " );
    var idChnl = charIDToTypeID( "Chnl" );
    desc77.putClass( idNw, idChnl );
    var idAt = charIDToTypeID( "At  " );
        var ref49 = new ActionReference();
        var idChnl = charIDToTypeID( "Chnl" );
        var idChnl = charIDToTypeID( "Chnl" );
        var idMsk = charIDToTypeID( "Msk " );
        ref49.putEnumerated( idChnl, idChnl, idMsk );
    desc77.putReference( idAt, ref49 );
    var idUsng = charIDToTypeID( "Usng" );
    var idUsrM = charIDToTypeID( "UsrM" );
    var idRvlA = charIDToTypeID( "RvlA" );
    desc77.putEnumerated( idUsng, idUsrM, idRvlA );
executeAction( idMk, desc77, DialogModes.NO );
}

Really? I mean seriously? You can hardly write anything without using the listener to find the corresponding charID ActionReference Descriptor what-the-eff-ever sequences.

I am currently migrating quite a bit of our jsx code to python+COM mainly because these are automated parts to be run headless on renderslaves and the jsx experience wasn’t exactly pleasant in that context either.

Regards,
Thorsten

#8

You can do quite a bit without hitting the Action stuff. the masks is a good point, but other than that I havent really hit any walls. Any time i am force to use the action descriptor stuff, i just wrap it in a function and add variables so its easier to maintain and use.

What other walls are you hitting?

#9

[QUOTE=TheMaxx;19871]You can do quite a bit without hitting the Action stuff. the masks is a good point, but other than that I havent really hit any walls. Any time i am force to use the action descriptor stuff, i just wrap it in a function and add variables so its easier to maintain and use.

What other walls are you hitting?[/QUOTE]

Well am not that fond of JavaScript myself. Plus there is obviously no code-reuse with the rest of our pipeline.
In our full automation scenario we have been hitting quite a lot of things that cause dialogue boxes for example. As these do not go away it leads to the render job to stall till they timeout unless you remote on the maschine and click it away. Things like that seem to cause COM exceptions via COM which is way more desirable. It’s also pretty desirable to have more generalized classes to control PS to be able to use it in local automation with user interaction (e.g. publishing results from our production tracking tool etc.)

Having to use the listener to get a use-able and tweak-able preset instead of a proper API is really my biggest concern i guess.

Dear Adobe, we’re shoveling a LOT of money your way every year. Please be so kind: Stop ignoring the EXR spec and adding 3D and Video features no-one asked for and add some real-world production features for the DCC crowd :slight_smile:

Regards,
Thorsten

#10

sigh. Photoshop automation is so lame.

When time permits I want to look into the Python integration in Nuke & Mari to see if it might be possible to switch. Big $$$$ however :frowning:

#11

im in the same boat with mari. We only have 2 seats, but there are already a few requests coming in. Looks pretty cool and good python integration. Just not on the priority list unfortunately :frowning:

#12

Dialogs that interrupt script execution can be suppressed. In JavaScript:

app.displayDialogs = DialogModes.NO;

Check out the PhotoShop JavaScript Reference for details, page 45, or more generically check the Scripting Guide, page 33.

The application’s displayDialogs property is also accessible via COM – I think the integer equivalent of DialogModes.NO is 3.

#13

Yeah, but we still encounter them ever so often. Not for things intentionally popping up dialogues, but things like “The script is taking too long” kind of errors…brr. These just break via COM it seems which is more desirable in our case. I have not reached the state of doing a real life comparison. But alone being able to reuse the code is worth the COM hassle for me.