Xref: utzoo comp.graphics:12403 alt.graphics.pixutils:155
Path: utzoo!mnetor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!noose.ecn.purdue.edu!mentor.cc.purdue.edu!ahg
From: ahg@mentor.cc.purdue.edu (Allen Braunsdorf)
Newsgroups: comp.graphics,alt.graphics.pixutils
Subject: Re: solution: pixel aspect ratio in GIF images
Summary: Document your image or get out of GIF
Message-ID: <12198@mentor.cc.purdue.edu>
Date: 16 Jul 90 19:13:06 GMT
References: <9866@pt.cs.cmu.edu> <9894@pt.cs.cmu.edu>
Reply-To: ahg@mentor.cc.purdue.edu (Allen Braunsdorf)
Followup-To: comp.graphics
Organization: Purdue UNIX Group
Lines: 107

In article <9894@pt.cs.cmu.edu> tgl@zog.cs.cmu.edu (Tom Lane) writes:
>In article <9866@pt.cs.cmu.edu>, I asked:
>> The GIF documentation that I have makes no mention of the question of
>> pixel shape.  Is there any recognized convention about whether a GIF
>> image is set up for square or non-square pixels, and what the assumed
>> pixel aspect ratio is in the latter case?
>
>There seems to be general agreement that there isn't a recognized
>standard for pixel aspect ratio.

True and unfortunate.  An image format that claims to be for
interchange is worthless for exactly that purpose because of this
fact.

Watch my lips:  Putting an image into GIF without somehow documenting
the aspect ratio destroys the image.  The originally intended image
cannot be recovered with certainty.

>Erik Talvola (talvola@janus.Berkeley.EDU) points out that a GIF picture
>of size 320x200 pixels is almost surely intended for an IBM CGA display,

or a Commodore 64 or an Atari ST or an Amiga....  I know for a fact
that my 64 and my Amiga make different sized 320 x 200 screens on the
same monitor (the 64's is narrower).  Not to mention that the Amiga can
make three screens that are all 320 x 200, but have different aspect
ratios.

>It seems to me that a workable solution for GIF files would be to
>standardize on Brian's suggestion: let the screen dimensions in the
>file header represent a pixel area that fills a 4x3 physical area.
>A GIF reader could then rescale the image appropriately for its own
>screen.
>
>This is something of a hack, but it has several nice properties:
>	1. The file format doesn't change.
>	2. Existing GIF readers don't break (since they almost
>	   surely ignore the screen dimension info).
>	3. A large fraction of the GIF files out there have correct
>	   info in them already (namely, all the IBM-screen files).
>
>The main disadvantage is that readers using this convention would have
>to guard against computing a bogus aspect ratio when given a GIF file
>that doesn't adhere to the convention.  One easy defense is to reject
>any computed ratio that falls outside the expected range (probably
>1.0 to 1.4 would cover it).  A command-line switch to override the
>aspect ratio adjustment would be a good idea too.

Nonsense.  I make lots of images for display on my Amiga that have
pixels nearly twice as wide as they are tall.  Atari 8 bits have modes
where the pixels are far wider than that.  A PostScript printer can
print a picture of >any< size with >any< pixel aspect ratio.

This "solution" is almost as narrow minded and silly as GIF is to begin
with.  That's by no means an attack on any of the people in this
discussion, only on the idea that you can somehow determine the aspect
ratio of an unknown image.  It just can't be done.

The only real solution is to tell the aspect ratio of the image when
you post it or whatever.  If somebody is going to send me a GIF, I
always tell them to send the aspect ratio along with it, or forget it.

Archives typically have a file that shows how many colors each file has,
why not another column for pixel aspect ratio:

clown.gif	657 x 395 x 8 (1:1)
shuttle.gif	657 x 395 x 8 (12:7)
zebra.gif	657 x 395 x 8 (4:13)

That way nobody has to guess.  If you guessed from just the dimensions
of those images, you would have been wrong at least twice, right?

>Any comments?

Yeah, in general, I'm more interested in the pixel aspect ratio (the
shape of the pixels) than in the image aspect ratio.  Either can be
computed from the other for a known image size, but I prefer the pixel
dimensions.

Why?  Because on many displays, the image size is variable, but the
pixel aspect ratio is not.  Again, on my Amiga I'm free to make an
screen of nearly any size, but I only have three (four really)
different kinds of pixels.  Posting the image aspect ratio with each of
my images would be very confusing as it varies so much, but the pixel
aspect ratio stays the same.

I often move images from one of my machines to another.  I use the
pixel aspect ratios to make any necessary corrections.  That way, the
images don't get distorted any more than they need to.  If I didn't
have the aspect ratio of the image documented, or didn't know the
aspect ratio of the target device, I could not do this.

Assumption of aspect ratio is an evil thing.  If you find you do it
often, you should probably consider a different image storage format.
Try IFF ILBM's, coding it up as a PostScript program, or even TIFF.

I don't like the complexities of TIFF, but at least I >can< decode a
TIFF.  No such luck with a GIF.  (Though it is easy to get the
information that is encoded in a GIF, it's impossible to get what's
just not there.)

GIF's a toy, and a dangerous one.  If you want to play with it, use a
warning sticker that contains the (pixel, or at least image) aspect
ratio.  That way, people won't have to slaughter your images.

---
Allen Braunsdorf			Purdue University Computing Center
cc.purdue.edu!ahg			UNIX Systems Programmer