Storing the file in the DB (be it an image or otherwise) is generally considered bad practice because it bloats the database, can't be used against searches, and may cause row results to be bloated if they include the column containing the file.
Having the image in the DB also makes it difficult for other programs to interact with the files. A common operation is to automatically generate thumbnail versions of images for previews of a larger image.
You are better off storing the file directly on the hard drive using Django's standard file fields, which simply stores the location of the file on the hard drive along with some other Meta data.
You have a choice. If you store the raw byte string in a local file without converting it, use a File fields. If you plan to convert the file to a real image format before saving it, use an ImageField.
If there is no other reason to convert it and there is a chance that the file will not be accessed later (or infrequently), then you may be able to save some processing by not converting the file until it is later accessed, converting it on the fly as you serve it out. If the images are likely to be accessed later or more than once, it's probably better to convert them up front so you can perform a straight file transfer later, which will be cheaper on resources in the long run.
You're likely receiving a base 64 encoded byte string (or some variant of that).
It doesn't matter what format the bytes will ultimately take on, it's still a bad idea for the reasons I outlined above.
Django does have a BinaryField if you really have your heart set on it:
-James