Ok so since 16777216 colors can be held in 24 bits does that means you could also hold 256 in 8 bits.
Yes.
gbagcn wrote:
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.
I have no idea what you're talking about and most likely neither do you.
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.
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.
If you look at my wording, though, I'm in agreement with you. Indeed, a mere 256 tones of grey does not sufficiently cover the range of human eyesight. This is why I chose the words 'much larger' than 16.7 million, which would indicate that human eyes can indeed view a discernable difference between more than 16.7 million colors, albeit perhaps not a significantly higher number.
Valid point on 32-bit depth, though.
24 bits x 8 bits x 8 bits does not equal 1536 bits. It equals 1536 bits^3, but I don't know of any use for cubing that unit (or even squaring it), so that multiplication is obviously meaningless. The other numbers can't be converted to bits anyway.
The hypothetical 256x256 image mentioned earlier has 65536 pixels, so the size of the uncompressed image (not including the header) would be 24 bits/pixel * 65536 pixels = 1572864 bits = 192 kB.
I think I know how to cube it. Since the state space/possible values of bits can be represented as 2^(bits) what if for this problem you changed it to 2^(bits)^3 and then plug in 1536 to get 2^1536^3 = x. Since x had over 10^22 digits in it I am not going to post it all here but go see for for yourself by plugging the values into http://www.std.com/~reinhold/BigNumCalc.html. If you take the (log2)x = 4608 and this represents the number of bits (probably wrong about this but don't know why).
Nitrodon I think I could do the same thing for the numbers you came up with as well. Convert 65536 to 16 bits and then take 24 bits x 16 bits = 384 bits^2. Now if you did the same thing as above you would get 2^384^2 = x (which is another really big number). Now take (log2)x = 768. Once again I probably messed up somewhere but I don't know where.
There are 65536 different states for a set of 16 bits. This does not mean that "65536" and "16 bits" are the same number. You can't substitute one for the other in the multiplication.
So why are you allowed to reduce some numbers to bits and not others? You are allowed to reduce 16777216 colors to 24 bits so what is wrong with reducing 65536 to 16 bits? Since there are 65536 states in a set of 16 bits and a 256x256 image has 65536 pixels, you should be able to make it so each bit state represents the location of a single pixel.
Your probably right about not being able to multiply them though. What if you added them together instead. That would make 40 bits (24+16) but that number seems way too low.
So why are you allowed to reduce some numbers to bits and not others?
There's no "reduction" anywhere. 65536 is simply the amount of integers which can be represented with 16 bits. There's no reduction anywhere.
If someone says "using 6 decimal digits you can represent 100000 different values" is he reducing something to something else? No, he is simply stating that with 6 decimal digits you can represent 100000 values. That's it.
You are allowed to reduce 16777216 colors to 24 bits so what is wrong with reducing 65536 to 16 bits?
There's no reduction anywhere. That's like saying "1000 cubic centimeters can be reduced to 1 litre". That's not a "reduction". That's simply stating how many cubic centimeters fit in one litre. In the same way you can say how many numbers can be represented with 16 or 24 bits.
Since there are 65536 states in a set of 16 bits and a 256x256 image has 65536 pixels, you should be able to make it so each bit state represents the location of a single pixel.
You can index a 256x256-pixel image with a 16-bit number, but what does that have to do with your original questions? What does that have to do with anything? It certainly isn't related to bit depth (or particularly to images at all).
Your probably right about not being able to multiply them though. What if you added them together instead. That would make 40 bits (24+16) but that number seems way too low.
you should be able to make it so each bit state represents the location of a single pixel.
The location of each pixel is given by the order of the file. If my image format was left-to-right top-to-bottom and I was describing a tiny 2x2 picture in 24 bit color I could say 000000888888CCCCCCFFFFFF and have that be the picture. I don't need to specify which pixel is the black one because the order already specifies the location.
Anywa, you should try actually reading what people have told you rather than making up stuff.
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.
Ok I figured out what I was doing wrong. That 40 bit file that I was making would only be able to store the color and location of a single pixel. Since images are made up of multiple pixels this isn't enough space to store an entire image. Also the location of a pixel isn't even important since you can just line them up next to each other.
First you read 24 bits and then you apply them to a single pixel. Then you read the next 24 bits and apply them to the next pixel. You repeat this process 65536 times so thats why you multiply 65536 x 24 = 1572864 bits.
Now there are still a few things I am not completely sure of that I haven't mentioned yet. If you wanted to find the total number of possible images you could generate (256x256, 24 bits per pixel) you would take 16777216^65536 right. You could also find it by taking 2^1572864. When I calculated these both of them resulted in a 473480 digit number that looked like it was equal so I think 16777216^65536 = 2^1572864. I am pretty sure you can label it as 473480 bits. If you square this number you get 224183310400 and I think that number represents the number of bits that every single 256x256, 24 bit picture would take up (every possible state of the image, with a new image file for each new state).
Ok just ignore that 3rd paragraph in my last post since I figured out I was doing some things wrong in that calculation. If you want to find the total amount of space every 256x256, 24 bit picture takes up first you multiply those numbers like I did earlier and get 1572864 bits. Then you need to figure out how many possible states those bits have and to find that do 2^1572864. Then take 1572864 x 2^1572864 and the answer should represent the number of bits all possible 256x256, 24 bit images take up. I am pretty sure that I did this right since this works for smaller file sizes as well.
