EXE file format
From MS Document)
.exe executable-file header format (3.1)
an executable (.exe) file for the microsoft windows operating system contains a combination of code and data or a combination
of code, data, and resources. the executable file also contains two headers: an ms-dos header and a windows header. the
next two sections describe these headers; the third section describes the code and data contained in a windows executable file.
ms-dos header
the ms-dos (old-style) executable-file header contains four distinct parts: a collection of header information (such as the
signature word, the file size, and so on), a reserved section, a pointer to a windows header (if one exists), and a stub program.
the following illustration shows the ms-dos executable-file header:
if the word value at offset 18h is 40h or greater, the word value at 3ch is typically an offset to a windows header. applications
must verify this for each executable-file header being tested, because a few applications have a different header style.
ms-dos uses the stub program to display a message if windows has not been loaded when the user attempts to run a
program.
for more information about the ms-dos executable-file header, see the microsoft ms-dos programmer's reference
(redmond, washington: microsoft press, 1991).
windows header
the windows (new-style) executable-file header contains information that the loader requires for segmented executable files.
this information includes the linker version number, data specified by the linker, data specified by the resource compiler, tables
of segment data, tables of resource data, and so on. the following illustration shows the windows executable-file header:
the following sections describe the entries in the windows executable-file header.
information block
the information block in the windows header contains the linker version number, the lengths of various tables that further
describe the executable file, the offsets from the beginning of the header to the beginning of these tables, the heap and stack
sizes, and so on. the following list summarizes the contents of the header information block (the locations are relative to the
beginning of the block):
location description
00h specifies the signature word. the low byte contains "n" (4eh) and the high byte contains "e" (45h).
02h specifies the linker version number.
03h specifies the linker revision number.
04h specifies the offset to the entry table (relative to the beginning of the header).
06h specifies the length of the entry table, in bytes.
08h reserved.
0ch specifies flags that describe the contents of the executable file. this value can be one or more of the following bits:
bit meaning
0 the linker sets this bit if the executable-file format is singledata. an executable file with this format
contains one data segment. this bit is set if the file is a dynamic-link library (dll).
1 the linker sets this bit if the executable-file format is multipledata. an executable file with this format
contains multiple data segments. this bit is set if the file is a windows application.
if neither bit 0 nor bit 1 is set, the executable-file format is noautodata. an executable file with this format
does not contain an automatic data segment.
2 reserved.
3 reserved.
8 reserved.
9 reserved.
11 if this bit is set, the first segment in the executable file contains code that loads the application.
13 if this bit is set, the linker detects errors at link time but still creates an executable file.
14 reserved.
15 if this bit is set, the executable file is a library module.
if bit 15 is set, the cs:ip registers point to an initialization procedure called with the value in the ax register
equal to the module handle. the initialization procedure must execute a far return to the caller. if the
procedure is successful, the value in ax is nonzero. otherwise, the value in ax is zero.
the value in the ds register is set to the library's data segment if singledata is set. otherwise, ds is set
to the data segment of the application that loads the library.
0eh specifies the automatic data segment number. (0eh is zero if the singledata and multipledata bits are
cleared.)
10h specifies the initial size, in bytes, of the local heap. this value is zero if there is no local allocation.
12h specifies the initial size, in bytes, of the stack. this value is zero if the ss register value does not equal the ds
register value.
14h specifies the segment
ffset value of cs:ip.
18h specifies the segment
ffset value of ss:sp.
the value specified in ss is an index to the module's segment table. the first entry in the segment table
corresponds to segment number 1.
if ss addresses the automatic data segment and sp is zero, sp is set to the address obtained by adding the size of
the automatic data segment to the size of the stack.
1ch specifies the number of entries in the segment table.
1eh specifies the number of entries in the module-reference table.
20h specifies the number of bytes in the nonresident-name table.
22h specifies a relative offset from the beginning of the windows header to the beginning of the segment table.
24h specifies a relative offset from the beginning of the windows header to the beginning of the resource table.
26h specifies a relative offset from the beginning of the windows header to the beginning of the resident-name table.
28h specifies a relative offset from the beginning of the windows header to the beginning of the module-reference table.
2ah specifies a relative offset from the beginning of the windows header to the beginning of the imported-name table.
2ch specifies a relative offset from the beginning of the file to the beginning of the nonresident-name table.
30h specifies the number of movable entry points.
32h specifies a shift count that is used to align the logical sector. this count is log2 of the segment sector size. it is
typically 4, although the default count is 9. (this value corresponds to the /alignment [/a] linker switch. when the
linker command line contains /a:16, the shift count is 4. when the linker command line contains /a:512, the shift
count is 9.)
34h specifies the number of resource segments.
36h specifies the target operating system, depending on which bits are set:
bit meaning
0 operating system format is unknown.
1 reserved.
2 operating system is microsoft windows.
3 reserved.
4 reserved.
37h specifies additional information about the executable file. it can be one or more of the following values:
bit meaning
1 if this bit is set, the executable file contains a windows 2.x application that runs in version 3.x protected
mode.
2 if this bit is set, the executable file contains a windows 2.x application that supports proportional fonts.
3 if this bit is set, the executable file contains a fast-load area.
38h specifies the offset, in sectors, to the beginning of the fast-load area. (only windows uses this value.)
3ah specifies the length, in sectors, of the fast-load area. (only windows uses this value.)
3ch reserved.
3eh specifies the expected version number for windows. (only windows uses this value.)
segment table
the segment table contains information that describes each segment in an executable file. this information includes the
segment length, segment type, and segment-relocation data. the following list summarizes the values found in the segment
table (the locations are relative to the beginning of each entry):
location description
00h specifies the offset, in sectors, to the segment data (relative to the beginning of the file). a value of zero means no
data exists.
02h specifies the length, in bytes, of the segment, in the file. a value of zero indicates that the segment length is 64k,
unless the selector offset is also zero.
04h specifies flags that describe the contents of the executable file. this value can be one or more of the following:
bit meaning
0 if this bit is set, the segment is a data segment. otherwise, the segment is a code segment.
1 if this bit is set, the loader has allocated memory for the segment.
2 if this bit is set, the segment is loaded.
3 reserved.
4 if this bit is set, the segment type is movable. otherwise, the segment type is fixed.
5 if this bit is set, the segment type is pure or shareable. otherwise, the segment type is impure or
nonshareable.
6 if this bit is set, the segment type is preload. otherwise, the segment type is loadoncall.
7 if this bit is set and the segment is a code segment, the segment type is executeonly. if this bit is set
and the segment is a data segment, the segment type is readonly.
8 if this bit is set, the segment contains relocation data.
9 reserved.
10 reserved.
11 reserved.
12 if this bit is set, the segment is discardable.
13 reserved.
14 reserved.
15 reserved.
06h specifies the minimum allocation size of the segment, in bytes. a value of zero indicates that the minimum allocation
size is 64k.
resource table
the resource table describes and identifies the location of each resource in the executable file. the table has the following form:
word rscalignshift;
typeinfo rsctypes[];
word rscendtypes;
byte rscresourcenames[];
byte rscendnames;
following are the members in the resource table:
rscalignshift specifies the alignment shift count for resource data. when the shift count is used as an exponent of 2,
the resulting value specifies the factor, in bytes, for computing the location of a resource in the
executable file.
rsctypes specifies an array of typeinfo structures containing information about resource types. there must
be one typeinfo structure for each type of resource in the executable file.
rscendtypes specifies the end of the resource type definitions. this member must be zero.
rscresourcenames specifies the names (if any) associated with the resources in this table. each name is stored as
consecutive bytes; the first byte specifies the number of characters in the name.
rscendnames specifies the end of the resource names and the end of the resource table. this member must be
zero.
type information
the typeinfo structure has the following form:
typedef struct _typeinfo {
word rttypeid;
word rtresourcecount;
dword rtreserved;
nameinfo rtnameinfo[];
} typeinfo;
following are the members in the typeinfo structure:
rttypeid specifies the type identifier of the resource. this integer value is either a resource-type value or an offset
to a resource-type name. if the high bit in this member is set (0x8000), the value is one of the following
resource-type values:
value resource type
rt_accelerator accelerator table
rt_bitmap bitmap
rt_cursor cursor
rt_dialog dialog box
rt_font font component
rt_fontdir font directory
rt_group_cursor cursor directory
rt_group_icon icon directory
rt_icon icon
rt_menu menu
rt_rcdata resource data
rt_string string table
if the high bit of the value in this member is not set, the value represents an offset, in bytes relative to the
beginning of the resource table, to a name in the rscresourcenames member.
rtresourcecount specifies the number of resources of this type in the executable file.
rtreserved reserved.
rtnameinfo specifies an array of nameinfo structures containing information about individual resources. the
rtresourcecount member specifies the number of structures in the array.
name information
the nameinfo structure has the following form:
typedef struct _nameinfo {
word rnoffset;
word rnlength;
word rnflags;
word rnid;
word rnhandle;
word rnusage;
} nameinfo;
following are the members in the nameinfo structure:
rnoffset specifies an offset to the contents of the resource data (relative to the beginning of the file). the offset is in terms of
alignment units specified by the rscalignshift member at the beginning of the resource table.
rnlength specifies the resource length, in bytes.
rnflags specifies whether the resource is fixed, preloaded, or shareable. this member can be one or more of the following
values:
value meaning
0x0010 resource is movable (moveable). otherwise, it is fixed.
0x0020 resource can be shared (pure).
0x0040 resource is preloaded (preload). otherwise, it is loaded on demand.
rnid specifies or points to the resource identifier. if the identifier is an integer, the high bit is set (8000h). otherwise, it is an
offset to a resource string, relative to the beginning of the resource table.
rnhandle reserved.
rnusage reserved.
resident-name table
the resident-name table contains strings that identify exported functions in the executable file. as the name implies, these strings
are resident in system memory and are never discarded. the resident-name strings are case-sensitive and are not
null-terminated. the following list summarizes the values found in the resident-name table (the locations are relative to the
beginning of each entry):
location description
00h specifies the length of a string. if there are no more strings in the table, this value is zero.
01h - xxh specifies the resident-name text. this string is case-sensitive and is not null-terminated.
xxh + 01h specifies an ordinal number that identifies the string. this number is an index into the entry table.
the first string in the resident-name table is the module name.
module-reference table
the module-reference table contains offsets for module names stored in the imported-name table. each entry in this table is 2
bytes long.
imported-name table
the imported-name table contains the names of modules that the executable file imports. each entry contains two parts: a single
byte that specifies the length of the string and the string itself. the strings in this table are not null-terminated.
entry table
the entry table contains bundles of entry points from the executable file (the linker generates each bundle). the numbering
system for these ordinal values is 1-based--that is, the ordinal value corresponding to the first entry point is 1.
the linker generates the densest possible bundles under the restriction that it cannot reorder the entry points. this restriction is
necessary because other executable files may refer to entry points within a given bundle by their ordinal values.
the entry-table data is organized by bundle, each of which begins with a 2-byte header. the first byte of the header specifies the
number of entries in the bundle (a value of 00h designates the end of the table). the second byte specifies whether the
corresponding segment is movable or fixed. if the value in this byte is 0ffh, the segment is movable. if the value in this byte is
0feh, the entry does not refer to a segment but refers, instead, to a constant defined within the module. if the value in this byte is
neither 0ffh nor 0feh, it is a segment index.
for movable segments, each entry consists of 6 bytes and has the following form:
location description
00h specifies a byte value. this value can be a combination of the following bits:
bit(s) meaning
0 if this bit is set, the entry is exported.
1 if this bit is set, the segment uses a global (shared) data segment.
3-7 if the executable file contains code that performs ring transitions, these bits specify the number of words
that compose the stack. at the time of the ring transition, these words must be copied from one ring to the
other.
01h specifies an int 3fh instruction.
03h specifies the segment number.
04h specifies the segment offset.
for fixed segments, each entry consists of 3 bytes and has the following form:
location description
00h specifies a byte value. this value can be a combination of the following bits:
bit(s) meaning
0 if this bit is set, the entry is exported.
1 if this bit is set, the entry uses a global (shared) data segment. (this may be set only for singledata
library modules.)
3-7 if the executable file contains code that performs ring transitions, these bits specify the number of words
that compose the stack. at the time of the ring transition, these words must be copied from one ring to the
other.
01h specifies an offset.
nonresident-name table
the nonresident-name table contains strings that identify exported functions in the executable file. as the name implies, these
strings are not always resident in system memory and are discardable. the nonresident-name strings are case-sensitive; they
are not null-terminated. the following list summarizes the values found in the nonresident-name table (the specified locations are
relative to the beginning of each entry):
location description
00h specifies the length, in bytes, of a string. if this byte is 00h, there are no more strings in the table.
01h - xxh specifies the nonresident-name text. this string is case-sensitive and is not null-terminated.
xx + 01h specifies an ordinal number that is an index to the entry table.
the first name that appears in the nonresident-name table is the module description string (which was specified in the
module-definition file).
code segments and relocation data
code and data segments follow the windows header. some of the code segments may contain calls to functions in other
segments and may, therefore, require relocation data to resolve those references. this relocation data is stored in a relocation
table that appears immediately after the code or data in the segment. the first 2 bytes in this table specify the number of
relocation items the table contains. a relocation item is a collection of bytes specifying the following information:
address type (segment only, offset only, segment and offset)
relocation type (internal reference, imported ordinal, imported name)
segment number or ordinal identifier (for internal references)
reference-table index or function ordinal number (for imported ordinals)
reference-table index or name-table offset (for imported names)
each relocation item contains 8 bytes of data, the first byte of which specifies one of the following relocation-address types:
value meaning
0 low byte at the specified offset
2 16-bit selector
3 32-bit pointer
5 16-bit offset
11 48-bit pointer
13 32-bit offset
the second byte specifies one of the following relocation types:
value meaning
0 internal reference
1 imported ordinal
2 imported name
3 osfixup
the third and fourth bytes specify the offset of the relocation item within the segment.
if the relocation type is imported ordinal, the fifth and sixth bytes specify an index to a module's reference table and the seventh
and eighth bytes specify a function ordinal value.
if the relocation type is imported name, the fifth and sixth bytes specify an index to a module's reference table and the seventh and
eighth bytes specify an offset to an imported-name table.
if the relocation type is internal reference and the segment is fixed, the fifth byte specifies the segment number, the sixth byte is
zero, and the seventh and eighth bytes specify an offset to the segment. if the relocation type is internal reference and the segment
is movable, the fifth byte specifies 0ffh, the sixth byte is zero; and the seventh and eighth bytes specify an ordinal value found in
the segment's entry table.
TXT: I think it's easy.No need to explain.
JPG or JPEG
Writen by Eric Hamilton)
JPEG File Interchange Format
Version 1.02
Why a File Interchange Format
JPEG File Interchange Format is a minimal file format which enables JPEG bitstreams to
be exchanged between a wide variety of platforms and applications. This minimal format
does not include any of the advanced features found in the TIFF JPEG specification or any
application specific file format. Nor should it, for the only purpose of this simplified
format is to allow the exchange of JPEG compressed images.
JPEG File Interchange Format features
o Uses JPEG compression
o Uses JPEG interchange format compressed image representation
o PC or Mac or Unix workstation compatible
o Standard color space: one or three components. For three components, YCbCr
(CCIR 601-256 levels)
o APP0 marker used to specify Units, X pixel density, Y pixel density, thumbnail
o APP0 marker also used to specify JFIF extensions
o APP0 marker also used to specify application-specific information
JPEG Compression
Although any JPEG process is supported by the syntax of the JPEG File Interchange Format
(JFIF) it is strongly recommended that the JPEG baseline process be used for the purposes
of file interchange. This ensures maximum compatibility with all applications supporting
JPEG. JFIF conforms to the JPEG Draft International Standard (ISO DIS 10918-1).
The JPEG File Interchange Format is entirely compatible with the standard JPEG
interchange format; the only additional requirement is the mandatory presence of the
APP0 marker right after the SOI marker. Note that JPEG interchange format requires (as
does JFIF) that all table specifications used in the encoding process be coded in the
bitstream prior to their use.
Compatible across platforms
The JPEG File Interchange Format is compatible across platforms: for example, it does not
use 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 RGB
components 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 is
mandatory right after the SOI marker.
The JFIF APP0 marker is identified by a zero terminated string: "JFIF". The APP0 can be
used for any other purpose by the application provided it can be distinguished from the
JFIF 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. If
used, these segment(s) must immediately follow the JFIF APP0 marker. Decoders should
skip 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 the extension.
This version, version 1.02, has only one extension defined: an extension for defining
thumbnails stored in formats other than 24-bit RGB.
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. Application-
specific 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 601
but are normalized so as to occupy the full 256 levels of a 8-bit binary encoding. More
precisely:
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 a
range of 0 to 1.0 and those for E'Cb and E'Cr have a range of -0.5 to +0.5, Y, Cb, and Cr
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 B
Cb = - 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 converting an
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 image
samples encoded in a JFIF file are located in the upper left hand corner of the image and
encoding proceeds from left to right and top to bottom. Top-down orientation is used for
both the full resolution image and the thumbnail image.
The process of converting an image file having bottom-up orientation to JFIF must include
inverting 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 the
samples of other components is necessary for proper image post processing and accurate
image presentation. In JFIF files, the position of the pixels in subsampled components are
defined with respect to the highest resolution component. Since components must be
sampled orthogonally (along rows and columns), the spatial position of the samples in a
given subsampled component may be determined by specifying the horizontal and vertical
offsets of the first sample, i.e. the sample in the upper left corner, with respect to the
highest 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 the
spectral bandwidth of the full resolution components. Subsampling can easily be
accomplished 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).
NOTE - This definition is compatible with industry standards such as Postcript
Level 2 and QuickTime. This defintition is not compatible with the conventions
used by CCIR Recommendation 601-1 and other digital video formats. For these
formats, pre-processing of the chrominance components is necessary prior to
compression in order to ensure accurate reconstruction of the compressed image.
JPEG File Interchange Format Specification
The syntax of a JFIF file conforms to the syntax for interchange format defined in Annex B
of ISO DIS 10918-1. In addition, a JFIF file uses APP0 marker segments and constrains
certain parameters in the frame header as defined below.
X'FF', SOI
X'FF', APP0, length, identifier, version, units, Xdensity, Ydensity, Xthumbnail,
Ythumbnail, (RGB)n
length (2 bytes) Total APP0 field byte count, including the byte
count value (2 bytes), but excluding the APP0
marker itself
identifier (5 bytes) = X'4A', X'46', X'49', X'46', X'00'
This zero terminated string ("JFIF") uniquely
identifies this APP0 marker. This string shall
have zero parity (bit 7=0).
version (2 bytes) = X'0102'
The most significant byte is used for major
revisions, the least significant byte for minor
revisions. Version 1.02 is the current released
revision.
units (1 byte) Units for the X and Y densities.
units = 0: no units, X and Y specify the pixel
aspect ratio
units = 1: X and Y are dots per inch
units = 2: X and Y are dots per cm
Xdensity (2 bytes) Horizontal pixel density
Ydensity (2 bytes) Vertical pixel density
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 thumbnail
pixels, n = Xthumbnail * Ythumbnail
[ Optional JFIF extension APP0 marker segment(s) - see below ]
o
o
o
X'FF', SOFn, length, frame parameters
Number of components Nf = 1 or 3
1st component C1 = 1 = Y component
2nd component C2 = 2 = Cb component
3rd component C3 = 3 = Cr component
o
o
o
X'FF', EOI
JFIF Extension APP0 Marker Segment
Immediately following the JFIF APP0 marker segment may be a JFIF extension APP0
marker. This JFIF extension APP0 marker segment may only be present for JFIF versions
1.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 byte
count value (2 bytes), but excluding the APP0
marker itself
identifier (5 bytes) = X'4A', X'46', X'58', X'58', X'00'
This zero terminated string ("JFXX") uniquely
identifies this APP0 marker. This string shall
have zero parity (bit 7=0).
extension_code (1 byte) = Code which identifies the extension. In this
version, 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 JFIF
extension APP0 marker segment varies with the
extension. See below for a specification of
extension_data for each extension.
JFIF Extension: Thumbnail coded using JPEG
This extension supports thumbnails compressed using JPEG. The compressed thumbnail
immediately follows the extension_code (X'10') in the extension_data field and the length
of 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 format defined
in Annex B of ISO DIS 10918-1. However, no "JFIF" or "JFXX" marker segments shall
be present. As in the full resolution image of the JFIF file, the syntax of extension_data
constrains parameters in the frame header as defined below:
X'FF', SOI
o
o
o
X'FF', SOFn, length, frame parameters
Number of components Nf = 1 or 3
1st component C1 = 1 = Y component
2nd component C2 = 2 = Cb component
3rd component C3 = 3 = Cr component
o
o
o
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 in
the 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 by
each value of an 8-bit binary encoding (0 - 255).
(pixel)n (n bytes) 8-bit values for the thumbnail pixels
n = Xthumbnail * Ythumbnail
JFIF Extension: Thumbnail stored using three bytes per pixel
This extension supports thumbnails stored using three bytes per pixel in the extension_data
field. 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 thumbnail
pixels, n = Xthumbnail * Ythumbnail
Useful tips
o you can identify a JFIF file by looking for the following sequence: X'FF', SOI, X'FF',
APP0, <2 bytes to be skipped>, "JFIF", X'00'.
o if you use APP0 elsewhere, be sure not to have the strings "JFIF" or "JFXX" right after
the APP0 marker.
o if you do not want to include a thumbnail, just program Xthumbnail = Ythumbnail = 0.
o be sure to check the version number in the special APP0 field. In general, if the major
version number of the JFIF file matches that supported by the decoder, the file will be
decodable.
o if you only want to specify a pixel aspect ratio, put 0 for the units field in the special
APP0 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 should
always be non-zero.
You can learn Other file format from www.csdn.com.cn & MSDN & MPEG site.
Declaration:
The Articles above are cut from some technology sites,not written by me.
