The "reduced" algorithm, from the FAQ is fairly simple: 1. Transform the image into a suitable color space. 2. (Optional -- omitted) 3. Group the pixel values for each component into 8x8 blocks. Transform each 8x8 block through a discrete cosine transform 4. In each block, divide each of the 64 frequency components by a separate "quantization coefficient", and round the results to integers. 5. Encode the reduced coefficients using either Huffman or arithmetic coding. 6. Tack on appropriate headers, etc, and output the result.
Basically, the 3rd step is where the "pixel" come into play. In theory, one can write a codec for an arbitrary color depth. In practice, I am yet to see one. Since all "observable" codecs work on 24 bit color, there's a good reason to think of JPEG as 24 bit format (if you want to be able to read it back, anyway). BTW, zipped 24 bit tiff would be still a 24 bit format, although <q>the concept of "bits per channel" just doesn't exist inside a</q> zip file :) Mishka -----Original Message----- From: Steve Jolly <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Fri, 19 Mar 2004 16:14:26 +0000 Subject: Re: JPEG Question > > Sorry to rain on your parade, but JPEG is far more complicated than > "eight bits per channel". Internally, there is no concept even of > pixels! Regular JPEGs are usually created from 8-bit-per-channel > bitmaps, and there's not much point in converting them back into bitmaps > of greater depth than that before viewing or printing them, but there > the concept of "bits per channel" just doesn't exist inside a JPEG file. > > If you want to enter the scary world of lossy compression techniques, a > good starting place is the comp.compression FAQ at > http://www.faqs.org/faqs/compression-faq/. JPEG is described in section > 75, which is in part 2 of the FAQ. > > S
