AcademySoftwareFoundation
ImageEffect instances should have a unique identifier
Stubbing this for now, but the short of it:
It would be very useful for the host to give an effect instance some sort of unique identifier (probably an actual UUID string) that can be used to seed "unique to this instance" behavior, such as seeding a random number generator. This identifier shouldn't be copied if the user copies the plugin to another shot, for example. That would have its own new unique identifier. The identifier should persist between project loads/unloads, and not change if a plugin instance is deleted and then undo-deleted, for example.
I think some folks will ask: "What defines a unique instance of an effect?". My answer is that you define it however it's defined to your end-users. Most hosts probably have a concrete answer for this and I would imagine it's all pretty similar, but please do make edge and corner cases known!
~~EDIT: Now that I've thought a little bit more about it, I think it would be also very useful for clips to have unique identifiers. You could theoretically have two different plugins coordinate their random seed by using the source clip's unique identifier (if specified by the user as a choice parameter, for example).~~
So to try to pin down the language you mean each "instance" of the OFX effect that the user can see in their project/timeline/graph/etc is given (by the host) a unique ID, and this ID is set as a property in every OFX plugin effect instance created by/from/for that "instance" (and there could be many of these, especially in a host which uses ephemeral render instances).
So to try to pin down the language you mean each "instance" of the OFX effect that the user can see in their project/timeline/graph/etc is given (by the host) a unique ID, and this ID is set as a property in every OFX plugin effect instance created by/from/for that "instance" (and there could be many of these, especially in a host which uses ephemeral render instances).
Yes!
My take is render instances for the same user-applied instance would all have the same ID. If it's used as a seed, then it would need to be consistent across render instances.
On Tue, Jun 17, 2025, 4:58 AM Phil Barrett @.***> wrote:
barretpj left a comment (AcademySoftwareFoundation/openfx#203) https://github.com/AcademySoftwareFoundation/openfx/issues/203#issuecomment-2979726149
So to try to pin down the language you mean each "instance" of the OFX effect that the user can see in their project/timeline/graph/etc is given (by the host) a unique ID, and this ID is set as a property in every OFX plugin effect instance created by/from/for that "instance" (and there could be many of these, especially in a host which uses ephemeral render instances).
— Reply to this email directly, view it on GitHub https://github.com/AcademySoftwareFoundation/openfx/issues/203#issuecomment-2979726149, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM64AX4ZDN5RKJP5437WNT3D7RC5AVCNFSM6AAAAAB7OISYDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNZZG4ZDMMJUHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
My take is render instances for the same user-applied instance would all have the same ID. If it's used as a seed, then it would need to be consistent across render instances.
I believe that is what @barretpj is saying!
I think it would also be useful for clips to also have their own unique identifier. Imagine a world in which two different plugins could coordinate their randomness (as a user option, perhaps) by creating a seed from the source clip unique id (identical across different plugins) + the time provided by the host.
Ok yeah I originally read it wrong. This will be trivial for me to add to Silhouette- just need the property name. I assume it would just be on the Effect handle, and not passed as an argument.
On Tue, Jun 17, 2025, 8:23 AM Greg Cotten @.***> wrote:
gregcotten left a comment (AcademySoftwareFoundation/openfx#203) https://github.com/AcademySoftwareFoundation/openfx/issues/203#issuecomment-2980373676
My take is render instances for the same user-applied instance would all have the same ID. If it's used as a seed, then it would need to be consistent across render instances.
I believe that is what @barretpj https://github.com/barretpj is saying!
— Reply to this email directly, view it on GitHub https://github.com/AcademySoftwareFoundation/openfx/issues/203#issuecomment-2980373676, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAM64AQGFYGECVQFJSDSEBD3EAJERAVCNFSM6AAAAAB7OISYDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSOBQGM3TGNRXGY . You are receiving this because you commented.Message ID: @.***>
I'm not sure your proposed Clip UID is viable. We already have kOfxImagePropUniqueIdentifier, how is this different?
I'm not sure your proposed Clip UID is viable. We already have
kOfxImagePropUniqueIdentifier, how is this different?
If you need temporally coherent randomness in your render you cannot seed your RNG based on an Image UID. With a Clip UID (or Effect UID) you seed off of that UID and then you can use the time property to be temporally coherent across the Clip or Effect instance respectively.
I'd settle for just an Effect UID and can update my PR accordingly if you think the Clip UID won't work. Or we can narrow the scope of the Clip UID property to only support Source clips if you think that would help.
If you need temporally coherent randomness in your render you cannot seed your RNG based on an Image UID. With a Clip UID (or Effect UID) you seed off of that UID and then you can use the time property to be temporally coherent across the Clip or Effect instance respectively.
Are you talking about applying different plugin operators at adjacent points to the same upstream clip, and using a clip UID to make them coherent?
I'd settle for just an Effect UID and can update my PR accordingly if you think the Clip UID won't work. Or we can narrow the scope of the Clip UID property to only support Source clips if you think that would help.
Unclear what you mean by "only support Source clips" - in the General context there are no rules about what your plugin names its inputs - see https://openfx.readthedocs.io/en/main/Reference/ofxImageEffectContexts.html
Are you talking about applying different plugin operators at adjacent points to the same upstream clip, and using a clip UID to make them coherent?
Yes, that is the primary scenario I think. Imagine a scenario where the effect needs to pick a random (normalized coordinate) starting point (at time == 0, or something) to draw a circle and then smoothly animate the circle along a (deterministically) random vector field. You would use the UID to seed the starting point and the vector field and modulate it with the time property.
Unclear what you mean by "only support Source clips"
I guess what I mean is a host is free to simply omit the UID of an any clip it's unable to generate a UID for (I could adjust comments in the PR accordingly). I would expect a host to be able to define a clip UID for any clip the host has complete ownership of (original source media or generated media by the host, etc.). This is what I meant by "Source clip" - I should have written "Source media" to differentiate from the OpenFX clip name concept and the general concept of source media.
The plugin could of course fall back to the effect UID if the clip UID doesn't exist or isn't available, and then fall back even further to some user-supplied seed.
Again, happy to remove the clip UID if we think it's not really viable.
It's a lot harder to define, and a lot harder to implement, I'd say. A standards change generally needs a plug-in and a host vendor to both implement the feature before it can be accepted.
@gregcotten - maybe most reliable for you would be just to create an hidden parameter and during create instance just set a random int and set that parameter?
Pierre
@gregcotten - maybe most reliable for you would be just to create an hidden parameter and during create instance just set a random int and set that parameter?
Pierre
Unfortunately not really - there are two problems with that.
-
When "copying" a plugin's parameters to another operator slot (like a node in Resolve), that identical seed will get copied with it (bad)
-
Setting during create instance has host-specific caveats and sometimes outright doesn't work, so I'd rather not rely on that.
ok @barretpj, I've amended my PR to only add kOfxImageEffectPropUniqueIdentifier
This will be in Silhouette 2025.0.1 which should be out in the next week or so.
@gregcotten Could you test this using @fxtech 's latest host? If it's good, we can merge it!
