@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.
Please leave feedback for these new capabilities in this forum.
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.
IMO it would be a much better to store pixels like:
[[R1, G1, B1], [R2, G2, B2], [R3, G3, B3]]
[[R1, R2, R3], [G1, G2, G3], [B1, B2, B3]]
Would be much easier to parse pixel by pixel or channel by channel
From the docs I don’t understand how to use
PhotoshopImageData In the example:
const pixelData = await imageObj.imageData.getData()
Edit: Oh, you get it with any other getter of Imaging API and
imageData is there. IMHO this should be mentioned in
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.
Thank you for contributing.
Slightly related, encode and save to PNG, JPEG, etc. 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 those, as in 10ms versus 5000ms.
There are the renditions API (in XD) but I believe that you may have to create a layer or scenenode first and then access it.
Note: I see there’s encodeImageData method for JPEG. It looks like it returns a base64 string.
textItem showing up as undefined. When I access a text layer with the following:
let layer = utls.getLayerByID(layerID);
utls.showAlert(layer.name + ': "' + layer.textItem.contents + '"');
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.
same for me, although docs say available in 24.1