Gif to IFF

Gif to IFF

Post by Jon Greenbla » Sun, 02 Sep 1990 05:30:00



        Can someone give me a pointer to a GIFF to IFF program.
I would prefer either a binary for the amiga or source/binary for another
machine if such an absurdity exists.

                                        Thanks much,

                                                JonnyG.

 
 
 

Gif to IFF

Post by Jukka Lindgr » Tue, 02 Oct 1990 23:08:00



>    Can someone give me a pointer to a GIFF to IFF program.
[stuff deleted]
>                                            JonnyG.

        Can someone tell, in laymans terms, what is actually the difference
between Gif, IFF and TIFF -fileformats? 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...

Or should I just forget it!

-=toweri=-

--
= VOICE: + 358 0 571789              || Any opinions expressed contain        =

= or: ...!mcsun!santra!clinet!toweri || Therefore no disclaimers can be made  =
= SNAIL: don't bother...             ||              (I KNEW you'd hate it !) =

 
 
 

Gif to IFF

Post by John Ols » Tue, 02 Oct 1990 15:43:00



>    Can someone tell, in laymans terms, what is actually the difference
>between Gif, IFF and TIFF -fileformats? 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...

GIF: Compu$erve picture format with up to 256 colors.  It likes to use a
1.2 aspect ratio if I remember right.  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.

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.

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

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.

John Olsen

 
 
 

Gif to IFF

Post by Allen Braunsdo » Tue, 02 Oct 1990 10:51:00


In article <390...@hpfcdq.HP.COM> ol...@hpfcdq.HP.COM (John Olsen) writes:
>tow...@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 ...

read more »

 
 
 

Gif to IFF

Post by Dr. Harry Plantin » Tue, 02 Oct 1990 15:52:00



>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.  

>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.

>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.

There is other information that should be stored with images but which
I have not heard anyone mention.

_Big-endian vs. Little-endian_:  does 255 represent white or black?

_Primary colors_:  the wavelengths of the (R, G, and B) primaries used
in representing the image.  Usually the NTSC primaries are used, but
some devices such as color printers may use other primaries.
Furthermore, the actual color of the pigments may vary from monitor to
monitor, and if the information is known for a particular monitor then
color correction can be performed.  Primary color information is is
essential in matching colors between devices with different primaries.
[See Roy Hall's book "Illumination and Color in Computer Generated
Imagery."]

_Gamma correction factor_:  Monitors, video cameras, and other
equipment vary in their "gamma correction" value.  Typically, the
brightness output of a monitor is not linear with the input value, but
exponential.  It typically depends on the input as the function

lookup value = intensity ^ (1/gamma)

It is possible to perform gamma correction before storing the data in
a standard file format, but much information is lost.  For a monitor
with gamma 2.2 and linear input, only about 190 of the 255 different
possible output values can be used for an 8-bit image [from Hall].

=================

Is there other information that should be stored with an image?

Is there a file format that stores this information?

If not, perhaps this group should define standard extension to one of
the existing file formats for storing this information.

-Harry Plantinga

 
 
 

Gif to IFF

Post by Ed Fa » Tue, 02 Oct 1990 02:28:00


Quote:> _Big-endian vs. Little-endian_:  does 255 represent white or black?

White.  I've never seen an exception, although I suppose there might be.
I think it would be simpler to reverse the numbers when writing your files
than to get the whole world to accept a new image attribute.

Quote:> _Primary colors_:  the wavelengths of the (R, G, and B) primaries used
> in representing the image.  Usually the NTSC primaries are used, but
> some devices such as color printers may use other primaries.
> Furthermore, the actual color of the pigments may vary from monitor to
> monitor, and if the information is known for a particular monitor then
> color correction can be performed.  Primary color information is is
> essential in matching colors between devices with different primaries.
> [See Roy Hall's book "Illumination and Color in Computer Generated
> Imagery."]

I don't see how you're going to match colors between systems with different
primaries, but I suppose if you're going to go to all that trouble,
then you might as well find out what the primaries are on the system that
produced the image and assume that's what the rgb values represent.

Quote:> _Gamma correction factor_:  Monitors, video cameras, and other
> equipment vary in their "gamma correction" value.  Typically, the
> brightness output of a monitor is not linear with the input value, but
> exponential.  It typically depends on the input as the function

> lookup value = intensity ^ (1/gamma)

> It is possible to perform gamma correction before storing the data in
> a standard file format, but much information is lost.  For a monitor
> with gamma 2.2 and linear input, only about 190 of the 255 different
> possible output values can be used for an 8-bit image [from Hall].

Well, since gamma varies from monitor to monitor (depending on manufacture,
how it's adjusted and how bright the room lights are where the monitor
sits), there's no point in storing the information in the raster file.
The ideal situation would be for every raster file to represtent intensities,
and for every viewing program to know the gamma for the monitor it's
being run on (how? /etc/gamma or something?) and ajust accordingly.

In truth, most images were generated by someone who "tweaked" the values
on their own system until they looked "good", and then wrote out a
rasterfile.  This means that every rasterfile contains an implicit
crude gamma correction built in.  It would be nice if everybody knew
the gamma of their own monitor and reverse-corrected when they wrote
out the rasterfile, but in practice, this never happens.  In fact, one
of the secrets to generating a good 1-bit-dithered image from an 8-bit
image is reversing the gamma correction in the 8-bit raster file
before dithering.

I suppose if you *really* want to store this kind of information in
raster files, you could have new tags added to TIFF.

--

  "If you wrapped yourself in the flag like George Bush does, you'd
  be worried about flag-burning too"

 
 
 

Gif to IFF

Post by J.T. Conkl » Wed, 03 Oct 1990 00:53:00



>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.

TIFF doesn't have an aspect ratio tag because it doesn't need one.
It stores XResolution, YResolution, and ResolutionUnit as separate
tags.

The aspect ratio is computed by dividing the XResolution by YResolution.

    --jtc

--
J.T. Conklin
        ...!{ubc-cs,uunet}!van-bc!tessera!jtc

 
 
 

Gif to IFF

Post by Chris Sea » Tue, 02 Oct 1990 03:00:00




> There is other information that should be stored with images but which
> I have not heard anyone mention.

> _Big-endian vs. Little-endian_:  does 255 represent white or black?

By this do you mean byte ordering.  TIFF supports both Intel and Motorola
byte ordering.  "does 255 represent white or black?",  This is called
Photometric Interpretation in TIFF parlance.

Quote:

> _Primary colors_:  the wavelengths of the (R, G, and B) primaries used

> _Gamma correction factor_:  Monitors, video cameras, and other

TIFF tags for primary chromaticities, white point are available.
For gamma, color response curves describe any sort of companding function
as a set of 3 16-bit lookup tables.

"Internal" compression schemes are also available.  The full TIFF 5.0
specification is available from Aldus.

And, best of all, an excellent public domain TIFF library written by
Sam Leffler is available via FTP from ucbvax.berkeley.edu.  It is very
easy to use and extend.

--Chris

 
 
 

Gif to IFF

Post by J.T. Conkl » Tue, 02 Oct 1990 04:52:00



>There is other information that should be stored with images but which
>I have not heard anyone mention.

You are in luck.  Image colorimetry information was added to the TIFF
standard as of TIFF 5.0 (8/8/88).

Quote:>_Big-endian vs. Little-endian_:

    Set by GreyResponseCurve for bilevel and greyscale, and ColorMap
    for palette color images.  RGB is defined such that 0 represents
    minimum intensity.

Quote:>_Primary colors_:

    Set by TIFF's PrimaryChromaticities tag

Quote:>_Gamma correction factor_:

    Set by TIFF's ColorResponseCurves tag

    --jtc

--
J.T. Conklin
        ...!{ubc-cs,uunet}!van-bc!tessera!jtc

 
 
 

Gif to IFF

Post by Allen Braunsdo » Tue, 02 Oct 1990 05:50:00




>>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.

>TIFF doesn't have an aspect ratio tag because it doesn't need one.
>It stores XResolution, YResolution, and ResolutionUnit as separate
>tags.

>The aspect ratio is computed by dividing the XResolution by YResolution.

I ran off to grab my TIFF 5.0 spec to check the phrasing on this.  It goes
like this:

        X Resolution

        The number of pixels per Resolution Unit in the X direction,
        i.e., in the Image Width direction.  It is, of course, not
        mandatory that the image be actually printed at the size
        implied by this parameter.  It is up-to the application to use
        this information as it wishes.

                                        [ TIFF 5.0 8/8/88 Page 16 ]

OK, I'll buy that the tags are there.  I'm sorry that I missed them somehow.

I'd like this entry much better, however, if the last sentence assured me that
my aspect ratio would be preserved.  If any TIFF reader ever distorts one of
my images without warning me ("Sorry, I'm too dumb to do a simple aspect ratio
correction."), I'll blame the author instead of the format, even though the
loose wording of the specification gives the idiot some room to move.

A tag like this is fundamental to image fidelity.  Rules should be well
defined and strictly followed.  To me, this is as important as the Image Width
or Length.

Now I'm curious if the TIFF reading applications I use actually follow these
parameters.  I'll check the NeXT later this week.  Thanks again for pointing
this out to me.  I know I've seen it (I've read the whole nauseating
specification), but I forgot it somehow.

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