In brief, it won't. The two CLR runtimes are completely different, although they have similar interfaces.
There are three caveats to this:
(1) If you have the source code, and that code doesn't depend on anything Silverlight doesn't support, you can try cross-compiling it for Silverlight, by referencing the source files in a Silverlight project. Sometimes you can get it to work with minor source tweaks, or judicious use of #if defines. Sometimes you can't.
(2) In Silverlight 4/.NET 4, you can sometimes reuse assemblies compiled for Silverlight in .NET. The CLR team has a blog post explaining how it works. This is a pretty limited solution, however, because (a) the assemblies first have to be compiled for Silverlight, and (b) these portable assemblies can only call a small set of other assemblies which are themselves portable, such as Mscorlib, System, System.Core, and so forth. (I should note that this won't work for you, since you're targeting WP7, which is based on Silverlight 3.)
(3) You can occasionally muck about with the DLL internals and hack the compiled DLL into believing it's a Silverlight DLL. There's a blog post about how to do it here. But again, this is a pretty limited solution, because the assembly can't call any methods or assemblies that aren't included in Silverlight. This includes some pretty basic things, like some of the overrides for Buffer.BlockCopy(), that sort of thing. I'd be surprised if this technique worked with a complex commercial image-processing DLL, but stranger things have happened.