--JawZ-- ENB resources, updated 15 september-14

[nexstac]

so, you checked the realtime gamma algo, before me

Code: Select all

//reverse gamma correction
   color = 0.012522878 * color + 0.682171111 * color * color + 0.305306011 * color.r * color.g * color.b;

// color controls

//restore gamma correction
   color = 0.585122381 * sqrt(color) + 0.783140355 * sqrt(sqrt(color)) - 0.368262736 * sqrt(sqrt(sqrt(color)));

i will test it now, also...

you are right... in your box above the color-dynamic-converter, i also see no reason to seperate it to RGB!

i read a message from kermles today, perhaps he will come here, anytime!

that seems a bit tooo performance heavy for me, i tested it yesterday:

Code: Select all

//restore gamma correction
   color = max(1.055 * pow(color, 0.416666667) - 0.055, 0);

[nexstac]

but JawZ, beware:

every operation has to be LINEAR SPACE optimized if you convert it to linear space!
...think about that...
in 1.0 gamma

EDIT:
Realtime gamma-correction works excellent!!!!!

EDIT EDIT:
Iam so happy, kermles is back with his crazy stuff!!!! i love that guy!!!!

[Kermles]

Hey guys, nexzstac informed me that my code was wanted so here I am I guess. Sorry to have disappeared for a long time. Hi JawZ!

Anyway I figured that instead of spend days cleaning up my own file for a new release and making you guys sort through it all, it would probably be easier for everyone if I just gave you the tonemapping algorithm and let you implement it the way you want. Some info on the code, it is an implementation of the math found here:

http://www.cg.tuwien.ac.at/research/the ... ode34.html

and it was NOT designed by me. I tried to do it myself but it turns out someone had already done it better than I could have, so I converted it to HLSL and made it work with ENBSeries. I separated it into its own function to make it easier to use, as far as I know there is no point in modifying the function itself at all. So you probably shouldn't change the code. If you want to use it, you would call the function under the "#if POSTPROCESSING == #" thingy and pass in the external parameters of the same names as the ones used in the function declaration.

Using adaptation is mandatory if you are going to use this postprocessing method (and any proper tonemapping method HAS to use adaptation for a correct result), but IMO it is worth it as it produced great results in my testing, it is my favorite tonemapping algorithm that I have worked on so far.

You guys at this point probably know more about doing proper saturation, brightness, contrast and gamma conversion stuff than I do so I left that stuff out, you can add it on your own.

Here is the code then:

Code: Select all

float3 tonemap(in float3 color, in float grayadaptation ) 
{
	#define scalef(Lmax, Lwa, scale)\
	scale = 1.f / Lmax * pow ( (1.219f + pow(0.5f * Lmax, 0.4f)) / (1.219f + pow(Lwa, 0.4f)) , 2.5f);

	float L_display_max = 1.0f;  // maximum display luminance
	float scale;                 // scale factor                
 
 // compute world adaptation level
 float L_wa = grayadaptation;
 
 scalef(L_display_max, L_wa, scale);

// multiply pixel values with scale factor and clip if necessary
color*=scale;
return saturate(color);
}

Yeah, it's weird looking but there should be no reason to change it anyway so it doesn't matter.
Place the function in the section of the enbeffect.fx file just under the end of the postprocessing method options (or anywhere as long as it's not inside another function and is above the main enb shader functions).

Here is how to call the function if you don't already know:

Code: Select all

color.xyz = tonemap(color.xyz, grayadaptation);

Hopefully it works and someone can get some use out of it.

Cheers, and let me know if I can help you guys with anything. I will try to be more active from now on.

[ENBSeries]

I don't know where some of these math you got guys, but recommend to think first, could these be in real optics and eye, then it's easy to understand which are wrong.

Code: Select all

color.rgb = max(1.055 * pow(color.rgb, 0.416666667) - 0.055, 0);

only complete idiot can write such math and say it's valid, it's nice for gta4 developers or vanilla skyrim graphics, especially if change to:
color.rgb = max(1.55 * pow(color.rgb, 0.416666667) - 0.55, 0);
for stunning look

Gamma in digital photos is 2.2, not 2.4 or anything else. Some digital cameras allow to change gamma, but such features never used for making textures (most in skyrim are edited and don't have 2.2, so no sence to bother). When image is not from celluloid camera, then math like this must be used (with little changes to fit overexposed photos):

Code: Select all

to linear
color = color/(1.000001 - color)
back
color = color/(1.0 + color)

But all above is absolutely useless in enbeffect.fx, because gamma applied at objects rendering stage and output is already gamma corrected by ColorPow parameter. So what you actually doing?

[nexstac]

hi boris,
...so, nobody knows what happens inside your hook... if you can do some short document points, it would be great!
we have had experimented with linear-space operations inside a pixel-shader... so if the operation is linear-space and you
convert it back... i see no problem there.

... i like it to be a idiot!

[nexstac]

@boris

i think that guy is a idot:
http://chilliant.blogspot.de/2012/08/sr ... -hlsl.html

coz you are more into math... i belive!!!!
...just kidding

[nexstac]

hmmm...
i finally decided to leave ENB.
sorry, Jawz! have a good time and all my best wishes to you!

boris, seems not to interested to share what happens inside his ENB.
he want just to call us idiots... i dislike it... iam sorry!

boris, do well and think about your users belive in you!
...but i don´t do so, anymore!
sorry!

[ENBSeries]

If that blog is yours, then yes, you idiot. Programming have strict rules, programming of shaders give more flexibility, but it doesn't mean that you can do anything just because of eyes limitation. Don't want to listen, don't want to learn - find other work. I will not make any documentation for shaders, because it's programming and knowledge which can't be described in few pages, so listen and learn or go away. Regarding linear or gamma space computations in enbeffect.fx, every 3d programmer know that hdr is in linear space, it's not need to be described in any docs, it's axiom. Eh, what am i doing here, just another little boy who like to see offence of himself everywere. --JawZ-- ignore all crap written in blogs, those are fake coders who promote own theories. Use only prooved concepts and think what happens in real life from physical side and what can't be.

[--JawZ--]

So if ENB handles the gamma correction then Kermles initial code does not need such coding applied to it either then.

Kermles initial Final Adjustment code;

Code: Select all

#if(FINAL_ADJUSTMENTS == 1)
	float3 	FinalSaturation 	= lerp( lerp( SaturationDay, SaturationNight, JKNightDayFactor), SaturationInt, JKInteriorFactor );
	float 	FinalBrightness 	= lerp( lerp( BrightnessDay, BrightnessNight, JKNightDayFactor), BrightnessInt, JKInteriorFactor );
	float 	FinalContrast 		= clamp(lerp( lerp( ContrastDay, ContrastNight, JKNightDayFactor), ContrastInt, JKInteriorFactor ), -1.0, 1.0);	
			
	//convert to linear colorspace
	color.r 		= 1.0/(1.0+color.r);
	color.g 		= 1.0/(1.0+color.g);
	color.b 		= 1.0/(1.0+color.b);
	//reverse gamma correction
	color.rgb 		= pow(color.rgb, 2.2);

	//saturate
	color.rgb 		= lerp(dot(color.rgb,(float3(0.299, 0.587, 0.114))), color.rgb, FinalSaturation);
	//brighten
	color.rgb		/= FinalBrightness;
	//adjust contrast
	float factor 	= (1.0156862745098039215686274509804 * (FinalContrast + 1.0)) / (1.0156862745098039215686274509804 - FinalContrast);
	float newRed   	= saturate(factor * (color.r   - 0.5078431372549019607843137254902) + 0.5078431372549019607843137254902);
	float newGreen 	= saturate(factor * (color.g - 0.5078431372549019607843137254902) + 0.5078431372549019607843137254902);
	float newBlue  	= saturate(factor * (color.b  - 0.5078431372549019607843137254902) + 0.5078431372549019607843137254902);
	color.rgb 		= float3(newRed, newGreen, newBlue);

	//restore gamma correction
	color.rgb 		= pow(color.rgb, 0.45454545454545454545454545454545);
	//restore dynamic range
	color.r 		= (1.0/color.r)-1.0;
	color.g 		= (1.0/color.g)-1.0;
	color.b 		= (1.0/color.b)-1.0;

#endif

Or am I missing something here?

I will keep that in mind Boris but I'm still going to experiment and that means creating or stumbling on such codes, can only learn through one's mistakes as the saying goes. And as you've probably figured out for yourself I don't have the knowledge to tell the difference between "good" and "bad" code segments. But I'm learning that too, as slow as it may be.

[ENBSeries]

The mod apply ColorPow to textures before they are used, this guarantee proper linear color operations. Post process linearisation is invalid, because lighting, reflections, specular - must be computed in linear space, it's not photo from camera where processor compressed image and with image editor you need to do something to it, processor is enbeffect.fx shader. Just forget everything from photoshop or similar image editors, they designed to change real images, before that you need to make proper tonemapping + adaptation to make it realistic. In any other case it's just hypocrisy, like this: color.rgb = max(1.055 * pow(color.rgb, 0.416666667) - 0.055, 0);

If that code applied before tonemapping or instead of it, then it's wrong. If after tonemapping, then it can be used, but i don't understand why to use after tonemapping if tonemapping is not so simple like gamma 2.2 as single operation and why to use wrong math.

Code: Select all

color=1.0/(1.0+color);
color=pow(color, 2.2);

- this is not convertion to linear space, imagine the graph from first code line with various "color" arguments.

Btw long digits are useless in shaders, because they have standart floating point variable support with 24 bit mantissa. Values like this 0.5078431372549019607843137254902 must be clamped to 0.50784314, otherwise some compilers may fail (i can't guarantee usage of same compiler, changed many versions of them).