determine if blob is an image without loading entire field?

Question

is there a way to read only a few bytes out of a BLOB type field in a database (for this question it doesn't matter the DB brand) and determine if the binary content is an image (assume it is one of: JPG, GIF, PNG)? I have a webapp that stores files in the database, and if it is an image, I want to show a thumbnail, otherwise I want to show an icon... but I don't have any MIMETYPE info stored anywhere else for the blob (it's not my design)... and because it is a webapp, the loading of the image needs to occur in a separate call (getImage.ashx) from writing out the <img> tag.. and when I'm writing out the tag I don't want to have to read the entire blob into a library, determine if it is an image, resize it... etc etc ... I'd like to be able to look at the first few bytes and know whether I need to write the tag or not. I don't understand image file structures/formats well enough to know if there is some sort of standard header in the first few bytes that I could read in to tell if it is a JPG, GIF, or PNG.

make sense?

if you want to help me specifically (instead of generally answering whether it can be done) then I'm using .NET C# and SQL 2005

Thanks!

Answer 1

PNGs start with: 89 50 4E 47 0D 0A 1A 0A ; see http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html

GIFs start with 47 49 46 38 37 61 (GIF87a) or 47 49 46 38 39 61 (GIF89a) ; see http://www.fileformat.info/format/gif/egff.htm

JPEGs start with FF D8 FF E0 xx xx 4A 46 49 46 00 (EDIT: adding missing portion of the header; xx xx is the header length, in bytes) ; see http://www.obrador.com/essentialjpeg/headerinfo.htm

reference: http://wangrui.wordpress.com/2007/06/19/file-signatures-table/

Answer 2

• JPEG files start with FF D8 FF
• GIF files start with GIF89a (47 49 46 38 39)

Answer 3

This is taking it back to the old school (for data access tactics). Anyhow, you can use a DataReader to grab the field and stream results, then just look at the firs 8 bytes to see what kind of image you are dealing with.

See this article for an intro on how to attach a streamreader to your datareader.

All that said, I would probably just get all the bytes unless the images are ginormous, mainly because any speed you gain from examining the header could be lost when dipping into the well a second time.

Another tactic might be to create a view which inspects the field and exposes the type, based on the first header bytes, in SQL. Kind a ugly but works in a pinch.