Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!mips!sgi!shinobu!odin!surfside.sgi.com!jindak From: jindak@surfside.esd.sgi.com (Chris Schoeneman) Newsgroups: comp.graphics Subject: Re: solution: pixel aspect ratio in GIF images Message-ID: <10454@odin.corp.sgi.com> Date: 17 Jul 90 16:48:10 GMT References: <9866@pt.cs.cmu.edu> <9894@pt.cs.cmu.edu> <12198@mentor.cc.purdue.edu> <9922@pt.cs.cmu.edu> Sender: news@odin.corp.sgi.com Reply-To: jindak@surfside.esd.sgi.com (Chris Schoeneman) Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 79 In article <12198@mentor.cc.purdue.edu>, ahg@mentor.cc.purdue.edu (Allen Braunsdorf) writes: >Assumption of aspect ratio is an evil thing. And in article <9922@pt.cs.cmu.edu> tgl@zog.cs.cmu.edu (Tom Lane) writes: >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. I agree, too. But instead of messing with the format (at least the format's meaning), why not extend GIF within it's framework? GIF allows for "extension blocks" which all readers must accept. So I propose the following extension: 7 6 5 4 3 2 1 0 Byte # +---------------+ |0 0 1 0 0 0 0 1| 1 '!' - GIF extension block introducer +---------------+ |0 1 0 1 0 0 1 0| 2 'R' - For 'aspect Ratio' +---------------+ |0 0 0 0 0 0 1 0| 3 2 - Two bytes in block +---------------+ | pixel width | 4 - First part of ratio (numerator) +---------------+ | pixel height | 5 - Second part of ratio (denominator) +---------------+ |0 0 0 0 0 0 0 0| 6 0 - extension block end code +---------------+ Let byte four equal 'x' and byte five equal 'y' Then x:y is the _pixel_ aspect ratio. 'x' and 'y' should be relatively prime (ie they should have no common divisor except one), but they don't have to be. A 640x480 image for display on a VGA graphics system (IBM), would have a 1:1 ratio, so bytes four and five would both equal one. Note that the _image_ aspect ratio is 4:3, but the pixels are square. A more extreme example would be an image designed for display on an TRS-80. It would have a ratio of 5:12, since twelve pixels are as wide as 5 pixels are high. Dividing the image's pixel aspect ratio by your machine's pixel aspect ratio gives the number of pixels across per pixel down that need to be drawn to produce the image correctly. For example, let's assume a machine with a pixel aspect ratio of 1:2 (twice as high as wide). For an image with a 1:1 pixel aspect ratio: 1 - 1 1 2 2 --- = - x - = - So we need two pixels across for each one down. 1 1 1 1 - 2 For an image with a 4:3 pixel aspect ratio: 4 - 3 4 2 8 --- = - x - = - We need eight pixels across for three down. 1 3 1 3 (Or 2.667 pixels across per one down.) - 2 The latter example points out a problem. Should the decoder draw the image with each dot made with 8x3 pixels? This is entirely up to the decoder. It could instead draw horizontally three pixels, three pixels, two pixels for three points in the image. (On the next line it might try 3,2,3, then 2,3,3, etc.) The point is however the image is drawn, the aspect ratio is correct. Comments or suggestions? -Chris Schoeneman Chris Schoeneman | I was neat, clean, shaved and sober, jindak@surfside.esd.sgi.com | and I didn't care who knew it. Silicon Graphics, Inc. | -Raymond Chandler Mountain View, CA | (The Big Sleep)