IFF FORM and Chunk Registry

IFF FORM and Chunk Registry

Last Updated: June 8, 2012

This section contains the official list of registered FORM and Chunk names that are reserved and in use. This list is often referred to as the 3rd party registry since these are FORM and Chunk types created by application developers and not part of the original IFF specification.

For all FORM and Chunk types that are public, the official specifications from the third party company are listed (in alphabetical order). At the end of this section are additional documents describing how the ILBM FORM type works on the Amiga.

New chunks and FORMS should be registered with the AmigaOS development team. Please make all submissions via the AmigaOS web site contact form.

Developing New IFF FORMs and Chunks

IFF has been one of the keys to the Amiga's superiority in multimedia applications, allowing interchange of media elements between packages. The wealth of standard IFF FORMs and chunks gives the Amiga user data-sharing capabilities that are virtually unequaled on other systems. The Amiga's ability to render an image, touch it up, convert it to a different display mode, and load it into in another package is something that is a chore on other platforms, simply because the format of the image file may be different from one application to the next. IFF files lessen the need for "conversion" software, because most Amiga applications can read and write them.

Since its introduction as an open standard in 1985, IFF has widened to encompass data of many sorts-and the need for new IFF types continues to grow. To satisfy these growing needs, developers will continue to define and support new IFF types.

When developing a new IFF type, there are several steps you should follow:

Discuss needs and specifications within the developer community and with the AmigaOS development team.

The most important thing about designing IFF FORMs and chunks is that they meet the data storage and transfer needs of multiple applications. When more than one product uses the same IFF type, the market widens for all products that use that IFF type. Users are not forced to use one product or another, but can buy as many as they need to get the job done, fully utilizing all the features that each product has to offer. This step helps to ensure that a proposed IFF form or chunk type is flexible and isn't redundant.

Implement the new type and conduct feasibility tests.

Before settling on a format, set up prototype code to test the proposed format. This will help to prove that the idea is sound and can be implemented in software before others try to use it.

Submit specifications to the AmigaOS development team.

Coming up with a new kind of IFF FORM or chunk is easy--almost too easy. Just about anyone can follow the IFF guidelines and define their own FORM or chunk. If every application used a different IFF FORM, one application would be unable to share data with another because it can't read the other application's IFF FORM. It's like making up a new word for something that everyone sees every day. You may understand what the word means, but when you try to use your new word to communicate with others, they won't understand you. Further, deciding to use a pre-existing FORM or chunk in a new and different way is a lot like making up your own meaning for a pre-existing word. Confusion results when programs try to read FORMs or chunks whose meaning was altered by a non-conforming program.

To avoid the problem of incompatible IFF types, register your new IFF types with the AmigaOS development team. The AmigaOS development team acts as a "dictionary" of IFF types. By submitting your proposals for FORM or chunk types to Amigan Software, you help prevent duplication of an existing data type. Also, if you register your new IFF type, it is more likely that it will be adopted as an IFF standard that other applications will use. For example, the ANIM form came from third party developers who proposed and refined the format. Now ANIM is the de facto standard for animation files.

For an excellent example of a third party FORM specification, see the WORD FORM. For an example of chunk descriptions, examine the 8SVX FORM's SEQN and FADE chunks.

Note that even you don't plan to release the specifications of your FORM or chunk, you must still register the name with the AmigaOS development team. This is the only way to prevent name conflicts in IFF files. You should register your FORM and chunk names before finalizing your product and its documentation in case there is a name conflict with an existing IFF type.

Distribute final specifications to the developer community.

Once you have registered your FORM or chunk with the AmigaOS development team, you should release the specifications of the chunk to the developer community. Although the AmigaOS development team publishes FORMs and chunks online developers should not rely on this method to distribute their IFF type specification. One of the most efficient ways to distribute your specification is to include it in your application's documentation. Distributing the specification will increase the probability of your FORM or chunk becoming a standard.

Third party FORMs

The following is an alphabetical list of registered FORMs, generic chunks (shown as (any).chunkname), and registered new chunks for existing FORMs (shown as formname.chunkname). The center column describes where additional information on the FORM or chunk may be found. Items marked “EA IFF” are described in the main chapters of the EA IFF specs. Those marked “IFF TP” are described in the third-party specifications section. Items marked “propos” are submitted proposals, some of which are private. And items marked with “—” are private or yet unreleased specifications.

Chunk ID	Reference	Description
(any).ANNO	IFF Standard	EA IFF 85 generic annotation chunk
(any).AUTH	IFF Standard	EA IFF 85 generic author chunk
(any).CHRS	IFF Standard	EA IFF 85 generic character string chunk
(any).CSET	IFF_TP	chunk for specifying character set
(any).FRED	--	Private ASDG global chunk
(any).FVER	IFF_TP	chunk for 2.0 VERSION string of an IFF file
(any).HLID	IFF_TP	HotLink IDentification (Soft-Logik)
(any).INFO	propos	This chunk contains data usually found in a file's .info file
(any).JUNK	IFF_TP	Always ignore this chunk
(any).UTF8	IFF_TP	UTF-8 character text
(any).NAME	IFF Standard	EA IFF 85 generic name of art, music, etc. chunk
(any).TEXT	IFF Standard	EA IFF 85 generic unformatted ASCII text chunk
(any).(c)	IFF Standard	EA IFF 85 generic copyright text chunk
8SVX	EA_IFF	EA IFF 85 8-bit sound sample form
8SVX.CHAN.PAN	IFF_TP	Stereo chunks for 8SVX form
8SVX.SEQN.FADE	IFF_TP	Looping chunks for 8SVX form
ACBM	IFF_TP	Amiga Contiguous Bitmap form
AHAM	----	unregistered (???)
AHIM	private	AHI Modes
AHIM.AUDN	private	AUDio driver Name
AHIM.AUDD	private	AUDio driver Data
AHIM.AUDM	private	AUDio Mode
AIFF	IFF_TP	Audio 1-32 bit samples (Mac, Apple II, Synthia Pro)
ANBM	IFF_TP	Animated bitmap form (Framer, Deluxe Video)
ANIM	IFF_TP	Cel animation form
ANIM.brush	IFF_TP	ANIM brush format
ANIM.op6	IFF_TP	Stereo (3D) animations
ANIM.op7	----	unregistered (???)
ANIM.op8	IFF_TP	-
ARC	propos	archive format proposal (old)
ARES	----	unregistered (???)
ATXT	----	temporarily reserved
AVCF	private	AmigaVision Flow format (currently private)
BANK	----	Soundquest Editor/Librarian MIDI Sysex dump
BBSD	----	BBS Database, F. Patnaude, Jr., Phalanx Software
C100	----	Cloanto Italia private format
CAT	IFF Standard	EA IFF 85 group identifier
CELP	propos	For storage of compressed ZyXEL voice data (reserved)
CHBM	----	Chunky bitmap (name reserved by Eric Lavitsky)
CLIP	----	CAT CLIP to hold various formats in clipboard
CMUS	propos	Common MUsical Score
CPFM	----	Cloanto Personal FontMaker (doc in their manual)
DCCL	----	DCTV paint clip
DCPA	----	DCTV paint palette
DCTV	----	DCTV raw picture file
DECK	----	private format for Inovatronics CanDo
DEEP	IFF_TP	Chunky pixel image files (used in TV Paint)
DOC	----	unregistered (PageStream)
DR2D	IFF_TP	2D object standard format
DSDR	----	unregistered (DrawStudio)
DRAW	----	reserved by Jim Bayless, 12/90
DTYP	IFF_TP	DataTypes identification
EXEC	propos	Proposed form for executable (loadseg-able) code
FANT	IFF_TP	Fantavision movie format
FAX3	----	private GPSoftware FAX format, no longer used
FAXX.GPHD	IFF_TP	Additional header info for FAXX forms
FAXX	IFF_TP	Facsimile image form
FIGR	----	Deluxe Video - reserved
FILM	----	LIST FILM - For storing ILBMs with interleaved 8SVX audio
FNTR	IFF Standard	EA IFF 85 reserved for raster font
FNTV	IFF Standard	EA IFF 85 reserved for vector font
FORM	IFF Standard	EA IFF 85 group identifier
FTXT	IFF Standard	EA IFF 85 formatted text form
GRYP	propos	byteplane storage proposal (copyrighted)
GSCR	IFF Standard	EA IFF 85 reserved general music score
GMS	IFF_TP	Gesture and Motion Signal GMS Web Site
GUI	propos	user interface storage proposal (private)
HEAD	IFF_TP	Flow - New Horizons Software
ILBM	EA_IFF	EA IFF 85 raster bitmap form
ILBM.3DCM	----	reserved by Haitex
ILBM.3DPA	----	reserved by Haitex
ILBM.ASDG	----	private ASDG application chunk
ILBM.BHBA	----	private Photon Paint chunk (brushes)
ILBM.BHCP	----	private Photon Paint chunk (screens)
ILBM.BHSM	----	private Photon Paint chunk
ILBM.CLUT	IFF_TP	Color Lookup Table chunk
ILBM.CMYK	IFF_TP	Cyan, Magenta, Yellow, & Black color map (Soft-Logik)
ILBM.CNAM	IFF_TP	Color naming chunk (Soft-Logik)
ILBM.CTBL.DYCP	IFF_TP	Newtek Dynamic HAM color chunks
ILBM.DCTV	----	reserved
ILBM.DGVW	----	private Newtek DigiView chunk
ILBM.DPI	IFF_TP	Dots per inch chunk
ILBM.DPPV	IFF_TP	DPaint perspective chunk (EA)
ILBM.DRNG	IFF_TP	DPaint IV enhanced color cycle chunk (EA)
ILBM.EPSF	IFF_TP	Encapsulated Postscript chunk
ILBM.PCHG	IFF_TP	Line by line palette control information (Sebastiano Vigna)
ILBM.PRVW	propos	A mini duplicate ILBM used for preview (Gary Bonham)
ILBM.TMAP	----	Transparency map (temporarily reserved)
VTAG	propos	Viewmode tags chunk suggestion
ILBM.XBMI	IFF_TP	eXtended BitMap Information (Soft-Logik)
ILBM.XSSL	IFF_TP	Identifier chunk for 3D X-Specs image (Haitex)
IOBJ	----	reserved by Seven Seas Software
IODK	----	reserved for Jean-Marc Porchet at Merging Technologies
ITRF	----	reserved
JMOV	----	reserved for Merging Technologies
LIST	IFF Standard	EA IFF 85 group identifier
MFAX	----	reserved for TKR GmbH & Co.
MIDI	----	Circum Design
MOVI	----	LIST MOVI - private format
MSCX	----	private Music-X format
MSMP	----	temporarily reserved
MTRX	IFF_TP	Numerical data storage (MathVision - Seven Seas)
NSEQ	----	Numerical sequence (Stockhausen GmbH)
OB3D	propos	Proposal for a standard 3D object format
OCMP	IFF Standard	EA IFF 85 reserved computer prop
OCPU	IFF Standard	EA IFF 85 reserved processor prop
OPGM	IFF Standard	EA IFF 85 reserved program prop
OSN	IFF Standard	EA IFF 85 reserved serial num. prop
PGTB	IFF_TP	Program traceback (SAS Institute)
PICS	IFF Standard	EA IFF 85 reserved Macintosh picture
PLBM	IFF Standard	EA IFF 85 reserved obsolete name
PMBC	propos	reserved for Black Belt Systems 91.12.01
PREF	----	Reserved by Commodore for user preferences data, currently private
PREF.AHIG	private	AHI Global preferences
PREF.AHIU	private	AHI Unit preferences
PROP	IFF Standard	EA IFF 85 group identifier
PRSP	IFF_TP	DPaint IV perspective move form (EA)
PTCH	----	Patch file format (SAS Institute)
PTXT	----	temporarily reserved
RGB4	----	4-bit RGB (format not available)
RGBN and RGB8	IFF_TP	RGB image forms, Turbo Silver (Impulse)
RGBX	----	temporarily reserved
ROXN	----	private animation form
SAMP	IFF_TP	Sampled sound format
SC3D	----	private scene format (Sculpt-3D)
SHAK	----	private Shakespeare format
SHO1	----	reserved by Gary Bonham (private)
SHOW	----	reserved by Gary Bonham (private)
SMUS	EA_IFF	EA IFF 85 simple music score form
SPLT	IFF_TP	ASDG's file SPLiTting system
SSRE	----	reserved for Merging Technologies 92.05.04
SWRT	----	unregistered (???)
SYTH	----	SoundQuest Master Librarian MIDI System driver
TCDE	----	reserved by Merging Technologies
TDDD	IFF_TP	3D rendering data, Turbo Silver (Impulse)
TERM	----	unregistered (???)
TMUI	IFF_TP	Toolmaker IFF project file format (ToolMaker V1.19)
TREE	IFF_TP	Storage of arbitrary data structures as trees (or nested lists)
TRKR	propos	TRacKeR style music module format proposal
UNAM	IFF Standard	EA IFF 85 reserved user name prop
USCR	IFF Standard	EA IFF 85 reserved Uhuru score
UVOX	IFF Standard	EA IFF 85 reserved Uhuru Mac voice
VDEO	----	private Deluxe Video format
WORD	IFF_TP	ProWrite document format (New Horizons)
WOWO	----	unregistered (Wordworth)
YAFA	----	unregistered animation format (Wildfire)
YUVN	IFF_TP	For storage of Y:U:V image data (MacroSystems)

(any).HLID

HotLink IDentification (Soft-Logik)

HLID Generic chunk

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

Chunk ID: "HLID" (HotLink IDentification)

Description: This chunk is used by applications that store local copies of HotLink'ed files. When an application reads in a local copy and finds a HLID chunk, the application can check if any changes have been made to the file and get the new changes if any have been made. Also the application can set up a notification on the file, and treat it just like the application subscribed to the file. The format of the chunk is 3 long words. The first two hold the publication ID and the last one holds the publication version number. These are all the entries needed to load a hotlink'ed file from HotLinks.

Example:

                       HLID            ;chunk ID
                       0000000C        ;chunk length (12 bytes)
                       00000001        ;publication ID (part 1)
                       00000005        ;publication ID (part 2)
                       00000002        ;publication version number

(any).INFO

This chunk contains data usually found in a file's .info file.

Proposed by Chris Ludwig 91.12.19.

(any).JUNK

Always ignore this chunk.

This chunk was designed to let garbage data in an IFF file be quickly marked as such. Instead of actually having to remove the garbage chunk, just rename it "JUNK". All IFF readers should ignore "JUNK" chunks. Thanks to David Ellis for this idea. Registered 91.11.

EXEC

Proposed FORM for executable (loadseg-able) code.

(reserved 8/91 by Chris Ludwig)

HEAD

TITLE:  HEAD  (FORM used by Flow - New Horizons Software, Inc.)

IFF FORM / CHUNK DESCRIPTION
============================

Form/Chunk ID:  FORM HEAD, Chunks NEST, TEXT, FSCC

Date Submitted: 03/87
Submitted by:   James Bayless - New Horizons Software, Inc.


FORM
====

FORM ID:  HEAD

FORM Description: 

   FORM HEAD is the file storage format of the Flow idea processor
by New Horizons Software, Inc.  Currently only the TEXT and NEST
chunks are used.  There are plans to incorporate FSCC and some
additional chunks for headers and footers.


CHUNKS
======

CHUNK ID:  NEST

   This chunk consists of only of a word (two byte) value that gives
the new current nesting level of the outline.  The initial nesting level
(outermost level) is zero.  It is necessary to include a NEST chunk only
when the nesting level changes.  Valid changes to the nesting level are
either to decrease the current value by any amount (with a minimum of 0)
or to increase it by one (and not more than one).


CHUNK ID:  TEXT

   This chunk is the actual text of a heading.  Each heading has a TEXT
chunk (even if empty).  The text is not NULL terminated - the chunk
size gives the length of the heading text.


CHUNK ID: FSCC

   This chunk gives the Font/Style/Color changes in the heading from the
most recent TEXT chunk.  It should occur immediately after the TEXT chunk
it modifies.  The format is identical to the FSCC chunk for the IFF
form type 'WORD' (for compatibility), except that only the 'Location'
and 'Style' values are used (i.e., there can be currently only be style
changes in an outline heading).  The structure definition is:

typedef struct {
   UWORD   Location;   /* Char location of change */
   UBYTE   FontNum;    /* Ignored */
   UBYTE   Style;      /* Amiga style bits */
   UBYTE   MiscStyle;  /* Ignored */
   UBYTE   Color;      /* Ignored */
   UWORD   pad;        /* Ignored */
} FSCChange;

   The actual chunk consists of an array of these structures, one entry
for each Style change in the heading text.

PMBC

Reserved for Black Belt Systems 91.12.01

TITLE: PMBC - It's Coming... thoughts?
We have created an entirely new way to store high-color
images, specifically 24 bit accurate images. The storage
format includes the ability to save 8 bit alpha information
(or just a simple 1 bit mask, as appropriate) with
the image.

This method is called PMBC.

PMBC provides compression that ranges from a possible
maximum of thirty to forty times that of IFF 24, including
the alpha channel when the IFF24 does not, to an average
gain of about 16% over IFF24.

PMBC is totally lossless; in that way, it is similar
to IFF24 - that is why I compare it to IFF24, rather
than JPEG, for instance. JPEG provides a much larger
compression, but at the cost of accuracy which is totally
unacceptable in scientific and medical work. As you
may know, one of the board members of Black Belt is
a Neuro-Radiologist... and he doesn't want to hear
about "lossy" compression. :^)

PMBC is available now, commercially, as a Public Interface
load/save module for our Imagemaster and Image Professional
products. We've gotten a fair bit of feedback on this
initial release of it, and it's generally been positive.
Only one user has managed to "break" the compressor
in the sense that the PMBC file is larger than the
equivalent IFF 24 file. We've not yet seen this mythical
file, but we're REAL interested. :^)

Another benefit of PMBC is that the compressed files
are highly ordered when you are talking about the PMBC
file that is created... as a result, when you LHARC
a PMBC file, you get another significant gain. In almost
all cases, a PMBC file is smaller than the same image
file in IFF24 _after_ it's been compressed with LHARC.
Then you can LHARC the PMBC file and pick up even more.
This makes it very attractive for lots of uses.

PMBC is "aware" of various colorspaces; C, M, Y, K
results, greyscale results, and R, G and B results
all compress exceedingly well, eliminating the need
for a separate (like the 8 bit IFF) format for files
in these limited spaces. In fact, in a PMBC file, if
you have a _region_ that is inone of these spaces,
that region will achieve significant;y higher compression
than the rest of the image, resulting in an overall
very high gain in, er, shrunkenness. :^)

All of this is transparent to the user, all they see
is save and load.

The compressor itself is currently written in C, and
isn't by any means optomized for speed; yet it appraches
the speed of a similarly coded IFF24 compressor. We
have high hopes for excellent compression speeds.

Now, here is where we are at. Currently, there is no
decent way to losslessly compress an image other than
IFF24. PMBC can save the user in the region of 16megs
per 100mb partition, which isn't an unreasonable amount
of images for many users - and 16 megs is a lot to
get back "for free" (no loss of data). We're interested
to hear what developers in general think of the compression
and the features I've described here. Those who wish
to experiment with it can do so now, within Imagemaster
or Image Professional.

This is not _currently_ in an IFF wrapper, and PMBC
itself is subject to improvement by us w/o notice until
we are at the point where we are ready to "w5rap it
up", he said punningly.

Until then, the technology will remain proprietary.

Thanks for your time.

Ben Williams

PS: Please, as a favor to me... if you answer this
note, start off with "Ben..." so I'll know it's for
me. BIX is a bit troublesome that way.

Additional documents

Intro to IFF Amiga ILBM Files and Amiga Viewmodes

The IFF (Interchange File Format) for graphic images on the Amiga is called FORM ILBM (InterLeaved BitMap). It follows a standard parsable IFF format.

Sample hex dump of beginning of an ILBM

Important note! You can NOT ever depend on any particular ILBM chunk being at any particular offset into the file! IFF files are composed, in their simplest form, of chunks within a FORM. Each chunk starts starts with a 4-letter chunkID, followed by a 32-bit length of the rest of the chunk. You PARSE IFF files, skipping past unneeded or unknown chunks by seeking their length (+1 if odd length) to the next 4-letter chunkID.

0000: 464F524D 00016418 494C424D 424D4844    FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100    .....@..........
0020: 00000A0B 01400190 43414D47 00000004    .....@..CAMG....
0030: 00000804 434D4150 00000030 001100EE    ....CMAP...0....
0040: EEEE0000 22000055 33333355 55550033    .... ..P000PPP.0
0050: 99885544 77777711 66EE2266 EE6688DD    ..P@ppp.`. `.`..
0060: AAAAAAAA 99EECCCC CCDDAAEE 424F4459    ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF    ..c.......UD*...  etc.

Interpretation:

      'F O R M' length  'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844    FORM..d.ILBMBMHD

       length  WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100    .....@..........

                                             start of C-AMiGa
      TranAspt PagwPagh 'C A M G' length  <- View modes chunk
0020: 00000A0B 01400190 43414D47 00000004    .....@..CAMG....

      Viewmode 'C M A P' length  R g b R  <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001100EE    ....CMAP...0....

      g b R g  b R g b  R g b R  g b R g  <- Rgb's are for reg0 thru regN
0040: EEEE0000 22000055 33333355 55550033    .... ..P000PPP.0

      b R g b  R g b R  g b R g  b R g b
0050: 99885544 77777711 66EE2266 EE6688DD    ..P@ppp.`. `.`..

      R g b R  g b R g  b R g b 'B O D Y'
0060: AAAAAAAA 99EECCCC CCDDAAEE 424F4459    ............BODY

                                             Compacted
       length   start of body data        <- (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF    ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE    ...........Zw.].  etc.

Notes on CAMG Viewmodes:  HIRES=0x8000  LACE=0x4  HAM=0x800  HALFBRITE=0x80

Interpreting ILBMs

ILBM is a fairly simple IFF FORM. All you really need to deal with to extract the image are the following chunks:

(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
 and preserve any copyright information if you rewrite the ILBM)

   BMHD - info about the size, depth, compaction method
          (See interpreted hex dump above)

   CAMG - optional Amiga viewmodes chunk
          Most HAM and HALFBRITE ILBMs should have this chunk.  If no
          CAMG chunk is present, and image is 6 planes deep, assume
          HAM and you'll probably be right.  Some Amiga viewmodes
          flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
        Note that new Amiga 2.0 ILBMs may have more complex 32-bit
        numbers (modeid) stored in the CAMG.  However, the bits
        described above should get you a compatible old viewmode.

   CMAP - RGB values for color registers 0 to n
          (each component left justified in a byte)
        If a deep ILBM (like 12 or 24 planes), there should be no CMAP
        and instead the BODY planes are interpreted as the bits of RGB
        in the order R0...Rn G0...Gn B0...Bn

   BODY - The pixel data, stored in an interleaved fashion as follows:
          (each line individually compacted if BMHD Compression = 1)
             plane 0 scan line 0
             plane 1 scan line 0
             plane 2 scan line 0
             ...
             plane n scan line 0
             plane 0 scan line 1
             plane 1 scan line 1
             etc.

Body Compression

The BODY contains pixel data for the image. Width, Height, and depth (Planes) is specified in the BMHD.

If the BMHD Compression byte is 0, then the scan line data is not compressed. If Compression=1, then each scan line is individually compressed as follows:

More than 2 bytes the same stored as BYTE code value n from -1 to -127 followed by byte to be repeated (-n) + 1 times. Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes of data.

The byte code -128 is a NOP.

Interpreting the Scan Line Data

If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting if necessary, you will have N planes of pixel data. Color register used for each pixel is specified by looking at each pixel thru the planes. I.e., if you have 5 planes, and the bit for a particular pixel is set in planes 0 and 3:

PLANE     4 3 2 1 0
PIXEL     0 1 0 0 1

then that pixel uses color register binary 01001 = 9

The RGB value for each color register is stored in the CMAP chunk of the ILBM, starting with register 0, with each register’s RGB value stored as one byte of R, one byte G, and one byte of B, with each component scaled to 8-bits. (ie. 4-bit Amiga R, G, and B components are each stored in the high nibble of a byte. The low nibble may also contain valid data if the color was stored with 8-bit-per-gun color resolution).

BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.

Hopefully, if the picture is HAM or HALFBRITE, the package that saved it properly saved a CAMG chunk (look at a hex dump of your file with ACSII interpretation - you will see the chunks - they all start with a 4-ASCII- character chunk ID). If the picture is 6 planes deep and has no CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode flags.

HAM pics with a 16-bit CAMG will have the 0x800 bit set in CAMG ViewModes. HALBRITE pics will have the 0x80 bit set.

To transport a HAM or HALFBRITE picture to another machine, you must understand how HAM and HALFBRITE work on the Amiga.

How Amiga HAM mode works

Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB values. In HAM mode, the bits in the two last planes describe an R G or B modification to the color of the previous pixel on the line to create the color of the current pixel. So a 6-plane HAM picture has 4 planes for specifying absolute color pixels giving up to 16 absolute colors which would be specified in the ILBM CMAP chunk. The bits in the last two planes are color modification bits which cause the Amiga, in HAM mode, to take the RGB value of the previous pixel (Hold and), substitute the 4 bits in planes 0-3 for the previous color’s R G or B component (Modify) and display the result for the current pixel. If the first pixel of a scan line is a modification pixel, it modifies the RGB value of the border color (register 0). The color modification bits in the last two planes (planes 4 and 5) are interpreted as follows:

   00 - no modification.  Use planes 0-3 as normal color register index
   10 - hold previous, replacing Blue component with bits from planes 0-3
   01 - hold previous, replacing Red component with bits from planes 0-3
   11 - hold previous. replacing Green component with bits from planes 0-3

How Amiga HALFBRITE mode works

This one is simpler. In HALFBRITE mode, the Amiga interprets the bit in the last plane as HALFBRITE modification. The bits in the other planes are treated as normal color register numbers (RGB values for each color register is specified in the CMAP chunk). If the bit in the last plane is set (1), then that pixel is displayed at half brightness. This can provide up to 64 absolute colors.

Other Notes

Amiga ILBMs images must be a even number of bytes wide. Smaller images (such as brushes) are padded to an even byte width.

ILBMs created with Electronic Arts IBM and Amiga “DPaintII” packages are compatible (though you may have to use a ’.lbm’ filename extension on an IBM). The ILBM graphic files may be transferred between the machines (or between the Amiga and IBM sides your Amiga if you have a CBM Bridgeboard card installed) and loaded into either package.