Xref: utzoo comp.graphics:12420 alt.graphics.pixutils:157
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!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: You shouldn't ignore the screen size
Message-ID: <12234@mentor.cc.purdue.edu>
Date: 17 Jul 90 20:23:45 GMT
References: <9866@pt.cs.cmu.edu> <9894@pt.cs.cmu.edu> <12198@mentor.cc.purdue.edu> <9922@pt.cs.cmu.edu>
Reply-To: ahg@mentor.cc.purdue.edu (Allen Braunsdorf)
Followup-To: comp.graphics
Organization: Purdue UNIX Group
Lines: 48
Organization:
Keywords:

In article <9922@pt.cs.cmu.edu> tgl@zog.cs.cmu.edu (Tom Lane) writes:
>In article <12198@mentor.cc.purdue.edu>, ahg@mentor.cc.purdue.edu
>(Allen Braunsdorf) writes (in response to a previous post of mine):
>
>How about not using "fighting words" when you don't understand the proposal?
>
>What I suggested was that the original creator of a GIF image document the
>image's pixel aspect ratio by redefining the meaning of a currently useless
>pair of numbers.  It should be obvious that there is no way to regenerate
>this info (except by "eyeball adjustment") at any later date.
>
>> 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.
>
>Exactly.  What I'm proposing is a way to include that number without
>breaking the existing file format.

But it does break.  The screen size is in there so that multiple images
stored in one file have a place to go.  My GIF decoder makes a frame as
big as the screen and then renders each image into this frame.  And
it's not just me- that's the right thing to do.  If you record a bogus
screen size, you could really break things.  Even if it didn't break,
the picture might have a really funny border around it.

Multiple images in one file allow you to make a picture with many
colors by breaking it up into little tiles.  That way I could get more
than 256 colors in a picture if I wanted.  It's standard and it's
useful.  It's especially useful for broadcasting several little
"window" pictures to a terminal.  (I'm sure that was the original
idea.)

Since I don't use GIF locally here, my tool (giftorgb) creates three
files (foo.[rgb]) that are just raw byte dumps of the frame.  From
that, I can process the image any way I need and then recode it into
whatever format later.

>I agree, but GIF is sufficiently popular and storage-efficient that
>it's not likely to go away just because I don't like it.  Better to
>offer a constructive and reasonably painless proposal for fixing it.

Another poster proposed adding a new '!' block to the format.  That's
the right way, and a good idea.  My comments about that are under
separate cover.

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