Xref: utzoo comp.graphics:12395 alt.graphics.pixutils:154 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!zog.cs.cmu.edu!tgl From: tgl@zog.cs.cmu.edu (Tom Lane) Newsgroups: comp.graphics,alt.graphics.pixutils Subject: Re: solution: pixel aspect ratio in GIF images Summary: clarification of original proposal Message-ID: <9922@pt.cs.cmu.edu> Date: 16 Jul 90 23:26:36 GMT References: <9866@pt.cs.cmu.edu> <9894@pt.cs.cmu.edu> <12198@mentor.cc.purdue.edu> Organization: Carnegie-Mellon University, CS/RI Lines: 61 In article <12198@mentor.cc.purdue.edu>, ahg@mentor.cc.purdue.edu (Allen Braunsdorf) writes (in response to a previous post of mine): > >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 "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. 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. > >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). > > 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. OK, I wasn't aware of that. That means the range-check couldn't be as tight as I suggested, but it doesn't render the proposal unworkable. It would be easy to extend my proposal so that image creators could unambiguously indicate that they were supplying aspect ratio data per the new interpretation: just put small numbers, say less than 64, into the "screen dimensions" fields. A reader seeing "4x3" could be certain that it was computing a valid aspect ratio correction, whereas if it saw "320x200" it might want to confirm the correction with its user. > 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 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. -- tom lane Internet: tgl@cs.cmu.edu UUCP: !cs.cmu.edu!tgl BITNET: tgl%cs.cmu.edu@cmuccvma CompuServe: >internet:tgl@cs.cmu.edu