jonnyg@umd5.umd.edu (Jon Greenblatt) (09/20/89)
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.
toweri@clinet.FI (Jukka Lindgren) (10/06/89)
In article <5339@umd5.umd.edu> jonnyg@umd5.umd.edu (Jon Greenblatt) writes: > > 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 = = EMAIL: toweri@clinet.fi || * The Absolute Truth * = = or: ...!mcsun!santra!clinet!toweri || Therefore no disclaimers can be made = = SNAIL: don't bother... || (I KNEW you'd hate it !) =
olsen@hpfcdq.HP.COM (John Olsen) (10/13/89)
toweri@clinet.FI (Jukka Lindgren) writes: > 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 olsen@hpfcdq.HP.COM
ahg@mentor.cc.purdue.edu (Allen Braunsdorf) (10/20/89)
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
jtc@tessera.uucp (J.T. Conklin) (10/22/89)
In article <4608@mentor.cc.purdue.edu> ahg@mentor.cc.purdue.edu (Allen Braunsdorf) writes: >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
ahg@mentor.cc.purdue.edu (Allen Braunsdorf) (10/23/89)
In article <1989Oct21.235312.416@tessera.uucp> jtc@tessera.UUCP (J.T. Conklin) writes: >In article <4608@mentor.cc.purdue.edu> ahg@mentor.cc.purdue.edu (Allen Braunsdorf) writes: >>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