I still think the the easiest path here would be for BorisFX to package that regrain node as a separate plugin that you can bypass the Si user interface (since the node tree never really changes), and maybe at a cost less than the full Si app. They’ve done that before with their paint node.
This is much more likely to happen than ADSK building this node, nor does it make sense to expend all this dev time to create yet another implementation of it. We’re already used to a similar path with Neat.
If the cost of that degrain only OFX plugin is more akin to Neat rather than full Si, I think a lot of folks would be open to buying it.
Thoughts @FriendsFromBorisFX?
Silhouette 2023.0.4 was not widely released. It had one fix which was:
Multiple Instances of OFX Plug-in Did Not Release Memory
Memory was not releasing when using multiple instances of the Silhouette OFX plug-in.
The plan was to release this in the upcoming Silhouette 2023.5 release as it does not affect a lot of customers. Most Silhouette plug-in users don’t have lots of Silhouette instances. If you would like Silhouette 2023.0.4, you can download it from here: Silhouette 2023.0.4
As to whether we will release our Denoiser ML and/or Regrain as separate plug-ins, I am not sure. We are considering it. I know many of you classify Silhouette a plug-in, but it is really a standalone program which is also a plug-in. What you are asking is not unlike asking the Foundry or Autodesk to cherry pick a feature you like from Nuke or Flame and sell it as a plug-in. This requires more thought on our side. Thanks for your input!
Thanks Marco.
I had encountered the same issue with the memory leak, but then just switched to rendering them out instead of chasing it down like Alan did. Appreciate the link to version 4 in case it comes up again.
Re: the standalone plugin - completely understand the complexity. I think there are three groups of users to consider.
There’s the core audience of Si which use it to it’s fullest extent. I used to be in that camp years ago. Si is a fantastic app for many use cases. Those will use regrain natively.
There are the folks that have multiple apps, including Si, Nuke and/or Flame. They probably don’t have use for Si as a full compositor, but rely on some unique strengths of Si. These days I use it only for two things: paint and regrain. It’s still by far the best paint tool out there, and some jobs just need it. But for the core work I rely on Flame or Nuke depending on the nature of the work. As such this group has a full Si license and can use regrain in the way described here, though it’s a bit more involved as a repackaged node. Price is still pretty steep for just these two functions. For now I remain committed to Si (also because it’s part of the suite), but the landscape may evolve.
The last group are people who are only on Flame and do all their work there (Nuke doesn’t matter, because it already has grain management). These are the folks that might most benefit from a repackaged node, as they may not justify paying for a full Si license just for grain, but may for the node. How many there are? Well, this forum is an indication. It won’t be thousands, but it will be some really loyal fans…
Don’t forget Si also has Primatte which is still the best keyer available in Flame.
Right. But if I needed that type of keying power, I probably just work on the shot in Nuke, which then also has Keylight and a whole host of other tools.
But I can see the occasional scenario where everything is in Flame, and all you need is a quick excursion through Primatte.
Which btw when would make it a plugin within a plugin within a plugin. As I believe Si’s version of Primatte is really a function of all the Continuum nodes becoming available. Primatte has been in Resolve for quite a while thanks to Continuum. So becomes a question of how deep do you want to stack your plugins.
I would kill for a linux version of the BCC stuff. Our Avid editors will not give them up and do not want (?!?!) Sapphire instead. I’m so sick of close-but-not-perfect rebuilding of already-approved glitches and old film fx.
These are all good points. Continuum is already set up for plug-in units which are individual small collections of plug-ins. If it weren’t for Continuum not currently supporting Linux, this would be the obvious place to add the Densoiser ML and Regrain nodes from Silhouette. Continuum already sells Primatte separately. A Linux version of Continuum would be possible, but it would be limited to the BCC+ selection of filters. Obviously, there’s some technical issues on our side that would need to be addressed.
@marcopaolini I downloaded v4 today for a new project I’m on. It works as expected for the most part.
I did run into one problem, which could be related to the original bug. This project has 6 batch groups, each one of which needs regraining. I set it up in the first batch group, and then to be efficient just copied that node (Si OFX in Flame) into the next batch group to save time setting up all over again, as it’s more or less the same node tree. And since it’s similar footage, in theory even an analysis should carry over within reason.
But once I worked on the second regrain, everything came to a crawl, similar to v3. I ended up deleting the second node and restarting Flame. From there, I created new nodes for each batch and that worked fine.
Not a high priority, but may be worth looking into what happens when you copy a node and why it runs into trouble. Also would be nice to be able to copy nodes and save a repetitive step.
You can’t copy/paste/duplicate Si OFX. They know about this limitation and I think they are working on a fix for 2023.5.
OK, that’s what I thought… Should put a big red warning label on it. It’s a misery when you try…
I mean it’s nice though that they now save the project within Flame (same as Mocha). Earlier versions you had to create a file on disk, which was a PITA. I guess one step forward, waiting on the other.
Yup… although I believe once you use Paint or Stability you must then create an on-disk project.
Right, for Paint that makes sense.
Flame does all paint in real-time. Si actually maintains a bitmap per frame on disk as you paint. That’s what prevents the speed from degrading if you have mountains of pen strokes. Also why a rebuild takes a while after you delete something from paint history, as then they’re rebuilding this bitmap stroke by stroke. It’s a great solution, but does require a folder to store all this on.
We just fixed the the Silhouette project copy/paste issue and this will be included in Silhouette 2023.5. Sorry for the inconvenience.
@marcopaolini Found another small issue. If I should log this as a bug instead of piling onto this thread, let me know…
In my current project which has multiple batch groups, if I restart Flame and switch between the batchgroups, the Si/Regrain OFX doesn’t seem to refresh if I change anything upstream in the node graph, it shows me an outdated cached version.
If I click on the node, and in the OFX settings quick switch between ‘Output: composite’ to ‘Output: roto’ and then back, it properly refreshes and reflects the node tree again. This happens when switching between batch groups.
Looks like something needs a little push to remain current. This toggle appears to reload the project, as it goes to ‘project offline’ briefly while on the roto dropdown.
In this screen, if I change some color upstream, it’s properly reflected in the comp node at the bottom, but the Si node at the top remains stuck on something old. Once I toggle the Si node, everything works again.
Best thing for the devs is to screen record and narrate.
Silhouette is caching some of its results so doesn’t see the upstream change. This is not specific to Flame and happens in Nuke as well. We don’t think there’s a way to be notified if something upstream changed, but will check into if this is possible.
I see. That makes sense.
In the absence of being automatic, could the plugin have a ‘flush cache’ button instead? That would be more obvious and a single click rather than the project type toggle.
In looking back, this problem started because Flame was always asking Silhouette to purge the cache. This really slowed things down. We then enabled caching to avoid this performance issue. So, the proper thing to do would be to put it back to the correct behavior, but Flame will be slow. We can then pass this on to Autodesk to fix on their end. We can look at doing this for Silhouette 2024.
Not an easy problem.
But I think I rather have outdated/cached data than Flame being slow. One you can live with as long as you are aware, the other becomes are real drag.
I guess, there’s not really any good way of knowing when a meaningful change happened vs. not. Regrain typically sits at the very of node tree, just before render. It’s a typical habit to put a context view on the last node of the tree to see what the output will be, but in this case having the context on the Regrain is not representative, you need to put it on the node before the comp input of the Regrain. And, more importantly, before you render anything, you need to kick the Regrain node to update, otherwise your render it at risk of being stale, and that’s a major issue.
So short of ADSK devs having a better way of letting you know when to flush the cache in a more efficient manner, I do come back to a ‘flush cache’ button to keep it manual, but make it easier to do.
If I understand the problem correctly.
PS: I guess the other option would be to not cache, but for everyone while they’re working to disable the Regrain node to stop it from slowing everything down. So you only have it enabled when you set it up, and when you do renders, but not otherwise. The visual feedback will be obvious in the node tree.