Bug in PS 24.6 beta? Wrong LayerKind

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.

1 Like

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

This thread talks about another “complicated” way to set metadata that I’m not sure is even possible with vanilla javascript: Photoshop UXP plugin + XMPMetadata - #2 by simonhenke

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.

That snippet won’t work with vanilla javascript you need to add XML library.

In the future, there should be some DOM way to do so.

That would be great.

I think there’s a misunderstanding here. To clarify: XMP metadata (both document and layer) is persistent and stored with the file (as documented in the Photoshop file spec). However, random custom Javascript properties added to DOM objects are not automatically serialized. There’s a difference there.

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.