Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!ccavax!lmrc!hassinger
From: hassinger@lmrc.uucp
Newsgroups: comp.sys.amiga.hardware
Subject: Re: (Non) Square Pixels?
Message-ID: <5125@lmrc.uucp>
Date: 2 Mar 90 17:25:41 GMT
References: <4687@lmrc.uucp> <3119@cello.UUCP> <943@tardis.Tymnet.COM> <11032@saturn.ADS.COM>
Organization: Liberty Mutual Research Center, Hopkinton, MA
Lines: 63

In article <11032@saturn.ADS.COM>, xanthian@saturn.ADS.COM (Metafont Consultant Account) writes:
> In article <943@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes:
> 
>>The shape of the dots of phosphor and the number of phosphor dots
>>per square inch do not really affect the shape of the pixels.
> 
> This discussion would be a lot clearer, and blessedly shorter, if the
> originating posting for the thread, or any other posting along the
> way, had bothered to state that what we would like to be square is the
> imaginary rectangle formed by connecting the _centers_ of the (almost
> inevitably _round_) phosphor dots or dot clusters in a two by two
> array of addressable pixels on an (ideal) screen, not particularly the
> dots or dot clusters themselves being square.

[lengthy, interesting discussion but not on the real issue...]

> The standard solution for decades now has been to do an aspect ratio
> correction before deciding what picture pixels to illuminate, so that
> circles come out round on the screen, whenever that is feasible.
> 
> Some nice things don't work out well though; bit images don't rescale
> nicely by aspect ratios that aren't powers of two, so doing a 90
> degree flip of a font character is likely to change its vertical to
> horizontal size ratio in its own coordinate system, because copying
> pixels is much more satisfactory than resampling them for this task.

Yes, this is the real issue...

> Similarly, scanned images are likely to look like accordians as they
> are subjected to quarter turns, because the cpu cycles needed to
> maintain the aspect ratios by resampling would slow the turns to a
> crawl, and the color change artifacts caused by resampling would be
> even more objectionable than the aspect changes.  Trust me, I've coded
> this one.
> 
> The world is full of compromises; aspect ratios "should" be square;
> they rarely are.

In my particular case the issue is not real time (Dpaint III animation:
calculations done in non-real time, results saved to ANIM file for later real
time playback).  Dpaint does not try to do the resampling that would be
required to maintain the correct aspect ratio for rotations.  I take it this is
either because it was ignored, determined to not be worthwhile, or because the
results produced be resampling are very poor.

I tried an experiment and found resampling to correctthe aspect ratio produced
very poor results.  As with any sampling, it may be possible to improve on a
simple algorithm at the expense of considerably greater compute time.

Note all this applies only to the rotation of image data that is in bit map
form. In rendering programs that represent the basic image description
mathematically, it is not a problem since the aspect ratio correction is
applied in the process of rendering each frame.

I think the point is that on the Amiga the aspect ratio is about 11:10 so it
would seem that for just a 10% gain in horizontal resolution we give up the
advantages of a 1:1 aspect ratio or "square pixels".

> xanthian@well.sf.ca.us (Kent Paul Dolan)


Bob Hassinger
...uunet!ccavax!lmrc!hassinger