Xref: utzoo comp.graphics:12368 alt.graphics.pixutils:149 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!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: Summary and possible solution: pixel aspect ratio in GIF images Message-ID: <9894@pt.cs.cmu.edu> Date: 13 Jul 90 15:39:58 GMT References: <9866@pt.cs.cmu.edu> Organization: Carnegie-Mellon University, CS/RI Lines: 63 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. 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, one of 640x350 pixels for an IBM EGA display. In either case, the standard physical screen aspect ratio is 4:3, so a CGA pixel has aspect ratio 1.2, an EGA pixel about 1.37. VGA displays fill the same physical screen with 640x480 pixels, so their pixels are square. Images of other dimensions might have come from anywhere. From Cameron Simpson : > The FBM doco remarks that the assumed aspect ratio > when converting a GIF is 1.2, but I've seen 1.0 and 1.1 and even 2.2! > I'd use 1.2 as a first guess. A muttered curse on people who produce > monitors with non-square pixels may also be in order. [Amen! -- tgl] Brian Moffet (brianm@sco.COM) says "most monitors are 4x3". Since a GIF file's header contains fields for screen width and height in pixels (which need NOT have anything to do with the image dimensions), one could derive the intended pixel aspect ratio by assuming that the specified pixel height and width fill a 4x3 physical area. Unfortunately, > most programs that write GIF Files do not take into account > the screen size. They either write the image size there, or something > else. So, you're pretty much hosed when you try to use that as a > method of finding out the size of the original screen the picture > was developed on. 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. Any comments? -- tom lane Internet: tgl@cs.cmu.edu UUCP: !cs.cmu.edu!tgl BITNET: tgl%cs.cmu.edu@cmuccvma CompuServe: >internet:tgl@cs.cmu.edu