Escape 130 - Revision history

Multimedia Mike: update to link to mirrored document

2018-01-26T03:20:29Z

update to link to mirrored document

← Older revision		Revision as of 20:20, 25 January 2018
Line 1:		Line 1:
	* [[Eidos Technologies]]		* [[Eidos Technologies]]
	* Samples: http://samples.mplayerhq.hu/game-formats/rpl/		* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
	* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt ~~(The referenced~~ document was used as a reference for a lot of the description ~~here~~, but ~~note that~~ the Pb/Pr adjustment table described ~~there has~~ errors! The tables on this page are correct.)		* Technical Description: https://multimedia.cx/mirror/dec130-spec.txt (Mirrored from this now-defunct link: http://pirsoft-dsl-dropzone.de/dec130-spec.txt ) Note that this document was used as a reference for a lot of the description on this page, but the Pb/Pr adjustment table described in the original document had errors. The tables on this wiki page are correct.

	Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.		Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

Eli.friedman at 18:16, 22 June 2008

2008-06-22T18:16:21Z

← Older revision		Revision as of 11:16, 22 June 2008
Line 1:		Line 1:
	* [[Eidos Technologies]]		* [[Eidos Technologies]]
	* Samples: http://samples.mplayerhq.hu/game-formats/rpl/		* Samples: http://samples.mplayerhq.hu/game-formats/rpl/
	* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt		* Technical Description: http://pirsoft-dsl-dropzone.de/dec130-spec.txt (The referenced document was used as a reference for a lot of the description here, but note that the Pb/Pr adjustment table described there has errors! The tables on this page are correct.)

	Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.		Surprisingly, unlike previous [[ESCAPE]] codecs, Escape 130 was completely redesigned. Now it operates in mixed [[YUV]]/[[RGB]] colorpace and employs simple differential coding. In short, the source RGB image broken into 2x2 blocks. The average value of each pixel quad is interpolated, converted to YUV colorspace and stored together with quantized neighboring pixel differences. The decoder, operating in reverse, unpacks interpolated pixel values, convert them to RGB colorspace, then requantizes 4 pixels using supplied or pre-defined coefficient set. Compression works well for full-motion video, but static images experience visible blocking.

	~~'''~~The following is a ~~work-in-progress~~ spec for the Escape 130 codec; it is ~~likely to be inaccurate!'''~~		The following is a spec for the Escape 130 codec; this is accurate as far as I know, but it is possible there are errors.

	==Container==		==Container==
Line 31:		Line 31:
	==Colorspace and Organization==		==Colorspace and Organization==

	Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace. Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There is always one base Y sample for any given block, plus there can be a adjustment pattern on top of the sample, which provides more resolution.		Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace. Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There is always one base Y sample for any given block, plus there can be a adjustment pattern on top of the base sample, which provides more resolution.

	XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, there is a special pattern applied after conversion to 8-bit RGB: (top left) green+6, (top right) red+6 blue+6, (bottom left) red+4 blue+4 green+2, (bottom right) red+2 blue+2 green+4. However, I have no idea what the purpose is; I think this is too small to be visible.		XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, there is a special pattern applied after conversion to 8-bit RGB: (top left) green+6, (top right) red+6 blue+6, (bottom left) red+4 blue+4 green+2, (bottom right) red+2 blue+2 green+4. However, I have no idea what the purpose is; possibly to reduce blockiness? That said, I think this adjustment is too small to be visible.

	XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there is a flag in bit 17 of the header that allows selecting an alternate colorspace, but I don't know of any samples.		XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there is a flag in bit 17 of the header that allows selecting an alternate colorspace, but I don't know of any samples.

Eli.friedman: /* Colorspace and Organization */

2008-06-22T17:53:51Z

Colorspace and Organization

← Older revision		Revision as of 10:53, 22 June 2008
Line 35:		Line 35:
	XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, there is a special pattern applied after conversion to 8-bit RGB: (top left) green+6, (top right) red+6 blue+6, (bottom left) red+4 blue+4 green+2, (bottom right) red+2 blue+2 green+4. However, I have no idea what the purpose is; I think this is too small to be visible.		XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, there is a special pattern applied after conversion to 8-bit RGB: (top left) green+6, (top right) red+6 blue+6, (bottom left) red+4 blue+4 green+2, (bottom right) red+2 blue+2 green+4. However, I have no idea what the purpose is; I think this is too small to be visible.

	XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there is a flag in ~~but~~ 17 of the header that allows selecting an alternate colorspace.		XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there is a flag in bit 17 of the header that allows selecting an alternate colorspace, but I don't know of any samples.

	==Encoding==		==Encoding==

Eli.friedman: /* Encoding */

2008-06-22T17:44:54Z

Encoding

← Older revision		Revision as of 10:44, 22 June 2008
Line 47:		Line 47:
	A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.		A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

	There are four formats for the Y value(s): one encodes a base value for the block plus an intensity pattern for the individual pixels, one just encodes a base value, one encodes a difference from the previous block's base value, and one is just an indicator to use the previous block's base value. ~~(XXX talk about the individual pixel adjustments for the blocks without an intensity pattern.)~~		There are four formats for the Y value(s): one encodes a base value for the block plus an intensity pattern for the individual pixels, one just encodes a base value, one encodes a difference from the previous block's base value, and one is just an indicator to use the previous block's base value.

	There are three formats for the Cb and Cr values: one encodes the values for the block, one encodes an adjustment from the previous block's values, and one is just an indicator to use the previous block's values.		There are three formats for the Cb and Cr values: one encodes the values for the block, one encodes an adjustment from the previous block's values, and one is just an indicator to use the previous block's values.

Eli.friedman: /* Colorspace and Organization */

2008-06-22T17:43:39Z

Colorspace and Organization

← Older revision		Revision as of 10:43, 22 June 2008
Line 31:		Line 31:
	==Colorspace and Organization==		==Colorspace and Organization==

	Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace ~~(XXX not exactly right?)~~. Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There is always one base Y sample for any given block, plus there can be a adjustment pattern on top of the sample, which provides more resolution.		Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace. Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There is always one base Y sample for any given block, plus there can be a adjustment pattern on top of the sample, which provides more resolution.

	XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, ~~the default pattern~~ is a pattern ~~which affects~~ the ~~Cb and Cr channels~~; this ~~doesn't really make much sense~~ to ~~me, though~~.		XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, there is a special pattern applied after conversion to 8-bit RGB: (top left) green+6, (top right) red+6 blue+6, (bottom left) red+4 blue+4 green+2, (bottom right) red+2 blue+2 green+4. However, I have no idea what the purpose is; I think this is too small to be visible.

	XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there ~~might be~~.		XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there is a flag in but 17 of the header that allows selecting an alternate colorspace.

	==Encoding==		==Encoding==

Eli.friedman at 06:05, 3 April 2008

2008-04-03T06:05:47Z

← Older revision		Revision as of 23:05, 2 April 2008
Line 34:		Line 34:

	XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, the default pattern is a pattern which affects the Cb and Cr channels; this doesn't really make much sense to me, though.		XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, the default pattern is a pattern which affects the Cb and Cr channels; this doesn't really make much sense to me, though.

			XXXFIXME: Is there more than one potential colorspace? Some information I have indicates that there might be.

	==Encoding==		==Encoding==

Eli.friedman: /* Colorspace and Organization */ Wording change, plus explain FIXME a bit

2008-04-03T05:53:14Z

Colorspace and Organization: Wording change, plus explain FIXME a bit

← Older revision		Revision as of 22:53, 2 April 2008
Line 31:		Line 31:
	==Colorspace and Organization==		==Colorspace and Organization==

	Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace (XXX not exactly right?). Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There ~~can be either~~ one ~~or four~~ Y ~~samples~~ for any given block.		Each frame is conceptually a series of 2x2 blocks of pixels, encoded from left to right, top to bottom. The colors are encoded in the file using a [[YCbCr]] colorspace (XXX not exactly right?). Y samples use 6 bits, Cb and Cr samples use 5 bits. There is always one Cb and one Cr sample per 2x2 block of pixels. There is always one base Y sample for any given block, plus there can be a adjustment pattern on top of the sample, which provides more resolution.

	XXXFIXME: I~~'ve seen various comments involving stuff in~~ an ~~RGB colorspace~~; ~~I don~~'t ~~know exactly what is going on here~~, ~~and I'm not going to try and figure it out until I've got the rest of decoding working~~.		XXXFIXME: The information I have indicates that for blocks without an adjustment pattern, the default pattern is a pattern which affects the Cb and Cr channels; this doesn't really make much sense to me, though.

	==Encoding==		==Encoding==

Eli.friedman: Fix up intensity pattern information

2008-04-03T05:25:40Z

Fix up intensity pattern information

Show changes

Eli.friedman: Some small, but important, corrections/clarifications

2008-04-03T02:47:25Z

Some small, but important, corrections/clarifications

← Older revision		Revision as of 19:47, 2 April 2008
Line 45:		Line 45:
	A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.		A block code consists of two parts: the first part encodes the Y value(s), and the second part encodes the Cb and Cr values.

	There are four formats for the Y value(s): one encodes a base value for the block plus ~~a difference~~ pattern for the individual pixels, one just encodes a base value ~~(XXX with a flat pattern?)~~, one encodes a difference from the previous ~~values~~, and one is just an indicator to use ~~the values from~~ the previous block.		There are four formats for the Y value(s): one encodes a base value for the block plus an intensity pattern for the individual pixels, one just encodes a base value, one encodes a difference from the previous block's base value, and one is just an indicator to use the previous block's base value. (XXX talk about the individual pixel adjustments for the blocks without an intensity pattern.)

	There are three formats for the Cb and Cr values: one encodes the values for the block, ~~and~~ one encodes an adjustment ~~for~~ the previous block, and one is just an indicator to use ~~the values from~~ the previous block.		There are three formats for the Cb and Cr values: one encodes the values for the block, one encodes an adjustment from the previous block's values, and one is just an indicator to use the previous block's values.

	==Encoding details==		==Encoding details==
Line 165:		Line 165:
	\|}		\|}

	====Tables for 4-~~color~~ encoding====		====Tables for intensity-pattern encoding====
	======Pattern strength codes (adjustments strengths relative to 6-bit sample):======		======Pattern strength codes (adjustments strengths relative to 6-bit sample):======
	(XXX Unverified)		(XXX Unverified)

Eli.friedman: /* Table for Cb/Cr adjustment codes */ Finally figured out the right Cr codes

2008-04-02T01:48:51Z

Table for Cb/Cr adjustment codes: Finally figured out the right Cr codes

← Older revision		Revision as of 18:48, 1 April 2008
Line 126:		Line 126:

	====Table for Cb/Cr adjustment codes====		====Table for Cb/Cr adjustment codes====
	~~(XXX I'm almost certain the Cr column is wrong!)~~
	{\| border="1"		{\| border="1"
	\|-		\|-
Line 147:		Line 146:
	\| 011		\| 011
	\| -1		\| -1
	\| 0		\| 1
	\|-		\|-
	\| 100		\| 100
	\| -1		\| -1
	\| -1		\| 0
	\|-		\|-
	\| 101		\| 101
	\| -1		\| -1
	\| -2		\| -1
	\|-		\|-
	\| 110		\| 110
Line 165:		Line 164:
	\| -1		\| -1
	\|}		\|}


	====Tables for 4-color encoding====		====Tables for 4-color encoding====