WPF Bitmap Effects Revisited

Ok, so the first pass was ok (apart from the messed up file uploads 🙁 thanks alot WLW! ) but there are still a few minor niggles. Firstly was the whole com registration deal. Whilst its not really a bit deal in development (you can register the effect as part of the build process) when it comes to deployment, well, it means your xcopy deployable project just got a whole load more complex!.

Whilst looking at the possibility of using isolated com & the reg-free support with manifests, I came across a couple of blog entries by John Melville detailing how to build a managed C++ single assembly for bitmap effects.

So, I brushed off my C++ cap, and jumped straight in. Using a single managed C++ assembly approach is a much more elegant solution, and gives us back the ability to distribute the bitmap effect assembly with our application rather than jumping through the usual com registration hoops.

Anyway, I have created 2 new bitmap effects, and I’ve also re-factored the GreyScale bitmap effect in the last post into a single assembly.

The 2 new Bitmap effects are a

• SaturationBitmapEffect

  Has a single DependencyProperty called , surprisingly , "Saturation". The range for this value must be from 0.0, to 1.0 which represents an unsaturated image up to a fully saturated image.

  Although you can use the HSLBitmapEffect, the SaturationBitmapEffect uses only 3 multiplies so is significantly faster than doing a full colorspace transform just to reduce the saturation. Just like the GreyScaleBitmapEffect, the SaturationBitmapEffect also uses correctly scaled colour components to represent a the greyscale image.

• HLSBitmapEffect

  The HLS bitmap effect allows you to control all three components; Hue, Saturation and Lightness. Each RGB colour is transformed into its double hexacone equivalent in the HLS space, and then scaled or shifted by the DependencyProperty’s exposed on the Effect called… heh, you guessed it, Hue,Saturation and Lightness!

Here you see the Bitmap Effect being applied in Blend. If you click the little triangle next to the BitmapEffect Name, you should see the effects dependency properties.

Note that both Saturation are [0.0 .. 1.0] whereas the hue is a SHIFT value of [0.0 .. 1.0] where the range represents a 0-360 SHIFT in the hue, ie 0.5 is a 180 degree shift in hue.

Although bitmap effects are very costly in terms of rendering in WPF since they force the whole stack to render your control hierarchy in software – the effects aren’t really all that slow and although the advice to avoid bitmap effects if possible still stands, I find judicious use of them acceptable, especially if used on something that is static.

Speedwise, the GreyscaleBitmapEffect is the fastest since it only involves a straight weighting of the input colours. Next is the SaturationBitmapEffect, which is only marginally slower than the Greyscale effect. I’ve tried this on the top level window to fade it to grey when the application loses focus, and it still runs at an acceptable frame rate on my Laptop (Centrion Duo with Nvidia Quadro NVS 110) ie… not the fastest hardware on the planet, but still desaturates an 800×600 window quite easily.

Lastly is the HLS effect. On a per pixel basis, it’s quite heavy duty, transforming each RGB triplet into the HLS colour space, and then back again, so i suggest using this only for testing or prototyping work. Once you know the HLS values in any bitmap you’re working with, its definitely worth cracking out Paint.NET and baking in those HLS values. I don’t think you’d get away with leaving the HLS bitmap effect in place on anything but top end hardware.

Which brings me to my next point, I’ve read on the Rob Relyea’s MIX08 blog entries that the WPF team will open up the Direct X pipeline and allow us to plug in our own pixel shaders. This will allow some staggeringly cool effects, and easily make transforms like HSL work in real time with no noticable performance loss! If this does make it into the 3.5 update it will really improve WPF’s extensibility beyond writing the odd bitmap effect! I can’t wait!

One last bonus (heh, i’m starting to sound like I should be working on the Shopping Channel; – "but wait THERE’s MORE!") – I’ve put together a skeleton single assembly BitmapEffectProject , and a bunch of steps to modify the code (if you’re not au-fait with C++)

All the steps are in Visual Studio’s TODO list format, so they’re right there in the source code. IIRC Step #9 is the bit where you twiddle the pixels which should probably be the last thing you do, but I couldn’t be bothered re-numbering the steps 😉

One minor point to note is you may see this dialog pop up when you open the test project in blend

All this means is that Blend doesn’t understand managed C++ projects. This can be safely ignored since you’ll really be twiddling the pixels inside VisualStudio anyway.

To use the bitmap effect simply add a project reference to the desired DLL, and add an appropriate namespace directive in your XAML file like so :

xmlns:HLSEffect="clr-namespace:HLSBitmapEffect;assembly=HLSBitmapEffectLib"

then add the bitmap effect to your bitmap.

        <Image Name="aPic" Source="images/Source.jpg">
            <Image.BitmapEffect>
                <HLSEffect:HLSBitmapEffect>
                    <HLSEffect:HLSBitmapEffect.Saturation>
                        <Binding ElementName="satSlider" Path="Value"/>
                    </HLSEffect:HLSBitmapEffect.Saturation>
                </HLSEffect:HLSBitmapEffect>
            </Image.BitmapEffect>
        </Image>

…and you should be good to go!

Enjoy!