The impeccable 4K exr add-noise workflow?

I wanna add perfect noise on the touched/CGI area in a comp, so I suggested 3 workflows:

Idea A: was to denoise using various patterns on the hight-lights/shadows/midtones areas of the plate, then comp with the denoised result, and add the noise using the difference between the denoised plate and the original one using add.
I didn’t like the result as the result doesn’t look like the original plate, with so many flat aeas.

Idea B: should not mess with the original plate, but use the difference mentioned above to noise only the CGI/touched area, but I am not also convinced especially if you add different tones from the original plate-like more dark added areas or so.

Idea C: That I don’t know how to do it in Flame precisely, is to analyze the original noise on the plate and apply it using another node (or not) on the altered area

Which one is your favorite?

  1. Denoise the plate using Neat Video
  2. Subtract the Denoised clip from the camera original.
  3. Do your comp.
  4. Add the result from step 2 to your comp.
  5. Compare the result of step 4 to the camera original. If its identical, good job. If it isn’t, swap the inputs on Step 2. Then, good job.

Please note that whilst this may be the perfect way to add camera original grain, if your cg has different luminance values relative to the background plate or the converse is true, then, you’ll need to manually add grain using the Regrain or Crok.


Gotchya, in your 5 steps solution, I was using difference not subtract, my bad, it works great.
Yes I was wondering if the CGI has different luminance contents, then I have to regrain manually.
Why can’t we use the analysed data from denoise to use them to noise something else? Why there is a denoise option that you can turn off inside the same node?

1 Like

Yup. Likely I’d regrain manually. Grain rarely is the same for all levels of luminance. But it’s worth a shot sometimes. And it’s a go to setup for a lot of cleanup.

1 Like

Convert the plate and comp to log and regrain. It solves most of the luma issues.

More specifically:

Convert both the plate and neat video pass to log (I usually use LogC, but any log is fine) and subtract the Neat from the plate.

Do the whole comp normally in linear from the Neat pass (not the Log one)

When the comp is done, convert it to log and add the subtracted plate then convert the result back to linear.


Also be aware that a divide and then multiply approach might work better in some cases than add and subtract in terms of grain theft. I’m unsure of why this is (I’m sure someone knows) but we had a project a few months ago where for some reason or another the subtract add method was giving very slight artifacts visible in the difference matte (set to a high gain) and the divide multiply method was 100% clean. I’ll add though, that in my experience most all of the time the subtract add gives a better result than the divide multiply.

1 Like

For any regraining, I tend to switch to log. If I’m manually doing it with the regrain node and curves especially. The grain sampling tool in flame seems to not work whatsoever in linear, doesn’t matter what color space it’s set to.


Perfect Chris, yes I tend not to mess around with the whole frame, and try to focus on my area of comp that is localized easily through mattes or alphas.
I will try your tips
Many thanks

1 Like


Use DasGrain

he said something about nuke again bring out the torches

No but seriously, dasGrain is such a killer thing, I wish adsk would just copy it into a node, I just cant be bothered manually grain matching when there is a tool out there that just does it for you, perfectly.


dasGrain is magic, its so good, ive used it on hollywood movies, netflix series and whatever else and it held up all the QC, i havent even noticed anything weird on venice or other cameras because… it just solves it.


jup see my previous post, its nuke only :frowning:

Is there a feasture request for a automatic regrain node from adsk? :melting_face:

You can see the dasGrain code so it should be possible to rework that for flame?

Ill have a look later for a FR - dasGrain isnt even AI or anything crazy fancy, you input denoised plate, plate and the comp, have it analyze a bunch of frames and boom it regrains the comp for you. No crazy trickery, no custom numpy or anything it just works with default nuke nodes and some python trickery afaik.

It might be possible to connect to it via Pybox. I’d have to take a look at DasGrain and see what’s what.

It’ll slow down the comp considerably…like to the point we here you’d want to pre render everything in flame upstream from the Pybox.

1 Like

my current workflow is kinda dumb, so yea i was also thinking of pybox,

I usually do my comp for dailies with a stupid regrain setup in flame then when everything is final i export , open in nuke, run dasGrain and import that back into flame so … ugh not fast at all.

I’ll take a peek at it. I’ll hit you up for a demo of DasGrain in Nuke.

I think this one is the closest. The last comment is mine, referencing you talking about DasGrain with the note “this is exactly what we want”


I’m glad to hear I’m not the only one using multiple regrain nodes to match to Venice footage! I was a little bit ashamed- like, “this can’t possibly be the way to do this but I can’t see any other way manually to match this wacky grain.”

1 Like

Hey Finn, I’m no Nuke gizmo expert, but is it possible to see all the nodes under the hood in DasGrain? I thought you could to that- like basically explode it all out like a group in flame? Or maybe that was a dream…

yes you can cmd shift G or something (edit->node ->group → ungroup. (on top or my head

you can also copy paste the node into a text editor and see the underlying code.


I think last time we looked at this with ivar the result was we couldnt do it with matchbox due to some limitations, I dont see why something like openFX (is there any ofx wirh mutliple RGB inputs??) shouldnt work. there are some blinkscript shaders involved but those are just voronoi scatters and stuff.

Really not a dev, but porting this to openFX sounds like the most sane plan.

1 Like