WAP Architecture - Part VII

Conformance and Interoperability

The WAP Forum views vendor interoperability as an important element to the success of WAP products. In order toprovide as high a probability as is technically possible that two WAP products developed independently by twodifferent vendors will successfully interoperate, a rigorous definition of conformance, compliance, and testing has beendeveloped.

Conformance answers the question, “Does an implementation meet the standard as written?” The WAP Forum chartersa neutral third party to build a comprehensive test suite from its specifications. Usually, implementations are testedagainst known references.Interoperability answers the question, “Will this implementation work with other products developed to the samestandard?”

Interoperability testing uses a test suite designed to test implementation to implementation compatibility,and implementations are tested against each other. Interoperability testing is not focused on compliance—two productswith the same non-compliant implementation will be interoperable.

The WAP Forum Certification Program is focused on conformance, but offers some interoperability testing as well.The Certification Program covers the entire value chain as shown in Figure 13.

To improve interoperability at the authoring level, the WAP Forum provides authoring guidelines to improve theaccessibility of WAP content. To certify WAP clients and servers, the WAP Forum conducts interoperability testing ofan implementation against multiple reference implementations using a predefined suite of test cases.

The WAP Forum has defined a number of Class Conformance Profiles, e.g. Class A, Class B, and Class C. Animplementation may be certified in one or more class. The class conformance requirements are specified in[ClassConform].

Each WAP Specification includes static conformance requirements (SCRs) for that specification. These define whichfeatures are mandatory and optional and are the basis for the conformance test suite.

Reference : Wireless Application Protocol Forum, Ltd, 2000-2001

WAP Architecture - Part VI

Sample Configurations of WAP Technology

Example WAP 1.x Gateway

Example WAP HTTP Proxy with Profiled TCP and HTTP

Example WAP Proxy Support for TLS Tunneling

Example Direct Access

Dual Stack Support

WAP Architecture - Part V

Components of the WAP Architecture
The WAP architecture provides a scaleable and extensible application development environment for mobilecommunication devices. This is achieved through a layered design of the protocol stack (Figure 7). Each layer providesa set of functions and/or services to other services and applications through a set of well-defined interfaces. Each of thelayers of the architecture is accessible by the layers above, as well as by other services and applications.

The WAP architecture separates service interfaces from the protocols that provide those services to allow for evolutionof the specifications and selection of the most appropriate protocol for a given context. Many of the services in thestack may be provided by more than one protocol. For example, either HTTP [RFC2616] or WSP [WSP] may providethe Hypermedia Transfer service.

Bearer Networks

Protocols have either been designed or selected to operate over a variety of different bearer services, including shortmessage, circuit-switched data, and packet data. The bearers offer differing levels of quality of service with respect tothroughput, error rate, and delays. The protocols are designed to compensate for or tolerate these varying levels ofservice.

Since the Transport Services layer provides the interface between the bearer service and the rest of the WAP stack, thetransport specifications (e.g., [WDP]) may list the bearers that are supported and the techniques used to allow theprotocols to run over each bearer. The list of supported bearers will change over time with new bearers being added asthe wireless market evolves.

Transport Services

The Transport Services layer offers a set of consistent services to the upper layer protocols and maps those services tothe available bearer services. The Transport Services transport unstructured data across the underlying bearer networks.These transport services create a common abstraction that is consistent across all the bearers.

The Transport Services include, but are not limited to:

· Datagrams – The datagram service provides data transport in which self-contained, independent entities of datacarry sufficient information to be routed from the source to the destination computer without reliance on earlierexchanges between this source and destination computer and the transporting network. UDP (User DatagramProtocol) [STD0006] and WDP (Wireless Datagram Protocol) [WDP] are two protocols used to provide thedatagram transport service in the WAP architecture.

· Connections – The connection service provides data transport service in which communication proceeds in threewell-defined phases: connection establishment, two-way reliable data transfer and connection release. TCP(Transmission Control Protocol) [STD0007] is a protocol used to provide the connection transport service of IP1bearers for the WAP architecture. In order to cope with the wireless network characteristics, the TCP protocol canbe profiled for its use, see [WP-TCP].

Transfer Services

The Transfer Services provide for the structured transfer of information between network elements.

The Transfer Services include, but are not limited to:

· Hypermedia Transfer – The hypermedia transfer services provides for the transfer of self-describing hypermediaresources . The combination of WSP (Wireless Session Protocol) [WSP] and WTP (Wireless Transaction Protocol)[WTP] provide the hypermedia transfer service over secure and non-secure datagram transports. The HTTP(Hypertext Transfer Protocol) [RFC2616] provides the hypermedia transfer service over secure and non-secureconnection-oriented transports.

· Streaming – The streaming services provide a means for transferring isochronous data such as audio and video.

· Message Transfer – The message transfer services provide the means to transfer asynchronous multimediamessages such as email or instant messages. MMS Encapsulation [MMSEncapsulation] is a protocol used totransfer messages between WAP devices and MMS servers.

Session Services

The session services provide for the establishment of shared state between network elements that span multiple networkrequests or data transfers. For example, the Push session establishes that the WAP Device is ready and able to receivepushes from the Push Proxy.

The Session Services include, but are not limited to:

· Capability Negotiation – The WAP architecture includes specifications for describing, transmitting, and managingcapabilities and preference information about the client, user, and network elements. See [UAProf] for moreinformation. This allows for customisation of information and content returned by the origin server or pushed bythe application.

· Push-OTA – The Push-OTA (Over The Air) session service provides for network-initiated transactions to bedelivered to wireless devices that are intermittently able to receive data (e.g., modal devices and devices withdynamically assigned addresses). The Push-OTA service operates over the connection-oriented transport serviceand datagram transport [PushOTA].

· Sync – The Sync service provides for the synchronisation of replicated data.

· Cookies – The Cookies service allows applications to establish state on the client or proxy that survives multiplehypermedia transfer transactions. See [HTTPState] for more information.

Application Framework

The Application Framework provides a general-purpose application environment based on a combination of WorldWide Web (WWW), Internet and Mobile Telephony technologies. The primary objective of the Application Frameworkis to establish an interoperable environment that will allow operators and service providers to build applications andservices that can reach a wide variety of different wireless platforms in an efficient and useful manner.

The Application Frame work includes, but is not limited to:

· WAE/WTA User-Agent – WAE is a micro-browser environment containing or allowing for markup (includingWML and XHTML), scripting, style-sheet languages, and telephony services and programming interfaces, alloptimised for use in hand-held mobile terminals. See [WAE] for more information.

· Push – The Push service provides a general mechanism for the network to initiate the transmission of data toapplications resident on WAP devices. See [PushArchOverview] for more information.

· Multimedia Messaging – The Multimedia Message Service (MMS) provides for the transfer and processing ofmultimedia messages such as email and instant messages to WAP devices.

· Content Formats – The application framework includes support for a set of well-defined data formats, such as colorimages, audio, video, animation, phone book records, and calendar information.

Security Services

Security forms a fundamental part of the WAP Architecture, and its services can be found in many of its layers. Ingeneral the following security facilities offered are:

· Privacy – facilities to ensure that communication is private and cannot be understood by any intermediate partiesthat may have intercepted it.

· Authentication – facilities to establish the authenticity of parties to the communication.· Integrity – facilities to ensure that communication is unchanged and uncorrupted.

· Non-Repudiation – facilities to ensure parties to a communication cannot deny the communication took place.

The Security Services span all the various layers of the WAP Architecture. Some specific examples of the securityservices include:

· Cryptographic Libraries – This application framework level library provides services for signing of data forintegrity and non-repudiation purposes. See [WMLScriptCrypto] for more information.

· Authentication – The Security Services provide various mechanisms for client and server authentication. At theSession Services layer HTTP Client Authentication [RFC2617] may be used to authenticate clients to proxies andapplication servers. At the Transport Services layer, WTLS and TLS handshakes may be used to authenticateclients and servers.

· Identity – WIM provides the functions that store and process information needed for user identification andauthentication [WIM]· PKI – The set of security services that enable the use and management of public-key cryptography and certificates[WPKI], [WAPCert].

· Secure Transport – The Transport Services layer protocols are defined for secure transport over datagrams andconnections. WTLS is defined for secure transport over datagrams and TLS is defined for secure transport overconnections (i.e. TCP). See [WTLS] and [WAPTLS] for more information.

· Secure Bearer – Some bearer networks provide bearer level security. For example, IP networks (especially in thecontext of IPv6) provide bearer-level security with IPSec [RFC2401].

Service Discovery

Service discovery forms a fundamental part of the WAP Architecture and its services can be found at many layers.

Some specific examples of Service Discovery services include:

· EFI – The External Functionality Interface (EFI) allows applications to discover what external functions/servicesare available on the device.

· Provisioning – The Provisioning service allows a device to be provisioned with the parameters necessary to accessnetwork services. See [ProvArch] for more information.

· Navigation Discovery – The Navigation Discovery service allows a device to discover new network services (e.g.secure pull proxies) during the course of navigation such as when downloading resources from a hypermediaserver. The WAP Transport-Level End-to-End Security specification [TransportE2ESec] defines one navigationdiscovery protocol.

· Service Lookup – The Service Lookup service provides for the discovery of a service’s parameters through adirectory lookup by name. One example of this is the Domain Name System (DNS) [STD0013].

Other Services and Applications

The WAP layered architecture enables other services and applications to utilise the features of the WAP stack through aset of well-defined interfaces. External applications may access the various services directly. The WAP layeredarchitecture builds upon an extensible set of protocols. This allows the WAP stack to be used for applications andservices not currently specified by WAP, but deemed to be valuable for the wireless market. Such applications andservices may benefit from adding protocols or particular protocol capabilities. For example, applications, such aselectronic mail, calendar, phone book, notepad, and electronic commerce, or services, such as white and yellow pages,may be developed to use the WAP protocols.

WAP Architecture - Part IV

Supporting Servers

The WAP Architecture also includes supporting servers, which provide services to devices, proxies, and applications asneeded. These services are often specific in function, but are of general use to a wide variety of applications.

The supporting servers defined by the WAP Forum include, but are not limited to:

· PKI Portal—The PKI Portal (shown in Figure 4) [WPKI] allows devices to initiate the creation of new public keycertificates.

· UAProf Server—The UAProf Server [UAProf] allows applications to retrieve the client capabilities and personalprofiles of user agents and individual users.

· Provisioning Server—The Provisioning Server [ProvArch] is trusted by the WAP device to provide its provisioninginformation.

WAP Network Elements

A typical WAP network is shown in Figure 5.

WAP clients communicate with application servers through a number of different proxies or directly. WAP clientssupport the proxy selection mechanism that allows them to utilise the most appropriate proxy for a given service or toconnect directly to that service as necessary. Proxies can be used to augment a request. They translate between WAPand WWW protocols (HTTP, TCP), thereby allowing the WAP client to submit requests to the origin server.

Proxies may be located in a number of places, including wireless carriers or independent service providers in order toprovide feature enhancements coupled to the wireless network (e.g., telephony, location and provisioning) or tooptimise the communication between device and application server (e.g., protocol translation and cookie caching).Proxies may be located in a secure network to provide a secure channel between wireless device and the secure network.

In some instances, the device might make direct connections to application servers, for example to provide a secureconnection directly between the device and application server.

The supporting servers provide support functions required by or generally useful to devices, proxies, and applicationservers. These functions include Provisioning, PKI, user agent profiles, etc.

Device Architecture

The architecture for WAP devices is shown in Figure 6. The Application Framework provides the device executionenvironment for WAP applications. WAP applications are comprised of markup, script, style sheets and multimediacontent, all of which are rendered on the device. The WAP Application Environment (WAE) processing model definesthe structure in which these various forms of executable and non-executable content interact.

The network protocols on the WAP client are shared between client and server. They are described in further detailbelow. Content renderers interpret specific forms of content and present them to the end user for perusal or interaction.Common functions are defined to be utilised by the application framework, including persistence and data synchronisation.

The Wireless Identity Module (WIM), as specified in [WIM], contains the identity of the device and the cryptographicmeans to mutually authenticate WAP devices and servers.

The architecture also provides a mechanism to access external functions that are embedded or attached to the devicesvia the External Functionality Interface (EFI).

Security Model

WAP enables a flexible security infrastructure that focuses on providing connection security between a WAP client andserver.

WAP can provide end-to-end security between protocol endpoints. If a browser and origin server desire end-to-endsecurity, they can communicate directly using the security protocols. Moreover, the WAP specifications includesupport for application-level security, such as signed text.

WAP Architecture - Part III

The WAP Model

The WAP programming model (Figure 2) is the WWW programming model with a few enhancements. Adopting theWWW programming model provides several benefits to the application developer community, including a familiarprogramming model, a proven architecture, and the ability to leverage existing tools (e.g., Web servers, XML tools,etc.). Optimisations and extensions have been made in order to match the characteristics of the wireless environment.Wherever possible, existing standards have been adopted or have been used as the starting point for the WAPtechnology.

The most significant enhancements WAP has added to the programming model are:

· Push

· Telephony Support (WTA)





The classical request-response mechanism is commonly referred to as pull to contrast it with the push mechanism.

WAP content and applications are specified in a set of well-known content formats based on the familiar WWW contentformats. Content is transported using a set of standard communication protocols based on the WWW communicationprotocols. The WAP microbrowser in the wireless terminal co-ordinates the user-interface and is analogous to astandard web browser.

WAP defines a set of standard components that enable communication between mobile terminals and network servers,including:

· Standard naming model – WWW-standard URLs are used to identify WAP content on origin servers. WWWstandardURIs are used to identify local resources in a device, e.g. call control functions.

· Content typing – All WAP content is given a specific type consistent with WWW typing. This allows WAP useragents to correctly process the content based on its type.

· Standard content formats – WAP content formats are based on WWW technology and include display markup,calendar information, electronic business card objects, images and scripting language.

· Standard communication protocols – WAP communication protocols enable the communication of browserrequests from the mobile terminal to the network web server.

The WAP content types and protocols have been optimised for mass market, hand-held wireless devices.


Feature/Performance-Enhancing Proxies

WAP utilises proxy technology to optimise and enhance the connection between the wireless domain and the WWW.

The WAP proxy may provide a variety of functions, including:

· Protocol Gateway – The protocol gateway translates requests from a wireless protocol stack (e.g., the WAP 1.xstack—WSP, WTP, WTLS, and WDP) to the WWW protocols (HTTP and TCP/IP). The gateway also performsDNS lookups of the servers named by the client in the request URLs.

· Content Encoders and Decoders – The content encoders can be used to translate WAP content into a compactformat that allows for better utilisation of the underlying link due to its reduced size.

· User Agent Profile Management – User agent profiles describing client capabilities and personal preferences[UAProf] are composed and presented to the applications.

· Caching Proxy – A caching proxy can improve perceived performance and network utilisation by maintaining acache of frequently accessed resources.

This infrastructure ensures that mobile terminal users can access a wide variety of Internet content and applications, andthat application authors are able to build content services and applications that run on a large base of mobile terminals.

The WAP proxy allows content and applications to be hosted on standard WWW servers and to be developed usingproven WWW technologies such as CGI scripting.

While the nominal use of WAP will include a web server, WAP proxy and WAP client, the WAP architecture can quiteeasily support other configurations.

WAP Architecture - Part II

Architectural Goals

The goals of the WAP Forum architecture are as follows. This summary is informative and non-exhaustive; the orderof the items does not represent any priority or importance.


· Provide a web-centric application model for wireless data services that utilises the telephony, mobility, and otherunique functions of wireless devices and networks and allows maximum flexibility and ability for vendors toenhance the user experience.

· Enable the personalisation and customisation of the device, the content delivered to it, and the presentation of thecontent.

· Provide support for secure and private applications and communication in a manner that is consistent andinteroperable with Internet security models.

· Enable wireless devices and networks that are currently or in the near future being deployed, including a widevariety of bearers from narrow-band to wide-band.

· Provide secure access to local handset functionality.

· Facilitate network-operator and third party service provisioning.

· Define a layered, scaleable and extensible architecture.

· Leverage existing standards where possible, especially existing and evolving Internet standards.

Architecture Overview

The World-Wide Web Model

The Internet World-Wide Web (WWW) architecture provides a very flexible and powerful programming model (Figure1). Applications and content are presented in standard data formats, and are browsed by applications known as webbrowsers. The web browser is a networked application, i.e., it sends requests for named data objects to a network serverand the network server responds with the data encoded using the standard formats.

The WWW standards specify many of the mechanisms necessary to build a general-purpose applicationenvironment, including:

· Standard naming model – All servers and content on the WWW are named with an Internet-standard UniformResource Locator (URL) [RFC2396].

· Content typing – All content on the WWW is given a specific type thereby allowing web browsers to correctlyprocess the content based on its type [RFC2045, RFC2048].

· Standard content formats – All web browsers support a set of standard content formats. These include theHyperText Markup Language (HTML) [HTML4], scripting languages [ECMAScript, JavaScript], and a largenumber of other formats.

· Standard Protocols – Standard networking protocols allow any web browser to communicate with any web server.The most commonly used protocol on the WWW is the HyperText Transport Protocol (HTTP) [RFC2616],operating on top of the TCP/IP protocol suite [STD0007].

This infrastructure allows users to easily reach a large number of third-party applications and content services. It alsoallows application developers to easily create applications and content services for a large community of clients.

WAP Architecture - I

WAP is positioned at the convergence of three rapidly evolving network technologies, wireless data, telephony, and theInternet.

Both the wireless data market and the Internet are growing very quickly and are continuing to reach new customers. Theexplosive growth of the Internet has fuelled the creation of new and exciting information services.

Most of the original technology developed for the Internet has been designed for desktop and larger computers andmedium to high bandwidth, generally reliable data networks. Mass-market, hand-held wireless devices present a moreconstrained computing environment compared to desktop computers.

Because of fundamental limitations of power andform-factor, mass-market handheld devices tend to have:
· Less powerful CPUs,
· Less memory (ROM and RAM),
· Restricted power consumption,
· Smaller displays, and
· Different input devices (e.g., a phone keypad).

Similarly, wireless data networks present a more constrained communication environment compared to wired networks.Because of fundamental limitations of power, available spectrum, and mobility, wireless data networks tend to have:
· Less bandwidth,
· More latency,
· Less connection stability, and
· Less predictable availability.

Mobile networks are growing in complexity and the cost of all aspects of providing value-added services is increasing.In order to meet the requirements of mobile network operators, solutions must be:
· Interoperable – terminals from different manufacturers communicate with services in the mobile network;
· Scaleable – mobile network operators are able to scale services to customer needs;
· Efficient – provides quality of service suited to the behaviour and characteristics of the mobile network;
· Reliable – provides a consistent and predictable platform for deploying services; and
· Secure – enables services to be extended over potentially unprotected mobile networks while still preserving theintegrity of user data; protects the devices and services from security problems such as loss of confidentiality.

Many of the current mobile networks include advanced services that can be offered to end-users. Mobile networkoperators strive to provide advanced services in a useable and attractive way in order to promote increased usage of themobile network services and to decrease the turnover rate of subscribers.

Standard features, like call control, can beenhanced by using WAP technology to provide customised user interfaces. For example, services such as callforwarding may provide a user interface that prompts the user to make a choice between accepting a call, forwarding toanother person, forwarding it to voice mail, etc.

The nature of wireless devices is that they are inherently mobile. This mobility introduces new opportunities forservices that are sensitive to mobility and can provide location-dependent information. The WAP specifications andarchitecture capitalise on this unique aspect of wireless devices by including mobility as part of the application model.

The WAP specifications address mobile network characteristics and operator needs by adapting existing networktechnology to the special requirements of mass-market, hand-held wireless data devices and by introducing newtechnology where appropriate.

The WAP specifications will accommodate a range of devices, from devices that provide very basic functionality todevices that continue to expand their capabilities. This motivates an architecture where functionality may be moved todifferent locations within the network as appropriate, i.e. either to devices or to network servers as necessary.

JPEG File Interchange Format V1.02 - III

JFIF Extension APP0 Marker Segment
Immediately following the JFIF APP0 marker segment may be a JFIF extension APP0marker. This JFIF extension APP0 marker segment may only be present for JFIF versions1.02 and above. The syntax of the JFIF extension APP0 marker segment is:

X’FF’, APP0, length, identifier, extension_code, extension_data

length (2 bytes) Total APP0 field byte count, including the bytecount value (2 bytes), but excluding the APP0marker itself

identifier (5 bytes) = X'4A', X'46', X'58', X'58', X'00'This zero terminated string (“JFXX”) uniquelyidentifies this APP0 marker.

extension_code (1 byte) = Code which identifies the extension. In thisversion, the following extensions are defined:
= X'10' Thumbnail coded using JPEG
= X'11' Thumbnail stored using 1 byte/pixel
= X'13' Thumbnail stored using 3 bytes/pixel
extension_data (variable) = The specification of the remainder of the JFIFextension APP0 marker segment varies with theextension. See below for a specification ofextension_data for each extension.

JFIF Extension:
Thumbnail coded using JPEGThis extension supports thumbnails compressed using JPEG. The compressed thumbnailimmediately follows the extension_code (X'10') in the extension_data field and the lengthof the compressed data must be included in the JFIF extension APP0 marker length field.

The syntax of the extension_data field conforms to the syntax for interchange formatdefined in Annex B of ISO DIS 10918-1. However, no “JFIF” or “JFXX” markersegments shall be present. As in the full resolution image of the JFIF file, the syntax ofextension_data constrains parameters in the frame header as defined below:

X’FF’, SOI
•
•
•
X’FF’, SOFn, length, frame parameters

Number of components Nf = 1 or 31st
component C1 = 1 = Y component
2nd component C2 = 2 = Cb component
3rd component C3 = 3 = Cr component
•
•
•
X’FF’, EOI

JFIF Extension: Thumbnail stored using one byte per pixel

This extension supports thumbnails stored using one byte per pixel and a color palette inthe extension_data field. The syntax of extension_data is:

Xthumbnail (1 byte) Thumbnail horizontal pixel count
Ythumbnail (1 byte) Thumbnail vertical pixel count
palette (768 bytes) 24-bit RGB pixel values for the color palette. The RGB values define the colors represented byeach value of an 8-bit binary encoding (0 - 255).
(pixel)n (n bytes) 8-bit values for the thumbnail pixelsn = Xthumbnail * Ythumbnail.

JFIF Extension: Thumbnail stored using three bytes per pixel

This extension supports thumbnails stored using three bytes per pixel in the extension_datafield. The syntax of extension_data is:

Xthumbnail (1 byte) Thumbnail horizontal pixel count
Ythumbnail (1 byte) Thumbnail vertical pixel count
(RGB)n (3n bytes) Packed (24-bit) RGB values for the thumbnailpixels, n = Xthumbnail * Ythumbnail

Useful tips
• you can identify a JFIF file by looking for the following sequence: X'FF', SOI, X'FF',APP0, <2>, "JFIF", X'00'.

• if you use APP0 elsewhere, be sure not to have the strings "JFIF" or "JFXX" right afterthe APP0 marker.

• if you do not want to include a thumbnail, just program Xthumbnail = Ythumbnail = 0.
• be sure to check the version number in the special APP0 field. In general, if the majorversion number of the JFIF file matches that supported by the decoder, the file will bedecodable.

• if you only want to specify a pixel aspect ratio, put 0 for the units field in the specialAPP0 field. Xdensity and Ydensity can then be programmed for the desired aspect ratio.Xdensity = 1, Ydensity = 1 will program a 1:1 aspect ratio. Xdensity and Ydensity shouldalways be non-zero.

JPEG File Interchange Format V1.02 - II

APP0 marker used for application-specific information

Additional APP0 marker segments can be used to hold application-specific information which does not affect the decodability or displayability of the JFIF file. Applicationspecific

APP0 marker segments must appear after the JFIF APP0 and any JFXX APP0
segments. Decoders should skip any unrecognized application-specific APP0 segments.
Application-specific APP0 marker segments are identified by a zero terminated string which identifies the application (not "JFIF" or “JFXX”). This string should be an organization name or company trademark. Generic strings such as dog, cat, tree, etc. should not be used.

Conversion to and from RGB

Y, Cb, and Cr are converted from R, G, and B as defined in CCIR Recommendation 601but are normalized so as to occupy the full 256 levels of a 8-bit binary encoding. Moreprecisely:

Y = 256 * E'y

Cb = 256 * [ E'Cb ] + 128

Cr = 256 * [ E'Cr ] + 128

where the E'y, E'Cb and E'Cb are defined as in CCIR 601. Since values of E'y have arange of 0 to 1.0 and those for E'Cb and E'Cr have a range of -0.5 to +0.5, Y, Cb, andCr must be clamped to 255 when they are maximum value.

RGB to YCbCr Conversion

YCbCr (256 levels) can be computed directly from 8-bit RGB as follows:

Y = 0.299 R + 0.587 G + 0.114

BCb = - 0.1687 R - 0.3313 G + 0.5 B + 128

Cr = 0.5 R - 0.4187 G - 0.0813 B + 128

NOTE - Not all image file formats store image samples in the order R0, G0,B0, ... Rn, Gn, Bn. Be sure to verify the sample order before convertingan RGB file to JFIF.

YCbCr to RGB Conversion

RGB can be computed directly from YCbCr (256 levels) as follows:

R = Y + 1.402 (Cr-128)

G = Y - 0.34414 (Cb-128) - 0.71414 (Cr-128)

B = Y + 1.772 (Cb-128)

Image Orientation

In JFIF files, the image orientation is always top-down. This means that the first imagesamples encoded in a JFIF file are located in the upper left hand corner of the image andencoding proceeds from left to right and top to bottom. Top-down orientation is used forboth the full resolution image and the thumbnail image.

The process of converting an image file having bottom-up orientation to JFIF must includeinverting the order of all image lines before JPEG encoding.

Spatial Relationship of Components

Specification of the spatial positioning of pixel samples within components relative to thesamples of other components is necessary for proper image post processing and accurateimage presentation. In JFIF files, the position of the pixels in subsampled components aredefined with respect to the highest resolution component. Since components must besampled orthogonally (along rows and columns), the spatial position of the samples in agiven subsampled component may be determined by specifying the horizontal and verticaloffsets of the first sample, i.e. the sample in the upper left corner, with respect to thehighest resolution component.

The horizontal and vertical offsets of the first sample in a subsampled component,Xoffseti[0,0] and Yoffseti[0,0], is defined to be

Xoffseti[0,0] = ( Nsamplesref / Nsamplesi ) / 2 - 0.5

Yoffseti[0,0] = ( Nlinesref / Nlinesi ) / 2 - 0.5

where

Nsamplesref is the number of samples per line in the largest component,

Nsamplesi is the number of samples per line in the ith component,

Nlinesref is the number of lines in the largest component,

Nlinesi is the number of lines in the ith component.

Proper subsampling of components incorporates an anti-aliasing filter which reduces thespectral bandwidth of the full resolution components. Subsampling can easily beaccomplished using a symmetrical digital filter with an even number of taps (coefficients).A commonly used filter for 2:1 subsampling utilizes two taps (1/2,1/2).

As an example, consider a 3 component image which is comprised of components havingthe following dimensions:

Component 1: 256 samples, 288 lines

Component 2: 128 samples, 144 lines

Component 3: 64 samples, 96 lines

NOTE - This definition is compatible with industry standards such as PostcriptLevel 2 and QuickTime. This defintition is not compatible with the conventionsused by CCIR Recommendation 601-1 and other digital video formats. For theseformats, pre-processing of the chrominance components is necessary prior tocompression in order to ensure accurate reconstruction of the compressed image.

JPEG File Interchange Format V1.02 - I

Why a File Interchange Format

JPEG File Interchange Format is a minimal file format which enables JPEG bitstreams tobe exchanged between a wide variety of platforms and applications. This minimal formatdoes not include any of the advanced features found in the TIFF JPEG specification or anyapplication specific file format. Nor should it, for the only purpose of this simplified formatis to allow the exchange of JPEG compressed images.

JPEG File Interchange Format features

• Uses JPEG compression

• Uses JPEG interchange format compressed image representation

• PC or Mac or Unix workstation compatible

• Standard color space: one or three components. For three components, YCbCr(CCIR 601-256 levels)

• APP0 marker used to specify Units, X pixel density, Y pixel density, thumbnail

• APP0 marker also used to specify JFIF extensions

• APP0 marker also used to specify application-specific information

JPEG Compression

Although any JPEG process is supported by the syntax of the JPEG File InterchangeFormat (JFIF) it is strongly recommended that the JPEG baseline process be used for thepurposes of file interchange. This ensures maximum compatibility with all applicationssupporting JPEG. JFIF conforms to the JPEG Draft International Standard (ISO DIS10918-1).

The JPEG File Interchange Format is entirely compatible with the standardJPEG interchange format; the only additional requirement is the mandatory presenceof the APP0 marker right after the SOI marker.

Note that JPEG interchange formatrequires (as does JFIF) that all table specifications used in the encoding process be coded inthe bitstream prior to their use.

Compatible across platforms

The JPEG File Interchange Format is compatible across platforms: for example, it does notuse any resource forks, supported by the Macintosh but not by PCs or workstations.

Standard color space

The color space to be used is YCbCr as defined by CCIR 601 (256 levels). The RGBcomponents calculated by linear conversion from YCbCr shall not be gamma corrected(gamma = 1.0). If only one component is used, that component shall be Y.

APP0 marker used to identify JPEG FIF

The APP0 marker is used to identify a JPEG FIF file. The JPEG FIF APP0 marker ismandatory right after the SOI marker.

The JFIF APP0 marker is identified by a zero terminated string: "JFIF". The APP0 can beused for any other purpose by the application provided it can be distinguished from theJFIF APP0.

The JFIF APP0 marker provides information which is missing from the JPEG stream:version number, X and Y pixel density (dots per inch or dots per cm), pixel aspect ratio(derived from X and Y pixel density), thumbnail.

APP0 marker used to specify JFIF extensions

Additional APP0 marker segment(s) can optionally be used to specify JFIF extensions. Ifused, these segment(s) must immediately follow the JFIF APP0 marker.

Decoders shouldskip any unsupported JFIF extension segments and continue decoding.The JFIF extension APP0 marker is identified by a zero terminated string: "JFXX".

The JFIF extension APP0 marker segment contains a 1-byte code which identifies theextension.

This version, version 1.02, has only one extension defined: an extension fordefining thumbnails stored in formats other than 24-bit RGB.

Naive Bayesian Classifiers in Java - II

Class diagram

Sequence diagram

Screenshot from the application

(screenshot with loaded training data for the example “playing tennis” )

There are three classes left , which fulfil control tasks.

MyRadioButtonListener:
This class is an inner class of the NaiveBayesApplication class, it implements the java.awt.event.ActionListener interface. There is instanciated one listener for every RadioButton. The task of ths listeners is to keep the stringkeys vector of the NaiveBayesApplication consistent to the selected RadioButtons.

WindowCloser:
This class implements the java.awt.event.WindowListener interface. The instanced object is responsible for shutting down the application when the user closes the application window.

XMLFileFilter:This class inherits from the javax.swing.filechooser.FileFilter class. The instanced object is responsible that only XML-files are shown, when the user loads new training data.Training Data Input via XML

An XML-file, which represents training data for the NaiveBayesApplication must have a special format.
Such an XML-file must have three tags. The first one is the tag, which contains a string representing the domain. The second one is the tag, which contains subtags which describe the attributes and their possible values. Since I map the attribute values in a hashtable with a string as key, two different attributes are not allowed to have equal values. The third tag is the tag, which contains a number of tags which represent the real training data. For more information please look at the example training data XML-files.

As example training data I chose the “Playing Tennis” example from [1] and created an new example “Accident”.
The “Playing Tennis” has the following attributes (outlook, temperature, humidity, wind) and the two classifications (playing , not playing).
The “Accident” example has the attributes (status of driver, status of road, sight, driving license for more than 5 years) and the two classifications (accident, no accident).
It is certainly arguable if these examples make any sense or represent any real data, but the used training datas are not the subject of this seminar work.

How to run the program
To get this application running you need the jdk1.3 or higher and the package[2] which provides the DOMparser I’ve used. You must add the path of this package to your Classpath variable, then the application should work.

Naive Bayesian Classifiers in Java - I

Introduction

The goals of this paper are first to give a short overview to naive bayesian classifiers and second to document an implementation of naive bayesian classifiers in the programing language Java using XML for the data input.
This paper and the associated application are subject of an seminar work for the course “ Intelligent Systems and Intelligent Agents” by Matjaz Gams at the Kaiserslautern University of Applied Sciences in march 2002.

Bayesian Learning

Other learning algorithms eliminate those hypotheses, which are not consistent to an training example. Whereas the Bayesian Learning just reduces the probability of an inconsistent hypothesis. This gives the Bayesian Learning a bigger flexibility. The Bayesian Learning Algorithms combine training data with a priori knowledge to get the a posteriori probability of an hypothesis. So it is possible to figure out the most probable hypothesis according to the training data. The basis for all Bayesian Learning Algorithms is the Bayes Rule.






P(h) = prior probability of hypothesis h
P(D) = prior probability of training data D
P(hD) = probability of h given D
P(Dh) = probability of D given h

Naive Bayes Algorithm

One of these algorithms is the Naive Bayes Algorithm, which uses Naive Bayesian Classifiers and which is subject of this seminar work.
Up to now we wondered which hypothesis is the most probable for a given dataset resp. a new instance.


But the question what Naive Bayesian Classifiers are about is which classification is the most probable for this new instance if we have a look at the training data.
For example an instance of an patient = (age,sex,weight) could be (45,male,120kg). An Naive Bayes System could calculate values for the following two classifications “cardiac insufficiency” and “no cardiac insufficiency” according to the available training data. Then the classifier with the biggest value rules the hypothesis. Whereby the conditional independence of the attributes of the instances is required for the use of Naive Bayesian Classifiers.

How does it look brought into a formula?

X be a set of instances xi = (a1,a2,…,an)
V be a set of classifications vj
Naive Bayes assumption:













This leads to the following algorithm:

Naive_Bayes_Learn (examples)
for each target value vj
estimate P(vj)
for each attribute value ai of each attribute a
estimate P(ai vj )

Classify_New_Instance (x)

In my implementation I chose an algorithm, that is a little different as you will see.


The Implementation

When I started to design this little application, I made three decisions. 1. the application should be useable for different kinds of training data, whereby only two targets (classifications) are allowed. 2. It should use a GUI for the communication with the user. 3. the application should be platform independent.
That’s why I chose Java as programming language for this project and XML for the representation of the training data.

The Java Classes

NaiveBayesApplication:
This class is responsible for the GUI and inherits from the javax.swing.JFrame class. It has the following important attributes:
- NaiveBayesLearner learner
- String domain (stores the name of the training data domain)
- Vector stringkeys (in this vector keywords were stored according to the instance requested by the user)
-
Thera are some other attributes which are only important for the GUI and the interaction with the user, but not for the algorithm.


The methods are:
- main() (instantiates an object of NaiveBayesApplication)
- loadTrainingData() (loads an XML-training data file with a DOMParser, calls the method getGUIPanelFromXML(), instantiates the attribut learner and calls its method learn() )
- getGUIPanelFromXML(Node,Node) (creates the GUI out of two Node objects according to the org.w3c.dom)
- calculate() (calls the calculate(stringkeys) method of the attribute learner with the vector stringkeys as parameter and actualizes the result on the screen from a Panel which is delivered by the called method)
- createActions() (creates AbstractActions objects, which are triggered when the user clicks the according buttons)

NaiveBayesLearner:
This class actually includes the algorithm. It has the following attributes:
- int numberofdatasets (used to store the number of training data examples)
- int numberofyes (used to store the number of training data examples which have positive result)

- int numberofno (used to store the number of training data examples which have negative result)
- String domain (stores the name of the training data domain)
- Hashtable attributevalues (This hashtable is filled with AttributeValue objects according to all possible values that the different attributes of the current training data can have. String objects where used as keys. AttributeValue objects count how often they appear in the training data with a positive and how often with a negative result.)

… and the following methods:
- learn(Node,Node) (fills up the attributevalues hashtable with AttributeValues objects and brings those to count their number of appeareances depending on the result.)
- calculate(Vector) (calculates, according to the Strings in the given Vector, the two classifiers, for the according AttributeValue objects, and the hypothesis. These classifiers and the hypothesis were put into a Panel and returned)

note: This is the typical estimation of P(aivj):




Where
n: examples with v=v;
p is prior estimate for P(aivj)
nc: examples with a=ai,
m is an empirical smoothing factor depending on the training data

Since I liked to make the application useable for different kinds of training data, I chose the following estimation, which is sufficient, if the number of training datasets is not very small.
Used Estimation of P(aivj):
P(ai vj) <= nc / n if (nc =0) => take 1 instead of nc

AttributeValue:
This class has these attributes:
- String name (stores the String which describes this AttributeValue object)
- int counteryes (stores the number of appearances of this AttributeValue object on positve results)
- int counterno (stores the number of apperances of this AttributeValue object on negative results)
and these methods:
- countyes() (increments counteryes)

- countno() (increments counterno)
- as well as get methods for counteryes and counterno.