MultimediaWiki - User contributions [en]

Max

2008-04-09T15:13:52Z

Dcsmith77:

Nuance PaperPort Image file format

* Extension: max
* Company: [[Nuance Communications]]
* Samples: http://www.google.com.au/search?q=vigcj+filetype:max (google "vigcj" and find files with a .max extension)

This format is undiscovered, but has ViGCj as the first 5 bytes of the format. It has the ability to store both text and images for a document.

http://zenkov.freeforums.org/viewtopic.php?p=111&sid=fb08ba99e90212bc1f29ebef108d1f2c

Apparently uses leadtools image format to store the image in the file.
Format partially reverse engineered here: http://maxview.cvs.sourceforge.net/maxview/decpp.c?revision=1.27&view=markup
[[Category:Undiscovered Image Formats]]

Abc

2008-02-06T01:57:06Z

Dcsmith77: Leadtools Advanced bitonal compression

leadtools abc (advanced bitonal compression)
[http://www.leadtools.com/SDK/Document/Document-Addon-LEAD-ABC.htm]

Max

2008-01-23T07:57:45Z

Dcsmith77:

Paperport file format.

This format is undiscovered, but has ViGCj as the first 5 bytes of the format. It has the ability to store both text and images for a document.

Samples can be found by [http://www.google.com.au/search?q=vigcj+filetype:max | googling vigcj and finding files with a .max extension].

http://zenkov.freeforums.org/viewtopic.php?p=111&sid=fb08ba99e90212bc1f29ebef108d1f2c

apparently uses leadtools image format to store the image in the file

[[Category:Undiscovered Image Formats]]

HD Photo

2007-08-31T06:54:41Z

Dcsmith77:

==HD Photo==

is a format developed by Microsoft. It is known under the following names
# 'Windows Media Photo'
# 'HD Photo (High Dynamic range Photo)'
# 'JPEG XR (JPEG eXtended Range)'.

Windows Media Photo supports the following pixel formats: (from http://blogs.msdn.com/billcrow/archive/2006/06/22/642213.aspx)

# 16bpp (16bits per channel x 1 channel) Grayscale Fixed Point.
# 16bpp (16bits per channel x 1 channel) Grayscale Floating Point.
# 48bpp (16bits per channel x 3 channels ) RGB Fixed Point.
# 48bpp (16bits per channel x 3 channels ) RGB Floating Point.
# 64bpp (16bits per channel x 4 channels ) RGBA Fixed Point.
# 64bpp (16bits per channel x 4 channels ) RGBA Floating Point.
# 32bpp (32bits per channel x 1 channel) Grayscale Fixed Point.
# 32bpp (32bits per channel x 1 channel) Grayscale Floating Point.
# 96bpp (32bits per channel x 3 channels ) RGB Fixed Point.
# 96bpp (32bits per channel x 3 channels ) RGB Floating Point.
# 128bpp (32bits per channel x 4 channels) RGBA Fixed Point.
# 128bpp (32bits per channel x 4 channels) RGBA Floating Point.
# 128bpp (32bits per channel x 4 channels) PRGBA Floating Point with Pre-multiplied alpha channel?
# 32bpp (8bits per channel + 8bits exponent) R'G'B'E. R = R' x 10^E, G = G' x 10^E, B = B' x10^E.

There are also CMYK, CMYKA, BGR555, BGR565, BGRA, ...
[[Category:Image Formats]]

Max

2007-04-27T10:00:29Z

Dcsmith77:

Max

2007-04-27T09:55:26Z

Dcsmith77:

Paperport file format.

This format is undiscovered, but has ViGCj as the first 5 bytes of the format. It has the ability to store both text and images for a document.

[[Category:Undiscovered Image Formats]]

Max

2007-04-27T09:53:53Z

Dcsmith77:

Paperport file format.

This format is undiscovered, but has ViGCj as the first 5 bytes of the format. It has the ability to store both text and images for a document.

GarageBand

2007-04-27T09:33:28Z

Dcsmith77:

Garageband is Apple's consumer multitrack editor.

Garageband files are actually directories with a .band extenstion.

Within the directory there is a projectData file and a Media directory containing source aiffs.

The projectData file is an xml file describing the project along with a large chunk of base64 encoded data within the <data> tags.

Samples can be found here: [http://nin.com/access/only/]

GarageBand

2007-04-27T09:31:31Z

Dcsmith77:

GarageBand

2007-04-27T09:30:47Z

Dcsmith77:

Garageband is Apple's consumer multitrack editor.

Garageband files are actually directories with a .band extenstion.
Within the directory there is a projectData file and a Media directory containing source aiffs.
The projectData file is an xml file describing the project along with a large chunk of base64 encoded data within the &ltdata&gt tags

Talk:FFmpeg Wishlist

2007-04-10T21:01:10Z

Dcsmith77:

XMV demuxer could be RE'd from this:
http://sourceforge.net/tracker/index.php?func=detail&aid=1097094&group_id=53761&atid=471491
--[[User:Kostya|Kostya]] 06:13, 13 July 2006 (EDT)

Does it really need 'implement' on every line? such code duplication!
[[User:Compn|Compn]] 17:21, 4 December 2006 (EST)
:Yeah I know it needs some structure, feel free to clean this up. I just wanted a place to keep my ideas.--[[User:Merbanan|Merbanan]] 17:27, 4 December 2006 (EST)
:: how about putting it into sections like Demuxers, Decoders, Filters, etc? would you like this change? or would it be too complicated?
::: That sounds fine.--[[User:Merbanan|Merbanan]] 03:36, 5 December 2006 (EST)

I've made a first try at re-organizing the page. There's a lot of stuff left in Misc because I wasn't sure how to categorize it. [[User:Dashcloud|Dashcloud]] 00:26, 10 December 2006 (EST)
:It does not look like dts in wav works: if you try to play Fire_VooDoo_Studio_30_second.wav without -f dts, it plays garbage (using svn-8448)[[User:Dashcloud|Dashcloud]]
::I have done my best to re-organize and clean-up this article, will do some futher cleanup after SoC really kicks-off --[[User:Gamester17|Gamester17]] 23:20, 20 March 2007 (GMT+1)

CRYO APC

2007-04-10T20:44:33Z

Dcsmith77:

* Extensions: .APC, .HNM, .BF, .ZIK
* Company: [[CRYO Interactive Entertainment]]

This covers the audio format for one of the versions of CRYO's video formats.

==Credit==
This file comes from [http://www.wotsit.org wotsit.org] and was originally written by Valery V. Anisimovsky.

== APC Audio Files==

The music, sfx, speech and video (.HNM) soundtracks in some CRYO Interactive
games are .APC stand-alone files. APC file has the following header:

struct APCHeader
{
char szID[8];
char szVersion[4];
DWORD dwOutSize;
DWORD dwSampleRate;
LONG lSampleLeft;
LONG lSampleRight;
DWORD dwStereo;
};

''szID'' -- ID string, which is "CRYO_APC".

''szVersion'' -- version ID string, all files in the mentioned games have this
set to "1.20". Note that this field may, in principle, vary.

''dwOutSize'' -- number of samples in the file. May be used for song length
(in seconds) calculation.

''dwSampleRate'' -- sample rate for the file.

''lSampleLeft'' -- the initial value for the left sample (see below).

''lSampleRight'' -- the initial value for the right sample (see below).

''dwStereo'' -- this seems to be boolean stereo flag: if this is not zero, the
audio stream in the file is stereo (music and partly video soundtracks),
otherwise it's mono (sfx, speech).

The resolution is NOT specified in the header, so the default value (16-bit)
should be used.

After the APCHeader IMA ADPCM compressed sound data comes. You may find
IMA ADPCM decompression scheme description further in this document.

== IMA ADPCM Decompression Algorithm ==

During the decompression four LONG variables must be maintained for stereo
stream: ''lIndexLeft, lIndexRight, lCurSampleLeft, lCurSampleRight'' and two --
for mono stream: ''lIndex, lCurSample''. At the beginning of the file you must
initialize ''lCurSampleLeft/Right'' variables to the values from APCHeader while
''lIndexLeft/Right'' are initialized to zeroes.
Note that LONG here is signed.

Here's the code which decompresses one byte of IMA ADPCM compressed
stereo stream. Other bytes are processed in the same way.

BYTE Input; // current byte of compressed data
BYTE Code;
LONG Delta;

Code=HINIBBLE(Input); // get HIGHER 4-bit nibble

Delta=StepTable[lIndexLeft]>>3;
if (Code & 4)
Delta+=StepTable[lIndexLeft];
if (Code & 2)
Delta+=StepTable[lIndexLeft]>>1;
if (Code & 1)
Delta+=StepTable[lIndexLeft]>>2;
if (Code & 8) // sign bit
lCurSampleLeft-=Delta;
else
lCurSampleLeft+=Delta;

// clip sample
if (lCurSampleLeft>32767)
lCurSampleLeft=32767;
else if (lCurSampleLeft<-32768)
lCurSampleLeft=-32768;

lIndexLeft+=IndexAdjust[Code]; // adjust index

// clip index
if (lIndexLeft<0)
lIndexLeft=0;
else if (lIndexLeft>88)
lIndexLeft=88;

Code=LONIBBLE(Input); // get LOWER 4-bit nibble

Delta=StepTable[lIndexRight]>>3;
if (Code & 4)
Delta+=StepTable[lIndexRight];
if (Code & 2)
Delta+=StepTable[lIndexRight]>>1;
if (Code & 1)
Delta+=StepTable[lIndexRight]>>2;
if (Code & 8) // sign bit
lCurSampleRight-=Delta;
else
lCurSampleRight+=Delta;

// clip sample
if (lCurSampleRight>32767)
lCurSampleRight=32767;
else if (lCurSampleRight<-32768)
lCurSampleRight=-32768;

lIndexRight+=IndexAdjust[Code]; // adjust index

// clip index
if (lIndexRight<0)
lIndexRight=0;
else if (lIndexRight>88)
lIndexRight=88;

// Now we've got lCurSampleLeft and lCurSampleRight which form one stereo
// sample and all is set for the next input byte...
Output((SHORT)lCurSampleLeft,(SHORT)lCurSampleRight); // send the sample to output

HINIBBLE and LONIBBLE are higher and lower 4-bit nibbles:
#define HINIBBLE(byte) ((byte) >> 4)
#define LONIBBLE(byte) ((byte) & 0x0F)
Note that depending on your compiler you may need to use additional nibble
separation in these defines, e.g. ''(((byte) >> 4) & 0x0F)''.

StepTable and IndexAdjust are the tables given in the next section of
this document.

Output() is just a placeholder for any action you would like to perform for
decompressed sample value.

Of course, this decompression routine may be greatly optimized.

As to mono sound, it's just analoguous:

Code=HINIBBLE(Input); // get HIGHER 4-bit nibble

Delta=StepTable[lIndex]>>3;
if (Code & 4)
Delta+=StepTable[lIndex];
if (Code & 2)
Delta+=StepTable[lIndex]>>1;
if (Code & 1)
Delta+=StepTable[lIndex]>>2;
if (Code & 8) // sign bit
lCurSample-=Delta;
else
lCurSample+=Delta;

// clip sample
if (lCurSample>32767)
lCurSample=32767;
else if (lCurSample<-32768)
lCurSample=-32768;

lIndex+=IndexAdjust[Code]; // adjust index

// clip index
if (lIndex<0)
lIndex=0;
else if (lIndex>88)
lIndex=88;

Output((SHORT)lCurSample); // send the sample to output

Code=LONIBBLE(Input); // get LOWER 4-bit nibble
// ...just the same as above for lower nibble

Note that HIGHER nibble is processed first for mono sound and corresponds to
LEFT channel for stereo.

== IMA ADPCM Tables ==

LONG IndexAdjust[]=
{
-1,
-1,
-1,
-1,
2,
4,
6,
8,
-1,
-1,
-1,
-1,
2,
4,
6,
8
};

LONG StepTable[]=
{
7, 8, 9, 10, 11, 12, 13, 14, 16,
17, 19, 21, 23, 25, 28, 31, 34, 37,
41, 45, 50, 55, 60, 66, 73, 80, 88,
97, 107, 118, 130, 143, 157, 173, 190, 209,
230, 253, 279, 307, 337, 371, 408, 449, 494,
544, 598, 658, 724, 796, 876, 963, 1060, 1166,
1282, 1411, 1552, 1707, 1878, 2066, 2272, 2499, 2749,
3024, 3327, 3660, 4026, 4428, 4871, 5358, 5894, 6484,
7132, 7845, 8630, 9493, 10442, 11487, 12635, 13899, 15289,
16818, 18500, 20350, 22385, 24623, 27086, 29794, 32767
};

== HNM Movie Soundtracks ==

.HNM movie hasn't got soundtrack inside the HNM movie file itself.
However the soundtrack for HNM movie is a stand-alone APC file, as a rule,
with the same file title. The format of such APC soundtracks is just the
same as described above.

== APC Audio Files in BF Archives ==

When stored in .BF resources, APC audio files are stored "as is", without
compression or encryption. That means if you want to play/extract APC
file from the BF resource you just need to search for (''szID'') id-string
("CRYO_APC") and read APC header starting at the beginning position of
found id-string. This will give you starting point of the file and the size
of the file will be the sum of APCHeader size and the compressed audio stream
size correspondent to (''dwOutSize'') header field (that is, (''dwOutSize'') for
stereo stream and (''dwOutSize)/2'' for mono stream).

== ZIK Audio Files ==

In the game Chine music is in ZIK files. Most of them are simple RAW files:
16-bit signed stereo 22050 Hz (no header), except for only one which is a
regular WAV file. So, you can just load and play those ZIKs as RAWs (except
for one which is WAV).

==PC Games Using CRYO APC==
*[http://www.mobygames.com/game/windows/atlantis-the-lost-tales Atlantis: The Lost Tales]
*[http://www.mobygames.com/game/windows/sacred-amulet Aztec: The Curse in the Heart of the "City of Gold" a.k.a Sacred Amulet]
*[http://www.mobygames.com/game/windows/egypt-ii-the-heliopolis-prophecy Egypt II]
*[http://www.mobygames.com/game/odyssey-the-search-for-ulysses Odyssey: The Search For Ulysses]
*[http://www.mobygames.com/game/china-the-forbidden-city China: The Forbidden City]
* Atlantis 2
* Zero Zone a.k.a Onderzoek 2098 [http://www.mobygames.com/game/windows/zero-zone] [http://en.wikipedia.org/wiki/ZeroZone]

[[Category:Game Formats]]

Westwood Studios

2007-04-10T20:44:04Z

Dcsmith77:

Website: [http://www.westwood.com http://www.westwood.com]

The gaming company behind the Command & Conquer series, currently owned by [[Electronic Arts]]. They are the creators of the [[VQA]] format.

[[Category:Multimedia-related Companies]]

Decoding AAC FIL

2007-04-10T18:43:01Z

Dcsmith77:

''Part of [[Understanding AAC]]''

This can apparently be used for extension data since libfaad2 checks for SBR data in the FIL chunk which is known to be applicable to later HE-AAC variants. There are other extension data types in the syntax. According to the libfaad2 logic, a FIL element can have either an SBR chunk or a series of other extension types. These are the defined extension types:

* 1: FILL_DATA
* 2: DATA_ELEMENT
* 11: DYNAMIC_RANGE
* 12: SBR_DATA
* 13: SBR_DATA_CRC

local count
local extra_count
local extension_type
4 bits: count
if (count == 15)
8 bits: extra_count
count += extra_count
4 bits: extension_type

FILL_DATA:
4 bits: must be 0000b
foreach 0..count-2
8 bits: must be 0xA5 (10100101b)

DATA_ELEMENT:
'''[unfinished]'''

DYNAMIC_RANGE:
'''[unfinished]'''

SBR_DATA:
'''[unfinished]'''

SBR_DATA_CRC:
'''[unfinished]'''

Oma

2007-04-10T18:41:36Z

Dcsmith77: revert

* Extension: oma, omg
* Company: [[Sony]]

Container format used to encapsulate [[Sony ATRAC|ATRAC3]] and ATRAC3+ for use with Sony's portable players. Files ending with .omg are protected with the [[OpenMG]] [[DRM]] system.

The OMA file format contains a payload scrambled with a 32-bit value [http://www.waider.ie/hacks/workshop/c/mple/FILE_FORMAT_v2.txt]. The format is known to carry MP3 and ATRAC3 audio. The metadata format is a variant of ID3v2 and uses standard ID3v2 frame types, such as TIT2, TPE1, TALB and TCON. In addition to these standard frame types, TXXX and GEOB frames contain OpenMG-specific metadata.

TXX OMG_TRACK "track number (ASCII)"
TXX OMG_AGENR "content description (ASCII)"
TXX OMG_ATPE1 "leader performer (ASCII)"
GEOB OMG_BLKSI contains a metadata structure. observed strings include:
KEYRING
EKB
SHARE_P_SID
REFID
GEOB OMG_OLINF binary blob

[[Category:Container Formats]]

XPM

2007-04-10T18:40:24Z

Dcsmith77:

'''XPM''' (''X PixMap'') is an ASCII image format used by the X Window System. It was created in 1989 by Daniel Dardailler and Colas Nahaboo working at the INRIA, France, and was later enhanced by Arnaud Le Hors. It is intended primarily for creating icon pixmaps, and supports transparent color. It has a simple structure, deriving from the earlier [[XBM]] syntax.

Three styles are known, the simple XPM2:
:<tt>! XPM2</tt>
:<tt>128 128 64 1</tt>
:<tt>z c #f6f6f6</tt>
:<tt>Z c #eeeeee</tt>
:''etc., palette using '''1''' character codes''
:<tt>@ c #080808</tt>
:<tt>. c #000000</tt>
:<tt>............................................</tt>
:''truncated first row, each dot is a pixel with colour <tt>#000000</tt> as defined above.''

This is about an XPM2 image with width 128, height 128, 64 colours, using one character per pixel.
One tool is known to use only '''a''' to '''p''' for 16 colours, switching to '''aa''' up to '''dp''' for 64 colours,
but still reading single character encodings for 64 colours, compare [[Base64]].

With more colours the codes use more characters, e.g. '''aa''' up to '''pp''' for 16*16=256 colours. This is less useful
for text editors, because a string '''ab''' could be actually the middle of two adjacent pixels '''dabc'''. Spaces are
allowed as colour code, see [[#External links|links]], but might be a bad idea depending on the used text editor. Without
control codes, space, and quote (needed in XPM1 and XPM3) 128-33-2=93 [[ASCII]] characters are available for single character
colour codes.

It's helpful if the converter from other formats to XPM can sort the palette from white to black, because one of the
reasons to edit an icon might be to get rid of antialiasing artefacts after a reduction of the number colours, adding
affected pixels to <tt>#000000</tt> or <tt>#ffffff</tt> acting as transparency colour (the dots in the example).

For XPM2 it's clear how many lines belong to the image, two header lines, the second header line announcing the number of
colour codes (64 lines in the example above) and rows (height 128 in the example above), e.g. 2+64+128=194 lines.

The other styles are designed to be used as is in C sources, example:

:<tt>#define XFACE_format 1</tt>
:<tt>#define XFACE_width 48</tt>
:<tt>#define XFACE_height 48</tt>
:<tt>#define XFACE_ncolors 2</tt>
:<tt>#define XFACE_chars_per_pixel 1</tt>
:<tt>static char *XFACE_colors[] = {</tt>
:<tt>"a", "#ffffff",</tt>
:<tt>"b", "#000000"</tt>
:<tt>};</tt>
:<tt>static char *XFACE_pixels[] = {</tt>
:<tt>"abaabaababaaabaabababaabaabaababaabaaababaabaaab",</tt>
:''etc., 48 rows with 48 pixels''.

This is a black and white image in the first (1989) XPM format.
The source icon was in [[PNG]] format, and although it defined <tt>#ffffff</tt> as
transparent, this detail was lost in the conversion. The
hex. RGB <tt>#123456</tt> codes can be also replaced by known
colour names found in a "well known location" <tt>rgb.txt</tt>,
where "well known location" depends on the operating
system and the used tools. The XPM "colour" name for transparency is '''none'''.

Just for the records the same image in the other styles:

:<tt>! XPM2</tt>
:<tt>48 48 2 1</tt>
:<tt>a c #ffffff</tt>
:<tt>b c #000000</tt>
:<tt>abaabaababaaabaabababaabaabaababaabaaababaabaaab</tt>
:''etc.''

:<tt> /* XPM */</tt>
:<tt> static char * XFACE[] = {</tt>
:<tt> "48 48 2 1",</tt>
:<tt> "a c #ffffff",</tt>
:<tt> "b c #000000",</tt>
:<tt> "abaabaababaaabaabababaabaabaababaabaaababaabaaab",</tt>
:''etc.''

The latter format is XPM3, the common format used
for the X Window System since about 1991. The '''c'''
means "colour", it's possible to add '''m''' for
"monochrome" output, '''g''' for "grayscale", and '''s''' for "symbolic",
explaining what a defined colour is supposed to do.

The "symbolic" feature allows to adjust colours
depending on the context where they are used, like
say <tt>s border c blue</tt> could be adjusted on
a blue background.

If the width, height, colours, and characters per
pixel line contains six instead of four numbers the
additional values indicate the coordinates of a
"hotspot", '''0 0''' is the upper left corner
of a box containing the icon and the default. A
"hotspot" is used for mouse pointers and similar
applications.

[[Category:Image Formats]]

Talk:FFmpeg Summer Of Code 2007

2007-03-07T18:44:08Z

Dcsmith77:

== TIFF/TGA encoder? ==

Why? It seems too small a task to be done in the course of SoC. --[[User:Kostya|Kostya]] 09:20, 7 March 2007 (EST)

: True, I'll rework it. --[[User:Merbanan|Merbanan]] 11:44, 7 March 2007 (EST)

== DPX Encoder/Decoder ==
From what I understand this is the output of most film scanners. Having not used one I'm not 100% sure of this, and maybe someone could clarify, but my understanding is that film scanners output a collection of these files (I'm unsure if they're put in a container or not). There are already open source implementations in imagemagick and graphics magick.

FFmpeg Wishlist

2007-02-26T00:21:53Z

Dcsmith77: /* Decoders */

A temporary FFmpeg wish/todo list:
== Decoders ==
* g723.1/rtp decoder (vivo g.723?)
* g729/rtp decoder
* Bethsoft VID decoder
* a Monkey's Audio decoder, look at the c++ sdk sources
* a JPEG2000 decoder
* a gsm decoder
* QCELP decoder [http://www.3gpp2.org/Public_html/specs/alltsgscfm.cfm spec] is c.s0020 and source is c.r0020
* AMV decoder, http://scrub50187.com/ has the creator. wikipedia has [http://en.wikipedia.org/wiki/AMV_video_format articles] about the format also.
* integer only vorbis decoder (to replace tremor)
* LGPL'ed AAC decoder
* Fix wmv8 decoder
* MLP decoder

== Demuxers ==
* iff demuxer (with anim and sound decoding), xine has a decoder for it
* g723.1/rtp demuxer
* g729/rtp demuxer
* Bethsoft VID demuxer
* vivo demuxer, look at the mplayer vivo demuxer for reference
* a xmv demuxer, look at http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/25207/focus=25224 and http://www.maxconsole.net/?mode=news&newsid=411 for hints; also look at http://sourceforge.net/tracker/index.php?func=detail&aid=1097094&group_id=53761&atid=471491 (should be a working demuxer/decoder)
* AMV demuxer, http://scrub50187.com/ has the creator. wikipedia has [http://en.wikipedia.org/wiki/AMV_video_format articles] about the format also.

== Features ==
* a new audio api
* radix-4 fft routines
* grabbing from video devices under windows, apply this vfw capture patch http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2006-December/005607.html
* -[h|v]flip options for ffplay
* improved documentation (web,manpage)

== Misc ==
* NSV muxer
* add PAFF to [[H.264]] decoder
* improve seeking in asf files
* clean up alac decoder
* dts in wav support
* raw dts support
* integrate speex, glue code or native
* add xing or vbri header parsing support to the mp3 decoder/parser
* a aac parser so -acodec copy to mp4/mov works
* clean up the h263 rtp patch found on this page: http://www.salyens.com/downloads/index.html#ffmpeg-0.4.7
* add nice error messages to the flv demuxer(Nelly Moser) amr decoder and dv encoder/decoder
* game formats:
** [[Gremlin Digital Video]]
** [[ARMovie|ARMovie/RPL]]
** [[ESCAPE]]
** [[C93]]
** [[M95]]
** [[THP]]
* subtitle support

== [[Snow]] ==
* multiple reference frames improvements
** decide which frames to keep (e.g. long-term refs)
** some changes to the mv prediction code
* non translational motion compensation
** estimate non translational parameters per block by using surrounding motion vectors
** add a ac coded bit per block to switch between translational and non-translational MC
** borrow the non translational MC code from libmpcodecs/vf_perspective.c
** some changes to the encoder to decide between translational and non t.
* Trellis quantization (select quantized coefficient so as to minimize the rate distrortion
* 4x4 sized block support (we have 16x16 and 8x8 currently)
* 1/8 pel motion compensation / estimation support (pretty much just encoder changes needed which in case of the iterative me should be trivial)
* improve the intra color decision

== A/V Filters ==
* adopt mplayer filter system or create new one.
**http://article.gmane.org/gmane.comp.video.ffmpeg.devel/39130
***for michaelni's idea of what to do
* decide on name.
** libavfilter (conflicts with LAVF)? libavmunge?

JPEG-LS

2007-02-20T03:47:45Z

Dcsmith77:

'''JPEG-LS''' was developed with the aim of providing a low complexity lossless image compression standard that could be able to offer better compression efficiency than [[lossless JPEG]]. Part 1 of this standard was finalized in 1999.

[[Category:Multimedia-related Standards Bodies]]
[[Category:Container Formats]]

[[Category:Image Formats]]

JPEG 2000

2007-02-20T03:47:16Z

Dcsmith77:

'''JPEG 2000''' is a [[wavelet]]-based image compression standard. It was created by the Joint Photographic Experts Group committee with the intention of superseding their original discrete cosine transform-based [[JPEG]] standard. Common filename extensions include .jp2 and .j2c, while the MIME type is image/jp2.

[[Category:Image Formats]]

XPM

2007-02-20T03:44:23Z

Dcsmith77:

XBM

2007-02-20T03:43:50Z

Dcsmith77:

Usage
Primarily used for the storage of cursor and icon bitmaps for use in the X graphical user interface.

Comments
XBM is a monochrome bitmap format in which data is stored as a C language data array.

Normally, we think of images as data being stored as binary information in a file. In many cases, however, it is more convenient to represent smaller bitmapped images as collections of ASCII data rather than binary data. If such a small bitmapped image is being used by a software application, such as the cursors and icons found in all graphical user interfaces, the images may be stored as an array of ASCII characters, or even as an array of data values stored in the actual software source code.

Contents:
File Organization
File Details
For Further Information

Storing small amounts of image data directly as C language source code is the philosophy behind the XBM (X BitMap) format. Small images that will be compiled into a software program are stored as simple arrays of data values, with one array used per stored image. XBM files are therefore nothing more than C language source files that are read by a compiler, rather than by a graphical display program or bitmap editor, as are most other graphical files.

XBM bitmap data is mostly found in C source header files (with a .h file extension) and in separate XBM bitmap files (with no file extension). Multiple XBM image-data arrays may be stored in a single file, but none of the images may have the same name, or a naming conflict will result.

The XPM (X PixMap) format is similar to XBM. XPM is a cousin of XBM and is capable of storing color bitmap image data and a colormap. XPM is also an ASCII format and is described in the XPM article.
File Organization

XBM files have a height and width, and may define an optional hotspot within the image. The hotspot is used for bitmapped cursors and indicates the absolute position of the cursor on the screen. The hotspot on an arrow cursor is the tip of the arrow, which is usually located at position 0,0 in the bitmap.

In place of the usual image file format header, XBM files have two or four #define statements. The first two #defines specify the height and width of the bitmap in pixels. The second two specify the position of the hotspot within the bitmap, and are not present if no hotspot is defined in the image.

The labels of each #define contain the name of the image. Consider an image that is 8x8 pixels in size, named FOO, with a hotspot at pixel 0,7. This image contains the following #define statements:

#define FOO_width 8
#define FOO_height 8
#define FOO_x_hot 0
#define FOO_y_hot 7

The image data itself is a single line of pixel values stored in a static array. Data representing our FOO image appears as follows:

static unsigned char FOO_bits[] = {
0x3E, 0x80, 0x00, 0x7C, 0x00, 0x82, 0x41, 0x00};

Because each pixel is only one bit in size, each byte in the array contains the information for eight pixels, with the first pixel in the bitmap (at position 0,0) represented by the high bit of the first byte in the array. If the image width is not a multiple of eight, the extra bits in the last byte of each row are not used and are ignored.

XBM files are found in two variations: the older X10 format and the newer (as of 1986) X11 format. The only difference between these formats is how the pixel data is packed. The X11 flavor stores pixel data as 8-bit BYTEs. The older X10 flavor stores pixel data as 16-bit WORDs. There are no markers separating the rows of image data in either of these formats, and the size of an XBM array is limited only by the compiler and machine using the bitmap.

The X10 XBM is considered obsolete. Make sure that any X software you write is able to read both the XBM X10 and X11 formats, but when you write data, use only the X11 XBM format.
File Details

Following is an example of a 16x16 XBM bitmap stored using both its X10 and X11 variations. Note that each array contains exactly the same data, but is stored using different data word types:

/* XBM X10 format */
#define xlogo16_width 16
#define xlogo16_height 16
static unsigned short xlogo16_bits[] = {
0x0f80, 0x1e80, 0x3c40, 0x7820, 0x7810, 0xf008, 0xe009, 0xc005,
0xc002, 0x4007, 0x200f, 0x201e, 0x101e, 0x083c, 0x0478,
0x02f0};
/* XBM X11 format */
#define xlogo16_width 16
#define xlogo16_height 16
static unsigned char xlogo16_bits[] = {
0x0f, 0x80, 0x1e, 0x80, 0x3c, 0x40, 0x78, 0x20, 0x78, 0x10,
0xf0, 0x08, 0xe0, 0x09, 0xc0, 0x05, 0xc0, 0x02, 0x40, 0x07,
0x20, 0x0f, 0x20, 0x1e, 0x10, 0x1e, 0x08, 0x3c, 0x04, 0x78,
0x02, 0xf0};

This page is taken from the Encyclopedia of Graphics File Formats and is licensed by O'Reilly under the Creative Common/Attribution license.

[[Category:Image Formats]]

XWD

2007-02-20T03:43:17Z

Dcsmith77:

XWD is used to store images of captured X window displays.

The XWD (X Window Dump) format is used specifically to store screen dumps created by the X Window System. Under X11, screen dumps are created by the xwd client. Using xwd, the window or background is selected to dump and an XWD file is produced containing an image of the window. If you issue the following command:

% xwd -root > output.xwd

the entire contents of the current display are saved to the file output.xwd. The id of the window to dump may also be specified by using the -id command-line flag on versions of xwd prior to Release 5.

Contents:
File Organization
For Further Information
File Organization

The first version of the X Window System to support window dumps was X10. Only gray-scale and color-mapped dumps were supported, and the bitmapped data was never compressed. The X10 version of XWD contains the following header:

typedef struct _X10WindowDump
{
LONG HeaderSize; /* Header size in bytes */
LONG FileVersion; /* X10 XWD file version (always 06h) */
LONG DisplayType; /* Display type */
LONG DisplayPlanes; /* Number of display planes */
LONG PixmapFormat; /* Pixmap format */
LONG PixmapWidth; /* Pixmap width */
LONG PixmapHeight; /* Pixmap height */
SHORT WindowWidth; /* Window width */
SHORT WindowHeight; /* Window height */
SHORT WindowX; /* Window upper left X coordinate */
SHORT WindowY; /* Window upper left Y coordinate */
SHORT WindowBorderWidth; /* Window border width */
SHORT WindowNumColors; /* Number of color entries in window */
} X10WINDOWDUMP;

HeaderSize is the size of the header in bytes. This value is always 40.

FileVersion contains the version number of the XWD file. This value is always 06h.

DisplayType is the type of the display from which the image was dumped.

DisplayPlanes is the number of color planes in the image data. This value is typically 01h or 03h.

PixmapFormat indicates the format of the bitmap. A value of 00h indicates a single-plane bitmap (XYFormat), and a value of 01h indicates a bitmap with two or more planes (ZFormat).

PixmapWidth and PixmapHeight represent the size of the image in pixels.

WindowWidth and WindowHeight represent the size of the window to display.

WindowX and WindowY represent the position of the window on the display.

WindowBorderWidth indicates the width of the window border in pixels.

WindowNumColors specifies the number of colors that can be displayed in the window.

If the image is a PseudoColor image, a color map immediately follows the header. The color map contains one entry per color in the image, and each entry has the following format:

typedef struct _X10ColorMap
{
WORD EntryNumber; /* Number of the color-map entry */
WORD Red; /* Red-channel value */
WORD Green; /* Green-channel value */
WORD Blue; /* Blue-channel value */
} X10COLORMAP[WindowNumColors];

EntryNumber is the number of the color-map entry. This value starts at 00h. Color maps typically do not exceed 256 entries in size.

Red, Green, and Blue are the RGB channel values for this entry. The range of each of these values is typically 0 to 65535; often, only the high byte of the value is set (i.e., the value is 0-255 shifted left eight bits.)

The XWD format was revised for Version 11 of the X Window System. The new format can store more types of image data and many fields have been added to the header and to the color map, reflecting the increased graphics capabilities of X11 over X10.

The Version 11 XWD file format contains the following header:

typedef struct _X11WindowDump
{
DWORD HeaderSize; /* Size of the header in bytes */
DWORD FileVersion; /* X11WD file version (always 07h) */
DWORD PixmapFormat; /* Pixmap format */
DWORD PixmapDepth; /* Pixmap depth in pixels */
DWORD PixmapWidth; /* Pixmap width in pixels */ /
DWORD PixmapHeight; /* Pixmap height in pixels */
DWORD XOffset; /* Bitmap X offset */
DWORD ByteOrder; /* Byte order of image data */
DWORD BitmapUnit; /* Bitmap base data size */
DWORD BitmapBitOrder; /* Bit-order of image data */
DWORD BitmapPad; /* Bitmap scan-line pad*/
DWORD BitsPerPixel; /* Bits per pixel */
DWORD BytesPerLine; /* Bytes per scan-line */
DWORD VisualClass; /* Class of the image */
DWORD RedMask; /* Red mask */
DWORD GreenMask; /* Green mask */
DWORD BlueMask; /* Blue mask */
DWORD BitsPerRgb; /* Size of each color mask in bits */
DWORD NumberOfColors; /* Number of colors in image */
DWORD ColorMapEntries; /* Number of entries in color map */
DWORD WindowWidth; /* Window width */
DWORD WindowHeight; /* Window height */
LONG WindowX; /* Window upper left X coordinate */
LONG WindowY; /* Window upper left Y coordinate */
DWORD WindowBorderWidth; /* Window border width */
} X11WINDOWDUMP;

HeaderSize is the size of the header in bytes. This value is always 40.

FileVersion contains the version number of the XWD file. This value is always 07h.

PixmapFormat is the format of the image data. A value of 00h indicates a 1-bit (XYBitmap) format. A value of 01h indicates a single-plane bitmap (XYPixmap). A value of 02h indicates a bitmap with two or more planes (ZPixmap).

PixmapDepth is the depth of the bitmap in pixels. This value is 1 to 32.

PixmapWidth and PixmapHeight represent the size of the image in pixels.

XOffset specifies the number of pixels to ignore at the beginning of each scan-line.

ByteOrder indicates the byte order of the image data. Values for this field are 00h for least significant byte first, and 0 for most significant byte first.

BitmapUnit is the size of each data unit in each scan line. This value may be 8, 16, or 32.

BitmapBitOrder indicates the order of the bits within each byte of image data. Values for this field are 00h for least significant byte first, and 0 for most significant byte first.

BitmapPad is the number of bits of padding added to each scan line. This value may be 8, 16, or 32.

BitsPerPixel contains the size of each pixel in bits. For StaticGray and GrayScale images, this value is 1. For StaticColor and PseudoColor images, this value is 2 to 15 (typically 8). For TrueColor and DirectColor images, this value is 16, 24, or 32.

BytesPerLine is the size of each scan line in bytes.

VisualClass indicates the format of the image data:

* Even-numbered values indicate fixed-image data that cannot be changed in memory.

* Odd-numbered values indicate dynamic image data that may be altered.

* The values 00h (StaticGray) and 01h (GrayScale) specify a gray-scale image.

* The values 02h (StaticColor) and 03h (PseudoColor) indicate a color mapped image.

* The values 04h (TrueColor) and 05h (DirectColor) indicate true-color image data.

RedMask, GreenMask, and BlueMask are the RGB mask values used by ZPixmaps.

BitsPerRgb is the size of each RedMask, GreenMask, and BlueMask in bits.

NumberOfColors specifies the number of colors in the image. This value also indicates the number of colors for colormapped images as well.

ColorMapEntries contains the number of entries in the color map. This value is 00h if there is no color map.

WindowWidth and WindowHeight are the size of the window to display.

WindowX and WindowY contain the position of the window on the display.

WindowBorderWidth is the width of the X Window border in pixels. If the border has not been captured in the dump, this value is 00h.

The color map immediately follows the header. Each entry in the color map is 12 bytes in size and has the following format:

typedef struct _X11ColorMap
{
DWORD EntryNumber; /* Number of the color map entry */
WORD Red; /* Red-channel value */
WORD Green; /* Green-channel value */
WORD Blue; /* Blue-channel value */
CHAR Flags; /* Flag for this entry */
CHAR Padding; /* WORD-align padding */
} X11COLORMAP[ColorMapEntries];

EntryNumber is the number of the color map entry. This value starts at 00h. Color maps typically do not exceed 256 entries in size.

Red, Green, and Blue are the RGB channel values for this entry. The range of each of these values is typically 0 to 65535; often, only the high byte of the value is set (i.e., the value is 0-255 shifted left eight bits.)

Flags indicates which of the color channels in the color map are actually used. The value of this field is typically 07h, indicating that all three channels are used.

Padding is a byte set to a value of 00h and used to pad the color map entry out to an even WORD boundary in size.
For Further Information

This page is taken from the Encyclopedia of Graphics File Formats and is licensed by O'Reilly under the Creative Common/Attribution license.

[[Category:Image Formats]]

WPG

2007-02-20T03:41:32Z

Dcsmith77:

Usage
Used for storage of document and image data.

Comments
WPG is supported by other applications mainly for compatibility, due to the widespread distribution of WordPerfect for MS-DOS.

The WordPerfect Graphics Metafile (WPG) file format is a creation of WordPerfect Corporation (WPC) specifically for use with its line of software products. WPG image files are likely to be found in any environment that is supported by WPC products, including MS-DOS, UNIX, and the Apple Macintosh.

Contents:
File Organization
File Details
For Further Information

WPG files are capable of storing both bitmap and vector data, which may contain up to 256 individual colors chosen from a palette of more than one million total colors. It is also possible to store Encapsulated PostScript (EPS) code in a WPG file.

The particular version described in this article is the WordPerfect Graphic file format as created by the WPC products WordPerfect 5.x and DrawPerfect 1.x.

A WPG-format file created using WordPerfect 5.0 can store either bitmap or vector image data, but not both at once. WPG files created under WordPerfect 5.1 and later can store both bitmap and vector image data in the same file. Unfortunately, there is no way to tell whether a WPG file contains both bitmap and vector data by reading the header. The actual record data from the body of the file must be read and interpreted.

File Organization

In WPC terminology, a WordPerfect Graphics Metafile contains a prefix area (the header) and a record area (the graphics data). All data in the metafile is written using the big-endian byte order.
File Details

This section contains information about the prefix and record areas of a WordPerfect Graphics Metafile.
Prefix

The prefix is 16 bytes in length and has the following format:

typedef struct _WordPerfectGraphic
{
BYTE FileId[4]; /* File Id Code (always FFh 57h 50h 43h) */
DWORD DataOffset; /* Stat of data in the WPG file (always 10h)*/
BYTE ProductType; /* Product Code (always 1) */
BYTE FileType; /* WPC File Code (always 16h) */
BYTE MajorVersion; /* Major Version Code (always 1) */
BYTE MinorVersion; /* Minor Version Code (always 0) */
WORD EncryptionKey;/* Password Checksum (0 = not encrypted) */
WORD Reserved; /* Reserved field (always 0) */
} WPGHEAD;

FileId values are four contiguous bytes that contain the standard WPC File ID code. All WPC files starting with those created by WordPerfect 5.0 begin with this code. The values for these fields, in order, are FFh, 57h, 50h, and 43h.

DataOffset contains an offset value pointing to the start of the record data in the WordPerfect Graphics Metafile. Because the record data always immediately follows the prefix, and the prefix is always 16 bytes in length, this value is always 10h.

ProductType identifies the WPC software product that created the WPG file. This field always contains the value 01h, indicating that the file was created by the WordPerfect word processor. This value is always the same, even if the WPG file was created by a third-party software application.

FileType identifies the type of data the file contains. For WPG files, the value of this field is always 16h.

MajorVersion and MinorVersion contain the internal version number of the product for which the WPG file was created (which may not match the published, external version number of the product). For all WPG files, the MajorVersion field always contains a value of 01h, and the MinorVersion field always contains a value of 00h.

EncryptionKey normally contains a value of 00h if the file is not encrypted. If the value of this field is non-zero, then the value is used as the checksum of the password and is used to decrypt the file. In the current version, WPG files are never encrypted and therefore the value of this field is always 00h.

Reserved is not currently used and always contains a value of 00h.
Record Area

Following the prefix in a WordPerfect Graphics Metafile is the record area. This area contains a sequence of objects and their attributes; this information is used to render the image. Any colormaps, bitmaps, and sections of PostScript code are also considered objects within the WPG file record area.
Record prefix

Each record begins with a record prefix (a header in almost any other format). The record prefix may be two, four, or six bytes in length depending on the type of record it precedes. Here are the three possible record prefix formats:

/* Two-byte prefix */
typedef struct _TwoByteRecPrefix
{
BYTE RecordType; /* The Record Type identifier */
BYTE RecordLength; /* The length of the record in bytes (0-FEh)*/
} RECPREFIX2BYTE;

/* Four-byte prefix */
typedef struct _FourByteRecPrefix
{
BYTE RecordType; /* The Record Type identifier */
BYTE SizeIndicator; /* WORD or DWORD length follows (always FFh)*/
WORD RecordLength; /* The length of the record in bytes */
} RECPREFIX4BYTE;

/* Six-byte prefix */
typedef struct _SixByteRecPrefix
{
BYTE RecordType; /* The Record Type identifier */
BYTE SizeIndicator; /* WORD or DWORD length follows (always FFh)*/
DWORD RecordLength; /* The length of the record in bytes */
} RECPREFIX6BYTE;

Record type

RecordType, the first field of each record, contains a value that identifies the type of data stored in the record as follows:

Record Type

Record Description

01h

Fill attributes

02h

Line attributes

03h

Marker attributes

04h

Polymarker

05h

Line

06h

Polyline

07h

Rectangle

08h

Polygon

09h

Ellipse

0Ah

Reserved

0Bh

Bitmap (Type 1)

0Ch

Graphics text (Type 1)

0Dh

Graphics text attributes

0Eh

Color map

0Fh

Start of WPG data (Type 1)

10h

End of WPG data

11h

PostScript data follows (Type 1)

12h

Output attributes

13h

Curved polyline

14h

Bitmap (Type 2)

15h

Start figure

16h

Start chart

17h

PlanPerfect data

18h

Graphics text (Type 2)

19h

Start of WPG data (Type 2)

1Ah

Graphics text (Type 3)

1Bh

PostScript data follows (Type 2)

The following is a listing of the record types, their formats, and the flags associated with them. For more information, please consult the Wordperfect documentation.
Fill Attributes

BYTE 0

Hollow

1

Solid

2

Finely spaced 45-degree lines

3

Medium spaced 45-degree lines

4

Coarsely spaced 45-degree lines

5

Fine 45-degree hatching

6

Medium 45-degree hatching

7

Coarse 45-degree hatching

8

Fine vertical lines

9

Medium vertical lines

10

Coarse vertical lines

11

Dots density 1 (least dense)

12

Dots density 2

11

Dots density 3

13

Dots density 4

14

Dots density 5

15

Dots density 6

16

Dots density 7 (densest)

18

Dots (medium)

19

Dots (coarse)

20

Fine horizontal

21

Medium horizontal

22

Coarse horizontal

23

Fine 90-degree cross-hatching

24

Medium 90-degree cross-hatching

25

Coarse 90-degree cross-hatching

26

Fine 45-degree lines

27

Medium 45-degree lines

28

Coarse 45-degree lines

29

Brick pattern (horizontal)

30

Brick pattern (vertical)

31

NA

32

Interweaving

33

NA

34

NA

35

Tile pattern

36

Coarse lines (thick)

37

Alternating dark and light squares

BYTE

Fill-color palette index (0-ffh)

Line Attributes

BYTE 0

None

1

Solid

2

Dash 1 (long)

3

Dots

4

Dash-dot

5

Dash 2 (medium)

6

Dash-dot-dot

7

Dash 3 (short)

BYTE

Line color (0-ffh)

WORD

Line width (arbitrary units)

Marker Attributes

BYTE 0

None

1

Dots

2

Plus sign

3

Star

4

Circle

5

Square

6

Triangle

7

Inverted triangle

8

Diamond

9

45-degree cross

BYTE

Marker color (0-ffh)

WORD

Marker height (arbitrary units)

Polymarker

The first area, two bytes in length, holds the number of points. This is followed by a list of WORD coordinate pairs denoting the position of the actual points in arbitrary units.
Line

WORD

X value of start of line

WORD

Y value of start of line

WORD

X value of end of line

WORD

Y value of end of line

These are all in arbitrary units.
Polyline

The first area, two bytes in length, holds the number of points. This is followed by a list of WORD coordinate pairs denoting the position of the actual points in arbitrary units.
Rectangle

WORD

X of lower left of rectangle

WORD

Y of lower left of rectangle

WORD

Width

WORD

Height

These are all in arbitrary units.
Polygon

The first area, two bytes in length, holds the number of vertices. This is followed by a list of WORD coordinate pairs denoting the position of the actual vertices in arbitrary units.
Ellipse

WORD

X value of center

WORD

Y value of center

WORD

X radius

WORD

Y radius

WORD

Rotation angle measured from the x axis

WORD

Start of arc (degrees)

WORD

End of arc (degrees)

WORD

Flags: bit 0 connect ends of arc to center, bit 1 connect to each other

Bitmap Type 1

WORD

Width (pixels)

WORD

Height (pixels)

WORD

Bits-per-pixel (1,2,4,8)

WORD

X-resolution of source (pixels/inch)

WORD

Y-resolution of source (pixels/inch)

This is followed by the bitmap data in BYTE format. Note that this may be RLE compressed.
Graphic Text Type 1

WORD

Text length in bytes

WORD

X value of text position

WORD

Y value of text position

This is followed by the text string in BYTE format.
Graphics Text Attributes

WORD

Font character width (arbitrary units)

WORD

Font character height (arbitrary units)

WORD

Reserved

WORD

Reserved

WORD

Reserved

WORD

Reserved

WORD

Reserved

WORD

Font type--e.g., 0df0 Courier, 1150 Helvetica, 1950 Times

BYTE

Reserved

BYTE

Alignment, vertical (0 left, 1 center, 2 right)

BYTE

Alignment, horizontal (0 base, 1 center, 2 cap, 3 bottom, 4 top)

BYTE

Color (0-ffh)

WORD

Rotation (degrees from horizontal)

Colormap

WORD

Start color (0-ffh)

WORD

Number of colors

BYTE

Red value of first color

BYTE

Green value of first color

BYTE

Blue value of first color

.
.
.

BYTE

Red value of last color

BYTE

Green value of last color

BYTE

Blue value of last color

Start of WPG Data

BYTE

Version number

BYTE

Flags (bit 0 PostScript, maybe bitmap, bit 1 PostScript, no bitmap

WORD

Width of image (arbitrary units)

WORD

Height of image (arbitrary units)

End of WPG Data

This record has no data associated with it. It is used to signal the end of a data section in the file and acts as an end-of-file marker.
PostScript Data Follows

BYTE

Actual PostScript data

.
.
.

BYTE

Output Attributes (WordPerfect 5.0 only)

BYTE

Background color (0-ffh)

BYTE

Foreground color (0-ffh)

WORD

X value of lower left of clipping window

WORD

Y value of lower left of clipping window

WORD

Clip window width

WORD

Clip window height

Size and position values are in arbitrary units.
Curved Polyline (WordPerfect 5.1 and later)

DWORD

Size of equivalent data in pre-5.1 files

WORD

Number of points

WORD

X value of first point

WORD

Y value of first point

WORD

X value of first control point

WORD

Y value of first control point

.
.
.

WORD

X value of last point

WORD

Y value of last point

WORD

X value of last control point

WORD

Y value of last control point

Bitmap Type 2 (WordPerfect 5.1 and later)

WORD

Rotation angle from horizontal (degrees)

WORD

X value of lower left

WORD

Y value of lower left

WORD

X value of upper right

WORD

Y value of upper right

WORD

Width (pixels)

WORD

Height (pixels)

WORD

Pixel depth (bits)

WORD

Horizontal resolution (pixels/inch)

WORD

Vertical resolution (pixels/inch)

This is followed by the actual bitmap data, which is RLE compressed, although there appear to be some (possibly illegal) variants produced by third-party programs which are not.
Start Figure

DWORD

Length of object data

WORD

Rotation angle from horizontal (degrees)

WORD

X value of lower left

WORD

Y value of lower left

WORD

X value of upper right

WORD

Y value of upper right

This is followed by the figure data.
Start Chart

DWORD

Length of chart data in file

WORD

X value lower left

WORD

Y value lower left

WORD

X value upper right

WORD

Y value upper right

This is followed by the actual chart data.
PlanPerfect Data

This is data associated with WordPerfect Corporation's PlanPerfect application. Please contact WordPerfect for more information.
Graphics Text Type 2 (WordPerfect version 5.1 and later)

DWORD

Size of equivalent data written by version prior to 5.1

WORD

Rotation angle from horizontal (degrees)

WORD

Length of text (characters)

WORD

X value of text start

WORD

Y value of text start

WORD

X value of text end

WORD

Y value of text end

WORD

X scale factor

WORD

Y scale factor

BYTE

Type (0 window, 1 line, 2 bullet chart, 3 simple chart, 4 free-format chart)

This is followed by the string data.
Start of WPG Data Type 2

BYTE

Type

WORD

Length of data in file

This is followed by the actual data.
RecordLength

RecordLength, the second field of each record, may be a BYTE, WORD, or DWORD in size, depending upon the value stored in the first BYTE of this field (SizeIndicator above). Because it is possible for the same RecordType to have a different size each time it appears in the same WPG file, each record cannot be assigned a RecordType field of a fixed size. You must therefore determine the size of the RecordLength field when you read the record prefix.

If the BYTE value read after the RecordType field is in the range of 00h to FEh, the RecordLength field is a BYTE in size, and this value is used as the number of bytes in the record. If the BYTE is the value FFh, then the RecordLength field is either a WORD or a DWORD in size.

The next WORD of the prefix is then read. If the high bit of this WORD is 0, then this value is the length of the record. If the high bit is 1, then this value is the upper WORD value of a DWORD length value. The next WORD is read and is used as the lower WORD value in the DWORD. This DWORD value is then the length of the record. The following code should help to clarify this logic:

BYTE RecordType;
DWORD RecordLength;
FILE *fp;
RecordType = GetByte(fp); /* Read the RecordType */
RecordLength = GetByte(fp); /* Read the RecordLength */
if (RecordLength == 0xFF) /* Not a BYTE value */
{
RecordLength = GetWord(fp); /* Read the next WORD value */
if(RecordLength & 0x8000) /* Not a WORD value */
{
RecordLength <<= 16; /* Shift value into the high WORD */
RecordLength += GetWord(fp); /* Read the low WORD value */
}
}

Example Records

The following is a description of several of the records found in the WPG format. For a complete listing of all records and values, refer to the WordPerfect Developer's Toolkit.

The first record of a WPG file is always the Start WPG Data (0Fh) record. This record contains information on the size of the image and the version number of the WPG file and has the following format:

typedef struct _StartWpgRecord
{
BYTE Version; /* WPG Version Flags (always 01h) */
BYTE WpgFlags; /* Bit flags */
WORD Width; /* Width of image in WP Units */
WORD Height; /* Height of image in WP Units */
} STARTWPGREC;

Version indicates the WPG file version. This value is currently defined to be 01h.

The eight bits in the WpgFlags field are used as flag values. If Bit 0 is set to 0, then there is no PostScript code included in this WPG file. If Bit 0 is set to 1, then PostScipt code is included in this file. Bits 1 through 7 are reserved and always set to 0.

Width and Height contain the size of the image in WP Units (WPU), each of which is equal to 1/1200th of an inch.

A ColorMapRecord (0Eh) normally follows the StartWpgRecord, unless the image is black and white. If no ColorMapRecord is present, then the default colormap is used instead. There is only one ColorMapRecord per WPG file, regardless of how many bitmap or vector objects the file contains. The current WPG format does not provide a way to assign separate colormaps to specific vector objects and bitmaps.

All images stored in a WPG file, both bitmap and vector, use index values into the colormap to define their colors. This record may define an entire color map unique to this image, or it may define only a smaller colormap used to overlay a portion of the default colormap. To avoid problems with WPC products, the first 16 colors in the colormap should never be changed from their default values. The ColorMapRecord has the following format:

typedef struct _ColorMapRecord
{
WORD StartIndex; /* The starting index of this color map */
WORD NumberOfEntries;/* The number of entries in this color map*/
BYTE *ColorMap[][3]; /* Color map triples */
} COLORMAPREC;

StartIndex indicates the starting color index number of this map.

NumberOfEntries indicates the number of contiguous entries in the colormap from the starting index. If entries 178 though 244 in the default colormap were being replaced by this colormap, the value of StartIndex would be 178, and the value of NumberOfEntries would be 66. If the entire colormap were being replaced, the values of these fields would be 0 and 256 respectively.

These two fields are followed by a sequence of three-byte triples, which hold the actual colormap data. The number of triples is equal to the value stored in the NumberOfEntries field. The number of bytes in this field is calculated by multiplying the value of the NumberOfEntries field by 3. The default colormap for WPG files is the same as the IBM VGA standard color table defined in the PS/2 Display Adapter manual.

The VGA colormap structure is also shown in Chapter 2, in the section called "Examples of Palettes."

This colormap contains 256 color entries, each with a 1-byte red, green, and blue color value for a total of 768 map elements. The first 16 colors are those of the IBM EGA color table. Colors 17 through 32 are 16 gray-scale shades. The remaining 224 colors are a palette of 24 individual colors, each with three different intensity levels and three different saturation levels. The WPG color map uses eight bits for red and six bits each for green and blue.

When displaying WPG images using a display adapter, such as the VGA, with fewer bits per primary color, the color values are truncated starting with the least significant bits. For a VGA adapter that has only 6 bits for red, all 8-bit red values in the color table are shifted to the right twice before the value is used. The green and blue values are not changed.

As previously mentioned, a WPG file created with WordPerfect 5.0 can store either bitmap or vector image data, but not both. This is due to a limitation of the Bitmap (0Bh) record structure. This record is now considered obsolete and should not be used when you create new WPG files. The structure of this record is as follows:

typedef struct _BitmapType1
{
WORD Width; /* Width of image in pixels */
WORD Height; /* Height of image in pixels */
WORD Depth; /* Number of bits per pixel */
WORD HorzRes; /* Horizontal resolution of image */
WORD VertRes; /* Vertical resolution of image */
} BITMAP1REC;

Width and Height describe the size of the bitmap in pixels.

Depth contains the number of bits per pixel. The possible values of this field are 1, 2, 4, or 8 for 2-, 4-, 16-, and 256-color images.

HorzRes and VertRes are the horizontal and vertical resolution of the original bitmap in pixels per inch. These values can also describe the minimum resolution of the screen required to display the image.

The bitmap data follows this record structure. The Bitmap Type 1(0Bh) record was superseded by the Bitmap Type 2 (14h) record introduced with WordPerfect 5.1. This new record added five fields not found in the Bitmap Type 1 record. These fields contain information on the position of the bitmap on the output device. If you use a Bitmap Type 2 record, it is also possible to store multiple bitmaps in a single WPG file.

The structure of the Bitmap Type 2 record is shown below:

typedef struct _BitmapType2
{
WORD RotAngle; /* Rotation angle of bitmap (0-359) */
WORD LowerLeftX; /* Lower-left X coordinate of image */
WORD LowerLeftY; /* Lower-left Y coordinate of image */
WORD UpperRightX; /* Upper-right X coordinate of image */
WORD UpperRightY; /* Upper-right Y coordinate of image */
WORD Width; /* Width of image in pixels */
WORD Height; /* Height of image in pixels */
WORD Depth; /* Number of bits per pixel */
WORD HorzRes; /* Horizontal resolution of image */
WORD VertRes; /* Vertical resolution of image */
} BITMAP2REC;

RotAngle is the rotation angle of the bitmap in degrees. This value may be in the range of 0 to 359, with 0 indicating the image is not rotated.

LowerLeftX and LowerLeftY describe the location of the lower-left corner of the image in WPUs.

UpperRightX and UpperRightY describe the location of the upper-right corner of the image in WPUs. Note that the origin point (0,0) of all WPG images is the lower left-hand corner of the output device.

The remaining five fields, Width, Height, Depth, HorzRes, and VertRes, are identical to those in the Bitmap Type 1 record.

It is possible to store two or more images in a WPG file by using multiple Bitmap records. The coordinate information found in a Bitmap Type 2 record will allow the images to be positioned on the output device so they do not overlap. The size of a bitmap in bytes may be determined by multiplying the Height, Width, and Depth fields and then dividing the product by 8:

SizeInBytes = (Height * Width * Depth) / 8;

Bitmap data is always stored in a WPG file using a byte-wise run-length encoding (RLE) algorithm. (See Chapter 9, Data Compression, for more information on run-length encoding algorithms.) Each scan line is encoded separately.

There are four possible types of RLE packets in the WPG algorithm:

* Encoded packet

* Literal packet

* All-bits-on packet

* Repeat scan-line packet

An encoded packet may encode a run of from 1 to 127 bytes in length. An encoded packet always has the most significant bit (MSB) as 1 and the seven least significant bits (LSBs) are a non-zero value. The length of the run is the value of the seven LSBs. If the MSB of this byte is 1, but the seven LSBs are set to 0, then the next byte is read as the run count and the byte value FFh is repeated "run count" times. If the MSB of the byte read is 0, and the seven LSBs are a non-zero value, then this is a literal run. The seven LSBs hold the run-count value and the next "run count" bytes are read literally from the encoded data stream. If the run count is 0, then the next byte is read as the run count and the previous scan line is repeated "run count" times.

The pseudocode for the WPG RLE algorithm is shown below:

Read a BYTE
If the Most Significant Bit is ON
If the 7 LSB are not 0
The RunCount is the 7 least significant bits
Read the next BYTE and repeat it RunCount times
If the 7 LSB are 0
Read the next BYTE as the RunCount
Repeat the value FFh RunCount times
If the Most Significant Bit is OFF
If the 7 LSB are not 0
The RunCount is the 7 least significant bits
The next RunCount BYTEs are read literally
If the 7 LSB are 0
Read the next BYTE as the RunCount
Repeat the previous scan line RunCount times

Encapsulated PostScript (EPS) data may be included in a WPG file by using the PostScript Data Type 1 (11h) record or the PostScript Data Type 2 (1Bh) record. The PostScript Data Type 1 record contains a set of output commands needed to print the EPS code included in the WPG file on a PostScript printer. The structure for the PostScript Data Type 1 record is as follows:

typedef struct _PsDataType1
{
WORD BbLowerLeftX; /* Lower left X coordinate of image */
WORD BbLowerLeftY; /* Lower left Y coordinate of image */
WORD BbUpperRightX; /* Upper right X coordinate of image */
WORD BbUpperRightY; /* Upper right Y coordinate of image */
} PSTYPE1REC;

The four fields in this record contain the bounding-box values of the PostScript image in points. These are the values found in the %%BoundingBox field in the EPS header. The EPS data immediately follows this record. The PostScript Data Type 2 record is used to store one or more EPS images. If the EPS data also contains a TIFF, PICT, WMF, or EPSI image, as is found in a Display PostScript file, this data is converted to a Bitmap Type 2 record that follows the PostScript Data Type 2 record.

The structure for the PostScript Data Type 2 record is shown below:

typedef struct _PsDataType2
{
DWORD RecordLength; /* Length of the following record */
WORD RotAngle; /* Angle of roation of image */
WORD LowerLeftX; /* Lower-left X coordinate of image */
WORD LowerLeftY; /* Lower-left Y coordinate of image */
WORD UpperRightX; /* Upper-right X coordinate of image */
WORD UpperRightY; /* Upper-right Y coordinate of image */
BYTE FileName[40]; /* File name of original EPSF file */
WORD BbLowerLeftX; /* Lower-left X coordinate of bounding box */
WORD BbLowerLeftY; /* Lower-left Y coordinate of bounding box */
WORD BbUpperRightX; /* Upper-right X coordinate of bounding box */
WORD BbUpperRightY; /* Upper-right Y coordinate of bounding box */
} PSTYPE2REC;

RecordLength indicates the number of bytes occuring in the Bitmap Type 2 record following the EPS data. If the EPS data does not have an associated Bitmap Type 2 record, then the value of this field is 0.

The RotAngle, LowerLeftX, LowerLeftY, UpperRightX, and UpperRightY fields have the same meaning as in the Bitmap Type 2 (14h) record.

FileName contains the name of the original EPSF file from which this EPSF code was derived.

The BbLowerLeftX, BbLowerLeftY, BbUpperRightX, and BbUpperRightY fields are the same as in the PostScript Data Type 1 (11h) record.

The EPSF code immediately follows this record. The PostScript Data Type 2 record found in WordPerfect 5.1 and DrawPerfect supersedes the PostScript Data Type 1 record found only in WordPerfect 5.0 and DrawPerfect 1.0. You should always use the Type 2 record rather than the Type 1 when creating new WPG files.

The last record in every WPG file is the End of WPG Data (10h) record. This record has a NULL body; it merely marks the end of the WPG record stream.

This page is taken from the Encyclopedia of Graphics File Formats and is licensed by O'Reilly under the Creative Common/Attribution license.

[[Category:Image Formats]]

DPX / Cineon

2007-02-20T03:41:00Z

Dcsmith77:

'''DPX''', the short form of '''Digital Picture Exchange''', is a common file format for digital film work and is an ANSI/SMPTE standard (268M-2003). The file format primarily represents the Optical density of each color channel of a scanned negative in a 10-bit log format where the Gamma correction of the original camera negative is preserved as taken by a film scanner.
DPX provides a great deal of flexibility in storing color and other information for exchange between production facilities. Multiple forms of packing and alignment are possible.

The DPX file format is derived from the output file format of the Kodak Cineon film scanner, and has been published by SMPTE as ANSI/SMPTE 268M-2003 (originally was version 1 268M-1994).

== Availability of the Official DPX Standard ==

'''Availability in Single Copy:'''

SMPTE has the DPX standard 268M-2003, indexed [http://www.smpte.org/smpte_store/standards/index.cfm?scope=0&stdtype=smpte&CurrentPage=11 on page 11] of [http://www.smpte.org/smpte_store/standards/index.cfm?stdtype=smpte&scope=0 their standards index] (April, 2005)

GraphicsMagick has implemented the format, info available [http://www.graphicsmagick.org/www/motion-picture.html]

[[Category:Image Formats]]

WPG

2007-02-18T02:51:57Z

Dcsmith77:

DPX / Cineon

2007-02-18T02:37:45Z

Dcsmith77:

XBM

2007-02-18T02:18:47Z

Dcsmith77:

XWD

2007-02-18T02:17:29Z

Dcsmith77:

XWD

2007-02-18T02:09:03Z

Dcsmith77:

{|
|+
|- Type | Bitmap ||
|- Colors | Unlimited ||
|- Compression | Uncompressed ||
|- Maximum Image Size | 64Kx64K ||
|- Multiple Images Per File | No ||
|- Numerical Format | Big- and little-endian ||
|}

XWD is used to store images of captured X window displays.

The XWD (X Window Dump) format is used specifically to store screen dumps created by the X Window System. Under X11, screen dumps are created by the xwd client. Using xwd, the window or background is selected to dump and an XWD file is produced containing an image of the window. If you issue the following command:

% xwd -root > output.xwd

the entire contents of the current display are saved to the file output.xwd. The id of the window to dump may also be specified by using the -id command-line flag on versions of xwd prior to Release 5.

Contents:
File Organization
For Further Information
File Organization

The first version of the X Window System to support window dumps was X10. Only gray-scale and color-mapped dumps were supported, and the bitmapped data was never compressed. The X10 version of XWD contains the following header:

typedef struct _X10WindowDump
{
LONG HeaderSize; /* Header size in bytes */
LONG FileVersion; /* X10 XWD file version (always 06h) */
LONG DisplayType; /* Display type */
LONG DisplayPlanes; /* Number of display planes */
LONG PixmapFormat; /* Pixmap format */
LONG PixmapWidth; /* Pixmap width */
LONG PixmapHeight; /* Pixmap height */
SHORT WindowWidth; /* Window width */
SHORT WindowHeight; /* Window height */
SHORT WindowX; /* Window upper left X coordinate */
SHORT WindowY; /* Window upper left Y coordinate */
SHORT WindowBorderWidth; /* Window border width */
SHORT WindowNumColors; /* Number of color entries in window */
} X10WINDOWDUMP;

HeaderSize is the size of the header in bytes. This value is always 40.

FileVersion contains the version number of the XWD file. This value is always 06h.

DisplayType is the type of the display from which the image was dumped.

DisplayPlanes is the number of color planes in the image data. This value is typically 01h or 03h.

PixmapFormat indicates the format of the bitmap. A value of 00h indicates a single-plane bitmap (XYFormat), and a value of 01h indicates a bitmap with two or more planes (ZFormat).

PixmapWidth and PixmapHeight represent the size of the image in pixels.

WindowWidth and WindowHeight represent the size of the window to display.

WindowX and WindowY represent the position of the window on the display.

WindowBorderWidth indicates the width of the window border in pixels.

WindowNumColors specifies the number of colors that can be displayed in the window.

If the image is a PseudoColor image, a color map immediately follows the header. The color map contains one entry per color in the image, and each entry has the following format:

typedef struct _X10ColorMap
{
WORD EntryNumber; /* Number of the color-map entry */
WORD Red; /* Red-channel value */
WORD Green; /* Green-channel value */
WORD Blue; /* Blue-channel value */
} X10COLORMAP[WindowNumColors];

EntryNumber is the number of the color-map entry. This value starts at 00h. Color maps typically do not exceed 256 entries in size.

Red, Green, and Blue are the RGB channel values for this entry. The range of each of these values is typically 0 to 65535; often, only the high byte of the value is set (i.e., the value is 0-255 shifted left eight bits.)

The XWD format was revised for Version 11 of the X Window System. The new format can store more types of image data and many fields have been added to the header and to the color map, reflecting the increased graphics capabilities of X11 over X10.

The Version 11 XWD file format contains the following header:

typedef struct _X11WindowDump
{
DWORD HeaderSize; /* Size of the header in bytes */
DWORD FileVersion; /* X11WD file version (always 07h) */
DWORD PixmapFormat; /* Pixmap format */
DWORD PixmapDepth; /* Pixmap depth in pixels */
DWORD PixmapWidth; /* Pixmap width in pixels */ /
DWORD PixmapHeight; /* Pixmap height in pixels */
DWORD XOffset; /* Bitmap X offset */
DWORD ByteOrder; /* Byte order of image data */
DWORD BitmapUnit; /* Bitmap base data size */
DWORD BitmapBitOrder; /* Bit-order of image data */
DWORD BitmapPad; /* Bitmap scan-line pad*/
DWORD BitsPerPixel; /* Bits per pixel */
DWORD BytesPerLine; /* Bytes per scan-line */
DWORD VisualClass; /* Class of the image */
DWORD RedMask; /* Red mask */
DWORD GreenMask; /* Green mask */
DWORD BlueMask; /* Blue mask */
DWORD BitsPerRgb; /* Size of each color mask in bits */
DWORD NumberOfColors; /* Number of colors in image */
DWORD ColorMapEntries; /* Number of entries in color map */
DWORD WindowWidth; /* Window width */
DWORD WindowHeight; /* Window height */
LONG WindowX; /* Window upper left X coordinate */
LONG WindowY; /* Window upper left Y coordinate */
DWORD WindowBorderWidth; /* Window border width */
} X11WINDOWDUMP;

HeaderSize is the size of the header in bytes. This value is always 40.

FileVersion contains the version number of the XWD file. This value is always 07h.

PixmapFormat is the format of the image data. A value of 00h indicates a 1-bit (XYBitmap) format. A value of 01h indicates a single-plane bitmap (XYPixmap). A value of 02h indicates a bitmap with two or more planes (ZPixmap).

PixmapDepth is the depth of the bitmap in pixels. This value is 1 to 32.

PixmapWidth and PixmapHeight represent the size of the image in pixels.

XOffset specifies the number of pixels to ignore at the beginning of each scan-line.

ByteOrder indicates the byte order of the image data. Values for this field are 00h for least significant byte first, and 0 for most significant byte first.

BitmapUnit is the size of each data unit in each scan line. This value may be 8, 16, or 32.

BitmapBitOrder indicates the order of the bits within each byte of image data. Values for this field are 00h for least significant byte first, and 0 for most significant byte first.

BitmapPad is the number of bits of padding added to each scan line. This value may be 8, 16, or 32.

BitsPerPixel contains the size of each pixel in bits. For StaticGray and GrayScale images, this value is 1. For StaticColor and PseudoColor images, this value is 2 to 15 (typically 8). For TrueColor and DirectColor images, this value is 16, 24, or 32.

BytesPerLine is the size of each scan line in bytes.

VisualClass indicates the format of the image data:

* Even-numbered values indicate fixed-image data that cannot be changed in memory.

* Odd-numbered values indicate dynamic image data that may be altered.

* The values 00h (StaticGray) and 01h (GrayScale) specify a gray-scale image.

* The values 02h (StaticColor) and 03h (PseudoColor) indicate a color mapped image.

* The values 04h (TrueColor) and 05h (DirectColor) indicate true-color image data.

RedMask, GreenMask, and BlueMask are the RGB mask values used by ZPixmaps.

BitsPerRgb is the size of each RedMask, GreenMask, and BlueMask in bits.

NumberOfColors specifies the number of colors in the image. This value also indicates the number of colors for colormapped images as well.

ColorMapEntries contains the number of entries in the color map. This value is 00h if there is no color map.

WindowWidth and WindowHeight are the size of the window to display.

WindowX and WindowY contain the position of the window on the display.

WindowBorderWidth is the width of the X Window border in pixels. If the border has not been captured in the dump, this value is 00h.

The color map immediately follows the header. Each entry in the color map is 12 bytes in size and has the following format:

typedef struct _X11ColorMap
{
DWORD EntryNumber; /* Number of the color map entry */
WORD Red; /* Red-channel value */
WORD Green; /* Green-channel value */
WORD Blue; /* Blue-channel value */
CHAR Flags; /* Flag for this entry */
CHAR Padding; /* WORD-align padding */
} X11COLORMAP[ColorMapEntries];

EntryNumber is the number of the color map entry. This value starts at 00h. Color maps typically do not exceed 256 entries in size.

Red, Green, and Blue are the RGB channel values for this entry. The range of each of these values is typically 0 to 65535; often, only the high byte of the value is set (i.e., the value is 0-255 shifted left eight bits.)

Flags indicates which of the color channels in the color map are actually used. The value of this field is typically 07h, indicating that all three channels are used.

Padding is a byte set to a value of 00h and used to pad the color map entry out to an even WORD boundary in size.
For Further Information

This page is taken from the Encyclopedia of Graphics File Formats and is licensed by O'Reilly under the Creative Common/Attribution license.

XWD

2007-02-18T02:07:04Z

Dcsmith77:

{|
Type | Bitmap ||
Colors | Unlimited ||
Compression | Uncompressed ||
Maximum Image Size | 64Kx64K ||
Multiple Images Per File | No ||
Numerical Format | Big- and little-endian ||
|}

XWD is used to store images of captured X window displays.

The XWD (X Window Dump) format is used specifically to store screen dumps created by the X Window System. Under X11, screen dumps are created by the xwd client. Using xwd, the window or background is selected to dump and an XWD file is produced containing an image of the window. If you issue the following command:

% xwd -root > output.xwd

the entire contents of the current display are saved to the file output.xwd. The id of the window to dump may also be specified by using the -id command-line flag on versions of xwd prior to Release 5.

Contents:
File Organization
For Further Information
File Organization

The first version of the X Window System to support window dumps was X10. Only gray-scale and color-mapped dumps were supported, and the bitmapped data was never compressed. The X10 version of XWD contains the following header:

typedef struct _X10WindowDump
{
LONG HeaderSize; /* Header size in bytes */
LONG FileVersion; /* X10 XWD file version (always 06h) */
LONG DisplayType; /* Display type */
LONG DisplayPlanes; /* Number of display planes */
LONG PixmapFormat; /* Pixmap format */
LONG PixmapWidth; /* Pixmap width */
LONG PixmapHeight; /* Pixmap height */
SHORT WindowWidth; /* Window width */
SHORT WindowHeight; /* Window height */
SHORT WindowX; /* Window upper left X coordinate */
SHORT WindowY; /* Window upper left Y coordinate */
SHORT WindowBorderWidth; /* Window border width */
SHORT WindowNumColors; /* Number of color entries in window */
} X10WINDOWDUMP;

HeaderSize is the size of the header in bytes. This value is always 40.

FileVersion contains the version number of the XWD file. This value is always 06h.

DisplayType is the type of the display from which the image was dumped.

DisplayPlanes is the number of color planes in the image data. This value is typically 01h or 03h.

PixmapFormat indicates the format of the bitmap. A value of 00h indicates a single-plane bitmap (XYFormat), and a value of 01h indicates a bitmap with two or more planes (ZFormat).

PixmapWidth and PixmapHeight represent the size of the image in pixels.

WindowWidth and WindowHeight represent the size of the window to display.

WindowX and WindowY represent the position of the window on the display.

WindowBorderWidth indicates the width of the window border in pixels.

WindowNumColors specifies the number of colors that can be displayed in the window.

If the image is a PseudoColor image, a color map immediately follows the header. The color map contains one entry per color in the image, and each entry has the following format:

typedef struct _X10ColorMap
{
WORD EntryNumber; /* Number of the color-map entry */
WORD Red; /* Red-channel value */
WORD Green; /* Green-channel value */
WORD Blue; /* Blue-channel value */
} X10COLORMAP[WindowNumColors];

EntryNumber is the number of the color-map entry. This value starts at 00h. Color maps typically do not exceed 256 entries in size.

Red, Green, and Blue are the RGB channel values for this entry. The range of each of these values is typically 0 to 65535; often, only the high byte of the value is set (i.e., the value is 0-255 shifted left eight bits.)

The XWD format was revised for Version 11 of the X Window System. The new format can store more types of image data and many fields have been added to the header and to the color map, reflecting the increased graphics capabilities of X11 over X10.

The Version 11 XWD file format contains the following header:

typedef struct _X11WindowDump
{
DWORD HeaderSize; /* Size of the header in bytes */
DWORD FileVersion; /* X11WD file version (always 07h) */
DWORD PixmapFormat; /* Pixmap format */
DWORD PixmapDepth; /* Pixmap depth in pixels */
DWORD PixmapWidth; /* Pixmap width in pixels */ /
DWORD PixmapHeight; /* Pixmap height in pixels */
DWORD XOffset; /* Bitmap X offset */
DWORD ByteOrder; /* Byte order of image data */
DWORD BitmapUnit; /* Bitmap base data size */
DWORD BitmapBitOrder; /* Bit-order of image data */
DWORD BitmapPad; /* Bitmap scan-line pad*/
DWORD BitsPerPixel; /* Bits per pixel */
DWORD BytesPerLine; /* Bytes per scan-line */
DWORD VisualClass; /* Class of the image */
DWORD RedMask; /* Red mask */
DWORD GreenMask; /* Green mask */
DWORD BlueMask; /* Blue mask */
DWORD BitsPerRgb; /* Size of each color mask in bits */
DWORD NumberOfColors; /* Number of colors in image */
DWORD ColorMapEntries; /* Number of entries in color map */
DWORD WindowWidth; /* Window width */
DWORD WindowHeight; /* Window height */
LONG WindowX; /* Window upper left X coordinate */
LONG WindowY; /* Window upper left Y coordinate */
DWORD WindowBorderWidth; /* Window border width */
} X11WINDOWDUMP;

HeaderSize is the size of the header in bytes. This value is always 40.

FileVersion contains the version number of the XWD file. This value is always 07h.

PixmapFormat is the format of the image data. A value of 00h indicates a 1-bit (XYBitmap) format. A value of 01h indicates a single-plane bitmap (XYPixmap). A value of 02h indicates a bitmap with two or more planes (ZPixmap).

PixmapDepth is the depth of the bitmap in pixels. This value is 1 to 32.

PixmapWidth and PixmapHeight represent the size of the image in pixels.

XOffset specifies the number of pixels to ignore at the beginning of each scan-line.

ByteOrder indicates the byte order of the image data. Values for this field are 00h for least significant byte first, and 0 for most significant byte first.

BitmapUnit is the size of each data unit in each scan line. This value may be 8, 16, or 32.

BitmapBitOrder indicates the order of the bits within each byte of image data. Values for this field are 00h for least significant byte first, and 0 for most significant byte first.

BitmapPad is the number of bits of padding added to each scan line. This value may be 8, 16, or 32.

BitsPerPixel contains the size of each pixel in bits. For StaticGray and GrayScale images, this value is 1. For StaticColor and PseudoColor images, this value is 2 to 15 (typically 8). For TrueColor and DirectColor images, this value is 16, 24, or 32.

BytesPerLine is the size of each scan line in bytes.

VisualClass indicates the format of the image data:

* Even-numbered values indicate fixed-image data that cannot be changed in memory.

* Odd-numbered values indicate dynamic image data that may be altered.

* The values 00h (StaticGray) and 01h (GrayScale) specify a gray-scale image.

* The values 02h (StaticColor) and 03h (PseudoColor) indicate a color mapped image.

* The values 04h (TrueColor) and 05h (DirectColor) indicate true-color image data.

RedMask, GreenMask, and BlueMask are the RGB mask values used by ZPixmaps.

BitsPerRgb is the size of each RedMask, GreenMask, and BlueMask in bits.

NumberOfColors specifies the number of colors in the image. This value also indicates the number of colors for colormapped images as well.

ColorMapEntries contains the number of entries in the color map. This value is 00h if there is no color map.

WindowWidth and WindowHeight are the size of the window to display.

WindowX and WindowY contain the position of the window on the display.

WindowBorderWidth is the width of the X Window border in pixels. If the border has not been captured in the dump, this value is 00h.

The color map immediately follows the header. Each entry in the color map is 12 bytes in size and has the following format:

typedef struct _X11ColorMap
{
DWORD EntryNumber; /* Number of the color map entry */
WORD Red; /* Red-channel value */
WORD Green; /* Green-channel value */
WORD Blue; /* Blue-channel value */
CHAR Flags; /* Flag for this entry */
CHAR Padding; /* WORD-align padding */
} X11COLORMAP[ColorMapEntries];

EntryNumber is the number of the color map entry. This value starts at 00h. Color maps typically do not exceed 256 entries in size.

Red, Green, and Blue are the RGB channel values for this entry. The range of each of these values is typically 0 to 65535; often, only the high byte of the value is set (i.e., the value is 0-255 shifted left eight bits.)

Flags indicates which of the color channels in the color map are actually used. The value of this field is typically 07h, indicating that all three channels are used.

Padding is a byte set to a value of 00h and used to pad the color map entry out to an even WORD boundary in size.
For Further Information

This page is taken from the Encyclopedia of Graphics File Formats and is licensed by O'Reilly under the Creative Common/Attribution license.

XBM

2007-02-18T02:00:00Z

Dcsmith77:

Type Bitmap
Colors Mono
Compression None
Maximum Image Size Unlimited
Multiple Images Per File Yes
Numerical Format ASCII
Originator X Consortium
Platform Any supporting X Window System
Supporting Applications BRL-CAD
See Also XPM

Usage
Primarily used for the storage of cursor and icon bitmaps for use in the X graphical user interface.

Comments
XBM is a monochrome bitmap format in which data is stored as a C language data array.

Code fragments are available for this format.

Sample images are available for this format.

Normally, we think of images as data being stored as binary information in a file. In many cases, however, it is more convenient to represent smaller bitmapped images as collections of ASCII data rather than binary data. If such a small bitmapped image is being used by a software application, such as the cursors and icons found in all graphical user interfaces, the images may be stored as an array of ASCII characters, or even as an array of data values stored in the actual software source code.

Contents:
File Organization
File Details
For Further Information

Storing small amounts of image data directly as C language source code is the philosophy behind the XBM (X BitMap) format. Small images that will be compiled into a software program are stored as simple arrays of data values, with one array used per stored image. XBM files are therefore nothing more than C language source files that are read by a compiler, rather than by a graphical display program or bitmap editor, as are most other graphical files.

XBM bitmap data is mostly found in C source header files (with a .h file extension) and in separate XBM bitmap files (with no file extension). Multiple XBM image-data arrays may be stored in a single file, but none of the images may have the same name, or a naming conflict will result.

The XPM (X PixMap) format is similar to XBM. XPM is a cousin of XBM and is capable of storing color bitmap image data and a colormap. XPM is also an ASCII format and is described in the XPM article.
File Organization

XBM files have a height and width, and may define an optional hotspot within the image. The hotspot is used for bitmapped cursors and indicates the absolute position of the cursor on the screen. The hotspot on an arrow cursor is the tip of the arrow, which is usually located at position 0,0 in the bitmap.

In place of the usual image file format header, XBM files have two or four #define statements. The first two #defines specify the height and width of the bitmap in pixels. The second two specify the position of the hotspot within the bitmap, and are not present if no hotspot is defined in the image.

The labels of each #define contain the name of the image. Consider an image that is 8x8 pixels in size, named FOO, with a hotspot at pixel 0,7. This image contains the following #define statements:

#define FOO_width 8
#define FOO_height 8
#define FOO_x_hot 0
#define FOO_y_hot 7

The image data itself is a single line of pixel values stored in a static array. Data representing our FOO image appears as follows:

static unsigned char FOO_bits[] = {
0x3E, 0x80, 0x00, 0x7C, 0x00, 0x82, 0x41, 0x00};

Because each pixel is only one bit in size, each byte in the array contains the information for eight pixels, with the first pixel in the bitmap (at position 0,0) represented by the high bit of the first byte in the array. If the image width is not a multiple of eight, the extra bits in the last byte of each row are not used and are ignored.

XBM files are found in two variations: the older X10 format and the newer (as of 1986) X11 format. The only difference between these formats is how the pixel data is packed. The X11 flavor stores pixel data as 8-bit BYTEs. The older X10 flavor stores pixel data as 16-bit WORDs. There are no markers separating the rows of image data in either of these formats, and the size of an XBM array is limited only by the compiler and machine using the bitmap.

The X10 XBM is considered obsolete. Make sure that any X software you write is able to read both the XBM X10 and X11 formats, but when you write data, use only the X11 XBM format.
File Details

Following is an example of a 16x16 XBM bitmap stored using both its X10 and X11 variations. Note that each array contains exactly the same data, but is stored using different data word types:

/* XBM X10 format */
#define xlogo16_width 16
#define xlogo16_height 16
static unsigned short xlogo16_bits[] = {
0x0f80, 0x1e80, 0x3c40, 0x7820, 0x7810, 0xf008, 0xe009, 0xc005,
0xc002, 0x4007, 0x200f, 0x201e, 0x101e, 0x083c, 0x0478,
0x02f0};
/* XBM X11 format */
#define xlogo16_width 16
#define xlogo16_height 16
static unsigned char xlogo16_bits[] = {
0x0f, 0x80, 0x1e, 0x80, 0x3c, 0x40, 0x78, 0x20, 0x78, 0x10,
0xf0, 0x08, 0xe0, 0x09, 0xc0, 0x05, 0xc0, 0x02, 0x40, 0x07,
0x20, 0x0f, 0x20, 0x1e, 0x10, 0x1e, 0x08, 0x3c, 0x04, 0x78,
0x02, 0xf0};

For Further Information

For further information about the XBM format, see the code examples included on the CD-ROM.

The XBM format is part of the X Window System created by the X Consortium. The X11 source code distribution contains many XBM files (in the /bitmaps directory) and C language source code functions (such as XCreateBitmapFromData, XCreatePixmapFromBitmapData, XReadBitmapFile, and XWriteBitmapFile), which operate upon XBM data. The central FTP site for X11 distribution is:

ftp://ftp.x.org/

Other references containing information on XBM include the following:

Gettys, James, and Robert W. Scheiffler, X Window System, Digital Press, 1992.

Gettys, James, Robert W. Scheiffler, et al. Xlib-C language X Interface, X Consortium Standard, X Version 11, Release 5, First Revision, August 1991.

Nye, Adrian, Xlib Programming Manual, third edition, O'Reilly & Associates, Inc., Sebastopol, CA, 1992.

This page is taken from the Encyclopedia of Graphics File Formats and is licensed by O'Reilly under the Creative Common/Attribution license.

XWD

2007-02-18T01:47:48Z

Dcsmith77:

Type Bitmap
Colors Unlimited
Compression Uncompressed
Maximum Image Size 64Kx64K
Multiple Images Per File No
Numerical Format Big- and little-endian
Originator X Consortium
Platform UNIX X Windows
Supporting Applications Many
See Also None

Usage
XWD is used to store images of captured X window displays.

Comments
Many image-processing and display applications and toolkits read and write XWD format image files.

Vendor specifications are available for this format.

Code fragments are available for this format.

Sample images are available for this format.

The XWD (X Window Dump) format is used specifically to store screen dumps created by the X Window System. Under X11, screen dumps are created by the xwd client. Using xwd, the window or background is selected to dump and an XWD file is produced containing an image of the window. If you issue the following command:

% xwd -root > output.xwd

the entire contents of the current display are saved to the file output.xwd. The id of the window to dump may also be specified by using the -id command-line flag on versions of xwd prior to Release 5.

Contents:
File Organization
For Further Information
File Organization

The first version of the X Window System to support window dumps was X10. Only gray-scale and color-mapped dumps were supported, and the bitmapped data was never compressed. The X10 version of XWD contains the following header:

typedef struct _X10WindowDump
{
LONG HeaderSize; /* Header size in bytes */
LONG FileVersion; /* X10 XWD file version (always 06h) */
LONG DisplayType; /* Display type */
LONG DisplayPlanes; /* Number of display planes */
LONG PixmapFormat; /* Pixmap format */
LONG PixmapWidth; /* Pixmap width */
LONG PixmapHeight; /* Pixmap height */
SHORT WindowWidth; /* Window width */
SHORT WindowHeight; /* Window height */
SHORT WindowX; /* Window upper left X coordinate */
SHORT WindowY; /* Window upper left Y coordinate */
SHORT WindowBorderWidth; /* Window border width */
SHORT WindowNumColors; /* Number of color entries in window */
} X10WINDOWDUMP;

HeaderSize is the size of the header in bytes. This value is always 40.

FileVersion contains the version number of the XWD file. This value is always 06h.

DisplayType is the type of the display from which the image was dumped.

DisplayPlanes is the number of color planes in the image data. This value is typically 01h or 03h.

PixmapFormat indicates the format of the bitmap. A value of 00h indicates a single-plane bitmap (XYFormat), and a value of 01h indicates a bitmap with two or more planes (ZFormat).

PixmapWidth and PixmapHeight represent the size of the image in pixels.

WindowWidth and WindowHeight represent the size of the window to display.

WindowX and WindowY represent the position of the window on the display.

WindowBorderWidth indicates the width of the window border in pixels.

WindowNumColors specifies the number of colors that can be displayed in the window.

If the image is a PseudoColor image, a color map immediately follows the header. The color map contains one entry per color in the image, and each entry has the following format:

typedef struct _X10ColorMap
{
WORD EntryNumber; /* Number of the color-map entry */
WORD Red; /* Red-channel value */
WORD Green; /* Green-channel value */
WORD Blue; /* Blue-channel value */
} X10COLORMAP[WindowNumColors];

EntryNumber is the number of the color-map entry. This value starts at 00h. Color maps typically do not exceed 256 entries in size.

Red, Green, and Blue are the RGB channel values for this entry. The range of each of these values is typically 0 to 65535; often, only the high byte of the value is set (i.e., the value is 0-255 shifted left eight bits.)

The XWD format was revised for Version 11 of the X Window System. The new format can store more types of image data and many fields have been added to the header and to the color map, reflecting the increased graphics capabilities of X11 over X10.

The Version 11 XWD file format contains the following header:

typedef struct _X11WindowDump
{
DWORD HeaderSize; /* Size of the header in bytes */
DWORD FileVersion; /* X11WD file version (always 07h) */
DWORD PixmapFormat; /* Pixmap format */
DWORD PixmapDepth; /* Pixmap depth in pixels */
DWORD PixmapWidth; /* Pixmap width in pixels */ /
DWORD PixmapHeight; /* Pixmap height in pixels */
DWORD XOffset; /* Bitmap X offset */
DWORD ByteOrder; /* Byte order of image data */
DWORD BitmapUnit; /* Bitmap base data size */
DWORD BitmapBitOrder; /* Bit-order of image data */
DWORD BitmapPad; /* Bitmap scan-line pad*/
DWORD BitsPerPixel; /* Bits per pixel */
DWORD BytesPerLine; /* Bytes per scan-line */
DWORD VisualClass; /* Class of the image */
DWORD RedMask; /* Red mask */
DWORD GreenMask; /* Green mask */
DWORD BlueMask; /* Blue mask */
DWORD BitsPerRgb; /* Size of each color mask in bits */
DWORD NumberOfColors; /* Number of colors in image */
DWORD ColorMapEntries; /* Number of entries in color map */
DWORD WindowWidth; /* Window width */
DWORD WindowHeight; /* Window height */
LONG WindowX; /* Window upper left X coordinate */
LONG WindowY; /* Window upper left Y coordinate */
DWORD WindowBorderWidth; /* Window border width */
} X11WINDOWDUMP;

HeaderSize is the size of the header in bytes. This value is always 40.

FileVersion contains the version number of the XWD file. This value is always 07h.

PixmapFormat is the format of the image data. A value of 00h indicates a 1-bit (XYBitmap) format. A value of 01h indicates a single-plane bitmap (XYPixmap). A value of 02h indicates a bitmap with two or more planes (ZPixmap).

PixmapDepth is the depth of the bitmap in pixels. This value is 1 to 32.

PixmapWidth and PixmapHeight represent the size of the image in pixels.

XOffset specifies the number of pixels to ignore at the beginning of each scan-line.

ByteOrder indicates the byte order of the image data. Values for this field are 00h for least significant byte first, and 0 for most significant byte first.

BitmapUnit is the size of each data unit in each scan line. This value may be 8, 16, or 32.

BitmapBitOrder indicates the order of the bits within each byte of image data. Values for this field are 00h for least significant byte first, and 0 for most significant byte first.

BitmapPad is the number of bits of padding added to each scan line. This value may be 8, 16, or 32.

BitsPerPixel contains the size of each pixel in bits. For StaticGray and GrayScale images, this value is 1. For StaticColor and PseudoColor images, this value is 2 to 15 (typically 8). For TrueColor and DirectColor images, this value is 16, 24, or 32.

BytesPerLine is the size of each scan line in bytes.

VisualClass indicates the format of the image data:

* Even-numbered values indicate fixed-image data that cannot be changed in memory.

* Odd-numbered values indicate dynamic image data that may be altered.

* The values 00h (StaticGray) and 01h (GrayScale) specify a gray-scale image.

* The values 02h (StaticColor) and 03h (PseudoColor) indicate a color mapped image.

* The values 04h (TrueColor) and 05h (DirectColor) indicate true-color image data.

RedMask, GreenMask, and BlueMask are the RGB mask values used by ZPixmaps.

BitsPerRgb is the size of each RedMask, GreenMask, and BlueMask in bits.

NumberOfColors specifies the number of colors in the image. This value also indicates the number of colors for colormapped images as well.

ColorMapEntries contains the number of entries in the color map. This value is 00h if there is no color map.

WindowWidth and WindowHeight are the size of the window to display.

WindowX and WindowY contain the position of the window on the display.

WindowBorderWidth is the width of the X Window border in pixels. If the border has not been captured in the dump, this value is 00h.

The color map immediately follows the header. Each entry in the color map is 12 bytes in size and has the following format:

typedef struct _X11ColorMap
{
DWORD EntryNumber; /* Number of the color map entry */
WORD Red; /* Red-channel value */
WORD Green; /* Green-channel value */
WORD Blue; /* Blue-channel value */
CHAR Flags; /* Flag for this entry */
CHAR Padding; /* WORD-align padding */
} X11COLORMAP[ColorMapEntries];

EntryNumber is the number of the color map entry. This value starts at 00h. Color maps typically do not exceed 256 entries in size.

Red, Green, and Blue are the RGB channel values for this entry. The range of each of these values is typically 0 to 65535; often, only the high byte of the value is set (i.e., the value is 0-255 shifted left eight bits.)

Flags indicates which of the color channels in the color map are actually used. The value of this field is typically 07h, indicating that all three channels are used.

Padding is a byte set to a value of 00h and used to pad the color map entry out to an even WORD boundary in size.
For Further Information

For further information about the XWD format, see the documentation included on the CD-ROM.

The XWD format is part of the X Window System created by the X Consortium. Information about the XWD format, and, indeed, all of the file formats associated with the X Window System, is scattered over a wide variety of header files (in /usr/include/X11) and UNIX manual pages.

The central FTP distribution site for X11 is:

ftp://ftp.x.org/

Many image-processing and display applications and toolkits included on the CD-ROM (e.g., FBM, ImageMagick, pbmplus, xli, xloadimage, and xvread) and write XWD-format image files, and documentation for those tools may contain additional information about XWD.

This page is taken from the Encyclopedia of Graphics File Formats and is licensed by O'Reilly under the Creative Common/Attribution license.

XPM

2007-02-18T01:32:06Z

Dcsmith77:

XPM

2007-02-18T01:31:36Z

Dcsmith77: /* Styles */

{{Infobox file format
| name = X PixMap
| extension = <tt>.xpm</tt>
| mime = image/x-xpixmap </code>'''unofficial''' <code>image/x-xpm </code>'''unofficial'''<code>
| owner = BULL Research
| creatorcode =
| genre = [[Image file formats]]
| containerfor =
| containedby =
| extendedfrom = [[XBM]] and [[Portable pixmap]]
| extendedto =
}}
'''XPM''' (''X PixMap'') is an ASCII image format used by the X Window System. It was created in 1989 by Daniel Dardailler and Colas Nahaboo working at the INRIA, France, and was later enhanced by Arnaud Le Hors. It is intended primarily for creating icon pixmaps, and supports transparent color. It has a simple structure, deriving from the earlier [[XBM]] syntax.

Three styles are known, the simple XPM2:
:<tt>! XPM2</tt>
:<tt>128 128 64 1</tt>
:<tt>z c #f6f6f6</tt>
:<tt>Z c #eeeeee</tt>
:''etc., palette using '''1''' character codes''
:<tt>@ c #080808</tt>
:<tt>. c #000000</tt>
:<tt>............................................</tt>
:''truncated first row, each dot is a pixel with colour <tt>#000000</tt> as defined above.''

This is about an XPM2 image with width 128, height 128, 64 colours, using one character per pixel.
One tool is known to use only '''a''' to '''p''' for 16 colours, switching to '''aa''' up to '''dp''' for 64 colours,
but still reading single character encodings for 64 colours, compare [[Base64]].

With more colours the codes use more characters, e.g. '''aa''' up to '''pp''' for 16*16=256 colours. This is less useful
for text editors, because a string '''ab''' could be actually the middle of two adjacent pixels '''dabc'''. Spaces are
allowed as colour code, see [[#External links|links]], but might be a bad idea depending on the used text editor. Without
control codes, space, and quote (needed in XPM1 and XPM3) 128-33-2=93 [[ASCII]] characters are available for single character
colour codes.

It's helpful if the converter from other formats to XPM can sort the palette from white to black, because one of the
reasons to edit an icon might be to get rid of antialiasing artefacts after a reduction of the number colours, adding
affected pixels to <tt>#000000</tt> or <tt>#ffffff</tt> acting as transparency colour (the dots in the example).

For XPM2 it's clear how many lines belong to the image, two header lines, the second header line announcing the number of
colour codes (64 lines in the example above) and rows (height 128 in the example above), e.g. 2+64+128=194 lines.

The other styles are designed to be used as is in C sources, example:

:<tt>#define XFACE_format 1</tt>
:<tt>#define XFACE_width 48</tt>
:<tt>#define XFACE_height 48</tt>
:<tt>#define XFACE_ncolors 2</tt>
:<tt>#define XFACE_chars_per_pixel 1</tt>
:<tt>static char *XFACE_colors[] = {</tt>
:<tt>"a", "#ffffff",</tt>
:<tt>"b", "#000000"</tt>
:<tt>};</tt>
:<tt>static char *XFACE_pixels[] = {</tt>
:<tt>"abaabaababaaabaabababaabaabaababaabaaababaabaaab",</tt>
:''etc., 48 rows with 48 pixels''.

This is a black and white image in the first (1989) XPM format.
The source icon was in [[PNG]] format, and although it defined <tt>#ffffff</tt> as
transparent, this detail was lost in the conversion. The
hex. RGB <tt>#123456</tt> codes can be also replaced by known
colour names found in a "well known location" <tt>rgb.txt</tt>,
where "well known location" depends on the operating
system and the used tools. The XPM "colour" name for transparency is '''none'''.

Just for the records the same image in the other styles:

:<tt>! XPM2</tt>
:<tt>48 48 2 1</tt>
:<tt>a c #ffffff</tt>
:<tt>b c #000000</tt>
:<tt>abaabaababaaabaabababaabaabaababaabaaababaabaaab</tt>
:''etc.''

:<tt> /* XPM */</tt>
:<tt> static char * XFACE[] = {</tt>
:<tt> "48 48 2 1",</tt>
:<tt> "a c #ffffff",</tt>
:<tt> "b c #000000",</tt>
:<tt> "abaabaababaaabaabababaabaabaababaabaaababaabaaab",</tt>
:''etc.''

The latter format is XPM3, the common format used
for the X Window System since about 1991. The '''c'''
means "colour", it's possible to add '''m''' for
"monochrome" output, '''g''' for "grayscale", and '''s''' for "symbolic",
explaining what a defined colour is supposed to do.

The "symbolic" feature allows to adjust colours
depending on the context where they are used, like
say <tt>s border c blue</tt> could be adjusted on
a blue background.

If the width, height, colours, and characters per
pixel line contains six instead of four numbers the
additional values indicate the coordinates of a
"hotspot", '''0 0''' is the upper left corner
of a box containing the icon and the default. A
"hotspot" is used for mouse pointers and similar
applications.

XPM

2007-02-18T01:27:39Z

Dcsmith77:

== Styles ==
Three styles are known, the simple XPM2 stripped all [[C (programming language)|C]] idiosyncrasies, example:

:<tt>! XPM2</tt>
:<tt>128 128 64 1</tt>
:<tt>z c #f6f6f6</tt>
:<tt>Z c #eeeeee</tt>
:''etc., palette using '''1''' character codes''
:<tt>@ c #080808</tt>
:<tt>. c #000000</tt>
:<tt>............................................</tt>
:''truncated first row, each dot is a pixel with colour <tt>#000000</tt> as defined above.''

This is about an XPM2 image with width 128, height 128, 64 colours, using one character per pixel.
One tool is known to use only '''a''' to '''p''' for 16 colours, switching to '''aa''' up to '''dp''' for 64 colours,
but still reading single character encodings for 64 colours, compare [[Base64]].

With more colours the codes use more characters, e.g. '''aa''' up to '''pp''' for 16*16=256 colours. This is less useful
for text editors, because a string '''ab''' could be actually the middle of two adjacent pixels '''dabc'''. Spaces are
allowed as colour code, see [[#External links|links]], but might be a bad idea depending on the used text editor. Without
control codes, space, and quote (needed in XPM1 and XPM3) 128-33-2=93 [[ASCII]] characters are available for single character
colour codes.

It's helpful if the converter from other formats to XPM can sort the palette from white to black, because one of the
reasons to edit an icon might be to get rid of antialiasing artefacts after a reduction of the number colours, adding
affected pixels to <tt>#000000</tt> or <tt>#ffffff</tt> acting as transparency colour (the dots in the example).

For XPM2 it's clear how many lines belong to the image, two header lines, the second header line announcing the number of
colour codes (64 lines in the example above) and rows (height 128 in the example above), e.g. 2+64+128=194 lines.

The other styles are designed to be used as is in C sources, example:

:<tt>#define XFACE_format 1</tt>
:<tt>#define XFACE_width 48</tt>
:<tt>#define XFACE_height 48</tt>
:<tt>#define XFACE_ncolors 2</tt>
:<tt>#define XFACE_chars_per_pixel 1</tt>
:<tt>static char *XFACE_colors[] = {</tt>
:<tt>"a", "#ffffff",</tt>
:<tt>"b", "#000000"</tt>
:<tt>};</tt>
:<tt>static char *XFACE_pixels[] = {</tt>
:<tt>"abaabaababaaabaabababaabaabaababaabaaababaabaaab",</tt>
:''etc., 48 rows with 48 pixels''.

This is a black and white image in the first (1989) XPM format.
The source icon was in [[PNG]] format, and although it defined <tt>#ffffff</tt> as
transparent, this detail was lost in the conversion. The
hex. RGB <tt>#123456</tt> codes can be also replaced by known
colour names found in a "well known location" <tt>rgb.txt</tt>,
where "well known location" depends on the operating
system and the used tools. The XPM "colour" name for transparency is '''none'''.

Just for the records the same image in the other styles:

:<tt>! XPM2</tt>
:<tt>48 48 2 1</tt>
:<tt>a c #ffffff</tt>
:<tt>b c #000000</tt>
:<tt>abaabaababaaabaabababaabaabaababaabaaababaabaaab</tt>
:''etc.''

:<tt> /* XPM */</tt>
:<tt> static char * XFACE[] = {</tt>
:<tt> "48 48 2 1",</tt>
:<tt> "a c #ffffff",</tt>
:<tt> "b c #000000",</tt>
:<tt> "abaabaababaaabaabababaabaabaababaabaaababaabaaab",</tt>
:''etc.''

The latter format is XPM3, the common format used
for the X Window System since about 1991. The '''c'''
means "colour", it's possible to add '''m''' for
"monochrome" output, '''g''' for "grayscale", and '''s''' for "symbolic",
explaining what a defined colour is supposed to do.

The "symbolic" feature allows to adjust colours
depending on the context where they are used, like
say <tt>s border c blue</tt> could be adjusted on
a blue background.

If the width, height, colours, and characters per
pixel line contains six instead of four numbers the
additional values indicate the coordinates of a
"hotspot", '''0 0''' is the upper left corner
of a box containing the icon and the default. A
"hotspot" is used for mouse pointers and similar
applications.

=== Comparison with XBM ===
Here's the same [[:image:Blarg.xbm.gif|image]] as shown on [[XBM]] in both formats,
the examples are complete images <tt>Blarg.xbm</tt> and <tt>Blarg.xpm</tt>:
#define blarg_xbm_width 16
#define blarg_xbm_height 7
static char blarg_xbm_bits[] = {
0xec, 0xff, 0xea, 0xff, 0x6c, 0x32, 0xaa,
0x5a, 0x6c, 0x3a, 0xff, 0x7f, 0xff, 0x9f};
Above is the XBM (183 bytes text), below the XPM2 (170 bytes), for 16*7 black and white pixels.
! XPM2
16 7 2 1
* c #ffffff
. c #000000
**..*...........
*.*.*...........
**..*..**.**..**
*.*.*.*.*.*..*.*
**..*..**.*...**
...............*
.............**.

JPEG

2006-10-23T03:11:22Z

Dcsmith77:

* FourCCs: JPEG, CJPG
* Organization: [[ISO/IEC JTC1/SC29/WG1]] "Joint Photographic Experts Group" (JPEG)
* Organization: [[Independent JPEG Group]]
* Samples:
** CJPG: http://samples.mplayerhq.hu/V-codecs/CJPG/

JPEG is a ubiquitous lossy or lossless image format.

[[Category:Video Codecs]]
[[Category:Video FourCCs]]

[[Category:Image Formats]]

TIFF

2006-10-20T23:26:37Z

Dcsmith77: Initial Copy from wikipedia

== Flexible options ==
TIFF is a flexible and adaptable file format. It can handle multiple images and data in a single file through the inclusion of "tags" in the file header. Tags can indicate the basic geometry of the image, such as its size, or define how the image data is arranged and whether various image compression options are used. For example, TIFF can be used as a container for JPEG and RLE (run-length encoding) compressed images. A TIFF file can also include a vector-based clipping path (an outline that crops or frames the main image). The ability to store image data in a lossless format makes TIFF files a useful method for archiving images. Unlike standard JPEG, TIFF files can be edited and resaved without suffering a compression loss. Other TIFF file options include multiple layers or pages.

Although it is a widely accepted standard format today, when TIFF was first introduced, its extensibility led to compatibility problems. Programmers were free to specify new tags and options, but not all programs implemented support for all the tags that had been created. As a result the lowest common denominator soon became "the" TIFF, and even today the vast majority of TIFF files, and the code that reads them, are based on a simple 32-bit uncompressed image.

TIFF does have an option to use LZW compression, a lossless data compression technique for reducing file size.

Every TIFF file begins with a 2-byte indicator of byte order: "II" for little endian and "MM" for big endian byte ordering. The following 2 bytes represent the number 42. The number 42 was selected "for its deep philosophical significance." The reading of 42 is dependent on the byte order indicated in the first 2 bytes. The entire file is read based on the indicated byte order.

Byte order can cause compatibility issues between Apple Macintosh and Windows programs, which typically use different byte order for TIFF files. Some programs offer the option of saving in Mac or Windows byte order so files can be used across platforms.
== TIFF in document imaging ==
TIFF format is standard in document imaging and document management systems. In this environment it is normally used with CCITT Group IV 2D compression, which supports black-and-white (also called bitonal or monochrome) images. In high-volume environments, documents are typically scanned in black and white (rather than color or grayscale) to conserve storage capacity. An average A4 scan produces 30 kilobytes (KB) of data at 200 dpi (dots per inch resolution) and 50 KB of data at 300 dpi. 300 dpi is far more common than 200 dpi.

Because TIFF format supports multiple pages, multi-page documents can be saved as single TIFF files rather than as a series of files for each scanned page.

Portable Network Graphics

2006-10-20T23:20:32Z

Dcsmith77: Initial submit copied from wikipedia

===File header===
A PNG file starts with an 8-byte signature. The hexadecimal byte values are 89 50 4E 47 0D 0A 1A 0A. Each of the header bytes is there for a specific reason [http://www.libpng.org/pub/png/spec/1.1/PNG-Rationale.html#R.PNG-file-signature]:
{|class=wikitable
!|Byte(s)
!style="text-align:left"|Purpose
|-
|89
|Has the high bit set to detect transmission systems that do not support 8 bit data and to reduce the chance that a text file is mistakenly interpreted as a PNG, or visa versa.
|-
|50 4E 47
|In ASCII, the letters "'''PNG'''", allowing a person to identify the format easily if it is viewed in a text editor.
|-
|0D 0A
|A DOS style newline (CRLF) to detect DOS-UNIX line ending conversion of the data.
|-
|1A
|A byte that stops display of the file under DOS when the command TYPE has been used
|-
|0A
|A unix newline (LF) to detect UNIX-DOS line ending conversion.
|}
==="Chunks" within the file===
After the header come a series of chunks each of which conveys certain information about the image. Chunks declare themselves as ''critical'' or ''ancillary'', and a program encountering an ancillary chunk that it does not understand can safely ignore it. This chunk-based structure is designed to allow the PNG format to be extended while maintaining compatibility with older versions.

The chunks each have a header specifying their size and type. This is immediately followed by the actual data, and then the checksum of the data. Chunks are given a 4 letter case sensitive name. The case of the different letters in the name provides the decoder with some information on the nature of chunks it does not recognise.

The case of the first letter indicates if the Chunk is essential or not. If the first letter is uppercase, the chunk is essential. If not, the chunk is ancillary. Essential chunks contain information that is necessary to read the file. If a decoder encounters an essential chunk it does not recognise, it must abort reading the file.

The case of the second letter indicates if the chunk is "public" (either in the specification or the registry of special purpose public chunks) or "private" (not standardised). Uppercase is public and lowercase is private. This ensures that public and private chunk names can never conflict with each other.

The third letter must be uppercase to conform to the PNG specification. It is reserved for future expansion.

The case of the fourth letter indicates if a chunk is safe to copy by editors that do not recognise it. If lowercase the chunk may be safely copied regardless of the extent of modifications to the file. If uppercase it may only be copied if the modifications have not touched any critical chunks.
====Essential chunks====
A decoder must be able to interpret these to read and render a PNG file.
* IHDR must be the first chunk, it contains the header.
* PLTE contains the palette; list of colors.
* IDAT contains the image, which may be split among multiple IDAT chunks. Doing so increases filesize slightly, but makes it possible to generate a PNG in a streaming manner.
* IEND marks the image end.

====Metadata chunks====
Other image attributes that can be stored in PNG files include gamma values, background color, and textual metadata information. PNG also supports color management through the inclusion of ICC color space profiles.
* bKGD gives the default background color. It is intended for use when there is no better choice available, such as in standalone image viewers (but not web browsers).
* cHRM gives the white balance.
* gAMA specifies gamma.
* hIST can store the histogram, or total amount of each color in the image.
* iCCP is an ICC color profile.
* iTXt contains international (UTF-8) text, compressed or not.
* pHYs holds the intended pixel size and/or aspect ratio of the image.
* sBIT (significant bits) indicates the color-accuracy of the source data.
* sPLT suggests a palette to use if the full range of colors is unavailable.
* sRGB indicates that the standard sRGB color space is used.
* tEXt can store text that can be represented in ISO 8859-1, with one name=value pair for each chunk.
* tIME stores the time that the image was last changed.
* tRNS contains transparency information. For indexed images, it stores alpha channel values for one or more palette entries. For truecolor and greyscale images, it stores a single pixel value that is to be regarded as fully transparent.
* zTXt contains compressed text with the same limits as tEXt.

The lowercase first letter in these chunks indicates that they are not needed for the PNG specification. The lowercase last letter in some chunks indicates that they are safe to copy, even if the application concerned does not understand them.
===Colour depth===
PNG images can either use palette-indexed color or be made up of one or more channels (numerical values directly representing quantities about the pixels). When there is more than one channel in an image all channels have the same number of bits allocated per pixel (known as the bitdepth of the channel). Although the PNG specification always talks about the bitdepth of channels, most software and users generally talk about the total number of bits per pixel (sometimes also referred to as bitdepth or color depth).

The number of channels will depend on whether the image is greyscale or color and whether it has an alpha channel. PNG allows the following combinations of channels:
* greyscale
* greyscale and alpha (level of transparency for each pixel)
* red, green and blue (rgb/truecolor)
* red, green, blue and alpha

{| class="wikitable" style="margin: 1em auto 1em auto"
|+ PNG color options
!rowspan="2"|Type
!colspan="5"|Bit depth per channel
|-
!1
!2
!4
!8
!16
|-
|indexed (color type 3)
|{{yes}}
|{{yes}}
|{{yes}}
|{{yes}}
|{{no}}
|-
|greyscale (color type 0)
|{{yes}}
|{{yes}}
|{{yes}}
|{{yes}}
|{{yes}}
|-
|greyscale & alpha (color type 4)
|{{no}}
|{{no}}
|{{no}}
|{{yes}}
|{{yes}}
|-
|truecolor (RGB - color type 2)
|{{no}}
|{{no}}
|{{no}}
|{{yes}}
|{{yes}}
|-
|truecolor & alpha (RGBA - color type 6)
|{{no}}
|{{no}}
|{{no}}
|{{yes}}
|{{yes}}
|}

With indexed color images, the palette is always stored at a depth of 8 bits per channel. The palette must not have more entries than the image bitdepth allows for but it may have fewer (so if an image for example only uses 90 colors there is no need to have palette entries for all 256).

Indexed color PNGs are allowed to have 1, 2, 4 or 8 bits per pixel by the standard; greyscale images with no alpha channel allow for 1, 2, 4, 8 or 16 bits per pixel. Everything else uses a bitdepth per channel of either 8 or 16. The combinations this allows are given in the table above. The standard requires that decoders can read all supported color formats but many image editors can only produce a small subset of them.
===Transparency of image===
PNG offers a variety of transparency options. With truecolor and greyscale images either a single pixel value can be declared as transparent or an alpha channel can be added. For paletted images, alpha values can be added to palette entries. The number of such values stored may be less than the total number of palette entries, in which case the remaining entries are considered fully opaque.

The scanning of pixel values for binary transparency is supposed to be performed before any color reduction to avoid pixels becoming unintentionally transparent. This is most likely to pose an issue for systems that can decode 16 bits per channel images (as they must to be compliant with the specification) but only output at 8 bits per channel (the norm for all but the highest end systems).
===Compression===
PNG uses a non-patented lossless data compression method known as deflation. This method is combined with prediction, where for each image line, a ''filter method'' is chosen that predicts the color of each pixel based on the colors of previous pixels and subtracts the predicted color of the pixel from the actual color. An image line filtered in this way is often more compressible than the raw image line would be, especially if it is similar to the line above (since deflate has no understanding that an image is a 2D entity, and instead just sees the image data as a stream of bytes).
===Interlacing===
PNG offers an optional 2-dimensional, 7-pass interlacing scheme – the Adam7 algorithm. This is more sophisticated than GIF's 1-dimensional, 4-pass scheme, and allows a clearer low-resolution image to be visible earlier in the transfer. However, as a 7-pass scheme, it tends to reduce the data's compressibility more than simpler schemes.
===Animation===
PNG does not offer animation. MNG is an image format that supports animation and is based on the ideas and some of the chunks of PNG but is a complex system and does not offer fallback to single image display like GIF does. APNG is another image format based on PNG that supports animation and is simpler than MNG. APNG offers fallback to single image display for PNG decoders that do not support APNG. However neither of these formats are widely supported.

Talk:Main Page

2006-10-05T02:47:41Z

Dcsmith77:

Can we make some infos skeletons for the contributors and give links to the documentation of the wiki system and/or guide for how to write and which modification tags available?

== source list ==

http://www.digitalpreservation.gov/formats/fdd/browse_list.shtml

have you seen this site? not sure its useful, has some information.
plus its .gov!

-[[User:Compn|Compn]] 22:17, 21 September 2006 (EDT)

: I'm sure I [http://multimedia.cx/eggs/ blogged] about that somewhere. If you can find a good place for it on the Wiki, be my guest. --[[User:Multimedia Mike|Multimedia Mike]] 12:20, 22 September 2006 (EDT)

What about a section for image formats?--[[User:Dcsmith77|Dcsmith77]] 22:47, 4 October 2006 (EDT)

Talk:Main Page

2006-10-05T02:46:53Z

Dcsmith77: /* source list */

Can we make some infos skeletons for the contributors and give links to the documentation of the wiki system and/or guide for how to write and which modification tags available?

== source list ==

http://www.digitalpreservation.gov/formats/fdd/browse_list.shtml

have you seen this site? not sure its useful, has some information.
plus its .gov!
What about a section for image formats?
-[[User:Compn|Compn]] 22:17, 21 September 2006 (EDT)

: I'm sure I [http://multimedia.cx/eggs/ blogged] about that somewhere. If you can find a good place for it on the Wiki, be my guest. --[[User:Multimedia Mike|Multimedia Mike]] 12:20, 22 September 2006 (EDT)