While WPF probably does have drawing capabilities, it is really a completely different UI toolkit than WinForms. If you are planning on porting your app to WPF eventually, I could see drawing your image using it, but otherwise I don't really see why you'd want to introduce WPF just to draw one image. That seems like overkill to me.
You can find out more about WPF at MSDN or WindowsClient.net.
Indeed, you cannot base your decision wheter to go for WPF / Winform based on whether you want to draw the above thing. You will be able to draw the above thing in System.Drawing without much problem.
More interesting would be the following: Is the above artefact represented by some complex object? In that case you can teach WPF to just render said object in the above way. If you have a program that e.g. dynamically changes essential dimensions, then you can tell WPF that if you change those values in your object, the display of it must be altered as well.
All in all the two technologies are quite different, however, I would deem WPF to be the more complete one - even so, personally I think WPF came a few years too early, considering how slow adoption is compared to its possibilities.
WPF is a new framework for standard GUI controls (buttons, textboxes, etc.) but for drawing custom images, especially if they are not controls, it's virtually the same as WinForms.
There are some drawing differences, due to the fact that WinForms uses GDI to draw and WPF uses DirectX, but for straight drawing both are mostly equivalent.
Now, if the drawing was an interactive control, then WPF has the advantage because it is much easier to customize the drawing of a standard control than in WinForms.
So the question becomes, what does the drawing do? Could a standard control do the same function if you could just change it's appearance? If so then WPF is what you need.