[Home]
[Edit this page]
[Recent Changes]
[Special Pages]
[Help]
database » encryption » CppDefinition » WhatLinksHere » CurlUndocumented » userpage » executable » JavaScriptFAQ » CppVclGlossary » BeginnersGuideToCurl » JPEG
Displaying differences between revision 3 and the latest revision
= (Graphics) JPEG =¶
¶
Back to Graphics FAQ Main Page.
[purple][size=5][b]JPEG FAQS[/b][/size][/purple]
[b]1: What is JPEG?[/b]
JPEG stands for Joint Photographic Experts Group, the original name of the committee that wrote the standard.
JPEG is created for compressing any full-color or gray-scale image of natural, real-world scenes. It works well on photographs, naturalistic artwork, and similar material; not so well on lettering, simple cartoons, or line drawings. JPEG handles only still images.
JPEG is "lossy," meaning that the decompressed image isn't quite the same as the one you started with.(There are lossless image compression algorithms, but JPEG achieves much greater compression than is possible with lossless methods.)That is the size of a JPEG file is much smaller as compared to the file created by a lossless compression. JPEG is designed to exploit known limitations of the human eye, notably the fact that small color changes are perceived less accurately than small changes in brightness. Thus, JPEG is intended for compressing images that will be looked at by humans.
A useful property of JPEG is that the degree of lossiness can be varied by adjusting compression parameters. This means that the image-maker can trade off file size against output image quality. Conversely, if you aren't happy with the output quality at the default compression setting, you can jack up the quality until you are satisfied, and accept lesser compression.
Another vital aspect of JPEG is that decoders can trade off decoding speed against image value, by using speedy but imprecise approximations to the requisite calculations. Some viewers obtain remarkable speedups in this way. (Encoders can also trade accuracy for speed, but there's usually less reason to make such a sacrifice when writing a file.)
[b] 2: Why use JPEG? [/b]
There are two good reasons: to make your image files smaller, and to store 24-bit-per-pixel ( picture element) color data instead of 8-bit-per-pixel data.
Making image files smaller is a win for transmitting files across networks and for archiving libraries of images. Being able to compress a 2 Mbyte full-color file down to, say, 100 Kbytes makes a big difference in size and transmission time. JPEG can easily provide 20:1 compression of full-color data.
[b]3: How can the GIF and JPEG be compared? [/b]
If you are comparing GIF and JPEG, the size ratio is usually more like 4:1 .
Now, it takes longer to decode and view a JPEG image than to view an image of a simpler format such as GIF. Thus using JPEG is essentially a time/space tradeoff: you give up some time in order to store or transmit an image more cheaply. But it's worth noting that when network transmission is involved, the time savings from transferring a shorter file can be greater than the time needed to decompress the file.
The second fundamental advantage of JPEG is that it stores full color information: 24 bits/pixel (16 million colors). GIF, the other image format widely used on the net, can only store 8 bits/pixel (256 or fewer colors).
Many people are scared off by the term "lossy compression". However, when it comes to representing real-world scenes, there is no digital image format that can retain all the information that impinges on your eyeball. By comparison with the real-world scene, JPEG loses are far less information than GIF. The real disadvantage of lossy compression is that if you repeatedly compress and decompress an image, you lose a little more quality each time. This is a serious objection for some applications but matters not at all for many others.
[b] 4: How well does JPEG compress images? [/b]
Works great indeed, especially with different types of images. For full-color images, the uncompressed data is normally 24 bits/pixel. The best-known lossless compression methods can compress such data about 2:1 on average. JPEG can typically achieve 10:1 to 20:1 compression without visible loss, bringing the effective storage requirement down to 1 to 2 bits/pixel. 30:1 to 50:1 compression is possible with small to moderate defects, while for very-low-quality purposes such as previews or archive indexes, 100:1 compression is quite feasible. An image compressed 100:1 with JPEG takes up the same space as a full-color one-tenth-scale thumbnail image, yet it retains much more detail than such a thumbnail.
For comparison, a GIF version of the same image would start out by sacrificing most of the color information to reduce the image to 256 colors (8 bits/pixel). This provides 3:1 compression. GIF has additionally ?"LZW" compression built in, but LZW doesn't work very well on typical photographic data; at most you may get 5:1 compression overall, and it's not at all uncommon for LZW to be a net loss (i.e., less than 3:1 overall compression).
LZW *does* work well on simpler images such as line drawings, which is why GIF handles that sort of image so well. When a JPEG file is made from full-color photographic data, using a quality setting just high enough to prevent visible loss, the JPEG will typically be a factor of four or five smaller than a GIF file made from the same data.
Gray-scale images do not compress by such large factors. Because the human eye is much more sensitive to brightness variations than to hue variations, JPEG can compress hue data more heavily than brightness (gray-scale) data. A gray-scale JPEG file is generally only about 10%-25% smaller than a full-color JPEG file of similar visual quality. However, the uncompressed gray-scale data is only eight bits/pixel, or one-third the size of the color data, so the calculated compression ratio is much lower. The threshold of visible loss is often around 5:1 compression for gray-scale images.
The exact threshold at which errors become visible depends on your viewing conditions. The smaller an individual pixel, the harder it is to see an error; so errors are more visible on a computer screen (at 70 or so dots/inch) than on a high-quality color printout (300 or more dots/inch).
Thus, a higher-resolution image can tolerate more compression which is fortunate considering it's much bigger to start with. The compression ratios quoted above are typical for screen viewing. Also note that the threshold of visible error varies considerably across images.
[b]8: What is color quantization? [/b]
To display a full-color image, the computer must choose an appropriate set of representative colors and map the image into these colors. This process is called[b] "color quantization"[/b]. Clearly, color quantization is a lossy process. It turns out that for most images, the details of the color quantization algorithm have much more impact on the final image quality than do any errors introduced by JPEG itself (except at the very lowest JPEG quality settings). Making a good color quantization method is a black art, and no single algorithm is best for all images.
On the other hand, a GIF image has already been quantized to 256 or fewer colors. (A GIF always has a specific number of colors in its palette, and the format doesn't allow more than 256 palette entries.) GIF has the advantage that the image-maker precompiled the color quantization, so viewers don't have to; this is one of the things that make GIF viewers faster than JPEG viewers. If the maker quantized to a different number of colors than what you can display, you'll either waste display capability or else have to reunite to reduce the number of colors (which usually results in much poorer image quality than quantizing once from a full-color image). Furthermore, if the maker didn't use a high-quality color quantization algorithm, you're out of luck --- the image is ruined. For this reason, JPEG promises significantly better image quality than GIF for all users whose machines don't match the image maker's display hardware.
JPEG's full color image can be quantized to precisely match the viewer's display hardware.
A closely related problem is seen in many current World Wide Web browsers when running on an 8-bit display; they force all images into a pre-chosen palette. (They do this to avoid having to worry about how to allocate the limited number of available color slots among the various items on a Web page.) A GIF version of a photo usually degrades very badly in this situation, because it's effectively being forced through a second quantization step. A JPEG photo won't look wonderful either, but it will look less bad than the GIF equivalent because it's been quantized only once.
A growing number of people have better-than-8-bit display hardware already 15- or 16-bit/pixel "high color" displays are now quite common, and true 24-bit/pixel displays are no longer rare. For these people, GIF is already obsolete, as it cannot represent an image to the full capabilities of their display. JPEG images can drive these displays much more effectively.
In short, JPEG is an all-around better choice than GIF for representing photographic images in a machine-independent fashion.
It's sometimes thought that a JPEG converted from a GIF shouldn't require color quantization. That is false; even when you feed a 256-or-less-color GIF into JPEG, what comes out of the decompressor is not 256 colors, but thousands of colors. This happens because JPEG's lossiness affects each pixel a little differently; so two pixels that started with identical colors will usually come out with slightly different colors. Considering the whole image, each original color is "smeared" into a cluster of nearby colors. Therefore, quantization is always required to display a color JPEG on a color-mapped display, regardless of the image source. The same effect makes it nearly meaningless to talk about the number of colors used by a JPEG image. Even if you tried to count the number of distinct pixel values, different JPEG decoders would give you different results because of round off error differences.
See also jpg.
[Edit this page] [Page history] [What links here] [Discuss this topic] [Printer Friendly]
database » encryption » CppDefinition » WhatLinksHere » CurlUndocumented » userpage » executable » JavaScriptFAQ » CppVclGlossary » BeginnersGuideToCurl » JPEG
Displaying differences between revision 3 and the latest revision
= (Graphics) JPEG =¶
¶
Back to Graphics FAQ Main Page.
[purple][size=5][b]JPEG FAQS[/b][/size][/purple]
[b]1: What is JPEG?[/b]
JPEG stands for Joint Photographic Experts Group, the original name of the committee that wrote the standard.
JPEG is created for compressing any full-color or gray-scale image of natural, real-world scenes. It works well on photographs, naturalistic artwork, and similar material; not so well on lettering, simple cartoons, or line drawings. JPEG handles only still images.
JPEG is "lossy," meaning that the decompressed image isn't quite the same as the one you started with.(There are lossless image compression algorithms, but JPEG achieves much greater compression than is possible with lossless methods.)That is the size of a JPEG file is much smaller as compared to the file created by a lossless compression. JPEG is designed to exploit known limitations of the human eye, notably the fact that small color changes are perceived less accurately than small changes in brightness. Thus, JPEG is intended for compressing images that will be looked at by humans.
A useful property of JPEG is that the degree of lossiness can be varied by adjusting compression parameters. This means that the image-maker can trade off file size against output image quality. Conversely, if you aren't happy with the output quality at the default compression setting, you can jack up the quality until you are satisfied, and accept lesser compression.
Another vital aspect of JPEG is that decoders can trade off decoding speed against image value, by using speedy but imprecise approximations to the requisite calculations. Some viewers obtain remarkable speedups in this way. (Encoders can also trade accuracy for speed, but there's usually less reason to make such a sacrifice when writing a file.)
[b] 2: Why use JPEG? [/b]
There are two good reasons: to make your image files smaller, and to store 24-bit-per-pixel ( picture element) color data instead of 8-bit-per-pixel data.
Making image files smaller is a win for transmitting files across networks and for archiving libraries of images. Being able to compress a 2 Mbyte full-color file down to, say, 100 Kbytes makes a big difference in size and transmission time. JPEG can easily provide 20:1 compression of full-color data.
[b]3: How can the GIF and JPEG be compared? [/b]
If you are comparing GIF and JPEG, the size ratio is usually more like 4:1 .
Now, it takes longer to decode and view a JPEG image than to view an image of a simpler format such as GIF. Thus using JPEG is essentially a time/space tradeoff: you give up some time in order to store or transmit an image more cheaply. But it's worth noting that when network transmission is involved, the time savings from transferring a shorter file can be greater than the time needed to decompress the file.
The second fundamental advantage of JPEG is that it stores full color information: 24 bits/pixel (16 million colors). GIF, the other image format widely used on the net, can only store 8 bits/pixel (256 or fewer colors).
Many people are scared off by the term "lossy compression". However, when it comes to representing real-world scenes, there is no digital image format that can retain all the information that impinges on your eyeball. By comparison with the real-world scene, JPEG loses are far less information than GIF. The real disadvantage of lossy compression is that if you repeatedly compress and decompress an image, you lose a little more quality each time. This is a serious objection for some applications but matters not at all for many others.
[b] 4: How well does JPEG compress images? [/b]
Works great indeed, especially with different types of images. For full-color images, the uncompressed data is normally 24 bits/pixel. The best-known lossless compression methods can compress such data about 2:1 on average. JPEG can typically achieve 10:1 to 20:1 compression without visible loss, bringing the effective storage requirement down to 1 to 2 bits/pixel. 30:1 to 50:1 compression is possible with small to moderate defects, while for very-low-quality purposes such as previews or archive indexes, 100:1 compression is quite feasible. An image compressed 100:1 with JPEG takes up the same space as a full-color one-tenth-scale thumbnail image, yet it retains much more detail than such a thumbnail.
For comparison, a GIF version of the same image would start out by sacrificing most of the color information to reduce the image to 256 colors (8 bits/pixel). This provides 3:1 compression. GIF has additionally ?"LZW" compression built in, but LZW doesn't work very well on typical photographic data; at most you may get 5:1 compression overall, and it's not at all uncommon for LZW to be a net loss (i.e., less than 3:1 overall compression).
LZW *does* work well on simpler images such as line drawings, which is why GIF handles that sort of image so well. When a JPEG file is made from full-color photographic data, using a quality setting just high enough to prevent visible loss, the JPEG will typically be a factor of four or five smaller than a GIF file made from the same data.
Gray-scale images do not compress by such large factors. Because the human eye is much more sensitive to brightness variations than to hue variations, JPEG can compress hue data more heavily than brightness (gray-scale) data. A gray-scale JPEG file is generally only about 10%-25% smaller than a full-color JPEG file of similar visual quality. However, the uncompressed gray-scale data is only eight bits/pixel, or one-third the size of the color data, so the calculated compression ratio is much lower. The threshold of visible loss is often around 5:1 compression for gray-scale images.
The exact threshold at which errors become visible depends on your viewing conditions. The smaller an individual pixel, the harder it is to see an error; so errors are more visible on a computer screen (at 70 or so dots/inch) than on a high-quality color printout (300 or more dots/inch).
Thus, a higher-resolution image can tolerate more compression which is fortunate considering it's much bigger to start with. The compression ratios quoted above are typical for screen viewing. Also note that the threshold of visible error varies considerably across images.
[b]8: What is color quantization? [/b]
To display a full-color image, the computer must choose an appropriate set of representative colors and map the image into these colors. This process is called[b] "color quantization"[/b]. Clearly, color quantization is a lossy process. It turns out that for most images, the details of the color quantization algorithm have much more impact on the final image quality than do any errors introduced by JPEG itself (except at the very lowest JPEG quality settings). Making a good color quantization method is a black art, and no single algorithm is best for all images.
On the other hand, a GIF image has already been quantized to 256 or fewer colors. (A GIF always has a specific number of colors in its palette, and the format doesn't allow more than 256 palette entries.) GIF has the advantage that the image-maker precompiled the color quantization, so viewers don't have to; this is one of the things that make GIF viewers faster than JPEG viewers. If the maker quantized to a different number of colors than what you can display, you'll either waste display capability or else have to reunite to reduce the number of colors (which usually results in much poorer image quality than quantizing once from a full-color image). Furthermore, if the maker didn't use a high-quality color quantization algorithm, you're out of luck --- the image is ruined. For this reason, JPEG promises significantly better image quality than GIF for all users whose machines don't match the image maker's display hardware.
JPEG's full color image can be quantized to precisely match the viewer's display hardware.
A closely related problem is seen in many current World Wide Web browsers when running on an 8-bit display; they force all images into a pre-chosen palette. (They do this to avoid having to worry about how to allocate the limited number of available color slots among the various items on a Web page.) A GIF version of a photo usually degrades very badly in this situation, because it's effectively being forced through a second quantization step. A JPEG photo won't look wonderful either, but it will look less bad than the GIF equivalent because it's been quantized only once.
A growing number of people have better-than-8-bit display hardware already 15- or 16-bit/pixel "high color" displays are now quite common, and true 24-bit/pixel displays are no longer rare. For these people, GIF is already obsolete, as it cannot represent an image to the full capabilities of their display. JPEG images can drive these displays much more effectively.
In short, JPEG is an all-around better choice than GIF for representing photographic images in a machine-independent fashion.
It's sometimes thought that a JPEG converted from a GIF shouldn't require color quantization. That is false; even when you feed a 256-or-less-color GIF into JPEG, what comes out of the decompressor is not 256 colors, but thousands of colors. This happens because JPEG's lossiness affects each pixel a little differently; so two pixels that started with identical colors will usually come out with slightly different colors. Considering the whole image, each original color is "smeared" into a cluster of nearby colors. Therefore, quantization is always required to display a color JPEG on a color-mapped display, regardless of the image source. The same effect makes it nearly meaningless to talk about the number of colors used by a JPEG image. Even if you tried to count the number of distinct pixel values, different JPEG decoders would give you different results because of round off error differences.
See also jpg.
[Edit this page] [Page history] [What links here] [Discuss this topic] [Printer Friendly]
