What's the maximum size an uncompressed 48x48 image can have? I'd like to set up a reference image for debugging.
48 * 48 = 2304
So, (2304 * number of channels * bytes per channel) bytes
W * H * BitsPerPixel
If BitsPerPixel is 32 (Millions of colors), then it would be 73,728 bits. divide that by 8 to get bytes (9,216). The actual size would vary between the uncompressed formats a bit, especially depending on their color capabilities.
For Bitmaps, this Wikipedia page mentiones some of the color options: http://en.wikipedia.org/wiki/Bitmap
Recently I wrote a primitive PNG writer. You have to put one byte infront of every line and add PNG as well as ZLIB headers and checksums. I'm not sure but I think you can have RGBA images with 16bit per channel. The raw data would be 48*49*2*4=9.4kB. So I would make sure that you can handle 16kB or so.
As you are talking about compression, I assume that you mean an image file.
The maximum size would depend on the file format and bit depth that you allow.
A 96 bpp TIFF image for example would be 46 kB.
A more reasonable format could be a 24 bbp BMP file, which is 7 kB.
Related
This is all of the information I was provided in the practice question. I am trying to figure out how to calculate it when prompted to do so on an exam...
How to determine the number of bytes necessary to store an uncompressed grayscale image of size 8000 × 3400 pixels?
I am also curious how the calculation changes if the image is a compressed binary image.
"I am trying to figure out how to calculate it when prompted to do so on an exam."
There are 8 bits to make 1 byte, so once you know how many bits-per-pixel (bpp) you have, this is a very simple calculation.
For 8 bits per pixel greyscale, just multiply the width by the height.
8000 * 3400 = 27200000 bytes.
For 1 bit per pixel black&white, multiply the width by the height and then divide by 8.
(8000 * 3400) / 8 = 3400000 bytes.
It's critical that the image is uncompressed, and that there's no padding at the end of each raster line. Otherwise the count will be off.
The first thing to work out is how many pixels you have. That is easy, it is just the width of the image multiplied by the height:
N = w * h
So, in your case:
N = 8000 * 3400 = 27200000 pixels
Next, in general you need to work out how many samples (S) you have at each of those 27200000 pixel locations in the image. That depends on the type of the image:
if the image is greyscale, you will have a single grey value at each location, so S=1
if the image is greyscale and has transparency as well, you will have a grey value plus a transparency (alpha) value at each location, so S=2
if the image is colour, you will have three samples for each pixel - one Red sample, one Green sample and one Blue sample, so S=3
if the image is colour and has transparency as well, you will get the 3 RGB values plus a transparency (alpha) value for each pixel, so S=4
there are others, but let's not get too complicated
The final piece of the jigsaw is how big each sample is, or how much storage it takes, i.e. the bytes per sample (B).
8-bit data takes 1 byte per sample, so B=1
16-bit data takes 2 bytes per sample, so B=2
32-bit floating point or integer data take 4 bytes per sample, so B=4
there are others, but let's not get too complicated
So, the actual answer for an uncompressed greyscale image is:
storage required = w * h * S * B
and in your specific case:
storage required = 8000 * 3400 * 1 * 1 = 27200000 bytes
If the image were compressed, the only thing you should hope and expect is that it takes less storage. The actual amount required will depend on:
how repetitive/predictable the image is - the more predictable the image is, in general, the better it will compress
how many colours the image contains - fewer colours generally means better compression
which image file format you require (PNG, JPEG, TIFF, GIF)
which compression algorithm you use (RLE, LZW, DCT)
how long you are prepared to wait for compression and decompression - the longer you can wait, the better you can compress in general
what losses/inaccuracies you are prepared to tolerate to save space - if you are prepared to accept a lower quality version of your image, you can get a smaller file
I have read severel posts like this one claiming that the size of a JPG texture can be calculated as
If each pixel contains 32 bits of information, then
307,200 * 32 = 9,830,400 bits of information
Divide by the 8 bits to become a byte value
9,830,400 / 8 = 1228800 bytes (Or 1.17 Mb)
which totally makes sense since each pixel is represented by a color value. Here comes the weird part:
I have these two JPG files
First JPG
which has the dimensions 242x198 and uses 24-bit color values.
Second JPG
which has the dimensions 3840x2400 and uses 24-bit color values.
Then I tried to calculate the sizes using the technique above and concluded that
The first JPG must have the size 242*198*24 = 1149984 bits = 1149984/8/1000 = 143.7 kb - now the actual file size is 47,6 kb?? So the calculation apparently gives a number above the actual size, why?
The second JPG must have the size 3840*2400*24 = 221184000 = 221184000/8/10000 = 27.6 mb - now the actual file size is 7.33 mb. So the calculation apparently gives a number above the actual size, why?
I have myself managed to draw the first JPG and made sure to export it without compression (JPG 100).
The whole point of JPEGs is that they are compressed to take up less space. If you resave your file as a BMP you'll get the sizes you expect (plus a bit extra for headers and alignment).
I'd like to know which is the image format which permits me to encode losslessly 0xFFFFFF colors, but I need the one which occupies less space on disk. I know that BMP, JPEG(variant), TIFF, PNG,(just to say some) are lossless, but which one is the one that, considering also zipping or whatever, can occupy less space?
A PNG image (16million.png) containing all possible RGB888 colors was published in 1996. It occupies 115,989 bytes. I have converted the same image to a MNG file of just 472 bytes. The current version of pngcrush (1.8.0) brings the PNG file down to 91514 bytes.
See Khalid Sayood's Lossless Compression Handbook.
If on the other hand you are asking about a format that can represent a single pixel in any one of the 16 million colors, then PNG takes 69 bytes
including the 8-byte PNG signature, the IHDR, IEND, and IDAT chunk overhead, and several bytes of zlib overhead within the IDAT chunk, while a simple PPM file only takes 14 bytes to represent such single-pixel images (P6 1 1 255 \n red green blue).
Between those extremes, the best compression depends upon the content of the image.
I created a monochrome bitmap image and stored it in secondary memory. The dimension of the image is 484 * 114. In monochrome each pixel of the image is represented by 1 bit so the size of the image should be 6.7 kb . But when I check the size by right on file in OS , it is 7.18 KB , I need the explanation why the size is different and not exact as I calculated?
Because of overhead of headers for example; your bitmap won't only store the bits representing your image but also (meta)information containing information such as width, height, bits per plane etc. The actual bitmap data is just a bunch of bytes, without this (meta)information your image might as well be 114 x 484 instead of 484 x 114. Take a look at, for example, the BMP fileformat.
Also, OS'es tend to round filesizes to particular block sizes (like 4Kib). Unless you state the exact filesize in bytes, OS and filetype all we can do is guess.
Bitmap images contain pure representation of raw data. A 512x512 24bit bitmap image (like game textures) is 768KB in size, as it should be. Why a 512x512, but 8-bit instead of 256KB, is 257KB? Also a 256x256 8-bit image is 65KB instead of 64! (66,614 bytes instead of 65536 bytes); but for the 24 bit one, it is exactly as it should be.
Thanks...I'm confused.
What do you mean with "bitmap image"? It is true that they contain raw data, but they may contain a header also.
And/Or there could be some rounding error in whatever interface is telling you "65 Kb". What is the exact length in bytes for the 64K image? Is it 65536 bytes, or something more?