This is the key, the stuff that comes off the sensor must undergo some processing in order to output as a file.
It doesn't even need to be processed as such in order to have different file sizes. Jut deciding how to write down (save) an image will have this effect. To get an idea of why compression might vary with information we can do a simple thought experiment. Imagine a simple sensor - it's one row of pixels (say, 256 of them) and they are binary - they only see light or dark. We take our image and want to write it down to save it. Since each pixel sees light or dark, we may as well write a 1 for light and a 0 for dark - it will save on paper. The simplest way of saving the image is just to write down, in order, the pixel values. Let's write down a sample image:
1001100001.... and so on for the rest of the pixels, all the way to the end.
However, looking at it, you can straight away see a way of saving space. Instead of writing each pixel, lets write the number of pixels of the same value that occur one after another and if only one of those values occurs, we can just write it down. So on the image above we have:
A single one, so write 1
two zeros, so write 20
two ones, so 21
four zeros, so 40
and for the sake of argument, let's assume the final one that I wrote was indeed single one, so it becomes 1
The written down image is now 12021401
We've used 8 numbers to represent the original 10 pixels that I wrote down. It's a compression algorithm!
Straight away you can see that an all dark image or all bright image is very easy to compress - for our 256 pixel sensor it would be 2560 or 2561: a compression factor of 64 on our "file size". You can also see how, the more useful information in the image, the less compression we can get away with - an alternative pattern of 10101010... cannot be compressed in our scheme. A mathematician called Shannon came up with a way of generalising this to any scheme and showed that this is always true - if you want to do lossless compression, then there is a minimum size that you can compress to, no matter what the scheme is. Some schemes will, however, get closer to this limit than others. It also explains why you won't get much change out of using a zip programme on a jpeg - depending on the quality setting of your jpeg they are already pretty efficiently packed and so can't get much smaller.
An interesting side effect is that with most ( or perhaps all - I can't remember) schemes, there will be images that when "compressed" will end up larger than the original image due to the extra information required to decode them (e.g. the "4" in the "40" part of the pretend image we compressed in the example)
Ps. Please never use the scheme I showed for real compression - it's stupid and breaks easily! It's just a nice tutorial example
