ILBM IFF Interleaved Bitmap - Revision history

Steven Solie: /* Appendix E. Standards Committee */

2012-06-08T21:05:32Z

Appendix E. Standards Committee

Steven Solie: /* ILBM.PRVW.proposal */

2012-05-10T20:09:42Z

ILBM.PRVW.proposal

← Older revision		Revision as of 20:09, 10 May 2012
Line 1,192:		Line 1,192:
	</pre>		</pre>

	= ILBM.PRVW~~.proposal~~ =		= ILBM.PRVW =

	<pre>		<pre>
Line 1,208:		Line 1,208:
	and nobody can read them).		and nobody can read them).
	</pre>		</pre>


	= ILBM.XBMI =		= ILBM.XBMI =

Steven Solie: /* ILBM.CLUT */

2012-05-10T19:00:52Z

ILBM.CLUT

← Older revision		Revision as of 19:00, 10 May 2012
Line 417:		Line 417:
	= ILBM.CLUT =		= ILBM.CLUT =

			<pre>
	TITLE: CLUT IFF chunk proposal		TITLE: CLUT IFF chunk proposal

Line 519:		Line 520:
	small ones like CLUT.		small ones like CLUT.
	</pre>		</pre>


	= ILBM.CMYK =		= ILBM.CMYK =

Steven Solie: /* ILBM.PCNG */

2012-05-10T18:43:46Z

ILBM.PCNG

← Older revision		Revision as of 18:43, 10 May 2012
Line 815:		Line 815:


	= ILBM.~~PCNG~~ =		= ILBM.PCHG =

	<pre>		<pre>
Line 1,191:		Line 1,191:
	==========================		==========================
	</pre>		</pre>


	= ILBM.PRVW.proposal =		= ILBM.PRVW.proposal =

Steven Solie: /* ILBM.PCNG */

2012-05-10T18:37:57Z

ILBM.PCNG

← Older revision		Revision as of 18:37, 10 May 2012
Line 1,190:		Line 1,190:

	==========================		==========================
			</pre>


			= ILBM.PRVW.proposal =

			<pre>
			A mini duplicate ILBM used for preview (Gary Bonham)

			Registered 9/91 by Oxxi's Gary Bonham

			PRVW is just like an ILBM but is nested in an ILBM. It is a
			miniature version of the picture.

			He didn't call it ILBM because he didn't want editors and parsers
			getting confused and delving in.

			He didn't use a CAT for obvious reasons (like they blow up DPaint
			and nobody can read them).
			</pre>


			= ILBM.XBMI =

			<pre>
			eXtended BitMap Information (Soft-Logik)

			Chunk XBMI for FORM ILBM
			========================

			Submitted by Dan Weiss, Deron Kazmaier, and Gary Knight (8/29/91)

			Chunk ID: "XBMI" (eXtended BitMap Information)
			Description: This chunk will hold the horizontal and vertical dots per inch,
			and the picture type. Each entry is one word (two bytes) in length for a total
			chunk length of three words. The first word holds the picture type. Currently
			we have defined 6 types of pictures:

			#define ILBM_PAL 0 /* BODY data = indexes into the palette (CMAP)
			* numcolors = 1<<depth;
			*/

			#define ILBM_GREY 1 /* BODY = grayscale values
			* Bits per sample = number of bitplanes.
			* Samples per pixel = 1.
			* black = 0, white = (1<<depth)-1;
			*/

			#define ILBM_RGB 2 /* BODY data = red, green, and blue values.
			* Bits per sample = depth/3.
			* Samples per pixel = 3.
			*/

			#define ILBM_RGBA 3 /* BODY data = red, green, blue, and alpha
			* channel values.
			* Bits per sample = depth/4.
			* Samples per pixel = 4.
			*/

			#define ILBM_CMYK 4 /* BODY data = cyan, magenta, yellow, and black
			* values.
			* Bits per sample = depth/4.
			* Samples per pixel = 4.
			*/

			#define ILBM_CMYKA 5 /* BODY data = cyan, magenta, yellow, black,
			* and alpha channel values.
			* Bits per sample = depth/5.
			* Samples per pixel = 5.
			*/

			#define ILBM_BW 6 /* BODY data = black and white bits.
			* Bits per sample = 1.
			* Samples per pixel = 1.
			* white = 0, black = 1.
			*/

			The second and third words hold the number of dots per inch in the horizontal
			and vertical directions respectively.

			Example:

			XBMI ;chunk ID
			00000006 ;chunk length (6 bytes)
			0002 ;picture type (2==ILBM_RGB)
			012C ;x dpi (300)
			012C ;y dpi (300)
			</pre>


			= ILBM.XSSL =

			<pre>
			Identifier chunk for 3d X-Specs image. (Haitex)

			Finding an XSSL chunk in an ILBM indicates that the ILBM is to be displayed as
			a 3-D image with the X-Specs product from Haitex.

			The chunk contains four (4) bytes of reserved data.
	</pre>		</pre>

Steven Solie: /* ILBM.DPPV */

2012-05-10T18:34:42Z

ILBM.DPPV

Show changes

Steven Solie at 18:32, 10 May 2012

2012-05-10T18:32:39Z

Show changes

Steven Solie at 18:29, 10 May 2012

2012-05-10T18:29:20Z

@@ Line 1: / Line 1: @@
-= “ILBM” IFF Interleaved Bitmap =
+= ILBM IFF Interleaved Bitmap =
 ; Document Date:
@@ Line 413: / Line 413: @@
 Dan Silva, Electronic Arts<br />
 Barry Walsh, Commodore-Amiga<br />

Steven Solie: /* CAMG */

2012-05-09T16:31:58Z

CAMG

← Older revision		Revision as of 16:31, 9 May 2012
Line 153:		Line 153:
	=== CAMG ===		=== CAMG ===

	A “CAMG” chunk is specifically for ~~Commodore~~ Amiga ILBMs. All Amiga-based reader and writer software should deal with CAMG. The Amiga supports many different video display modes including interlace, Extra Halfbrite, hold and modify (HAM), plus a variety of new modes under the 2.0 operating system. A CAMG chunk contains a single long word (length=4) which specifies the Amiga display mode of the picture.		A “CAMG” chunk is specifically for Amiga ILBMs. All Amiga-based reader and writer software should deal with CAMG. The Amiga supports many different video display modes including interlace, Extra Halfbrite, hold and modify (HAM), plus a variety of new modes under the 2.0 operating system. A CAMG chunk contains a single long word (length=4) which specifies the Amiga display mode of the picture.

	Prior to 2.0, it was possible to express all available Amiga ViewModes in 16 bits of flags (Viewport->Modes or NewScreen->ViewModes). Old-style writers and readers place a 16-bit Amiga ViewModes value in the low word of the CAMG, and zeros in the high word. The following Viewmode flags should always be removed from old-style 16-bit ViewModes values when writing or reading them:		Prior to 2.0, it was possible to express all available Amiga ViewModes in 16 bits of flags (Viewport->Modes or NewScreen->ViewModes). Old-style writers and readers place a 16-bit Amiga ViewModes value in the low word of the CAMG, and zeros in the high word. The following Viewmode flags should always be removed from old-style 16-bit ViewModes values when writing or reading them:
Line 202:		Line 202:
	* HIRES \| LACE \| HAM \| EXTRA_HALFBRITE		* HIRES \| LACE \| HAM \| EXTRA_HALFBRITE
	*/</pre>		*/</pre>

	== Standard “BODY” Data Chunk ==		== Standard “BODY” Data Chunk ==

Steven Solie: /* Introduction */

2012-05-09T03:32:21Z

Introduction

← Older revision		Revision as of 03:32, 9 May 2012
Line 14:		Line 14:
	An ILBM is an archival representation designed for three uses. First, a stand- alone image that specifies exactly how to display itself (resolution, size, color map, etc.). Second, an image intended to be merged into a bigger picture which has its own depth, color map, and so on. And third, an empty image with a color map selection or “palette” for a paint program. ILBM is also intended as a building block for composite IFF FORMs like “animation sequences” and “structured graphics”. Some uses of ILBM will be to preserve as much information as possible across disparate environments. Other uses will be to store data for a single program or highly cooperative programs while maintaining subtle details. So we’re trying to accomplish a lot with this one format.		An ILBM is an archival representation designed for three uses. First, a stand- alone image that specifies exactly how to display itself (resolution, size, color map, etc.). Second, an image intended to be merged into a bigger picture which has its own depth, color map, and so on. And third, an empty image with a color map selection or “palette” for a paint program. ILBM is also intended as a building block for composite IFF FORMs like “animation sequences” and “structured graphics”. Some uses of ILBM will be to preserve as much information as possible across disparate environments. Other uses will be to store data for a single program or highly cooperative programs while maintaining subtle details. So we’re trying to accomplish a lot with this one format.

	This memo is the IFF supplement for FORM ILBM. Section 2 defines the purpose and format of property chunks bitmap header “BMHD”, color map “CMAP”, hotspot “GRAB”, destination merge data “DEST”, sprite information “SPRT”, and ~~Commodore~~ Amiga viewport mode “CAMG”. Section 3 defines the standard data chunk “BODY”. These are the “standard” chunks. Section 4 defines the non- standard data chunks. Additional specialized chunks like texture pattern can be added later. The ILBM syntax is summarized in Appendix A as a regular expression and in Appendix B as a box diagram. Appendix C explains the optional run encoding scheme. Appendix D names the committee responsible for this FORM ILBM standard.		This memo is the IFF supplement for FORM ILBM. Section 2 defines the purpose and format of property chunks bitmap header “BMHD”, color map “CMAP”, hotspot “GRAB”, destination merge data “DEST”, sprite information “SPRT”, and Amiga viewport mode “CAMG”. Section 3 defines the standard data chunk “BODY”. These are the “standard” chunks. Section 4 defines the non- standard data chunks. Additional specialized chunks like texture pattern can be added later. The ILBM syntax is summarized in Appendix A as a regular expression and in Appendix B as a box diagram. Appendix C explains the optional run encoding scheme. Appendix D names the committee responsible for this FORM ILBM standard.

	Details of the raster layout are given in part 3, “Standard Data Chunk”. Some elements are based on the ~~Commodore~~ Amiga hardware but generalized for use on other computers. An alternative to ILBM would be appropriate for computers with true color data in each pixel, though the wealth of available ILBM images makes import and export important.		Details of the raster layout are given in part 3, “Standard Data Chunk”. Some elements are based on the Amiga hardware but generalized for use on other computers. An alternative to ILBM would be appropriate for computers with true color data in each pixel, though the wealth of available ILBM images makes import and export important.

	=== Reference ===		=== Reference ===
Line 24:		Line 24:
	describes the underlying conventions for all IFF files.		describes the underlying conventions for all IFF files.

	Amiga is a registered trademark of ~~Commodore-~~Amiga, Inc.		Amiga is a registered trademark of Amiga, Inc.

	Electronic Arts is a trademark of Electronic Arts.		Electronic Arts is a trademark of Electronic Arts.