home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Frozen Fish 2: PC
/
frozenfish_august_1995.bin
/
bbs
/
d01xx
/
d0185.lha
/
IFF_News
< prev
next >
Wrap
Text File
|
1988-12-13
|
9KB
|
191 lines
IFF News 11/88
==============
Carolyn Scheppner - CBM
FORMS and Chunks not in the original EA IFF specs
=================================================
A "Registry" document has been added to the IFF specs. The Registry
contains lists of all registered chunks and forms, and notes on
additions and changes to the specs of the original EA forms and their
chunks.
Form specifications for registered public third-party forms will
appear in the Third-Party section of the IFF manual. However, due
to the proliferation of application-specific forms, future IFF manuals
might only contain forms in use by more than one company's products.
Creating and Registering New FORMs and Chunks
=============================================
Authors who wish to create new forms or chunks are strongly urged to
- Collaborate with other software authors and CBM on their design
- Choose unique names and reserve them with CBM to avoid conflicts
- Register all new forms and chunks with CBM
Authors should remember special-purpose chunks are usually lost when
an IFF FORM is loaded into another application and saved back out.
The IFF spec states that IFF writers must not write back chunks that
they don't understand because inconsistencies could be created in
the FORM.
The current CBM contact for registration of IFF FORMs and chunks is:
Carolyn Scheppner - CATS/IFF
CBM
1200 Wilson Drive
West Chester, PA. 19380 U.S.A.
UUCP: {allegra|rutgers|uunet}!cbmvax!carolyn
BIX: cscheppner (proposals may be posted/discussed in amiga.dev/iff)
3. The embedded ILBM forms in an ANIM do not adhere to the ILBM spec
and technically should have had a different chunk ID. They do
not contain the required ILBM property BMHD, and instead contain
an ANHD and delta information for changing the previous image.
This inconsistency occurred because the original ANIM concept of
sequential ILBMs was slowly modified, for speed and compactness,
into a single ILBM followed by frames containing encoded animation
changes. After much discussion with the authors and third parties
supporting the ANIM form, it was decided that this inconsistency
must remain for now to avoid breaking existing products.
ILBM Problem Areas
==================
Thanks to John Bittner of the Zuma Group for organizing much of this
information in our amiga.dev/iff conference on BIX.
1. PageWidth and PageHeight - Overscan or Not ?
There are two sets of variables in an ILBM which describe the size
of the picture. The image dimensions are stored in w and h. The
other two variables, pageWidth and pageHeight, have been interpreted
in different ways by the various applications which create ILBMs.
The ILBM spec describes them as follows:
"The size in pixels of the source "page" (any raster device) is stored
in pageWidth and pageHeight, e.g. (320,200) for a low resolution Amiga
display. This information might be used to scale an image or to
automatically set the display format to suit the image. (The image can
be larger than the page.)"
DPaintII stores the normal Amiga screen size in pageWidth and pageHeight,
and the image size (which may be larger) in w and h. Up until now,
we have maintained that this is the correct use of these variables
because it preserves the normal screen dimensions for programs which
wish to clip or scroll larger images in a normal size display.
In addition, storage of the normal screen size makes it possible for
the correct ViewModes to be determined in the absence of an Amiga
ViewModes CAMG chunk.
However, a number of other applications which save overscan images
store the full size of their display ViewPort in the pageWidth and
pageHeight variables, and there seems to be a growing consensus
that this is the correct use of these variables. This approach is
non-Amiga-specific and preserves the artist's intent of the size
raster in which the image was meant to be displayed.
For now, flexible ILBM readers should be prepared to deal with
with either alternative, and must parse CAMG chunks for the
correct Amiga ViewModes. If a CAMG chunk is not present, ViewModes
must be guessed based on the pageWidth and pageHeight. For 1.3
viewmodes, width greater than or equal to 640 can be assumed HIRES,
and height greater than or equal to 400 assumed LACE. These
assumptions may be incorrect for future viewmodes.
2. The Use and Misuse of the CAMG chunk
The "optional" ILBM chunk CAMG holds the Amiga ViewModes for displaying
the image contained in an ILBM.
With the current variety of overscan storage methods, and the introduction
of HAM and HALFBRITE paint packages, it is extremely important that
all Amiga ILBM readers and writers save and parse this chunk. I have
actually seen HALFBRITE ILBMs with NO CAMG chunk! I guess the reader
programs are supposed to see that it's 6 bitplanes and toss a coin to
decide if it's HAM or HALFBRITE. Please store CAMG chunks in all
ILBMs and parse them when reading ILBMs.
When saving and parsing the CAMG chunk, you should be aware that certain
ViewMode bits can cause problems for display programs which use the
CAMG contents directly for Screen or View modes. The following
Amiga Viewmode bits should be masked out when reading or writing
a CAMG chunk: SPRITES, VP_HIDE, GENLOCK_AUDIO, and GENLOCK_VIDEO.
The reserved high word of the CAMG must currently be written as
zero but not assumed to be zero when read.
3. CRNG Color Cycling chunks - Active or Not ?
DPaintII, by default, usually saves CRNG chunks which contain cycle
ranges and are marked as active, regardless of whether a picture is
meant to be cycled. This makes it impossible for a cycling display
program to reliably identify ILBMs which should not be cycled.
Internally, DPaintII interprets a cycle rate <= 36 (RNG_NORATE)
to mark a cycle range as non-active.
4. How many colors should a CMAP contain ?
There seems to be a great deal of variation in the size of the CMAP
stored in HAM ILBMs by various applications. Some store only the
number of absolute colors used in that particular HAM ILBM. Programs
that do this must be really careful about following the IFF spec
rules regarding the padding between odd-sized chunks. Some store the
maximum number of absolute colors in a HAM display (16). Some store
a full palette of 32, and many may store a palette of 64 because the
supplied IFF example code generically uses 1<<bitmap->depth when
calculating the size CMAP to write. ILBM display programs must be
careful to not blindly accept and set the number of color registers
provided in a CMAP.
A Word about Compatibility
==========================
There have been several incidences of new ILBM graphic products
going to market and then being found incompatible with major existing
ILBM graphic software. Before releasing any product which saves IFF
files of any type, please test the compatibility of your files by
loading them into the major existing software products which read
and write files of the same type, and try loading the files created by
other applications. If you do not have access to a large number of
these other products, try to find people who do and arrange file exchanges
and compatibility tests. If your product adapts to PAL screen sizes
or clock rate (important in audio period calculations), arrange for
your product to also be tested on a PAL system.
Be especially careful if you are not using the EA supplied IFF reading,
writing, and compression routines. This can sometimes lead to the creation
of subtly out-of-spec IFF files which are rejected by products which use
the IFF code supplied by EA. Some examples would be odd length chunks
not followed by a pad byte or a reader not designed to handle pad bytes.
Another would be a badly compressed ILBM. The EA compresser is smart and
does not encode a scan line if encoding would result in more bytes. The EA
decompressor expects a smartly compressed file, and will return an error if
handed an encoded line more than one control byte larger than destination
scan line. If you are not using the EA IFF code, please make sure that your
code follows all of the rules.
Future IFF
==========
We hope to see a shared run-time iff.library sometime this year, through
a coordinated effort between CBM and third-parties. Core IFF reading and
writing routines will probably be in an IFF.library, with form-specific
routines in separate modules or libraries. An IFF.library would take a
lot of the code burden off of applications and would be especially useful
for programmers using languages other than C.