What exactly is the correlation between the amount of pixels in an image and the correlating space it will take up on one's hard drive? I know that the more pixels / more storage but is there an exact linear correlation between these two metrics or is it more complicated than that?
2 Answers
Bits.
A bit is a single unit of data. A group of bits forms a byte. Generally there are 8 bits per single byte. Groups of bytes form a kilobyte
- 8bits = 1 Byte
- 1024 bytes = 1 kilobyte (kb)
- 1024 Kilobytes = 1 Megabyte (mb)
- 1024 Megabytes = 1 Gigabyte (gb)
- 1024 Gigabytes = 1 Terabyte (tb)
- 1024 Terabytes = 1 Petabyte (pb)
- ... and so on
RGB images are generally 24bits images. That means each pixel takes 24 bits to store - 8 red, 8 green, 8 blue. Or in other words 1 byte red, 1 byte green, 1 byte blue per pixel So, if you've got a 10 square pixel image that's 100 pixels, 2400 bits, or 24 bytes. The larger the pixel width and pixel height of the image the more bytes it takes.
Be aware, although most commonly 24bit, RGB images can also be 32bit, 48bit, 64bit, or even 96bit
As for "how much hard drive space" it takes, that's a relative term. Hard drives can be formatted in various ways. Some use 4bit architecture - meaning the smallest data size used is 4bits. Others may be formatted to 8bit architectures, using 8 bits as the smallest data size. So on an 8 bit system, if you have a 4bit image, the formatting of the hard drive still allots 8bits for that image. So, there's no way for anyone to know how much hard drive space an image will take without knowing the specific hard drive specifications. You can read more on hard drive architecture at Wikipedia.
-
Good explanation, however you didn't include anything on compressed, which is the reason that there is no strict linear correlation - the same image can have varying file sizes depending on the storage format ... Sep 30, 2014 at 21:48
-
There's no way to calculate "compression" in general terms. There are a ton of algorithms for compression and each one may or may not react differently give the same image. I don't see how anyone could calculate compression in general terms.– ScottSep 30, 2014 at 21:50
-
Yeah but the question was if the pixel dimensions are linear (linearly?) correlated to the file size, which they aren't mostly because of compression. So of course you can't elaborate every compression algorithm there is, I'm only saying you should mention it to not confuse the asker ... Sep 30, 2014 at 22:41
Images store a two dimensional array. Uncompressed data thus uses up roughly:
x dimension * y dimension * size of one channel (usually 1-4 bytes)* number of channels per layer (usually 3-5) * number of layers
Note this is a big number for big images. Much of this data is redundant because many layers contain areas of same color etc. Compression acts on this redundancy. Its impossible to say how much the image gets compressed, generally the image compresses better the larger it is. Some images compress really well others not so much. It is common to see that some larger images are smaller on disk than smaller ones. Especially 2bit 2 color images compress amazingly well for their pixel size.
Then there is the disk itself the disk usually allocates a allocation block so no matter what your image size this is the minimum space it takes. In effect the image size is quantized by allocation blocks. Big disks can have huge allocation blocks.
So while pixel images technically grow exponentially its impossible to tell because of compression. Its a bit like putting random stuff into a opaque balloon blow it up, and ask people what size it will take after its deflated. Imopossible to know unless you know what the balloon contains.
Best not draw any conclusions between size on disk and size in pixels. But certainly knowing the upper limit might help.
