Click here to Skip to main content
12,996,841 members (133,685 online)
Rate this:
Please Sign up or sign in to vote.
I am interested in learning WPF, so i want to develop a small application that is capable of doing some basic image manipulation.
For leaning basics this is ok , but what if i really need to develop a serious image manipulation with WPF?

1) How much support is there for imaging in WPF ?

2) Is WPF a good choice for serious high performance imaging application?

3) Is it overkilling slow for sophisticated image manipulation?

4) Is there any good image processing library that can be used with WPF for better results?

I need suggestions and guidance. Thank you very much in advance.
Posted 8-Feb-11 23:12pm
YvesDaoust 1-Aug-11 5:42am
What do you call "basic image manipulation" and "serious image manipulation" ? What do you call "high performance imaging" ?

What image processing operations do you really need ?

Without more details, answering your question is a nonsense.
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

You might find this blog[^] interesting.
Rate this: bad
Please Sign up or sign in to vote.

Solution 4

WPF has impressive rendering capabilities, and by using RenderTargetBitmap Class[^] you can leverage that functionality to create bitmap images.

If you want to go into sub-pixel accuracy then Anti-Grain Geometry[^] may be just what you need. It's a C++ library, but you can access the functionality by leveraging C++/CLI mixed mode. What you get out of anti-grain is "professional" quality imaging capabilities.

If you want to look at a complete imaging solution gimp[^], the GNU Image Manipulation Program, can be used as a learning source. It's open source.

Anti-Grain and gimp goes beyond what's currently available in WPF in their respective areas - obviously you can use them as background material if you want to accomplish something similar using c# and WPF.

Espen Harlinn
Manfred R. Bihy 9-Feb-11 17:41pm
Good answer! 5+
Espen Harlinn 10-Feb-11 15:35pm
Thank you Manfred!
Abhinav S 10-Feb-11 8:11am
Nice answer (much better than mine). 5.
Espen Harlinn 10-Feb-11 15:36pm
Thank you Abhinav!
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

I think WPF is much better choice for image manipulations than System.Windows.Forms. Probably, the most important feature is that WPF operations are not strictly pixel-based, but direct access to pixel is very well designed. It is better even for non-basic image processing (can be very advanced, in fact).

Performance is better because WPF is based on DirectX, presentation itself is better. The WriteableBitmap does not require unsafe, unlike System.Drawing, direct bit manipulation is very logical and well designed for performance.

The set of available tools for manipulation is also much better. All that trouble most people have is related to prior experience with GDI/GDI+. All performance problems I know is related to misuse of the techniques. WPF is very different and needs understanding.

Espen Harlinn 9-Feb-11 17:06pm
Good answer :)
SAKryukov 9-Feb-11 17:28pm
Thank you, Espen.
Manfred R. Bihy 9-Feb-11 17:41pm
Good one! 5+
SAKryukov 9-Feb-11 17:47pm
No superfluous words this time?
Thank you, Manfred.
Manfred R. Bihy 9-Feb-11 18:14pm
I'm never too sure about what exactly the right number of words is. :)

Too much elaboration can distract from the essence and too little will leave to much room for interpretation. The afore mentioned is true for both questions and answers. You could say I'm linguistically inclined, but I'm still unsure of what is enough and what is too lacking.

At least I try to think about it. :)

The answers you tend to give are very rich information wise which I find quite refreshing, but i fear that some your elaborations are lost on the general audience. Nevertheless keep up the good work. :thumbsup:
SAKryukov 9-Feb-11 19:50pm
I don't think this is the biggest sin of mine.

Many ears ago a friend of mine gave me his great idea (I would classify into the field practical ethics) of "respect by default". You make assumptions if favor of the person you don't know well to the maximum possible degree, even if it seems unrealistic. "By default" the person is treated as the best you can possibly expect in the current situation. When you start dealing with such person, you might see the mistake you make, but this mistake is in the positive direction. In real life this fails because values are ordered in different ways.
I have long time experience with little kids, so I know what I'm talking about. Sometimes you can explain complex scientific stuff if you know the best thing: how to provoke questions.
JF2015 10-Feb-11 1:16am
Once again a very good advice. 5+
SAKryukov 10-Feb-11 13:17pm
Thank you very much.
Abhinav S 10-Feb-11 8:11am
Nice answer. 5.
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

I think using WPF is perfectly OK as long as you stick to basic image manipulation.

Probably the biggest problem is the fact that the WPF rendering system is not strictly pixel-based. WPF works with device-independent units instead of pixels, which brings, for example, very smooth rendering of vector shapes. However, it could happen that your 640x480 bitmap image scaled to 100% does not occupy exaclty 640x480 pixels on the screen which is definitely not what you need in an image-editting application. There are also small problems with zooming etc...

Another problem is that you can't easily work with the raw bitmap data (although you can use WriteableBitmap or the workaround Abhinav S posted), which brings performance problems.

On the other side, GPU-accelerated shader effects can be used to provide immediate previews of complex operations and keep the UI fully responsive...

To sum it up, WPF has many limitations as well as many advantages, and I wouldn't recommend it for a complex image-processing application.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web02 | 2.8.170622.1 | Last Updated 9 Feb 2011
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100