If I understand correctly, the only way to save custom calculated values ​​for use in parameters is to calculate them in Wrangle and save them in a small layer, then read the pixel value where needed.
But this doesn't work for me, and I'm not sure if it's a bug or if I'm doing something wrong.

1) Create a constant with a test color different from 0 and 1, for example, purple.
2) Create an sdfshape and enter an expression for reading the first pixel into the radius. We should get the radius based on our pixel value, right?

The search shows several functions :
1) pic/picni. I enter picni("../constant1", 0, 0, D_CLUM) - and it returns 0. I tried the spare parameter, absolute paths, and all kinds of color types - everything is still zero.
2) volumeindex/volumesample - the result is also 0. The VEX volumeindex function works fine in Wrangle, but not in hscript.
Could someone in the know please tell me if I'm mistaken or if these functions don't work at all in Copernicus? Or is there another way to pass expressions from Wrangle to another node's parameter?

Largely, the answer here is no. If a parameter depends on pixel values and is set by an expression it means we can't keep the computation on the gpu, so have to bounce back to the cpu. Historically this results in networks that are impossible to then make gpu friendly, so we consciously did not make it easy to do this.

We're not happy with the current state as we want to drive these things ourselves, so are looking for ways to enable it properly in the future

But what can you do today?

pic expression is the old cops only, but I see our docs didn't say that. I've added a note to that effect.

volumesample must point to a sop, not a cop.

So the current complicated work around is to use a sop net in cops. Dive into that and put down a copnet sop and set it to fetch an external cop. Point to the cop you want to read. This gives you a volume. Now back at the original cop level you can write a volumesample expression that points to the copnet node inside the sopnet.

Note that this will be a break point in graph evaluation, we'll not be able to compile through this, so it won't work in blocks, and there may be performance issues as it bounces through the CPU. But if there is a will, there is a way...

Thanks for the clarification and solution, jlait!
Frankly, I (like most users) am not too concerned about graph breakpoints; a simple mechanism for parameter management is much more important.
I think we spend infinitely more time battling with complex options for simple calculations than a fast graph would save us, and it's not worth it. Time is precious.

I think it would be very productive if you implemented more user-friendly solutions for parametric parameter management in Copernicus.

For now, I'll use sop, as you suggested. In principle, I can simply store detail attributes there.

Yeah, detail attributes with a detail() expression is probably the easiest approach for now.

You can also technically use the HOM API to do this

Just out of curiosity, what are the attributes created by the "layer attribute create" node? The help says they're for usd. But that looks like the equivalent of detail attributes. Why not write attributes with a Wrangler name or something there and then read them in a parameter? And all this is inside Copernicus.

The attributes are probably most similar to "primitive" attributes, but Copernicus has one-wire-per-primitive so they also look like detail attributes.

They are for whatever extra non-image meta data you may need to attach. USD in particular uses them to store the output file name to ensure things are saved in the proper location.

The File COP will also fill out all the extra data from .exr here, so you can get stuff like cryptomatte manifests, etc, in it.

Having a wrangle to update them does seem like a good idea.

jlait
Having a wrangle to update them does seem like a good idea.

Honestly, I was also initially targeting these layer attributes, but it turns out there's no information on how to read them. There's no information in the node help. No neural network knows either. The Detail/prim() functions return zero. Could you tell me how to read them in hscript or VEX?

Gaalvk

jlait
Having a wrangle to update them does seem like a good idea.

Honestly, I was also initially targeting these layer attributes, but it turns out there's no information on how to read them. There's no information in the node help. No neural network knows either. The Detail/prim() functions return zero. Could you tell me how to read them in hscript or VEX?

You can use python to read them. hou.ImageLayer.attributes() will give you a dictionary with all of them.