Post subject: Am I understanding the concept of bits per pixel right
Joined: 5/30/2005
Posts: 98
Bits per pixel means the number of colors an indivisual pixel in an image can display right? So for example if you look up an images properties and see it has 32 bits per pixel that means that each pixel can display 32 different colors right.
Senior Moderator
Joined: 8/4/2005
Posts: 5777
Location: Away
Wrong. 8 bits per pixel means a pixel can take 256 different colors (2^8=256).
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Post subject: Re: Am I understanding the concept of bits per pixel right
Banned User
Joined: 12/23/2004
Posts: 1850
Post subject: Re: Am I understanding the concept of bits per pixel right
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
gbagcn wrote:
So for example if you look up an images properties and see it has 32 bits per pixel that means that each pixel can display 32 different colors right.
I find your misconception rather interesting. It would be interesting to know if you know what "bit" means, and that if you understand what it means that, for example, one byte consists of 8 bits or that one pixel consists of 24 bits. I suppose that, in a way, the misconception might be logical. If a pixel consists, for example, of 8 bits, in other words, 8 elements which can be either 0 or 1, one might think that each of these elements represents one color and that the chosen color is marked with a 1 while the other bits are 0. If you think about it a bit more, I'm sure you'll understand that that would be a huge waste of resources. Think about this: Couldn't we optimize and say that, besides those 8 colors, if the first *two* bits are 1, then we choose a 9th color? And of course if the second and third bits are 1, we could choose a 10th color, and so on? And if *three* bits are 1, we can still chose more colors, etc. Just this way we get a lot more colors that can be represented with 8 bits. However, that's still not the optimal way of using the bits. Each bit combination can be assigned a unique number, for example like this: 00000000 = 0 00000001 = 1 00000010 = 2 00000011 = 3 00000100 = 4 00000101 = 5 etc. These combinations are unique, and each one can be mapped to a number. With 8 bits we get 256 different combinations. With 16 bits we get 65536 different combinations. In general, the number of possible combinations is 2^bits. That's why, for example, a pixel of 8 bits can represent a total of 256 colors, pixel of 16 bits can represent a total of 65536 colors, and a pixel of 24 bits can represent a total of 16777216 colors. In theory a pixel with 32 bits could represent 4294967296 different colors. However, in practice only the 24 first bits of that value is used for the color information (giving the 16777216 possible colors). This is because it's handy to have one byte (ie. 8 bits) per color channel (ie. 8 bits for the red component of the color, 8 bits for the green component and 8 bits for the blue component). Usually if you have a 32bpp image, the last 8 bits are used for the alpha channel (although in some cases it may simply be unused, and 32 bits are used, with the last 8 bits "wasted" for other reasons, such as memory alignment, etc). The alpha channel tells the transparency of the pixel.
Emulator Coder, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
For 8 bit and below, a palette is traditionally constructed and each colour refers to an entry in the palette. For 15 bit mode, 5 bits for red, green and blue. For 16 bit mode, 1 extra bit for green. For 24 bit mode, 8 bits per colour. 32 bit mode is as above. Some high end software and scanners will do work in better than 8 bits per colour. 48 bit colour would be 16 bits per red,green,blue for example. Quite heavy, but if you're doing major image editting, 256 shades of red might not be enough to preserve the image quality.
Joined: 5/30/2005
Posts: 98
So you take the bits per pixel number a cube it right. That means if you wanted to find the file size of an image in terms of bits you would do that following right: Image resolution x (bits per pixel)^3 = image file size (bits) 800x600 x 32^3 = 15728640000 So am I doing this right? Also I know this is only what the file size would be uncompressed. Is there a way to make this formula more accurate by factoring in some basic compression without being too complex?
Emulator Coder, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
No. Take bits straight up. 8 bit = 8 bits. 800x600x8 = 3,840,000 bits = 480,000 bytes. Alternatively, divide the number of bits by 8. 8 bit means 8/8=1 byte per pixel. People use bits pretty rarely for such measurements. If the number is a fraction, round up. 15 bit -- 15/8 = 1.875 -> 2 bytes per pixel. 800x600x1 = 480,000 bytes. Compression is a strange beast. It depends on the material and format. PNG will work best with cartoon-like images with few colours in it. JPEG works best with photographic material. Both will easily cut a file size down by a factor of 10 if used in the correct place. An 800x600 JPEG can be under 150 kilobytes with reasonable quality. A PNG can do the same if selected properly and optimized. I cannot give you a hard and fast rule. PNG has its limits. JPEG trades quality for size. You can make a 2000x2000 image 50 KB if you're willing to accept it being turned into one giant smudge of colour. You'll find good JPEG saving applications give you a quality selector. You're trading file size for accuracy. Low quality gives artifacts and smudging. High quality makes dial-up users cry.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
gbagcn wrote:
So you take the bits per pixel number a cube it right.
I don't really understand where you are getting that cube from. There's no cube. It's just the resolution (in pixels) times the bits. Basic math.
DeHackEd wrote:
For 16 bit mode, 1 extra bit for green.
Btw, the reason why the extra bit is added precisely to the green component and not the others is because the human eye perceives green shades more accurately than red or blue shades. (That's also the reason why the correct way of transforming an image to grayscale is not to the take average of the color components, but you have to weight them, and the green component has a considerably larger weight than the others.)
Joined: 5/30/2005
Posts: 98
First of all before I go any further I want to make sure I am understanding the concept of a bit right. For example the bit stream 1001 can be written in terms of 2^X = Y (in this example x = 4 and y = 16). The way I refer to X and Y (when thinking about it myself, not to other people) not is that X represents the number of bits while Y represents the state space of those bits. Since I have seen the word "bits" used to refer to both X and Y I am not sure which one is supposed to be refered to as a bit. Each pixel is made up of the RGB color model so since there are 3 variables in this color model (red, green, blue) I took the number of bits per pixel and multiplied this number by itself 3 times (in other words cubed it). For example in an image with 16 bits per pixel you would have 16 bits for red x 16 bits for green x 16 bits for blue. The reason you need 16 bits for each color is because you need to represent the level of intensity of red, green, and blue. For example the lowest intensity would be 0000 while the highest intensity would be 1111.
Senior Moderator
Joined: 8/4/2005
Posts: 5777
Location: Away
A bit is a binary digit, it can take a form of 0 or 1. That's everything there is to a bit. Try reading everything people above said and linked to you, it's explained everywhere if you just try to search for it one bit (accidental pun).
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
gbagcn wrote:
For example the bit stream 1001
I think a bit stream is related to some other things, not really relevant to this issue. Perhaps "bit sequence" is more the term you were looking for.
can be written in terms of 2^X = Y (in this example x = 4 and y = 16).
Hmm, "1001" cannot be "written as 2^4 = 16". What 2^4 is telling you is the amount of different bit combinations that can be achieved with 4 bits (ie. 16 different combinations). "1001" is simply one of those possible combinations. In order to know which decimal value does "1001" (which is a base-2 number) correspond, you can do it with the formula: 2^0 + 2^3 = 1 + 8 = 9. The first term is for the least-significant bit (the "zeroth bit") which is on, and the second term is for the fourth least-significant bit (the "third bit"). Likewise "1111" would be 2^0 + 2^1 + 2^2 + 2^3 = 15. (You can also think of "1001" as being 1*2^0 + 0*2^1 + 0*2^2 + 1*2^3 if you like.)
The way I refer to X and Y (when thinking about it myself, not to other people) not is that X represents the number of bits while Y represents the state space of those bits. Since I have seen the word "bits" used to refer to both X and Y I am not sure which one is supposed to be refered to as a bit.
I have never seen the maximum range representable by a certain amount of bits being referred to as "bits". I think you are confused. "Bits" is always used to describe the amount of bits in a certain value, nothing more.
Each pixel is made up of the RGB color model
Not necessarily. RGB is just *one* way of representing images. Another very used representation is a paletted image (used eg. in GIFs and 8-bit PNGs), where each pixel is just an index value to a palette table, instead of being the color itself. Thus from the pixel value alone it's impossible to tell the color of the pixel. You have to look at the correspondent color in the palette table instead. There are other color representations used in image formats besides RGB, but they are much more rarely used. (Mainly they are used in very specialized industries.) In the vast majority of image formats, however, the rule of thumb is that if it's an "8 bits per pixel" image, it's paletted, and if it has more bits per pixel, it uses the RGB model (although in some cases it could also be BGR, which is just a case of ordering of the color components inside each pixel).
so since there are 3 variables in this color model (red, green, blue) I took the number of bits per pixel and multiplied this number by itself 3 times (in other words cubed it).
No, bits per pixel means exactly that: The number of bits used per pixel. How these bits are divided into the different color components is another thing, but one pixel uses that amount of bits, period.
For example in an image with 16 bits per pixel you would have 16 bits for red x 16 bits for green x 16 bits for blue.
That would not be 16 bits per pixel. That would be 48 bits per pixel, which is a completely different thing. If an image has 16 bits per pixel, then it has 16 bits per pixel, not a bit more. (Usually this kind of image will have 5 bits for the red component, 6 bits for the green component and 5 bits for the blue component, but that's mostly irrelevant.)
The reason you need 16 bits for each color is because you need to represent the level of intensity of red, green, and blue. For example the lowest intensity would be 0000 while the highest intensity would be 1111.
"0000" and "1111" are 4-bit values, not 16-bit. If you had 4 bits per color component, and it's an rgb image, then the pixel would have 12 bits, iow. it would be a 12-bits-per-pixel image.
Joined: 5/30/2005
Posts: 98
Ok I think I messed up my explanation of what 2^X = Y actually means. X represents the number of numbers in the bit sequence (in base 10 this is known as the number of digits in a number) and Y represents the number of bits in the bit sequence. For example in the bit sequence nnnn (where n is either 0 or 1) X = 4 and Y = 16. Also the lowest possible value of this bit sequence is 0000 while the highest possible value is 1111. This is similar to base 10 4 digit numbers where the lowest value of them is 0000 (0's to the left of the first 0 are usually ignored) and the highest value is 9999. So regarding the image stuff that means that you could use the following formula to find the file size for an image: Image resolution x bits per pixel = image file size (bits) 800 x 600 x 32 = 15360000 This is what I thought before I created this topic but I must have explained it wrong or something.
Joined: 6/26/2007
Posts: 147
gbagcn wrote:
So regarding the image stuff that means that you could use the following formula to find the file size for an image: Image resolution x bits per pixel = image file size (bits) 800 x 600 x 32 = 15360000
Somewhat, GIF, JPEG, and PNG are used because they compress the image, and there's usually some header data in everything, but this type of approach might work for certain BMP files.
Former player
Joined: 3/30/2004
Posts: 1354
Location: Heather's imagination
gbagcn wrote:
Ok I think I messed up my explanation of what 2^X = Y actually means. X represents the number of numbers in the bit sequence (in base 10 this is known as the number of digits in a number) and Y represents the number of bits in the bit sequence.
Bit means "binary digit". X is the number of bits. Y is the number of possible values.
someone is out there who will like you. take off your mask so they can find you faster. I support the new Nekketsu Kouha Kunio-kun.
Joined: 5/30/2005
Posts: 98
What do you mean by header data? I have never heard that term before. How would you factor in header data to that formula? Boco I am not sure if you answer is accurate or not because I have never heard the term "possible values" to refer to a bit sequence (except maybe in this topic).
Emulator Coder, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
It means if you were given a lump of 15360000 bits, you couldn't tell what resolution or bit depth it was. You need a few extra bytes at the start to read "800x600 RGB32" or some such. That's the "header", like a header on a page in a document. Possible values means that for 8 bits, you can have as "possible values" the following: 0000 0000 = 0 0000 0001 = 1 0000 0010 = 2 ..... 0000 1111 = 15 ...... 1111 1111 = 255 = 256 "possible values" The 24 bit version is 16,777,216 possible values. 16 bit is 65,536.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
gbagcn wrote:
What do you mean by header data? I have never heard that term before. How would you factor in header data to that formula?
Every image file format has a header section. Where do you think that, for example, the resolution information of the image is stored?
Joined: 5/30/2005
Posts: 98
Ok let me try this again. I am going to post what I think a bit sequence for a 256x256 image with 16 bits per pixel looks like. This bit sequence excludes the header data. The letter n represents 0 or 1. Ignore the -'s since they are just being used for spacing. 1.----------------2.--------------3a.-----3b.-----3c. nnnn-nnnn----nnnn-nnnn----nnnnn-nnnnn-nnnnnn 1. This part of the bit sequence is the length of the image. Since this bit sequence has 256 possible values then it should be able to represent the length. 2. This part of the bit sequence is the width of the image. Since this bit sequence has 256 possible values then it should be able to represent the width. 3. This part of the bit sequence is the bits per pixel of the image. Since the bits per pixel of the image is 16 I used 16 binary digits. I further divided this bit sequence to represent the intensity of red, blue, and green light. 3a represents the intensity of red light, 3b represents the intesity of blue light, and 3c represents the intensity of green light. Since the number of binary digits (count up the number of n's above) in this image is 32 (2^32=4294967296) and the number 4294967296 (this number must represent the number of bits right because 32 is too small of a number to represent them) seems too large for such a small resolution image I think I might be doing something wrong.
Former player
Joined: 3/30/2004
Posts: 1354
Location: Heather's imagination
Dot dot dot. Could you please actualy read the responses people have been giving you? Resolution of the image is stored in the header. You can't ignore header data and then put it in anyway. Most of your message makes no sense. Lets assume a 24-bit image of any size, and we'll ignore header data. As stated in the bit depth (= bits per pixel), each pixel is represented by 24 bits. Because 4 bits (16 values) can be represented by a hexadecimal digit (16 values) we can make the value of a single pixel more readable by using 6 hex digits instead. So we have each pixel as RRGGBB, with RR being two hex digits defining the red content, GG being two hex digits defining green content,a nd BB being two hex digits defining blue content. A red pixel would be FF0000. A white pixel would be FFFFFF. A black pixel would be 000000. And so on. The total (file) size of the (uncompressed) image (without header data) is the number of pixels multiplied by the bit depth. So with a 256x256x24 image, it takes up 256 (width) * 256 (height) * 24 (bit depth) / 8 (bits per byte) / 1024 (bytes per kilobyte) = 192kb. It is a 24-bit image (meaning each pixel has 24 bits) and is 192 kb (meaning total size).
someone is out there who will like you. take off your mask so they can find you faster. I support the new Nekketsu Kouha Kunio-kun.
Editor, Reviewer, Experienced player (978)
Joined: 4/17/2004
Posts: 3109
Location: Sweden
gbagcn: I recommend you to ask someone who understands this (your local computer nerd/teacher/professor) and have him explain it to you in person on paper, because it's obvious that the explanations people are giving here aren't getting through.
Joined: 5/30/2005
Posts: 98
Ok I guess that sort of makes sense but there is still one thing bothering me. Since pixels can display so many different colors and bit depth is related to the number of colors the pixel can display why is the bit depth number so small? If you took the hexadecimal number FFFFFF and converted it into base 10 it would be 16777216. Shouldn't this number have some sort of meaning? For one thing it is much larger than the number 256.
Former player
Joined: 3/30/2004
Posts: 1354
Location: Heather's imagination
As I said before, each hexidecimal digit is 4 bits. So a six-hex string is 24-bits (three bytes). 24-bit color is what's used to define colors on the internet and the like. Anyway. 0xFFFFFF is the maximum number in 24-bit color, and as you say, it's 16 777 215. Plus one (for 0x000000) and we have 16 777 216 possible colors in the 24-bit color space. As has been explained to you about 10 times now, 2^24 = 16 777 216. That is, 2^y = x, where y is the bit depth and x is the maximum number of colors that could be in the image.
someone is out there who will like you. take off your mask so they can find you faster. I support the new Nekketsu Kouha Kunio-kun.
Joined: 10/15/2007
Posts: 685
Okay, first, you need to understand the concept of additive color. In light, which is emitted by your monitor, all colors are created by the intensity of three base colors: Red, Green, and Blue. A bit is a binary digit, 0 or 1. A byte is eight bits long, containing a value between 00 and FF (or 0 and 255 in base-ten). In 24-bit color, each individual pixel is drawn with 24 bits of data that define the color. 24 bits = 3 bytes. Each byte defines the luminosity of red, green, and blue. FF0000 = Red. 00FF00 = Green. 0000FF = Blue. 000000 = black, the absense of all color. FFFFFF = white, the presence of all color. ... Now, 32-bit color is, in actuality, 24-bit color with an additional byte of data to represent opacity. ... Getting back to the maximum 'value' of 16.7 million, it is generally accepted that the average human eye tends to not discern colors of a much larger variety than this particular number. This is part of why nobody really made it a point to evolve beyond 24-bit color. The only significance that 16.7 million has is that it's the base-ten equivalent of FFFFFF, which is 3 bytes long, and the cleanest way to define a pixel in additive color, without going for extreme overkill. X-bit color just tells you how many bits of data are used per pixel to draw an image.
Kirby said so, so it must be true. ( >'.')>
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
gbagcn wrote:
If you took the hexadecimal number FFFFFF and converted it into base 10 it would be 16777216. Shouldn't this number have some sort of meaning? For one thing it is much larger than the number 256.
It's more practical to say "24-bit image" than "16777216-color image", especially since "24" is much easier to remember (and to understand in context) than "16777216", and also because the image probably doesn't use 16777216 colors (even if it could). "24-bit image" more unambiguously describes the color depth supported by the image format and the amount of space allocated for each pixel. "16777216-color image" is meaningless unless you happen to recognize the number and can deduce that it's actually referring to a 24-bit image.
superjupi wrote:
Now, 32-bit color is, in actuality, 24-bit color with an additional byte of data to represent opacity.
That's how it usually goes in practice. There's no rule which would force a 32-bit image to do so, though. It could perfectly use, for example, 10 bits per color channel. But yeah, in the general case it's a 24-bit image.
Getting back to the maximum 'value' of 16.7 million, it is generally accepted that the average human eye tends to not discern colors of a much larger variety than this particular number. This is part of why nobody really made it a point to evolve beyond 24-bit color.
That's not true. 24-bit coloring is not enough to cover the entire range of colors which the human eye can discern. For example, only 256 shades of gray can be represented with such an image, and the average person can perfectly distinguish the border between two large areas of gray which differ by only one value (in each color component, to get the next representable shade of gray). The reason why most images use 8 bits per color channel is simply because 8 bits is the most convenient amount of data, and 256 shades of each color component is usually enough for acceptable quality. There are several image formats, most prominently PNG, which support larger color depths. PNG supports up to 16 bits per color channel (ie. 48-bit images). This makes it possible to represent, for example, 65536 shades of gray, which starts much better bordering the limit which a human can distinguish. (Of course the disadvantage of this is that the image, quite obviously, requires much more space.) Even this, though, cannot represent all possible colors a human can see. That's because it uses the RGB color model. There are certain frequencies which a human can see and which fall outside the RGB range and thus cannot be reproduced with any device using RGB to produce colors. See more details at http://en.wikipedia.org/wiki/Gamut
Joined: 5/30/2005
Posts: 98
Ok so since 16777216 colors can be held in 24 bits does that means you could also hold 256 in 8 bits. The purpose of reducing 256 to 8 would be to make the units the same for all 3 numbers. Of course I know doing something like 8 bits x 8 bits x 24 bits = 1536 bits would probably be wrong since you already told me the right numbers to use. I don't know why it would be wrong though because using the same units for all 3 numbers makes more sense.