Xref: utzoo comp.graphics:12422 alt.graphics.pixutils:159 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.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: It depends on which method breaks more programs Message-ID: <9938@pt.cs.cmu.edu> Date: 17 Jul 90 22:21:02 GMT References: <9866@pt.cs.cmu.edu> <9894@pt.cs.cmu.edu> <12198@mentor.cc.purdue.edu> <10454@odin.corp.sgi.com> Organization: Carnegie-Mellon University, CS/RI Lines: 54 In article <10454@odin.corp.sgi.com>, jindak@surfside.esd.sgi.com (Chris Schoeneman) writes: > ... 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: > > [ straightforward extension block defining assumed pixel aspect ratio ] That's the obvious solution, and certainly the logically cleanest one. Why did I propose hacking up the screen size values instead? Because *not all GIF readers handle extension blocks*. In particular, the two that I have here (Patrick Naughton's gif2ras and xgif) choke on any extension block. These particular two seem to be descended from a common ancestor, which may well have other progeny. Sure, these readers violate the published standard; but they are pretty widely used. Meanwhile, in article <12234@mentor.cc.purdue.edu> ahg@mentor.cc.purdue.edu (Allen Braunsdorf) writes: >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. [I assume Allen means "makes a frame as big as the logical screen size indicated in the file header", not "as big as the display the decoder is using". I could argue that it wouldn't be difficult to handle multiple images this way without using the file's screen size, but that's really not the point here.] So what we've got are two different proposals, each of which breaks a different subset of the GIF readers currently out there. On aesthetic grounds the extension-block approach is certainly superior, but I'm not at all sure that it is superior on backwards compatibility grounds. It would be nice to get some hard data on the following points: 1. How many existing GIF readers pay any attention to the screen size numbers (as opposed to the image size)? 2. How many existing GIF readers correctly skip over unrecognized extension blocks? I don't have any easy way of finding out either of these things. Perhaps someone on the net knows the answers. Don't get me wrong --- I'd be glad to see Chris's proposal (or *any* solution) adopted. I just think that a high degree of backwards compatibility is going to be necessary to make the thing fly. I suspect that redefining the screen size fields would create fewer compatibility problems than adding an extension block. -- tom lane Internet: tgl@cs.cmu.edu UUCP: !cs.cmu.edu!tgl BITNET: tgl%cs.cmu.edu@cmuccvma CompuServe: >internet:tgl@cs.cmu.edu