Port of Painterly shader from nvidia Ansel
- NattyDread
- Topic Author
It's sort of a mix of surface blur and Kuwahara shader.
It's located in \AppData\Local\Temp\NvCamera\_binaries\Painterly.yaml\Painterly.acef
Please Log in or Create an account to join the conversation.
- OtisInf
It's funny, the painterly shader isn't in source shipped with ansel, all others are. Perhaps because Kyprianidis' work is licensed under the GPL? (He does ship the shader code on google code, which is defunct now, but you can still reach it.). The OpenGL shader is dogslow however (and opengl) so they re-implemented it, which to my knowledge doesn't violate GPL at all, but at least give the man credit. Ah big corporations eh?
Please Log in or Create an account to join the conversation.
- NattyDread
- Topic Author
I could never get KuwaharaAnisotropic to look this good:
This is the closest I could get:
Please Log in or Create an account to join the conversation.
- OtisInf
Check this app, see for yourself code.google.com/archive/p/gpuakf/downloads
Please Log in or Create an account to join the conversation.
- Marty McFly
I don't think NVIDIA would be happy if someone found a way into the shaders and ported them to ReShade, so either use Anisotropic Kuwahara on ReShade or Painterly using NVIDIA's tool. Is there a specific reason you want Painterly on ReShade when you can use it just fine using FreeStyle / Ansel?
Please Log in or Create an account to join the conversation.
- Martigen
Reshade always works, though
Please Log in or Create an account to join the conversation.
- brussell
Please Log in or Create an account to join the conversation.
- OtisInf
Interesting, considering Jan Eric's paper discusses all known ones (albeit at the time of writing, which is several years ago). The algorithm you're using isn't in that paper, I recon? (I think Simplify or whatever the name of the photoshop plugin is also uses an algo that's not in the paper).Marty McFly wrote: You can certainly try to optimize Anisotropic Kuwahara to be as fast as Painterly, but I doubt this is possible. Albeit visually similar, they are different in a lot of ways. Kuwahara grows areas with similar colors like a dissolving watercolor painting, but it's not the only way of doing this.
All shaders (except this one) are in source on disk, you can edit them and when you start an ansel powered game you get the edited version. so finding a way into the shaders is quite easy. I just found it interesting this particular one isn't in source on disk, that's allI don't think NVIDIA would be happy if someone found a way into the shaders and ported them to ReShade, so either use Anisotropic Kuwahara on ReShade or Painterly using NVIDIA's tool. Is there a specific reason you want Painterly on ReShade when you can use it just fine using FreeStyle / Ansel?
If it's not anisotropic kuwahara as you say, then I've said nothing.
Please Log in or Create an account to join the conversation.
- Marty McFly
I don't know about Photoshop filter mechanics but since they have a wide array of filters, one can see there's an infinite amount of ways to screw up the image in an artistic manner.
As you mentioned, Jan Eric's paper is from 2009 and when you compare any graphical advancement from this time with newest developments, obviously they fall short. If the performance of OG anisotropic Kuwahara is as bad as it is today, I wonder how it performed on 2009 tech
Biggest problem of Kuwahara is that it's not separable so complexity is always some O(n^2) which isn't very good, especially since you can't post blur like you would with DoF. Anisotropic Kuwahara makes matters worse by being not cache efficient since kernel is depending on underlying surface detail. The approach I used doesn't suffer from these problems (still O(n^2) though).
Please Log in or Create an account to join the conversation.
- NattyDread
- Topic Author
Incompatible in terms of opening ReShade gui and tweaking shaders when Ansel is active.
Although I completely forgot about Freestyle. That solves some of the issues.
Amazing work on the shader btw. I really love how clean and hq processed image looks.
Would be great if we could occasionally push that radius a bit more tho.
Please Log in or Create an account to join the conversation.
- OtisInf
Any chance Ansel will support vertex shaders soon? I asked Henry but he's apparently Awol or not looking at his twitter account. I could port my dof over without the vertex shader but it's slower then, so I'd rather use a vertex shader. I saw if you get a compile error in a yfx file you don't get a log, which is a bit of a shame, do you know if it spits out a log if a compile error occurs? The ansel SDK in the private github repo sadly only talks about integrating ansel, not about what to do to get a shader running inside Ansel.
I ask this as the dof in ansel doesn't have near plane bleed and no control over the bokeh highlights ( I changed that locally by adding some of my own dof's code to the dof.yfx but rather have public source and as I already have done the work of writing all that code I'd love to have that running inside ansel as reshade doesn't work on dx12 )
TIA
Please Log in or Create an account to join the conversation.
- Marty McFly
The DoF in Ansel is basically my ReShade DoF - stripped down with less controls, hence hardcoded highlights - however I posted pictures of a DoF with proper near plane bleed a while ago, it just has 1 bug I cannot get rid of that prevents me from using it on ReShade or Ansel.
No offense, your Cinematic DoF is great and I think it would be a good addition to Ansel, but the way the near blur works is incorrect, it spreads the blur level outside, so sharp far field next to blurry near field gets blurred as well, even though blurry near field on top of sharp far field should be alpha blended.
As you probably saw, I've been working on another DoF - with near field bleed - for a while now, which was on hold due to the other stuff that had to be done. What about licensing with your Depth of Field, it's derivative work of a lot of papers - wouldn't that cause problems? I'm no expert in this field at all, that's why I'm asking.
Please Log in or Create an account to join the conversation.
- OtisInf
Hmm bummer, well at least it hot-loads when you alt-tab (full screen)Marty McFly wrote: I've been asking for Vertex Shader support for a while, don't know when / if that is going to happen. Compute shader would be even cooler, blurring benefits so much from these. Not getting compiler errors/warnings makes things difficult but tbh, the files are small enough that you quickly find what's wrong.
what doesn't it do that it should do? Perhaps I've ran into the same issue.The DoF in Ansel is basically my ReShade DoF - stripped down with less controls, hence hardcoded highlights - however I posted pictures of a DoF with proper near plane bleed a while ago, it just has 1 bug I cannot get rid of that prevents me from using it on ReShade or Ansel.
It actually needs to do that. An edge of an element near the camera blurs in both directions (it's the same as when you blur the near plane with a gaussian blur where you use transparent pixels for the in-focus/far plane pixels). The version of cinematicdof in the reshade shader repo does blur abit too much at times (with high blur values) and that could look a bit ugly indeed, I've toned it done in my own repo abit (I should send a pr sometime).No offense, your Cinematic DoF is great and I think it would be a good addition to Ansel, but the way the near blur works is incorrect, it spreads the blur level outside, so sharp far field next to blurry near field gets blurred as well, even though blurry near field on top of sharp far field should be alpha blended.
It's scatter-as-gather as you know, so an in-focus pixel right next to a pixel that's in the near plane should gather what the near-plane pixel scatters over it but won't as its CoC is close to 0 (or 0). To make that work, I blur the CoC of the near plane into the rest so when blurring the near plane I use the blurred CoC (which is based on tiles) which mimics what the scatter approach would have spread over the in-focus pixel. I use tiles with neighbor averaging to calculate the CoC to use for infocus/farplane pixels when blurring the near plane. With that CoC, which is > 0, the in-focus pixel will gather the near plane pixel and thus bleed (a bit) which is what we're after. It blurs the result of the farplane blur pass so it will blur a blurred far plane a bit further. At least I can't see artifacts that don't occur too when I take macro shots with my canon.
Just using tiles gave artifacts however: around the edges of the tiles obvious edges were visible and I couldn't get that right. An alpha should be used to make them smoothly blend but I couldn't get that alpha right. However the solution was simple: blur the tiles with CoC values This gives smooth edges and still has the desired effect of having a CoC large enough to gather the scattered fragments for infocus/farplane pixels when blurring near plane.
It's MIT licensed so it can be used whenever as long as credit is given.As you probably saw, I've been working on another DoF - with near field bleed - for a while now, which was on hold due to the other stuff that had to be done. What about licensing with your Depth of Field, it's derivative work of a lot of papers - wouldn't that cause problems? I'm no expert in this field at all, that's why I'm asking.
Please Log in or Create an account to join the conversation.
- piltrafus
Marty,
Do you think is possible to release a version of it for reshade?
Thanks.
Please Log in or Create an account to join the conversation.
- Marty McFly
OtisInf wrote: what doesn't it do that it should do? Perhaps I've ran into the same issue.
Transparency bug in near plane areas, where a strongly blurred near field area is next to near- but almost in focus area. Other approaches such as Jimenez' don't suffer from this, but the near plane bleed looks much worse. Today I took another stab at it and migitated it enough so it's not noticable anymore (dropping alpha in those areas and use small fullres blur on that area which I have to do anyways), don't know why I hadn't though of this before.
It actually needs to do that. An edge of an element near the camera blurs in both directions (it's the same as when you blur the near plane with a gaussian blur where you use transparent pixels for the in-focus/far plane pixels). The version of cinematicdof in the reshade shader repo does blur abit too much at times (with high blur values) and that could look a bit ugly indeed, I've toned it done in my own repo abit (I should send a pr sometime).
It's scatter-as-gather as you know, so an in-focus pixel right next to a pixel that's in the near plane should gather what the near-plane pixel scatters over it but won't as its CoC is close to 0 (or 0). To make that work, I blur the CoC of the near plane into the rest so when blurring the near plane I use the blurred CoC (which is based on tiles) which mimics what the scatter approach would have spread over the in-focus pixel. I use tiles with neighbor averaging to calculate the CoC to use for infocus/farplane pixels when blurring the near plane. With that CoC, which is > 0, the in-focus pixel will gather the near plane pixel and thus bleed (a bit) which is what we're after. It blurs the result of the farplane blur pass so it will blur a blurred far plane a bit further. At least I can't see artifacts that don't occur too when I take macro shots with my canon.
Just using tiles gave artifacts however: around the edges of the tiles obvious edges were visible and I couldn't get that right. An alpha should be used to make them smoothly blend but I couldn't get that alpha right. However the solution was simple: blur the tiles with CoC values This gives smooth edges and still has the desired effect of having a CoC large enough to gather the scattered fragments for infocus/farplane pixels when blurring near plane.
Yeah, I know.... the reason why this DoF here is taking me so long is because I tried solving this issue I'm almost satisfied with the near field blur now, took me long enough:
It's MIT licensed so it can be used whenever as long as credit is given.
Your DoF is MIT licensed but what about the papers you got your information from? How is that handled, generally? You were under the assumption that I re-coded the Anisotropic Kuwahara and you said that would not violate its GPL license - but what about other licenses? I'm asking because I did some advancements on MXAO using the state of the art GTAO method, basically coded after its paper (source code is not available).
Please Log in or Create an account to join the conversation.
- crosire
GPLv3:
[...] To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work. [...]
[...] all copies or substantial portions of the Software. [...]
Disclaimer: I'm obviously not a lawyer, so take this with a grain of salt.
Please Log in or Create an account to join the conversation.
- OtisInf
had the same thing I think. The explanation of Jimenez was unclear to me, it looked like he fixed it in the upscaler but the secret sauce how to do that wasn't in the paper.Marty McFly wrote:
Transparency bug in near plane areas, where a strongly blurred near field area is next to near- but almost in focus area. Other approaches such as Jimenez' don't suffer from this, but the near plane bleed looks much worse. Today I took another stab at it and migitated it enough so it's not noticable anymore (dropping alpha in those areas and use small fullres blur on that area which I have to do anyways), don't know why I hadn't though of this before.OtisInf wrote: what doesn't it do that it should do? Perhaps I've ran into the same issue.
That looks alright Tip, also try it with pointy edges, like grass ends, I had a problem there (I think the Unreal paper mentions that too) which needed special code.(snip)
Yeah, I know.... the reason why this DoF here is taking me so long is because I tried solving this issue I'm almost satisfied with the near field blur now, took me long enough:
As Crosire said, ideas can't be copyrighted. An application of an idea can be patented (EU) or an algorithm can be patented in the US (not eu), but a paper that discusses how to do things and it's not patented is up for grabs. The scientific community publishes papers just to share knowledge, often with sourcecode, and it's often generously licensed even. If you implemented an idea from a paper, the code is yours. It might implement a patented algorithm (in the US) but it's often hard to prove it's the exact algorithm. The shader I wrote is based on research papers which were published to spread knowledge, the ideas in them are therefore free. Would some of them come with code and had I copied that code, then I would have to obey the license of that code.
Your DoF is MIT licensed but what about the papers you got your information from? How is that handled, generally? You were under the assumption that I re-coded the Anisotropic Kuwahara and you said that would not violate its GPL license - but what about other licenses? I'm asking because I did some advancements on MXAO using the state of the art GTAO method, basically coded after its paper (source code is not available).It's MIT licensed so it can be used whenever as long as credit is given.
Don't worry about it. In my field, O/R mappers, the whole application of the mechanism and set of algorithms is patented over 243 times (no joke) in the US by as much companies. Even if you run into something that might be patented by someone, changes are close to 0 you'll hear something about it.
Please Log in or Create an account to join the conversation.
- TreyM
IMO, a paper exists to demonstrate a concept and a basic explanation of how something was accomplished or discovered. I do not consider them to be blueprints to just completely copy snippets of code verbatim. That's just my opinion.
Please Log in or Create an account to join the conversation.
- Marty McFly
OtisInf wrote: That looks alright Tip, also try it with pointy edges, like grass ends, I had a problem there (I think the Unreal paper mentions that too) which needed special code.
Oh yes, that proved to be a major bummer, finding the areas where this happens was very difficult, but once i found it, solution was easy. It's still not perfect but as close as it gets without actually having the color data behind those grass thingies.
Please Log in or Create an account to join the conversation.