Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!mentor.cc.purdue.edu!ahg
From: ahg@mentor.cc.purdue.edu (Allen Braunsdorf)
Newsgroups: comp.graphics
Subject: Re: Gif to IFF
Summary: IFF is most portable, TIFF is complicated, GIF is a toy
Keywords: aspect ratio information required for maximum portability
Message-ID: <4608@mentor.cc.purdue.edu>
Date: 20 Oct 89 09:51:41 GMT
References: <1198@clinet.FI> <390039@hpfcdq.HP.COM>
Reply-To: ahg@mentor.cc.purdue.edu (Allen Braunsdorf)
Organization: Photosurrealism
Lines: 202

In article <390039@hpfcdq.HP.COM> olsen@hpfcdq.HP.COM (John Olsen) writes:
>toweri@clinet.FI (Jukka Lindgren) writes:
>>	Can someone tell, in laymans terms, what is actually the difference
>>between Gif, IFF and TIFF -fileformats?

I stuck that at the bottom.  Read this other stuff first.

>Most important to me is to know,
>>if it's possible to create an IFF -file from TIFF -file (24 or 36 bits).
>>Or, better still: to create a HAM -image from TIFF -image...

You can make a 24 bit ILBM (IFF picture) easily.  Very few programs could
deal with such a beast, though.  ILBMs can be direct (colors in pixels)
or indirect (register numbers in pixels) like TIFFs.  GIFs can only
do indirection.

I make HAM images from 24 bit pictures all the time (and have been for quite
a while).  Currently, my utilities are unavailable, but I plan a binary
only release on a FF disk sometime soon.  The big holdup was waiting for
the word on 24 bit ILBMs.  Now I'm retooling my program to work exclusively
in IFF.

>GIF: Compu$erve picture format with up to 256 colors.

Not entirely true.  Each image can contain only 256 colors, but the entire
file can have as many images as you like, so cut the picture up and code
the images separately.  At the worst, divide it into 16 x 16 pixel squares.

It's inefficient, but you can get around it with some effort.

>It likes to use a
>1.2 aspect ratio if I remember right.

WRONG!  GIF says nothing about aspect ratio >at all<, which makes it
absolutely worthless for the use it was supposedly defined for: the exchange
of high resolution images between different platforms.  I use many different
displays and several different aspect ratios.  GIF is of no use to me.  Even
overlooking GIF's other shortcomings, this is unforgivable.

Take for example this IBM PS/2 over here.  It has several graphics modes
with many different aspects ratios (at least 4).  The Amiga has three.
The NeXt and Mac and Sun have square pixels.  If GIF had two more bytes
in the file header, this wouldn't be a problem.  ILBMs do, GIFs don't.
For this reason, a "GIF to IFF" program can't be trusted.  Ever.  Period.

>Lots of computers now have GIF
>viewing programs, but many have to drop extra colors if the computer can't
>do 256 onscreen at once.

I wasn't pleased at all with the Amiga GIF viewer I tried.  I ended up
turning the GIFs into 24 bit color separations, guessing at the aspect
ratio correction (no other way to deal with it), and HAMming the result.
It works, but it take a while longer than the average GIF viewer.  The
pictures looked about the same on the Amiga as on the PS/2.

On the IBM side, VUGIF and VGIF are the two viewers I've tried that I like
the best.  Many others are out there as well.

GIF's an amusing diversion, but I can't possibly take it seriously.

>IFF: File format developed by Electronic Arts for the Commodore Amiga, and
>also used on other systems.  It can be used for pictures (ILBM=interleaved
>bit map), sounds, text, and a few other things.  Pictures can contain things
>like color tables, color cycle ranges (colormap animation), all using 
>various types of compression.

The IFF was developed for interchange, and not for the Amiga in particular.
It's nice that it's caught on so well on the Amigas, because it keeps programs
compatible.  It's be nicer if its use were more widespread.  Deluxe Paint
reads and writes (some) ILBMs on every platform it runs on.  As long as an
ILBM doesn't contain a CAMG, it's very portable.  If it has one, the only bits
you should need are HAM and EHB, which are fairly easy to decipher in a direct
manner, but not directly translatable to a typical indirect display.

IFF has many advantages.  The biggest is that it is not an image format.  It
is a general Interchange File Format.  This allows combinations of different
types of data in a structured way.  This aspect of the format is often
underutilized.  It would have been really great, for instance, if NeXT had
gone with the IFF instead of TIFF, because then they'd have their
sound/graphics/text incorporation solved without the mess.

I use IFF ILBMs for image storage because they handle aspect ratio information
and all the code I needed to handle them was available for free.  If you are
only storing images, the format can be a bit imposing, but the parser really
isn't that tough.

The biggest problem I've had is with vendors defining their own (unnecessary)
chunks without documenting them.  The worst offender was (the last version of)
Photon Paint (that I saw), which had its own version of CAMG.  Stupid and
confusing.

The biggest problem everyone has with me is that >they< don't follow the
standard.  It's perfectly legit to hand a 24 bit deep picture to Deluxe
Paint.  I could also give it one 30000 pixels wide- or one with really tall
pixels.  It should either do the right thing or tell me why it can't.  Last
version of Deluxe Paint I gave a 24 bit ILBM to died a slow painful death.

(Note: a 24 bit ILBM wasn't really kosher until June (after the program was
written) of this year, so he should have rejected it with a friendly message.)

>TIFF: Not a clue as to it's internals. :^(  Apparently used by NeXT and
>some scanners.

TIFF is very much like the IFF, but it is only for the storage of images.
This sounds like a good thing 'til you notice that TIFF is more complicated
with less functionality.  That is, I need to write more code to decode a TIFF
image that to decode many classes of IFF files.  With the proper tags, an
image can be coded in nearly any way imaginable.  While this is very good for
the writer, it makes reading a TIFF difficult.  Many commercial programs will
write TIFFs, but cannot read an arbitrary TIFF.  (The same is true of IFF-
see above.)

The best place to go for code is the tifftools that are available by ftp.  I
think you can get them at ucb.

Two of the machines I work with a lot (NeXT and Macintosh) have big trouble
with TIFF.  Images that are Applescanned and ported come out negative, for
instance.

TIFF did not, have a tag for aspect ratio last time I checked (it is used
almost exclusively on square pixeled devices), though one could be added
easily.  With this addition, TIFF would be a useful general image format, but
a lot of trouble to support.  Don't be a hero, grab those tifftools and work
from there.  They work better than most commercial programs and you can
probably wedge your application into them without much trouble.

>Fbm lists TIFF as "not yet supported" in the version I have (7 March 1989),
>but the fbm package has a file tifftopbm.  That would take it to monochrome,
>however. There's also a pbm program called ppmtoillbm which can write HAM 
>IFF files.  The pbm package was posted recently to comp.sources or some 
>such group.

pbmtoilbm shouldn't need HAM at all.  Writing a bitmap out in IFF is really
easy (especially since they already have pbmtomacp and they're almost the
same.)  pbm doesn't specify aspect ratio either, but it's widely accepted
to be 1:1, so use that and go.  Simple program.  Of course most IFF viewers
don't aspect ratio correct.  *Sigh*  Guess their authors saw one too many
GIFs.

In summary:

GIF	A format for storing images with color look up tables.  No aspect
	ratio is saved, so fidelity cannot be insured.  The file consists
	of a header of fixed fields, an optional global color map,
	and one or more images (which each have a header and optional
	local color map).  The format is extensible through ! blocks.  I've
	heard rumors about these, but I've never seen one documented or
	source code to a program that would do anything more than ignore
	them.

	GIF's primary use is the transfer of non-critical images between
	personal computers.  It is also popular as a storage format on
	some personal computers (especially IBM compatibles).  Images
	often appear stretched or squashed.  This is because aspect ratio
	information is unavailable in the format.  Many viewers do a terrible
	job of representing the colors in the stored image.  This is the fault
	of the programmers (and the hardware, of course!)

IFF	A general interchange format for data.  The part you want to look
	at is the FORM ILBM.  This is a fairly simple digital image
	structure that describes the attributes of an image and how
	to decipher it and then has the image itself.  The format is
	extensible by the addition of chunks.

	It is used by Electronic Arts to store data for their programs on a
	variety of machines and by Amiga users as their primary storage
	format.  Most Amiga programs skimp a bit on the standard and couldn't
	handle non-Amigaish files if confronted by them.  This is the fault
	of the programmer and not the format.  The format, if followed
	carefully is a good way to store an image for later use on an
	arbitrary platform.  Many readers are careless and many writers
	do odd (though ignorable) things.

TIFF	A very flexible image storage format.  Files contain a small header
	and then a directory of tags.  These tags describe attributes
	of the image.  By adding tags, the format can be extended.

	TIFF is used primarily for scanners and image processing programs
	on large microcomputers ("workstations", if you insist) and some
	personal computers.  With the addition (and strict adherence to)
	an aspect ratio tag, this format could be used most anywhere.  It
	just takes a lot of code to do right.

	I don't like a lot of things about TIFF, but it can work.  Many of
	my complaints concern the way the definition is handled (or not.)

I hope this helps you out.  I do a lot of image conversion, so I work with
this stuff all the time.  I think of these three, IFF is the clear choice,
but will admit that I usually don't format images at all when I'm processing
them.  I keep them around as four simple files (very similar to the archives
at venera.isi.edu and pprg.unm.edu, but with aspect ratio information in
the .a files.)  This is changing as I am growing accustomed to deep ILBMs,
but it is something to think about.  The last thing I would want to do is
invent YADISF (Yet Another Digital Image Storage Format), but unformatted
data has its place.  It's quick and dirty and easy to get to from anywhere.

If you've any questions, you can try to mail me.  I haven't been reading
this group as closely as I used to.

---
Allen Braunsdorf			 Purdue University Computing Center
staff.cc.purdue.edu!ahg		  UNIX Group Part Time, Consulting the Rest