Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!utfyzx!oscvax!omnitor!ktureski
From: ktureski@omnitor.UUCP
Newsgroups: comp.graphics
Subject: Re: Intelligent scaling of bit-mapped graphics (Help!)
Message-ID: <1120@omnitor.UUCP>
Date: Mon, 19-Jan-87 11:59:24 EST
Article-I.D.: omnitor.1120
Posted: Mon Jan 19 11:59:24 1987
Date-Received: Wed, 21-Jan-87 19:47:19 EST
References: <2872@gitpyr.gatech.EDU> <2406@well.UUCP> <3385@milano.UUCP>
Organization: Omnibus Computer Graphics Inc.
Lines: 57

> > In article <2872@gitpyr.gatech.EDU> dave@gitpyr.gatech.EDU (David Corbin) writes:
> > >I am looking for information (programs, algorithms, references to texts)
> > >on how to scale a bit-mapped image from one resolution to another, in an
> > >intelligent manner....
> 
> What you need to do is find a surface-fitting algorithm.  You will
> feed it your data as (X, Y, Z==pixel_value) tuples.  The algorithm
> will fit a surface to the data.  Then you can use the surface to
> compute New_Z = f(New_X, New_Y) where f is the interpolation function
> as applied to the surface.

True, but I think overly complex. Simply consider the problem as a pair of
2D passes ... to go from m*n to M*N, use a pass in X to interpolate the m
values into M, then another pass in Y interpolate those results from n to N.

You can use cubic interpolation if you like, but linear suffices visually.
In fact, you can cheat on that too ...

Consider the case where you wish to triple the width and height of the image,
Our usual resolution is 512*484. But to save time in tests, we'll compute at
"ninth res" and scale up to something close enough to 512*484. Using code in
the Ikonas bitslice, we can do the scale in a couple of seconds.

So here's what your pixels look like in the original scan line:

		abcde

And this is what you want to end up with (I chose to interpolate only):

		aIJbIJcIJdIJe

where I and J are interpolated values. Using linear interpolation, we get

		I = (2 * a + b) / 3
		J = (a + 2 * b) / 3

To avoid the division, I cheated, and used

		I = (3 * a + b) / 4	[really I = (a + a + a + b) >> 2]
		J = (a + 3 * b) / 4	[really J = (a + b + b + b) >> 2]

Visually, one could not tell which of the two methods was used (and our
animators have good eyes for such things!). As a simple example, suppose
a=1 and b=4. You'd expect the values for I and J to be 2 and 3 respectively.
And that's what the first method gives. The other method produces I=1.75
and J=3.25 ... the sum of a+I+J+b is the same however, and that's one reason
why the difference is negligible. Other factors include the way the pixels
are displayed on the screen (they cover more area than they should, and mix
together anyway).

Kevin M Tureski
Omnibus/Abel
2180 Yonge St. Toronto, Ontario, Canada  M4S 2B9

UUCP:   {allegra,decvax,ihnp4,utcsri}!watmath!omnitor!ktureski
QUOTE:	But some day you will be old enough to start reading fairy tales again.
								   C. S. Lewis