The Longest Journey XMG - Revision history

imported>Ikskoks at 21:23, 21 January 2021

2021-01-21T21:23:11Z

← Older revision	Revision as of 21:23, 21 January 2021
(No difference)

imported>Ikskoks at 21:23, 21 January 2021

2021-01-21T21:23:11Z

← Older revision		Revision as of 21:23, 21 January 2021
Line 112:		Line 112:

	[[Category:PC formats\|The Longest Journey XMG]]		[[Category:PC formats\|The Longest Journey XMG]]
			[[Category:File Format]]

90.173.33.0 at 20:28, 4 April 2012

2012-04-04T20:28:31Z

← Older revision	Revision as of 20:28, 4 April 2012
(No difference)

90.173.33.0 at 20:28, 4 April 2012

2012-04-04T20:28:31Z

← Older revision		Revision as of 20:28, 4 April 2012
Line 110:		Line 110:

	Unknown<br>		Unknown<br>

			[[Category:PC formats\|The Longest Journey XMG]]

imported>DenizOezmen: header fixes

2007-03-16T18:59:26Z

header fixes

← Older revision	Revision as of 18:59, 16 March 2007
(No difference)

imported>DenizOezmen: header fixes

2007-03-16T18:59:26Z

header fixes

← Older revision		Revision as of 18:59, 16 March 2007
Line 56:		Line 56:
	<tt><b>		<tt><b>
	<font color="blue">// XMG header</font><br>		<font color="blue">// XMG header</font><br>
	uint32 {4} - ~~Colour depth (bytes)~~ <font color="~~purple~~">~~(3 for RGB)~~</font><br>		uint32 {4} - <font color="red">Unknown</font> (probably version number, usually 3)<br>
	RGB {3}    - Transparency colour<br>		RGB {3}    - Transparency colour<br>
	uint8 {1}  - <font color="red">Unknown</font><br>		uint8 {1}  - <font color="red">Unknown</font><br>
Line 62:		Line 62:
	uint32 {4} - Image height<br>		uint32 {4} - Image height<br>
	uint32 {4} - Scanline length<br>		uint32 {4} - Scanline length<br>
	~~uint32 {4} - Colour depth (bytes)<br>~~
	~~uint32 {4} - Colour depth (bytes)<br>~~
	uint32 {4} - <font color="red">Unknown</font><br>		uint32 {4} - <font color="red">Unknown</font><br>
	uint32 {4} - <font color="red">Unknown</font><br>		uint32 {4} - <font color="red">Unknown</font><br>
	</b></tt><br>		</b></tt><br>

	The scanline length value ~~equals the width of the image multiplied with the color depth (which should be 3). Thus, it~~ determines the memory consumption of one image line when expressed in RGB values.		The scanline length value determines the memory consumption of one image line when expressed in RGB values.

	After this header, the image data follows. It describes the image line-wise (from the top left to the bottom right) in terms of tiles (2x2 pixels in size) and can contain different types of colour entries: RGB, YCbCr or transparency. To cope with this differentiation, the basic data structure builds on reading byte opcodes. Such an opcode is interpreted as a bitfield of the format <tt>xxyyzzzz</tt>, where <tt>xx</tt> denotes the color mode (<tt>00</tt> for YCbCr, <tt>01</tt> for transparency, <tt>10</tt> for RGB) and <tt>yyzzzz</tt> denotes the number of tiles to be processed. In case <tt>xx</tt> equals <tt>11</tt>, <tt>yy</tt> is the color mode and a second opcode <tt>aaaaaaaa</tt> has to be read. The number of tiles is then <tt>zzzzaaaaaaaa</tt>.		After this header, the image data follows. It describes the image line-wise (from the top left to the bottom right) in terms of tiles (2x2 pixels in size) and can contain different types of colour entries: RGB, YCbCr or transparency. To cope with this differentiation, the basic data structure builds on reading byte opcodes. Such an opcode is interpreted as a bitfield of the format <tt>xxyyzzzz</tt>, where <tt>xx</tt> denotes the color mode (<tt>00</tt> for YCbCr, <tt>01</tt> for transparency, <tt>10</tt> for RGB) and <tt>yyzzzz</tt> denotes the number of tiles to be processed. In case <tt>xx</tt> equals <tt>11</tt>, <tt>yy</tt> is the color mode and a second opcode <tt>aaaaaaaa</tt> has to be read. The number of tiles is then <tt>zzzzaaaaaaaa</tt>.

imported>DenizOezmen: clarifications; also: colour space's correct name is YCbCr, not YCrCb

2006-09-04T00:25:09Z

clarifications; also: colour space's correct name is YCbCr, not YCrCb

← Older revision	Revision as of 00:25, 4 September 2006
(No difference)

imported>DenizOezmen: clarifications; also: colour space's correct name is YCbCr, not YCrCb

2006-09-04T00:25:09Z

clarifications; also: colour space's correct name is YCbCr, not YCrCb

← Older revision		Revision as of 00:25, 4 September 2006
Line 17:		Line 17:
	shall be called the <tt>RGB</tt> type.<br><br>		shall be called the <tt>RGB</tt> type.<br><br>

	The XMG format is based on the ~~YCrCb~~ colour scheme, which makes a conversion to RGB necessary, should one decide to save the image as a standard bitmap. Therefore, conversion tables have to be set up according to the following matrix/vector multiplication scheme:		The XMG format is based on the YCbCr colour scheme, which makes a conversion to RGB necessary, should one decide to save the image as a standard bitmap. Therefore, conversion tables have to be set up according to the following matrix/vector multiplication scheme (a rounded variant of the standard set in CCIR 601 without signal head- or footroom; quite similar to image data encoded according to the JFIF 1.02 standard [http://www.jpeg.org/public/jfif.pdf]):

	\| R \| \| 1.000000 1.402000 ~~0.000000~~ \| \| Y \|		\| R \| \| 1.000000 0.000000 1.402000 \| \| Y \|
	\| G \| = \| 1.000000 -0.~~714136~~ -0.~~344136~~ \| * \| Cr \|		\| G \| = \| 1.000000 -0.344136 -0.714136 \| * \| Cb - 128 \|
	\| B \| \| 1.000000 0.000000 ~~1.772000~~ \| \| Cb \|		\| B \| \| 1.000000 1.772000 0.000000 \| \| Cr - 128 \|

	Or put differently:		Or put differently:

	R = Y + 1.402 * Cr		R = Y + 1.402 * (Cr - 128)
	G = Y - 0.~~714136~~ * Cr - 0.~~344136~~ * Cb		G = Y - 0.344136 * (Cb - 128) - 0.714136 * (Cr - 128)
	B = Y + 1.772 * Cb		B = Y + 1.772 * (Cb - 128)

	Please note that		Please note that
Line 42:		Line 42:
	</tt>		</tt>

	Now, the conversion from ~~YCrCb~~ to RGB can be done simply by:		Now, the conversion from YCbCr to RGB can be done simply by:

	R = Y + YCrR[Cr]		R = Y + YCrR[Cr]
	G = Y + ~~YCrG~~[Cr] + ~~YCbG~~[Cb]		G = Y + YCbG[Cb] + YCrG[Cr]
	B = Y + YCbB[Cb]		B = Y + YCbB[Cb]

Line 70:		Line 70:
	The scanline length value equals the width of the image multiplied with the color depth (which should be 3). Thus, it determines the memory consumption of one image line when expressed in RGB values.		The scanline length value equals the width of the image multiplied with the color depth (which should be 3). Thus, it determines the memory consumption of one image line when expressed in RGB values.

	After this header, the image data follows. It describes the image line-wise (from the top left to the bottom right) in terms of tiles (2x2 pixels in size) and can contain different types of colour entries: RGB, ~~YCrCb~~ or transparency. To cope with this differentiation, the basic data structure builds on reading byte opcodes. Such an opcode is interpreted as a bitfield of the format <tt>xxyyzzzz</tt>, where <tt>xx</tt> denotes the color mode (<tt>00</tt> for ~~YCrCb~~, <tt>01</tt> for transparency, <tt>10</tt> for RGB) and <tt>yyzzzz</tt> denotes the number of tiles to be processed. In case <tt>xx</tt> equals <tt>11</tt>, <tt>yy</tt> is the color mode and a second opcode <tt>aaaaaaaa</tt> has to be read. The number of tiles is then <tt>zzzzaaaaaaaa</tt>.		After this header, the image data follows. It describes the image line-wise (from the top left to the bottom right) in terms of tiles (2x2 pixels in size) and can contain different types of colour entries: RGB, YCbCr or transparency. To cope with this differentiation, the basic data structure builds on reading byte opcodes. Such an opcode is interpreted as a bitfield of the format <tt>xxyyzzzz</tt>, where <tt>xx</tt> denotes the color mode (<tt>00</tt> for YCbCr, <tt>01</tt> for transparency, <tt>10</tt> for RGB) and <tt>yyzzzz</tt> denotes the number of tiles to be processed. In case <tt>xx</tt> equals <tt>11</tt>, <tt>yy</tt> is the color mode and a second opcode <tt>aaaaaaaa</tt> has to be read. The number of tiles is then <tt>zzzzaaaaaaaa</tt>.

	Colour entries of the defined type are read until the requested number of tiles has been filled. Then, the next opcode can be read.<br><br>		Colour entries of the defined type are read until the requested number of tiles has been filled. Then, the next opcode can be read.<br><br>

	==== ~~YCrCb~~ colour mode ====		==== YCbCr colour mode ====

	In this mode, colour entries of the type		In this mode, colour entries of the type
Line 103:		Line 103:
	==== RGB colour mode ====		==== RGB colour mode ====

	In this mode, four structures of the type <tt>RGB</tt> have to be read per requested tile. The colours are applied to the tile just like the Yx values in the ~~YCrCb~~ mode are distributed.<br><br>		In this mode, four structures of the type <tt>RGB</tt> have to be read per requested tile. The colours are applied to the tile just like the Yx values in the YCbCr mode are distributed.<br><br>

	=== MultiEx BMS ===		=== MultiEx BMS ===

imported>DenizOezmen: added format description

2006-08-29T17:15:20Z

added format description

← Older revision	Revision as of 17:15, 29 August 2006
(No difference)

imported>DenizOezmen: added format description

2006-08-29T17:15:20Z

added format description

New page

== XMG ==

* ''' Format Type ''': Image 
* ''' [http://en.wikipedia.org/wiki/Endianness Endian Order] ''': Little Endian 

=== General conventions and basic definitions ===

First, let the following be a convention throughout this document: 

<tt>
uint8 {1} - Red 
uint8 {1} - Green 
uint8 {1} - Blue 
</tt>

shall be called the <tt>RGB</tt> type. 

The XMG format is based on the YCrCb colour scheme, which makes a conversion to RGB necessary, should one decide to save the image as a standard bitmap. Therefore, conversion tables have to be set up according to the following matrix/vector multiplication scheme:

| R | | 1.000000 1.402000 0.000000 | | Y |
| G | = | 1.000000 -0.714136 -0.344136 | * | Cr |
| B | | 1.000000 0.000000 1.772000 | | Cb |

Or put differently:

R = Y + 1.402 * Cr
G = Y - 0.714136 * Cr - 0.344136 * Cb
B = Y + 1.772 * Cb

Please note that
* all result values have to be clamped to byte values, i.e. integers in the range of 0..255 and
* depending on how this conversion is implemented, small differences (due to rounding) in comparison to the pictures generated by the game engine are possible. However, if done right, these differences are usually unnoticable by the human eye.

Thus, in the course of this document it is assumed that the following tables have been set up: 

<tt>
YCbB[i]  --  given the Cb value i, output its contribution to B 
YCrR[i]  --  given the Cr value i, output its contribution to R 
YCbG[i]  --  given the Cb value i, output its contribution to G 
YCrG[i]  --  given the Cr value i, output its contribution to G 
</tt>

Now, the conversion from YCrCb to RGB can be done simply by:

R = Y + YCrR[Cr]
G = Y + YCrG[Cr] + YCbG[Cb]
B = Y + YCbB[Cb]

 

=== Format Specifications ===

An XMG file starts with a general header: 

<tt>
// XMG header 
uint32 {4} - Colour depth (bytes) (3 for RGB) 
RGB {3}    - Transparency colour 
uint8 {1}  - Unknown 
uint32 {4} - Image width 
uint32 {4} - Image height 
uint32 {4} - Scanline length 
uint32 {4} - Colour depth (bytes) 
uint32 {4} - Colour depth (bytes) 
uint32 {4} - Unknown 
uint32 {4} - Unknown 
</tt> 

The scanline length value equals the width of the image multiplied with the color depth (which should be 3). Thus, it determines the memory consumption of one image line when expressed in RGB values.

After this header, the image data follows. It describes the image line-wise (from the top left to the bottom right) in terms of tiles (2x2 pixels in size) and can contain different types of colour entries: RGB, YCrCb or transparency. To cope with this differentiation, the basic data structure builds on reading byte opcodes. Such an opcode is interpreted as a bitfield of the format <tt>xxyyzzzz</tt>, where <tt>xx</tt> denotes the color mode (<tt>00</tt> for YCrCb, <tt>01</tt> for transparency, <tt>10</tt> for RGB) and <tt>yyzzzz</tt> denotes the number of tiles to be processed. In case <tt>xx</tt> equals <tt>11</tt>, <tt>yy</tt> is the color mode and a second opcode <tt>aaaaaaaa</tt> has to be read. The number of tiles is then <tt>zzzzaaaaaaaa</tt>.

Colour entries of the defined type are read until the requested number of tiles has been filled. Then, the next opcode can be read. 

==== YCrCb colour mode ====

In this mode, colour entries of the type

<tt>
uint8 {1} - Y0 
uint8 {1} - Y1 
uint8 {1} - Y2 
uint8 {1} - Y3 
uint8 {1} - Cr 
uint8 {1} - Cb 
</tt>

have to be read. The Cr- and Cb-values are valid for the complete tile, while the Yx-values have to be applied to the four pixels of the tile in the following manner:

+----+----+
| Y0 | Y1 |
+----+----+
| Y2 | Y3 |
+----+----+

The conversion to RGB can be done as specified above. 

==== Transparency colour mode ====

Here, the requested number of tiles is simply flood-filled with the transperency colour specified in the XMG header. 

==== RGB colour mode ====

In this mode, four structures of the type <tt>RGB</tt> have to be read per requested tile. The colours are applied to the tile just like the Yx values in the YCrCb mode are distributed. 

=== MultiEx BMS ===

Not written yet 

=== Supported Programs ===

Unknown