J2ME: Thumbnails Extraction of JPEG (Exif) Images made with Mobile Phone Camera

Mobile Phones Cameras, being digital, make pictures/images in JPEG format particularly ‘Exif’ flavor of JPEG format. Exif has been decided as a standard for Digital Cameras. We are not going to discuss the process involved in the creation of JPEG images i.e. the encoding process of a raw image into compressed JPEG image which essentially involves three steps in order of Discrete Cosine Transform(DCT), Quantization and Entropy (Huffman) Encoding. Here we are concerned about how data is organized that is the ‘FORMAT’ once a JPEG image has been created. However we do need a JPEG decoder for thumbnail extraction, there is one freely available. First we talk a little about JPEG format and its Exif flavor.
Few Words on JPEG format
A JPEG (jpg) file is organized in order of markers along with their contents. Each marker itself takes 2 bytes. The very first marker (0xFFD8) stands for Start of Image (SOI). This declares that this is a JPEG file. The second marker is (APPn) that depends upon the application using JPEG hence the marker contains an identifier in its contents indicating the application. The marker have any value from APP0 (0xFFE0) to APP15 (0xFFEF) both inclusive.
In JPEG format, immediate 2 bytes after each marker contain the length of the marker’s contents including the length field itself, so is the case with APPn marker. APP0 (0xFFE0) belongs to ‘JFIF’ marker while APP1 (0xFFE1) to ‘Exif’ marker (We are interested in APPn marker particularly APP1 (0xFFE1) marker for extracting thumbnail which is already embedded in the file within this marker). In APPn, after length field, following bytes contain the ASCII code equivalent of the identifier name (5 bytes for ‘JFIF’ and 6bytes for ‘Exif’). Please see the NOTE below. The Exif identifier is 45, 78, 69, 66, 00, 00 (6 bytes). From there on, Exif format is same as TIFF image format is. More detail on Exif (and its embedded TIFF) please see here. After reading a specific number of offset bytes when thumbnail offset is reached, it could be in one of three formats JPEG compressed (most commonly used), RGB TIFF or YCbCr TIFF (The number of offset bytes depends upon ‘byte align’ discussed below). If JPEG compressed, it is just like another JPEG image of a cut down scale which is decoded for display. (I have tried on Sony Ericson K800i and Nokia 6630, both of them had the thumbnail in JPEG Compressed format hence our discussion pertains to this only). Another important thing about TIFF header (8 bytes), embedded in Exif format, is that its first 2 byte informs you about the byte align of TIFF data to be followed that is either little endian (used by Intel) or big endian (used by Motorola). So you have got to look for this thing to calculate the offset while reading Exif file in general and TIFF file in particular. JPEG generally uses big endian however Exif allows both of them. Moreover, most of the digital cameras using Exif format follow little endian. Also remember that all the offset in TIFF are calculated from the first byte of the TIFF header.
NOTE
In case of JFIF, last byte out of 5 contains zero while last two bytes in case of ‘Exif’ contain zero, for example, 4A, 46, 49, 46, 00 (5 bytes)for JFIF. The JFIF v1.02 and above have JFIF extension according to which APP0 has extension part which again starts with application marker hence making two APP markers. The thumbnail may be located either under first marker or under second marker For more detail on JFIF , please see here.
...continued

JDOM vs DOM4J

Bear in mind, JDOM and DOM4J are java API for XML processing. JDOM is open source pure Java API for XML processing. JDOM is not an extension or wrapper over W3C DOM model. JDOM is an object model in java that stands for XML document that is the same model as of DOM. JDOM does use SAX API with XML parser (Xerces or Crimson or any other) at the back end to establish the in-memory tree based model.
Note: JDOM uses the defaults parser of JAXP as it calls the parser through JAXP, however, it can be changed to any other parser (Please see the previous post).
You can find this description on the following this link. Like DOM and unlike to SAX, JDOM provides random access to contents of the document hence allowing to update it. JDOM is compatible for conversion to DOM Model or SAX Events and vice versa. Please see this. Unlike DOM, JDOM doesn’t work through interfaces rather it has concrete classes for different components of the model i.e. node, element, attributes etc.
DOM4J, on the other hand like DOM, has done it other way round than JDOM. DOM4J is also XML Processing APIs and follow the same tress based object model for XML document. DOM4J works through interfaces rather than concrete classes. That’s the major difference between DOM4J and JDOM. DOM4J makes navigating along the tree easier than JDOM due to this difference. DOM4J also provides some support for XPath (which, unfortunately, I didn’t get a chance to explore).
The purpose of this and the last three posts is to have a clear understanding of what is what in the area of XML Parsing. I haven’t provided any code here because there is huge coding stuff available on the web for this purpose. I’ll get back to each of them with more detail some other time (fingers crossed!!).

JAXP: Another Player in Java-XML Game

JAXP stands for ‘Java API for XML Processing’. Please, don’t confuse it with other APIs like SAX, DOM, JDOM etc. JAXP is a set of APIs for XML processing making a rather abstract layer in the overall scheme of XML processing. SAX, DOM and JDOM are parsing APIs only, used in parsing of XML document, while JAXP has a broader spectrum of its application, it lets you parse, validate and transform XML documents, here we are concerned with the parsing feature of it however. Remember, JAXP is not parsing APIs nor is it a new way of XML handling in java. As a matter of fact, JAXP provides a convenient way of XML processing. As said before, JAXP exists at the abstract layer; it uses a parser behind the scenes for parsing purposes. JAXP is a bundle of some APIs and a parser. Previously, JAXP was bundled with Crimson parser as the default one; however, JAXP provides the facility to change to some other parser without recompiling the application which has several benefits. (Details can be found on the following link.) These parsers in turn implement SAX, DOM or some other parsing APIs. We are not going into much detail here; please refer to All About JAXP for detail on JAXP along with example code too, this tutorial on JAXP provides quite a comprehensive detail on JAXP highlighting its parsing and validation feature.

When to use SAX and DOM?

This question doesn’t have any straight or fix answer because it really depends upon the situation. Different parameters (memory, speed etc) have to be taken into consideration to make this decision. We go through some of points that will be helpful in making the decision which API should be used in which situation.

• DOM is memory intensive while SAX is not, because DOM creates a Document object in memory using a tree data structure while SAX does not create any such default object in memory rather uses custom object which makes SAX less memory intense.
• DOM is slower than SAX for the same reason as of memory.
• DOM provides a random access to the XML contents of the document having them in memory while SAX provides sequential access to the contents as it has access to one part of the document at a time.
• DOM has an edge over SAX that it provides ability to modify the document which is not the case with SAX. This implies that if client application is concerned about the location of different elements within the document (may be to modify it) then DOM is the option, however, if it’s concerned with individual elements then SAX is the right option.
• From a parser’s point of view, there is nothing much to do for a parser for SAX. There are few interfaces to be implemented for SAX for parser while this is not the case with DOM. Most of the parsers support both of these models.

Based on these points, you can have some idea which model is the most suitable to your needs!!

XML Parsing

With respect to XML document parsing particularly with Java, things have been quite puzzling, at least for me! Jargons like DOM, SAX, JDOM, dom4j etc made things quite confusing! I am going to put up my finding on the issue, from different sources, to share with others, hope it helps. Please correct me or share with me if I am wrong on something or if something is missing!! Let us talk a little about DOM and SAX first then JDOM and dom4j.
Generally an XML document can be parsed in one of two ways either via Document Object Model (DOM) that’s been specified by W3C or via Simple API for XML (SAX).
By looking at an XML document (at least a well-formed one), it’s quite simple to say that it has a tree like structure e.g. root node(root element), child nodes, sub-child nodes etc. So we can infer that a tree structure will help us access the contents within the document, tree data structure for instance!!! This is the approach around which DOM APIs are based on. On the other hand, XML document contents can also be accessed by the reading the document sequentially, very much like humans do while reading a book, that’s where SAX APIs have originated from!! !
Document Object Model, or DOM, is a platform and language-independent API from W3C for accessing and modifying XML documents. A DOM based parser reads the whole XML document in one go and keeps it in memory in tree-like structure where each node of the tree stands for an element of the document. Once in memory, parser provides methods to access the contents. The XML document is read line by line and as element(s) are encountered, the corresponding tree is built on. DOM enables navigation along the built tree in any direction providing random access to any node.
Simple API for XML, or SAX, is API collection of Callbacks for sequential parsing of the XML document. SAX based parsers are event-driven parser, these parsers parse XML document sequentially without storing the structure into the memory that makes SAX memory efficient as compared to DOM. The events issued by the parser are: start and end of the document, start and end of each tag, comments and processing instructions. SAX based parsers, being sequential, provides access to only one bit of the document at a time.

Remember: SAX and DOM are just APIs for parsing XML document, (so are JDOM and Dom4j as we’ll discuss them later) and are not parsers!!! You do need DOM, SAX or any other parsing API to parse XML Document. A parser can be based on either of the APIs.

SAX and DOM APIs have evolved as specifications that describe how XML parsers can pass contents of an XML documents to client applications through different interfaces which are implemented by XML parsers. Though first developed for Java, APIs were later developed for other major programming languages. There are number of parsers available Apache Xerces, Sun Crimson, Oracle’s XML Parser, MSXML etc. Apache Xerces and Crimson have been included in the JDK 1.5 and later.

SAX and DOM APIs are different with respect to their structure as explained above that is SAX is an event based collection of Callbacks while DOM is in-memory tress structure. Thus DOM uses tree data structure while does SAX doesn’t use any until done so manually which essentially means that a parse tree can also be constructed with event based API.

Next time we'll discuss a comparison of DOM and SAX