Don Williams wrote: > I've always believed that the compression software creates a table.
JPEG compression doesn't so much create a table, as it changes what is being stored. Instead of pixel colors, it stores coefficients to a "formula" known as the Discrete Cosine Transformation (DCT). When the JPEG data is loaded, the algorithm plugs these coefficient values back into the formula and ends up with an array of pixel colors that's very close to the original image, but usually not exactly the same. Some compression formats, usually those based on what's known as Huffman Coding, do actually store a table that's specific to the image in the image data file. When the compressed data is loaded, the algorithm (logically, not actually) looks up the data values from the file in that table and the table tells them what pixel colors those data values represent. CCITT Group 3 and Group 4 fax images, OTOH, don't store the table at all. The table is precomputed for eight exemplar images and every image compressed with Group 3 or Group 4 fax format compression uses the same table. And the algorithms based on Lempel-Ziv encoding (LZ, LZW, LZ-77, etc.) don't store the table, because the decoder can rebuild it on the fly from the incoming compressed data. IIRC, the GIF file format uses a form of LZ encoding. The Zip, Arc, Rar, and other generic compressed file formats typically can use any of several compression algorithms on a file, and can use different ones for different files within the archive. > Its also possible to drop the least significant bits in each byte > without messing the images up too much. You can do all kinds of > arcane things with these bits. Actually, dropping some of the least significant bits is one of the effects of the JPEG algorithm. And steganography is the study of methods of hiding other information in those least significant bits. -- Thanks, DougF (KG4LMZ) -- PDML Pentax-Discuss Mail List [email protected] http://pdml.net/mailman/listinfo/pdml_pdml.net
