Copyright (c) Hyperion Entertainment and contributors.
Difference between revisions of "IFF FORM and Chunk Registry"
Jump to navigation
Jump to search
Steven Solie (talk | contribs) |
Steven Solie (talk | contribs) |
||
| (7 intermediate revisions by the same user not shown) | |||
| 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 |
+ | 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 84: | Line 84: | ||
| chunk for 2.0 VERSION string of an IFF file |
| chunk for 2.0 VERSION string of an IFF file |
||
|- |
|- |
||
| − | | [[ |
+ | | [[HLID_IFF_Hotlink_Identification|(any).HLID]] |
| IFF_TP |
| IFF_TP |
||
| HotLink IDentification (Soft-Logik) |
| HotLink IDentification (Soft-Logik) |
||
|- |
|- |
||
| − | | [[ |
+ | | [[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 |
||
|- |
|- |
||
| − | | [[ |
+ | | [[JUNK_IFF_Junk_Data|(any).JUNK]] |
| IFF_TP |
| IFF_TP |
||
| Always ignore this chunk |
| Always ignore this chunk |
||
| Line 151: | Line 151: | ||
| IFF_TP |
| IFF_TP |
||
| 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]] |
||
| + | | 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]] |
| [[ANBM_IFF_Animated_Bitmap|ANBM]] |
||
| Line 168: | 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 510: | Line 518: | ||
| PREF |
| PREF |
||
| ---- |
| ---- |
||
| − | | Reserved by |
+ | | Reserved by the AmigaOS Development Team for user preferences data, currently private |
|- |
|- |
||
| PREF.AHIG |
| PREF.AHIG |
||
| Line 648: | Line 656: | ||
| For storage of Y:U:V image data (MacroSystems) |
| For storage of Y:U:V image data (MacroSystems) |
||
|} |
|} |
||
| − | |||
| − | === (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. |
||
| − | |||
| − | == 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'<-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</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 "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: |
||
| − | |||
| − | <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) |
