Everyone writing image files really needs a certain minimal exposure to what really happens in the image files. There are certainly reasons to write the output file one way versus another, but there is no one correct answer for every case. Here's the homework in case you have not explored it before on your own.
The point hoped to be shown here is as follows: The file size is larger when the data compression is lossless, small, or none. The file size is much smaller when the compression is large and lossy.
The common file formats addressed here are TIF, GIF, and JPG.
TIF files with LZW compression are lossless. Which is not the smallest files, but TIF is one of the best possible file quality formats for the master copies of your scans.
GIF files are lossless compression, but are best suited for simple graphics, like logos, containing solid areas in few colors. GIF is limited to 256 colors, however it is the conversion to 256 colors that cause the color losses, and the file format itself is lossless. You can read and write GIF files multiple times without additional losses.
JPG files are most common now, because they produce an extremely small file and are very suitable for Email and web pages, but the smallness virtue comes at the expense of JPG using a lossy compression. JPG is NOT suitable for master copies of images. JPG compression is called lossy because there are data losses, that is, the file data is changed somewhat, and we cannot read back exactly what we wrote out. We see this as visible artifacts in the image. Artifacts are effects that are products of the process. JPG is designed for photographs, with continuous tones rather than sharp edges. JPG doesn't like sharp edges like found in text, logos, etc. However, TIF and GIF are very kind to sharp edges. We will show that below.
The JPG Quality setting affects image quality. The JPG Quality setting is the opposite of Compression, i.e., 70% Quality can be said to be 30% Compression. Some programs show it one way, some the other. The numbers are relative and have no absolute meaning. This setting is normally found under the Options button in the File - Save As dialog.
PNG files are not detailed here, but PNG8 indexed files are very similar size to GIF, and PNG24 are very similar size to TIF files (using LZW compression).
Here is a small simple test image, 99x33, containing continuous tones as well as some sharp edges. The lines are two pixels wide. It could be any image. It's a tiny file because I want to show it when blown up. Note that this image was generated in a graphics application, and is independent of the scanner. The scanner was NOT involved.
These files are too small for the file size comparisons to be very meaningful. The uncompressed size of 24 bit RGB color is 3 bytes per pixel, so 99x33x3 is 9801 bytes). Indexed files are smaller, roughly 4 bytes per color before compression.
The TIF file with LZW compression was 6976 bytes, 71.2% compressed size of RGB.
90% Quality JPG - 1352 bytes, 13.8% compressed size of RGB.
70% Quality JPG - 1074 bytes, 10.9% compressed size of RGB.
50% Quality JPG - 966 bytes, 9.8% compressed size of RGB.
30% Quality JPG - 893 bytes, 9.1% compressed size of RGB.
256 color GIF - Optimized palette - 2932 bytes, 29.9% compressed size of RGB.
256 color GIF - Standard 6-6-6 palette - 1524 bytes, 15.5% compressed size of RGB.
16 color GIF - Optimized palette - 888 bytes, 9.1% compressed size of RGB.
Let's look closer. First the JPG files:
These larger images below are created by reading the small files above, then enlarging them 4 times. Artifacts of the JPG compression are visible. These artifacts are also visible in the small images above at640x480, but are not very visible at 1024x768 unless enlarged. For scale,the black lines are 2 pixels wide.
This next image is a 90% JPG file of the TIF file enlarged 4 times, and any small artifacts you see are a result of that, and not the TIF file itself. You can download the actual tiny TIF file if you want to see the real thing, or want to duplicate the same experiments on it, but it is the TIF image we have enlarged, and the JPG artifacts are not enlarged this time.
TIF
TIF is as good as it gets. You needn't worry about it, except perhaps the file size. LZW compression helps TIF size, but is not as dramatic as JPG. In fact, TIF will still be downright huge.
90%
The 90% Quality JPG file enlarged 4 times. Compression artifacts are beginning to be visible on the sharp edges. But there are few if any benefits from 100% Quality, JPG still compresses even then, and a 90% Quality JPG file will be quite small.
70%
The 70% Quality JPG file enlarged 4 times. It's still pretty good, and
this image would be suitable for most viewing purposes. This level of compression
is well warranted for many applications where size is important. I mostly
use 75% Quality myself as a good compromise between Quality and Size.
50%
The 50% Quality JPG file enlarged 4 times. The artifacts at the sharp
edges become more pronounced. Some blocking seen here, see next image.
30%
The 30% Quality JPG file enlarged 4 times. Notice the several large square pink blocks in the smooth areas, about 4 times wider than the black lines. JPG compression processes areas of 8x8 pixels at a time, and sometimes combines them to be larger blocks of the same one color. Frankly, this is always much more visible in photographic images than in this specialized one, and shows up earlier than it did here. Our sample image is "too" continuous to show it well.
This is the histogram of the small TIF file above. There is more discussion of histograms on the A Simple Way page, and this histogram in particular on the >Luminance page from the Basics section.
This is the histogram of the small 90% JPG file above. The vertical scale doubled on me, divide heights by two, but the idea is still here. Even if it may look good, we have picked up considerable artifacts. And we do MORE of this EVERY time we read and write the JPG file.
So, you've been warned.
OK, now you know what JPG artifacts to look for when you zoom in on your own JPG files. Granted, we are enlarged 4 times here, and maybe it looks worse than it is, but it's fair to say that most regular images will look worse than this simple one at high levels of compression. There would typically be more sharp edges, often close enough together to affect one another. And especially note that additional similar artifacts are produced EVERY TIMEyou rewrite the JPG file, and so will continue to grow cumulatively worse over time if you do that.
So don't do that!
Here is a large sample (135K) showing >JPG artifacts in a real photographic image.
JPG is wonderful for its purpose (very small size), but it is NOT suitable for master copies. Use TIF for master copies.For files you do not anticipate rewriting again, JPG is fine. Except that we do ALWAYS end up wanting to edit and rewrite them. 😊
So there is no misunderstanding, reading JPG files is not a problem. Reading does not alter the file, it does not create more artifacts. So you can read a JPG file a jillion times without concern. It's the writing of the file, and the rewriting of it, that is the problem. When the data is compressed for writing, the artifacts are generated. Every time.
Now the GIF files
GIF files first require image conversion from 24 bit color to 8 bit color. Specifically, this means to 256 colors or less. There are several different ways to convert to 256 colors.
Below: The 256 color Optimized GIF file enlarged 4 times, and its palette. This GIF looks pretty good, partially because of this specialized image. This image has only 243 colors in the first place, so this GIF is not very limited by the fact that GIF can contain at most 256 colors. However, JPG files are much smaller than GIF for images with continuous tones (photographs).
Since most of this image's colors are red, the optimized index contains mostly red also. Optimized means optimized for this image, instead of being optimized for the Windows 8 bit Palette Manager. Since there is only one Windows Palette Manager for 8 bit video modes, the other regular colors are for the rest of the desktop, but there will still be some strange colors on the rest of the desktop in systems with 8 bit video modes. This is of no concern for 16 or 24 bit video boards, which don't use a Palette Manager, even when showing 8 bit images.
It should be noted again that this palette concept does not apply to JPG images, but only to GIFs, which uses indexed palettes. JPG images WILL dither on a 256 color video system. Graphics people should not still be using 256 color video any more, but there is still need to create GIF files for graphic images, like logos.
| 
|
Below: the 16 color Optimized GIF file enlarged 4 times, and its palette. GIF, particularly 16 color GIF, is IDEAL for web pages for logos and similar simple graphics without continuous tones, the files can be very small. Since most of this image's colors are red, the optimized index contains mostly red also. Since we only have 16 colors, many of the pinks are combined into the same few colors.
| 
|
But there are many ways to create a GIF palette. This next way was with the Standard Index 256 Color menu, shown below with its palette. It is the Standard 6-6-6 palette, 6 colors of each of Red, Green, and Blue, so that 6x6x6 colors is 216 colors independent of this specific image. The remaining 40 are standard colors reserved for the Windows desktop. The 6x6x6 standard colors are designed to be approximately correct for ANY image, and are the same for any image. This is a concern for 8 bit video modes because there is just one Windows Palette Manager, and ALL images on the desktop must share one palette simultaneously. There are some strange colors observed when the palette changes. This standard palette is intended to minimize that. This Standard 6-6-6 palette is the same palette as the PhotoImpact WWW Browser Optimized palette for Netscape (which has two menus for the same thing).
However, using the Netscape Standard palette only helps those still using 8 bit color hardware. This used to be very important 5 years ago when we all had 8 bit boards. There are two schools, 1) that this is still important, and 2) why bother anymore? Users still on 8 bit modes are frankly used to poor color, it's nothing they haven't seen before, and they can upgrade video modes if they wish. Why make the majority, those with the now standard 16and 24 bit modes capable of good color, see poor color because not everyone can? The choice must depend on your purpose I suppose, but its hard to defend today.
You will see many sites on the web telling you that Netscape and other browsers show only this 216 color palette, using only 6 tones each of Red, Green, Blue (6x6x6=216 combinations). And that is true if you are in 8 bit video mode, but that is not current information today. True color 24 bit video boards don't use palettes at all, even for GIF images. To show that this is so, here is a 256 color gradient GIF image, using an Adaptive indexed palette:
If your video board is in 16 or 24 bit color mode, then you can see that
your browser is obviously not limiting this to 6 tones of red. An Adaptive
palette adjusts to the actual image tones, and contains the best 256 colors
appropriate for the image. In this case the entire palette is shades of pink.
PhotoImpact will create GIF palettes other ways too, this next is the
3-3-2"bits" palette. It uses 8x8x4 colors, robbing from Blue to benefit
Red and Green, intended to have more unique colors in the palette. Again,
the palette is independent of the image.
