Kabloom! GUI bloom control rev3, now in header file

[--JawZ--]

I haven't read all the comments about code suggestions so sorry if this will be off topic but there is also another code that controls specific color channels.
MTichenor's HSV Color Equalizer found in his ENB Evolved preset;
http://www.nexusmods.com/skyrim/mods/23765/?

Maybe it's worth looking into as well, or perhaps not I dunno.

[Kermles]

I think mTichenor's HSV control is probably the best solution, I forgot about that. I seem to remember it having problems being a lossy conversion or something though, and HSV needs LDR values, and it can do strange things because V is the max component and not the luma. But still I don't know any better way to do the same thing. I believe there is a way to replace the V component with a reversible luma calculation, I think if you modify the HSV conversion to use the Y from CIE Yxy, then HSV apparently works a little better. I wish I knew how to code some Catmull-Rom splines and set up a really flexible color control shader, but that is fancy math.

Also, I realized that my bloom thing doesn't need to replace other bloom methods or clog up someone's enbeffect.fx, I will be posting a better solution for people to add it to existing presets sometime soon, and maybe some other stuff, maybe a video of how to use it/what it can do.

[prod80]

@Jawz/Kremles
I'm out the country now, but I will certainly play with some of the examples here, thanks

@Kremles
I've played a lot with the photoshop blend modes, it has some nice options though a lot of them rely on multiple passes which may only take place in enbbloom.fx or effect.txt depending on why it looks bad... I found a lot of them look bad because the following;

1 - bloom texture resolution is only 512x512. You already notice the quality of the bloom is not too good on various methods... Even if not directly visible, it becomes apparent on for instance screen blending already (which is rather simple). It's a good idea to port the bloom output to your screen once to actually see what you are working with, just use a return statement at the beginning of your pixel shader and start game to view only the texture you are working with;

Code: Select all

return float4(tex2D(_s3, _v0.xy).xyz, 1.0f);

2 - you actually need to blend multiple textures multiple times, so you need a file that has multiple passes, for instance when you want to use Soft Light blend mode and afterwards another blend mode based on the soft light texture that has to be treated by for instance a blur effect.

In any case you'll likely find out the majority of the blend modes will not work so well, Screen, Add and Softlight do however. Here's Softlight and Overlay math functions, just for the heck of it;

Softlight -- a = base color, b = blend texture (bloom texture), s = interpolation between both
Make sure a and b went through a saturate()

Code: Select all

float3 softlight(float3 a, float3 b, float s)
{
float3 ret;
float3 b_x2 = 2.0 * b;
float3 a_b_x2 = a * b_x2;
float3 c1 = a_b_x2 + a * a - a * a_b_x2;
float3 c2 = sqrt(a) * ( b_x2 - 1.0 ) + 2.0 * a - a_b_x2;
ret = ( b > 0.5 ) ? c1 : c2;
return lerp( a, ret, s );
}

Overlay blend -- a, b, s, same thing as above
Again, a & b must go through a saturate

Code: Select all

float3 overlay(float3 a, float3 b, float s)
{
float3 ret;
float3 c1 = 1.0 - ( 2.0 * ( 1.0 - a ) * ( 1.0 - b ) );
float3 c2 = a * b * 2.0;
ret = ( a > 0.5 ) ? c1 : c2;
return lerp( a, ret, s );
}

Both those blend modes are contrast enhancing, NOT "bloom-ish"

Cant remember where I got those code from, but they aren't something I did besides adding function with interpolation...

[Kermles]

Good idea, maybe I can start looking into messing with the other files. I was hoping to move it to enbbloom and mess with radius and maybe some effects besides blur anyway. I have noticed that screen blending and these others with saturate()/LDR output don't do well before tonemapping unless using addition or lighten+multiply/add, so I probably should move everything around regardless. What I am currently thinking is to move everything but the blend modes/their final blend pass code to enbbloom.fx, find some sort of tonemapping curve to apply to the bloom output, and then blend it after scene tonemapping so that it doesn't need to be clamped for those blend modes. Is this a bad idea? I found some example of it here, near the bottom: http://content.gpwiki.org/D3DBook:High- ... _Rendering

Wasn't planning on doing it exactly like they did though. Anyway, thanks, you have really got me thinking with all your suggestions.

Edit: Posted update, moved entire effect into header file and removed dependency on xcolorbloom, now it will work in any file by just copying over some code, no replacing enbeffect.fx or modifying any existing code. Also made a couple small fixes and tweaks, reorganized it heavily and prettied it up. Think it's working pretty close to how I want now, so no more edits until I come up with an enbbloom.fx version hopefully.

[prod80]

Nice link.

Some other food for thought;
What if you combine pixel luminance and ENB adaptation for tonemapping? ENB adaptation measures the average brightness of the entire screen, then measure pixel luminance and compare that to screen average and see what to do with that particular pixel.

Just need to work out the math to use HSL in a way that the L component is actual pixel luminance and not delta of highest - lowest RGB... and run just tonemapping over Luma so that tonemapping process does not cause color shifts, then convert the whole thing back to RGB.

Sorry for constantly shifting off topic

[Kermles]

Try Yxy instead of HSL, the large Y is luminance. Go from RGB->XYZ->Yxy->tonemapping on Y value->XYZ->RGB. Simpler than redesigning HSL properly. It's there on that page I linked to. Just so you know, luminance avoids color shifts, but visually it tends to look more like colors are oversaturated and have too much local color contrast than running tonemapping on RGB. It's part of what gives a lot of HDR photos their "fake" look with certain tonemappers. There's probably a luma-based desaturation effect you can use to mitigate it. RGB tonemapping gives a more natural result like ordinary film, and if you look at individual color tone curves for popular film emulsions the curves are often very different.

I will try your idea out, I used adaptation to control the Ward tonemapper before and it worked fairly well, but I haven't tried with others. That one was otherwise not very configurable.

[nexstac]

how about investigate in my code and pull out some ideas out of it?

-> NXS POST PROCESS at Skyrim Nexus

...also, you will find answers to some existing questions!

my best wishes to you, kermles

[Marty McFly]

Your code is a pain in the ass to read....all these weird formattings...

[Kermles]

Sorry, after getting transferred from different programs too much it started getting really janky so I used a code formatter that produced the least insane result. There are much worse code styles, like at the bottom of the page here: http://alienryderflex.com/hsp.html

It's okay for me because I hate dealing with the huge strings of parentheses in it otherwise, but I'll work on that, my workflow just needs to be sorted out. Files keep getting reverted after I save them? Not sure what the heck is going on. There were a few problems with the rev3 file caused by it that should be gone now: Re-separated blend strength and lerp amount for certain blend modes, fixed color balance feature, improved saturation method, fixed it seemingly not compiling. Sorry everyone who was inconvenienced.

Nexzstac
Thanks very much, I'll look into it some more!

[nexstac]

@Kermles
i think you will find some good brain food.
it was coded in some days... and it contains some nice
ideas that could be developed further

@Marty McFly
i don´t know what your problem is with my "weird formattings"?
have you opend my file in windows "paint"? maybe... lol...
please show me your code!
please show me what you have developed and not adopted!
...than we can talk about my "weird formattings"!
ok, kid?