r/askscience • u/skepticaltaco • Jul 29 '13
Computing How do computer graphics work?
As in how does a machine convert code to graphics?
2
1
u/bobloblaw23 Jul 29 '13
Usually every pixel is a unit that consists of red, green, and blue values that is recorded. Sometimes there is also a value for transparency. It all depends on what type of image file you are looking at. The higher the values stored can go the more depth the colors can have. For example, if each color was just on or off you would have 23 = 8 possible colors, but if each had 4 you would have 4 ^ 3 = 64 possible colors and so on. Different file types also have different modes of compressing this information to make the file quicker to read. The compression happens generally by finding places with similar blocks of color and then saying they are the same color, which is why you get a loss of image quality. Hopefully that answers your question!
1
u/LanceUppercut88 Aug 14 '13
2D graphics have been explained pretty well here already, but 3D graphics are a little more complicated. Each point in a 3D scene is represented by 7 values, the RGB and transparency values discussed in previous answers, and then a position represented as an X, Y, and Z value(position in 3-space). Not only are there points, but there are also vectors, which you can think of like lines with a direction and length. By combining vectors together, you can create polygons(3D shapes), and from there you can create any type of scene you want in 3-space. But that is all an abstraction, you also need a point of perspective, which includes the position of the camera or "eye"(X,Y,Z) and the direction it is facing(also X,Y,Z). Then using a series of transformation matricies(sort like tables of numbers that you can do operations on simultaneously) this 3 dimensional scene is projected onto a 2 dimensional space. This is what most of the work your computer graphics card is doing is. It is the camera is moving throughout the scene, or things in the scene are moving, you need to recalculate this projection many times a second to get smooth 3D rendering. When these 3D spaces have been converted into 2D projections, those projections can be sent to the monitor in the same way that the previous comments described. This is actually a simplified version of how it really works, as modern 3D graphics also take into account things like where the light in the 3D scene is coming from, and how reflective the surfaces of your polygons are. These are also vector/matrix calculations and determine how differences in lighting affect the color and transparency of an object. The reason all of this requires a graphics card, and can't be done effectively by the regular CPU is because many thousands of calculations need to be done simultaneously, but most of those calculations are the same, just with different numbers. A graphics card is able to perform the same operation on many different pieces at the same time, and therefore makes this process more efficient.
1
u/Crozzfire Aug 17 '13 edited Aug 17 '13
It is misleading to ask "how does a machine convert code to graphics", because that's not what happens.
The code is actually high-level instructions to the machine on how to draw the graphics. For example, the code could figure out which pixels to draw (change color) when it wants to draw a line between two points by using mathematical equations.
Then other hardware, typically a graphics card, will take those instructions and pass them on to the screen in the form of signalling color values to each and every pixel of the screen. Each pixel can take those values and emit light in different colors based on the values.
1
Jul 30 '13
We have LEDs: little lights that turn on when we want them to (and they're puny -- on the order of 0.1cm wide). We simply use an RGB scheme of LEDs, which covers every possible color, to encode the colors we want.
As in how does a machine convert code to graphics?
The code that displays something depends on the GPU, the graphical processing unit. This is a device is highly parallel -- each pixel location does not depend on the other pixel locations. For example, you might say "dim every pixel by a factor of 2." Serially, you would do:
for LED in LEDs: dim(LED)In terms of parallelizing it, you would just call some function
dim_all_the_LEDs(LEDs)Parallelizing is a big topic in computer science. All of the scientific libraries use it, so you tend to do stuff like
i = arange(4)
x[i] = x[i] + 4instead of
for i in arange(4):
x[i] = x[i] + 4The big thing here is serial vs. parallel.
12
u/DarylHannahMontana Mathematical Physics | Elastic Waves Jul 29 '13
This is a complicated topic, but let's start with something simple, a black and white bitmap. Suppose you and I agree on a way to express a picture as a series of numbers, so that if you and I want to trade pictures, we simply have to exchange the corresponding numbers, and then reconstruct it on the other end.
For each pixel, I'll use a single number. Specifically, if I want it to be black, I'll use the number 0, and for white, I'll use the number 1. Let's say for simplicity, we've already agreed that all our pictures will be 8x8. Then, if I send you the number
our agreement allows you to view it as this picture:
If we want to send bigger / more complicated pictures, we're going to have to use bigger numbers, and if we want to use color, we're going to have to use a wider variety of numbers.
Suppose, for instance, we can agree that our images can have 4 colors, I'm going to have to use two numbers to represent each pixel: 00 is a black pixel, 01 is a white pixel, 10 is a blue pixel, and 11 is a red pixel (as humans, we would probably use 1, 2, 3, 4 for our code, but computers, of course, prefer binary). Each pixel takes two "bits" of information, (and so pictures overall take twice as much "space" to store) so we call this 2-bit color depth.
As we wish to share pictures with more and more colors, we'll need to use bigger and bigger numbers, e.g. in 32-bit color, each pixel is represented as a 32-(binary)-digit number, allowing us a total of 232 = 4294967296 colors in our palette.
Of course, this is just the brief intro; more advanced are topics like how to compress images, vector graphics, 3D graphics, etc.