What determines JPEG file size?

I have noticed that different images of identical resolution and dimensions often have widely varying file

sizes when saved as JPEGs. In other words, at the same JPEG quality level, some files are larger than

others. I am often bothered by having to reduce quality level in order to post a JPEG image to a website at

a reasonable size, as this can alter the appearance of the image on the web. As an example, I like to

split-tone B&W images in Lightroom. They may initially look great on my monitor, but when saved as low

quality JPEGs, weird color shifts sometimes occur. Raising quality level eliminates the color shifts.

Obviously, JPEG compression is not as straight forward as one might expect. What is the explanation for

this phenomenon?

Rob

At identical settings, the amount of details in the image determines file size. Images with file

detail produce bigger JPEGs than blurry shots.

A picture with more colours and details won't be able to be compressed as much as a simple picture with little detail and few colours and will result in a larger file size. It's all in how the jpg algorithm works. If you have a photo of nothing but a blank white wall, then it can be compressed (and expressed) simply as something like "1 million pixels of white". Or another way of explaining it if you have a typical scene, and there are 5 pixels in a row of an identical colour like in a blue sky, the jpg encoding will simplify that and express it as "5 blue" rather than "blue, blue, blue, blue, blue". It takes less bytes to express "5 blue" than "blue, blue, blue, blue, blue".

That's why if every pixel in the picture was the same colour it would compress extremely efficiently whereas a picture with lots of fine detail won't. It's also why noisy (high ISO) pictures are larger in size out of the camera than clean (low ISO) pictures. All those individual random specks of noise can't be efficiently compressed and expressed.

Great explanations. Thanks.

Rob

The issue in any kind of lossy compression scheme is complexity. Since the compression

algorithms are seeking redundancy (if a sky is a single toned slate gray, for example, it is

possible to represent the set of pixels representing the sky by a single 3-digit number.

The algorithm identifies the set of pixels and the value associated with that set. That is far

less data than recording the information about every single pixel in that set, therefore the

compression will be greater.) If the image is very complex, a leafy forest scene with lots of

colors, then the file will be larger.

The issue is this: if you are trying to reduce a file significantly in size by increasing the

compression, then it will lump similar pixel values together and represent them as a single

value. This results in a very noticable jpg artifacting, like banding in the sky. Your

original might have a nice blue to light blue gradation, but when it is compressed

significantly, you have bands of color instead of a gentle gradation. If that is the case, you

are over-compressing.

I'm not sure about you, but I use as little compression as possible, even for PN.

Understand that if your image is above a certain size, PN will re-compress it as a smaller

version anyway. So you need to be aware that a second compression will make the

compression artifacting even more noticable.

Hi, the compression algorithm that Frank Dzambic is describing in called <a="http://en.wikipedia.org/wiki/Run-length_encoding">run length encoding</a> and is not exactly how JPEG compression works.

<p>The JPEG compression algorithm is reasonably complex. There are some good articles on how JPEG works on the internet. The <a href="http://en.wikipedia.org/wiki/Jpeg">wikipedia article</a> is quite good. As is <a href="http://www.impulseadventure.com/photo/jpeg-compression.html">this article</a> by the author of a program called JPEGSnoop. Calvin has a <a href="http://www.impulseadventure.com/photo/">number of interesting articles</a> on JPEG and digital photography.

<p>The step involved in JPEG are as follows:-

<ol>

<li>In the case of a full color (RGB) image the RGB values are converted to a lightness (luma) value and two colour (chroma) values.

<li>Optionally, the colour (chroma) values are averaged over a two or four pixel block. I must stress this is optional and is not the major part of the compression. This is known as chroma sub-sampling.

<li>The luma and chroma values are now treated as three seperate images. They are broken up into blocks of 8x8 values.

<li>Each 8x8 block of values is converted into a number of frequencies and amplitudes. Using the <a href="http://en.wikipedia.org/wiki/Discrete_cosine_transform"> discrete cosine transform</a>. The frequencies used are predefined. It is only the amplitudes that need to be stored.

<li>Some of the amplitude values are modified, based on the <a href="http://en.wikipedia.org/wiki/Quantization_matrix#Quantization_matrices">quantization table</a> being used. When you select a different quality in an application you are simply choosing a quantization table. This has the effect of eliminating some of the high frequencies from the image, and changing the amplitudes of some others. The colour (chroma) values are more aggresively quantized than the brightness (luma) values, as apparently human vision is less concerned with errors in colour than brightness.

<li>The purpose of the previous steps is to make the data more compressable. The data is now compressed using two compression schemes (run length encoding and huffman coding). This <em>data</em> is no longer pixel values, but rather the amplitudes of a set of frequencies needed to recreate the pixel values.

</ol>

<p>Note: The loss of infomation is in step 4, while the actual compression is in step 6.

<p>To answer Robert Goldstein's original question, The size of a JPEG file is determined by:-

<ol>

<li>If chroma sub-sampling is used

<li>The amount of high frequency information in the image

<li>How much of the frequency information is thrown away

</ol>

<p>The colour shifts seen in your split tone images may be caused by throwing away too much information from the colour (chroma) channels.

<p>I hope this helps,

<p>Andrew

Sorry

"Note: The loss of infomation is in step 4, while the actual compression is in step 6."

should read

"Note: The loss of infomation is in step 5, while the actual compression is in step 6."