@samgannaway has updated the Photoshop documentation with the following:
The Imaging API … will enable UXP plugins/scripts to get and set pixel data into directly into layers and masks (and even selections in a way). We are considering these functions to be properly “beta” in that we are hoping to receive feedback before we cement them. In fact, access to them is via an “imaging_beta” property to drive home the point:
TextItem is a regular DOM update. However, this update goes far beyond what was possible in ExtendScript. I won’t list all the properties here because the number is large.
Great to see. There are two comments in the documentation:
First off, all Imaging API methods that return pixels are asynchronous. This is needed because modifying and even querying pixel data may incur disk I/O.
Converting image data between different color spaces or color profiles is somewhat time consuming.
The docs say the API is run async meaning other code can run while this occurs in the background.
Will there be a way to get the progress of the calls? That way we can inform users that progress is happening and how far along it is.
It’s super exciting to see UXP develop beyond ExtendScript’s capabilities!
One suggestion that I have is to consider support for putting raw pixel data, i.e. support for image data without color profile. That would require PhotoshopImageData to represent such a state. This would support the use-case in which Photoshop’s color management is disabled (via Edit > Assign Profile). This is actually pretty common in environments where ICC profiles are not widely used anymore in the pipeline (notably VFX pipelines relying on OpenColorIO).
Another minor point is the use of the term “color space” to refer to RGB, Grayscale, Lab etc. I would argue that this should rather be “color model” (in the GUI actually referred to as color mode). (i.e. sRGB or Linear RGB are both color spaces for the RGB color model). I know this sounds like a nit-picky note and the two terms are sometimes (unfortunately) used interchangeably in literature, but since this API is brand new there’s a chance here to do it right and future proof
To everyone that has posted here so far (and in the future):
Your comments are exactly why we released this in Beta+(Beta). We will be collecting all the comments here and elsewhere to further the discussion and development of this feature.
Slightly related, can you add in the features to encode and save to PNG, JPEG, etc.
Why? There are JS libraries that take pixel data and create a PNG but in some cases native support may offer orders of magnitude performance improvements over library support, as in 10ms versus 5000ms. So having native support for this would make a huge difference.
Note: I now see there’s encodeImageData method for JPEG. It looks like it returns a base64 string. This is great. Add to the wish list a PNG support.
layer.name works fine, but layer.textItem shows up in the debugger as “undefined.” And in the debugger, if I plow down into the properties, textItem doesn’t show up at all, which is consistent with undefined.
I’m trying the “imaging -test” plugin, I noticed that on pc the execution is very slow. I tried the desaturation function, on two different PCs and on a Mac. there is a noticeable performance difference, it is about 10-15 times slower on pc. i think there is a bug.
Very late comment on this thread, but I’ve just noticed that the imaging API page does not have any flags on the Photoshop version from which each call is available.
In the example:
Pinging