It seems to me that the recent PS update (24.6 - Beta) does not properly determine the layer kind of certain layers.
If the active layer in my document is a solid fill layer, then the expression
evaluates to “pixel” . In version 24.5 the answer is “solidFill” .
Use constants to compare this. Never text. Also for other things, if there’re constants available, use those
This is a known bug. My fix is already in review. This happens because the adjustment info property is not readable via batchplay. Which is another bug that should be also fixed.
adjustmentInfo in DOM API is still lacking, IMO. For example, it provides NO info on “neutral” points placed on a Curves adjustment layer. These are points placed on the curve, like a point at (128, 128) that don’t bend the curve but are still present on the curve. There’s no longer a method for devs to discover them that I can tell.
legacyContentData listed them, but that’s now gone in Ps Beta. It would be ideal if DOM API ‘adjsutmentInfo’ and batchPlay ‘adjustment’ array listed all points on the curve regardless of whether the curve gets bent or not.
How would it be helpful? What is the current difficulty?
@Jarda – I create a Curves adjustment layer using my UXP plugin which places specific neutral points on the composite Curve and on the Red, Green, and Blue channel curves. The plugin then looks for these neutral points with a UXP getter (currently looking at
legacyContentData) if the user selects a layer at some point further along in their workflow. If these neutral points are determined to be present, I know the layer is capable of interacting with my plugin, which specifically interacts with these points. If the plugin doesn’t find the neutral points, then my plugin ignores the layer and assumes it was a user-created Curves adjustment layer not intended to interact with my plugin. Without being able to assess these presence (or absence) of these neutral points, the only way for the plugin to determine if the layer is capable of interacting with my plugin is by layer name, but the user might want to change the layer name, and then the plugin won’t recognize the layer as being capable of interacting with my plugin going forward in their workflow. So, being able to evaluate the presence of neutral points on the various composite and color channel curves allows determining layer compatibility with my plugin independent of layer name or layer id. This has worked great with
legacyContentData. I’ve not been able to figure out an alternative layer property to use now that
legacyContentData has been removed from Ps Beta and have moved to using the layer’s
name for determining plugin compatability, but it’s not ideal and compromises usability since users won’t be free to change layer names like they were before.
Why not use layer metadata?
@Jarda–How do you conveniently set “layer metadata” and is it saved with the document?
This thread suggests that layer metadata is not saved with the image but only available during the Ps session: Adding custom properties or metadata to Layers?
This thread talks about saving layer info in document metadata but what a complex process to go through when the layer already knows the the information on the neutral points and users could easily get it comparatively easily using
legacyContentData: Document XMP metadata
I did NOT find a DOM API for accessing or writing layer metadata here: https://developer.adobe.com/photoshop/uxp/2022/ps_reference/classes/layer/
The point still exists, I think, that the addition of the
adjustment layer property doesn’t provide the level of data previously present in
legacyContenData, at least not that I can see if the neutral points on the curve aren’t accessible to developers. Why can’t we at least have parity with
legacyContenData? Also, why should we have to create metadata for something the layer already is keeping track of. In other words, why can’t these neutral points be exposed for developers to use?
Yes, I think it would not mind having those points available. I will ask whether this could be changed.
Regarding to best practice of tracking layers affected by plugin and storing its values…
I am not saying it is easy. I am suggesting it is a general and right way to solve this need because users can manually modify that curve in a way that would interfere with the functionality of your plugin. Or another plugin could modify that point too without understanding its meaning.
In the future, there should be some DOM way to do so.
I agree with @Jarda that using XMP metadata is not actually as complicated as people might think and ultimately gives you a lot of flexibility to attach custom data to a Photoshop file. Given that UXP is compliant with ES6 it’s straight forward to use 3rd party libraries, including one that allows XML encoding. Sure it will be very nice to have this as part of the DOM but it’s also not the end of the world to code this up…
@michael.u The core fix to the bug will be present in the next Beta release on 5/26.
Today I downloaded the actual beta and I can confirm that the bug is fixed.