Tutorial Understanding; Mega Pixels, Mega Bytes; tif, jpg, bmp, nef, & raw?

[Teflon-Mike]

Teflon-Mike submitted a new resource:

Understanding; Mega Pixels, Mega Bytes; tif, jpg, bmp, nef, & raw? - Understanding; Mega Pixels, Mega Bytes; tif, jpg, bmp, nef, & raw?

Or, Image Size, File Size, File Format & Compression (for beginners)

Introduction

I recently had to spend an afternoon sorting out a little problem for my old Mum; She wanted to get a couple of coffee mugs and some coasters printed with a photo, as gifts... "The site wont let me upload the photo!" she kept telling me, "It says they are too small!"

Then when I asked how many pixels it was, she kept insisiting that it was 500Kilo-Bytes....
Then I asked what camera...

Read more about this resource...

 

[Teflon-Mike]

1 - Lets start with IMAGE SIZE and Talk Pixels.

This is an 'Image'.. not a very exiting one I'll admit, there's no picture, but it's still an image. And it's made up of tiny little 'dots', squares actually, called 'Pixels'.

So, the image shows, a grid, 60 squares wide and 40 squares tall.... this is the IMAGE SIZE... 60 pixels by 40. Here is another pictre, 60 x 40 pixels.

Not very wonderful, is it? Its all, well, like its made out of leggo! Right. This is the same picture, at a 'Resolution' of 600 x 400 'pixels'.

Isn't that nicer? You can now see the circle is round! And the corners of the box and the triangle have radiused corners.

Here's another picture, with a bit more in it; again 60 pixels by 40.

Hmmmm... I have removed the grid-lines showing the edges of the pixels for you... but... in True Rolf Harris manner... "Know what it is yet?"

Here you are, at a 'resolution' of 600x400, you can see the 'detail' in the picture, and it's... it's... well, folk dancers.

So.. the more 'pixels' you have in an image, the finer detail you can see. It has a higher 'resolution'.

OK... little admission. Actually ALL these pictures have the same 'Image Size'; they are all 600 pixels x 400 pixels. This is so that they all display the same size on your screen.

This is what the picture of the coloured shapes looks like, displayed 'actual size'. BIT on the small size, isn't it?

This is because of your 'screen resolution'. The Screen you are viewing this on is composed of dots or pixels too; generally something in the order of 1000 by 800. Doesn't matter if its a little 3" screen on a smart-phone, or a 20" Monitor on a computer, or even a 40" wide-screen TV.... there's still the same number of pixels... they are just bigger or smaller.

But, on a web-page, the browser software tends to try and display pictures at a reproduction ratio of 1:1 ie: it will give one 'screen' pixel for every 'image pixel'. Which is worth noting; because if you have a picture with more pixels than the screen.... well... a lot of the possible 'resolution' is going to be wasted.

The 'computer', or whatever the device driving the screen is, will do one of two things. The first, is it will simply display one image pixel per screen pixel until the screen is full, and then 'over flow' so you only see part of the picture, usually the top left hand corner, and have to scroll up and down, left and right, to see other parts of it. Or the computer (or other device) will 're-size' the image, and clump image pixels together to create new 'screen' pixels.

Which is sort of what I have done backwards. The pixels on your screen are tiny, so to show you 'pixels' I re-sized pictures down to just 60 x 40 pixels, reducing the 'resolution', then blew them back up to a size that would display on screen as one square for every 10x10 screen pixels.

But, you get the idea. The IMAGE SIZE is the number of PIXELS that make up the picture. Its not how big the screen its displayed on is, or how big it displays on screen, and it's NOT the size the amount of memory that the data to make that picture takes up on your SD card, or Hard Disc Drive or anything.

More Pixels in a picture, generally the higher 'resolution' the image is considered to be; the more detail that the picture can contain, and the more 'real' it can make the picture look.

So; your camera; when you buy it will be sold as an 'umpety' Mega-Pixel camera, or having an 'umpety' Mp 'Sensor'.

I have a couple knocking about; My first compact digital camera boasted a 1.3Mp 'Resolution'. Later one a wopping 5Mpix sensor, and a slightly later one, a 7.1MegaPix resolution. My Digital SLR, boasts an eevn higher resolution, 24Mpix.

These 'ratings' are derived simply from counting up the total number of pixels in the pictures the camera makes.

The 24Mp Camera, makes pictures 6000 pixels by 4000 pixels. 6000 x 4000 = 24,ooo,ooo or 24 million, hence 24 'Mega' pixels.

The 1.3Mp Camera makes pictures 1280 pixels x 1024 pixels. 1280 x 1024 = 1,310,720. Rounding to nearest significant figures, 1.3 Million, or 'Mega', Pixels.

Simple Hugh?

Other than, cameras dont HAVE to use thier highest potential pixel resolution; there are usually settings on the camera to change the size of images captured, this may be to save memory on the cards internal storage or memory-card, or because the camera takes time to process larger images, and smaller image sizes let it work faster and take more pictures in the same time, perhaps on 'sequence' or in 'sport' mode.

But; thats basically it so far for IMAGE SIZE... how many dots or pixels there are in the picture. So lets move on to....

 

[Teflon-Mike]

2 - FILE SIZE....

Two Pictures I used before... lets have a look at them again. But imagine you are blind..... and I shall try and describe the picture to you in words.

It has a white back-ground. In the top left hand corner is a green triangle, taking up almost a quarter of the frame. Its a light shade of green and the triangle is base down. Next to that in the Right hand corner, again taking up about a quartter of the frame is a white square with black outline, the corners slightly rounded. At the bottom, in the left hand corner is a solid red circle. The rest of the frame is empty.

The picture is of some Traditional Folk Dancers, dancing on a village green. There are seven couples dancing in the shot. Behind them is a flowerbed, and a hedge, and behind that, a house. A white car is parked infront of the house. There is a clear blue sky, with a wiff of cloud in the top right hand corner of the frame. The Men Dancing, are all wearing white linnen shirts, with billowing sleeves, and black pantaloons over white silk stockings, with black dancing shoes; but they have waste-coats of intricate designs and colours. One is burgandy and embroydered with gold, another ivory, embroydered with paterns in silver. Another's is green. The women all have long skirts with intricate designs. One is crimson, one is green, another is brown. Each has an apron, of similarly beutiful design........

I think I'll stop there before I end up sounding like that fella, well, I think he's a fella! That does the Make-Overs on Telly! I think you get the idea. There's a lot more going on ion the second picture of the Folk Dancers, than in the first thats just three different coloured shapes.

Point is, that to describe them in words.... the more detail thats in the picture... more words I have to use to describe it.

Now, the FILE on your computer or memory card or whatever, is NOT a 'picture'... OK, if you are looking at it in a "Graphical User Interface" a picture might be being used to represent the 'file'... but electronic devices dont deal in pictures, they deal in electons, or the abscence of electrons, naughts and ones. DIGITAL representations.

And the 'File' is simply a load of digits, in a code the computer understands, that 'Describe' the picture as I have tried to do in plain language. And the FILE SIZE is basically how many computer 'words' the computer needs to use to describe the picture.

And this is the important bit; both pictures have the same number of pixels in them; but the picture of the shapes needs an awful lot less words to describe it than the picture of the Folk Dancers... especially If I was to try and describe every little detail of the lady's dresses or shawls or the blades of grass they are standing on, the shaddows they are casting, etc etc etc.

Obviousely, more pixels there are... more such detail I have to describe....

But.... IMAGE SIZE and FILE SIZE are not totally dependent on each other.

 

[Teflon-Mike]

3 - File FORMAT and COMPRESSION....

Right getting down to some Nitty-Gritty here. If I open a picture in my favourite Photo-Editor; and then 'Save As', it gives me a drop down list of possible 'File Types' that I can save it as; .tif, .gif, .bmp, jpg, to mention four you might come accross. There are a lot of other such 'formats' that are more or less common. However, jpg or J-Pegg, is the most usual that most camera makers have standardised on for consumer cameras, and the format most cameras will default to saving photo's in.

I just described two pictures in words, right? And I'm typing this in 'English'... because I am English and I speak the English language and I write in the English language.... because well, I'm useless at languages really! I can just about order a cup of coffee in French... and a beer in Spanish.... but more than that? Not a hope! BUT... if I was so gifted, I could translate those descriptions into other languages; French, German, Spanish, Dutch, I dont know, Swahili, perhaps, ancient greek or even Latin.

And each of those different languages would probably take a different number of words, and certaily a different number of charecters to say the same thing... more or less.

So, the variouse different file formats used to describe an Image are a similar thing. Different languages, or conventions for describing the picture, and they each have thier own advantages and dissadvantages about how they do it.

And a big part of this is COMPRESSION.

Used the analogy earlier of a ton of feathers and a ton of lead; both weigh the same amount, but the feathers would take up a lot more space.... only you can 'squash' feathers.. You can squash lead actually, but tends to take a bit more brute force, and all you are likely to achieve is to change the lead's shape... bit like squashing plasticine... it'll just change shape, not volume.

Feathers, though. Nice and squashy, and you could pack a load into a plastic bag, then suck all the air out with a vacuum cleaner, and your ton of feathers would still weigh a ton.... but instead of filling a rather large garage... they would probably pack down enough to fit in the back of a small van.

Computer Data is similar; and depending on the format used, more or less compression is possible, to squash down the FILE SIZE.

Lets go back to that grid at the beginning...

We have 60 squares accross, and 40 squares down, 2,400 'pixels' in all.

Now, the blank grid is nice and easy to describe. ALL the pixels are 'white'. ah yes. 'white'... what is 'white'?

Well, remembering my O-Level physics a long long time ago, 'white' is ALL the colours of the rainbow, jumbled up and seen together. Richard Of York Was Found in a Carpark.... Red, Orange, Yellow, W..... err... no.... that's not right

Need to keep this simple! Back to my primary school art teacher, who gave me a little palet of just five paints, Red, Blue & Green, for 'colours' and Black and white for 'shades', and told me they were the 'Primary' colours and I could mix ANY colour from them.... actually... she gave me Red, Yellow and Blue... but it's close enough!

Right; Three colours, and mix them in the right proportion and you can make any other colour you want. Pale blue? Just a little bit of blue, nothing else. Bright Red? Lots and lots of red and nothing else. White? Nothing at all. Black? All of all of them.

Getting a bit scientific then, we can define a colour by saying how much of each primary colour is needed to make it.

So we have a scale, 0% to 100%, for each, Red, Blue and Green.

If we have 0%Red 0% Blue 0%Green, we get black. If we have 100%Red, 100%Blue 100% Green we get white.

So we need three values between 0 and 100 to define the colour and brightness of each pixel.... our grid has 2,400 of them... lets try and 'code' the image?

Well first of all we need to say what the proportions are, so 60 pixels wide, by 40 pixels tall, then we need to explain how we are going to describe them? Battlehsips grid? So rows denoted by numbers, columns by letters, A1 in the top right hand corner.... And so we begin

A1= 100R100B100G
B1 = 100R100B100G
C1 = I'm getting bored of this..... they are all the same, aren't they?

lets look at a something a bit more like a real picture, and have a think about this....

Its the leggo folk dancers again. Lets have a crack at coding it, using this Battle-ship grid method.

A1=66R87G91B A2=68R89G93B A3=67R90G93B A4=69R91G93B
B1=68R89G93B B2=67R88G91B B3=70R90G95B B4=71R91G95B
C1=65R85G97B C2=71R91G93B C3=69R90G93B C4=71R92G95B
D1=70R91G93B D2=70R90G93B D3=71R91G93B D4=71R92G95B

Right... I have only done the top right hand corner, which is mostly blue sky, so the values are all very similar, but you get the idea, could work right the way accross and down the picture, and assign every square a Red-Green-Blue colour value.

Lots of charecters in there isn't there? But, in the 'heavier' file format's like tiff, or RAW, this is the sort of laboriouse long hand way the data that descrives the picture is coded.... I've only done 16 pixels out of two and a half thousand, imagine how much it would take to make the 'propper' one.

That's the 600x400 resolution image, that's got 240,000 pixels needing thier three value description. The 'full-size' image I shot on my camera is 6000x4000 and needs 24 million, three value descriptions to describe all it's pixels!

There has to be a shorter way of doing this, especially as a LOT of pixels are going to have exactly the same value? And you are right. This is the 'Pallet Colour' method of doing it.

We started with two data-sets to describe the picture. First the 'Header' information is the one that defined the width and height of the image, then says that we are going to describe each pixel ordered in battle-ship grid array, by three value colour-code. Then we have the 'Data-Set' that defines the colour codes for each pixel in turn.

Now, with a lot of pixels, the same colour, what we could do, to short hand the millions and millions of possible colour codes we could have, is put a 'pallet' into the header data. We say "AA = 66R87G91B" and AB = 68R89G93B etc and our data array then becomes a lot smaller.

A1=AA A2=AB A3=AC A4=AD
B1=AE B2=AF B3=AG B4=AH
C1=AI C2=AJ C3=AK C4=AL
D1=AM D2=AN D3=AJ D4=AL

And provided that you have a lot of repeated values; enough that you make less extra data creating the look up table, than you save, in the pixel data, it can dramatically reduce the amount of raw code or data needed to describe the picture.

BUT, it means that the computer has to keep going and looking at the look-up table to find out what the actual values it needs are for each pixel, rather than having them immediately to hand.

Which means that while you need less 'space' to store the image file, it gives the device that has to write it, the camera, or whatever is going to read it, and display it on a screen more 'processing' to do on it.

And While I have used to methods of encoding to explain it, there are endless variations and permutations on how it might actually be done.

But this is PRIMARY compression that is contained in the actual 'format' for encoding a picture.

As said, the 'heavier' file formats that make files with the largest file-size for any given image size, tend to write thier code out on long hand, which reduced the processing demands reading and writing the file, making it easier to manage in the camera when created, then on anything that displays it, or in an editor if you are trying to make any changes.

The 'lighter' formats, that make smaller file sizes for any given image size, make the camera or display devices or editing software do more work, but the storage size is smaller, so they take up less storage space and if you want to transport them; upload them to the web, send them via e-mail or anything like that, can be moved more easily.

And that is really as far as I want to take it, without getting into the debates on the merits of different file formats, other than to explain a feature of J-Peg that you may have come across. 'Compression Rate'.

 

[Teflon-Mike]

4 - Variable Compression

If I have a picture open in Photo-Shop, and click 'Save As' and select jpg, I then get a dialogue box asking me what Compression Rate, I would like to save it as. Offers me the choice of 12 levels, 0 being High-Compression 'Low Quality', and 12, being low compression and high quality.

This poses a few questions, but, lets back up to the 'Look-Up-Table' method of short-handing the data-file I suggested above.

I suggested defining each colour as a % Red, % Blue and % Green. Lets say we work only on whole numbers... thats 100 possible shades or Red, 100 possible shades of Blue, 100 possible shades of Green.... 100 possible Reds, times 100 possible Greens gives 10,000 possible shades for each of the 100 possible Blues, or potentially, 1,000,000 colours. One million.

That would be a pretty big chunk of 'data' to have in every file we ever created; and actually, we only HAVE 2,400 pixels! We dont NEED a data table defining codes for a million colours... with less than two and a half thousand pixels to define, we are never going to use ALL those colour codes.

In fact... even if we had more than a million pixels, chances that every single one is going to be a different colour is pretty slim!

So, wouldn't it be good if we could use some sort of inbetweenie code, that looked at all of the pixels first, and found out what colours were used, and only gave codes to colours that were used, I dont know, more than ten times?

Then you have a compact look-up-table, for the most used colours, but in the pixel set, you get the full three value colour code for colours that aren't so common, and the abbreviated one for those most used?

OK, well this kind of working gives rise to the first way that 'variable compression' can be applied.

I suggested we assign a look-up code to any colour used by more than ten pixels. That could shrink the data-set quite a bit. Alternatively, if you set the threshold to add to the look-up table at say 100 pixels, you'd get a smaller look-up-table and bigger data set. a 'Lower' compression rate.

This is still 'primary' compression, its provided by the standard that defines how the data should be coded for that file format. But it is User Defined and variable level compression, that some, not all, but some cameras and editing software will let you use, to decide whats more important; a small file size for convenient transport and storage, or less compression for faster editing and display.

 

[Teflon-Mike]

5 - Compression & Quality & whats compression loss?

This, is I think the last part of this tutorial. We are heading off into pretty complex technical issues, but they do bear some pondering.

So, Lets start with "Quality".. how GOOD something may be... or not.

Backing up to the top, I put up the two images.

Leggo shapes, vs smooth shapes

The smooth shapes has a higher 'resolution', it shows more 'detail', so most people would say it was 'better'. And in general, the higher the pixel count, the more detail you can see or 'resolve' so the better picture you get.

IMAGE SIZE is not directly related to FILE SIZE, but obviously more pixels you have, more data you need to describe them all.

So if you get to a point, where you just cant compress FILE SIZE any smaller, the only way to compress it any more, is to make the IMAGE SIZE smaller. Smaller image, less pixels, less data you need to describe it.

BUT, you are going to lower the image 'quality'... and you are throwing away 'data' or loosing it.

The leggo shapes picture compared to the smooth shapes picture is an example of this; and shows how much quality you could loose...

But what if.... there was a way to shrink the image size, to reduce the number of pixels you had to record in the file... but... without such drastic loss of image resolution?

OK... well there is, and it leads into a technique known as 'INTERPOLATION' Which is a fancy scientific term for 'educated Guess work'!

OK...

Folk Dancer's picture (A-gain!) And the data-coding of the first 16 pixels in teh corner.....

A1=66R87G91B A2=68R89G93B A3=67R90G93B A4=69R91G93B
B1=68R89G93B B2=67R88G91B B3=70R90G95B B4=71R91G95B
C1=65R85G97B C2=71R91G93B C3=69R90G93B C4=71R92G95B
D1=70R91G93B D2=70R90G93B D3=71R91G93B D4=71R92G95B

What IF... I took out the data for every second pixel?

A1=Interpolate A2=68R89G93B A3=Interpolate A4=69R91G93B
B1=68R89G93B B2=Interpolate B3=70R90G95B B4=Interpolate
C1=Interpolate C2=71R91G93B C3=Interpolate C4=71R92G95B
D1=70R91G93B D2=Interpolate D3=71R91G93B D4=Interpolate

OK, so typing 'interpolate' into each cell, doesn't save many charecters, but notice that there is a real value still above, below and to the side of every missing value? And the data-file is still saying that there are more pixels that there aren't colour values for.

And we now have one 'entry' we can put into a look-up table in the header that says "Interpolate = insert averaged value of four pixels on either side", and it takes half the data out of the pixel data set, at one swoop.

We have 'lost' the original data that defined these pixels, But, we can tell whatever is reading the file to make a pretty good 'educated guess' at what ought to be there.

This is 'lossy' compression; chucking away 'real' recorded data, and replacing it with a command to make an educated guess.

More you use, the more likely you are to loose image quality, the actual detail that was contained in those pixels to start with, but the 'resolution' needn't suffer.

Just to take the topic a little further to help clarify other fears and suggestions about 'lossy compression', when I say 'the more you use it'. Two ways you can use 'more' lossy compression.

First 'more' is to use a higher degree of interpolation. Intead of skipping alternate pixels, leaving a gap with four known values on either side, you drop more pixels so that you have fewer 'known' values, and more blanks to fill in between them.

Second, is if you 'successively' compress with losses. Lets say you open a J-peg in Photo-Shop, then save it. The image you opened, was 6000x4000 pixels, but the data-file originally only contained the actual recorded data for half of them.

Now, when you 'save' the file... the software is going to take the pixel data it has in its memory, chuck away alternate records and only write half back to the data-file.... but its just as likely to write the values it guessed at as the values that were actually recorded... open that file back up, and you now have a set of pixels created from the guessed values, and the ones you had real data for, blank, and being giessed at from the previouse guesses!

This risk of image deterioration, from 'lossy compression' is one many people warn of quite strongly; however, if you have an 'acceptable' level of first generation lossy compression, in a saved file... doesn't matter how many times you open and read that image file... its not going to loose any MORE data or quality. You can copy it, e-mail it, burn it to CD... as long as you dont write a NEW second generation copy of that file, you are not going to loose any more image data or image quality from it.

Its when you make second generation, copies of the file, and start compounding losses on top of losses, that you may start to degrade the image; and this only happens if you make CHANGES to the file, opening it up in image management or image editing software and then 'saving' the altered image data.

And if you are a photo-shop junkie, making lots of convoluted manipulations to your picture, you could be saving those changes and multiplying losses quite frequently, especially if you save between changes to save having to repeat process if a manipulation doesn't work. This is really only when the question of seriouse 'quality loss' from lossy compression starts to become an issue.

If you shoot in J-Peg, which contains primary 'lossy-compression', and save a master copy of your phot straight to CD... technically, you have NO data 'loss'...

Whats gone onto CD will remain on CD, and is exactly what was recorded by the camera... The camera has not 'recorded' the data it's 'lost' writing the very first file... and you cannot 'loose' what you have never had.

But I'll let you into a little secret... most cameras, use 'interpolation' to deliver the pixel count in the images they make ANYWAY!

My camera makes 24Mpixel images. I'm 'told' it has a 24MPixel 'sensor' to make that image... How many individual 'receptors' it has I haven't a clue... but in theory, it would need three, one for Red, one for Blue, and one for Green, for every pixel it makes.... I REALLY doubt that my camera has 72million receptors....

I suspect it has perhaps 36Million receptors arraged in a honey-comb pattern... red next to green next to blue... a BIT like this.....

This hexagonal array, rather than a grid array, means that if you super-impose a grid over the honey-comb.... you can get colour values for the square, from at least three different colour hexagons, and average them to make an 'educated guess' at what the value for that square ought to be.... bit like this....

So, you dont have one receptor per pixel recording all three colour values, you have three receptors, one for each colour.. but they are providing thier value to be 'averaged' by four adjacent pixels....

Which means... even if the camera does use a 'lossy' compression system in the file format it writes to.... what data it's 'loosing' was PROBABLY only a 'best guess' anyway!

Anyhow... this takes us right down to the base mechanics of how the camera works... and is all interesting stuff, if a bit 'heavy'... but I hope it helps explain 'pixels', how a camera makes them, and how they get shunted around and relate to 'bytes.

Time to end the lecture, with, I think....

 

[Teflon-Mike]

6 - Summary

OK, well the very first thing is that digital images are made of PIXELS. Little coloured squares like a roman tile mosaic, that are laid out in a grid to make your picture. More pixels you have, more detailed your picture can be, the higher its 'resolution'.

IMAGE SIZE is the number of PIXELS in your picture. Measured usually in Maga-Pixels, when a camera is ratet, or in 'pixel dimensions' how many pixels wide and how many tall, when you look at the image 'properties' on the computer.

Describing the picture to the computer is a DATA FILE. This is computer code, that tells the computer what colour each of the pixels are, and where they fit in the picture.

The data describing the picture has a FILE SIZE, which is measured in BYTES or Mega-Bytes.

How many Mega-Bytes may be needed to describe a picture depends on a number of factors.

1. How many Pixels there are. More pixels more data you need to describe them all.
2. The Coding 'Format'. Some formats write the data out in a very long winded way, some are much more brief. Some formats include 'compression' that can help make the file size smaller, but some compression can 'loose' data and hence image quality.
3. How 'busy' the picture is. More detail in the picture, more words are needed to describe it, and the less the coding can abbreviate it any.
4. Interpolation, is a means of 'educated guess work'. Filling in blanks between pixels by looking at the pixels around it. Often used in 'lossy' compression, it can help drastically reduce file size whilst retaining image size. And it is how the camera 'guesses' the values of pixels in a grid array, from recording the brightness values of adjacent Red, Green and Blue 'receptors' in a honey-comb array.

So... when people ask you for a 'Big image'... or a 'Small Image'.... well, you need to know whether they are talking about FILE SIZE or IMAGE SIZE, and then start asking about the format they'd prefer! Because there is very little corrolation between the two.

Just for note: a 24Mpix, or 6000x4000 pixel image, in the 'heavy' tif format takes up 'about' 100Mb of disc space. In 'high-quality' minimal compression jpg, it takes up about 10Mb.... but at 'low-quality' maximum compression can be shrunk to about 1Mb. That's the same image, at the same resolution... but 100x the difference in file size!