To understand why rich (or true) color was beyond the capabilities and price range of early systems, it is necessary to remember both the high costs of memory in the early days and to understand how computers create pretty images and colors on our monitors.
Given that since computers see everything in terms of bits, which can only have values of zero or one, it's easy to see how a computer would encode (or store) a pure black and white image. With each bit representing one pixel on the screen, the computer would use a value of zero to denote black and a value of one to denote white. By creating a huge two-dimensional array of these bits, a black line could be drawn on a white background by changing all of the bits between the start and end point of the line to values of zero, while leaving all of the other bits with values of one. This can be simulated by taking a piece of graph paper and coloring some of the blocks, while leaving others blank. Keep at it long enough and you can create a very blocky image of a person, or a dog, or anything.
Black and white images (or two-color images) were very economical due to the fact that it takes eight bits to make up a byte (or character) which means for a 1000x500 pixel image (500,000 bits), the computer could store this image in 62,500 bytes (or a bit less than 64Kb). In the early days, even 64Kb (a kilobyte is 1024 bytes) would have cost an arm and a leg since most computers only shipped with 16Kb. The only variable in deciding how much memory an image would take was the resolution, bigger images took up more memory and required more expensive machines, while reducing the image's resolution reduced the amount of memory needed to display the image. Here's an example of a rose rendered in black and white.
Got all that? Ok, let's talk about color. Early images were stored in such a way that only the best sixteen colors of an image were used. All the computer would do would be to take that full color image of the lovely rose and try to pick the sixteen colors that would best represent the image. The neat thing is that with a little work (and a technique called "error diffusion") you can store a decent looking picture of the rose while still saving space. Since four bits were all that were needed to store sixteen colors, it was possible to store two pixels per byte. Thus our 1000x500 pixel image could be stored in 250,000 bytes (or four times the size of the black and white image). Here's the same rose rendered using only sixteen colors.
Well, sixteen color images were good, but everyone wanted more, more, more! So they tried storing pictures using 32 colors or even 64 colors which resulted in images that were 25 to 50 percent bigger than the sixteen color images, but provided enough color depth that the images looked more and more real. Then, memory prices finally dropped enough that our computers could display an incredible 256 colors out of the thousands or millions of the colors in real life images. Images were definitely looking better and better, the only problem was that that same image of the rose that only took up 62Kb as a black and white image now used up 500Kb of memory (or eight times)! And images kept getting bigger and bigger (think about it, a modern 28.8kbps modem could move that 500Kb image across the phone line in about 3.5 minutes while an old 2400bps modem would have taken about 35 minutes). Anyway, here is a 256 color of the rose (looks pretty darn good doesn't it).
Ok still? Good, because it gets simpler. A lot of graphics images are now stored in what is known as a "true-color" or "deep-color" format which simply means that the image can store and reproduce an image containing thousands or millions of colors (which is a real as you need to get to fool the human eye). By using three bytes, with one byte representing 256 shades of red, the second byte encoding 256 shades of green, and the last byte encoding 256 shades of blue for each pixel and varying the intensities of each of these primary colors, computers were finally able to display "true-color" images (or so darn close you can't tell). Once again, images got bigger (our 1000x500 pixel image would eat up 1500Kb now, or 24 times the size of the original black and white image). This is one of the main reasons that people who create web pages should go extra light on the graphics (they get mighty big really quick). Okay, back off the soap box, here's the full-color image of our rose. Notice that even with a "true-color" or "deep-color" monitor, it's really hard to tell the difference between the deep color rose and the 256 color rose, but on larger images it becomes obvious which one is which.
In low-color or medium-color images (such as sixteen color or 256 color) the palette is used as an index for encoding each pixel in the image. Think of it as a code for figuring out which dab of paint to use when painting a single pixel. The first pixel might be brown, so we grab a bit of brown and paint that pixel, the next pixel is coded as blue, so we grab a bit of blue and paint that pixel, and so on...
So why not just use a 24 bit value for each pixel (in other words, why not just store it as a "true-color" image)? Because then the image would take up too much space (between three and six times more), and space is always a precious commodity when it comes to slow links like phone lines or limited spaces like memory. Which leads me into my next topic.
But as images gained more and more color depth and as resolutions increased, file sizes also increased geometrically, everyone was tired of getting messages that an image would take hours to transfer or that their diskette drives were too small to hold a given image. So along came some smart person who realized that there was a lot of repetitive information in most images (or a large area where colors were the same in their neighboring pixels).
Consider this, if you were to tell someone how to get to your house, you wouldn't say "get on Rte 111 and go a mile, then go another mile, then go another mile, then go another mile...", you would say "get on Rte 111 and go ten miles and then get on Rte 61". You've just compressed the information needed to tell someone else how to get to your house by using the fact that once they get on Rte 111 they don't have to do anything else until they get to Rte 61.
Compression is the removal of redundant information. That's it, and unless your're begging for a headache, that's all you need to know.
"Lossy" compression comes from the realization that when it comes to fooling the human eye, we can remove some information from the image to make it smaller and our eyes will never notice the difference. Our minds are so good at recognizing patterns from incomplete data that even when we looked at the black and white image of the rose, our mind still identified it as a rose, regardless of the fact that there was no color and much of the information was missing. So when we store an image using "lossy" compression, we drop some of the information in an effort to decrease the amount of space required to store an image, and when we retrieve the image from storage it will be missing tiny bits of information that we never noticed in the first place.
The downside to lossy compression is that if you keep storing and retrieving an image using lossy compression, it gradually loses it's crispness and clarity. (Like that old dollar bill in your pocket.) So if you are working on an image, use a lossless compression, then when you get a final product, use a lossy compression for distribution to save time and space.
In general, while the newer bitmap file formats include a limited method of compression, bitmap files are generally not efficient for transmission and storage of images due to their larger sizes when compared with GIFs or PNGs. One of the few good uses for bitmap files is when you want to turn that pretty picture you have into wallpaper for your desktop background.
Bitmaps can hold black and white images, low or medium color images (sixteen or 256 colors), and even 24 bit ("true-color") images. But if you are creating a background wallpaper, you'll want to reduce the number of colors in an image to sixteen or 256 colors in order to reduce the amount of memory required to display the image. On most computers with a 640x480 screen, a sixteen color image will eat up 256Kb (0.25Mb) of memory, a 256 color image will eat up 512Kb (0.5Mb), but a full 24 bit bitmap would use up 1.5Mb of memory. So to make things run faster, reduce the number of colors in your background wallpaper.
Unfortunately, UniSys gazed upon the code and the tremendous use of GIFs and found that CompuServe had used one of their patents and that UniSys could strong-arm the computer world and collect some revenue by requiring that everyone who's programs created GIFs needed to pay royalties to UniSys. After a firestorm that lasted almost two years or so, things have quieted down and most graphic programmers paid up. But GIFs are still on the way out of popular use so that everyone can tell UniSys to crawl back in its hole and continue contemplating its navel.
GIFs were so popular that almost every web browser out there supports using them for web page graphics where they are very useful for limited color images. A good rule of thumb is that if the image has less than 64 colors, and it fairly simple (like a drawing or cartoon) then the GIF file format is a good choice for storing the image.
Due to the UniSys snafu, most graphics programs now support another public standard called PNG, which is the successor to GIF.
A note or two about JPG compression factors, also known as the "quality" factor or the "Q" value. This is the magic value that determines how tightly the JPG algorithm will compress your image when storing it, the tighter it compresses the more information that will be lost from the image. Compress too far and you end up with a blotchy image that borders on surrealism. Most Q scales run from zero to 100, with 100 being almost no compression, and low values such as 5 or 10 resulting in blotchy, but very small image files. I've found that a Q of 100 works well for when I have a large image that I need to scale or crop so that it doesn't lose too much information during the "load scale save load crop save" gyrations. For long term storage, images that I care about get stored with Q values of 80 to 90 (the quality 80 images are half the size of the quality 90 images when stored), while images that I care less about get stored with Q values as low as 70. I've seen images stored with lower Q values and image quality deteriorates rapidly below 60, especially for smaller images.
JPGs are very popular on the web given their small sizes and the fact that one can display true color images while also tuning the quality factor to produce a smaller image if needed.
TIFF are good for storing all types of images, and until the advent of PNG were the preferred method for storing "lossless" true-color images. (The jury is still open as to whether PNG will take over or not.)
| Copyright 1996,1997,1998 Thomas G. Harold, All Rights Reserved |
| [email protected] - Last updated: Aug 1996 |
| Location: 39 deg W, 76 deg N |