/ ISO/IEC JTC 1/SC 29/WG 1 N5220
Date: 2009-10-30
ISO/IEC JTC 1/SC 29/WG 1
(ITU-T SG16)
Coding of Still Pictures
JBIG JPEG
Joint Bi-level Image Joint Photographic
Experts Group Experts Group

TITLE:FCD Text of 10918-Part 5 – JFIF format

SOURCE:Bernie Brower, Editor, Daniel Lee, co-editor, Fumitaka Ono, Richard Clark

PROJECT:JPEG, JBIG

STATUS: For Ballot

REQUESTED ACTION:Review for review and ballot

DISTRIBUTION:WG 1, SC 29 Secretariat

Contact:
ISO/IEC JTC 1/SC 29/WG 1 Convener - Dr. Daniel T. Lee
eBay Inc., 2145 Hamilton Avenue, San Jose, California 95125, USA
eBay ChinaDevelopmentCenter, ShanghaiGermanCenter, 88 Keyuan Road, Zhangjiang Hi-Tech Park, Pudong, Shanghai 201203, China
Tel: +1 408 219 4709 Fax: +1 253 830 0372, E-mail:

Warning

This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

CONTENTSPage

1Scope

1.1Why a File Interchange Format?

1.2JPEG File Interchange Format features

2Normative references

3Definitions

4Abbreviations

5Conformance

6JPEG File Interchange Format (JFIF) Overview

6.1JPEG Compression

6.2Compatible across platforms

6.3Standard colour space

6.4The APP0 marker is used to identify a JPEG FIF file

6.5APP0 marker used to specify JFIF extensions

6.6APP0 marker used for application-specific information

7Conversion to and from RGB

8Image Orientation

9Spatial Relationship of Components......

10JPEG File Interchange Format Specification

10.1JFIF Extension APP0 Marker Segment......

10.2JFIF Extension: Thumbnail coded using JPEG

10.3JFIF Extension: Thumbnail stored using one byte per pixel

10.4JFIF Extension: Thumbnail stored using three bytes per pixel

10.4.1Useful tips

Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IECJTC1.

International Standards are drafted in accordance with the rules given in the ISO/IECDirectives, Part2.

The main task of the joint technical committee is to prepare International Standards. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75% of the national bodies casting a vote.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.[r1]

ISO/IEC109185 was prepared by Joint Technical Committee ISO/IECJTC1, Information technology, Subcommittee SC29, Coding of audio, picture, multimedia and hypermedia information, in collaboration withITU-T. The identical text is published as ITU-T Rec. XXX.

ISO/IEC10918 consists of the following parts, under the general title Information technology— Digital compression and coding of continuous-tone still images:

Part1: Requirements and guidelines

Part2: Compliance testing

Part3: Extensions

Part4: Registration of JPEG profiles, SPIFF profiles, SPIFF tags, SPIFF colour spaces, APPn markers, SPIFF compression types, and Registration Authorities (REGAUT)

Part5: JPEG File Interchange Format (JFIF)

Introduction

This document specifies a file format, referred to as the JPEG File Interchange Format (JFIF), for file-based interchange of images encoded according to the original JPEG standard [r2](ITU-T Recommendation T.81 | ISO/IEC 10918-1).

The JPEG File Interchange Format (JFIF) was collaboratively developed by a group of computer, telecommunications, and imaging companies in the early 1990's. Representing C-Cube Microsystems, Eric Hamilton (also a past convenor of JPEG) led the development of the specification. He hosted a meeting in late 1991, whose goals were to develop a simple file format [r3]that would allow the interchange of files containing bitstreams conforming to a simple baseline version of the original JPEG standard[r4]Around 40 representatives from various computer, telecommunications, and imaging companies attended the meeting. Subsequent development of the specification was conducted by e-mail and telephone discussion. A consensus was achieved fairly quickly and led to the publication of version 1.0 of the JFIF specification., This was edited by Eric Hamilton and distributed to the participants, and to other interested parties, including the Independent JPEG Group.

In the group’s view subsequently, the spatial sampling relationship of components as specified in JFIF 1.0 was not ideal, as it followed digital video practice rather than those of common computer formats at that time, such as Postscript and QuickTime[r5]. A new version was published, JFIF 1.01, that changed the specification, which aimed to follow the computer format convention. This was deemed to be a minor change, since JFIF 1.0 had been in circulation for only briefly, and decoders which ignored the version number would still render images according to the revised specification in a similar visualisation. The Independent JPEG Group (IJG) adopted JFIF version 1.01 for use in its [r6]Open Source software, and millions of images were published in this format. Later in 1992, further user feedback led to the final version of the JFIF specification, version 1.02. This supported additional thumbnail formats,and in particular thumbnails stored in a JPEG compressed format.

The JFIF Version 1.02 specification was widely and freely circulated, and has been implemented widely, to the extent that it is widely recognized as a de facto standard for the communication of bitstreams encoded according to the original JPEG standard.

In preparing this specification, the JPEG committee acknowledges and applauds the excellent work that Eric Hamilton and the JFIF group did in creating the JFIF specifications, and expresses its gratitude to the supporting organizations, in particular to C-Cube Microsystems (now LSI Logic) and the other companies that participated in the original JFIF work.

The JPEG committee also expresses its sincere gratitude to Eric Hamilton for his valuable help in editing this specification and years of service with the JPEG committee. [r7]

Since the development of the JFIF format, metadata has become a more important to processing and distributing images. Knowledge of the content of the image, its creators, the capture device, and the proper representation of the colours captured by different display devices are examples of critical metadata information for many imaging processes. Preservation of this metadata throughout any production, distribution and archiving processes is of increasing importance The committee has focused several efforts on the handling of metadata data associated with all of its imagery standards, including most recently JPSearch ( the ISO/IEC 24800 series of standards).

JPSearchis a standard for image management systems, including image search and retrieval. It aims at inter-operability of searching techniques between devices and systems by defining the interfaces and protocols for data exchange. Part-4, entitled “Metadata embedded in image data file format”[r8], specifies image data exchange format (for files containing bitstreams according to original JPEG (ISO/IEC 10918-1) and JPEG 2000 (ISO/IEC 15444-1 and ISO/IEC 15444-3) file formats)with associated additionalmetadata to accelerate the re-use of metadata already contained in the files[r9]. It supports two functionalities, the mobility of metadata and the persistent association of metadata with images. Part-5, entitled “Data interchange format between image repositories” standardizes a format for the exchange of image collections and their associatedmetadata between JPSearch compliant repositories. The data interchange format enables the synchronization of repositories in order to facilitate simple and interoperable exchange across different devices and platforms.

ISO/IEC FCD 10918-5:200X (E)

INTERNATIONAL STANDARD

ISO/IEC FCD 10918-5:200X (E)

ITU-T Rec. T.XXX(200X E)

ITU-T RECOMMENDATION

Information technology –Digital compression and coding of continuous-tone still images:

JPEG File Interchange Format (JFIF)

1Scope

1.1Why a File Interchange Format?

JPEG File Interchange Format (JFIF) is a minimal file format which enables JPEGbitstreams (according to ITU-T Recommendation T.81 | ISO/IEC 10918-1) 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 [r10]specification or anyapplication-specific file format. The only purpose of this simplified format is to allow the exchange of JPEG compressed images.

1.2JPEG File Interchange Format features

  • Uses JPEG compression
  • Uses JPEG interchange format compressed image representation
  • PC or Mac or Unix workstation compatible
  • Standard colour space: one or three components. For three components, YCbCr (ITU-R BT.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

2Normative references

The following Recommendations and International Standards contain provisions which, through reference in this text,constitute provisions of this Recommendation | International Standard. At the time of publication, the editions indicatedwere valid. All Recommendations and Standards are subject to revision, and parties to agreements based on thisRecommendation | International Standard are encouraged to investigate the possibility of applying the most recentedition of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currentlyvalid International Standards. The Telecommunication Standardization Bureau of the ITU maintains a list of currentlyvalid ITU-T Recommendations.

ITU-T Recommendation T.81 | ISO/IEC 10918-1: 1992, Information technology - Digital compression and coding of continuous-tone still images - Requirements and guidelines

ITU-R Recommendation BT.601-6 (01.07) Studio encoding parameters of digital television for standard 4:3 and wide screen 16:9 aspect ratios(Former CCIR 601 Recommendation)

3Definitions

For the purposes of this Recommendation | International Standard, the following definitions apply.

3.1JPEG File Interchange Format (JFIF):minimal file format which enables JPEG bitstreams (ITU-T Recommendation T.81 | ISO/IEC 10918-1) to be exchanged between a wide variety of platforms and applications

3.2Thumbnail: miniature (reduced resolution) representation of the JPEG image that is used to identify the image by its contents.

NOTEThumbnails are commonly used to quickly browse multiple images using a low resolution visualrepresentation of the images, rather than using file names or other metadata.

4Abbreviations

For the purposes of this Recommendation | International Standard, the following abbreviations apply.

JFIFJPEG File Interchange Format

5Conformance

Many requirements in this specification are expressed as format or syntax requirements rather than software or hardware implementation requirements. Implementations fall into two categories: JFIF decoders and JFIF encoders.

In order for a JFIF decoder to be considered conforming, the following rules apply:

  • It MUST NOT report errors when processing conforming instances of the documented format except when forced to do so by resource exhaustion.
  • It SHOULD report errors when processing non-conforming instances of the documented formats when doing so does not pose an undue processing or performance burden.

In order for a JFIF encoder to be considered conforming, the following rules apply:

  • It MUST NOT generate any new, non-conforming instances of the documented format.
  • It MUST NOT introduce any non-conformance when modifying an instance of the documented format.

6JPEG File Interchange Format (JFIF) Overview

6.1JPEG 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 – as defined in ITU-T Recommendation T.81|ISO/IEC 10918-1 - be used for thepurposes of file interchange. This ensures maximum compatibility with all applicationssupporting JPEG. JFIF conforms to the JPEG International Standard (ITU-T Recommendation T.81|ISO/IEC 10918-1).[r11]

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. The JPEG interchange formatrequires (as does JFIF) that all table specifications used in the encoding process be coded inthe bitstream prior to their use.

6.2Compatible 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.

6.3Standard colour space

The colour space to be used is YCbCr as defined by ITU-R BT.601 (256 levels) but with different scaling. If only one component is used, that component shall be Y..[r12]

6.4The APP0 marker is used to identify a JPEG FIF file

The JPEG FIF APP0 marker ismandatory immediately followingthe SOI marker.The JFIF APP0 marker is identified by a zero terminated string: "JFIF". The APP0 marker can beused for any other purpose by the application,providingit can be distinguished from theJFIF APP0 marker.The JFIF APP0 marker provides some information thatis not contained in the JPEG stream, such as: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.

6.5APP0 marker used to specify JFIF extensions

Additional APP0 marker segment(s) can optionally be used to specify JFIF extensions. Ifused, these segment(s) must followimmediately 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". TheJFIF extension APP0 marker segment contains a 1-byte code thatidentifies theextension. In theversion specified in this Standrad | Recommendation, 1.02, only one extension is defined: an extension fordefining thumbnails codedin formats other than 24-bit RGB.

6.6APP0 marker used for application-specific information

Additional APP0 marker segments can be used to hold application-specific informationthatdoes not affect the decodability or displayability of the JFIF file. Application-specific APP0 marker segments must appear after the JFIF APP0 and any “JFXX” APP0segments. Decoders should skip any unrecognized application-specific APP0 segments.Application-specific APP0 marker segments are identified by a zero terminated string that identifies the application (not "JFIF" or “JFXX”). It is recommended that this string represents an organizationname or company trademark. Generic strings such as “dog”, “cat”, “tree”, etc. should not beused.

7Conversion to and from RGB

Y, Cb, and Cr are converted from R, G, and B as defined in ITU-R Recommendation BT.601, but 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'Cr are defined as in ITU-R BT.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 have themaximum value.

RGB to YCbCr Conversion

YCbCr (256 levels) can be computed directly from full scale 8-bit RGB in which black is represented by (0, 0, 0) and white is represented by (255, 255, 255)using the following formulae:

Y = 0.299 R + 0.587 G + 0.114 B

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

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

NOTENot all image file formats store image samples in the order R0, G0, B0, ... Rn, Gn, Bn. the sample order must be verified 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)

8Image 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.

9Spatial 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 sub-sampled components is defined 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 I th component,

Nlinesref is the number of lines in the largest component,

Nlinesi is the number of lines in the I th 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.

In a JFIF file, centers of the samples are positioned as illustrated below:

Figure 1 — Centres of the samples of three components

NOTEThis definitionmatchesvarious industry specifications such as PostscriptLevel 2 and QuickTime. This definition differs from the conventionsused by ITU-R Recommendation 601 and some other digital video formats. In practice the difference may be considered minor, or pre-processing of the chrominance components may be performed to produce a more accurate reconstruction of the compressed image.