Copyright (c) Hyperion Entertainment and contributors.

Difference between revisions of "IFF FORM and Chunk Registry"

From AmigaOS Documentation Wiki
Jump to navigation Jump to search
 
(30 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== IFF FORM and Chunk Registry ==
  
== IFF FORM and Chunk Registry ==
   
−
Last Updated: May 10, 2012
 +
'''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.
  
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.
Line 7: Line 7:
 
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.
  
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 [http://www.amigaos.net| AmigaOS web site] contact form.
 +
New chunks and FORMS should be registered with the AmigaOS development team. Please make all submissions via the [http://www.amigaos.net AmigaOS web site] contact form.
   
 
== Developing New IFF FORMs and Chunks ==
  
== Developing New IFF FORMs and Chunks ==
Line 68: Line 68:
 
| EA IFF 85 generic author chunk
  
| EA IFF 85 generic author chunk
 
|-
  
|-
−
| (any).CHRS
 +
| [[FTXT_IFF_Formatted_Text#Data_Chunk_CHRS|(any).CHRS]]
 
| [[IFF_Standard|IFF Standard]]
  
| [[IFF_Standard|IFF Standard]]
 
| EA IFF 85 generic character string chunk
  
| EA IFF 85 generic character string chunk
 
|-
  
|-
−
| [[#(any).CSET|(any).CSET]]
 +
| [[CSET_IFF_Text_Character_Set|(any).CSET]]
 
| IFF_TP
  
| IFF_TP
 
| chunk for specifying character set
  
| chunk for specifying character set
Line 80: Line 80:
 
| Private ASDG global chunk
  
| Private ASDG global chunk
 
|-
  
|-
−
| [[#(any).FVER|(any).FVER]]
 +
| [[FVER_IFF_Version_String|(any).FVER]]
 
| IFF_TP
  
| IFF_TP
 
| chunk for 2.0 VERSION string of an IFF file
  
| chunk for 2.0 VERSION string of an IFF file
 
|-
  
|-
−
| [[#(any).HLID|(any).HLID]]
 +
| [[HLID_IFF_Hotlink_Identification|(any).HLID]]
 
| IFF_TP
  
| IFF_TP
 
| HotLink IDentification (Soft-Logik)
  
| HotLink IDentification (Soft-Logik)
 
|-
  
|-
−
| [[#(any).INFO|(any).INFO]]
 +
| [[INFO_IFF_Icon_Information|(any).INFO]]
 
| propos
  
| propos
 
| This chunk contains data usually found in a file's .info file
  
| This chunk contains data usually found in a file's .info file
 
|-
  
|-
−
| [[#(any).JUNK|(any).JUNK]]
 +
| [[JUNK_IFF_Junk_Data|(any).JUNK]]
 
| IFF_TP
  
| IFF_TP
 
| Always ignore this chunk
  
| Always ignore this chunk
  +
|-
  +
| [[UTF8_IFF_UTF-8_Unicode_Text|(any).UTF8]]
  +
| IFF_TP
  +
| UTF-8 character text
 
|-
  
|-
 
| (any).NAME
  
| (any).NAME
Line 120: Line 124:
 
| Looping chunks for 8SVX form
  
| Looping chunks for 8SVX form
 
|-
  
|-
−
| [[#ACBM|ACBM]]
 +
| [[ACBM_IFF_Amiga_Continuous_Bitmap|ACBM]]
 
| IFF_TP
  
| IFF_TP
 
| Amiga Contiguous Bitmap form
  
| Amiga Contiguous Bitmap form
Line 148: Line 152:
 
| Audio 1-32 bit samples (Mac, Apple II, Synthia Pro)
  
| Audio 1-32 bit samples (Mac, Apple II, Synthia Pro)
 
|-
  
|-
  +
| [[AIFF_IFF_Audio_Samples#AIFF|AIFF.COMM]]
−
| [[#ANBM|ANBM]]
  
  +
| IFF_TP
  +
| Describes fundamental parameters of the sampled sound
  +
|-
  +
| [[AIFF_IFF_Audio_Samples#AIFF|AIFF.SSND]]
  +
| IFF_TP
  +
| Contains the actual sample frames
  +
|-
  +
| [[ANBM_IFF_Animated_Bitmap|ANBM]]
 
| IFF_TP
  
| IFF_TP
 
| Animated bitmap form (Framer, Deluxe Video)
  
| Animated bitmap form (Framer, Deluxe Video)
Line 164: Line 176:
 
| Stereo (3D) animations
  
| Stereo (3D) animations
 
|-
  
|-
−
| ANIM.op7
 +
| [[ANIM_IFF_CEL_Animations#ANIM.op7|ANIM.op7]]
−
| ----
 +
| IFF_TP
  +
| Maximum playback speed and acceptable packing rates
−
| unregistered (???)
  
 
|-
  
|-
 
| [[ANIM_IFF_CEL_Animations#ANIM.op8|ANIM.op8]]
  
| [[ANIM_IFF_CEL_Animations#ANIM.op8|ANIM.op8]]
 
| IFF_TP
  
| IFF_TP
  +
| Maximum playback speed and acceptable packing rates. Easier to use than ANIM.op7
−
| -
  
 
|-
  
|-
 
| ARC
  
| ARC
Line 260: Line 272:
 
| reserved by Jim Bayless, 12/90
  
| reserved by Jim Bayless, 12/90
 
|-
  
|-
−
| [[#DTYP|DTYP]]
 +
| [[DTYP_IFF_DataType_Identification|DTYP]]
 
| IFF_TP
  
| IFF_TP
 
| DataTypes identification
  
| DataTypes identification
 
|-
  
|-
−
| [[#EXEC|EXEC]]
 +
| [[EXEC_IFF_Executable_Code|EXEC]]
 
| propos
  
| propos
 
| Proposed form for executable (loadseg-able) code
  
| Proposed form for executable (loadseg-able) code
Line 324: Line 336:
 
| user interface storage proposal (private)
  
| user interface storage proposal (private)
 
|-
  
|-
−
| [[#HEAD|HEAD]]
 +
| [[HEAD_IFF_Flow_Idea_Processor_Format|HEAD]]
 
| IFF_TP
  
| IFF_TP
 
| Flow - New Horizons Software
  
| Flow - New Horizons Software
Line 500: Line 512:
 
| EA IFF 85 reserved obsolete name
  
| EA IFF 85 reserved obsolete name
 
|-
  
|-
−
| [[#PMBC|PMBC]]
 +
| [[PMBC_IFF_High-color_Image_Format|PMBC]]
 
| propos
  
| propos
 
| reserved for Black Belt Systems 91.12.01
  
| reserved for Black Belt Systems 91.12.01
Line 506: Line 518:
 
| PREF
  
| PREF
 
| ----
  
| ----
−
| Reserved by Commodore for user preferences data, currently private
 +
| Reserved by the AmigaOS Development Team for user preferences data, currently private
 
|-
  
|-
 
| PREF.AHIG
  
| PREF.AHIG
Line 520: Line 532:
 
| EA IFF 85 group identifier
  
| EA IFF 85 group identifier
 
|-
  
|-
−
| [[#PRSP|PRSP]]
 +
| [[PRSP_IFF_Perspective_Move|PRSP]]
 
| IFF_TP
  
| IFF_TP
 
| DPaint IV perspective move form (EA)
  
| DPaint IV perspective move form (EA)
Line 644: Line 656:
 
| For storage of Y:U:V image data (MacroSystems)
  
| For storage of Y:U:V image data (MacroSystems)
 
|}
  
|}
−  
−
=== (any).CSET ===
  
−  
−
Chunk for specifying character set.
  
−  
−
Registered by Martin Taillefer.
  
−  
−
A chunk for use in any FORM, to specify character set used for text in FORM.
  
−  
−
<syntaxhighlight>
  
−
struct CSet {
  
−
LONG CodeSet; /* 0=ECMA Latin 1 (std Amiga charset) */
  
−
/* AmigaOS development team will define additional values */
  
−
LONG Reserved[7];
  
−
}
  
−
</syntaxhighlight>
  
−  
−
=== (any).FVER ===
  
−  
−
Chunk for 2.0 VERSION string of an IFF file.
  
−  
−
Registered by Martin Taillefer.
  
−  
−
A chunk for use in any FORM, to contain standard 2.0 version string.
  
−  
−
$VER: name ver.rev
  
−  
−
where "name" is the name or identifier of the file and ver.rev is a version/revision such as 53.1
  
−  
−
Example:
  
−  
−
$VER: workbench.catalog 53.42
  
−  
−  
−
=== (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.
  
−  
−
=== ACBM ===
  
−  
−
<pre>
  
−
Amiga Contiguous Bitmap form
  
−  
−
IFF FORM / CHUNK DESCRIPTION
  
−
============================
  
−  
−
Form/Chunk ID: FORM ACBM (Amiga Contiguous BitMap)
  
−
Chunk ABIT (Amiga BITplanes)
  
−  
−
Date Submitted: 05/29/86
  
−
Submitted by: Carolyn Scheppner CBM
  
−  
−  
−
FORM
  
−
====
  
−  
−
FORM ID: ACBM (Amiga Contiguous BitMap)
  
−  
−
FORM Description:
 
−  
−
FORM ACBM has the same format as FORM ILBM except the normal BODY
  
−
chunk (InterLeaved BitMap) is replaced by an ABIT chunk (Amiga BITplanes).
 
−  
−
FORM Purpose:
  
−  
−
To enable faster loading/saving of screens, especially from Basic,
  
−
while retaining the flexibility and portability of IFF format files.
  
−  
−  
−
CHUNKS
  
−
======
  
−  
−
Chunk ID: ABIT (Amiga BITplanes)
  
−  
−
Chunk Description:
  
−  
−
The ABIT chunk contains contiguous bitplane data. The chunk contains
  
−
sequential data for bitplane 0 through bitplane n.
  
−  
−
Chunk Purpose:
  
−  
−
To enable loading/storing of bitmaps with one DOS Read/Write per
  
−
bitplane. Significant speed increases are realized when loading/saving
  
−
screens from Basic.
  
−  
−  
−
SUPPORTING SOFTWARE
  
−
===================
  
−  
−
(Public Domain, available soon via Fish PD disk, various networks)
  
−  
−
LoadILBM-SaveACBM (AmigaBasic)
  
−
Loads and displays an IFF ILBM pic file (Graphicraft, DPaint, Images).
  
−
Optionally saves the screen in ACBM format.
  
−  
−
LoadACBM (AmigaBasic)
  
−
Loads and display an ACBM format pic file.
  
−  
−
SaveILBM (AmigaBasic)
  
−
Saves a demo screen as an ILBM pic file which can be loaded into
  
−
Graphicraft, DPaint, Images.</pre>
  
−  
−
=== ANBM ===
  
−  
−
<pre>
  
−
Animated bitmap form (Framer, Deluxe Video)
  
−  
−
TITLE: Form ANBM (animated bitmap form used by Framer, Deluxe Video)
 
−
 
−
(note from the author)
 
−
 
−
The format was designed for simplicity at a time when the IFF
 
−
standard was very new and strange to us all. It was not designed
 
−
to be a general purpose animation format. It was intended to be
 
−
a private format for use by DVideo, with the hope that a more
 
−
powerful format would emerge as the Amiga became more popular.
 
−
 
−
I hope you will publish this format so that other formats will
 
−
not inadvertantly conflict with it.
 
−
 
−
PURPOSE: To define simple animated bitmaps for use in DeluxeVideo.
 
−
 
−
In Deluxe Video objects appear and move in the foreground
 
−
with a picture in the background. Objects are &quot;small&quot; bitmaps
 
−
usually saved as brushes from DeluxePaint and pictures are large
 
−
full screen bitmaps saved as files from DeluxePaint.
 
−
 
−
Two new chunk headers are defined: ANBM and FSQN.
 
−
 
−
An animated bitmap (ANBM) is a series of bitmaps of the same
 
−
size and depth. Each bitmap in the series is called a frame and
 
−
is labeled by a character, 'a b c ...' in the order they
 
−
appear in the file.
 
−
 
−
The frame sequence chunk (FSQN) specifies the playback
 
−
sequence of the individual bitmaps to achieve animation.
 
−
FSQN_CYCLE and FSQN_TOFRO specify two algorithmic sequences. If
 
−
neither of these bits is set, an arbitrary sequence can be used
 
−
instead.
 
−
 
−
 
−
ANBM - identifies this file as an animated bitmap
 
−
.FSQN - playback sequence information
 
−
.LIST ILBM - LIST allows following ILBMs to share properties
 
−
..PROP ILBM - properties follow
 
−
...BMHD - bitmap header defines common size and depth
 
−
...CMAP - colormap defines common colors
 
−
..FORM ILBM - first frame follows
 
−
..BODY - the first frame
 
−
. - FORM ILBM and BODY for each remaining frame
 
−
.
 
−
.
 
−
 
−
Chunk Description:
 
−
 
−
The ANBM chunk identifes this file as an animated bitmap
 
−
 
−
Chunk Spec:
 
−
 
−
#define ANBM MakeID('A','N','B','M')
 
−
 
−
Disk record:
 
−
 
−
none
 
−
 
−
Chunk Description:
 
−
 
−
The FSQN chunk specifies the frame playback sequence
 
−
 
−
Chunk Spec:
 
−
 
−
#define FSQN MakeID('F','S','Q','N')
 
−
 
−
/* Flags */
 
−
#define FSQN_CYCLE 0x0001 /* Ignore sequence, cycle a,b,..y,z,a,b,.. */
 
−
#define FSQN_TOFRO 0x0002 /* Ignore sequence, cycle a,b,..y,z,y,..a,b, */
 
−
/* Disk record */
 
−
typedef struct {
 
−
WORD numframes; /* Number of frames in the sequence */
 
−
LONG dt; /* Nominal time between frames in jiffies */
 
−
WORDBITS flags; /* Bits modify behavior of the animation */
 
−
UBYTE sequence[80]; /* string of 'a'..'z' specifying sequence */
 
−
} FrameSeqn;
 
−
 
−
 
−
Supporting Software:
 
−
 
−
DeluxeVideo by Mike Posehn and Tom Case for Electronic Arts
 
−
 
−
 
−
Thanks,
 
−
Mike Posehn
  
−
</pre>
  
−  
−  
−
=== DTYP ===
  
−  
−
DataTypes Identification
  
−  
−
<pre>
  
−
#ifndef LIBRARIES_DATATYPES_H
  
−
#define LIBRARIES_DATATYPES_H
  
−
/*
  
−
** $Id: datatypes.h,v 39.1 91/12/13 10:17:52 davidj Exp $
  
−
**
  
−
** (C) Copyright 1991-1999 Amiga, Inc.
  
−
** All Rights Reserved
  
−
*/
  
−
#ifndef EXEC_TYPES_H
  
−
#include <exec/types.h>
  
−
#endif
  
−
#ifndef EXEC_LISTS_H
  
−
#include <exec/lists.h>
  
−
#endif
  
−
#ifndef EXEC_NODES_H
  
−
#include <exec/nodes.h>
  
−
#endif
  
−
#ifndef EXEC_LIBRARIES_H
  
−
#include <exec/libraries.h>
  
−
#endif
  
−
#ifndef LIBRARIES_IFFPARSE_H
  
−
#include <libraries/iffparse.h>
  
−
#endif
  
−  
−
/*****************************************************************************/
  
−  
−
#define ID_DTYP MAKE_ID('D','T','Y','P')
  
−  
−
/*****************************************************************************/
  
−  
−
#define ID_DTHD MAKE_ID('D','T','H','D')
  
−  
−
struct DataTypeHeader
  
−
{
  
−
STRPTR dth_Name; /* Descriptive name of the data type */
  
−
STRPTR dth_BaseName; /* Base name of the data type */
  
−
STRPTR dth_Pattern; /* Match pattern for file name. */
  
−
WORD *dth_Mask; /* Comparision mask */
  
−
ULONG dth_GroupID; /* Group that the DataType is in */
  
−
ULONG dth_ID; /* ID for DataType (same as IFF FORM type) */
  
−
WORD dth_MaskLen; /* Length of comparision mask */
  
−
WORD dth_Pad; /* Unused at present (must be 0) */
  
−
UWORD dth_Flags; /* Flags */
  
−
UWORD dth_Priority; /* Priority */
  
−
};
  
−  
−
#define DTHSIZE sizeof(struct DataTypeHeader)
  
−  
−
/*****************************************************************************/
  
−  
−
/* Basic file type */
  
−
#define DTF_TYPE_MASK 0x000F
  
−
#define DTF_BINARY 0x0000
  
−
#define DTF_ASCII 0x0001
  
−
#define DTF_IFF 0x0002
  
−
#define DTF_MISC 0x0003
  
−  
−
/* Set if case is important */
  
−
#define DTF_CASE 0x0010
  
−  
−
/* Reserved for system use */
  
−
#define DTF_SYSTEM1 0x1000
  
−  
−
/*****************************************************************************
  
−
*
  
−
* GROUP ID and ID
  
−
*
  
−
* This is used for filtering out objects that you don't want. For
  
−
* example, you could make a filter for the ASL file requester so
  
−
* that it only showed the files that were pictures, or even to
  
−
* narrow it down to only show files that were ILBM pictures.
  
−
*
  
−
* Note that the Group ID's are in lower case, and always the first
  
−
* four characters of the word.
  
−
*
  
−
* For ID's; If it is an IFF file, then the ID is the same as the
  
−
* FORM type. If it isn't an IFF file, then the ID would be the
  
−
* first four characters of name for the file type.
  
−
*
  
−
*****************************************************************************/
  
−  
−
/* System file, such as; directory, executable, library, device, font, etc. */
  
−
#define GID_SYSTEM MAKE_ID ('s','y','s','t')
  
−  
−
/* Formatted or unformatted text */
  
−
#define GID_TEXT MAKE_ID ('t','e','x','t')
  
−  
−
/* Formatted text with graphics or other DataTypes */
  
−
#define GID_DOCUMENT MAKE_ID ('d','o','c','u')
  
−  
−
/* Sound */
  
−
#define GID_SOUND MAKE_ID ('s','o','u','n')
  
−  
−
/* Musical instruments used for musical scores */
  
−
#define GID_INSTRUMENT MAKE_ID ('i','n','s','t')
  
−  
−
/* Musical score */
  
−
#define GID_MUSIC MAKE_ID ('m','u','s','i')
  
−  
−
/* Still picture */
  
−
#define GID_PICTURE MAKE_ID ('p','i','c','t')
  
−  
−
/* Animated picture */
  
−
#define GID_ANIMATION MAKE_ID ('a','n','i','m')
  
−  
−
/* Animation with audio track */
  
−
#define GID_MOVIE MAKE_ID ('m','o','v','i')
  
−  
−
/*****************************************************************************/
  
−  
−
/* A DTCD chunk contains an embedded executable that can be loaded
  
−
* with InternalLoadSeg. */
  
−
#define ID_CODE MAKE_ID('D','T','C','D')
  
−  
−
/* DataTypes comparision hook context (Read-Only). This is the
  
−
* argument that is passed to a custom comparision routine. */
  
−
struct DTHookContext
  
−
{
  
−
/* Libraries that are already opened for your use */
  
−
struct Library *dthc_SysBase;
  
−
struct Library *dthc_DOSBase;
  
−
struct Library *dthc_IFFParseBase;
  
−
struct Library *dthc_UtilityBase;
  
−  
−
/* File context */
  
−
BPTR dthc_Lock;
  
−
struct FileInfoBlock *dthc_FIB;
  
−
BPTR dthc_FileHandle;
  
−
struct IFFHandle *dthc_IFF;
  
−
STRPTR dthc_Buffer; /* Buffer */
  
−
ULONG dthc_BufferLength; /* Length of the buffer */
  
−
};
  
−  
−
/*****************************************************************************/
  
−  
−
#define ID_DTTL MAKE_ID('D','T','T','L')
  
−  
−
struct Tool
  
−
{
  
−
UWORD tn_Which; /* Which tool is this */
  
−
UWORD tn_Flags; /* Flags */
  
−
STRPTR tn_Program; /* Application to use */
  
−
};
  
−  
−
#define TSIZE sizeof(struct Tool)
  
−  
−
/* defines for tn_Which */
  
−
#define TW_INFO 1
  
−
#define TW_BROWSE 2
  
−
#define TW_EDIT 3
  
−
#define TW_PRINT 4
  
−
#define TW_MAIL 5
  
−  
−
/* defines for tn_Flags */
  
−
#define TF_LAUNCH_MASK 0x000F
  
−
#define TF_SHELL 0x0001
  
−
#define TF_WORKBENCH 0x0002
  
−
#define TF_RX 0x0003
  
−  
−
/*****************************************************************************/
  
−  
−
#ifndef DATATYPE
  
−
#define DATATYPE
  
−
struct DataType
  
−
{
  
−
struct Node dtn_Node1; /* Reserved for system use */
  
−
struct Node dtn_Node2; /* Reserved for system use */
  
−
struct DataTypeHeader *dtn_Header; /* Pointer to the DataTypeHeader */
  
−
struct List dtn_ToolList; /* List of tool nodes */
  
−
STRPTR dtn_FunctionName; /* Name of comparision routine */
  
−
ULONG dtn_Length; /* Length of the memory block */
  
−
};
  
−
#endif
  
−  
−
#define DTNSIZE sizeof(struct DataType)
  
−  
−
/*****************************************************************************/
  
−  
−
struct ToolNode
  
−
{
  
−
struct Node tn_Node; /* Embedded node */
  
−
struct Tool tn_Tool; /* Embedded tool */
  
−
ULONG tn_Length; /* Length of the memory block */
  
−
};
  
−  
−
#define TNSIZE sizeof(struct ToolNode)
  
−  
−
/*****************************************************************************/
  
−  
−
#ifndef ID_NAME
  
−
#define ID_NAME MAKE_ID('N','A','M','E')
  
−
#endif
  
−  
−
#endif /* LIBRARIES_DATATYPES_H */
  
−
</pre>
  
−  
−
=== EXEC ===
  
−  
−
<pre>
  
−
Proposed FORM for executable (loadseg-able) code.
  
−  
−
(reserved 8/91 by Chris Ludwig)
  
−
</pre>
  
−  
−
=== HEAD ===
  
−  
−
<pre>
  
−
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.</pre>
  
−  
−
=== PMBC ===
  
−  
−
<pre>
  
−
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.
  
−
</pre>
  
−  
−
=== PRSP ===
  
−  
−
DPaint IV perspective move.
  
−  
−
<pre>
  
−
/* -----------------------------------------------------------------------
 
−
IFF Information:
  
−
PRSP ::= &quot;FORM&quot; # {&quot;PSRP&quot; MOVE }
  
−
MOVE ::= &quot;MOVE&quot; # { MoveState }
  
−
* ---------------------------------------------------------------------- */
  
−
typedef struct {
  
−
BYTE reserved; /* initialize to 0 */
  
−
BYTE moveDir; /* 0 = from point 1 = to point */
  
−
BYTE recordDir; /* 0 = FORWARD, 1 = STILL, 2 = BACKWARD */
  
−
BYTE rotationType; /* 0 = SCREEN_RELATIVE, 1 = BRUSH_RELATIVE */
  
−
BYTE translationType; /* 0 = SCREEN_RELATIVE, 1 = BRUSH_RELATIVE */
  
−
BYTE cyclic; /* 0 = NO, 1 = YES */
  
−
SHORT distance[3]; /* x,y,z distance displacement */
  
−
SHORT angle[3]; /* x,y,z rotation angles */
  
−
SHORT nframes; /* number of frames to move */
  
−
SHORT easeout; /* number of frames to ease out */
  
−
SHORT easein; /* number of frames to ease in */
  
−
} MoveState;
  
−
</pre>
  
−  
−
== 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.
  
−  
−
<pre>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.</pre>
  
−
Interpretation:
  
−  
−
<pre> 'F O R M' length 'I L B M''B M H D'&lt;-start of BitMapHeader chunk
  
−
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
  
−  
−
length WideHigh XorgYorg PlMkCoPd &lt;- Planes Mask Compression Pad
  
−
0010: 00000014 01400190 00000000 06000100 .....@..........
  
−  
−
start of C-AMiGa
  
−
TranAspt PagwPagh 'C A M G' length &lt;- View modes chunk
  
−
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
  
−  
−
Viewmode 'C M A P' length R g b R &lt;- 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 &lt;- 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 &lt;- (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</pre>
  
−
=== Interpreting ILBMs ===
  
−  
−
ILBM is a fairly simple IFF FORM. All you really need to deal with to extract the image are the following chunks:
  
−  
−
<pre>(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.</pre>
  
−
=== 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:
  
−  
−
<pre>PLANE 4 3 2 1 0
  
−
PIXEL 0 1 0 0 1</pre>
  
−
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 &quot;CAMG&quot; 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:
  
−  
−
<pre> 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</pre>
  
−
==== 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.
  

Latest revision as of 20:49, 17 April 2014

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)
AIFF.COMM IFF_TP Describes fundamental parameters of the sampled sound
AIFF.SSND IFF_TP Contains the actual sample frames
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 IFF_TP Maximum playback speed and acceptable packing rates
ANIM.op8 IFF_TP Maximum playback speed and acceptable packing rates. Easier to use than ANIM.op7
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 the AmigaOS Development Team 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)
Retrieved from "http://wiki.amigaos.net/w/index.php?title=IFF_FORM_and_Chunk_Registry&oldid=7527"