[LoTekK]

this is an issue that i've known about for a long time, but never really gave any thought to... basically, i was wondering about why different colors give different results in jpeg (and a couple other compression algorithms as well), most notably red? i figure that there really shouldn't be a problem, unless the problem occurs because of pure red's hue number, which is zero... anyone able to shed light on this?

[balistic]

JPeG's compression is based on how it thinks people perceive images . . . it throws out information based on how important certain factors are in the interpretation of imagery. I'm guessing pure reds, magentas, and greens look bad because JPeG's visual importance settings are based on photography, not digital art . . . full intensity reds and purples don't show up very often in the real world, so JPeG isn't optimized to deal with those extremes.

[Frost]

Jpeg works on the principle of RGB, not hue. It splits up an image into a series of small squares, in which it tries to re-use simular data its already encountered in previous squares, I would assume redefining those squares to find intermediate, compensatory levels of RGB to accomodate the compression level desired. The smaller the file, the more it will blend in and destroy your image.

[Pat]

Those squares are 8x8 pixels. The data inside those squares are resampled, with a bias towards shifts in contrast OVER gradual color shifting. There's this thing called a DCT, Discret Cosine Transformation, which basically averages the data and selects the ranges which are most important. As balistic pointed out, that's because people aren't as likely to notice certain types of color data as others.

Lastly, the image is compressed --usually using some form of an Huffman encoder which basically looks for the most redundant color value and assigns it a low value to speed decompression and reduce file size.

There's some extreme math involved that you're probably going to want to avoid. Instead, try avoiding extreme colors, or radical shifts in contrast.

Wanna see something neat, if not esoteric? Null values inside the 8x8 grids are not tossed during the compression, since there's no need to average that data. So, since we know that 8x8 squares are the target range, you can construct an image which is friendly to the compression scheme.



This image is 320x320 pixels (divisible by 8 for maximum compression) and JPEG compressed at the LOWEST quality setting available. That's 0 in Photoshop. If you bring the image into an image editor and zoom in, you're not going to see ANY artifacting. Heh... try it. Resave the file as a JPEG again and again, using a "0" on the quality slider. No difference. Next time some wise-ass tells you it's never a good idea to resave JPEGS, hand him this one.

-Pat

[LoTekK]

whoops, *bump*ed my head...
if this is a stupid topic, then feel free to let me know and i'll just let it die quietly...

[Frost]

Thanks a lot Pat for clarifying this. My understanding was rather theoretical... I never dared (shudder) to gaze at JPG/MPG comp./decomp. code. =) Is the DCT applied sepperately on R, G and B channels, or does it affect all channels simultaneously in the form of JPG?

[ January 04, 2002: Message edited by: Frost ]

[balistic]

That's very cool Pat, thanks for the info.

[maxon]

So is this image supposed to be friendly to the compression scheme?



[ January 04, 2002: Message edited by: maxon ]

[Leo]

Pat, take a photo instead of black squares and you'll see how jpg compression reduce image quality each time you resave it.

-leo

[balistic]

Leo: Pat wasn't saying JPeG isn't lossy, he's saying that by knowing how JPeG compression works, you can construct an image that JPeG will not deteriorate.

With as much information as he obviously knows about JPeG, I'm sure Pat realizes that its a lossy format

[Pat]

balistic beat me to the punch again.

Maxon, if you read the message carefully, it says "null values". The trick only works with black and white. It's a totally useless exercise, except to highlight some interesting points about JPEG compression.

Frost: AFAIK the entire RGB image is quantized together, not individually by channel. I honestly don't know enough about the math to be sure of this, but it makes sense to average the cumulative value instead of doing 3 separate ones.

LoTekK: Here's the official definition of Huffman encoding that I stole off a website:

Huffman encoding (algorithm)

Definition: A minimal variable-length encoding based on the frequency of each character. First, each character becomes a trivial tree, with the character as the only node. The character's frequency is the tree's frequency. The two trees with the least frequencies are joined with a new root which is assigned the sum of their frequencies. This is repeated until all characters are in one tree. One code bit represents each level. Thus more frequent characters are near the root and are encoded with few bits, and rare characters are far from the root and are encoded with many bits.

Make sense?

-Pat

[LoTekK]

pat: to my complete and utter surprise, that actually made sense to me... well, sort of, anyways... i didn't entirely understand the "assigned the sum of their frequencies" bit, in that i don't understand why this is done... but hey, that's why i'm not a math major...

also, how does this apply to jpeg compression? since the algorithm isn't entirely dependent on the frequency of a color, how does the compression work on the whole?

sorry if i'm asking stupid questions, but this is, frighteningly enough, beginning to fascinate me...

[edit] wait, i reread the earlier posts and sumarrily slapped my forehead... is jpeg at all concerned with frequency in the first place? or do we, in this case, substitute [color importance] for frequency? [/edit]

[ January 04, 2002: Message edited by: LoTekK ]

[LoTekK]

pat, thanks, that certainly helped out plenty... to me, jpeg compression has always been some arcane thing that i let photoshop or psp handle for me while i just find the right balance between file size and image quality... i hope to put this newly-acquired info to good use... i had one question, though:

quote

Quote:

Huffman encoder which basically looks for the most redundant color value and assigns it a low value to speed decompression and reduce file size

could you expand on this? i'm not sure what you meant by redundant... or more specifically, how the algorithm determines redundancy...

thanks!