Click here to Skip to main content
15,896,727 members
Articles / Multimedia / GDI+
Article

A library to simplify access to image metadata

Rate me:
Please Sign up or sign in to vote.
4.84/5 (32 votes)
3 Aug 20044 min read 282.7K   10.1K   115   48
A library to simplify access to image metadata.

Introduction

Several image file formats enable you to store metadata along with an image. Metadata is information about an image, for example, title, width, camera model, and artist. Microsoft Windows GDI+ provides a uniform way of storing and retrieving metadata from image files in the Tagged Image File Format (TIFF), JPEG, Portable Network Graphics (PNG), and Exchangeable Image File (EXIF) formats. In GDI+, a piece of metadata is called a property item, and an individual property item is identified by a numerical constant called a property tag.

In .NET Framework, you can store and retrieve metadata by calling the SetPropertyItem and GetPropertyItem methods of the Image class, and you don't have to be concerned with the details of how a particular file format stores that metadata.

Another question is how can you use this data. You will receive just an array of bytes, and it is your problem how you interpret it. This library will simplify access to this image metadata by converting them to ordinary .NET data types and organizing them in the form of class properties and/or hashtable.

The primary source of information to write this class was MSDN.

MSDN Home > MSDN Library > Graphics and Multimedia > GDI+ > GDI+ Reference > Constants

I'd like also to thank Jeffrey S. Gangel whose article "Photo Properties" at CodeProject brought me to the idea to write this class. His program makes basically the same, the only difference is that I wanted to have image information in the form that seems to me to be more comfortable and conventional.

Not all image property tags are implemented as class properties. Those are accessible only from PropertyItems hashtable. If anyone needs this library at all and even needs the specific property, I'll be very glad to help him. But I think it is not necessary, because the whole source code is available and modifiable.

Usage

C#
// Accessing image proprties
public void ShowEquipModel() 
{ 
    Info inf=new Info("c:\\tmp\\Example.jpeg"); 
    MessageBox.Show(inf.EquipModel);
}
C#
// Accessing image proprties as a hastable 
public void ShowAllProperties() 
{ 
    Info inf=new Info("c:\\tmp\\Example.jpeg");
    listView.Items.Clear(); 
    foreach (string propertyname in inf.PropertyItems.Keys) {
        ListViewItem item1 = new ListViewItem(propertyname,0);
        item1.SubItems.Add((inf.PropertyItems[propertyname]).ToString());
        listView.Items.Add(item1); 
    } 
}

The properties of the Info class are listed below:

  • Brightness

    Brightness value. The unit is the APEX value. Ordinarily, it is given in the range of -99.99 to 99.99.

  • Copyright

    Copyright information.

  • DateTime

    Date and time the image was created.

  • DTDigitized

    Date and time when the image was stored as digital data. If, for example, an image was captured by DSC and at the same time the file was recorded, then DateTimeOriginal and DateTimeDigitized will have the same contents.

  • DTOrig

    Date and time when the original image data was generated. For a DSC, the date and time when the picture was taken.

  • EquipMake

    The manufacturer of the equipment used to record the image.

  • EquipModel

    The model name or model number of the equipment used to record the image.

  • ExposureProg

    Class of the program used by the camera to set exposure when the picture is taken.

  • FNumber

    F number.

  • FocalLength

    Actual focal length, in millimeters, of the lens. Conversion is not made to the focal length of a 35 millimeter film camera.

  • Image

    Sets or returns the current Image object.

  • ISOSpeed

    ISO speed and ISO latitude of the camera or input device as specified in ISO 12232.

  • MeteringMode

    Metering mode.

  • Orientation

    Image orientation viewed in terms of rows and columns.

  • PixXDim

    Type is PropertyTagTypeShort or PropertyTagTypeLong. Information specific to compressed data. When a compressed file is recorded, the valid width of the meaningful image must be recorded in this tag, whether or not there is padding data or a restart marker. This tag should not exist in an uncompressed file.

  • PixYDim

    Type is PropertyTagTypeShort or PropertyTagTypeLong. Information specific to compressed data. When a compressed file is recorded, the valid height of the meaningful image must be recorded in this tag whether or not there is padding data or a restart marker. This tag should not exist in an uncompressed file. Because data padding is unnecessary in the vertical direction, the number of lines recorded in this valid image height tag will be the same as that recorded in the SOF.

  • PropertyItems

    Returns a HashTable of all available properties of a given Image. Keys of this HashTable are display names of the Property Tags, and values are transformed (typed) data.

  • ResolutionUnit

    Unit of measure for the horizontal resolution and the vertical resolution. 2 - inch 3 - centimeter.

  • XResolution

    Number of pixels per unit in the image width (x) direction. The unit is specified by PropertyTagResolutionUnit.

  • YResolution

    Number of pixels per unit in the image height (y) direction. The unit is specified by PropertyTagResolutionUnit.

See also

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


Written By
Software Developer
Germany Germany
Tweeter: @gmamaladze
Google+: gmamaladze
Blog: gmamaladze.wordpress.com

Comments and Discussions

 
GeneralICM INFO Pin
AndE0026-Feb-05 4:39
AndE0026-Feb-05 4:39 
GeneralEXIF data Pin
barichter24-Feb-05 3:48
barichter24-Feb-05 3:48 
GeneralDispose missing Pin
Michael Wolber11-Jan-05 4:54
sussMichael Wolber11-Jan-05 4:54 
GeneralRe: Dispose missing Pin
mimuel3-Oct-05 8:46
mimuel3-Oct-05 8:46 
GeneralImageDescription Pin
i386.com7-Oct-04 4:50
i386.com7-Oct-04 4:50 
GeneralRe: ImageDescription Pin
jwsadler29-Aug-06 2:35
jwsadler29-Aug-06 2:35 
GeneralImage check Pin
btvbtv29-Sep-04 0:11
btvbtv29-Sep-04 0:11 
GeneralRe: Image check Pin
George Mamaladze29-Sep-04 1:38
George Mamaladze29-Sep-04 1:38 
The simplest way is to open a file stream and read first four bytes. They must by FF D8 FF E0. There are some special cases (less than 1%) which does not pass under this schema. Fore more information see an article below.


Subject: [15] How do I recognize which file format I have,
and what do I do about it?

If you have an alleged JPEG file that your software won't read, it's likely
to be some proprietary JPEG-based format. You can tell what you have by
inspecting the first few bytes of the file:

1. A JFIF-standard file will start with the four bytes (hex) FF D8 FF E0,
followed by two variable bytes (often hex 00 10), followed by 'JFIF'.

2. If you see FF D8 FF at the start, but not the 'JFIF' marker, you
probably have a not-quite-JFIF JPEG file. Most JFIF software should
read it without complaint. If you are using something that is picky
enough to complain about the lack of a JFIF marker, try another decoder.
(Both very old JPEG files and very new ones may lack JFIF markers ---
the new SPIFF standard mentioned above doesn't use a JFIF marker.
So gripe to your software vendor if you find this to be the problem.)

3. A Macintosh PICT file, if JPEG-compressed, will have several hundred
bytes of header (often 726 bytes, but not always) followed by JPEG data.
Look for the 3-byte sequence (hex) FF D8 FF. The text 'Photo - JPEG'
will usually appear shortly before this header, and 'AppleMark' or
'JFIF' will usually appear shortly after it. Strip off everything
before the FF D8 FF and you will usually be able to decode the file.
(This will fail if the PICT image is divided into multiple "bands";
fortunately banded PICTs aren't very common. A banded PICT contains
multiple JPEG datastreams whose heights add up to the total image
height. These need to be stitched back together into one image.
Bailey Brown has some simple tools for this purpose on a Web page at
http://www.isomedia.com/homes/bailey/photo-jpeg/photo-jpeg.html.)

4. If the file came from a Macintosh, it could also be a standard JFIF
file with a MacBinary header attached. In this case, the JFIF header
will appear 128 bytes into the file. Get rid of the first 128 bytes
and you're set.

5. Anything else: it's a proprietary format, or not JPEG at all. If you
are lucky, the file may consist of a header and a raw JPEG data stream.
If you can identify the start of the JPEG data stream (look for FF D8),
try stripping off everything before that.

At least one release of HiJaak Pro writes JFIF files that claim to be
revision 2.01. There is no such spec; the latest JFIF revision is 1.02.
It looks like HiJaak got the high and low bytes backwards. Unfortunately,
most JFIF readers will give up on encountering these files, because the JFIF
spec defines a major version number change to mean an incompatible format
change. If there ever *were* a version 2.01, it would be so numbered
because current software could not read it and should not try. (One wonders
if HiJaak has ever heard of cross-testing with other people's software.)
If you run into one of these misnumbered files, you can fix it with a
binary-file editor, by changing the twelfth byte of the file from 2 to 1.

Nicholas Sherlock
GeneralRe: Image check Pin
Slackshot13-Feb-07 12:27
Slackshot13-Feb-07 12:27 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.