New shader: cinematic depth of field

altokitty wrote: I believe I stressed it quite often too, heh. I quite disliked how it did defocusing in general, especially the odd "painting" effect and the weird haloing that occurs, and then this shader popped up!

Well, the DoF you refer as to the "ENB one" is also from me. I've never seen a single complaint about the highlight system of my DoF so I wasn't aware people dislike it - I write shaders like I prefer them, after all, painterly look is intended. Now I could defend my DoF and discuss why I think which one's better but instead of that, let me ask what my DoF could do to get back on top in your eyes? From what I read, you're quite in love with the highlighting of this one. What else? I can't do much more about performance on my DoF without reintroducing artifacts like this one has but surely about featureset. Just to be clear - which DoF of mine did you compare to this one? The one from the official github repo, or qUINT, or ... ?

Marty McFly wrote: Well, the DoF you refer as to the "ENB one" is also from me. ... Just to be clear - which DoF of mine did you compare to this one? The one from the official github repo, or qUINT, or ... ?

Oh, really? Well, uh, I wasn't using the "stock ENB" DoF shader to compare, I had kingeric1992's ENB DOF extra & ALF effect installed. Unless you go by a different name I'm not aware of, I don't think I was running your shader? It's this one, to link again: enbseries.enbdev.com/forum/viewtopic.php?f=7&t=3224

If it is by you, though, don't worry too much about the highlight system! I was just being over-exacting, I do like some stylisation to things at times and the shader's worked wonders in older screenshots. I did purposely exaggerate the aperture in my examples to further my points since I was mainly looking at luminosity defocusing, otherwise with more average settings it looks perfectly fine. Do note that the shader used is fairly old though, turns out I downloaded the wrong .fx and I'm using the version from 13/12/2014. So maybe things have changed since then.

I may have thrown in a jab at your qUINT DoF, though. I could compare the two in the same style that I did above, however I feel I'd rather not throw you and Otis into the ring. There's a matter of personal preference that plays strongly here, so I'd rather not get into it too. (plus, haven't played with it as much as I have with Cinematic DoF, so it'd be quite unfair.)

Marty McFly wrote: Now I could defend my DoF and discuss why I think which one's better but instead of that, let me ask what my DoF could do to get back on top in your eyes?

Didn't know this was a competition? There's no number 1 spot.

You know what annoys me a bit? That you don't make it healthy discussion. I mean: you don't debate inner workings of the shader, perhaps I did some things you didn't think of, or made some mistakes you recognized etc. Nope, none of that. (Edit: you did comment on the gaussian blur, I give you that, however that pass is 0.3ms tops so not a main contributor to the performance of the shader)

From day one not a single positive word from you. Rather strange, though. I mean I did read all the papers, including the last one from UE 4.20's dof where they use a different tile based approach for near plane bleed than Jimenez uses, and which is even better than Jimenez' approach (and better than what I have now) (See: advances.realtimerendering.com/s2018/index.htm , scroll down to "A Life of a Bokeh"). Perhaps a discussion about how to implement that properly, which could also benefit your dof shader, but nope. Which is a shame really, as neither of us have managed to implement a decent near plane bleed variant. Mine works but I'm not that happy with it, as it can be better, even though we lack the ability to use compute shaders.

It feels like it is as if you are so afraid someone's here to take your spot. As if there's even such a thing. In my experience that's not the way to go. FTR, I really don't care if people use for 99% your stuff and for 1% my stuff, or that there's a top spot and I'm not on it. I wrote this shader mainly for myself as a fun project and to have a shader that works like I want it to work for my own shots and shared it as others might like it too.

From what I read, you're quite in love with the highlighting of this one. What else? I can't do much more about performance on my DoF without reintroducing artifacts like this one has

Again, you seem to need to bash my shader as if it personally did something to you. What artifacts does it have? Undersampling? Yours has those artifacts too (they all do), but they're easily mitigated with changing settings, just like with yours. I don't really see why you feel the need to go this route?

Well, the DoF you refer as to the "ENB one" is also from me.

I found this remark a curious one. No idea you wrote Eric's shader... (which at places seems to be borrowed from other code as well. )

Well, I was actively trying to avoid what you call a healthy discussion because personally, I feel like showing off when I tell someone "this is a problem and this and this, you can optimize that". If you do want that feedback, sure. I appreciate tips and ideas but quite often I see release posts of a thing and the first reply is an array of what's wrong about it and what could be improved. Seems like we both have a very different opinion about this. When I asked about the focusing code (which means I like it, hidden compliment there) you went all copyright when that code is itself a derivative of various papers (which you credited) and I could easily restructure it a bit and just refer to those docs. Eric's focusing is also a derivative of those papers and both look strikingly similar. After that proverbal middlefinger for a few lines of code I wasn't really that eager to help improve this one. Then I found that problem on DX9 and actively searched why it happens, if I were thinking this DoF was crap I couldn't care less.

As matsilagi probably can confirm, I've been working for ages on this "A life of a bokeh" to be honest and I've somewhat succeeded in implementing their base approach but something is still not right, guess I need to write something of my own there. Tried a lot of new approaches the last months but none of them did really work out.

In the first post you made statements that your DoF is faster than the qUINT one, so apparently you see my DoF as the measurement for yours. And at least from my tests, the statement is just not true so I was a tiny bit pissed since no one would really validate this and just take it for granted. I'm spending a crazy amount of time to polish my shaders so I'm protective of them and take a stab at them personal, apparently just like you. And when I bash your DoF for having artifacts, it does have ones mine doesn't and I don't talk about undersampling, can take screenshots if wanted. You conclude in your code that there's no perfect bleeding solution when you most likely checked my code and yes, there is. Kind of a high horse saying "I tried and failed hence its impossible". And yes, there is #1 spot or a competition, if you will: we're trying to cut down the amount of shaders on the official repo. Makes little sense to have 5 effects that all do the same. Right now, my old DoF is the standard one and will soon be replaced with qUINT one. I don't want users to miss out on features - hence I aim to surpass all alternatives.

I understand your stance about all this but if you try to see things my way, you come off as a bit of a jerk hence my lashing out. Not saying you are one and it's difficult to judge character based on sparse online activities, but that's what I get from what I read. Apparently I strike you as a jerk, too, when actively trying not to.

Seems like I was mistaken about the ENB DoF, it was just so similar looking on the screenshots that I assumed it was mine and since Eric's DoF is DX9 only, it's only used on Skyrim LE so most newer enb configs use mine now. I didn't follow the entire discussion here so I apparently missed that.

In case you prefer to sort this out privately, I suggest we chat on Discord or similar, the forums really are a bad place for this and I derailed this thread more than I wanted.

Marty McFly wrote: Well, I was actively trying to avoid what you call a healthy discussion because personally, I feel like showing off when I tell someone "this is a problem and this and this, you can optimize that". If you do want that feedback, sure. I appreciate tips and ideas but quite often I see release posts of a thing and the first reply is an array of what's wrong about it and what could be improved. Seems like we both have a very different opinion about this.

If I was a seasoned shader dev it might be annoying if someone comes in and points at a legion of issues, but as I'm not (this is my first big shader), any help is welcome as that's how one learns.

When I asked about the focusing code (which means I like it, hidden compliment there) you went all copyright when that code is itself a derivative of various papers (which you credited) and I could easily restructure it a bit and just refer to those docs. Eric's focusing is also a derivative of those papers and both look strikingly similar. After that proverbal middlefinger for a few lines of code I wasn't really that eager to help improve this one.

That's fair, but my remarks have a context: I release my work under the BSD2 (or MIT if you will) license which is very friendly, however I've been bitten by people misusing that in the past (to great lengths even), hence my formal stance in that regard. I don't see how that's silly in any way. You don't release your shader under CC for nothing: you want it to be enforced as well, so why am I not allowed to ask you to respect the license I used? It's not giving a middlefinger, it's simply asking to respect a license. I don't know how long you're doing OSS, but changes are if you're doing it long enough you will run into cases where your code ends up in stuff where the license it was released under isn't respected. It is in most cases totally innocent stuff, but that's not important. The code borrowing project might get forked/copied again and the original author (you) is lost. Nothing personal.

Sure the focusing code isn't that hard, however it's not that straightforward either. Many papers describe focusing code which look all the same but aren't. Eric's code was helpful to get me understanding the things a bit but isn't the same. For one his units are different and his formulas too (I based mine on a scatter-based dof paper even as that one had the right units which worked with the reshade depth buffer. As I wrote this first and misunderstood a LOT about shaders/buffers etc., it was the most helpful paper around for this. Looking back now I understand things better, I could have borrowed code from others, but where's the fun in that?)

As matsilagi probably can confirm, I've been working for ages on this "A life of a bokeh" to be honest and I've somewhat succeeded in implementing their base approach but something is still not right, guess I need to write something of my own there. Tried a lot of new approaches the last months but none of them did really work out.

If you haven't already, you can register as a dev for the Unreal Engine and look into the code of the DiaphragmDOF shaders (it's a lot) on github. perhaps that tells you what you're missing. Frankly I think they both (Jimenez in the CoD paper/presentation and this one) omit essential details. Like: I get why the maxCOC per tile is used in near plane to blur all pixels of a tile with that. Then it has to be blended with the in-focus pixels. The alpha needed for that is in Jimenez based on a formula that's vaguely given but contains parameters that aren't specified. In the UE paper they don't give it. If I look at the blurred near-plane COC area I have, I can use that as alpha for the results of the blurred tiles and get smooth edges. (I have to test this still but I think this will work). Jimenez calculates this alpha on-the-fly from the pixels included from the near plane during blurring of a pixel, not sure what's more accurate, but I'm sure doing it real-time is a hell of a lot faster than doing a 2pass gaussian

In the first post you made statements that your DoF is faster than the qUINT one, so apparently you see my DoF as the measurement for yours. And at least from my tests, the statement is just not true so I was a tiny bit pissed since no one would really validate this and just take it for granted. I'm spending a crazy amount of time to polish my shaders so I'm protective of them and take a stab at them personal, apparently just like you.

The measurements I did were off, I also explained that later on in the thread. With low-ring count yours is faster, (which isn't weird, I do twice the amount of passes! )

I think measuring the perf of both can be very tricky, as mine is a bit more constant in performance (hovers ~6-8ms @1080p now) and yours (if I recall correctly!) can differ more in performance depending on the scene (so lots of out-of-focus elements make things go slower). It was likely due to that that mine looked faster, as I explained above in an earlier post. But whatever the performance, it's not really a big deal tbh. My shader wasn't written to be the fastest, as the sole goal of it was to look great and be 'reasonably quick'.

And when I bash your DoF for having artifacts, it does have ones mine doesn't and I don't talk about undersampling, can take screenshots if wanted. You conclude in your code that there's no perfect bleeding solution when you most likely checked my code and yes, there is. Kind of a high horse saying "I tried and failed hence its impossible".

See, this is what I was referring at. Why this hostile bullshit? Does my shader bleed in-focus pixels? It might, dunno. In general I don't see bleeding (and I take a lot of screenshots) but it might have a bug somewhere. You could have reported it as such but instead you went this way. It might be good to remind you this was my first big shader, it's likely I made mistakes. What I did do as well was try *everything* (in my ability as a shader dev) to avoid leaking. The code I have now worked best for this shader afaik.

But what is your point really? Or did you just want to tell me your code works and mine doesn't and therefore you're the better coder?

And yes, there is #1 spot or a competition, if you will: we're trying to cut down the amount of shaders on the official repo. Makes little sense to have 5 effects that all do the same. Right now, my old DoF is the standard one and will soon be replaced with qUINT one. I don't want users to miss out on features - hence I aim to surpass all alternatives.

Erm, since when do you control what's in the shader repo of reshade? Crosire merged my shader, so I don't know what plans you have but apparently he thought it was a good idea to add the shader to the repo. If you or him don't want it in the repo, just fucking say that and I'll store it elsewhere. Last thing I want is this kind of bullshit just because you have the feeling you 'lost your #1 spot'.

So @Crosire, wtf is this: is my shader going to be cut? If so, tell me so I can host it elsewhere and leave the stage to Marty here so he can be safe of his #1 spot... But if it has to go, all my other shaders I've contributed will go too.

I understand your stance about all this but if you try to see things my way, you come off as a bit of a jerk hence my lashing out. Not saying you are one and it's difficult to judge character based on sparse online activities, but that's what I get from what I read. Apparently I strike you as a jerk, too, when actively trying not to.

Apparently.

The reason for my CC license is so that I have the control over where it ends up. I have no problem with people I know using my code, even without copyright notice or anything like that. If I follow that BSD/MIT license thoroughly, I basically need to paste a huge copyright notice into my shader for about 20 lines of code. I give you that, you can't read my mind how I handle my licensing and it's surely a non-standard way of doing it but if someone asked me if he can borrow a small part of my stuff, I'd just give it to him. But yes, I cannot expect everyone to do that. Btw: I'm anything but a seasoned shader dev - I'm still learning and much younger than you, if that profile picture is you.

About the diaphragm DoF, I did sign up for Epic Games and tbh, the DoF is a huge clusterfuck. Tons of files, a lot of data abstracted behind CPU side code that needs to be hunted down tediously and at various places mixed with Jimenez DoF code so it's often hard to find out what code belongs to which mode and also they don't follow their own paper at various places. Unfortunately I have no clue about UE4 so I can't set up a testing scene to actually profile the DoF and not rely on a few presentation images.

I don't control what's inside the github repo, but me, crosire and CeeJay have a skype chat, and we talked about reducing redundancy - to which degree this will be done, can't say, I'm not the one doing it. But for example crosire replaced my YACA chromatic aberration with SweetFX's CA shader some while ago so I'm used to have my content cut - hence I'm obviously super anxious about my DoF.

I get the feeling you understood that part as if I wanted to kick your stuff out there or want this area for me alone - not at all. Currently I'm not even hosting my shaders in the official repo so there's not even a competition since my old DoF shader (and the ported other ones) are crap. Me thinks most of this discussion stems from both of us interpreting each other's words in the most negative way. The post that kicked all of this off was mostly to find out in which disciplines my DoF is inferior and how I can do something about that - I have a very competitive mindset and understood most of your comments or replies as to be very hostile, hence I reacted what I thought to be appropriately.

But seriously, there's no reason to escalate this by making it look like I need a safe spot at #1 or try to let crosire loose on me or to pin this on me. I already helped with the DoF here, even if you disregarded it. You took stabs against my work first, if you intended to or not, it reads that way - I got the attention of this thread by someone sending me it along with "hey, there's someone trash talking about your DoF". Twisting my words isn't that nice of a trick as well, I specifically said "we" are trying to cut down the amount of shaders - never said I am in control and obviously ("we"), crosire has a word in this as well. If that was on purpose, then quit that. If not, ignore that last paragraph.

---

To move this to a more reasonable discussion, let me show you what I think can be improved:

-You're doing sincos for every coordinate of the shape. If you scatter dots on a circle, it's better to compute a 2x2 matrix that rotates one point to the next, so you only get a matrix mul in place of trigonometry. iquilezles has a blog post about that.
-The way the masking works, you need to sample additional textures and overall, the shader uses a ton of textures - is that really necessary? I know you've adapted some papers but most DoF's are ALU bound nowadays.
-A lot of micro optimizations. Systemically, most of it looks quite okay but on various places code can be restructured to compile shorter. I'd suggest you try FX composer or something similar to check the ASM of the shader and move stuff around to see what changes. You probably won't think this makes much of a difference but Persson mentions that you can get 2x the speed out of any code if you do it right. Most of my code is straightforward but I do this microoptimizing excessively. CeeJay's code is a good reference for that, he's much better at finding optimizations than I am.

-The artifacts I was speaking about: You forgot to apply the same amount of highlight blending on the center tap, so if you try to maximize blur and reduce quality a lot and look at a starry sky, the center tap is significantly darker than the others.
-There's a strange blending between sharp and blurred areas so the DoF is more like a haze over everything, this gets less with raising quality though. The areas completely out of focus are fine though.

-Your gaussian blur isn't depth masked, hence it bleeds (check those pointy things on the upper right against the sky):

Thanks for the reply and change of tone I'll reply more in depth later, no time now.

Guys, guys, please don't argue! Argh, knew it wasn't a good idea to bring up a comparison. I'll apologise myself for ultimately being the one who started the derailing of this thread.

I know it's not my place to make this demand, especially since I'm new to posting on this forum, but wouldn't it be better if you guys put aside the differences and worked together? Otis' made his advances, Marty's made his advances, wouldn't it just be great if we could see them put together to create the perfect DoF shader? Both of you have done amazing work and I'd really hate to see either option get occluded or even just cut out by the other. Please, at least help each other out and be open to said help, it really isn't that pretty to see two minds like this butting heads.

To try to bring it back to topic, I had more fun tweaking with highlight gain and threshold (as well as properly configuring the shader) and, well, I think it looks pretty damn good.


I found highlight gain that high (your recommended 300-400) to be a bit too excessive, and the threshold to be a bit too low, this screenshot has them set at 250 & 0.9 respectively. I feel like the bokeh can be better, though. The lack of aberration around the edges makes highlighted bokeh look too "soft", and bokeh bias doesn't really fix that.

Also, you've probably already seen it, but the SIGGRAPH 2015 Making Your Bokeh Fascinating course by Masaki Kawase is a gorgeous showcase of various realistic bokeh types. Just a few more cents into the pile I've been stacking.

OtisInf wrote: Didn't know this was a competition? There's no number 1 spot.

Seriously? Way to make things awkward, man...

@altokitty: No worries, a heated discussion sometimes solves stuff faster than a calm one and everything is spoken out.
About the "Making your Bokeh look fascinating", I made a shadertoy to generate the pencil map:

www.shadertoy.com/view/XlccWN

It was one of the DoF experiments I spent my time on. Original plan was to upgrade my DoF with that, then I somehow made a DoF that can create huge ass discs with little overhead but it's impossible to mask properly. Then I wanted to make near blur bleed properly which lead me to the UE4 DoF, where I ultimately failed... will probably write something entirely from scratch.

Marty McFly wrote: (Licensing stuff)

All understandable, and I was like that too, till a large OSS project of mine ended up as a commercial app in China, and it then made me realise I have to be more protective of the license involved. It's the basis of re-usage and I see it as a base for understanding under what terms things are re-used, which is a strictly, for the lack of a better word, business affair: you use X, you respect X's license, if not, don't use X. This is something every software dev should understand and follow and also have no hard feelings about when a license is e.g. too restrictive (so you can't use X) or asked to be respected.

But yes, I cannot expect everyone to do that. Btw: I'm anything but a seasoned shader dev - I'm still learning and much younger than you, if that profile picture is you.

Yes, I'm pretty old For what's worth: take it from me, a person who has seen the wrong end of the license crap more than once, don't be too naive in this. You wrote some code and another person wants to use it? Credits where credits due. The CC license you picked was a wise choice.

About the diaphragm DoF, I did sign up for Epic Games and tbh, the DoF is a huge clusterfuck. Tons of files, a lot of data abstracted behind CPU side code that needs to be hunted down tediously and at various places mixed with Jimenez DoF code so it's often hard to find out what code belongs to which mode and also they don't follow their own paper at various places. Unfortunately I have no clue about UE4 so I can't set up a testing scene to actually profile the DoF and not rely on a few presentation images.

Yeah I have the same feeling. Their shaders are written in an intermediate language btw, which is then processed to a single shader (in the target language of choice), based on input flags, as far as I understand. But pretty obscure indeed. Their 'accumulator' stuff is too CPU oriented for being shader code, no idea how that ends up in HLSL (or GLSL). It's also full of commented out code which clearly resembles 'let's try this, see if this fixes anything'. They do have a sample app / assets (which they used in the presentation as well), but haven't tried it yet (as it likely requires me to compile the engine from source). the UE4 demos (executables, e.g. available through guru3d) don't contain this shader sadly.

I don't control what's inside the github repo, but me, crosire and CeeJay have a skype chat, and we talked about reducing redundancy - to which degree this will be done, can't say, I'm not the one doing it. But for example crosire replaced my YACA chromatic aberration with SweetFX's CA shader some while ago so I'm used to have my content cut - hence I'm obviously super anxious about my DoF.

I understand the urge to cut redundant stuff (some people pull all shaders which makes compiling them each time a slow affair) tho a lot of people use e.g. multiple dofs at the same time (e.g. matso's with the directional stretching of bokeh and a normal dof on top of that). Having just 1 in the repo is therefore IMHO not the way to go.

I get the feeling you understood that part as if I wanted to kick your stuff out there or want this area for me alone - not at all. Currently I'm not even hosting my shaders in the official repo so there's not even a competition since my old DoF shader (and the ported other ones) are crap. Me thinks most of this discussion stems from both of us interpreting each other's words in the most negative way. The post that kicked all of this off was mostly to find out in which disciplines my DoF is inferior and how I can do something about that - I have a very competitive mindset and understood most of your comments or replies as to be very hostile, hence I reacted what I thought to be appropriately.

Hmm, no my intention hasn't been to be hostile at all. I think I tried to avoid any bashing in this thread? I just re-read my opening post and the only reference to your shader is the performance remark, which I have corrected later on. I deliberately wanted to avoid ANY references to features etc. of other shaders, left alone remarks about quality of other shaders and have worded my post accordingly. I'm surprised it was seen as such, to be honest. FTR I don't think any dof is inferior to the other, they have different use cases, one works better here, the other better there (e.g. yours has features mine doesn't, which is by design, like CA, noise, different bokeh shapes).

You took stabs against my work first, if you intended to or not, it reads that way - I got the attention of this thread by someone sending me it along with "hey, there's someone trash talking about your DoF".

This is something I still want to address, as I find this rather odd, tbh. I say "Performance is on par with qUINT ADOF, often faster (9 passes, 6 rings)." which is honestly what I measured at the time, but as said, with improper configured setups. If that's 'trashtalking' or taking stabs at someone's work, then I apparently miss something.

You're not your code. You can take pride in your work, everyone does, but in the end, you're not your code. If someone says something about your code, be it a bug, performance issue, lack of a feature etc., that's about the code, not you. This is difficult, but trust me, life's easier when you see it like that.

---

To move this to a more reasonable discussion, let me show you what I think can be improved:

-You're doing sincos for every coordinate of the shape. If you scatter dots on a circle, it's better to compute a 2x2 matrix that rotates one point to the next, so you only get a matrix mul in place of trigonometry. iquilezles has a blog post about that.

Ok, sounds fair. What I actually want is pre-calc the values and store them in a buffer, but I think you can't have buffers in reshade other than textures, correct? Writing them to a texture is likely too slow for a lookup. I still think the performance is mainly hogged by the massive # of texturelookups, so not sure the sincos removal will give much. Thing is, I don't have a setup where I can profile per-pass (reshade only gives overall perf in ms per technique, not per pass). So it's all guesswork from my part where things are slow, which I hate but I can't find the right tooling or get it working (Nvidia's tooling didn't work with the app I used for testing). Will retry with the UE4 demo app and the latest drivers, perhaps something wasn't installed properly there.

-The way the masking works, you need to sample additional textures and overall, the shader uses a ton of textures - is that really necessary? I know you've adapted some papers but most DoF's are ALU bound nowadays.

I use full-res textures mainly to avoid a recombine phase, as I frankly don't know how to do that I know lerping between backbuffer and blurred buffer won't work (soussa) so I haven't found a reliable recombine algorithm I could base my code on. From what I've seen of big engine DoFs, they likely use tiling to avoid lots of texture look ups (frostbyte, cryengine, UE4), and that requires a lot of work to mitigate the side effects of using tiles, which might run into ALU bounds. Most slides of the UE4.20 presentation also are about that. As we can't do compute shaders in reshade (at least to my knowledge) I did everything in pixelshaders without tiles to avoid the work to mitigate their side-effects. It's my plan to take another stab at this tho, as I now more understand how things work than when I began on this project

-A lot of micro optimizations. Systemically, most of it looks quite okay but on various places code can be restructured to compile shorter. I'd suggest you try FX composer or something similar to check the ASM of the shader and move stuff around to see what changes. You probably won't think this makes much of a difference but Persson mentions that you can get 2x the speed out of any code if you do it right. Most of my code is straightforward but I do this microoptimizing excessively. CeeJay's code is a good reference for that, he's much better at finding optimizations than I am.

I tried to get FX Composer but failed, that's the amd tooling right? I'll see if I can still find it as it seems to be discontinued. (So no profiler/debugger used)

-The artifacts I was speaking about: You forgot to apply the same amount of highlight blending on the center tap, so if you try to maximize blur and reduce quality a lot and look at a starry sky, the center tap is significantly darker than the others.

yes, that's indeed something stupid I want to correct. It's odd tho, as it indeed doesn't occur always, which is also weird. But this is indeed something that's to be corrected.

-There's a strange blending between sharp and blurred areas so the DoF is more like a haze over everything, this gets less with raising quality though. The areas completely out of focus are fine though.

What quality setting did you use? I start at 5 but mostly use 6 if possible. I think it's due to undersampling but not sure. The shader doesn't have a 'full in-focus' area, everything is always 'out of focus' but close to the focus plane you don't see it as the CoC is too small. With hair slightly out of focus it indeed gives less of a stellar result and haven't found a way to work around this, other than apply a gaussian blur afterwards which made things look 'ok'.

-Your gaussian blur isn't depth masked, hence it bleeds (check those pointy things on the upper right against the sky):

Yes true and I really should mask it indeed.

Thanks for the feedback

altokitty wrote: (No need for apologies indeed)
To try to bring it back to topic, I had more fun tweaking with highlight gain and threshold (as well as properly configuring the shader) and, well, I think it looks pretty damn good.

Glad you got things more up to par to your liking

I feel like the bokeh can be better, though. The lack of aberration around the edges makes highlighted bokeh look too "soft", and bokeh bias doesn't really fix that. Also, you've probably already seen it, but the SIGGRAPH 2015 Making Your Bokeh Fascinating course by Masaki Kawase is a gorgeous showcase of various realistic bokeh types

It's not bokeh with sharp edges most of the time indeed. CA and bokeh shapes are a bit of an odd thing really, if you ask me Photographers tend to get rid of CA and bokeh with sharp blade edges most of the time as they're both a sign of a cheap lens (although there's a group who deliberately moves in the other direction and uses the bokeh shapes to their advantage), and that was my initial goal as well: as if you had the best lens, so CA and bokeh shapes weren't really on the list of things I wanted to add: why have high quality bokeh and ruin it with cheap-lens effects? (like edge distortion as well) If I have time I'll look into it, but for now I think it's on the backlog so don't hold your breath for these features, sorry Thanks for the feedback tho

Photographers tend to get rid of CA and bokeh with sharp blade edges most of the time as they're both a sign of a cheap lens (although there's a group who deliberately moves in the other direction and uses the bokeh shapes to their advantage), and that was my initial goal as well: as if you had the best lens, so CA and bokeh shapes weren't really on the list of things I wanted to add: why have high quality bokeh and ruin it with cheap-lens effects?

Oh, I might not have known that. I guess I'm too used to seeing things through cheap lenses. But at the end of the day, things like these have got to be subjective. Everyone prefers different things. Like I enjoy abusing film grain in my ReShade presets when you know that's a sign of bad film, and people seem to love effects like bloom, CA, vignettes, lens flares, all these known to be marks of a bad lens yet they're massively popular in post-processing effects. Guess the point I'm trying to make is that nothing's perfect, so it'd be nice to see some of these "defects" in the future, y'know?

As a side note I'd like to bring up since you seem to have studied lenses in photography quite in-depth for this, what is bokeh bias? I can't seem to find many real-world instances of it, I just get pointed to bunch of render engines' "physical camera" documentations if not other depth of field shaders. also, wouldn't bokeh bias be a sign of a bad lens too? hehe just sayin'

If I have time I'll look into it, but for now I think it's on the backlog so don't hold your breath for these features, sorry

If you don't mind me asking, what's on the list of things to come? Implementing Marty's suggestions, optimisation in general? Just curious.

could someone package this DOF shader into Reshade ?

altokitty wrote:

Photographers tend to get rid of CA and bokeh with sharp blade edges most of the time as they're both a sign of a cheap lens (although there's a group who deliberately moves in the other direction and uses the bokeh shapes to their advantage), and that was my initial goal as well: as if you had the best lens, so CA and bokeh shapes weren't really on the list of things I wanted to add: why have high quality bokeh and ruin it with cheap-lens effects?

Oh, I might not have known that. I guess I'm too used to seeing things through cheap lenses. But at the end of the day, things like these have got to be subjective. Everyone prefers different things. Like I enjoy abusing film grain in my ReShade presets when you know that's a sign of bad film, and people seem to love effects like bloom, CA, vignettes, lens flares, all these known to be marks of a bad lens yet they're massively popular in post-processing effects. Guess the point I'm trying to make is that nothing's perfect, so it'd be nice to see some of these "defects" in the future, y'know?

CA is an effect I think not many screenshotters like at all and I always wonder why it's in many post-processing pipelines. E.g. not many, if any at all, tv series or movies use as much CA (or any at all) but in games its excessive sometimes, ruining the overall image quality to a high degree. Effects that are available through other shaders (e.g. vignette) really should be applied through those shaders I think. With CA, I doubt it will ever make it into this shader, simply because I truly hate the effect But alas, if I have nothing better to do and people want it, perhaps... it's not high on the list of things to add.

As a side note I'd like to bring up since you seem to have studied lenses in photography quite in-depth for this, what is bokeh bias? I can't seem to find many real-world instances of it, I just get pointed to bunch of render engines' "physical camera" documentations if not other depth of field shaders. also, wouldn't bokeh bias be a sign of a bad lens too? hehe just sayin'

Bokeh bias in the shader means highlights are more profound at the edge of the bokeh circle, which in itself sounds odd, but it can be used to create 'busy bokeh'. See for instance this blogpost by Wronski, the dof developer of the witcher 2 and Farcry4: bartwronski.com/2014/04/07/bokeh-depth-o...going-insane-part-1/ . He also describes exactly how I feel too about bokeh and lenses. So to get there, you use a very small highlight and a small bias, just enough to get slightly visible rings. Some lenses have this kind of bokeh effect while others give a more gaussian result. Some prefer the former others prefer the latter. I don't have a real preference, it depends on the situation, hence I added it. So 'bias' here is typical for shaders, I don't think it's a term used by photographers :) (I'm just an amateur photographer btw)

If I have time I'll look into it, but for now I think it's on the backlog so don't hold your breath for these features, sorry

If you don't mind me asking, what's on the list of things to come? Implementing Marty's suggestions, optimisation in general? Just curious.

First of all a better near plane bleed, which requires likely a lot of code, and indeed some of the artifacts solved. The near plane bleed is 'ok' for now, but it can be better, and I have some ideas how to do it, so I'll try these out first.

@kinjx11: It's already part of the official shader collection, goes by CinematicDOF.fx.

@OtisInf:
Yeah, personally I'm not too big of a fan of CA either. In very very very subtle amounts it works to gorgeous effect, but otherwise the whole trend of "saturate the scene with CA!!!" is really dumb, in my opinion. There's a different kind of aberration that's what I meant by harder edges, it's spherical aberration like this:

The subtle more intense ring that forms around each bokeh circle. Though you've said (and I've found out) it's an artifact of poor lenses so... ¯\_(ツ)_/¯
I still do think the regular bokeh is perhaps a little too soft? Maybe I just have the post-blur smoothing a bit too high, but I personally find the bokeh to be really soft at the edges.

As for bokeh biasing, it's apparently known as "doughnut bokeh" in photography, caused by mirror lenses. It results in a very hollow centre though, unlike the digital kinds where it's more of a linear gradient. There's also such a thing as positive bokeh bias where the inside of the bokeh circle becomes more opaque rather than transparent, which is an even odder effect that I'm personally really not a fan of. I'd like to link www.bhphotovideo.com/explora/photography.../understanding-bokeh as a really comprehensive article on bokeh types in the real world, just as some extra reference.

I hope I'm not sounding too demanding with all this talk about "additional effects", by the way. I wholly understand this is ultimately your work and I respect your freedom to do whatever you want with it. It's just, y'know, it'd be really nice to see some Additional Pizzazz added in the future.

I think I may have some revised comments on the highlight system, now that I'm more well-read, but I definitely have to play with it a lot more first. Plus, I should probably give you a break from all this discussion. Best of luck with the near-plane bleed stuff, I guess we'll see who can beat who at implementing that stunning system described in that UE SIGGRAPH presentation (or an alternative!).

Have near plane bleed now pretty much sorted out:

Have optimized it to do less reads in near plane. This shot (with far plane blur set to 0, but for perf that doesn't matter, with blur it's the same ) is ~7.3ms @1200p Still not the performance I want, but 'acceptable' for now and what's to be expected I guess for using full-res buffers for far plane. Will work on some other issues reported as well, then do a PR.

@altokitty: thanks for the feedback
If the bokeh highlight is too soft, it might indeed be the post blur smoothing. If you set that to 0 it appears sharper? But to be honest, you likely won't get sharp bokeh edges in my shader, due to the nature of how it calculates highlights. The approach Marty uses is more usable for that.

Thanks for the info on the bokeh terminology and types, interesting!

PR: github.com/crosire/reshade-shaders/pull/107

- Much better near-plane bleed
- Corrected an issue with the post-gaussian blur bleeding near focus pixels
- Optimized things across the board
- Corrected near-plane highlight bleed.
- Corrected comments, removed reference of info no longer used.

5 rings gives good quality now, near and far plane blurred pixels in-frame with narrow depth-of-field now hovers around 5.5ms @ 1200p.

Enjoy!

(edit) Merged.

Hello hello! It's me again, played with the revised near-plane bleed stuff and I gotta say it works really nice.

There are a few things I'd like to raise (as usual) though, I find the shader has quite a few issues with defocusing very thin objects as well as some other bleed issues. I think this screenshot captures them quite nicely:


There's three main planes of focus here, the anguished goblin in the immediate foreground, the arrow just behind him and the second in-focus goblin. For the most part, the defocusing looks great! The near-plane bleed works beautifully, until the left part of the image. The first issue, very harsh aliasing occurs on the arrow even though it's slightly defocused. I've noticed that near-plane bleed into far-plane (especially into infinity i.e. skyboxes) causes this issue quite often, it doesn't occur with near-plane bleed into focus-plane.

The second issue is the way near-plane blur is handled, I guess. It's a very subtle yet noticeable effect, where near-plane looks like it samples from the far-plane in order to blur, which causes any far-plane details caught in the near-plane defocus to get blurred as well. You can see it happen in the same screenshot, here's a few of the area's magnified:

Apologies for the poor image quality, used Steam's screen capture for these and DD:DA doesn't support hotsampling.
First column is the boundary from the arrow to the helmet, near-with-near basically. The arrow's blur sorta merges with the helmet's blur and creates this odd boundary where the arrow's "triangulated" and there's a cone that forms from the arrow to the helmet.
The second and third columns are examples of near-on-focus-plane. The areas in focus have high detail, so it's obvious when they become blurred. You should be able to tell that where near and focus-plane meet, focus-plane details such as the belt and the scales are blurred as if part of the near-plane. There's also almost a distinct boundary where near-plane blur ends, you can sorta 'trace' the blurred near-plane in the second and third columns.
I'm not entirely sure if this issue can be resolved, since I know it's pretty hard to do so without sampling some aspect of the background, but I just thought I'd raise it up.

There's one more issue with far-plane bleed I've noticed too. This foliage shot should very clearly capture it:

...I doubt I need to point it out. This shouldn't be a depth-buffer issue, ReShade's able to read alpha textures in this game just fine and I've had it occur with solid geometry too (I believe that goblin example from a while ago should be one).
In case this is me being a dumb-dumb and not configuring things right again, the blur settings for all the screenshots here were FP Max = 2.5, NP Max = 1.25, Blur Quality = 6.0, Post-Blur = 0.1. No comments about performance, since I pretty much only use DoF in stills and never gameplay.

Hope I'm not sounding fussy here, I really do appreciate your efforts and overall I really think it looks great, definite improvement over the last (which had way more issues than just these). I just thought I'd bring up a few things I've noticed.

About the AA: no idea. It might be the slight blur on the arrow might cause the AA applied on the arrow to get ruined, showing the actual pixels again. (Hence engines apply AA after DoF) In reshade the dof is applied after the AA which I think could lead to these artifacts. I have no other explanation.

Issue 2, that's indeed something that's not really solvable. It does bleed background into the foreground to create the blurred outline so it looks soft. In theory the best way to do this is to blur the area behind the object, but those pixels aren't known, so this background reconstruction is faked by pulling pixels from the background area around the object which are hoped to look the same. It sometimes looks a tad odd at places, but it's not something I can solve.

3rd issue, you mean the white outlines? It's a bit hard to see: the dark areas inside the white outlines are leafs or holes? If you click on 'show debug' it should reveal the leafs beings darker than the background around them. I have seen this sometimes indeed which is something that could be solved by a different approach to the dof (by sorting the elements, applying them from back to front with an alpha, but the algorithm is described incompletely by Jimenez so it has to wait till I figure it out). It occurs in my dof and not in e.g. the dof.fx in reshade as the CoC value per pixel differs more over a deeper range in my shader than in the dof.fx in reshade (which due to its focusing code often results in a screen with more or less the same CoCs for the background. This isn't bad at all, CoCs differ only slightly the further away from the camera, it's just a thing I noticed when I displayed the CoC values in that shader). If the CoCs differ over a deeper range, blur ranges of 2 pixels next to each other can differ then as well, leading to the visibility of edges. I haven't seen it often tho, but it can happen.

It's either that, or your highlighting is rather high and it highlights the pixels around a leaf that's in front of it. (which is logical as the leaf isn't bright)

(edit) I tried to reproduce the 3rd issue, and I can, if I have a high aperture (e.g. 4-5 or higher) and high farplane blur max blur. Lowering the aperture and with it the farplane blur solves it, which effectively means the background all get more or less the same CoC values (if you enable sshowdebuginfo you'll see it's now e.g. a completely grey or white area). With a high aperture the CoCs have different values which could lead to artifacts in small areas, which you can smooth over with the post smoothing factor but that's a bit of a stopgap.

What really should be done (but isn't done at the moment) is from back to front, blending all CoCs into a single value but as said, I currently miss an important info element, but eventually I'll get there If you want to know the details, it's the algo described here: www.iryoku.com/next-generation-post-proc...uty-advanced-warfare (see powerpoint at the end).

So to remedy it, try to keep the farplane blur first at 1, and toy with either the lens length (making it longer) or the aperture (make it lower) to get the blur you want.