Conference hydra::amiga_v1

    A version of the IFF specs from about 2 years ago can be found at
    
    	TAPE::USER1:[AMIGA.FF64]*.*
    
    Some new chunk types have been added since then for music and
    animation, but these documents will give you a good idea of what's
    going on with images.  Note that AmigaDOS expects lines to end in
    a linefeed, while MS-DOS ends lines with carriage return-linefeed,
    so you may have to run these files through an editor (like SEDT)
    after unpacking the archive.
    
    I think the CAMG chunk is Amiga-specific stuff.  LACE undoubtedly
    means "interlace on," and HIRES probably refers to 640x400 video
    mode.  HALFBRITE is a feature of the graphics processor in most
    Amigas which cuts the intensity of a pixel in half.
    
    Wes

I have the latest IFF specs at home (Nov 1988) but I didn't think it
was OK for me to upload them.

If it is, I'll do it.

John

	Thanx for pointers so far.

	With help from SEDT (thanks Anker) I remapped line feeds to
	return line feeds and have looked through IFF.85 and ILBM. from
	FF64.

	Some clarity is now present, I am still confused over a few things.

	Here is my answers to my questions and what still remains:

	BMHD
	----
	
	Mask indicates an extra bit plane present in the body used for
	transparent colour/lasoo effects. 

	This means that there are (Nplanes + 1) planes of data in the
	BODY if mask is true. This may explain some of my problems!

	Padding - no purpose.

	Tran - transparency - used to indictae the colour map entry for
	transparent colour.

	Aspect - two bytes width and height so 2571. = 10./11. and
	5131. = 20./11.

	CAMG
	----

	Not that much wiser here. I interpreted LACE and HIRES as just that
	but am not sure if that refers to a characteristic of the display
	or the IFF file or if I need to take note of it. ie is it used
	by some software to set the display to particular modes or to 
	map the data in a different way.

	CRNG
	----

	What is colour range stepping - doesn't mean anything to me.

	DPPV
	----

	Couldn't find any reference to this chunk at all.

	Sorry if I'm being a bit slow but some of the bits are difficult
	to understand from the outside of the AMIGA world.

	Dave B

Re: .2

>I have the latest IFF specs at home (Nov 1988) but I didn't think it
>was OK for me to upload them.

Yes, the IFF specs and the Electric Arts code to read and write IFF
is public domain.  That is why Fred Fish has been allowed to redistribute
the IFF disk.

Re: .3

>	Aspect - two bytes width and height so 2571. = 10./11. and
>	5131. = 20./11.

This is the aspect ratio of an Amiga using the default Commodore monitors.
The Amiga does have 1:1 pixels even in the resolutions that you would think
would be 1:1.  The pixels are 10% taller than they are wide.

You should get the following aspect ratios for the follow screen resolutions:

	10:11	for 320 by 200 or 640 by 400 Amiga screens
	5:11	for 320 by 400 Amiga Screens
	20:11	for 620:200 Amiga Screens

You could use the aspect ratio information to reproduce the picture exactly
as it appears on an Amiga and 1080 monitor.  In practice, don't bother.

>	CAMG
>	----
>
>	Not that much wiser here. I interpreted LACE and HIRES as just that

The is the Commodore AMiGa hunk.  It give the flags you need to pass to
the Amiga operating system to have it create a screen with proper resolution
and hardware decoding of the bits making up the picture.

HIRES means use 640 pixels across instead of 320.

LACE means use 400 lines instead of 200.

HALFBRITE uses 32 color registers to do the work of 64.  The first five
bitplanes give you a color register number.  The sixth bitplane, if it
has a one bit for the pixel, means cut the intensity of the RGB values in
the color register in half for that pixel.

HAM encodes a twelve bitplane picture into six bitplanes.  Each pixel is
encoded as a function of the pixel before it.  Two bits are used to
encode a "command" (pick a color register or modify a color registers
red, green, or blue component).  The other four bits are either a color
register number or a new R, G, or B value.  This display mode allows
4096 colors to be displayed simultaneously on screen.  This mode is
excellent for digitized, real world pictures (which have smooth color
transitions).

>	CRNG
>	----
>
>	What is colour range stepping - doesn't mean anything to me.

Amiga paint programs have traditionally supported a limited form of
animation based on changing color registers on the fly (color cycling).
For example, draw the body of a bee.  Draw in the wings using color register
5.  Draw the wings again in a slightly different position using color register
6.  Set color register 5 to a nice color for the wings.  Set color register
6 to the background color.  Now, swap the values of registers 5 and 6
every tenth of a second.  The wings of the bee are buzzing!  If you just
ignore this chunk, nothing bad will happen to you.  Most IFF display
utilities (as opposed to paint programs) ignore this information.

>	DPPV
>	----
>
>	Couldn't find any reference to this chunk at all.

I don't know off hand.  In general, IFF is designed so you can skip
a chunk without knowing what is in the chunk.  The general philosophy
is that you should quietly skip over anything you don't understand:
it may be private data not intended for you.  For example, IFF animation
files start out with a ILBM of the first frame of the video.  A display
program for static pictures can find the first frame of the video even
if it doesn't understand the compressed deltas that follow it.

I think DPPV is a "Deluxe Paint Private" hunk.

I'll upload the IFF disk tonight. ARC, WARP, ZOO???

I guess ZOO is probably the best...

John

Thanks Randy (.4, .5)

I look forward to the later specs, I'll keep an eye open for them and will get
hold of a ZOO reader for MSDOS (they're around on CSCMAS I think).

I'll ignore CRNG with a clear concience (what spelling?!?!?). I was happily
ignoring HIRES and LACE and it seems that they are indeed needed by the display
not the ILBM reader (I just hope the don't mean anything to the BODY format!).

HALFBRITE and HAM are challenges. HALFBRITE is relatively easy as I just treat
the 6th bit as doubling the colour map (ie 64 colours). Just need to be sure I 
fill in the first 1/2 of the map with half brightness versions of the colour 
map supplied (and put that in the second half of the map).

HAM would be a nice challenge but I don't have any HAM encoded images to play
with. If there are any around I'd welcome a pointer (couldn't find any on
TAPE::).



<I think DPPV is a "Deluxe Paint Private" hunk.

<I'll upload the IFF disk tonight. ARC, WARP, ZOO???

<I guess ZOO is probably the best...

Reread FF64 and there is an explanation of DPPV, it is indeed Delux Paint and
is used to "describe the perspective state of a DPaint ILBM"

Guess I can happily ignore it!

In general I was reasonably happy ignoring chuncks - I'm just nosy and like to
be sure what I ignore is worth ignoring.

I'm going to have a another pass through my coding this weekend and see what I
can do with my new knowledge. I think the use of MASK is probably the biggest
confusion because I ignored it and counted NPlanes as being the total planes.
I'll see what counting MASK as an extra does.

Thanks to all

Dave B

The November 1988 IFF dosk is at:

	WJG::AMIGA:IFF0-39.WRP  and
	WJG::AMIGA:IFF40-79.WRP

It's WARP format, not ZOO.  This [IFF} disk is 90 something percent full.
I couldn't figure out how to make ZOO do an entire directory tree at once
and there are lots of subdirectories on this disk. Besides that would have made
one HUGE file do download for everyone...


John

	Well, made some progress at the weekend. Most of my problems were
	related to large images that meant I went over the 64K barrier. Once
	I improved the memory handling all was well.

	I also understand the MASK flag a lot better. Its only when its 1
	that an extra plane of data is present. Since in my images it was 
	either 0 (no mask) or 2 (transparent data present) I didn't have a
	problem - but I now check for it and hope I act correctly.

	Unfortunately the latest specs in WARP format don't seem readable
	outside of AMIGA land, certainly not in the PC world. If there is a 
	copy in ZOO or ARC that would be useful.

	Only real outstanding bits I have is that:

	o I haven't been able to test against HAM due to lack of images

	o The few I have with CAMG flag INTERLACE set all come out with
	  the smallest pixel as a solid 2*2 block. It almost looks as if the
	  display is set to a hiher resolution than the image has pixels so
	  the image has been "doubled up" to stop it getting too small. ie
	  the original was 200 lines, screen set to 400 so duplicate every
	  line( same for columns). Is this likely?

	Dave B

First, I think I should apologize and explain.

Sorry.
(No that the hard part's over!)

I recieved the IFF disk from CBM but never did much more than a click-on-the-
icons look at it. It came with a manual (about 1/2" thick, 8 1/2 x 11).

After uploading it I decided to poke around a bit more. I then discovered
that the spec itself is not on the disk! The READ.ME file says that this
release grew too large to fit on a floppy along with the example code. It also
says you can order a disk of it [the spec]  for $20 (?). I will probably
order the online copy.

In the mean time, I can put the whole floppy up in ZOO format if you'ld like.
It still has some good code examples. I suppose I could even photocopy the
ILBM section and mail it to you (legal?).

I used WARP cause:  	The whole floppy was full and a ZOO would be huge.
			I couldn't get ZOO to do subdirectories.

I think #2 above was because I have a pre-V2.00 copy of ZOO and it 
doesn't work for subdirectories correctly (ZOO a// IFF.ZOO DF0:  said
"/" is invalid)

John

	
	No apologies needed (.10), I'm an interloper here into Amiga land.

	A copy of the IFF disk in ZOO would be appreciated. I find the code
	examples helpful (even though they are in C). If you give me a week
	or so to get at it (I'm out fairly often) then its doesn't need to
	stay on-line for too long.

	A copy of the ILBM section (hardcopy) would be interesting. Depends
	how much has changed, or rather (I hope), been added. If its ok to
	send hardcopy then I can be found as:

	Dave Bottomley @EOO (which is Newmarket, UK) so infernal mail should
	reach me with no hassle.

	DaveB