Simulation of Depth of field blurring

[PeaceAnt]

hello,

here's my function. it performs blur according to brightness of pixels in second clip. it's good point to start with it to simulate depth of field i think.

a = imagesource("source.psd").converttorgb32.flipvertical
b = imagesource("blurmap.psd").converttorgb32.flipvertical

function GHRCompoundBlur(clip a, clip b){

a1 = a.blur(1)
a2 = a.bilinearresize(576,400).gaussResize(720,576,p=10)
a3 = a.bilinearresize(360,288).gaussResize(720,576,p=10)

a
layer(a1.mask(b.levels(63,1,127,0,255)))
layer(a2.mask(b.levels(128,1,191,0,255)))
layer(a3.mask(b.levels(192,1,255,0,255)))
}

GHRCompoundBlur(a,b)

http://img88.imageshack.us/img88/2360/cblurcopyxz4.jpg

pozdrawiam

[Sagekilla]

Your function has some issues. If you give it an input that's not 720x576, it borks immediately. You should have it get the height and width from your input clip and use that as your final scaling:

function GHRCompoundBlur(clip a, clip b){
width = a.Width()
height = b.Height()

a1 = a.blur(1)
a2 = a.bilinearresize(576,400).gaussResize(width, height,p=10)
a3 = a.bilinearresize(360,288).gaussResize(width, height,p=10)

a
layer(a1.mask(b.levels(63,1,127,0,255)))
layer(a2.mask(b.levels(128,1,191,0,255)))
layer(a3.mask(b.levels(192,1,255,0,255)))
}


Also, where do the downscale of BilinearResize(576,400) and BilinearResize(360,288) come from? The second one sounds like you're just halving the resolution. The first one doesn't seem to make any logical sense though. I did a very quick test of your function (fixed somewhat, to work more universally) and it seems to work well, but what purpose does the various values of each Levels() serve? They seem to be arbitrarily picked, too.

[*.mp4 guy]

He is simulating bluring with interpolation, most likely for speed. The sizes determine the amount (radius) of the blur.

[Sagekilla]

In that case, he should be using constants for each resize instead of a fixed size. Better yet, including a parameter to specify the "strength" of blurring.

Edit: To prevent sounding like a raving lunatic, I meant that he should be modifying the source frame's size by some constant (or variable) to get the blurring.

[vcmohan]

It looks that the function blurs as stated. But the result has not given any depth perception to my eyes. May be a more suitable input can be given as example.

[PeaceAnt]

especially for Sagekilla: :D
function GHRCompoundBlur(clip a, clip b, int "lvl1", int "lvl2"){
width = a.Width()
height = a.Height()
l1 = Default(lvl1, 85)
l2 = Default(lvl2, 170)

a
reduceby2
a1 = last.gaussResize(width, height,p=10)
reduceby2
a2 = last.gaussResize(width, height,p=10)
reduceby2
a3 = last.gaussResize(width, height,p=10)

a
layer(a1.mask(b.levels(0,1,l1-1,0,255)))
layer(a2.mask(b.levels(l1,1,l2,0,255)))
layer(a3.mask(b.levels(l2+1,1, 255,0,255)))
}

a = imagesource("source.psd").converttorgb32.flipvertical
b = imagesource("blurmap.psd").converttorgb32.flipvertical
GHRCompoundBlur(a,b,60,180)

very shallow depth of field
http://img224.imageshack.us/img224/3627/dof2bnd8.jpg
http://img78.imageshack.us/img78/2299/dof1yv9.jpg

originals:
http://www.spot3d.com/vray/help/150SP1/images/examples/vrayphysicalcamera/02_camLOW_f8_ss60_iso200_zoom1.png
http://www.spot3d.com/vray/help/150SP1/images/examples/vrayphysicalcamera/05_camIN_vigneg.png

pozdrawiam

[2Bdecided]

I think this is one of those cases where you really need to blur in the linear domain, rather than the sRGB domain.

http://mysite.verizon.net/spitzak/conversion/blur.html
from here:
http://mysite.verizon.net/spitzak/conversion/index.html

This is about the same issue wrt resizing:
http://www.4p8.com/eric.brasseur/gamma.html

This is where we discussed it here before:
http://forum.doom9.org/showthread.php?t=134192

Hope this helps.

Cheers,
David.

[Vitos]

2Bdecided, that's very interesting information... I was not aware of such issues - thanks!

[Sagekilla]

@2BDecided: I agree, processing in the linear domain really would be best. Unfortunately as the discussion in the that thread points out, it's hard to convert from a 2.2 <--> 1.0 mapping without introducing some error because of lack of precision (8 bits :(). I could imagine you can try doing something like:

Pseudo code:
Take source image
Convert to copy with linear mapping
Apply blurs to both copy and source
Convert copy back to 2.2 mapping
Smooth copy a little bit
Merge the copy and source image


It might work, it might not. It's an idea though ;)

[LaTo]

I made this one some times ago for a game clip:

function DOF(clip c, int "Mthr", int "Srad", int "Trad") {
Mthr=default(Mthr,256)
Srad=default(Srad,16)
Trad=default(Trad,4)
x=c.width()
y=c.height()

mask = c.mt_lutspa(relative=true,expr="x 1 2 / - abs y 1 2 / - abs + "+string(Mthr)+" *",chroma="128")
blur = Srad!=0 ? c.bicubicresize(round(x/(4*Srad))*4,round(y/(4*Srad))*4).bicubicresize(x,y,1,0) : c
blur = Trad!=0 ? blur.TemporalSoften(Trad,8,8,24,2) : blur

return mt_merge(c,blur,mask,luma=true,chroma="process") }

Really simple but maybe someone will be interested...

[PeaceAnt]

http://members.lycos.co.uk/grasshopper/dof/dof_CHB1.jpg
http://members.lycos.co.uk/grasshopper/dof/dof_CHB2.jpg

this two pics are blurred with my newest plugin. does it look better? ;)

pozdrawiam

[Sagekilla]

Worse IMO, it looks like it has black bleeding into the edges. I don't know if it was because of the way you used levels or because of the resizing method, but it looks worse with those black bleeding in.

[PeaceAnt]

yes, it has black bleeding into the edges. but it's not a point. the plugin i used is very simple yet http://forum.doom9.org/showpost.php?p=1220183&postcount=59
it performs real variable radius blur instead of blending blurred plains. it should look better if you look closely.

pozdrawiam

edit:
i fixed that problem :D how do you like this now?

[2Bdecided]

@2BDecided: I agree, processing in the linear domain really would be best. Unfortunately as the discussion in the that thread points out, it's hard to convert from a 2.2 <--> 1.0 mapping without introducing some error because of lack of precision (8 bits :().This is true, but if someone is going to write a variable blur plug-in from scratch (e.g. in C), then it makes sense to use, say, 16-bit linear internally.

This site...
http://mysite.verizon.net/spitzak/conversion/index.html
...explains a nice conversion (^2, rather than ^2.2, but it's close enough).

If variable blur remains a script, then the next best thing would be to "hack" whichever AVIsynth blur you use to drop log>lin at the start and lin>log at the end - making the part in between 16-bit if possible.

(I talk as one who can't program, so it's all easy for me!)

Cheers,
David.