result = (result – 0.5) * contrast + 0.5;

Where the contrast value is between 0 to infinity, and 1 means no change.

Also, brightness is normally implemented as;

result = result * brightness

Where brightness is between 0 and infinity, and 1 means no change. This will increase the brightness while keeping blacks black.

Cannot create instance of ‘BrightContrastEffect’ defined in assembly ‘WPFBrowserApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’. Exception has been thrown by the target of an invocation.

Effecter.Brightness = 0.1F;

Thoughts?

Appreciate for the explanation on how to do it.

Futher info required since lost ctc with you since 2004.

jelpudu
jlpd–>track this id

I want to use the example to not only change the brightnes on teh screen but also use the same effect by RenderTargetBitmap functionality, and it’s works! (answer for GRiNSER question).

I notice on litle “bug” that on the screeen the image is going to be white when i decreshe the brightnes and when render it to the file it became black as suspected. What is wrong? As Mark wrote the orginal posted effect shader code affect the alpha channel and the window is white… RenderTargetBitmap use as default the black bacground so this is why? I think that solutions provided by Husni Che Ngah and Mark will solve the problem.

Becouse i play with this stuff just 1 hour i dont know where i will found the shader compiler… probably in DirectX SDK I will go deep in it soon…

Best.

   result = result * (1.0+contrast)/1.0;

You don’t actually need to perform the division with one here; yet, it may get compiled to the shader anyway, and division is one of the most difficult calculations for the GPU to do, no matter whether the divisor is constant one or not.

Best regards,

-Niko

In all fairness, an optimizing compiler should turn a "division by constant" into a "multiply by constant" pattern, but still it is an unnecessary operation if the divisor is exactly 1.0f (which the compiler _could_ iron out too).

However, if the shader is compiled in debug mode, Direct3D will preserve all operations unoptimized so as to enable breakpoints and source-level variable watching. In "raw" D3D this is very useful for checking that the compiled code actually does what you would expect it to do.

I haven’t tested yet whether or not the WPF effect framework actually facilitates live debugging of the shaders, though, as we don’t seem to explicitly have neither access to the internal graphics device interface nor control of its creation parameters.