Welcome, Guest.
Username: Password: Remember me

TOPIC: Port of Painterly shader from nvidia Ansel

Port of Painterly shader from nvidia Ansel 5 months 3 days ago #1

I was wondering if someone could port Painterly from Ansel shaders.
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
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 5 months 2 days ago #2

It's anisotropic kuwahara, invented/discovered by Jan Eric Kyprianidis, see: www.kyprianidis.com/p/pg2009/. Someone ported his OpenGL shader some time ago to reshade: reshade.me/forum/shader-presentation/4030-kuwahara-anisotropic. Here's a version for reshade 3: gist.github.com/FransBouma/5a357b439c5aadc4ed8ab1de83dc95c4

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?
Last Edit: 5 months 2 days ago by OtisInf.
The administrator has disabled public write access.
The following user(s) said Thank You: NattyDread, BeTa

Port of Painterly shader from nvidia Ansel 5 months 1 day ago #3

I don't think it's the same effect. They def have something custom going on here.
I could never get KuwaharaAnisotropic to look this good:


This is the closest I could get:
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 5 months 1 day ago #4

The researcher has a code repository with an OpenGL app that runs 3 shaders, 2 are anisotropic kuwahara with different parameters (configurable) and approaches. Trust me, it looks exactly like your first shot. the reshade shader I linked to is a direct port but doesn't mimic the effect in the opengl app, I couldn't really find the reason why it wouldn't work/look the same. The original one however does look the same, so the shader dev (which I think is marty, but not sure) did a good job porting the effect over and make it much faster.

Check this app, see for yourself :) code.google.com/archive/p/gpuakf/downloads
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 5 months 1 day ago #5

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.

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?
Last Edit: 5 months 1 day ago by Marty McFly.
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 5 months 19 hours ago #6

Well, for one, Ansel only works with supported games.And for two, even in games where Ansel is -supposed- to work, it sometimes doesn't.

Reshade always works, though :)
Last Edit: 5 months 19 hours ago by Martigen.
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 5 months 18 hours ago #7

And, ehm, I know it's a well kept secret, but there exists another GPU manufacturer called "AMD". I know I know, sounds crazy!
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 5 months 17 hours ago #8

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.
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).
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?
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 all :)

If it's not anisotropic kuwahara as you say, then I've said nothing.
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 5 months 16 hours ago #9

I made several new filters (e.g. The watercolor briefly shown at CES keynote), a lot more work went into those than the others, so we've decided to make them closed source. As you surely know by looking at the public ones, these are no rocket science.

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 :blink:

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).
Last Edit: 5 months 16 hours ago by Marty McFly.
The administrator has disabled public write access.
The following user(s) said Thank You: OtisInf

Port of Painterly shader from nvidia Ansel 5 months 14 hours ago #10

ReShade (v4) and Ansel aren't really compatible as of now. That's the only reason I made a request. But yeah, as Martigen mentioned, ReShade always (well, almost always) works.
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. :)
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 5 months 9 hours ago #11

@marty thanks for the info! :) I must say, it looks great :)

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
Last Edit: 5 months 9 hours ago by OtisInf.
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 5 months 8 hours ago #12

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.

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.
Last Edit: 5 months 8 hours ago by Marty McFly.
The administrator has disabled public write access.
The following user(s) said Thank You: jas01, OtisInf

Port of Painterly shader from nvidia Ansel 5 months 24 minutes ago #13

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.
Hmm bummer, well at least it hot-loads when you alt-tab (full screen) :)
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.
what doesn't it do that it should do? Perhaps I've ran into the same issue.
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 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.
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.
It's MIT licensed so it can be used whenever as long as credit is given.
Last Edit: 4 months 4 weeks ago by OtisInf.
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 4 months 4 weeks ago #14

I would also love to use this painterly shader in reshade.

Marty,
Do you think is possible to release a version of it for reshade?
Thanks.
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 4 months 4 weeks ago #15

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 :sick: 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).
The administrator has disabled public write access.
The following user(s) said Thank You: TreyM, Uncle Crassius

Port of Painterly shader from nvidia Ansel 4 months 4 weeks ago #16

Ideas cannot be licensed. There may be patents on them, but that's a different topic. If you are just following mathematic formulas, but writing all code yourself, then my understanding is that you are the owner of that code and such are free to license it. If you however read source code from somebody else and reimplement that code (even if you rewrite most of it), things get more complicated and you'll have to pay close attention to whatever the original source code was licensed with and how it defines modifications. Unfortunately, this is often not very clearly defined:

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. [...]
MIT:
[...] all copies or substantial portions of the Software. [...]

Disclaimer: I'm obviously not a lawyer, so take this with a grain of salt.
Cheers, crosire =)
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 4 months 4 weeks ago #17

Marty McFly wrote:
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.
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. :)
(snip)
Yeah, I know.... the reason why this DoF here is taking me so long is because I tried solving this issue :sick: I'm almost satisfied with the near field blur now, took me long enough:

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.
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).
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.

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.
Last Edit: 4 months 3 weeks ago by OtisInf. Reason: clarification
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 4 months 4 weeks ago #18

Of course, you're unlikely to hear something about it due to the fact that no one just sits trolling through code on the internet trying to find something that they wrote being "stolen." But eventually, if someone just lifts code from papers and inserts it into a commercial product, they're going get bitten.

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.
The administrator has disabled public write access.

Port of Painterly shader from nvidia Ansel 4 months 4 weeks ago #19

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.

Last Edit: 4 months 4 weeks ago by Marty McFly.
The administrator has disabled public write access.