I am building a service that uploads images from a client to a UNC share. The service is built with WCF (what else) and I must say it is pretty slick.
To serialize images, you basically convert the bits into a byte array, serialize the array and away you go.The service I am working on takes advantage of the MTOM (Message Transmission Optimization Mechanism) encoding, which significantly improves the perfornance of larger payloads, which are usually common when dealing with images.
MTOM is a good choice when you are working with large binary attachments, regardless of transport protocol. For example, if you are using HTTP, MTOM is an excellent choice for optimizing the handling of binary data. In addition, TCP will also gain substantial improvements from using MTOM for large binary attachments.
One of the things you should know when dealing with larger message sizes, specifically, those that exceed 65K. Attempting to submit an image (message) larger than 65K will result in a 400 Bad Request error at the server.
Once you have a good idea of how large the images are going to be, you will want to adjust the maxReceivedMessageSize property on the binding of choice. The default is 65K which may be too small for most scenarios, even with low res images. Below is an example of a custom binding configuration you can use when using large message uploads:
<binding name="basicHttpOptimized" maxReceivedMessageSize="2000000" messageEncoding="Mtom">
<readerQuotas maxArrayLength="2000000" />
Notice the messageEncoding is set to "Mtom", and I've set the maxReceivedMessageSize to 2MB, matching it with the readerQuota. Both are just many of the switches and knobs at your disposal in WCF configuration and is another great example of how WCF is secure by default.
While MTOM does optimize large binary transfers, there is a point of diminishing returns if the binary data is not big enough to really get a boost from MTOM. For example, the payload of a moderate binary upload may be smaller than that of which is MTOM encoded because the MIME notation itself does introduce a swell in message size.
As a rule of thumb, always do some performance testing to ensure that you aren't hititng the head of a pin with a sledgehammer.