AddGrainC (now with Chroma noise & YUY2, RGB)

[Chainmax]

I see, thanks .

[zambelli]

Does anybody know how the size and strength and of the grain correlate to compression quantization? In other words, what size and strength of grain needs to be used in order for it to be preserved by H.264, VC-1 or MPEG-2 quantization?

[Sagittaire]

Originally Posted by zambelli

Does anybody know how the size and strength and of the grain correlate to compression quantization? In other words, what size and strength of grain needs to be used in order for it to be preserved by H.264, VC-1 or MPEG-2 quantization?

Well not simple because for example grain retention is not the same between AVC implementation. Anyway for all codec big grain size with low temporal complexity is alway more simple to compress. Small grain size with high temporal complexity is really hard to compress for all codec and particulary for AVC. In this case the better way to compress is degrain/regrain pre-process.

[Manao]

Zambelli : i advise you to make a gradient of noise (stacking grey videos with noises of different variances), and encode that in intra at different quantizer. You'll easily see the quantizer at which a noise of variance X disappear (or the variance needed for a noise to remain at quantizer Y). Do remember that in AVC, quantizers are exponential, so you don't need to test standard deviation 1,2,3,4,5,6....,n but rather 1.12^n (1.12^6 = 2 is the key factor behind AVC's quantization).

[McCauley]

Hi foxyshadis,

thanks for this nice little PlugIn.
Would it be possible to add the option to add a grain pattern that is constant for a specified amount of frames and then changes to the next pattern for the specified length and so on?
I basically want to use it for something like GrainOptimizer does.

Regards and thanks in advance
McCauley

[Adub]

Just use trim.

Ex.

source=avisource("example.avi)
a=source.trim(0.500).addgrainc(blah)
b=source.trim(501,1000).addgrainc(blah)
c=.....
a+b+c+....

[Didée]

More likely the aim is to change the noise pattern after only a few frames, ie. have like 2, 3, 4 or 5 frames with the same noise pattern, then switch to the next pattern, repeat, a.s.o.

x = 4   #  set the no. of frames with same noise pattern

clp   = last
grey  = BlankClip(clp,color_yuv=$808080)
noise = grey.AddGrainC(...)
noise = noise.changefps(framerate(clp)*x).trim(0,framecount(clp))

clp.mt_makediff(noise,U=3,V=3)  #  if it's only luma noise, use "U=2,V=2"

edit: "clip" => "clp", silly me.

[McCauley]

Thanks Didée, that's what i need for my purposes! As always you had a few simple lines that did the trick!
But since this should'nt be closely as fast as the same thing in AddgrainC, i would be happy too see it implemented directly in AddgrainC.

Regards
McCauley

[foxyshadis]

Test it, that shouldn't be noticeably slower unless you use timecodec. Since my computer was stolen last weekend, I won't be updating anything for a while, but the source is in the package.

[Leak]

Originally Posted by foxyshadis

Since my computer was stolen last weekend, [...]

o_O;;;

(Thank god my machine + radiator is so bulky they'd probably leave it behind; or should I fill it with concrete just to be sure?)

[Blue_MiSfit]

I'm wondering...

Why would one add chroma grain? I know it can be beneficial in certain cases or for artistic reasons to add luma grain, but chroma?

Just curious

Since my computer was stolen last weekend

NO! That's terrible I hope you didn't loose any vital data. Best of luck getting things back in order!

~MiSfit

[pitch.fr]

just FIY, this plugin creates mad memory leaks above 2 threads in MT via ffdshow.

problem doesn't exist in v1.0 and v1.1...they strictly obey SetMemoryMax()

too bad you said noisegen was improved in v1.3, but 1.5 Gb of memory leak on 4 threads is a tad too much

GrainFactory() works fine w/ any version

[swaaye]

Can someone post AddGrainC v1.4 somewhere? The link to foxyshadis site is down. Mad googling has only gotten me v1.3.

[J_Darnley]

It might not remain there but sure: http://users.telenet.be/darnley/avis...grainc_1.4.zip

[swaaye]

Originally Posted by J_Darnley

It might not remain there but sure: http://users.telenet.be/darnley/avis...grainc_1.4.zip

Thanks much

I put it up on megaupload too for anyone else in case your link dies
http://www.megaupload.com/?d=90EXJZGZ

[foxyshadis]

I finally reinstalled a build environment and built a fix for a memory bug that mainly rears its head with MT. Thanks to leeperry for bugging me to fix it a while back.

[leeperry]

yay, too awesome! I've been stuck w/ 1.1 since forever...what are the improvements exactly in the newer versions please? Could they make a noticeable difference in GrainFactory3()

1.2 2006/06/06 Foxyshadis Supports YUY2, RGB. Fix cache mess.
1.3 2006/06/10 Foxyshadis Crashfix, noisegen optimization
1.4 2006/08/11 Foxyshadis Constant replaces seed, seed repeatable

what does "noisegen optimization" mean exactly? a million!

[foxyshadis]

I believe that was from combining the two chroma noise planes into one, faster & less memory w/ no real difference. Wish I'd recognized the other major memory hog at the time.

I was also informed that this version won't run on Win2k, thanks to using VC 2010. Intentionally, since 2000 is out of support; I bet IanB's going to be hatin'. Damn it, Microsoft. Apparently there might be a way to patch it out, in the meantime cretindesalpes sent me a working fix built with 2005.

[leeperry]

oh, so it's mostly about speed improvements making compromises on PQ? coz somehow I prefer 1.1 over 1.4 in GrainF3() I think...but maybe it's placebo, I'll try again several times.

[foxyshadis]

The grain's the grain, I've never messed with how it gets created or combined with the frame. The only thing that I've ever changed is how it randomizes the per-frame, in order to support constant grain and defined grain even with random access, and enabling chroma (which is identical to luma in YV12) and RGB/YUY2 (which won't affect YV12 at all).

If you do prefer it, that might be because in 1.1, if a frame gets flushed out of cache it'll have a whole new randomized grainy image. I don't know how GrainF3 munges the image, but if it uses that fact, it will look different. It might be worth enlarging the possible grain size though.

The only thing pre-1.3 calculation would be good for is having different strength in the U and V planes... I can't think of any good reason why you would.