CSE605 Computer Graphics Scan Conversion

CSE605-Computer Graphics-Scan Conversion

-1-

Graphics Devices Scan Conversion

• Raster-Scan Displays and the Frame Buffer • Graphics Software • Windows-Based Graphics Systems • Fundamental Concepts • Scan Conversion

o Lines o Circles o Flood Fill o Character Generation o Anti-Aliasing

• Data Visualization Raster-Scan Displays and the Frame Buffer There are many different types of displays but the one in which we are most interested is the one most of us use each day, whether on a Mac, PC or workstation: a raster-scan display. The operation of a raster-scan display is based on a cathode-ray tube (CRT). A beam of electrons (cathode ray) is emitted by an electron gun. This beam passes through a focusing and deflection system which directs the beam toward specified positions on a phosphor-coated screen. The phosphor then emits a small spot of light at each position contacted by the electron beam. This flicker of light fades very quickly so, in order to maintain the picture on the screen, the picture must be redrawn repeatedly by directing the electron beam back over the same points.


-2-

Each phosphor point corresponds to a pixel. Raster-scan displays construct a picture from these individual points of light. The information stored for an image corresponds directly to the image on the display as shown below. In this example, the display is bi-level, i.e., each pixel is either on or off (a monochrome monitor). The raster image is stored, or “buffered” in an area of memory called the frame buffer. The frame buffer represents a Cartesian plane with an origin defined either at the lower left corner or upper left corner. To get the image from the frame buffer onto the screen, the image is scanned row by row from top to bottom, left to right, just like an ordinary TV. The CRT beam paints out a sequence of scan lines, one above the other. Each position of the beam on the screen corresponds to one pixel and the values of these pixels are read out from the frame buffer in sync with the beam position. For the image to be refreshed (and not flicker due to the fading of the phosphor), it must be scanned many times a second. Typical refresh rates are 60 times a second. There are other types of displays. In a random-vector display, the electron beam may be directed to any random point on the screen under program control. The display frame is created by moving the beam over the screen in the pattern of the image to be created. Liquid-crystal displays are very common in appliances (microwaves, digital clocks) and in laptops. They are flat, light and draw less power than raster-scan displays. LCD displays utilize two sheets of polarizing material with a liquid crystal solution between them. An electric current passed through the liquid causes the crystals to align so that light cannot pass through them. Each crystal, therefore, is like a shutter, either allowing light to pass through or blocking the light.


-3-

Our discussion thus far has focused on monochrome displays. In order to create color images on a raster-scan display, we need something more. First, we need more than one electron gun and more than one type of phosphor (which is all we needed for monochrome). A color display has three electron guns and three types of phosphor (one glows green, one red and one blue). The phosphor-coated screen of a color display has a “triad” pattern for each pixel. The focusing and deflection circuitry is much the same as in monochrome except three beams are being deflected now instead of just one. They all strike the screen at the same time and in the same place so that each gun hits its element of the triad. Actually a mask with tiny holes called a shadow mask is carefully positioned inside the tube of the display so that each of the beams can hit only one type of phosphor. Each gun always hits the phosphor of a particular color so for convenience, we talk about a “red” gun, “green” gun and “blue” gun, although the guns are the same.

For color, we also need to store more information about each pixel in the frame buffer. Each pixel color is represented by several bits, and conversion circuitry converts the digital representation of each pixel value into appropriate intensity values for the electron guns. If a pixel is described by b bits, there will be 2b possible values for its colors. Consider 6 bits per pixel. This is called a “6 bit/pixel” frame buffer and it can be implemented as 6 bit “planes” of memory in the frame buffer. The six bits that represent the pixel value give us 64 possible colors where two of the bits are routed to the green gun of the CRT, two to the red gun and two to the blue gun. Thus, each of the guns can be driven at four possible intensities: bit values relative intensity 00 0 (dark, i.e., none of this color) 01 1/3 (dim)

Electron Guns

Red Input

GreenInput

Blue Input

Deflection Yoke

Shadow Mask

Red, Blue, and Green

Phosphor Dots

CRT


-4-

10 2/3 (brighter) 11 1 (brightest) The digital value (e.g. 01) is converted to the analog value (1/3) by a DAC or digital-to-analog converter. This is an electronic device designed to convert logical values to voltage values. Each electron gun has a DAC and the intensity of its beam is driven by the output voltage of the DAC. Because each gun has four possible intensities in this example, 4 * 4 * 4 = 64 possible colors can be displayed. For example, suppose a given pixel has the value 011100:

01 for red at 1/3 11 for green at 1 00 for blue at 0 What we see is bright green and dim red giving us a faint yellow. This way of implementing color is called a direct color system because the pixel bits directly control the color displayed. Since it is typical these days to have 24 bits/pixel (8 bits for each RGB), over 16 million colors are possible. We might implement this as described above where we would have 24 bit planes that directly control the display device. But this requires a lot of memory (at least 3 megabytes for the frame buffer depending on the screen resolution) and is inefficient in general. Instead, many raster-scan displays have a color lookup table or CLUT that defines all the colors that can be displayed simultaneously on the screen. An index identifies each color in the table and specifies the amount of red, green and blue that it contains. To draw a

Green

Red

Blue

N

N

N


-5-

particular color, the application stores the CLUT index of the color into the pixel location in the frame buffer. Many color displays are capable of displaying a wide range of colors. Unfortunately, however, the number of colors that the screen can render at any given time may be limited. For example, a display that can potentially produce 16 million colors may be able to show only 256 of them simultaneously due to hardware limitations. When such a limitation exists, the device often dynamically maintains the CLUT. A dynamically maintained CLUT is called a palette in Windows. When an application requests a color that is not currently displayed, the device adds the requested color to the palette. When the number of requested colors exceeds the number possible for the device, it maps the requested color to an existing color, i.e., the colors displayed are different than the colors requested. When this happens, the system tries to replace requested colors with similar existing ones, so the difference between them is often small. Interactive raster-scan systems usually consist of several processing units. In addition to the CPU, there is usually a display controller that exists on a separate board. Here is the organization of a simple system:

Typically, a fixed area of memory is reserved for the frame buffer, and the display controller is given direct access to the frame buffer. A number of other operations can be performed by the display processor, besides the primary chore of refreshing the screen from the data in the frame buffer. Some transformations can be performed: areas of the

Display processor

memory

Frame buffer

Video controller Monitor

System memory

CPUPeripheral

devices

System bus

Display processor

0100

001

1

67

100110100001

0

67

255

1001 1010 0001

R G B

REDGREEN

BLUE

Pixel displayedat x', y'

Pixel inbit mapat x', y'

0 x0

y

x max

maxy

Bit map Look-up table Display

0100

001

1

0100

001

1

67

100110100001

0

67

255

1001 1010 0001

R G B

REDGREEN

BLUE

Pixel displayedat x', y'

Pixel inbit mapat x', y'

0 x0

y

x max

maxy

Bit map Look-up table Display


-6-

screen can be enlarged, reduced, or moved. The CLUT is also located on the display controller. Some display controllers have on-board memory for two frame buffers so that one can be used for refreshing the display while the other is queued up with the next frame to be shown (this is required for smooth animation). Many systems have a separate display processor on the display controller board. The purpose of the display processor is to free the CPU from the graphics chores. A major task of the display processor is digitizing a picture definition given in an application program into a set of pixel-intensity values to be stored in the frame buffer. This process is called scan conversion. Graphics routines specifying straight lines and other geometric shapes must be scan converted into a set of discrete pixels. Graphics Software Our focus in this course is on writing graphics applications. Graphics require that programs control specific graphics displays but many general-purpose languages do not contain graphics routines. The programmer must either write these routines or acquire them. In order to understand some of the issues involved, consider the following simple example.

This is, of course, a picture of a baby. It’s one of those international symbols that everyone is supposed to recognize regardless of nationality, and parental status. If we want to draw this with a computer we need to decompose it into primitive shapes or lines so that a sequence of calls to various graphics routines can create it. At first glance, the shape looks rather complex but it really isn’t:


-7-

Circles and rectangles are all we need, along with the ability to tilt and fill. void circle(int cx, int cy, double radius, Boolean filled); void rectangle(int cornerx, int cornery, double width, double height, double angle, Boolean filled); All we need is to draw the 15 objects in the right places, which really isn’t too hard to do. The question now is how do we write circle and rectangle so that they work properly given the hardware that we are using? There are a couple of options. One can use embedded graphics routines that come with a programming environment for a particular language. These routines are designed to work on a specific hardware configuration and thus, are device dependent. So to draw the above picture, one checks the user manual or the “.h” file to learn how to use the graphics routines, assuming one also has the appropriate hardware. The other approach is an independent graphics package which provides graphics routines for a general-purpose programming language. These packages include the drawing routines and a set of device drivers which control the hardware. A device driver is a collection of low-level routines that send codes and commands to a specific graphics device. Here is the process:

1) Programmer writes program in programming language with a particular graphics package in mind, making calls as needed to its drawing routines.

2) Programmer compiles program. 3) Graphics display is chosen and the application, graphics package, and

appropriate device driver are linked into an executable. The ideal scenario is if we want our code to work for a different display, just link in a different device driver without any changes to the application. This is true device independence. It is achieved by careful design of the graphics package. Suppose you have a function: void Line(double x1, double y1, double x2, double y2);


-8-

in the graphics package. What does it have inside it? { int xa, ya, xb, yb; /* maybe some other stuff is done too */ ddLine(xa, ya, xb, yb); /* device driver’s line drawer */ } The function may do other things, but primarily it makes a call to the device driver’s line drawer. Every driver has a different version of ddLine to match a specific graphics display. The only way this all works, of course, is if all the different device drivers name their functions the same. That’s where the whole idea of graphics standards comes in – something Microsoft has implemented in Windows, and SGI has done in OpenGL. Microsoft Windows-Based Graphics Systems


-9-

Fundamental Concepts The underlying element of all computer-generated pictures is geometry. Because of the inherent geometry of the grid-based raster display, raster graphics pictures are composed of geometric elements, such as points, lines, circles, arcs, triangles, and rectangles known as primitives. We essentially draw pictures on the raster by connecting dots, i.e., by drawing lines from pixel to pixel to create graphical primitives. These primitives serve as the basic building blocks in the construction of more complex objects.


-10-

We typically think of computer-generated pictures as existing in two or three dimensions. The fundamental difference between 2-D and 3-D graphics is that 2-D pictures appear flat, and 3-D pictures appear to have volume. Note that 3-D objects are created from 2-D primitives. A user may describe an irregular 3-D object like a tree trunk, but the computer would deal with this by dividing it into 2-D primitives. It calculates shape, placement and orientation of an object based on its geometric components, such as triangles and rectangles. Scan Conversion: Lines Now that we have a better understanding of the hardware and basic concepts involved in creating graphics software, we turn to the algorithms for scan conversion. These are the algorithms that determine which pixels to illuminate to draw a line or a circle or some other primitive. We know that the frame buffer consists of R rows and C columns each of memory elements which correspond to pixel locations on the screen. Each memory element either contains or references b bits of information which can generate 2b different colors or intensities for each pixel. To do scan conversion, we will assume the existence of a routine called SetPixel(row, col, C) which computes the memory address in the frame buffer for a pixel at row, col, and loads value C (which is either the color or the index for that color in the palette) into that address. To scan convert a line, we use SetPixel to set the pixels between the two designated endpoints of the line so the path will represent a good approximation of the ideal line segment that joins the endpoints. The following simple routine is our first pass at scan converting a line. The function works directly in device coordinates, i.e., the rows and columns of the frame buffer to determine which pixels lie closest to the ideal line. void scLine(int col1, int row1, int col2, int row2, int color) // draws a line from (col1, row1) to (col2, row2) in given color { double dy, dx, y, m; int x; dx = col2 - col1; dy = row2 - row1; m = dy / dx; y = row1; for (x = col1; x <= col2; x ++) { SetPixel(x, round(y), color); y = y + m; } }

For each x value, we use the slope of the line to find the ideal value y and then use round() to get the nearest pixel position. If we want to draw a line from (1,1) to (5,6), this routine would do the following: dx = 4; dy = 5 m = 1.25; y = 1


-11-

for x = 1 through 5 { SetPixel(x, round(y), color)

/* (1,1) (2,2) (3, 4) (4, 5) (5, 6) */ y = y + m } What are the limitations and disadvantages of this routine? This function is clearly not the best way to scan convert lines. An IBM researcher named Jack Bresenham came up with an algorithm in 1962 for scan converting lines using only incremental integer calculations. This means the location of the next pixel on the line is based on information about the previous pixel. It’s an important algorithm because it is very efficient, and it can be adapted to display circles and curves. To illustrate Bresenham’s approach, we first consider scan-converting lines with positive slope less than 1. Here is what we need to do: ….. yk+2 y = mx + b y k+1 y k x k x k+1 x k+2…… We start at the leftmost end point, we step to each successive column (x position) and plot the pixel whose scan line (y position) is closest to the line path. In the above diagram, we will assume that we have determined (xk, yk) to be displayed. We now need to decide which pixel to plot in column xk+1. We have two choices: (xk+1, yk) and (xk+1,


-12-

yk+1). The actual “y” value for the line is between the centers of pixels yk and yk+1 (in column xk+1). What we want to do is set the pixel which is closest to this line. So all we have to do is define these distances (the distance from y k to the line and the distance from y k+1 to the line). The actual y value for the line is defined by: y = m(xk+1) + b We call the first distance (from yk to y) d1 and the second (from y to yk+1) d2. d1 = y - yk = m(xk+1) + b - yk d2 = (yk+1) - y = (yk+1) - m(xk + 1) - b One way of looking at this is the difference between these two distances will be negative if yk is closer to y and positive if y k+1 is closer: d1 - d2 = 2m(xk+1) - 2yk + 2b - 1 Let’s see if we can figure out a way to use only integers in this equation so the algorithm that we are defining will be as fast as possible. The only non-integer number in this equation is m which is equal to the ratio of two positive integers (assuming we are drawing a line from (x0, y0) to (xn,yn)): dy = yn - y0 dx = xn - x0 m = dy / dx We can define a decision parameter p; the value of this parameter will decide which y pixel we should set. To obtain this decision parameter, we re-arrange the d1 - d2 equation above, so that it involves only integer calculations. pk = dx(d1 - d2) = dx(2m(xk+1) - 2yk + 2b - 1) Substituting dy/dx for m and doing a little algebra gives us: pk = 2dy * xk - 2dx * yk + c The sign of pk must be the same as d1 - d2 since dx >0 (we started by saying we were going to deal with positive slopes between 0 and 1). “c” is a constant with value 2dy + dx(2b-1) which does not change as the algorithm increments from x0 to xn.


-13-

So, what does all this mean? Well, if the pixel at yk is closer to the line than the pixel at yk +1 (i.e., d1 < d2) then pk is negative. In that case, we set the lower pixel; otherwise we set the upper one. Coordinate changes along the line occur in unit steps as we move to the next row or column. So we can get the value of the next decision parameter using the previous one. At step k+1, we have:

pk+1 = 2dy * xk+1 - 2dx * yk+1 + c Subtract the pk equation above from this one gives us:

pk+1 - pk = 2dy(xk+1 -xk) - 2dx (yk+1 -yk) pk+1 = pk + 2dy - 2dx (yk+1 -yk) Why subtract these two equations? We got rid of the c and we also know that (xk+1 -xk) = 1 so that goes away too. The (yk+1 -yk) is either going to be 0 or 1 depending on the sign of p k. To get this all to work, we just have to calculate some simple variables as we move from x0 to xn. The starting value for the decision parameter is: p0 = 2dy - dx (we plug (x0 , y0) into the pk equation.) Here is the final algorithm: Bresenham’s Line-Drawing Algorithm for |m| < 1 1) Input two endpoints, store left endpoint as (x0 , y0). 2) Set (x0 , y0) in the frame buffer. 3) Calculate constants: dx, dy, 2dy and 2dy - 2dx; calculate starting value of decision parameter: 2dy -

dx. 4) At each xk, starting with k = 0 and going until k = n, perform the following test:

If pk < 0 SetPixel(xk + 1, yk, color) pk+1 = pk + 2dy else SetPixel(xk + 1, yk + 1, color) pk+1 = pk + 2dy - 2dx Here is an example that you can plot yourself to see how it looks:

Scan convert a line from (20,10) to (30,18). dx = 10, dy = 8, 2dy = 16, 2dx = 20, 2dy - 2dx = -4 and p0 = 6


-14-

SetPixel(20,10, color)

k pk (xk+1, yk+1) k pk (xk+1, yk+1) 0 6 (21,11) 5 6 (26,15) 1 2 (22,12) 6 2 (27,16) 2 -2 (23,12) 7 -2 (28,16) 3 14 (24,13) 8 14 (29,17) 4 10 (25,14) 9 10 (30,18)

What are the cases we must deal with to have a generic line drawing algorithm? Scan Conversion: Circles Circles are also frequently used as graphic primitives, so it would be helpful to have a fast way to generate their pixel patterns given some basic information (center_x, center_y, radius). The most obvious way to draw a circle is to use the distance relationship between the center point (xc, yc) and a point on the circle (x, y) which is distance r from the center. This is defined by the Pythagorean Theorem: (x - xc)2 + (y - yc) 2 = r2 So all we have to do is step through x values and calculate the corresponding y values using a re-arrangement of this formula: y = yc ± sqrt(r2 - (xc - x) 2) What are the problems with this approach? Another way to do this is to take advantage of the inherent symmetry of a circle. y (x,y) x Notice that if we have the values for the (x,y) point in the Cartesian plane above, we can get seven other points around the circle very easily. What are the other points?


-15-

If we draw in the 45° angles (one is drawn), we divide the circle into 8 octants. Notice that these octants are symmetrical, i.e., circle sections in adjacent octants within one quadrant are symmetric with respect to the 45° line dividing the two octants. Taking advantage of this, we can generate pixel positions around a circle by calculating only the points within an octant. This speeds things up quite a bit, but the basic equation is still very slow to compute. Bresenham (of “Line-Drawing Algorithm” fame) did a similar algorithm for circles. We won’t take the time to go through the details but it’s worth a quick look. Consider the “best” pixels P = (x,y) to set in the octant just above the positive x-axis. In this octant, we increment the y value by 1 at each step, and calculate a new x value. Since we are below the 45° line, we will not have to change slope. Here is the situation. We have just set the black pixel and now we must figure out which pixel to set on the next round, pixel a or pixel b. We do this by figuring out which of these pixels is closest to a point on the actual circle.

Why are these the only two choices for the next pixel? The closer point can be found by finding the distances from each possible point to the true point (Xtrue, Ytrue) and then subtracting one distance from the other. By testing the sign of the result, we find which point should be used. Remembering that we are incrementing Y and calculating X in this octant, here is the formula for the square of the distance from the true point on the circle to the point on the right (b) which we will call Xlast: d1 = Xlast

2 - Xtrue2 = Xlast

2 - r2 + (Ylast + 1) 2 The last part of this formula comes from a substitution using the Pythagorean Theorem. The square of the distance from the point on the left (a) which we will call Xlast-1: d2 = Xtrue

2 - (Xlast -1) 2 = r2 - (Ylast + 1) 2 - (Xlast - 1) 2

We then calculate d1 - d2 for our decision parameter pi:


-16-

pi = 2(Ylast + 1) 2 + Xlast 2 + (Xlast - 1) 2 - 2r2 (*)

To find pi+1, we plug the next point (X current, Y current) into this formula. We know that Ycurrent is Ylast +1 and Xcurrent is either Xlast or Xlast -1. Since we don’t know which yet, we will just refer to it as Xcurrent. pi+1 = 2[(Ylast + 1) + 1] 2 + Xcurrent

2 + (Xcurrent - 1) 2 - 2r2 As in Bresenham’s line drawing algorithm, we now calculate pk+1 - pk. After much algebraic manipulation, we end up with: pk+1 = pk + 4Ylast + 6 + 2(Xcurrent

2 - Xlast 2) - 2(Xcurrent

- Xlast )

Depending on which point is closer to the line, the value (Xcurrent

- Xlast ) is either 0 or -1.

So the last term can be taken out and the constant becomes either 6 or 4. The (Xcurrent 2 -

Xlast 2) term will also cancel if Xcurrent

= Xlast, giving us the following simple formula: pk+1 = pk + 4Ylast + 6 This is what we need to find pk+1 when the point being plotted has the same X value as the last point. The other case is a little harder because of the squares: pk+1 = pk + 4Ylast + 8 + 2(Xcurrent

2 - Xlast 2)

Recall that Xcurrent

in this case = Xlast - 1 so we can do a substitution to get: pk+1 = pk + 4(Ylast - Xlast

) + 10 There is still a multiplication here but it is by 4, which is equivalent to shifting two bits to the left. All that remains is figuring out the initial value of p by substituting (X,Y) for (Xlast, Ylast) into the original “p” formula (marked with an asterisk above). We leave the rest for the reader to work out. Scan Conversion: Flood Fill In raster-scan systems, one way of defining regions is according to the color of the pixels which show where the region’s interior, exterior and boundary are. To tell where a region begins and ends, we must agree on some basic terms.

Two pixels are 4-connected if they are adjacent horizontally or vertically. Thus, the pixel at (10, 11) is 4-connected to the one at (10, 12) but not the one at (11, 12). Two pixels are 8-connected if they are adjacent horizontally, vertically, or diagonally. Thus, the pixel at (10, 11) is 8-connected to the pixel at (11, 12).


-17-

We’ll look at two simple filling algorithms. The first works on 4-connected regions. It changes every pixel of inside-color to new-color. It is called a flood-fill algorithm because it begins with a “seed” pixel in the interior of the region and floods the region with new-color spreading out from the seed pixel. The basic idea is simple: If the pixel at (x,y) is part of the interior (i.e., it has color inside-color), change it to new-color and apply the same principle recursively to its four connected neighbors. Notice we introduce a new routine in this algorithm: GetPixel(x, y) returns the color of the pixel at location (x,y). Recursive Flood-Fill for 4-Connected Regions void FloodFill(int x, int y, int inside_color, int new_color) { if (GetPixel(x,y) == inside_color) { SetPixel(x, y, new_color); FloodFill(x-1, y, inside_color, new_color); FloodFill(x+1, y, inside_color, new_color); FloodFill(x, y+1, inside_color, new_color); FloodFill(x, y-1, inside_color, new_color); } } How would you expand the algorithm to an 8-connected region? This is not efficient due to all the redundant checking that must be done. The second algorithm fills in “runs” of pixels. A run of pixels is a horizontally adjacent group of interior pixels. To see how this works, consider the following 4-connected region:

b

e

s a

d

c

fgh

j

i

“s” is the seed pixel. The run in which s is located (from a through b) is filled next. Then, the row above the a-b row is scanned (from a to b) to see if there is a run. One is found, and its rightmost pixel (c) is saved by pushing its address on a stack. Then, the row below is scanned from a to b; a run is found and its rightmost pixel (d) is pushed on the stack.


-18-

Now the stack is popped to give us a new seed (d) and the process is repeated. The run from d to e is filled and three new runs are found resulting in pushes of f, g, h. Pixel h is popped, its run is filled and two more runs are found (i and j are pushed on the stack). The process continues until the stack is empty at which point all pixels “reachable” from the original seed have been filled. Character Generation A necessary tool in the scan conversion toolkit is a character generator. Characters for our purposes are letters, numbers, punctuation and other symbols which must be displayed in a variety of sizes and styles. The overall design style for a set of characters is called a typeface or font. You’ve no doubt run into these before: Courier, Helvetica, Geneva, New York, etc. Two different methods are used for storing fonts. The simplest is to use grid patterns or bitmaps. To display the character, all we have to do is take a character grid and map it to a frame buffer position. We have one such grid for all the characters in a font.

The advantages of this approach are ease of implementation and speed. The downside is bitmap fonts require a lot of space because each variation in size and format (e.g., 10 point bold) is usually stored as a separate grid. There are techniques to modify size and format with just one stored font. Sizing techniques are more successful then format ones, as long as the size change is a simple integer multiple. To double the size of a character, for example, we can use pixel replication. What we do is take small sections of the original character grid, say 2-by-2 sections of pixels. We then create a 4-by-4 section by enlarging each 2-by-2 section in both directions. It is more difficult to enlarge by a non-integer factor or reduce the size of a character by a simple factor of two. Why? Format changes with bitmap fonts require a different set of characters for each format type. If we need to do more involved transformations, e.g., rotate a letter, bitmap fonts


-19-

are very limited. It’s easy to rotate by 180°, but to rotate at any angle requires a refashioning of the letter. The other, more flexible method of storing fonts is to use outline fonts. With this method, we describe the character shape using straight lines and curves (this is how it’s done in PostScript). Then we use one of the scan conversion fill routines to fill in the areas of the character. Outline fonts require less storage, but more time to process. We can produce bold, italic or different sizes by manipulating the curve and line definitions for the character outlines. The processing time is longer because of these manipulations, and also because the lines and curves and fills must be scan converted into the frame buffer. Anti-aliasing You have probably noticed that in raster-scan displays, we have a problem called the “jaggies”: that stair-step effect in lines at certain angles. This is a form of aliasing. It occurs because of the discrete nature of pixels, i.e., pixels appear on the display in a fixed rectangular array of points. If you draw a line at certain angles, the jaggies are very prominent; at other angles, not so much.

Aliasing arises in graphics from the effects of sampling. Samples are taken spatially, at different points. A pixel is set to a color based on the presence or absence of the figure to be drawn at one point (that point is the pixel’s center). In effect, the figure is sampled at this one point without checking other areas of the pixel. We are not looking “densely” enough within the pixel region; we could test more points if we want to minimize the problem. There are several techniques to perform anti-aliasing. An obvious thing to try is a higher resolution monitor. This makes the jags smaller in size relative to the figure being drawn (as shown above). Looking at software solutions, the basic idea of all anti-aliasing techniques is to “blur” or “smooth” the image. For example, if we are drawing a black triangle on a white background, we might use shades of gray pixels near the triangle’s border. When these


-20-

gracefully varying shades are looked at from afar, the eye tends to blend them together seeing a smoother edge.

We’ll take a look at one technique in detail: supersampling. When we apply supersampling, we take more than one sample per pixel. What we do is subdivide the pixel into subpixels. Then, we apply Bresenham’s algorithm (or whatever algorithm we are using) at this more dense level. But we don’t just set the pixel on or off, we apply different shades of gray (if we are in black/white), depending on where the pixels lie. The subpixels closest to the figure are darkest, the ones farther away are lighter shades of gray. The actual pixel value is the average of these samples. This has the effect of smoothing the stairstep effect by displaying a somewhat blurred line in the vicinity of the stairstep. There is a tradeoff for doing this: considerably more calculations per pixel. There are other anti-aliasing techniques but all share the idea of blurring the edges to avoid the jagged effect. So much for our whirlwind tour of scan conversion. We have only touched on the issues and complexities involved but hopefully, you now have a general understanding of what is involved in creating images on raster-scan displays. Sidebar: A Picture is Worth a Thousand Words (or a trillion data points) Graphics serve a critical role in data visualization. In certain applications, huge amounts of data are collected which are often difficult to analyze. Sometimes, a simple picture can reveal important relationships. A good example comes from the world of chaos. We first define a function for a basic parabola. For example, f(x) = 4δx(1 - x) where δ is some constant between 0 and 1. Beginning at a starting point for x0, between 0 and 1, the function is applied iteratively to generate the following sequence:


-21-

x1 = f(x0) x2 = f(x1) = f(f(x0)) x3 = f(x2) = f(f(f(x0))) etc. How does this sequence behave? It so happens that this function exhibits a very complex behavior and the only way to really get a feel for it is to display it graphically. The way we create the graph is we start with a point at (x0, x1), then draw a horizontal line to (x1, x1), then a vertical line to (x1, x2). In general, from the previous position (xk-1, xk), a horizontal line is drawn to (xk, xk) from which a vertical line is drawn to (xk, xk+1). If we use 0.1 for x0 and 0.7 for δ, we get a spiral effect where we converge on an attractor, or fixed point where f(x) = x. If δ is set to small values, the action is very simple, there is a single fixed point at x = 0. But as δ increases, something strange starts to happen. At δ = 0.85, for example, there appear to be several attractors. At the critical value of δ = 0.892486418, the effect is chaotic. For most starting points, the orbit is still periodic, but the number of orbits between repeats is very large. For other starting points, there is a periodic motion with very small changes in the starting point yielding very different behavior.

This remarkable phenomenon was first recognized by Mitchell Feigenbaum in 1975. Before then, most mathematicians believed that very small adjustments to a system of this nature should produce correspondingly small changes in its behavior. They also believed that simple systems like this could not exhibit such complicated behavior. Feigenbaum’s work spawned a new field into the nature of non-linear systems, known as chaos theory. Bibliography The above was derived from the following books. Refer to these if you’d like to know more about scan conversion.


-22-

Farrell, J.A., From Pixels To Animation. London: Academic Press, 1994. Foley, J., van Dam, A., Feiner, S., Hughes, J., Computer Graphics: Principles and Practice, Second Edition.

Reading, MA: Addison-Wesley, 1990. Hearn, D. and Baker, P., Computer Graphics, Third Edition. Englewood Cliffs, NJ: Prentice Hall, 2004. Microsoft Windows Software Dev. Kit: http://msdn.microsoft.com/ Pavlidis, T. Algorithms for Graphics and Image Processing, Rockville, MD: Computer Science Press,

1982. Rogers, D.F., and Earnshaw, R.A., Techniques for Computer Graphics, New York: Springer-Verlag, 1987. Sun Microsystems, Inc. An Introduction to Computer Graphics Concepts: from Pixels to Pictures, Reading,

MA: Addison-Wesley, 1991. Bresenham’s algorithms come from: Bresenham, J.E., “Algorithm for Computer Control of Digital Plotter,” IBM Systems Journal, 4: 25-30,

1965. Bresenham, J.E., “A Linear Algorithm for Incremental Display of Circular Arcs,” Communications of the

ACM, 20(2): 100-106, 1977. For more on anti-aliasing: Booth, K.S., Bryden, M.P., Cowan, W.B., et al, “On the Parameters of Human Visual Performance: An

Investigation of the Benefits of Antialiasing,” IEEE Computer Graphics and Applications, 7(9): 34-41, 1987.

Crow, F.C., “A Comparison of Antialiasing Techniques,” IEEE Computer Graphics and Applications, 1(1):

40-49, 1981. On chaos theory: Gleick, J., Chaos: Making a New Science, New York: Viking Penguin, 1987. Hofstadter, D.R., Metamagical Themas, New York: Basic Books, 1985.

Documents

CSE605 Computer Graphics Scan Conversion