Introduction

ExifLib simply reads Exif tags (i.e., camhera model, GPS data, date picture taken, shutter speed etc.) from JPEG files, without the overhead introduced by using the GDI+ classes located in System.Drawing.Imaging, and with less lines of code for the developer.

Background

I've been using a simple command line application to move my photos into subdirectories based on the date on which they were created. As with all other .NET Exif implementations I've seen, I was using the PropertyItem class located in System.Drawing.Imaging. While this does the job, I often found myself processing thousands of images at a time, and the .NET classes were just too slow for the job. ExifLib goes back to the JPEG/TIFF standard itself, and only reads the essentials, using little more than the file input classes in System.IO.

Using the Code

ExifLib is very simple, with only one class and one enum in the namespace. Just add a reference to ExifLib.dll, and you're good to go! An example follows:

Note that the ExifReader class holds the image file open, so once you're finished with the reader, be sure to call its Dispose method, either explicitly, or implicitly through a using statement (as in the above example).

How it works

Exif data is stored in the JPEG header, inside the APP1 block. This block contains a number of IFDs (image file directories). These include the EXIF IFD and the GPS IFD, which contain the tags available for retrieval by this library.

The IFDs start with a catalogue of EXIF tags and the stream offsets to where the data for each tag is stored. On instantiation, the library creates a Dictionary of these tag offsets, which are accessed during retrieval of a specific tag's value. It's this lazy retrieval which gives the library its speed, as most EXIF use-cases only involve retrieving a handful of tag values, so there's little use in retrieving tag values before they're required.

Points of Interest

Something strange that I learned while writing this library is that while JPEG stipulates "Big Endian" encoding (i.e., numbers read from left to right), the TIFF standard allows Big or Little Endian encoding. Since the Exif tags are encoded using TIFF encoding, often the JPEG will be read using "Big Endian" encoding until the TIFF section is reached, at which point the encoding reverses and the rest of the document is read using "Little Endian" encoding.

During coding, I realised from a comment on the ExifWorks CodeProject article that it's possible to increase performance when using System.Drawing.Image by setting the constructor's validateImageData parameter to false. However, even when using this enhancement, ExifLib still performs 50% faster, possibly because it does not read the tag values until they're requested. I have also noticed that ExifLib performs similarly with small (<1MP) images, but scales better when loading larger images. The screenshot at the top of this page was produced using a 12MP image.

History

Version 1.1

Array extraction has been added, thanks to a comment from Justin Carasick. This is used in various fields, including GPS coordinates and Exif versioning. The previous version of ExifLib would only return the first element from an array.

Version 1.2

Fixed bug when retrieving data for fields shorter than 4 bytes, thanks to a comment from bartsy. The previous version of ExifLib would lose important data from these fields when processing big-endian encoded files.

Updated the project to Visual Studio 2010, refactored a little of the code. The project is still .NET 2.0+.

Version 1.3

Added the ability to extract JPEG encoded thumbnails from images, thanks to a comment from StyrianOak. Note that uncompressed (i.e. TIFF) encoded thumbnails are not supported, but since any camera which supports the DCF standard will produce JPEG thumbnails, this is a minor limitation.

Version 1.4

Added a constructor overload to allow reading of JPEG data from any seekable stream

Modified code to allow compiling for Windows Phone and Silverlight. The NuGet package now includes Windows Phone and Silverlight DLLs.

Share

About the Author

Simon McKenzie has been working as a developer for 10 years, primarily in .NET, with interests in imaging and GIS, particularly on mobile platforms. He is the author of the award winningMapSnap GPS, a moving map application for Windows Phone. He's also the author of the popular (free) high-speed ExifLib EXIF extractor for .NET.

Comments and Discussions

When converting the tagdata to ushort, the bytes are reversed in case of big endian.For example: orientation 0800 becomes 0080. This results always in zero when converting to ushort.This is due to a bug in GetTagBytes.

From the spec "4.6.2 IFD Structure""In cases where the value fits in 4 bytes, the value itself is recorded.If the value is smaller than 4 bytes, the value is stored in the 4-byte area starting from the left,i.e., from the lower end of the byte offset area. For example, in big endian format,if the type is SHORT and the value is 1, it is recorded as 00010000.H.