Path: utzoo!attcan!uunet!snorkelwacker!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!ahg
From: ahg@mentor.cc.purdue.edu (Allen Braunsdorf)
Newsgroups: comp.graphics
Subject: Re: solution: pixel aspect ratio in GIF images
Summary: Extension block should apply to whole screen
Message-ID: <12238@mentor.cc.purdue.edu>
Date: 17 Jul 90 21:14:45 GMT
References: <9866@pt.cs.cmu.edu> <9894@pt.cs.cmu.edu> <12198@mentor.cc.purdue.edu> <9922@pt.cs.cmu.edu> <10454@odin.corp.sgi.com>
Reply-To: ahg@mentor.cc.purdue.edu (Allen Braunsdorf)
Organization: Purdue UNIX Group
Lines: 85

In article <10454@odin.corp.sgi.com> jindak@surfside.esd.sgi.com (Chris Schoeneman) writes:
>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 popular and efficient].
>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.

That's the right way, and I like it.  One problem: only one of these
should be allowed per file.  That is, it should describe the screen's
pixels and all the images in the file need to comply to it.  Otherwise,
it's a lot messier to decode.  I dump the screen into files and then
aspect ratio correct the whole thing.  If the aspect ratio could change
between images, I'd have to really beef up my GIF decoder.

It seems to me that the whole screen should have the same kind of pixel
anyway, so this limitation is in the spirit of the original idea (of
several images as part of a larger graphic screen on a single device).

How hard is it to amend the GIF definition?  Didn't they do it a while
back to allow Amiga HAM images?

>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.

If coloration is not a problem, they should probably filter the rows to
fit their display.  When I convert GIFs to 24 bit color images, I can
do this easily, but for a 256 color display it could be difficult.  Of
course, users with less than a 256 color display have to recolor the
image anyway, so this is probably less additional trouble there.

Some of the programs I've seen don't handle some pictures very well.
Usually it's because they either don't recolor or resize the pictures
nicely.  Do you suppose that if these programs were enhanced to use
accurate aspect ratio information they might improve in other ways as a
side effect?

>Comments or suggestions?

This extension block should come before the first image in the file and
(as I said above) should apply to the whole screen.

Has anybody else proposed this?  It seems that someone in then PC world
(with its many graphic modes with different aspect ratios) would have
demanded this a long time ago.

PC GIF decoders often make you pick the graphic mode to use for
display.  If they had this, they could use the aspect ratio and number
of colors to get a really close mode match (if it came from a machine
with the same graphic modes, it would be exact), or process the image
to make it fit whatever mode you wanted.

It sounds like a good idea to me.  If this were official, I'd probably
start using GIF for some things.

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