raveling@Unify.com (Paul Raveling) (02/13/91)
With 108 responses, the results are in for the poll on image
file formats. It shows 99 different formats in use, with GIF
by far the most popular.
Actually it's much more than 99: Many summarized
as a single format have different "subformats", such as
PBM, PGM and PPM in the PBMPLUS set, and monochrome,
color mapped, and 24-bit RGB in many others such as
Sun rasterfiles.
Beyond the counts that follow, here are some observations
based on comments in the responses:
-- Most respondents use several formats because they have to
in order to import and export images, but would prefer
to use only one format.
.. The PBM/PGM/PPM (PBMPLUS) formats are particularly
popular because they're used by the PBMPLUS package
for converting between other image formats. They're
often, if not usually, used for intermediate files rather
than as a "source or destination" format.
-- Many if not most respondents are unhappy to varying degrees
with the formats they [have to] use.
-- Popularity often depends a lot how long a given format
has been around and what platforms support it.
-- The main (frequently unsatisfied) needs expressed are for
simplicity, capability, and compression.
-- The group looking for simplicity in the file format seems
to be the largest. Those looking for capability, such as
as gamma correction data, are present in lesser numbers but
are still a strong contingent. Almost everyone wants
good data compression. Many want to use image formats
supported well on PC's.
.. At least one format, TIFF, has gets opposing reviews
from opposite sides: Some looking for capability think
it's great, some looking for simplicity don't like it.
.. Utah RLE is another preferred format for those looking
for capability.
.. GIF89a is prone to "too complex" opinions, and has only
rare use at present. Essentially all of the respondents
using GIF are using GIF87a.
-- The number of responses listing file formats they'd like
to use was fairly small, but most of the interest went to
JPEG, sometimes with phrasing such as "Something with better
compression, mature JPEG possibly".
** A couple conclusions (IMHO):
.. We need to define some genuine "ultimate" standards.
It should now be feasible to define a standard
for a simple image file format. It's a bit early
to define a "full capability" format, but it's not
too early to begin seriously working toward defining
one.
.. Standards should be chosen on the basis of their
technical and functional merit, rather than pure
popularity. Any emerging standard will need support
for importing a large number of old image formats.
.. Most popular formats, especially GIF87a, are
inappropriate to adopt as is for a standard.
.. For lossless data compression, I agree with those
who like to treat this as a separate issue: Define
the image file format without compression, then
compress the entire file via something such as
the Unix "compress" utility.
.. For maximum data compression, with some loss allowed,
it may be necessary to embed compression in the file
format. The only serious candidate for compression
with loss allowed at present is JPEG, and it's too
early to judge its success.
.. If ultimate standards are to be accepted, it will be
necessary to have them supported by virtually all
major vendors of workstations, PC's, and other image-using
systems. Are any established consortiums prepared
to participate in this?
------------------------------------------------------------------------
Results follow below, in descending order by frequency of
reported use and by alphabetic order for each frequency.
------------------------------------------------------------------------
File formats in use:
56 GIF
32 PBM/PGM/PPM (PBMPLUS)
32 TIFF
28 Sun rasterfile
25 Homebrew (see note at end of list)
16 Utah RLE
15 Postscript (including Encapsulated Postscript)
13 XBM (X11R4 bitmap)
11 XWD
10 Targa (TGA)
9 FITS
9 SGI (Silicon Graphics format[s?])
7 IFF (Amiga)
7 PICT
7 PICT2
6 PCX (Windows)
5 BMP (Windows)
4 FBM
4 GEM (.IMG)
4 HDF
4 HIPS
3 ILBM (Amiga)
3 viff
3 MacPaint
3 MTV "PIC"
2 BRL-CAD (.pix, .bw formats)
2 Group 3 FAX
2 JPEG
2 Pixar (pic)
2 "Various medical formats"
2 Xim
1 Acorn RISC OS Sprite
1 AIM/Wild Vision Hawk V9 512x256y 12 bit colour
1 AIM/Wild Vision Hawk V10 files 256x256y256g
1 Analyze (Mayo Clinic)
1 Apollo GPR images
1 ArVis 15 bit HIP.+LOP. sprites
1 Atari Spectrum 512
1 AVS Image and volume
1 big
1 CCIR 601 PAL/NTSC image YUV encoded
1 CDF
1 CGM
1 CT2T
1 CUT (DrHalo)
1 CVL (Computer Vision Lab, University of Maryland)
1 DDES
1 Degas PI1, PI2, PI3 images
1 dem
1 dlg
1 DVI (Imagen)
1 elas
1 Electronic Art's IFF ILBM pictures
1 EPS
1 FaceSaver
1 flux (apE Ohio)
1 GE Signa
1 Giffer
1 GL
1 Group 4 FAX
1 HPGL
1 IFF (Sun)
1 Img (Img Software Set)
1 img (Interleaf)
1 Irlam Instruments 200dpi 24bpp colour scanner
1 IRAF
1 IT8.4
1 LLVS
1 MacDraw
1 MIDAS
1 MILLIPEDE PRISMA 768x576y 8 bit colour images
1 PC EGA .DSP images 640x350y16c
1 .PIC
1 PICIO
1 Pineapple 16 bit per pixel image
1 ProArtisan compressed pictures 640x256y256c
1 QRT 24 bit .raw images
1 RIFF
1 RIX Softworks ColoRIX 8 bit per pixel files
1 RT 24 bit run length coded image. files
1 SCODL
1 SDS
1 Translator Clear format
1 System 600 (International Imaging Systems)
1 TimeStep satellite image 800x800y256g
1 TimeStep satellite image 128x256y256g & RGB separations
1 Universal Plane Format (extended LLVS)
1 University of North Carolina
1 UNIX rle format [Utah?]
1 Versatek CMYK rasterfile
1 VIS
1 Vitec
1 Watford digitiser pictures 512x256y64g & RGB separations
1 Wavefront raster file
1 WordPerfect WPG
1 xfig
1 Xgiff
1 ZSoft .PCX files [same as "Windows" .PCX files?]
1 4sight
Notes:
"Homebrew" includes 15 variants of raw raster data, 9 "own" formats
that apparently are more elaborate, and 1 modified
Sun rasterfile format
File formats that respondents Would like to use or are considering using:
9 JPEG (Often "Something with better compression, mature JPEG possibly")
2 FITS
2 GIF
1 Amiga SHAM
1 Dynamic Hi-res
1 HDF
1 MPEG
1 TIFF
------------------
Paul Raveling
Raveling@Unify.combuck@nrl-cmf.UUCP (Loren Buchanan) (02/13/91)
In article <1991Feb12.120203@Unify.com> raveling@Unify.com (Paul Raveling) writes: > -- Most respondents use several formats because they have to > in order to import and export images, but would prefer > to use only one format. Well, actually I would like to use 4 different formats that are all in the same family. These would be in order of size: PostScript hex format (without any header information), a binary version, a lossless compressed version, and a lossy compressed version. By family I mean that they all have the same row-column-[rank (or whatever you want to call the third dimension)] ordering, a minimal amount of header information (but the header can point to external sources of info.). > ** A couple conclusions (IMHO): > > .. We need to define some genuine "ultimate" standards. > It should now be feasible to define a standard > for a simple image file format. It's a bit early > to define a "full capability" format, but it's not > too early to begin seriously working toward defining > one. Well it is actually underway right now. DIN (the German standards organization [equivalent to ANSI, BSI, etc.] is working on defining Image Interchange Format (IIF) which is intended to be compatible with the proposed Programmer's Imaging Kernal (PIK) standard (being defined by X3H3). X3H3 is an Accredited Standards Committee operating under ANSI rules. > > .. Standards should be chosen on the basis of their > technical and functional merit, rather than pure > popularity. Any emerging standard will need support > for importing a large number of old image formats. Formal standards are usually created by political action within a committee. Large customers (U.S. Government, General Motors, Boeing, etc.) can force the adoption of standards that are not always the best. I think I better stop here before I get on a soapbox ;-). The following are either formal standards or are in the process of being defined as a formal standard (ANSI and/or ISO). The problem with these, is that they are being defined for use with a particular application set, not as a general purpose image file format. > 15 Postscript (including Encapsulated Postscript) > 13 XBM (X11R4 bitmap) > 11 XWD > 2 Group 3 FAX > 2 JPEG > 1 CCIR 601 PAL/NTSC image YUV encoded > 1 CGM > 1 Group 4 FAX > 1 IT8.4 The real problem is that there are so many different kinds of applications that images are used with, that there is no one format that will work reasonably well with all of them. The good news is that we are at least ensured of employent for some time to come. B Cing U Buck
GUTEST8@cc1.kuleuven.ac.be (Ives Aerts) (02/14/91)
In article <1991Feb12.120203@Unify.com>, raveling@Unify.com (Paul Raveling) says: > -- lots of data excluded -- > 7 IFF (Amiga) > 3 ILBM (Amiga) > 1 Electronic Art's IFF ILBM pictures > 1 IFF (Sun) These are all the same format so the votes should be counted together. (I'm not sure about Sun IFF though, but IFF should be the same on all computers) > 1 Amiga SHAM This is a display mode of the Amiga, not a graphics file format. > >------------------ >Paul Raveling >Raveling@Unify.com ------------------------------------------------------------------------ Ives Aerts | IBM definition SY-34378 GUTEST8@BLEKUL11.BITNET | A signature consists of sequences of gutest8@cc1.kuleuven.ac.be | non-blank characters separated by blanks. ------------------------------------------------------------------------
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/16/91)
In article <1991Feb12.120203@Unify.com> raveling@Unify.com (Paul Raveling) writes: | .. If ultimate standards are to be accepted, it will be | necessary to have them supported by virtually all | major vendors of workstations, PC's, and other image-using | systems. Are any established consortiums prepared | to participate in this? Well, no, actually. If GIF is supported by major vendors of workstations is news to me. If was developed for Compu$erve, and they has PC and Mac (and maybe Amiga) viewers written for it. Better viewers, and viewers for other machines were written by private individuals, small companies, etc. PMBPLUS is based on the work of one person, augmented by the work of many others, and as far as I know is supported by the public in general, not any commercial companies. Perhaps you should develop some really good format and let the public make it popular because it's better than all the rest. If it's good, people will write versions for many machines. If the first implementation is good it will port to many machines without much effort. If you have a good idea it will take off unless you work hard to hold it down. Examples are GNU software, netnews, X-windows, GIF, ZIP, etc. There's no need at all for commercial involvement. If you have a bad idea, the only way to make it common is to have IBM adopt it as a standard, and *nothing* will make it popular. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
zap@lysator.liu.se (Zap Andersson) (02/26/91)
G'day. The file format polling had (a lot) incorrect entries, and I will adress one subject: Amiga (Electronic arts) IFF here. IFF stands for Interchange File Format and is NOT (and will never be) an image file format per se. IFF is really just a way to structure data, in FORM's and LIST's and PROP's and all that things (like a C struct). IFF dictates the structure of a file. Then certain TYPES of IFF files exist, such as ILBM (ILBM is an IFF FORM). This can be found in the beginning of an Amiga picture: FORM ILBM it says! (Advanced, eh?) ILBM stands for InterLeaved Bit Map, and is an image file format supporting colormapped images. The format does not really dictate a bit count limit, but it is probably in practice only up to 8 bits. ILBM does compressin, simple run-length encoding. Since the IFF format can include data sets (chunks) that are application- specific by giving a four-letter word ;-) as cunk name, and the length of the chunk (so readers that doesn't know this chunk can skip it) it can really contain ANY data along with the picture, gamma correction, name of author, or shoe number of authors wives lovers daughters cat's former owner. IFF is defined by Electronic Arts. If you count the 'poll' list and count together all different mentions of IFF it comes very high on the list, above Targa, even. So I wonder, why is the computer industry so keen on reinventing the wheel over and over? The IFF format is an EXCELLENT structure for files, not only images (There are IFF's for formatted text, 8SVX (8 bit sampled sound) and SMUS for Simple Musical Score!!) And the ILBM format is really simple and somewhat effective (It does compress, but the code to dompress and de-compres is really simple). Why don't we all use IFF? Could any one person answer me that? Just some thoughts, really... -- * * * * * * * * * * * * * * * * * (This rent for space) * My signature is smaller than * Be warned! The letter 'Z' is Copyright 1991 * yours! - zap@lysator.liu.se * by Zap Inc. So are the colors Red, Green and * * * * * * * * * * * * * * * * * Greenish-yellow (Blue was taken by IBM)
knoll@well.sf.ca.us (John Knoll) (02/28/91)
Oh, come on. "The IFF format is an EXCELLENT structure...." I disagree in that the image format (ILBM) really bites. The pixel values are stored in bitplanes, so if you want to read the value of a single pixel of an 8-bit image, you have to access 8 bytes in different locations, mask out the bits you don't want, and assemble a real byte. I find this kinda stupid.
kdarling@hobbes.ncsu.edu (Kevin Darling) (03/01/91)
knoll@well.sf.ca.us (John Knoll) writes: > Oh, come on. "The IFF format is an EXCELLENT structure...." I disagree >in that the image format (ILBM) really bites. > The pixel values are stored in bitplanes, so if you want to read the value >of a single pixel of an 8-bit image, you have to access 8 bytes in different >locations, mask out the bits you don't want, and assemble a real byte. > I find this kinda stupid. Actually, up until a few weeks ago, I'd have agreed. Since then I've been thinking about the best format for exchanging picture files, and I must admit that a variable number of planes makes sense from the standpoint of only transmitting what is needed. Altho I'd be happy if even-byte counts (8/16/24 planes) instead went as chunky <grin>. best - kevin <kdarling@catt.ncsu.edu>
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (03/02/91)
In article <23390@well.sf.ca.us> knoll@well.sf.ca.us (John Knoll) writes: > Oh, come on. "The IFF format is an EXCELLENT structure...." I disagree > in that the image format (ILBM) really bites. > The pixel values are stored in bitplanes, so if you want to read the > value of a single pixel of an 8-bit image, you have to access 8 bytes > in different locations, mask out the bits you don't want, and assemble > a real byte. > I find this kinda stupid. And in turn I find your reply a bit parochial; you are talking about _exchange_ standards, and the world is not all the eight bit deep VGA display hardware in front of you. ILBM != IFF. It is merely an available encoding registered and supported in the IFF standard. The ILBM (InterLeaved BitMap, if memory serves) format is an excellent choice for an _exchange_ format, since the calculations for storing and retrieving, say, six bit deep data for an eight bit display device are much more straightforward from individual bitplanes than the shifts and masks that would be needed to pull that data out of a format that stored the first four pixels in three bytes like this: 11111122 22223333 33444444 Also, on a guess, packing with a "compress" type algorithm should be much more effective bitplane by bitplane, than for the above mess, which destroys runs of identical pixels by the byte embedding. More important, though, is that IFF is a standard container for standard encodings, and you are perfectly free to (and, more likely than not, someone already has) define an encoding key called "PAK8" instead of "ILBM" and store your data as eight bit pixels if that makes you happier. Of course, if you choose so parochial an encoding, few users of incompatible machines will bother to recognize your "PAK8" coding, but the VGA users will still be able to use it among themselves. The rule for an IFF "chunk" is, if a decoder/displayer doesn't recognize the code quadbyte, it is supposed to skip the associated data and go on to what it can handle; this is again excellent functionality in an _exchange_ standard. A little knowledge goes a long way in criticizing someone else's posting. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
nv89-nun@dront.nada.kth.se (Nicklas Ungman) (03/06/91)
In article <1991Mar2.075356.9352@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
The ILBM (InterLeaved BitMap, if memory serves) format is an excellent
choice for an _exchange_ format, since the calculations for storing and
retrieving, say, six bit deep data for an eight bit display device are
much more straightforward from individual bitplanes than the shifts and
masks that would be needed to pull that data out of a format that stored
the first four pixels in three bytes like this:
11111122 22223333 33444444
Also, on a guess, packing with a "compress" type algorithm should be much
more effective bitplane by bitplane, than for the above mess, which
destroys runs of identical pixels by the byte embedding.
The problem with ILBM as an exchange format is when reading a six bit deep
image and there's no CAMG chunk, you have no idea what so ever if it's HAM,
Halfbrite or something else. You have to guess or even ASK the user !!!
I think it's really stupid to not save all information needed.
You're right that PackBits (which ILMB use) packes better on individual
bitplanes. However, if you use LZW compression it's usually better to
use bit chunks. And I think LZW does usually beat PackBits (although I
have no proof for this)
More important, though, is that IFF is a standard container for standard
encodings, and you are perfectly free to (and, more likely than not,
someone already has) define an encoding key called "PAK8" instead of
"ILBM" and store your data as eight bit pixels if that makes you happier.
The rule for an IFF "chunk" is, if a decoder/displayer doesn't recognize
the code quadbyte, it is supposed to skip the associated data and go on
to what it can handle; this is again excellent functionality in an
_exchange_ standard.
If everybody defined their own standard chunks there would no longer be any
standard chunks.
Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
/Nixxonxanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (03/08/91)
Note followups! nv89-nun@dront.nada.kth.se (Nicklas Ungman) writes: > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: {An ongoing conversation, talking about the IFF standard] More important, though, is that IFF is a standard container for standard encodings, and you are perfectly free to (and, more likely than not, someone already has) define an encoding key called "PAK8" instead of "ILBM" and store your data as eight bit pixels if that makes you happier. The rule for an IFF "chunk" is, if a decoder/displayer doesn't recognize the code quadbyte, it is supposed to skip the associated data and go on to what it can handle; this is again excellent functionality in an _exchange_ standard. >If everybody defined their own standard chunks there would no longer be any >standard chunks. True if the story ended there, but there is a registration process so that if the Mac people wanted to register a BHX4 container name for the very common BinHex4.0 exchange format, they could assure that there were no collisions with other vendors' container names, and also (optionally) furnish a publically usable specification for that format, so that John or Jill Programmer could write a BHX4 handler for _any_ machine to which the encased data was of interest. It is also permissible to register a container name for a proprietary format. Though that dooms it as an exchange format, doing so does make it possible for a vendor to mix the proprietary containers with other containers in an IFF file, and know that on processing an IFF file, if that container name is seen, it is in the vendor's proprietary format, and the vendor provided handler should be invoked and can be invoked safely. At least one music program did/does use such a proprietary format. The proof of the pudding, etc., is that the vendor/format/implementation mix in IFF files on the Amiga (and perhaps other machines, I'm no expert here) has been quite successful. You can build an IFF that looks like a Chinese restaurant menu of containers, and pass the file to various handlers, and each does all and only what it can with the encoded data. For example, an IFF file might contain text, graphics, and picture containers, which can be separately accessed by pagers or editors or voice synthasizers for the text, viewers or paint programs for the graphics, and players or synthasizers or samplers for the music, depending on what interests the particular user, then passed off to a kitchen sink style special purpose handler that animates the graphics, plays the music, reads the text aloud, and scrolls the text in a "closed caption" window, all at once. I don't claim it is easy, merely that IFF makes it possible, and that such usage is common on the Amiga. Contrariwise, such complexity is not mandated for an IFF file, merely available. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> -- By the way, I think the term of art is more like "hunk" than "container", but I hope the latter is clearer to the person not associated with the IFF standard.